Durante años aprender a programar significó, en gran medida, aprender a escribir código.

Sintaxis. Frameworks. APIs. Patrones. Librerías. Debugging.

La inteligencia artificial está rompiendo esa equivalencia.

Hoy un buen agente de código puede producir en minutos una cantidad de software que antes requería horas o días de trabajo manual. Puede crear una API, levantar un frontend, escribir tests, modificar decenas de archivos, ejecutar comandos y corregir errores sin que una persona escriba cada línea.

Eso ha reactivado una pregunta incómoda:

Si la IA ya puede escribir el código, ¿qué debería estudiar un desarrollador?

Un video reciente, “El código está resuelto… ¿y ahora qué estudias? (mi posición real)”, plantea una respuesta que vale la pena tomar en serio.

La idea central puede resumirse así:

La generación de código está cerca de convertirse en una commodity para muchas aplicaciones comunes. El desarrollo de software, en cambio, está lejos de estar resuelto.

Esa distinción cambia por completo dónde conviene invertir el tiempo de aprendizaje.

Escribir código no es lo mismo que desarrollar software

Durante mucho tiempo ambas actividades estuvieron tan unidas que parecían la misma cosa.

Para construir una aplicación había que escribir código manualmente. Por eso una gran parte del valor práctico de un desarrollador estaba directamente relacionada con su capacidad para transformar una idea en instrucciones que una computadora pudiera ejecutar.

La IA está desacoplando esas dos cosas.

Ahora podemos tener:

objetivo
→ especificación
→ agente
→ código
→ tests
→ ejecución

La persona ya no necesita participar en cada transformación microscópica.

Pero eso no significa que el problema completo haya desaparecido.

Todavía alguien tiene que decidir:

  • qué debe construirse;
  • cómo dividir el problema;
  • qué arquitectura utilizar;
  • qué restricciones deben respetarse;
  • cómo demostrar que el sistema funciona;
  • qué riesgos son aceptables;
  • cuándo una solución está realmente lista para producción.

La IA puede escribir una función.

Puede escribir miles.

Pero un sistema de producción no es simplemente una colección de funciones.

La prueba del compilador

El video propone una forma útil de poner a prueba la afirmación de que “el código está resuelto”.

No le pidas a la IA otra aplicación CRUD.

Pídele algo como:

un compilador
un intérprete
un sistema operativo
un runtime
un motor de base de datos
un sistema distribuido de bajo nivel

La diferencia aparece rápidamente.

Las aplicaciones web convencionales existen dentro de espacios extremadamente conocidos. Hay millones de ejemplos, patrones maduros, frameworks abundantes y enormes cantidades de código parecido en los datos con los que fueron entrenados los modelos.

Eso convierte buena parte de la implementación en un problema cada vez más automatizable.

Pero cuando aumentan la profundidad técnica, las restricciones, las invariantes y la necesidad de mantener coherencia durante miles de decisiones, la dificultad deja de ser simplemente generar sintaxis correcta.

El problema pasa a ser ingeniería.

Por eso quizá la frase más útil no sea “el código está resuelto”.

Sería algo más parecido a:

Una parte cada vez mayor de la escritura de código está siendo automatizada.

Y eso nos obliga a movernos hacia arriba en la pila de abstracción.

1. Planificación: convertir intención en trabajo ejecutable

La primera habilidad que gana importancia es sorprendentemente poco glamorosa: planificar.

Cuando escribir código era caro, muchas personas podían improvisar directamente en el editor.

El coste de implementación limitaba naturalmente el tamaño de cada iteración.

Con agentes ocurre lo contrario.

Un agente puede producir muchísimo muy rápido.

Eso hace que una mala dirección también pueda producir muchísimo trabajo incorrecto muy rápido.

La planificación pasa entonces de ser documentación burocrática a convertirse en una interfaz entre intención y ejecución.

Un flujo moderno puede verse así:

objetivo grande
→ restricciones
→ arquitectura inicial
→ milestones
→ issues
→ tareas pequeñas
→ criterios de aceptación
→ agentes ejecutan

Mientras más capaz sea el agente, más importante se vuelve darle una estructura de trabajo suficientemente precisa.

La capacidad valiosa deja de ser únicamente “sé implementar esto”.

También es:

sé transformar un problema ambiguo en una secuencia de decisiones y tareas que pueden ejecutarse y verificarse.

Esta habilidad conecta directamente con lo que hemos descrito anteriormente en Capital de Tokens como agentic engineering: el humano se desplaza desde escribir cada archivo hacia diseñar el sistema que produce el cambio.

2. Orquestación: programar equipos de agentes

La segunda área es la orquestación de agentes.

No es una idea completamente nueva.

Durante décadas las empresas han dividido el trabajo entre especialistas:

product manager
→ arquitecto
→ backend
→ frontend
→ reviewer
→ QA
→ operaciones

Los agentes permiten representar parte de esa estructura mediante software.

Por ejemplo:

Specifier
→ define requisitos

Developer
→ implementa

Reviewer
→ busca defectos

QA
→ valida comportamiento

La diferencia es importante.

Antes, aumentar el paralelismo de un proyecto normalmente exigía contratar y coordinar más personas.

Ahora parte de ese paralelismo puede provenir de agentes especializados.

Esto introduce una nueva disciplina: diseñar cómo colaboran los agentes.

Hay varias capas posibles.

Orquestación entre modelos

Un sistema puede elegir distintos modelos según la tarea.

Uno puede ser mejor planificando, otro generando código, otro revisando o ejecutando tareas rápidas y baratas.

Orquestación dentro de un harness

Herramientas como los agent harnesses modernos pueden ofrecer un agente principal, subagentes, herramientas, sesiones, permisos y distintos loops de ejecución.

En nuestro análisis de DeepSeek Harness vimos precisamente esta dirección: el modelo deja de ser todo el producto y pasa a formar parte de una infraestructura mayor que administra herramientas, contexto, estado y ejecución.

Orquestación por encima de varios agentes

También pueden existir sistemas de control que asignen tareas completas a diferentes agentes o harnesses y luego recojan sus resultados.

En ese punto el desarrollador ya no está solamente programando una aplicación.

Está programando una organización de software.

3. Testing: cuando generar es barato, verificar se vuelve caro

Si existe una habilidad que probablemente aumente de valor con la IA, es el testing.

Hay una razón económica sencilla.

Cuando generar código es caro, escribir más código es el cuello de botella.

Cuando generar código se vuelve barato, el cuello de botella cambia:

¿Cómo sabemos que todo ese código es correcto?

Un agente puede modificar veinte archivos en segundos.

Puede ejecutar el programa y afirmar que funciona.

Pero sin un mecanismo independiente de verificación seguimos dependiendo de confianza.

Eso es especialmente peligroso porque los modelos pueden producir soluciones plausibles incluso cuando están equivocadas.

Por eso prácticas conocidas desde hace años adquieren una nueva función estratégica:

  • unit tests;
  • integration tests;
  • end-to-end tests;
  • property-based testing;
  • TDD;
  • BDD;
  • validación de contratos;
  • pruebas de regresión.

Los tests dejan de ser únicamente una protección para el código escrito por humanos.

Se convierten en la frontera objetiva entre el agente y la realidad.

Podemos imaginar el loop así:

agente implementa
→ tests fallan
→ agente corrige
→ tests pasan
→ reviewer inspecciona
→ nuevas pruebas intentan romperlo
→ QA valida criterios de aceptación

Mientras más autónoma sea la implementación, más necesitamos mecanismos independientes que puedan decir no.

Review adversarial: agentes que intentan demostrar que otro agente está equivocado

El video también destaca una variante particularmente interesante: la revisión adversarial.

En lugar de confiar en un único agente:

agente A
→ escribe código

podemos construir algo así:

agente A
→ implementa

agente B
→ intenta encontrar defectos

agente C
→ cuestiona supuestos y casos límite

suite automática
→ valida comportamiento

Eso consume más tokens y más cómputo.

Pero introduce diversidad de evaluación.

La lógica es parecida a una práctica clásica de ingeniería: quien implementa una solución no debería ser la única fuente de evidencia de que la solución funciona.

La IA hace posible automatizar buena parte de ese desacuerdo productivo.

Aquí aparece una paradoja interesante:

Cuanto más barato sea generar software, más rentable puede resultar gastar recursos intentando destruirlo antes de desplegarlo.

4. System design: elegir antes de implementar

La cuarta habilidad es probablemente la más difícil de automatizar por completo: diseño de sistemas.

No porque una IA no pueda generar arquitecturas.

Puede hacerlo.

Puede proponer bases de datos, colas, caches, APIs, balanceadores, servicios cloud, workers y pipelines completos.

El problema es que casi nunca existe una única arquitectura correcta.

Hay trade-offs.

Por ejemplo:

PostgreSQL o DynamoDB

monolito o microservicios

cola o llamada síncrona

consistencia fuerte o eventual

serverless o capacidad dedicada

construir o comprar

La respuesta depende del contexto:

  • volumen esperado;
  • presupuesto;
  • latencia;
  • equipo disponible;
  • requisitos regulatorios;
  • tolerancia a fallos;
  • complejidad operativa;
  • horizonte temporal del producto.

Una IA puede producir una recomendación técnicamente razonable y aun así ser una mala decisión para una empresa concreta.

Ahí aparece una forma de valor humano difícil de reducir a sintaxis:

criterio.

El ingeniero debe poder evaluar no solo si algo funciona, sino si es la solución adecuada dentro de las restricciones reales.

El conocimiento de código sigue importando

Nada de esto significa que debamos dejar de aprender programación.

Hay una diferencia enorme entre:

no escribir manualmente todo el código

y

no entender el código

Un desarrollador que no entiende programación tendrá enormes dificultades para:

  • detectar una abstracción incorrecta;
  • evaluar complejidad;
  • leer un stack trace;
  • distinguir una solución elegante de una frágil;
  • revisar concurrencia;
  • detectar problemas de rendimiento;
  • interpretar un diff grande;
  • decidir si un agente está inventando una API;
  • diseñar buenos tests.

La sintaxis puede perder valor relativo.

Los fundamentos no.

De hecho, la IA puede aumentar el retorno de entenderlos porque una persona técnicamente fuerte puede dirigir una cantidad de implementación muchísimo mayor.

Seguridad y cloud también suben de nivel

El video menciona dos áreas adicionales que merecen atención: seguridad y cloud computing.

Los agentes de código modernos ya no se limitan a sugerir texto.

Pueden tener acceso a:

filesystem
shell
GitHub
cloud CLIs
bases de datos
APIs
credenciales
sistemas de CI/CD

Eso convierte la seguridad en un problema todavía más importante.

Un agente útil necesita capacidades.

Pero cada capacidad también aumenta el radio de daño de una decisión incorrecta.

Por eso veremos más importancia en conceptos como:

  • least privilege;
  • sandboxes;
  • approval gates;
  • aislamiento;
  • gestión de secretos;
  • auditoría;
  • trazabilidad;
  • políticas de ejecución.

La pregunta ya no es solamente si el agente sabe programar.

También es qué le permitimos hacer.

El nuevo cuello de botella: decidir, coordinar y verificar

Podemos resumir la transición de esta manera:

ANTES

idea
→ humano diseña
→ humano escribe código
→ humano prueba
→ humano corrige

AHORA

idea
→ humano define objetivo y restricciones
→ agentes planifican / implementan
→ herramientas verifican
→ otros agentes revisan
→ humano decide y responde por el resultado

El código no desaparece.

Se convierte progresivamente en una capa más automatizada del proceso.

Y cuando una capa se automatiza, el valor se mueve hacia los problemas que quedan alrededor.

Por eso cuatro áreas destacan especialmente:

PLANIFICACIÓN
saber dividir correctamente el problema

ORQUESTACIÓN
saber coordinar agentes, modelos y herramientas

TESTING
saber demostrar que el resultado funciona

SYSTEM DESIGN
saber escoger la arquitectura correcta y sus trade-offs

No son habilidades nuevas.

Lo nuevo es su peso relativo.

De programadores a diseñadores de fábricas de software

Quizá la mejor forma de entender el cambio sea esta:

Antes diseñábamos software.

Ahora también estamos empezando a diseñar sistemas que diseñan y producen software.

Una fábrica de software agéntica puede contener:

especificaciones
+ agentes especializados
+ harnesses
+ herramientas
+ tests
+ reviewers
+ políticas
+ memoria
+ CI/CD
+ observabilidad

El producto intelectual del ingeniero deja de ser únicamente el código final.

También es la maquinaria que permite producir código correcto de forma repetible.

Eso conecta dos tendencias que hemos seguido de cerca en Capital de Tokens: el ascenso del agentic engineering y la aparición del agent harness como una nueva capa fundamental de la pila de desarrollo.

Entonces, ¿qué estudiar hoy?

Si alguien está empezando una carrera de software, la respuesta probablemente no sea abandonar programación porque una IA puede escribir Python o TypeScript.

La respuesta puede ser exactamente la contraria: aprovechar que implementar es más barato para subir más rápido hacia problemas de mayor nivel.

Aprender código.

Pero también aprender a:

modelar problemas
→ diseñar sistemas
→ dividir trabajo
→ escribir especificaciones
→ crear tests sólidos
→ evaluar trade-offs
→ revisar resultados
→ operar infraestructura
→ proteger sistemas
→ coordinar agentes

Porque incluso si llegamos a un mundo donde generar una aplicación convencional sea casi instantáneo, seguirá existiendo una pregunta mucho más difícil:

¿Quién sabe qué aplicación debemos construir, cómo debería funcionar y cómo demostramos que podemos confiar en ella?

Ahí sigue viviendo la ingeniería.

Fuente y lecturas relacionadas