Contrata al revisor antes que al programador: cómo formar el equipo de ingeniería de una startup cuando los agentes escriben el código (2026)

Surya Pratap
By Surya Pratap

31 de julio de 2026

11 min read

Startup Strategy
Diagrama de embudo que muestra un gran volumen de código de agentes que se estrecha en un punto de revisión solo para séniores, con el flujo mediano hasta main en descenso

Hay una discusión en LinkedIn que no se va a resolver, y otra más discreta en Reddit que ya se ha resuelto. La de LinkedIn trata de si la IA acabó con los empleos de ingeniería de nivel inicial: por un lado, el CEO de AWS, Matt Garman, que calificó la idea de sustituir a los juniors por IA como «una de las cosas más tontas que he oído nunca», y por otro, un muro de datos de contratación que muestra una fuerte caída de las ofertas de nivel inicial. La de Reddit, en hilos como los de r/ExperiencedDevs, es menos filosófica: séniores que describen jornadas convertidas en una cola ininterrumpida de pull requests por revisar, y un memorando de Indeed según el cual ya no se espera que los ingenieros sénior mentoricen a nadie por debajo de su nivel.

Para un fundador a punto de hacer sus tres primeras contrataciones de ingeniería, las dos discusiones tienen la forma equivocada. La pregunta útil no es si la IA está destruyendo los empleos junior en conjunto. Es esta: dado que los agentes escriben ya una gran parte de tu código, ¿qué está limitando de verdad la velocidad a la que sale tu producto, y a quién necesitas contratar para desbloquearlo? Los datos al respecto son inusualmente claros, y apuntan a un lugar que la mayoría de los fundadores no espera.

La cifra que lo replantea todo

Los datos de CircleCI de 2026 contienen un resultado que debería estar clavado sobre la mesa de todo fundador: el flujo en las ramas de funcionalidades subió un 59 % interanual, mientras que el flujo en la rama main del equipo mediano cayó. Se escribe más código que nunca. Proporcionalmente, llega menos a producción.

Las cifras por desarrollador explican el mecanismo. Los ingenieros que usaban IA completaron un 21 % más de tareas e integraron un 98 % más de pull requests —aproximadamente el doble de output—, pero el tiempo de revisión de las PR aumentó un 91 %. Las PR generadas con IA esperan 4,6 veces más antes de que un revisor siquiera las coja. Una vez que empieza la revisión, termina aproximadamente el doble de rápido, lo que suena alentador hasta que te fijas en lo que implica: revisar no es la parte lenta. La cola sí. El tiempo de ciclo apenas mejora porque el trabajo se queda esperando a una persona con suficiente contexto y autoridad para decir que sí.

A esto se refiere la gente cuando dice que el cuello de botella se desplazó. Escribir código fue la restricción durante toda la historia del software. Ya no lo es. Lo es decidir si el código es seguro para integrarlo, y esa decisión no se puede repartir por igual en un equipo. Sí se puede enseñar, eso sí: evaluar la salida de la IA, y saber qué modos de fallo buscar, es la mayor parte de lo que cubre nuestra formación para equipos de ingeniería.

Por qué golpea más fuerte a las startups

Una gran empresa absorbe una acumulación de revisiones dentro de sus capas existentes. Una startup de cuatro personas tiene exactamente una o dos que pueden aprobar con criterio un cambio en el sistema central. Si les compras más capacidad de agentes, no has aumentado la velocidad de lanzamiento: has alargado su cola.

El criterio no se paraleliza

La razón de que este cuello de botella sea tan persistente es que revisar bien lo que producen los agentes exige justo lo que los agentes no aportan: saber qué debería haberse construido. Un ingeniero sénior que revisa una PR de 400 líneas con buen aspecto no está comprobando la sintaxis. Se pregunta si esta es la abstracción correcta, si duplica algo que ya existe, si se comportará bien con carga, si la ruta de error es real y si rompe en silencio un supuesto a tres servicios de distancia. Eso es contexto, y el contexto se acumula; no se contrata al instante.

Por eso la queja de Reddit es más informativa que el debate de LinkedIn. Los séniores cuentan que ahora pasan más tiempo revisando que diseñando: que el trabajo que antes fluía por varias capas de la organización se concentra en las pocas personas cualificadas para juzgarlo. Eso no es una queja sobre la carga de trabajo. Es la descripción de un sistema cuyo rendimiento está limitado por su recurso más escaso, y en el que cada mejora de eficiencia aguas arriba hace que ese límite apriete más.

¿Entonces solo séniores? Eso se rompe por dos sitios

La conclusión obvia —formar el equipo solo con séniores y dejar que los agentes hagan lo que antes hacían los juniors— es la que alcanzaron muchos fundadores en 2025, y falla de dos maneras concretas.

La primera es aritmética. Los ingenieros sénior son la capacidad de revisión. Si todo el equipo genera output con agentes a doble volumen y las mismas personas son las únicas que pueden aprobarlo, has construido un sistema en el que cada nueva contratación suma a los dos lados de la ecuación. A partir de cierto punto, añadir otro sénior productor a un equipo pequeño empeora la cola en lugar de mejorarla. Por eso la indicación más útil que circula ahora mismo entre líderes de ingeniería es engañosamente sencilla: contrata al revisor antes que al programador. Tu siguiente contratación debería elegirse por si puede absorber carga de revisión, no por si puede producir más trabajo que necesite revisarse.

El segundo fallo es al que apuntaba de verdad Garman, y merece citarse bien porque la frase corta lo pierde. Los juniors, señaló, son «probablemente los empleados más baratos que tienes, los que más se han volcado en tus herramientas de IA», y luego el argumento de fondo: «¿Cómo va a funcionar eso cuando dentro de diez años no tengas a nadie que haya aprendido nada?». Los séniores no son un recurso renovable que se compra cuando hace falta. Son juniors a los que se les dieron problemas difíciles y alguien que revisara su trabajo. Una empresa que congela la contratación de nivel inicial está aplazando un coste, no evitándolo, y el mercado en el que comprará talento intermedio dentro de unos años será uno que todos los demás también dejaron sin alimentar.

Una nota honesta sobre los datos del desplome junior

La prueba más sólida del argumento de LinkedIn es un estudio de Harvard de los economistas Seyed Hosseini y Guy Lichtinger que abarca unas 285.000 empresas estadounidenses y más de 60 millones de trabajadores entre 2015 y 2025. Concluyó que, después de que las empresas adoptan la IA generativa, el empleo junior cae alrededor de un 9–10 % en seis trimestres mientras que el empleo sénior se mantiene prácticamente estable. Lo llaman cambio tecnológico sesgado por la antigüedad, y el mecanismo es intuitivo: la IA generativa se da bien en el trabajo rutinario y bien especificado en torno al cual se construyeron los puestos de nivel inicial.

Pero el contraargumento honesto merece su espacio, porque los fundadores que hacen planes de contratación no deberían atribuir de más. El desplome del nivel inicial empezó en 2022, meses después de que la Reserva Federal subiera los tipos de casi cero al 5,25 %, y mucho antes de que la IA estuviera de forma significativa en la mayoría de los flujos de trabajo. Las correcciones por sobrecontratación tras la pandemia y los simples recortes de costes explican gran parte de lo ocurrido; la IA solo añadió presión real a partir de finales de 2024. «Los sustituimos por IA» es, para unas cuantas empresas, una historia más favorecedora que «contratamos de más y subieron los tipos».

Las dos cosas son ciertas, y la combinación es lo que te importa: el desplome macro no fue sobre todo por la IA, y el efecto sesgado por la antigüedad que se suma encima es real y medible. En la práctica, eso significa que el talento junior en 2026 está a la vez más disponible y más infravalorado que en ningún momento de la última década, mientras que la habilidad concreta que más necesitas es la que se ha vuelto más escasa. Es una oportunidad de contratación, no un motivo para congelar.

Cómo son de verdad los equipos que lanzan

El panorama empírico de los equipos que lanzan rápido en 2026 es más pequeño de lo que esperan los fundadores. La dirección de ingeniería de OpenAI ha señalado a grupos de tres o cuatro personas con una colaboración fuerte como la unidad que avanza más rápido; Sora se lanzó en 28 días con cuatro personas. Los equipos pequeños ganan aquí en parte por la restricción de la revisión: menos traspasos, más contexto compartido y un revisor que ya entiende el cambio antes de abrirlo.

La indicación sobre la composición que se deriva es coherente: el equipo nativo de IA tiene más peso sénior, pero no congela la contratación de nivel inicial. Y las pruebas sobre calidad apuntan en la misma dirección: McKinsey comprobó que las organizaciones con mejores resultados combinaron la IA con ingenieros sénior para lograr mejoras del 31–45 % en la calidad del software, en lugar de usar la IA como sustituto de la experiencia. La palanca vino de juntar la herramienta con el criterio, no de sustituir el criterio por la herramienta.

El orden de contratación del fundador

  • Mide tu cola antes que tu plantilla. Mira cuánto espera una PR antes de que alguien la coja frente a cuánto dura la revisión una vez empezada. Si domina la espera, tu problema es la capacidad de revisión, y ningún aumento del rendimiento de los agentes lo arreglará.
  • Que tu primera contratación sea un revisor. Alguien lo bastante sénior como para responder del criterio de arquitectura y dispuesto a dedicar la mayor parte de su semana al trabajo de otros. Fíltralo de forma explícita: muchos buenos constructores no quieren este trabajo, y contratar a uno que no lo quiere es como el cuello de botella se queda.
  • Después contrata juniors a propósito, no a la defensiva. Uno o dos, con problemas reales y un revisor con nombre. Son baratos, son los que mejor dominan las herramientas de agentes y son la única forma de que llegues a tener un segundo revisor.
  • Limita el trabajo en curso, no el esfuerzo. Limita cuántas PR generadas por agentes pueden estar abiertas a la vez. Una generación ilimitada que entra en un conducto de revisión limitado produce acumulación y ramas obsoletas, no velocidad.
  • Gasta tu presupuesto de automatización en revisión, no en generación. Ya tienes más generación de la que puedes absorber. Los tests, el análisis estático y las pasadas de agentes antes de la revisión que reducen lo que una persona tiene que verificar en persona son donde rinde la hora marginal.
  • Protege la mentoría de forma explícita. El memorando de Indeed es el antipatrón. Si revisar a los juniors no forma parte de la descripción del puesto ni de la evaluación de alguien, la cola de revisión se lo comerá lo primero.

El hilo conductor es que la IA cambió qué recurso escasea, y la mayoría de los planes de contratación no se han puesto al día. Durante treinta años, la respuesta a «tenemos que lanzar más rápido» fue más gente que escriba código. Esa respuesta es ahora errónea de una forma concreta y medible: puedes duplicar el código y ver cómo llega menos a producción.

Los fundadores que acierten en la segunda mitad de 2026 parecerán algo pasados de moda: equipos pequeños, con peso sénior, que siguen contratando juniors mientras todo el mundo en LinkedIn explica por qué nadie los necesita. También serán aquellos cuya rama main sigue avanzando. Contrata para la restricción que tienes de verdad, no para la que tenías en 2021.

IdeaToMVP Academy

Want to build with AI — not just read about it?

4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.

Explore the Academy →
Share this post :