Hay un miedo que circula entre desarrolladores: que usar agentes de IA para programar baja la calidad del código. Es una preocupación legítima. Pero Simon Willison —uno de los ingenieros más influyentes del ecosistema Python y cofundador de Django— lo plantea de forma tajante en su nueva guía de Agentic Engineering Patterns: publicar peor código con agentes es una elección, no una consecuencia inevitable.
Y lo más interesante no es solo el argumento. Es lo que propone en su lugar: usar esa misma velocidad que da la IA para hacer todo lo contrario — reducir activamente la deuda técnica que nunca tuviste tiempo de tocar.
¿Qué es la deuda técnica y por qué se acumula?
La deuda técnica es el costo diferido de hacer las cosas “a medias” por falta de tiempo. Willison describe cuatro ejemplos muy concretos que cualquier desarrollador reconocerá al instante:
- APIs mal diseñadas desde el inicio: cuando un caso de uso no previsto aparece tarde, es más fácil agregar una API ligeramente diferente que corregir la original en decenas de lugares.
- Nombres mal elegidos: cambiaste teams a groups en la UI, pero en el código sigues usando el término original porque corregirlo en todo el sistema tomaría días.
- Funcionalidad duplicada que fue creciendo: dos módulos hacen casi lo mismo, con pequeñas diferencias, y nadie los unificó nunca.
- Archivos monstruosos: ese archivo de 4.000 líneas que idealmente debería ser cinco módulos separados, pero dividirlo nunca fue prioritario.
El patrón común: todos son cambios conceptualmente simples pero consumidores de tiempo. Y eso los hacía inalcanzables en la práctica.
El refactoring asíncrono: agentes trabajando mientras tú haces otra cosa
Aquí está la propuesta central de Willison: estas tareas de refactoring son el caso de uso ideal para los agentes de codificación.
El flujo es directo: le das instrucciones al agente, lo sueltas en una rama separada, y sigues trabajando en lo tuyo. Cuando termina, revisas el resultado en un pull request. Si está bien, lo integras. Si casi está, le das feedback. Si está mal, lo descartas. Sin interrupciones, sin bloqueos.
Para esto, Willison menciona específicamente agentes asíncronos como Gemini Jules, OpenAI Codex web, o Claude Code on the web. La ventaja de estos es que corren en la nube —no en tu laptop— lo que significa que puedes lanzar varios en paralelo sin afectar tu flujo.
Y el resultado práctico es claro: el costo de mejorar el código ha caído tanto que ya no hay excusa para no hacerlo. La deuda técnica que postergabas no tiene por qué seguir acumulándose.
Este enfoque complementa lo que ya vimos con Anthropic Code Review, que usa agentes para revisar automáticamente cada pull request — en ese caso, los agentes actúan como guardianes de calidad. Aquí, son actores proactivos que mejoran el código antes de que llegue al PR.
¿Más IA significa más opciones o más riesgo?
Willison también aborda una ventaja menos obvia: los LLMs pueden ayudarte a evaluar más opciones al inicio de un proyecto, reduciendo la probabilidad de elegir mal la tecnología o el diseño.
Antes de comprometerte con Redis para gestionar el feed de actividad de tu aplicación, puedes pedirle a un agente que construya una simulación del sistema y ejecute un load test. Lo que antes tomaba días de prototipado, ahora toma horas —o minutos. Y si puedes lanzar tres prototipos en paralelo para comparar enfoques, tienes decisiones de arquitectura mucho más sólidas.
Esto es especialmente valioso para reducir otro tipo de deuda técnica: la que viene de elegir mal desde el principio. Una mala decisión de arquitectura en semana 1 puede costar meses en semana 20. Los agentes bajan el costo de exploración al punto en que comprometerse con la opción incorrecta por falta de tiempo ya no tiene sentido.
El bucle de mejora compuesta: cómo los agentes se vuelven mejores con el tiempo
El punto más sofisticado de la guía es lo que Willison llama el bucle de ingeniería compuesta, tomando el término del concepto que desarrollaron Dan Shipper y Kieran Klaassen en Every.to.
La idea es simple pero poderosa: los agentes siguen instrucciones, y esas instrucciones pueden mejorar con el tiempo. Cada proyecto que completas con un agente termina con una retrospectiva. ¿Qué funcionó? ¿Qué no? Eso se documenta y se convierte en instrucciones para el siguiente run.
Con el tiempo, tu codebase mejora, tus instrucciones mejoran, y los resultados de los agentes mejoran con ellos. Las mejoras de calidad se componen — igual que el interés. Lo que antes era un ciclo de acumulación de deuda técnica puede convertirse en un ciclo de reducción activa de esa deuda.
Esto tiene implicancias directas para el debate sobre la deuda de verificación que genera la IA en el código: si inviertes en documentar qué funciona y qué falla, el costo de verificación baja sostenidamente en lugar de crecer.
Por qué importa
El debate sobre si la IA sube o baja la calidad del código generalmente parte de una premisa falsa: que los equipos no tienen control sobre eso. La realidad es que sí lo tienen.
El problema real —el que reveló el informe DORA 2025 sobre desarrolladores y IA— es que muchos equipos usan la velocidad que da la IA para entregar más rápido, pero no para mejorar. La presión de las expectativas de velocidad infinita termina en más código, más rápido, pero también más frágil.
Lo que propone Willison es un cambio de mentalidad concreto: usar parte de esa velocidad para hacer todo lo que antes no podías hacer por falta de tiempo. Renombrar variables a lo largo de 50 archivos. Dividir ese módulo enorme. Eliminar la duplicación. Cosas que mejoran la base de código a largo plazo y que ahora cuestan casi nada ejecutar.
Si los agentes de IA permiten que finalmente paguemos la deuda técnica que llevamos años acumulando, eso no es solo un cambio en cómo programamos. Es un cambio en la calidad del software que construimos.
