Esta semana el creador de Claude Code dijo que “el código está resuelto” y, como era de esperarse, internet explotó. El comentario se interpretó rápido como “ya no se necesitan programadores”, y muchos estudiantes de software se quedaron preguntándose si vale la pena seguir con su carrera.
La generación de código con IA está casi resuelta para aplicaciones comunes, pero el desarrollo de software como disciplina sigue muy lejos de estarlo. Esa es la distinción central que conviene entender antes de entrar en pánico. Escribir código no es lo mismo que hacer software, y las partes que realmente importan de un proyecto serio siguen requiriendo criterio humano.
En este artículo voy a explicarte por qué ese comentario no debería preocuparte, qué diferencia hay entre generar código y desarrollar software, y cuáles son las cuatro áreas que vale la pena estudiar a fondo si quieres seguir siendo relevante en esta época.
De dónde salió el comentario y por qué no da para tanto
El mensaje “el código está resuelto” nació de un tweet irónico que se tomó demasiado en serio. Un usuario en Twitter comentó, con cierta sorna, que el código ya está resuelto pero aún no tenemos aplicaciones que se actualicen por sí mismas y seguimos teniendo el botón de “refresh” para reiniciar las aplicaciones.
Lo curioso del asunto es que Boris, del equipo de Claude Code, respondió que eso no era un bug, sino una interfaz que aún no habían reparado. Las notas de la comunidad no tardaron en señalar que eso es, literalmente, la definición de un bug. Y ahí estaba la gracia: el propio ecosistema demostrando que el código no está tan resuelto como se dice.
Este tipo de debates se repite en cada actualización de modelos. Cada vez que sale un modelo nuevo, alguien declara la muerte de la programación, y luego la realidad se encarga de matizar las cosas. La diferencia es que ahora el mensaje caló más hondo porque la generación de código es realmente impresionante.
La IA genera aplicaciones, no sistemas completos
Si el código estuviera realmente resuelto, ya tendríamos sistemas operativos y compiladores creados completamente desde cero por IA. Pero lo que vemos hoy es generación de aplicaciones a nivel de usuario: las más comunes, las que siempre se han hecho.
La prueba más sencilla es intentar algo que no sea una aplicación web típica. Si crees que el código está resuelto, intenta crear un compilador, un intérprete o cualquier sistema de bajo nivel. Ahí te vas a dar cuenta de que aún hay muchísimo trabajo por hacer debajo de la superficie.
Esto no significa que la IA no sea útil. De hecho, es una herramienta extraordinaria para generar aplicativos web, y si la combinas con conocimientos reales de ingeniería de software, es muy probable que consigas trabajo sin problema. Pero hay una diferencia enorme entre generar una aplicación de usuario y construir un sistema robusto que sostenga una empresa.
Escribir código no es lo mismo que desarrollar software
La confusión principal está en equiparar la escritura de código con el desarrollo de software, cuando son cosas muy distintas. Esto no es nuevo: mucho antes de la IA, cualquiera podía tomar unos cursos en internet durante unos meses y generar un aplicativo web. La diferencia entre esa persona y un ingeniero de software siempre ha existido.
Una persona que escribe código no necesariamente sabe cómo construir una aplicación grande. No sabe cómo estructurarla, cómo hacerla escalar, cómo mantenerla a lo largo del tiempo. La IA ha hecho que escribir código sea más fácil, pero no ha resuelto los problemas de diseño, arquitectura y mantenimiento que definen al desarrollo de software real.
Y ahí está el punto: la generación de código es solo una parte del desarrollo de software. Hay muchas otras partes que siguen pendientes y que son las que realmente importan. Estas son las cuatro áreas que vale la pena estudiar a fondo.
Planificación: el trabajo invisible que ahora importa más
La planificación dejó de ser un tema de documentación aburrida para convertirse en una forma productiva de avanzar rápido en proyectos grandes. Cuando la IA puede generar código a gran velocidad, el cuello de botella se mueve hacia arriba: necesitas saber exactamente qué pedirle.
La planificación consiste en dividir la lógica de un proyecto en tareas concretas, una por una, y luego darle esa planificación a la IA para que la ejecute. Es un trabajo que requiere saltar de proyecto en proyecto y que puede ser cansado, pero es esencial si quieres que la generación de código sea realmente productiva.
Esto no es solo documentación. Es la diferencia entre pedirle a la IA “haz una aplicación” y decirle “primero crea el módulo de autenticación con estas especificaciones, luego el módulo de pagos con estas reglas de negocio”. La segunda opción produce software mucho más confiable.
Orquestación de agentes: la nueva forma de delegar
La orquestación de agentes es la delegación de tareas llevada al mundo de la IA, y existen varias formas de hacerla. Antes, si querías avanzar más rápido en un proyecto, contratabas a varias personas y les asignabas roles: uno de frontend, otro de backend. Hoy haces lo mismo con agentes, y lo que antes era una planificación para personas, ahora es una planificación para agentes.
Hay tres niveles principales de orquestación:
A nivel de modelo. Tienes una API única que combina varios modelos. Por ejemplo, Open Router tiene un modelo llamado Fusion que une una enorme cantidad de modelos e internamente intercambia entre varias respuestas. Es una forma de enrutar de un modelo a otro según la necesidad.
A nivel de harness. Aquí tienes un modelo maestro y otros modelos trabajadores. En Open Code puedes tener un modelo como Claude como orquestador y usar otro modelo más económico como trabajador. Lo mismo aplica en Claude Code, donde puedes combinar un modelo como orquestador y otro como subagente.
A nivel de ADE (Agent Development Environment). Esta es la capa más alta. Proyectos como Orca, Herder, Simox o Tracer te permiten combinar varios agentes dentro de un mismo entorno. Ya no haces la orquestación solo en Open Code o solo en Claude Code, sino que estos pueden contener a ambos, y un controlador superior maneja todo.
Por ejemplo, podrías tener un agente maestro que decide qué tarea asignar, un agente especializado en frontend, otro en backend, y un tercero que revisa el código generado. Todos coordinados desde un solo entorno.
Testing: la calidad que la IA no puede garantizar sola
Si no estás haciendo testing, el software que generas con IA es software a ciegas: modificas algo, la IA lo despliega y confías en que todo funcione. El testing siempre ha sido parte del software, pero antes nadie quería hacerlo porque implicaba escribir código adicional y usar herramientas más pesadas.
Hoy el testing se ha vuelto más importante que nunca, porque la IA puede generar código a gran velocidad, pero no puede garantizar que ese código funcione correctamente en todos los escenarios. Hay varios tipos de testing que vale la pena conocer:
- Testing unitario: verifica que cada función o módulo funcione de forma aislada.
- Testing end to end: verifica que todo el flujo de la aplicación funcione de principio a fin.
- BDD (Behavior Driven Development): una técnica que define el comportamiento esperado antes de escribir el código.
- TDD (Test Driven Development): una técnica donde escribes los tests antes que el código.
Pero hay un concepto que está ganando mucha popularidad: el testing adversarial. Suena complicado, pero es bastante sencillo: le das a un agente la tarea de escribir código, y luego tienes dos agentes que tratan de hacer review de ese código. Es más gasto de tokens, más trabajo y demora más, pero obtienes un review mucho más riguroso que simplemente ejecutar un script.
Un ejemplo real de esto fue la reescritura de Bun. Hace algunos meses, Bun estaba escrito en Zig con aproximadamente un millón de líneas de código, y fue reescrito completamente en Rust. No fue una reescritura simple de “reescribe el código y hazlo sin fallos”, sino que hubo una estrategia detrás, basada precisamente en este tipo de testing adversarial.
El mismo creador de Clean Code, ese libro famoso que todo el mundo menciona, también utiliza este tipo de testing y dice que por eso ya no revisa código manualmente. Es una señal clara de que esta es una habilidad que vale la pena dominar.
Diseño de sistemas: donde realmente te van a pagar
El diseño de sistemas es la habilidad que más depende de la experiencia y la que menos puede reemplazar la IA. No es algo que aprendas con un curso y ya. Puedes tomar cursos de diseño de sistemas, pero al final se trata de saber combinar piezas para armar un sistema real que resuelva un problema.
Cada pieza es software: una base de datos, un sistema de colas, un proveedor de API de IA, un load balancer, un servicio para generar contenido. La diferencia está en saber cuál pieza elegir, cómo conectarlas y cuándo intercambiarlas. Y eso depende de cuánta experiencia tengas.
La IA puede generar un diseño de sistema, e incluso puede usar un CLI de AWS, Azure o Google Cloud para implementarlo. Pero no lo hace a ciegas, y a veces genera una elección mala o una solución no tan óptima. Ahí es donde entra el criterio humano: alguien tiene que aprobar el diseño y asumir la responsabilidad de que funcione.
Esto es especialmente importante en proyectos de verdad, de empresas que tienen datos reales y necesitan un entorno estable para usuarios reales. En esos casos, la IA puede ayudarte a implementar, pero no puede decidir por ti qué arquitectura es la correcta.
Lo que aún no está resuelto y por qué
Una forma de poner a prueba si el código está resuelto es generar software que no conoces. Por ejemplo, aunque llevo bastantes años desarrollando, no me animo a generar un compilador con IA. Sé que no va a terminar de generarse completamente. Se podría, pero me tomaría bastante trabajo terminarlo, y esa es una limitación clara de que aún no estamos en ese punto.
Hace tres o cuatro años, cuando alguien me preguntaba si Copilot podía reemplazar la escritura de código, yo decía que no. El autocompletado te ayudaba, pero tenías que escribir el código tú mismo. Una de las limitaciones era que no tenía el contexto de todo el proyecto ni una forma de navegar rápidamente entre archivos.
Hoy eso ya no es un problema. Tenemos modelos con un millón de tokens de contexto, herramientas que pueden navegar por todo tu proyecto, y proyectos como Grapify que analizan la base de código completa y te dan rutas cortas para llegar a cualquier parte. El testing se puede automatizar, cosa que hace tres o cuatro años no se podía.
Pero justo por eso digo que el código no está resuelto. Cuando veamos los primeros sistemas operativos creados completamente con IA, o compiladores generados desde cero, quizás podríamos hablar de ese nivel. Y aún 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.
Resumen: qué estudiar si quieres seguir siendo relevante
La generación de código puede estar casi resuelta a nivel de aplicaciones comunes, pero el desarrollo de software no, y ahí es donde debes enfocar tu energía. Estas son las cuatro áreas que vale la pena estudiar a fondo:
| Área | Por qué importa | Qué estudiar |
|---|---|---|
| Planificación | La IA genera rápido, pero necesita instrucciones claras | División de proyectos en tareas, gestión de proyectos |
| Orquestación de agentes | La delegación de tareas ahora se hace con agentes | Modelos, harness, entornos ADE |
| Testing | La calidad del código generado no se garantiza sola | Testing unitario, end to end, adversarial |
| Diseño de sistemas | Requiere criterio humano y experiencia | Arquitectura, bases de datos, servicios en la nube |
Hay otros temas que también importan, como cloud computing y seguridad, pero si hablamos de desarrollo de software como tal, estas son las partes que siguen importando. La seguridad es especialmente relevante porque los agentes pueden entrar en cualquier sistema y ejecutar comandos o scripts que vulneren tu infraestructura.
Si estás estudiando una carrera relacionada con software y ves estos mensajes todos los días, no te desanimes. La IA es una herramienta extraordinaria, pero alguien tiene que decidir qué construir, cómo construirlo y si funciona correctamente. Ese alguien sigue siendo un humano con criterio.
¿Crees que el código está resuelto, o ves estas cuatro áreas como yo las veo? Si quieres profundizar en alguna de ellas, o si necesitas ayuda para aplicar estas ideas en tu propio proyecto, escríbeme por WhatsApp o visita mi sitio. Me encantaría saber qué opinas.