Los riesgos del agentic coding son más silenciosos que los beneficios que se promocionan: mientras la industria vende que “el humano orquesta y el agente codea“, lo que realmente pasa es que tu capacidad técnica se atrofia sin que te des cuenta, los costos escalan de forma no lineal, y cuando la herramienta se cae, tu equipo queda paralizado sin ningún plan B.
En 30 segundos
- El agentic coding propone que el humano define el plan y los agentes implementan el código, un modelo llamado Spec Driven Development (SDD)
- Lars Faye identificó trade-offs concretos: atrofia de habilidades, vendor lock-in, costos de tokens que escalan más que un salario fijo, y complejidad de infraestructura adicional para mitigar el no-determinismo de la IA
- El 28 de abril de 2026, un outage de Claude Code dejó equipos paralizados durante 3-4 horas, con degradación de calidad del 33.7% simultáneamente
- Addy Osmani documentó el “problema del 80%”: los agentes llegan rápido al 80% del proyecto, pero los últimos requerimientos se vuelven iterativos, costosos y frustrantes
- El 90% del código generado por agentes compila; el 45% tiene vulnerabilidades identificables
¿Qué es agentic coding y por qué se vende como la solución definitiva?
El agentic coding es un paradigma donde los desarrolladores definen requerimientos en lenguaje natural y los agentes de IA implementan el código de forma autónoma, iterando hasta completar la tarea. El modelo más citado es el Spec Driven Development (SDD): generás un plan detallado, lo cargás en el agente, y tirás de la palanca hasta que el resultado se parece a lo que pediste.
El rol del desarrollador cambia. Ya no escribís código; “orquestás”. Revisás outputs, ajustás el rumbo, das el visto bueno. La narrativa dominante es que esto es una evolución natural: vos ponés el criterio y el gusto, el agente pone los dedos en el teclado.
¿Por qué se vende tan bien? Porque los demos funcionan. Si le pedís a Claude Code que arme un CRUD en FastAPI, lo hace en minutos. Si antes tardabas dos horas en scaffoldear algo, ahora tardás diez minutos. Eso es real, no marketing.
El problema viene después.
Los trade-offs reales que la industria no menciona
Lars Faye publicó un análisis que la gente que vende este paradigma preferiría que no leyeras. Faye identificó varios trade-offs concretos que aparecen apenas se va del demo a producción real:
Primero: la infraestructura circundante se vuelve más compleja. Los agentes son no-deterministas (no siempre te dan el mismo resultado con el mismo input), y para mitigar eso necesitás layers adicionales de validación, testing, y revisión que antes no necesitabas. El ahorro de tiempo de codeo lo recuperás en overhead de gobernanza.
Segundo: los costos de tokens no se comportan como un salario. Un desarrollador tiene costo fijo mensual. Los tokens escalan con el uso, y en escenarios de proyectos complejos con múltiples iteraciones del agente, los números se pueden multiplicar hasta 122 veces respecto a una estimación inicial. Algunos equipos no descubren esto hasta que llega la factura. Lo explicamos a fondo en soluciones empresariales de seguridad.
Tercero: a más distancia entre el “orchestrator” y el código generado, más ambigüedad en lo que realmente se está commiteando. Podés aprobar un PR sin entender genuinamente qué hace el 30% del código.
La deuda cognitiva: perdés habilidades sin que te avisen
Ponele que llevás seis meses usando Claude Code para todo. ¿Qué pasa si mañana necesitás debuggear un memory leak en producción sin el agente? ¿Podés? ¿O ahora dependés de que el agente lea el stack trace y te diga qué hacer?
Faye llama a esto “atrofia cognitiva” (o cognitive debt), y es el riesgo más traicionero porque no duele cuando pasa. No hay un momento claro de “perdí esta habilidad”. Es gradual. Lo que antes resolvías solo en diez minutos ahora lo delegás al agente porque es más cómodo y más rápido. Y así, semana a semana, la autonomía técnica real se va evaporando.
Lo interesante es que esto no afecta igual a todos los perfiles. Un senior con diez años de experiencia puede usar agentes sin perder autonomía porque tiene el modelo mental cimentado. Un junior que aprende a programar con agentes desde el día uno está construyendo sobre arena: sabe pedirle cosas al agente, pero no entiende por qué el código funciona o falla.
Vendor lock-in: cuando Claude Code se cayó en abril de 2026
El 28 de abril de 2026, Claude Code tuvo un outage de entre 3 y 4 horas. No fue una degradación menor: equipos enteros quedaron paralizados, con una degradación de calidad del 33.7% reportada de forma simultánea al inicio del incidente.
Equipos que habían migrado su workflow entero a agentic coding no tenían plan B. No era que alguien no pudiese usar una funcionalidad extra; era que el flujo completo de desarrollo se detuvo. (Esto es exactamente lo que Faye predijo en su análisis, meses antes de que pasara.)
El vendor lock-in en herramientas de agentic coding es peor que en otras categorías de software porque es doble: dependés de la herramienta para producir código, y gradualmente dependés de ella para entender el código que ya existe en tu repo. Cuando la herramienta falla, no solo perdés el acceso; perdés la capacidad operativa. Te puede servir nuestra cobertura de por qué ChatGPT falla en código.
Los registros de status.claude.com de 2026 muestran que este fue el quinto incidente relevante en los primeros cuatro meses del año. No es un caso excepcional; es un patrón.
El problema del 80%: cuando la automatización falla silenciosamente
Addy Osmani documentó en su Substack lo que llama el “problema del 80%”: los agentes son muy buenos para llevar un proyecto al 80% de forma rápida. El primer 80% fluye. Parece magia.
El problema es el 20% restante. Los últimos requerimientos —los edge cases, las integraciones específicas, las decisiones de arquitectura que no quedaron claras en el spec— se vuelven iterativos de una forma que no escala bien. Cada iteración del agente consume tokens, tiempo, y atención del orchestrator. El slot machine lever no siempre tira oro, y las iteraciones malas cuestan igual que las buenas.
¿Y qué pasa cuando el agente llega al 80% de algo incorrecto? Que tenés un 80% de código que hay que tirar, y la pérdida es real.
Seguridad: el código compila, pero eso no significa que sea seguro
Datos de Rippling de 2026 sobre agentic AI muestran que el 90% del código generado por agentes compila correctamente. El problema es que el 45% de ese código tiene vulnerabilidades identificables mediante análisis estático. El agente produce código funcional, no código seguro.
Los vectores de ataque más documentados en agentic coding incluyen prompt injection (donde input malicioso en el contexto del agente lo hace generar código con backdoors), escalación de privilegios accidental cuando el agente tiene acceso a sistemas de producción, y dependencias introducidas sin revisión manual que traen CVEs conocidos.
El dato que más llama la atención: según Rippling, el 74% de los líderes tecnológicos ven a los agentes como un vector de ataque activo en sus organizaciones. Solo el 13% tiene gobernanza adecuada para mitigarlo. La mayoría está usando la herramienta sin los controles que debería tener. Tema relacionado: entender los modelos de lenguaje.
Si tu agente tiene acceso a producción sin sandboxed environments de por medio, el riesgo no es teórico.
Comparativa: agentic coding con y sin resguardos
| Aspecto | Agentic coding sin controles | Agentic coding con resguardos |
|---|---|---|
| Velocidad inicial | Alta (80% del proyecto rápido) | Alta, con overhead de revisión |
| Costo de tokens | Impredecible, puede x122 | Controlado con límites por sesión |
| Seguridad del código | 45% con vulnerabilidades | Reducido con SAST en el pipeline |
| Autonomía técnica del equipo | Cae progresivamente | Se preserva con práctica manual regular |
| Plan B ante outage | Ninguno | Flujo manual documentado |
| Vendor lock-in | Total (Claude Code o similar) | Parcial, con SDD framework agnóstico |
Cómo usar agentic coding sin caer en la trampa
La clave no es abandonar los agentes; es usarlos sin perder la autonomía técnica real. Algunas prácticas concretas:
- Mantené el hábito de debuggear sin el agente: una vez por semana, resolvé algo de producción sin abrirle Claude Code. Si no podés, ya estás en la zona de atrofia.
- No uses el agente como sustituto de entender el código: si el agente genera algo que no entendés, pedile que te lo explique antes de commitearlo, no después.
- Tenés que tener un plan B documentado ante outages: qué hace tu equipo si Claude Code no está disponible durante 4 horas en horario pico.
- SAST en el pipeline es no negociable: todo código generado por agentes pasa por análisis estático de seguridad antes de mergear. Sin excepciones.
- Sandbox antes de producción: si tu agente tiene acceso a sistemas reales, limitá ese acceso con entornos aislados. El agente no necesita acceso a prod para generar código.
- Revisá facturas de tokens semanalmente: el costo que parece razonable en un sprint puede explotar en el siguiente si el spec era ambiguo.
Los frameworks de SDD agnósticos de vendor (que no dependen de Claude Code específicamente) son una alternativa válida si el lock-in es una preocupación real para tu equipo. El spec lo podés ejecutar con distintas herramientas si el proceso está bien definido.
Si tu infraestructura web o tus entornos de desarrollo están en la nube, tener el control de dónde corren los agentes es parte de la ecuación. Con hosting propio en donweb.com podés definir mejor los límites de acceso que tiene cualquier herramienta externa a tus sistemas.
Lo que está confirmado y lo que todavía no cierra
Confirmado
- El outage del 28 de abril de 2026 afectó a equipos que dependían de Claude Code como herramienta principal
- El 45% del código generado por agentes tiene vulnerabilidades identificables (dato de Rippling, 2026)
- El “problema del 80%” documentado por Addy Osmani es consistente con la experiencia de múltiples equipos
- Los costos de tokens no son lineales y pueden escalar de forma inesperada en proyectos complejos
Lo que no queda claro todavía
- Si la atrofia cognitiva es reversible: no hay estudios longitudinales suficientes sobre desarrolladores que usaron agentes durante 12+ meses y luego volvieron al código manual
- Cuánto del 45% de vulnerabilidades es atribuible al agente vs. a las prácticas del equipo que lo usa
- Si los frameworks de SDD agnósticos de vendor realmente reducen el lock-in o solo lo desplazan a otro proveedor
Errores comunes al adoptar agentic coding
Creer que el spec se escribe solo
El SDD requiere specs muy precisos. Un spec ambiguo genera código ambiguo, y el agente va a iterar hasta que algo compile, no hasta que algo sea correcto. Si no tenés la habilidad de escribir un spec detallado y verificable, el agentic coding te va a costar más tiempo, no menos.
Asumir que el código generado es correcto porque compila
Compilar no es sinónimo de correcto. Es el error más caro de este paradigma. Equipos que aprueban PRs de código generado sin revisión manual porque “el agente lo hizo y los tests pasan” están acumulando deuda técnica y de seguridad a una velocidad que no van a ver hasta que sea tarde.
No contemplar el costo total de la herramienta
El análisis de costo-beneficio del agentic coding que la mayoría de los equipos hace es incompleto. Calculan el ahorro de horas de desarrollo, pero no suman: costo de tokens (variable), costo de infraestructura adicional de validación, costo de outages (horas de equipo perdidas), y costo de remediar vulnerabilidades de seguridad. Cuando se suma todo, el número cambia bastante. Esto se conecta con lo que analizamos en búsqueda y validación de soluciones.
Preguntas Frecuentes
¿Es realmente una buena idea usar agentes IA para toda la codificación?
Para tareas repetitivas, scaffolding, y primeros drafts de código, sí. Para toda la codificación sin excepción, no. El problema no es la herramienta sino la dependencia total. Los equipos que mejores resultados reportan usan agentes para el 40-60% de su trabajo, manteniendo habilidades manuales para debugging, arquitectura, y decisiones de seguridad.
¿Qué riesgos tiene depender de herramientas como Claude Code?
El vendor lock-in es el riesgo más inmediato: si la herramienta se cae (como pasó el 28 de abril de 2026), tu equipo queda paralizado sin un plan B. A eso sumale atrofia de habilidades técnicas, costos de tokens que pueden escalar hasta 122 veces lo estimado en proyectos complejos, y el 45% de vulnerabilidades que el análisis estático puede detectar en código generado automáticamente.
¿Pierdo mis habilidades de programador usando agentic coding?
Si lo usás sin control, sí. La atrofia cognitiva es gradual e indolora: empezás delegando las partes aburridas y terminás sin poder debuggear algo de producción sin ayuda del agente. La mitigación concreta es simple: reservá tiempo semanal para resolver problemas reales sin el agente, sin excepción.
¿Cuál es el verdadero costo del agentic coding?
Los tokens no tienen precio fijo. En proyectos complejos con specs ambiguos y múltiples iteraciones, los costos pueden multiplicarse hasta 122 veces respecto a la estimación inicial. A eso hay que sumar el overhead de infraestructura para mitigar el no-determinismo del agente, y el costo de remediar vulnerabilidades de seguridad que el análisis estático detecta tarde.
¿Qué es la deuda cognitiva en programación automática?
La deuda cognitiva es la pérdida progresiva de autonomía técnica que ocurre cuando un desarrollador delega sistemáticamente al agente tareas que antes hacía solo. No es inmediata ni dolorosa, por eso es peligrosa. Lars Faye la describe como la distancia creciente entre el “orchestrator” y el código real que se está generando y commiteando.
Conclusión
El agentic coding no es una trampa por ser malo; es una trampa porque sus costos reales son diferidos y silenciosos, mientras los beneficios son inmediatos y visibles. El primer mes con Claude Code parece productivísimo. El sexto mes, cuando hay un outage de 4 horas y nadie en el equipo sabe cómo avanzar sin el agente, o cuando el análisis de seguridad detecta vulnerabilidades en el 45% del código mergeado, ya es otra historia.
La pregunta correcta no es “¿uso agentic coding o no?” sino “¿con qué controles lo uso?”. Specs precisos, SAST en el pipeline, un plan B documentado para outages, revisión manual del código generado, y tiempo deliberado de práctica sin el agente. Con eso, la herramienta es un multiplicador real. Sin eso, es una deuda que se paga después.
Fuentes
- Lars Faye – Agentic Coding is a Trap: análisis original sobre trade-offs y deuda cognitiva
- Addy Osmani – The 80% Problem in Agentic Coding
- Rippling – Seguridad en agentic AI: datos de vulnerabilidades y gobernanza
- Ecosistema Startup – Outages de Claude AI en 2026 y cómo proteger tu startup
- Level Up – Spec Driven Development con Claude Code