Tras ejercer como jurado en The Retro Christmas Arcade —un hackathon internacional de 72 horas organizado por Hackathon Raptors—, Tomas Khellstrom fue invitado a unirse a la asociación como Fellow. La invitación es revisada por pares y altamente selectiva: los candidatos son evaluados por un comité aleatorio de miembros existentes según criterios rigurosos. Para Khellstrom, fue el último hito de una carrera construida sobre dos productos de aviación utilizados en todo el Grupo Lufthansa, una plataforma de reservas surgida durante la pandemia de COVID que generó millones en su primera semana, y una década de ingeniería en sistemas de alto riesgo con dinero real.
Hablamos con él sobre qué significa juzgar código bajo presión, qué busca en un equipo y por qué la responsabilidad —no el talento— es la cualidad que distingue a los buenos ingenieros de los excelentes.
EL PANEL DEL HACKATHON
Recientemente fuiste jurado en The Retro Christmas Arcade: 25 equipos, 72 horas y un motor de juegos basado en Rust que compila a WebAssembly. ¿Qué evaluabas exactamente al revisar esos proyectos?
El formato estaba deliberadamente limitado: Turbo, un motor de juegos que la mayoría de los participantes nunca había utilizado, con 72 horas en el reloj. Eso elimina la red de seguridad de las herramientas conocidas y obliga a un equipo a mostrar cómo piensa realmente: cómo define el alcance de un problema que no comprende del todo, qué elimina y por qué, cómo gestiona las últimas doce horas cuando el plan original ya se ha derrumbado.
Los criterios estaban estructurados en cinco dimensiones: la jugabilidad y el factor diversión tenían el mayor peso, con un 30%, seguidos de la autenticidad arcade y la ejecución técnica, con un 25% cada una, mientras que la integración temática navideña y la innovación completaban el resto. Lo que observaba por debajo de esas puntuaciones era la calidad de las decisiones. Un equipo que entregó una plataforma de diez niveles con una interfaz de selección de niveles, variedad de enemigos y un jefe final —como la entrada de primer puesto, Santario— no lo hizo por accidente. Eso es disciplina en la definición del alcance y coherencia en la entrega. Un equipo que renderizó todos los elementos visuales de forma procedural, sin ningún archivo de imagen externo, en 1.136 líneas —como Santa’s Endless Run— está demostrando un tipo de maestría diferente: la restricción como elección de diseño, no como limitación.
Los proyectos que encontré más significativos desde el punto de vista técnico eran aquellos en los que la arquitectura decía algo sobre el criterio del equipo. Entendían qué importaba y tomaban decisiones explícitas para llegar ahí.
Después de Christmas Arcade, fuiste invitado a unirte a Hackathon Raptors como Fellow. El proceso de selección es revisado por pares —un comité aleatorio de Fellows existentes evalúa a los candidatos según criterios definidos—. ¿Qué significa ese tipo de reconocimiento para ti en esta etapa de tu carrera?
Es significativo precisamente porque no es algo que uno mismo solicita. La Fellowship de Raptors funciona a través de un proceso de elección estructurado: se forma un grupo de Fellows existentes con experiencia relevante, se evalúa a los candidatos según criterios establecidos y la votación se realiza con transparencia y mecanismos de rendición de cuentas integrados. Los Fellows que ya forman parte de la asociación incluyen ingenieros de Okta, Snap, Zscaler, Harman y Microsoft —personas que construyen a una escala considerable.
Ser reconocido por ese grupo de pares, en lugar de por un empleador o una institución certificadora, es una señal diferente. Refleja cómo piensas y cómo contribuyes al campo, no solo lo que has lanzado comercialmente. Para una solicitud de visado, ese tipo de validación externa por parte de una asociación profesional internacional también tiene un peso estructural significativo: es independiente, está documentado y evaluado por profesionales del sector, no por el propio candidato.
EL TRABAJO DETRÁS DEL RECONOCIMIENTO
El contexto del hackathon es relativamente reciente. Pero el historial de ingeniería que lo respalda se remonta a más de una década. Establezcamos la base: ¿qué has construido realmente y a qué escala?
El trabajo comercial más significativo fue en Lufthansa Innovation Hub, donde fui líder técnico en dos productos.
El primero fue FlightPass: un bono de vuelos estilo suscripción para las aerolíneas del Grupo Lufthansa, finalmente desplegado en Lufthansa, Austrian Airlines, SWISS y Brussels Airlines. El concepto era un «bono de 10 viajes» para rutas frecuentes: precios predecibles, vuelos agrupados y beneficios de fidelización para segmentos específicos de clientes, como viajeros de negocios y estudiantes. Mi rol evolucionó de ingeniero senior a líder técnico a lo largo del ciclo de vida del proyecto: definí la estrategia de integración, fui responsable de los contratos de API, coordiné entre múltiples organizaciones internas y externas, y guié la secuencia de entregas en un complejo grafo de dependencias. El producto se lanzó en 2019, atrajo a decenas de miles de usuarios en su primera iteración y logró una retención significativamente más alta que los flujos estándar de reserva puntual, lo que validó el modelo tipo suscripción.
El segundo producto fue una plataforma de intercambio de reservas surgida durante el COVID. Cuando las cancelaciones masivas llegaron en 2020, el objetivo era permitir a los clientes convertir reservas canceladas en bonos de forma rápida y remota, reduciendo la carga sobre las operaciones de atención al cliente y preservando los ingresos futuros. Del concepto a la producción se tardaron aproximadamente dos meses. El equipo gestionó en paralelo los flujos de backend, frontend, integración y pruebas. Introdujimos un enfoque basado en libro mayor para rastrear la emisión de bonos, el uso parcial y los ajustes de saldo; la integridad financiera era innegociable. Realizamos pruebas de carga de manera intensiva porque esperábamos picos de tráfico inmediatos. Cuando el producto se lanzó, generó una facturación de varios millones de dólares en la primera semana.
Más allá de esos dos productos principales: lideré una migración de Heroku a una arquitectura de Kubernetes y AWS utilizando Terraform, que redujo los costes de infraestructura y mantenimiento en aproximadamente un 60% —decenas de miles de dólares anuales— gracias al ajuste del cómputo, el autoescalado, la eliminación del margen de la plataforma y la creación de entornos reproducibles. También construí una biblioteca de integración para la API de reservas de aerolíneas Farelogix —un sistema estándar del sector con aproximadamente un 10% de cobertura documental—. Hicimos ingeniería inversa de los endpoints no documentados interceptando el tráfico real de la interfaz de agentes del aeropuerto, construimos la biblioteca con cerca del 100% de cobertura de pruebas, incluyendo pruebas de integración respaldadas por VCR, y la convertimos en la base compartida para múltiples equipos. Esa biblioteca es el tipo de infraestructura interna que multiplica la velocidad de entrega en toda la organización.
«El problema más difícil era la consistencia financiera bajo alta carga con sistemas externos poco fiables.»
La plataforma de COVID es llamativa: facturación multimillonaria en la primera semana, construida en dos meses. ¿Cuál fue el problema técnico más difícil y cómo lo resolviste?
El problema más difícil era la consistencia financiera bajo alta carga con sistemas externos poco fiables. Si un bono se emitía parcialmente y la confirmación del sistema de reservas externo fallaba, el sistema podía derivar: el cliente vería un error, asumiría que la transacción había fallado y volvería a intentarlo. En un sistema de bonos, eso produce emisiones duplicadas. En términos de fintech, eso no es un error, es un evento que destruye la confianza.
Lo resolvimos rediseñando la arquitectura para imponer límites transaccionales estrictos, con reintentos post-transacción basados en cola para las operaciones externas. Si la transacción principal tenía éxito, la confirmación posterior se convertía en un proceso en segundo plano con consistencia eventual, reintentado de forma segura e idempotente, sin efectos secundarios visibles para el usuario.
Eso requirió tiempo adicional de implementación en un calendario que no tenía margen. Tomé la decisión de dedicar ese tiempo. Cuando llegó el día del lanzamiento y la alta carga golpeó los servidores, vimos presión en el rendimiento pero cero inconsistencias contables. La decisión fue correcta. En situaciones de alta incertidumbre —y un lanzamiento a escala pandémica es de las más inciertas que existen— proteger los invariantes financieros vale más que recortar tiempo de desarrollo.
SOBRE EL CRITERIO EN INGENIERÍA Y CÓMO DESARROLLARLO
Cuando revisas un proyecto —en un hackathon o en una revisión de código—, ¿qué distingue una buena ingeniería de una gran ingeniería?
La señal más clara es si el ingeniero pensó en qué podría salir mal. No de manera ansiosa, sino sistemática. ¿Las pruebas verifican invariantes reales del usuario o solo detalles de implementación? ¿La arquitectura hace explícitos los modos de fallo o los oculta? ¿El flujo de datos es predecible y trazable, o depende de suposiciones implícitas?
En un hackathon, eso se manifiesta en si un proyecto gestiona los casos extremos que el equipo tuvo tiempo de considerar; no todos, pero sí los que importan. En código de producción, se manifiesta en si un cambio es seguro de realizar seis meses después por alguien que no estuvo presente cuando se escribió.
Mi marco de KPI personal para evaluar cambios técnicos tiene tres capas. Primero: cobertura por contrato de los flujos críticos, no el porcentaje bruto de pruebas, sino si el camino principal y los modos de fallo más comunes están verificados explícitamente mediante pruebas de integración o E2E. Segundo: observabilidad y capacidad de diagnóstico, ¿puede el equipo de QA o soporte entender lo que ocurrió en producción sin involucrar a un desarrollador? Tercero: robustez del flujo de datos, ¿el acoplamiento arquitectónico mejora en lugar de degradarse con el tiempo?
Un ejemplo reciente: asumí la responsabilidad de un chatbot MVP basado en LLM que tenía aproximadamente un 10% de cobertura de flujos, sin alertas de producción y con un registro mínimo. En el transcurso de un trimestre, elevamos la cobertura de los flujos principales al 80%, introdujimos docenas de alertas que abarcaban desde la salud de la infraestructura hasta caídas en métricas de negocio, construimos un panel del embudo de marketing y estructuramos el registro de entradas/salidas para que el equipo de QA pudiera rastrear los incidentes de forma independiente. El tiempo de diagnóstico de incidentes se redujo de manera significativa. El comportamiento en producción pasó de ser anecdótico a medible.
Has escrito sobre TDD como una filosofía de responsabilidad, no como una metodología de pruebas. ¿Qué quieres decir con eso?
La pregunta que hago no es «¿escribiste la prueba primero?», sino «¿existe una prueba y se trata como parte de la arquitectura?». Una buena prueba es un contrato. Documenta el comportamiento esperado, define los invariantes y hace explícitas las suposiciones. Cuando falta una prueba en un flujo crítico, eso no es una brecha en las pruebas: es una brecha de responsabilidad. Nadie se ha comprometido formalmente con lo que se supone que debe hacer ese componente.
El ritual práctico que utilizo al incorporarme a un proyecto es escribir yo mismo una o dos pruebas representativas de extremo a extremo o de integración, desde el principio. Eso establece el estándar y reduce la resistencia: los ingenieros ven que las pruebas no tienen que ser lentas ni frágiles. Suelo introducir bibliotecas de estilo VCR para que las pruebas de integración puedan almacenar en caché las entradas/salidas externas, haciéndolas estables y rápidas sin sacrificar la cobertura de los flujos reales.
En las revisiones de código, las pruebas de nivel de flujo que faltan se señalan de la misma manera que la gestión de errores ausente. Con el tiempo, eso cambia la percepción: las pruebas dejan de ser «trabajo extra» y pasan a ser parte de cómo se define qué significa que algo está terminado.
La demostración más concreta de por qué esto importa: una vez introdujimos un módulo que cargaba un servicio adicional sobre un flujo de pago existente. El flujo original tenía una sólida cobertura de extremo a extremo; el nuevo módulo inicialmente solo tenía pruebas unitarias. Durante la revisión, señalé que no teníamos ninguna prueba que cubriera el flujo combinado. Tras añadir cobertura de integración, encontramos un problema grave: en algunos casos extremos, el paso adicional fallaba y mostraba una pantalla de error, pero el pago principal ya había sido procesado con éxito. Desde la perspectiva del usuario, la transacción había fallado; la reacción natural es volver a intentarlo. Eso es un doble cobro. Detectarlo antes de llegar a producción evitó problemas de conciliación financiera, carga extra en el soporte y daño reputacional. Las pruebas unitarias por sí solas nunca lo habrían detectado.
También has dirigido programas de mentoría para personas sin formación técnica, incluyendo, en un caso, a una empleada de caja de supermercado que llegó a ser ingeniera senior. ¿Cómo fue ese proceso?
El diseño del currículo surgió de mi propia experiencia de aprendizaje, no solo en programación sino también en idiomas y otras habilidades. El patrón que identifiqué es que los principiantes rara vez se detienen por la complejidad en sí misma; lo que los frena es la velocidad a la que crece. Así que reduzco deliberadamente esa curva. En lugar de cubrir muchos temas con pocos ejercicios cada uno, cubro menos ideas fundamentales con muchos ejercicios: de 15 a 20 pequeñas variaciones por concepto, con repetición espaciada. Ese enfoque permite que quienes aprenden rápido avancen a su ritmo, a la vez que garantiza que quienes necesitan más tiempo no se queden atrás ni se sientan desbordados.
La dimensión mental importa tanto como la técnica. La mayoría de los principiantes llevan consigo creencias como «no soy capaz de esto» o «la programación es solo para cierto tipo de personas». Hablamos de esas creencias directamente: sobre los errores como retroalimentación, no como fracaso; sobre el progreso como algo gradual y visible, no repentino.
La empleada de caja que se unió en 2016 es el ejemplo al que siempre vuelvo. Sin ninguna formación técnica. Un trabajo físicamente exigente, responsabilidades familiares, problemas de salud y períodos de meses en los que dejaba de estudiar por completo. A lo largo de aproximadamente 18 meses de práctica constante y mentoría, consiguió un puesto como desarrolladora júnior. Varios años después alcanzó el nivel senior, y su crecimiento salarial acabó superando el mío al inicio de mi propia carrera. Esa transformación tiene más significado para mí que cualquiera de los resultados comerciales en los que he participado.
SOBRE LA IA, EL FUTURO DE LA INGENIERÍA Y LO QUE DEBERÍAN HACER LOS INGENIEROS JÚNIOR
Has descrito planes para combinar materiales de código abierto con IA para crear itinerarios educativos gratuitos. ¿Cómo sería eso en la práctica?
El público objetivo son principiantes motivados e ingenieros júnior en etapas tempranas que no tienen acceso a formación técnica formal. El currículo estaría estructurado en torno a contratos y flujos, no en torno a sintaxis. Módulos principales: fundamentos de programación, APIs e integración, pruebas desde el nivel unitario hasta E2E, fundamentos de sistemas distribuidos, pensamiento en rendimiento y complejidad, y prácticas de responsabilidad que incluyen observabilidad y análisis de incidentes.
El formato combinaría vídeos conceptuales breves, grandes conjuntos de ejercicios progresivos, laboratorios interactivos y mentoría en vivo opcional. En lugar de «construye una aplicación de lista de tareas», los estudiantes implementarían funcionalidades pequeñas y definirían contratos para ellas, incluyendo la escritura de pruebas que codifiquen las expectativas del negocio. Los proyectos simularían escenarios del mundo real: integrarse con una API inestable, gestionar reintentos, razonar sobre idempotencia, leer registros para diagnosticar un fallo.
La IA desempeña tres roles en ese sistema. Tutor personal: responde preguntas, explica conceptos de múltiples maneras y adapta la dificultad de forma dinámica. Revisor de código: no comprueba la sintaxis, sino que plantea preguntas críticas sobre casos extremos, invariantes y compromisos. Personalizador del currículo: detecta lagunas en la comprensión y asigna ejercicios específicos.
El objetivo no es producir programadores rápidos. Es producir ingenieros capaces de pensar en sistemas, verificar el comportamiento y colaborar tanto con personas como con agentes de IA.
¿Cuáles son las tres habilidades que un ingeniero júnior debería priorizar hoy para convertirse en un ingeniero senior resiliente en cinco años?
Primera: pensar en términos de contratos y pruebas. Aprende a definir el comportamiento de forma explícita. Independientemente de si el código se escribe manualmente o lo genera un agente de IA, la capacidad de especificar invariantes, escribir pruebas de integración y validar flujos de extremo a extremo sigue siendo fundamental. Las herramientas cambian; la necesidad de contratos verificados no.
Segunda: razonamiento desde primeros principios sobre sistemas. Entiende la complejidad, el rendimiento, el flujo de datos, la concurrencia y los modos de fallo a un nivel que no dependa del framework específico que estés utilizando. Los modelos mentales sobre cómo se comportan los sistemas bajo carga o en situaciones de fallo son duraderos de una manera que el conocimiento de cualquier tecnología particular no lo es.
Tercera: responsabilidad más allá del código. Escribir código se está abaratando. Revisar código, hacer las preguntas arquitectónicas correctas, gestionar los compromisos y asumir responsabilidad por los resultados son habilidades que se están volviendo más valiosas, no menos. Un ingeniero senior resiliente no solo produce código; reduce la incertidumbre y da forma a los sistemas.
En cinco años, escribir código llevará menos tiempo. Pensar llevará más. Los ingenieros que prosperen serán los que traten a la IA como un asistente potente y se vean a sí mismos como diseñadores de sistemas responsables.
PREGUNTA FINAL
Has construido sistemas utilizados por cientos de miles de personas, lanzado un producto en una crisis global y mentorizado a alguien desde cero hasta el nivel de ingeniero senior. ¿Qué quieres que los lectores se lleven?
Que la fiabilidad y el crecimiento rara vez provienen del talento, sino de la disciplina y la responsabilidad. Ya sea que estés construyendo sistemas fintech, lanzando productos de aviación o aprendiendo a programar por primera vez, la diferencia suele estar en la seriedad con la que tratas los contratos, los casos extremos y las consecuencias de tus decisiones.
También quisiera que la gente se llevara la idea de que los caminos profesionales no tienen que ser lineales ni perfectos. Puedes dejar la universidad, dudar de ti mismo durante años, cambiar de país, cambiar de sector, y aun así construir sistemas significativos que importen a escala. Lo que cuenta es si sigues avanzando y si eliges clarificar los problemas en lugar de evitarlos.
Y para cualquiera que esté fuera de los grandes centros tecnológicos: la gran ingeniería no pertenece a una sola geografía. Con la mentalidad adecuada y acceso a la colaboración global, puedes construir sistemas a gran escala y resilientes desde casi cualquier lugar, incluyendo una ciudad tranquila con largos otoños y montañas nevadas cerca.
«La fiabilidad y el crecimiento rara vez provienen del talento. Provienen de la disciplina y la responsabilidad.»
