En 2026 ya nadie escribe código: programar empieza antes
En 2026 ya nadie escribe código.
La frase es exagerada, pero describe una escena cada vez más reconocible en las organizaciones. Un desarrollador puede comenzar una tarea explicando qué necesita, entregar contexto a una IA, recibir una primera solución y trabajar sobre algo que no escribió desde cero. Entonces, ¿cuál es el problema?
Esta no tan nueva forma de trabajar puede parecer una ganancia clara de productividad. Sin embargo, esconde un desplazamiento sutil del cuello de botella que anteriormente era producir código. Ahora (y probablemente en el futuro) la tensión está en lo que pasa antes y después. Está en entender el problema, establecer restricciones y comprobar que lo generado funciona dentro del sistema y del negocio.
Para una organización el riesgo no es que los programadores dejen de escribir código. Es confundir más código producido con más capacidad creada.
Programar empieza siempre antes del código
En abril de este año Microsoft Research publicó un informe con una estimación útil para dimensionar este cambio generacional: hoy sus desarrolladores dedican aproximadamente una décima parte de la jornada a escribir código a partir de su vínculo con la IA. El resto del tiempo está distribuido en comprender requisitos, navegar sistemas existentes, discutir decisiones, diseñar, probar, revisar y documentar. Son actividades menos visibles que escribir una línea de código, pero decisivas para que esa línea tenga sentido dentro de un sistema real.
Porque la realidad es que automatizar sintaxis no equivale a automatizar programación.
Antes de que exista código alguien debe definir qué problema merece ser resuelto, con qué información, bajo qué restricciones y dentro de qué arquitectura. Esas decisiones dependen de algo que un modelo no recibe automáticamente: el contexto.
La dificultad, entonces, ya no empieza necesariamente frente al editor. Empieza cuando la organización intenta explicar con suficiente precisión qué necesita construir y qué condiciones debe respetar la solución entregada.
Cuando generar se vuelve barato, verificar gana valor
La adopción de la IA muestra que el cambio ya está en marcha, aunque todavía está lejos del relato de una programación completamente autónoma, algo que trabajamos en este artículo. En la encuesta de desarrollo de Stack Overflow, el 51 % de los desarrolladores profesionales declaró utilizar herramientas de IA diariamente. De ese universo, el 72 % aseguró que el vibe coding –la construcción intuitiva usando palabras– no formaba parte de su trabajo.
Es cierto. La IA puede acelerar la tarea, pero esa velocidad no elimina la carga sino que la desplaza hacia otro lugar, algo que es referido como el impuesto de verificación o verification tax, donde parte del tiempo ahorrado durante la generación reaparece cuando el desarrollador necesita auditar, probar, corregir y comprender lo producido, algo que también abordamos en este artículo.
Una investigación publicada en julio por DORA, el equipo de investigación de Google Cloud sobre desarrollo y entrega de software, evidencia ese desplazamiento en una organización concreta. El estudio siguió a 802 desarrolladores y 196.212 pull requests. Descubrieron que mientras aumentaba la cantidad de cambios integrados por desarrollador, la carga por revisor prácticamente se duplicaba. Si bien es un solo caso empresarial y no permite generalizar el efecto a toda la industria, vuelve visible el problema.
Cuando producir una primera respuesta cuesta menos, distinguir una solución que parece correcta de una que realmente tiene impacto positivo gana valor.
Para una organización, esto crea una paradoja. El equipo puede generar más rápido sin aumentar al mismo ritmo su capacidad para revisar. El cuello de botella no desaparece. Cambia de lugar.
El contexto empieza a valer más que la sintaxis
Durante mucho tiempo aprender programación significó, entre otras cosas, dominar lenguajes, frameworks, estructuras y patrones. Todo eso sigue importando, aunque hoy la inteligencia artificial reduce la distancia entre una intención y una implementación técnicamente posible. Y eso que una intención incompleta también puede transformarse rápidamente en software.
Un modelo puede generar una API sin conocer excepciones del negocio, modificar una consulta sin saber que un campo aparentemente obsoleto conserva una regla histórica o proponer una arquitectura sin entender una dependencia crítica. En esos casos, el problema no está necesariamente en la calidad del código. Está en la distancia entre lo que se pidió y lo que la organización realmente necesitaba.
El código puede ser técnicamente correcto y, aun así, la solución estar equivocada.
Cuanto más sencillo sea transformar instrucciones en software, más importante será formular instrucciones que representen correctamente la realidad que ese software debe operar.
Ahí aparece una capacidad menos visible: conocer las reglas, excepciones y relaciones que permiten decidir qué conviene construir.
La IA puede reducir el costo de escribir, pero no reduce automáticamente el costo de comprender.
Fuente: Why Coding Skills Won’t Get You To Staff Engineer
De producir código a producir capacidad
El cambio más importante puede no ocurrir dentro del editor, sino en la manera en que una organización evalúa la capacidad de sus equipos técnicos.
Si el indicador sigue siendo cuánto código producen o cuántas funcionalidades entregan, la IA aparece principalmente como una herramienta para acelerar. El riesgo es descubrir después que una mayor producción exige también más revisión, más conocimiento del sistema y mejores criterios para decidir qué merece llegar a producción.
Para una dirección, ya no alcanza con saber cuánto más puede generar un equipo con IA. Importa cuánto de ese aumento puede comprender, validar, mantener y convertir en una mejora para el negocio. La diferencia entre adopción y capacidad empieza a jugarse ahí.
En Alpha Discovery vemos una lógica similar cuando trabajamos con información histórica. Generar una respuesta es apenas una parte del problema. Su valor depende de los datos que la sostienen, del contexto que permite interpretarla y de la capacidad de validarla antes de convertirla en una decisión.
Con el código empieza a ocurrir algo parecido en las organizaciones. La ventaja no está solamente en producir más rápido, sino en evitar que la capacidad de generar crezca más rápido que la capacidad de entender.
Quizás en lo que queda de 2026 sigamos escribiendo mucho código. Lo seguro a futuro es que cada vez será menos útil medir el aporte de un equipo solamente por cuánto logra producir.
¿Tu organización está incorporando IA para desarrollar más rápido?
Antes de medir solamente velocidad, conviene evaluar si también está fortaleciendo el contexto, la validación y la capacidad para decidir qué vale la pena construir.
