El código está casi resuelto; el desarrollo de software no

Cada cierto tiempo vuelve la misma frase: "el código ya está resuelto". Esta semana volvió a circular, y con ella la pregunta de siempre: si una IA genera todo el código, ¿para qué se contrata a alguien que programa?

Quiero dar mi posición sobre esto, pero sobre todo quiero dejar algo más útil: una lista de temas que yo mismo estoy estudiando en estos días y que son, en mi opinión, la razón por la que este tipo de titulares no me preocupa demasiado. Si estás en la universidad o estudiando algo relacionado a software y todos los días ves mensajes que te dicen que tu carrera ya no tiene sentido, esta lista es para ti.

De dónde sale la frase

La idea de que "el código está resuelto" viene de Boris Cherny, creador de Claude Code, que ha dicho públicamente que programar está en buena parte resuelto para el tipo de trabajo que él hace. Es una postura defendible, aunque conviene recordar de dónde viene: su trabajo es justamente que uses su herramienta.

Lo curioso es cómo volvió a encenderse el tema. Un usuario en Twitter comentó, de forma irónica, que si el código estuviera resuelto ya no tendríamos aplicaciones que dependen de un botón de "reiniciar" para aplicar cambios. La respuesta fue que eso no era un bug, sino un asunto de interfaz que todavía no se repara. Ahí saltaron las notas de la comunidad, porque eso es precisamente la definición de un bug.

De un intercambio así salieron cientos de posts. Y honestamente no da para tanto: es un tema repetido que va a volver con cada actualización de modelos. Pero sirve como excusa para responder algo que sí importa.

Mi posición: casi resuelto, pero a nivel de aplicaciones comunes

No, no todo el código está resuelto.

Una IA hoy puede generar cualquier estructura, cualquier sintaxis, prácticamente cualquier programa que le pidas. Y sí, creo que puede generar cualquier aplicativo web de los que se hacen todos los días. Yo no soy alguien anti-IA: la uso para prácticamente todo. Justamente porque la uso a diario conozco sus límites.

El punto es qué estamos midiendo. Lo que la gran mayoría está generando son aplicaciones web, es decir, aplicaciones a nivel de usuario, las más comunes y las más probadas. Si el código realmente estuviera resuelto, ya tendríamos sistemas operativos completos creados desde cero, compiladores completos, alternativas serias a proyectos grandes de infraestructura. No los vemos.

Si crees que ya está resuelto, hazte la prueba: intenta generar un compilador, un intérprete o cualquier sistema de bajo nivel. Vas a encontrar que ahí abajo todavía hay muchísimo por hacer.

Yo lo resumiría así: el código está casi resuelto a nivel de aplicaciones comunes. Lo que no está resuelto es el desarrollo de software.

Escribir código no es desarrollar software

Mucha gente usa los dos términos como si fueran lo mismo, y no lo son.

Esta diferencia existe desde antes de la IA. Cualquiera podía ver unos cursos durante algunos meses y terminar generando un aplicativo web. Eso ya pasaba. Lo único que cambió es el tiempo: lo que antes tomaba meses ahora toma minutos. Pero la conclusión es la misma de siempre: alguien que escribe código no es automáticamente un ingeniero de software, ni tiene necesariamente el criterio técnico para sostener una aplicación grande.

Eso no es un juicio contra nadie. Es solo que la generación de código es una parte del desarrollo de software, y hay otras partes que siguen muy pendientes. Estas son las cuatro a las que yo les estoy prestando atención ahora.

1. Planificación

Suena a documentación, a algo que no importa. Sí importa, y cada vez más, porque hoy puedes atacar proyectos mucho más grandes de los que antes te atrevías.

Cuando hablo de planificación me refiero a software de administración de proyectos o de tareas: poder partir la lógica de lo que hay que construir en tareas concretas y después entregarle esa planificación a un agente para que la continúe. Yo paso bastante tiempo generando planificaciones, y es un trabajo cansado, porque terminas saltando de proyecto en proyecto.

Todavía no encuentro el software correcto para esto. Estoy desarrollando el mío, pensado desde el inicio para que varios agentes puedan reescribirlo. Cuando esté, lo comparto.

2. Orquestación de agentes

Es el tema del que todo el mundo habla, y en el fondo es delegación de tareas de siempre, solo que ahora a agentes. Antes, si querías avanzar más rápido en un proyecto, contratabas a varias personas, cada una con un rol, y armabas una planificación. Hoy haces lo mismo con agentes. Lo que antes era una planificación para personas ahora es una planificación para agentes.

Ahora, "orquestación" significa cosas distintas según a quién le preguntes. Hay al menos tres niveles:

• A nivel de modelo. Una sola API que por dentro enruta entre varios modelos y combina respuestas. Es orquestación en el sentido de que decides a qué modelo va cada consulta.
• A nivel de harness. En OpenCode puedes tener un modelo maestro y modelos trabajadores: uno más caro como orquestador y otros más rápidos y baratos como workers. En Claude Code es la misma idea, combinando un modelo como orquestador y otro como subagente.
• A nivel de ADE (Agent Development Environment). Herramientas como Orca, Conductor, cmux o Emdash, que no orquestan dentro de un solo harness, sino que contienen a varios. Puedes tener Claude Code y Codex corriendo en paralelo en worktrees aislados, con una capa por encima que los controla a todos.

No es un tema complicado; es más bien cuestión de probar herramientas. Pero mucha gente ni sabe que estas alternativas existen.

3. Testing

Si no estás haciendo testing, lo que estás generando con IA es software a ciegas: modificas algo, el agente lo despliega y confías en que funcione.

El testing siempre estuvo ahí. Lo que pasa es que antes casi nadie quería hacerlo, porque era escribir código adicional, mantener un orden y sumar herramientas pesadas. Ese costo ya no es el mismo. Y siguen valiendo las mismas piezas: tests unitarios, end to end, y técnicas como TDD o BDD.

Lo que se está volviendo clave es el review adversarial: le pides a un agente que escriba código y pones a otros dos agentes, en contextos separados, a intentar romperlo. Gasta más tokens, demora más, pero obtienes una revisión mucho más seria que solo ejecutar un script y ver que no explote.

Esto no es teoría. Es exactamente lo que hizo Bun para portar su runtime de Zig a Rust: unas 535.000 líneas migradas en once días, con un implementador seguido de al menos dos revisores adversariales por unidad y otro agente aplicando las correcciones. No fue "reescribe esto y hazlo sin fallos": hubo una estrategia detrás. El creador de Clean Code también ha mencionado que usa este tipo de testing, y es una de las razones por las que ya no revisa código manualmente.

Si tuviera que recomendarte una sola de estas cuatro áreas para revisar a fondo, sería esta. Es donde realmente puedes ver la calidad del código que tu IA está generando.

4. Diseño de sistemas

Esta es la que considero que todo desarrollador debería dominar, y hoy más que antes.

El diseño de sistemas no se aprende en un curso. Hay cursos, sí, pero no terminas uno y ya sabes diseñar. Depende de la experiencia, porque diseñar es tomar varias piezas y armar un sistema real que resuelva un problema: una base de datos, un sistema de colas, un proveedor de API de IA, un load balancer, un servicio de contenido. Con experiencia sabes que esta parte admite dos variantes intercambiables, o que aquella encaja mejor conectada de otra forma.

Aquí ya no depende tanto de lo que genere la IA, sino de tu diseño. Y sí, la IA también puede proponerte un diseño: puede usar el CLI de AWS, Azure o Google Cloud y armarlo. Pero no a ciegas. Yo despliego continuamente en esas nubes y con frecuencia el modelo elige mal una pieza, o deja la solución a medias, o entrega algo que funciona pero no es óptimo. Puede salir mágicamente bien, como también puede hacerte perder dinero.

Cuando hablamos de un proyecto real, con datos reales y usuarios reales, alguien tiene que tener criterio para elegir el diseño. Y sobre todo, alguien tiene que aprobarlo y asumir la responsabilidad. Ahí es donde está el trabajo.

Cómo ponerlo a prueba tú mismo

La forma de comprobar si el código está resuelto es generar software que no conoces.

Yo llevo bastantes años desarrollando y todavía no me animo a generar un compilador con IA, porque sé que no va a terminar de salir. Se podría, pero me tomaría muchísimo trabajo cerrarlo. Esa es, para mí, la señal de que aún no estamos en ese punto.

Vale la pena comparar con hace tres o cuatro años. Cuando me preguntaban si el autocompletado tipo Copilot iba a reemplazar la escritura de código, yo decía que no, porque tenías que escribir tú y la herramienta solo completaba. Y una forma de comprobarlo era el testing: te generaba tests insalvables, porque no tenía contexto de todo el proyecto ni forma de navegarlo rápido.

Hoy eso ya no es un problema. Hay modelos con un millón de tokens de contexto, herramientas que navegan todo tu repositorio y proyectos que lo indexan para darte rutas cortas dentro de una base de código enorme. El testing se puede automatizar. Por eso mi respuesta ya no es la misma de entonces, pero tampoco es un sí.

El día que veamos generación consistente de código de bajo nivel, o los primeros sistemas operativos hechos completamente con IA, quizás sí estemos hablando de otro nivel. Y aun así, la planificación, la ejecución, el diseño de sistemas y el testing van a seguir puliéndose y volviéndose más complejos.

Lo que dejé fuera

Hay dos áreas que no son mi rubro pero que corren en paralelo y también importan: cloud computing (cómo desplegar modelos, sobre todo) y seguridad, que hoy es especialmente relevante porque los agentes pueden entrar a cualquier sistema y ejecutar comandos o scripts que lo vulneren. Son temas importantes, solo que no están enfocados en el desarrollo de software en sí.

Resumiendo: la generación de código puede que esté casi resuelta a nivel de aplicaciones comunes. El desarrollo de software no. Y si estás empezando, ahí es donde te conviene poner el esfuerzo.

¿Tú crees que el código ya está resuelto? Me interesa leer tu postura.