Cómo un equipo de 5 personas entrega a 10×: ingeniería nativa de IA en eSimphony

eSimphony está construido por un equipo de ingeniería de cinco personas. El producto cubre más de 150 países, lanza apps nativas para iOS y Android, opera un stack de integración con operadores multirregión, soporta cinco idiomas de extremo a extremo y entrega cambios de producto semanalmente. No somos una telco de mil personas. Somos un equipo pequeño operando con un apalancamiento deliberado.

El apalancamiento viene de un enfoque específico de la ingeniería que hemos interiorizado durante los últimos 18 meses. Lo llamamos desarrollo nativo de IA. Así es como se ve en la práctica.

La forma del equipo

Cinco ingenieros. Un diseñador de producto. Un CEO que todavía escribe algunas de las especificaciones del producto. Sin product manager formal: las especificaciones vienen del CEO + redacción asistida por Moza + criterio de ingeniería. Sin equipo dedicado de QA: las pruebas son parte del bucle de construcción. Sin DevOps separado: la infraestructura es responsabilidad de quien lanza la función.

Esto no es una presunción. Es una restricción. Con este tamaño de equipo, la única forma de entregar un producto del alcance de eSimphony es multiplicar la salida de cada ingeniero. La IA es el multiplicador en el que nos hemos apoyado.

El flujo de trabajo de cinco etapas

Cada cambio en eSimphony —desde un arreglo de texto hasta una nueva integración con un operador— pasa por las mismas cinco etapas. Cada etapa está asistida por IA; cada etapa tiene un humano en el bucle.

1. Descubrir (sin barreras técnicas)

Cuando llega un nuevo requisito ("necesitamos integrar al operador X para la cobertura de Egipto"), el primer movimiento del ingeniero no es asumir lo que no sabe. Es usar la IA para explorar el territorio desconocido en 20 minutos en lugar de 2 días.

En la práctica: un ingeniero que nunca ha integrado un MVNO egipcio puede consultar a un asistente de IA con la documentación de la API del operador, obtener un resumen estructurado de la superficie de integración, hacer preguntas de seguimiento sobre casos atípicos ("¿cuál es el flujo típico de eKYC para este mercado?") y producir una evaluación de una página sobre esfuerzo, riesgos e incógnitas antes del almuerzo.

Lo que cambia: el cuello de botella ya no es "¿tenemos un ingeniero que conozca este dominio?". Es "¿puede el ingeniero que tenemos, aumentado con IA, volverse lo suficientemente competente en este dominio en unas pocas horas?". Casi siempre, sí.

2. Especificar (horas, no semanas)

La mayoría de las especificaciones de producto en la mayoría de las empresas tardan de 1 a 3 semanas: un PM redacta, los stakeholders revisan, se añaden casos atípicos, se refinan los criterios de aceptación, luego ingeniería vuelve a dimensionar. Para cuando una especificación está "lista", la oportunidad original ha cambiado.

Nuestro enfoque: el ingeniero (o el CEO, dependiendo de la función) redacta una idea de producto de una línea. La IA la expande en un PRD estructurado: flujo de usuario, casos atípicos, métricas de éxito, criterios de aceptación, preguntas abiertas. El equipo lo refina en una sesión de trabajo de 45 minutos. La especificación se entrega a ingeniería el mismo día.

El compromiso: las especificaciones de este proceso son ligeramente más rústicas que una especificación tradicional liderada por un PM durante 2 semanas. Lo aceptamos. La compresión en el tiempo hasta la primera implementación vale la ambigüedad adicional, que se resuelve durante la construcción, no antes.

3. Diseñar (bucle de retroalimentación rápido)

Para funciones con UI significativa, nuestro diseñador trabaja junto al ingeniero en un bucle de "diseño-construcción-retroalimentación" medido en minutos, no en días. Maquetas generadas por IA (plugins de Figma + generadores de imágenes) exploran variantes rápidamente. El ingeniero entrega un prototipo en unas pocas horas. El diseñador revisa en hardware real. La iteración se mide en ciclos del mismo día.

El resultado es que diseño e ingeniería no son secuenciales: son concurrentes. Para cuando el diseño es "final", la implementación ya está casi en producción.

4. Construir (la IA escribe el código; los humanos revisan cada diff)

Esta es la parte más visible del enfoque nativo de IA. El proceso de ingeniería en eSimphony hoy:

• La IA genera ~90% del código nuevo (Cursor, Claude, GitHub Copilot, a menudo en combinación)
• Los ingenieros escriben las decisiones arquitectónicas, los límites de integración, la lógica de negocio complicada que requiere un conocimiento profundo del sistema
• El 100% del código es revisado por humanos antes del merge. Cada diff. Cada PR. Sin excepciones.

Este último punto es crítico y a menudo malinterpretado. "La IA escribe el código" no significa "ningún humano mira el código". Significa que el rol del ingeniero cambia de teclear implementación a revisar implementación. El trabajo cognitivo —¿esto coincide con la especificación, esto maneja los casos atípicos, esto encaja con la arquitectura, esto escala— sigue siendo del ingeniero. El trabajo mecánico —traducir intención en código sintácticamente correcto e idiomático— se delega.

Un PR típico en eSimphony tiene:

• 200-800 líneas de código cambiadas (vs ~100-200 tradicionales en equipos de la era 2024)
• 1 ingeniero revisando en detalle
• A menudo pruebas unitarias generadas por IA con >80% de cobertura sobre código nuevo
• Comentarios del revisor enfocados en arquitectura, no en sintaxis

5. Entregar (adaptarse en minutos)

La entrega es gradual: feature flags para cambios riesgosos, despliegues canary para servicios de backend, telemetría monitoreada por IA que detecta anomalías a los pocos minutos del lanzamiento. Cuando una entrega rompe algo, el rollback se mide en minutos, no en horas.

La parte de "telemetría monitoreada por IA" merece una frase: post-despliegue, un agente de IA vigila anomalías en tasas de error, latencia, problemas reportados por usuarios y conversión. Cuando las anomalías cruzan un umbral, se llama al ingeniero de guardia con un resumen de las causas raíz probables. Esto comprime el tiempo de detección de "el usuario reporta un bug a las 9 a. m." a "la alerta se dispara a las 09:03".

Los números

Métricas aproximadas de los últimos 12 meses:

• Ciclo de sprint: 1 semana. Las nuevas funciones se lanzan semanalmente; las correcciones pequeñas se lanzan a diario.
• 5 ingenieros trabajando a tiempo completo en producto. Un ingeniero adicional contratando a tiempo parcial.
• >90% del código nuevo es generado por IA (Cursor + Claude principalmente).
• 100% del código fusionado ha sido revisado por humanos.
• Tiempo mediano desde la especificación de la función hasta producción: 5-10 días.
• Incidentes de producción por trimestre: 1-2. Por debajo del promedio de la industria para nuestro alcance.
• Tickets de atención al cliente escalados a ingeniería: ~5/semana. La mayoría se resuelven el mismo día.

Estos números no son teóricos. Son el tempo operativo real de nuestro equipo.

Lo que esto no es

Vale la pena ser explícitos sobre lo que el desarrollo nativo de IA en eSimphony no significa.

No es "vibe coding". El código se revisa línea por línea. Las decisiones arquitectónicas las toman humanos. La IA acelera el tipeo, no el pensamiento.

No es "sin pruebas". Las pruebas generadas por IA tienen debilidades específicas (tienden a probar caminos felices más a fondo que los casos atípicos), así que los ingenieros añaden pruebas escritas a mano para los bordes. La cobertura de pruebas está consistentemente por encima del 80% en código nuevo.

No es "no se necesitan ingenieros senior". Al contrario. La IA aumenta dramáticamente el valor del criterio senior, porque los ingenieros senior pueden revisar y refinar la salida de la IA de 5 a 10 veces más rápido de lo que podrían escribirla desde cero. Los ingenieros junior usando IA sin revisión senior tienden a producir código que compila pero es estructuralmente frágil.

No es "sin pensamiento de diseño o producto". La IA es inútil sin especificaciones claras y flujos de usuario bien pensados. El trabajo cognitivo de "qué construir, por qué, para quién" sigue siendo humano.

Lo que requiere

Tres cosas, en orden de importancia.

1. Revisión humana estricta

Cada línea de código generado por IA pasa por la revisión de un ingeniero senior antes del merge. La tentación de saltarse la revisión para cambios pequeños "obviamente correctos" es real y peligrosa. Hemos mantenido la línea en el 100% de revisión.

2. Barandillas arquitectónicas estrictas

Cuando la IA genera código, sigue las convenciones locales. Convenciones fuertes = salida de IA fuerte. Hemos invertido mucho en límites de módulo claros, nomenclatura consistente, interfaces bien tipadas y documentación explícita de "cómo hacemos las cosas aquí" para que la IA pueda hacer coincidir patrones limpiamente.

3. Aceptación cultural de la IA como predeterminada

El equipo ha acordado, explícitamente, que la asistencia de IA es la predeterminada en cada flujo de trabajo. Los nuevos ingenieros son incorporados con este predeterminado. La oposición ("pero prefiero escribirlo yo mismo") se escucha y discute, pero la norma del equipo es que la IA maneja el trabajo mecánico a menos que haya una razón específica para que no lo haga.

Para qué no usamos IA

• Revisar código generado por IA (queremos ojos humanos frescos)
• Decidir qué construir (la estrategia de producto es humana)
• Escalaciones directas de atención al cliente (los humanos manejan los casos difíciles)
• Evaluaciones de desempeño y retroalimentación del equipo (solo humanos)
• Decisiones de contratación (solo humanos, aumentadas con IA para sourcing y filtrado)

El patrón: la IA aumenta la ejecución; los humanos son dueños de las decisiones.

Por qué esto importa para el producto

La salida de este flujo de trabajo es visible en el producto. Hemos entregado:

• Arquitectura de eSIM para toda la vida (un proyecto de varios trimestres en la mayoría de las empresas)
• Moza, la compañera de viajes con IA, en cinco idiomas
• Planes Dinámicos con IA en tres regiones
• Solución de problemas con IA con auto-curación
• Apps nativas de iOS y Android con lanzamientos semanales
• Backend multirregión con uptime de 99.9%+
• Localización en 5 idiomas en toda la superficie del producto

Esta lista normalmente requiere de 30 a 50 ingenieros y más de 3 años. La hemos entregado con 5 ingenieros en 18 meses.

Una nota sobre el reclutamiento

Estamos haciendo crecer al equipo con cuidado. Los ingenieros a los que les va bien aquí comparten tres rasgos:

1. Alto criterio por encima de alta producción. La IA maneja el tipeo; queremos ingenieros que sobresalgan revisando, decidiendo y dando forma.
2. Cómodos con la IA como un par. Ingenieros que tratan a la IA como un compañero de trabajo (delegan en ella, la revisan, la cuestionan) en lugar de como un oráculo mágico o una amenaza a su identidad.
3. Les importa el usuario. Los flujos de trabajo nativos de IA son lo suficientemente rápidos como para producir mucho código que compila pero no importa. Los ingenieros que pueden anclar cada PR en "¿esto ayuda al usuario?" producen el mejor trabajo.

Si eres tú, estamos contratando. Contáctanos a través de la página de carreras o escribe a Trung directamente.

Qué se entrega a continuación

El mismo flujo de trabajo que construyó el producto actual está entregando el roadmap:

• Gestión de múltiples eSIM (mayo de 2026)
• Planes familiares (junio de 2026)
• Fidelidad y recompensas (agosto de 2026)
• Cobertura directa con operadores en todo el mundo (2027)

Cada uno de estos es un proyecto de varios meses en una telco tradicional. Nuestras estimaciones internas tienen los cuatro entregándose en horario, con el mismo equipo de cinco personas.

Ese es el apalancamiento. Esa es la apuesta. Así es como un equipo pequeño entrega contra la inercia de toda una industria.

Mira eSimphony en acción, lee sobre nuestro posicionamiento, o revisa nuestro pitch deck de MVNO Nation Americas.