Latam El nuevo software necesita ingenieros de producto, no solo programadores
La IA acelera la generación de código, pero el verdadero cuello de botella ahora es la comprensión del sistema. Kent Beck y estudios recientes revelan que las habilidades interpersonales y la gestión de la intención marcan la diferencia.
El verano pasado, en un curso de emprendimiento que la profesora Margaret-Anne Storey dictaba en la Universidad de Victoria, Canadá, un equipo de estudiantes llegó a la octava semana con el proyecto paralizado. El código funcionaba, los tests pasaban, pero los cambios simples rompían cosas imprevistas. La explicación inmediata fue la clásica: deuda técnica, código apresurado, mala arquitectura. Pero al revisar más a fondo, Storey descubrió algo distinto: nadie en el equipo podía explicar por qué se habían tomado ciertas decisiones de diseño ni cómo debían encajar las piezas. El entendimiento compartido del sistema se había fragmentado.
La anécdota, que Storey relata en un artículo reciente publicado en arXiv, ilustra un fenómeno que está redefiniendo el núcleo del desarrollo de software en la era de la inteligencia artificial. Mientras la IA generativa permite a equipos pequeños producir código a una velocidad que era impensable hace pocos años –como reportan Peng y sus colegas en un estudio de 2023–, la capacidad humana para entender ese código no ha seguido el mismo ritmo. Para Storey, el riesgo principal ya no es solo la deuda técnica –el código mal escrito– sino dos categorías nuevas: la deuda cognitiva (la erosión del entendimiento compartido del equipo sobre el sistema) y la deuda de intención (la falta de registro explícito de los objetivos, restricciones y razones detrás de cada decisión).
El diagnóstico de Storey resuena con las advertencias que viene haciendo Kent Beck, uno de los creadores del manifiesto ágil y figura central en la ingeniería de software moderna. En una entrevista reciente en el podcast The Pragmatic Engineer, Beck señaló que asistentes como Claude Code y Codex de OpenAI ya escriben y corrigen código con una eficiencia que supera la de muchos desarrolladores junior. Pero Beck dio un paso más allá: advirtió que los programadores que solo saben programar están en riesgo, y que el futuro pertenece a lo que él llama «ingenieros de producto», un perfil que combina competencias técnicas con habilidades interpersonales como la comunicación y la empatía. «Ya no es suficiente saber escribir código; necesitas entender a las personas, gestionar expectativas y coordinar equipos», dijo Beck.
La propuesta de los tres tipos de deuda que formula Storey ayuda a entender por qué Beck tiene razón. La deuda técnica –código desordenado, malas prácticas de arquitectura– es la más visible y la que más herramientas de mitigación tiene: refactorización automatizada, pruebas generadas por IA, revisiones de código. Pero la deuda cognitiva es invisible. Un equipo puede tener un código limpio y, sin embargo, no entender cómo funciona ni por qué está hecho así. Cuando un desarrollador escribe código desde cero, aunque sea desordenado, construye un modelo mental del sistema. Cuando la IA genera ese mismo código, el desarrollador lo acepta sin el mismo nivel de comprensión. A escala de equipo y a lo largo del tiempo, esa falta de entendimiento se acumula.
Investigadores como Shaw y Nave han descrito este mecanismo como «surrender cognitivo»: la adopción de resultados de IA con un escrutinio mínimo, que evita tanto la intuición como el razonamiento deliberado. No es lo mismo que la «descarga cognitiva» estratégica –delegar una tarea específica a una herramienta, como usar un linter–. El surrender cognitivo puede ser intencional, pero erosiona la capacidad del equipo para razonar sobre el sistema. Y, peor aún, infla la confianza: el equipo cree que entiende el sistema mejor de lo que realmente lo entiende, hasta que algo falla.
Para las empresas latinoamericanas, esta discusión tiene implicaciones concretas. En la región, donde los equipos de desarrollo suelen ser más pequeños y los recursos para capacitación más ajustados, la velocidad que promete la IA puede tentar a los CTOs a priorizar la entrega de funcionalidades por sobre la comprensión del sistema. Pero si el equipo no entiende lo que la IA produjo, cualquier cambio futuro se vuelve una apuesta. Storey sugiere prácticas específicas para mitigar la deuda cognitiva: revisiones de código humanas (no solo automatizadas), sesiones de walkthrough donde los desarrolladores expliquen código que no escribieron ellos, retrospectivas cuando algo se rompe, y algo que llama «reimplementación» –pedirle a un agente de IA que reescriba una funcionalidad desde cero usando nuevos tests, como una forma de reconstruir el entendimiento.
Beck, por su parte, insiste en que la diferenciación profesional ya no está en la habilidad técnica pura. «He visto programadores brillantes que no pueden trabajar en equipo porque no saben comunicar lo que hacen», dijo. «En un mundo donde la IA escribe el código, el valor humano está en saber qué código escribir, y eso requiere entender el contexto del negocio y a las personas que lo usan». Para un CTO en América Latina, donde el mercado laboral de tecnología es cada vez más competitivo, invertir en la formación de «ingenieros de producto» –perfiles que combinan código, comunicación y visión de negocio– puede ser la jugada más rentable.
El verdadero cuello de botella del desarrollo de software ya no es escribir código. Es entenderlo.
