Una corriente cada vez más fuerte en la industria propone que el agentic coding —donde la IA escribe el código y el humano se limita a orquestar— es el futuro inevitable del desarrollo de software. Spec-Driven Development (SDD), planes generados por LLM, múltiples agentes iterando sin parar: la promesa es que el ingeniero "sube de nivel" y opera puramente como arquitecto. Pero el ensayo Agentic Coding is a Trap, publicado por Lars Faye, sumado a un reciente estudio interno de Anthropic y a relatos de veteranos como Simon Willison, plantea una advertencia incómoda: supervisar a un agente de IA exige las mismas habilidades que el agentic coding está atrofiando.
La discusión no se reduce al clásico "los desarrolladores siempre se quejan de las herramientas nuevas". Lo que diferencia este ciclo, según Faye, es que los efectos negativos ya no son especulativos. Hay datos, hay anécdotas convergentes y hay una admisión explícita por parte del propio fabricante de uno de los agentes más populares del mercado.
Qué está pasando con el agentic coding
El debate cobró fuerza tras la publicación del ensayo de Faye en larsfaye.com. El argumento central no es que las herramientas no sirvan —el autor reconoce explícitamente que son útiles y poderosas—, sino que su uso sostenido produce trade-offs cuantificables que la industria está minimizando o ignorando para sostener el hype.
Faye identifica cuatro costos concretos del modelo "orquestador + agente":
- Aumento de complejidad sistémica — los pipelines, validaciones, sandboxes y observabilidad necesarios para domar la no-determinismo de un LLM acaban siendo tan caros como el problema que el LLM iba a resolver.- Atrofia de habilidades — no solo en juniors, sino también en ingenieros con diez o más años de experiencia.- Vendor lock-in — caídas de Claude Code ya han dejado equipos enteros detenidos, sin plan B operacional.- Costos fluctuantes — un empleado tiene un costo fijo y predecible; los tokens son un blanco móvil que escala con el uso real. El orquestador depende de habilidades que el flujo está erosionando. ## Contexto: del autocompletado a la orquestación
Hace tres años, los asistentes de código eran autocompletadores sofisticados: sugerían una línea, una función, a veces un archivo. El humano seguía teniendo el control directo del cursor. Hoy el modelo dominante es distinto. Herramientas como Claude Code, Cursor Composer, Aider y Cline operan como agentes: leen archivos, escriben archivos, ejecutan comandos, prueban resultados, abren PRs. El humano "empuja la palanca de la tragamonedas" —en palabras de Faye— hasta que el resultado parece aceptable.
Spec-Driven Development lleva ese patrón a su conclusión lógica. La idea es definir requerimientos a nivel macro y micro, generar un plan, y desconectar al humano de la escritura del código. El supervisor está ahí para aportar "buen gusto", revisar la salida y dirigir al agente. Es una promesa seductora porque promete velocidad, pero descansa sobre una premisa frágil: que el supervisor sigue siendo capaz de detectar problemas en miles de líneas generadas antes de que se conviertan en deuda técnica o en incidentes en producción.
La paradoja de la supervisión
Lo más relevante del ensayo de Faye es una cita enterrada en una publicación reciente del propio Anthropic, donde la empresa reconoce el problema con una honestidad sorprendente: una razón por la que la atrofia de habilidades de programación es preocupante es la "paradoja de la supervisión"… usar Claude eficazmente requiere supervisión, y supervisar a Claude requiere las mismas habilidades de programación que pueden atrofiarse por el uso excesivo de IA.
💭 Clave: Si el modelo de uso correcto exige una habilidad que el propio modelo erosiona, el sistema no es estable a largo plazo. Es un loop de retroalimentación negativa que cualquier ingeniero de control reconocería como inestable.
La consecuencia es que el desarrollador que más necesita revisar críticamente la salida del agente es, paradójicamente, el que más rápido pierde la capacidad de hacerlo. La organización aplaude la productividad inmediata —más PRs, más features, menos tickets— mientras la deuda cognitiva se acumula sin métrica visible.
No es "subir de nivel en la abstracción"
Un argumento común en la comunidad sostiene que el agentic coding es simplemente un nuevo nivel de abstracción, comparable al salto de assembler a FORTRAN, o de C++ a Python. Faye desmonta esa equivalencia con un punto técnico: un nivel mayor de ambigüedad no es un nivel mayor de abstracción.
Cuando un programador pasó de C++ a Java, la semántica seguía siendo determinista. Mismas entradas, mismas salidas. Cuando un sysadmin migró a AWS, las primitivas cambiaron pero las garantías eran consultables en documentación estable. El agentic coding rompe ese contrato: la misma instrucción produce salidas distintas en runs distintos, y el comportamiento depende del contexto, del prompt, del modelo, de la temperatura, y de un sinfín de variables que no son reproducibles fácilmente.
El loop entre delegar a la IA y perder práctica directa.
graph LR
A["Desarrollador escribe prompt"] --> B["Agente genera codigo"]
B --> C["Humano revisa diff"]
C --> D["Menos practica directa"]
D --> E["Atrofia de habilidades"]
E --> F["Menor capacidad de supervisar"]
F --> A
El loop anterior es la representación gráfica de lo que Anthropic llama paradoja de la supervisión. Cada vuelta refuerza la dependencia y debilita al supervisor.
El problema del orquestador "experto"
Sandor Nyako, Director de Software Engineering en LinkedIn —quien supervisa cerca de 50 ingenieros— ha observado el fenómeno proliferando en su organización. El patrón se repite: ingenieros que antes podían explicar el comportamiento de un sistema línea por línea ahora lo describen en términos vagos, con frases como "el agente lo manejó" o "está en el plan que generamos".
Simon Willison, desarrollador con casi 30 años de experiencia y referencia obligada cuando se habla de uso productivo de LLMs, lo expresó en términos parecidos: "no tengo un modelo mental firme de lo que las aplicaciones pueden hacer y cómo funcionan, lo que significa que cada feature adicional se vuelve más difícil de razonar".
⚠️ Ojo: Que un veterano de tres décadas reporte pérdida de modelo mental es la señal más fuerte de que esto no es un problema generacional ni de juniors mal formados. El efecto se documenta arriba y abajo de la curva de experiencia.
El impacto sobre los juniors
Para los desarrolladores junior la cuesta es aún más empinada. Aprender a programar es 50% leer código y 50% escribir código —y debuggear, equivocarse, romper cosas, repararlas. Si truncamos esa segunda mitad y la reemplazamos por "revisar lo que generó el agente", la curva de aprendizaje se aplana en el peor lugar posible: justo donde se construye la intuición que después permitirá supervisar agentes en serio.
El resultado proyectado es preocupante: una nueva generación de desarrolladores promovidos a roles de orquestación sin haber pagado el peaje de friction que históricamente forjó a los seniors capaces de detectar bugs sutiles a la primera lectura.
Datos y cifras
Las cifras concretas que circulan en el debate ayudan a poner la conversación en perspectiva:
- 50 ingenieros bajo supervisión de Sandor Nyako en LinkedIn donde el fenómeno ya se observa.- 30 años de experiencia tiene Simon Willison, suficiente para descartar que el efecto sea un problema de novatos.- 2 horas de outage de Claude Code recientes que dejaron equipos enteros sin capacidad operativa según reportes en redes.- Tokens por PR: equipos serios reportan rangos de 500K a 5M tokens consumidos en flujos agenticos para una sola feature mediana, un costo que escala con el tamaño del repositorio.
Comparativa de modos de trabajo
Modo clasico:
- Dev escribe codigo
- CI valida
- PR review humano
- Merge
Modo agentic puro:
- Dev escribe spec/prompt
- Agente genera N variantes
- Dev revisa diff (cientos a miles de lineas)
- Agente itera sobre feedback
- CI valida
- PR review humano (a veces tambien con agente)
- Merge
Modo hibrido recomendado:
- Dev escribe el codigo critico (logica de negocio, seguridad)
- Agente cubre boilerplate, tests, refactors mecanicos
- Dev mantiene modelo mental completo del sistema
- CI + revision humana
Impacto y análisis
El agentic coding no es una moda destinada a desaparecer. Las herramientas funcionan lo suficiente como para haberse instalado en los flujos de miles de equipos, y el ahorro percibido en velocidad inmediata es real. El problema, como señala Faye, es que el contrato implícito que la industria firmó —"la IA hace el código, el humano supervisa con criterio"— solo se sostiene si la segunda mitad de esa frase no se erosiona.
Lo que está apareciendo en el debate es una propuesta más matizada. La pregunta no es "agentes sí o agentes no", sino dónde y cuándo conviene delegar. Hay tareas donde el costo cognitivo de no hacerlas a mano es bajo —migraciones mecánicas, generación de tests obvios, refactors regex-friendly. Y hay otras donde la pérdida de modelo mental es directamente proporcional al riesgo del sistema —lógica de negocio crítica, código de seguridad, primitivas de concurrencia.
💡 Tip: Una heurística útil para LATAM: si tu equipo no podría operar 48 horas sin el agente porque nadie recuerda cómo está estructurado el sistema, pasaste el umbral. Reducí la dependencia antes de que sea una crisis.
Qué sigue para LATAM
En el contexto latinoamericano, donde muchas empresas adoptan agentes para compensar la presión sobre los presupuestos de ingeniería, la advertencia tiene un peso adicional. Equipos pequeños sin redundancia de seniors son los más expuestos a la paradoja de supervisión: si el único arquitecto del sistema delega todo en un agente, el bus factor del proyecto se vuelve dependiente del proveedor del LLM, no del equipo humano.
Algunas prácticas que están emergiendo y que vale la pena considerar antes de empujar agentic coding al límite:
- Días de "código a mano" — semanas o sprints donde el agente queda apagado para mantener músculo.- Code reviews sin asistencia — un humano leyendo el diff sin que un LLM lo resuma primero.- Onboarding sin agente — los primeros 30 días de un junior se hacen leyendo y escribiendo código directamente, no orquestando.- Auditorías periódicas de modelo mental: ¿el equipo puede explicar el sistema en una pizarra sin abrir el repo?
El agentic coding es una herramienta poderosa, pero como toda herramienta poderosa exige un usuario competente. Y la competencia no se importa por API: se construye con friction, con bugs propios, con horas frente a un debugger. Saltarse esa etapa es exactamente la trampa que Faye advierte.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es exactamente el agentic coding?
Es un modelo de desarrollo donde un agente de IA —típicamente sobre Claude, GPT u otro LLM— ejecuta de forma autónoma tareas de programación: lee archivos, escribe código, corre comandos y prueba resultados, mientras el desarrollador humano define objetivos, revisa salidas y dirige el proceso sin escribir el código a mano.
¿Qué es la "paradoja de la supervisión" que menciona Anthropic?
Es la observación de que usar agentes de IA eficazmente requiere supervisión humana competente, pero esa supervisión exige las mismas habilidades de programación que el uso intensivo de IA tiende a atrofiar con el tiempo.
¿Solo afecta a desarrolladores junior?
No. El ensayo de Lars Faye y los reportes de Simon Willison muestran que ingenieros con 10, 20 e incluso 30 años de experiencia reportan pérdida de modelo mental sobre los sistemas que mantienen, no solo los principiantes.
¿Significa que hay que dejar de usar agentes de código?
No es la conclusión del ensayo. La propuesta es un uso selectivo: delegar tareas mecánicas y de bajo riesgo cognitivo, y mantener el control directo sobre la lógica crítica, la seguridad y el código que define la arquitectura del sistema.
¿Qué riesgos económicos extra trae el agentic coding?
Vendor lock-in (caídas del proveedor pueden detener al equipo), costos variables en tokens que escalan con el tamaño del proyecto, y la dificultad de cambiar de herramienta porque el equipo ya no sabe operar sin asistencia.
¿Cómo proteger a un equipo pequeño en LATAM de este efecto?
Combinar agentes con prácticas que preserven el músculo: revisiones humanas sin resumen previo de IA, días de código a mano, onboarding sin agente para juniors y auditorías periódicas del modelo mental compartido del sistema.
Referencias
- Agentic Coding is a Trap — Lars Faye — ensayo original que detona el debate sobre deuda cognitiva.- Blog de Simon Willison — reflexiones de un veterano sobre modelo mental y uso de LLMs en el día a día.- Anthropic Research — publicaciones donde la propia empresa documenta la paradoja de supervisión.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)