Claude Code convirtió a cada ingeniero en tres. Ahora las empresas necesitan más pensadores de productos.

Anthropic recientemente le dijo a su equipo de crecimiento que contratara más gerentes de producto, no menos. La razón, según se informó en la cobertura de la industria, fue que Claude Code había convertido silenciosamente su organización de ingeniería en un equipo que produce aproximadamente tres veces más de lo que su número de empleados real permitiría, y el cuello de botella se movió del entorno de desarrollo integrado (IDE) a las personas que deciden qué construir. Ese detalle es fácil de pasar por alto en el ruido de cada afirmación de productividad de IA. También es el cambio estructural por el que ahora está pasando el resto de la industria. El cuello de botella en el software ya no es la escritura. Es decidir qué escribir. Y los ingenieros que tratan eso como un problema de alguien más están a punto de estancarse. Durante la mayor parte de la última década, esa decisión estaba en manos de otra persona. La ingeniería de software era un oficio que absorbías lentamente y luego practicabas en una larga secuencia predecible: Profundiza en la tecnología, escribe el código, pregunta en Stack Overflow cuando te quedes atascado, escala a un ingeniero senior cuando Stack Overflow no pudo ayudar, y entrega el ticket. El gerente de producto poseía el embudo. El ingeniero poseía la construcción. Ambas partes trataban esta división como física. Luego, el embudo colapsó en cinco pasos. Una breve historia de cómo se comprimió el día del ingeniero. La era de Stack Overflow (2014 hasta finales de 2022): La forma en que pensaban los ingenieros vivía en un solo lugar. Pero las nuevas preguntas mensuales en Stack Overflow han disminuido aproximadamente un 77% desde noviembre de 2022, que no fue casualmente cuando se lanzó ChatGPT. La caída no es un referéndum sobre el sitio. Es un referéndum sobre el flujo de trabajo que representaba. La era de las pestañas del navegador (finales de 2022 a 2024): La primera generación de ChatGPT se encontraba fuera del IDE. Los ingenieros siguieron ejecutando el mismo ciclo que siempre habían corrido, solo que con un oráculo más rápido: Escribir un aviso en un navegador, pegar la respuesta de nuevo en VS Code, repetir. El trabajo seguía siendo de un solo hilo y dirigido por el ingeniero. El apalancamiento era real pero local. La era nativa del IDE (2024 a 2025): Cursor y Claude Code trasladaron el modelo dentro del editor y le dieron acceso al repositorio completo. La ruta de escalamiento al ingeniero senior se disolvió en gran medida. Durante años, la sabiduría predominante entre los ingenieros veteranos era que Bash tenía la mayor vida útil de cualquier herramienta en la pila. Para 2026, para una parte significativa de los desarrolladores en activo, el primer comando escrito en un terminal nuevo es claude. La era impulsada por especificaciones (2025 a 2026): Ventanas de contexto más amplias convirtieron el trabajo de sesión única en algo que anteriormente requeriría tickets, documentos de diseño y sprints. Se informa que el equipo de IDE Kiro de Amazon comprimió la construcción de características de dos semanas a dos días utilizando el mismo flujo de trabajo basado en especificaciones que estaban enviando. Un equipo de ingeniería de AWS describió que una re-arquitectura de 18 meses, originalmente planificada para 30 ingenieros, fue completada por 6 personas en 76 días. El cuello de botella dejó de ser cuánto tiempo lleva escribir el código. Empezó a ser cuán claramente el equipo puede describir cómo se ve lo correcto. La era de las rutinas (2026): En abril, Anthropic lanzó Claude Code Routines: Agentes programados y persistentes que funcionan en un ciclo, en un webhook, o durante la noche mientras la laptop está cerrada. Cron volvió. Los hooks volvieron. El trabajo del ingeniero ahora es parte orquestación: Crear un enjambre antes de acostarse, revisar una pila de solicitudes de extracción por la mañana. Envolturas de terceros como OpenClaw, que fue brevemente suspendido por Anthropic en abril antes de una reinstalación parcial, hicieron el mismo punto desde el lado de código abierto. El cuello de botella se movió; la mayoría de los equipos no. La ingeniería ha aumentado aproximadamente tres veces. La gestión de productos no se ha movido. La relación tradicional de 1:8 entre PMs y ingenieros, ya estresada, ahora se desarrolla más cerca de un efectivo 1:20 porque cada ingeniero envía más por día. Por ejemplo, LinkedIn reemplazó su trayectoria de gerente de producto asociado con un programa de "Constructor de Productos" que capacita a generalistas en producto, diseño e ingeniería. Anthropic está contratando más PMs, no menos. El patrón es consistente en las empresas que realmente han implementado flujos de trabajo agentes en producción: El sistema está produciendo características construidas más rápido de lo que está produciendo decisiones sobre qué debería ser construido. Para los ingenieros, esta es la señal de carrera más importante de la década y la más fácil de perder mientras las historias de productividad dominan el feed. Los principios básicos importan más, no menos. El instinto de declarar obsoletos los fundamentos en la era de los agentes interpreta la tendencia exactamente al revés. Cuando una fuga de memoria derriba la producción a las 3 de la mañana, y el motivo resulta ser un sutil error de propiedad acumulado hace 4 años, ningún agente actualmente en funcionamiento puede cerrar ese bucle de extremo a extremo. Los sistemas operativos, las redes, la concurrencia y los planes de consulta todavía deciden quién puede resolver un verdadero incidente. También deciden quién puede detectar los momentos en los que la salida de un agente parece correcta en la superficie y es silenciosamente, y costosamente, incorrecta debajo. El agente que escribió el 70% del código en un repositorio moderno no puede decir con fiabilidad a nadie dónde sus suposiciones sobre la seguridad de hilos, la propiedad de la memoria o el aislamiento de transacciones divergen de la ejecución en tiempo real. El ingeniero que puede leer la diferencia y captar eso es el ingeniero que el resto del equipo necesita en la sala, y ese ingeniero se basa en fundamentos, no en habilidades de aviso. La correlación es que los fundamentos son ahora una habilidad de apalancamiento, no una habilidad de higiene. En 2014, saber cómo funcionaba un reenvío TCP cerraba un ticket de depuración más rápido. En 2026, el mismo conocimiento evita que un todo un pipeline de lanzamiento impulsado por agentes envíe una regresión a gran escala. El radio de impacto del ingeniero que sabe qué está sucediendo debajo ha aumentado, no disminuido. La revisión es la nueva escritura. Los ingenieros en 2026 generan código a un ritmo que supera lo que cualquiera de ellos puede leer cuidadosamente. El equipo que envía rápido y sobrevive es el equipo cuyos ingenieros tratan la revisión del código generado por IA con al menos el mismo rigor que una vez reservaron para escribirlo. La encuesta de desarrolladores de Stack Overflow de 2025 mostró que el 84% de los desarrolladores usan herramientas de IA, y el 46% dice que no confía en la salida, aumentando drásticamente del 31% el año anterior. Esa brecha, el uso intensivo emparejado con una baja confianza, es exactamente donde las habilidades de revisión son ahora más importantes. Los programadores que empujan mucho y revisan poco están acumulando una deuda que se hará evidente durante el primer incidente real, y el ingeniero que puede pagarla es el que combinó su volumen con un profundo conocimiento de los principios básicos de los sistemas involucrados. El nuevo diferenciador es el embudo de producto. Ambos son necesarios. Ninguno es suficiente. El ingeniero que importa en 2026 es el que ha dejado de esperar que el embudo llegue en forma de un ticket de Jira. Eso significa hacer cosas que el rol históricamente se permitió omitir. Hablar con los clientes. Observar cómo realmente usan el producto. Leer la cola de soporte. Participar en la llamada de ventas. La señal que un equipo de producto recibe a través de tres capas de resumen, un ingeniero ahora puede obtenerla de primera mano en una tarde. Generar ideas, no solo estimaciones. El gerente de producto que solía obtener ideas para 8 ingenieros no puede obtener ideas para 20 con la misma fidelidad. El ingeniero que aparece con una oportunidad validada y delimitada ya no está haciendo el trabajo del PM. El ingeniero está haciendo el trabajo que requiere la nueva proporción. Trabajar hacia atrás desde el cliente. Amazon ha estado escribiendo el comunicado de prensa primero durante dos décadas. La disciplina se traslada bien a equipos de uno y a enjambres de agentes. Ambos producen una gran cantidad de software funcional en la dirección equivocada, sin una clara declaración de lo que significa "ganancias del cliente" antes de que se escriba cualquier código. Deja de esconderte detrás de la capacidad. La respuesta honesta a "¿Tienes capacidad para esta idea?" solía ser 'No'. Con rutinas, hooks y una pila de agentes cooperativos, la respuesta honesta está más cerca de "¿Cuánto vale la idea?" Esa es una conversación diferente, y una mucho más difícil de tener sin un verdadero punto de vista sobre el cliente. Lo que la próxima década recompensa. La historia en cinco fases arriba no es realmente una historia de herramientas. Es una historia de qué parte del trabajo tuvo que hacer un humano. La parte que sigue siendo humana, y que permanecerá humana en un futuro previsible, se ha movido hacia arriba en el embudo: De escribir, a revisar, a decidir, a elegir al cliente a servir y el problema a resolver. La versión 2026 de un gran ingeniero no es la que escribe más código. Es la que sabe qué construir, puede demostrar que vale la pena construirlo, y tiene la flota de agentes más la disciplina de revisión para enviarlo sin que el sistema colapse bajo su propia velocidad. Los ingenieros que internalizan esto pasarán la próxima década haciendo el trabajo más interesante que el software ha producido jamás. Los ingenieros que esperan un ticket lo pasarán viendo cómo se escribe el ticket por el agente a su lado. Ishan Gupta es ingeniero de software en Amazon.