¿Por qué los buenos desarrolladores desconfían tanto del desarrollo agéntico?
Los programadores con experiencia debaten si las herramientas de codificación “agénticas” de IA mejoran o erosionan la calidad del software y la habilidad de los desarrolladores. Muchos elogian a los agentes por acelerar drásticamente la implementación rutinaria y la depuración, pero advierten que delegar demasiado diseño y programación puede destruir los modelos mentales de un sistema, fomentar una revisión superficial de grandes cambios de código y convertir a los humanos en roles de QA de bajo contexto. Otros argumentan que el uso cuidadoso de agentes por parte de ingenieros sólidos, respaldado por buenas pruebas y observabilidad, puede ser una ventaja competitiva, mientras que la sobredependencia por parte de equipos menos capacitados corre el riesgo de producir sistemas frágiles, mal entendidos y una degradación a largo plazo de la experiencia.
¿Por qué la cautela?
- Muchos sostienen que la cautela se basa en la experiencia, no en el miedo: los agentes actuales a menudo producen código que “funciona”, pero que es frágil, incoherente o difícil de razonar.
- Existe la preocupación de que el desarrollo agéntico socave precisamente el proceso que crea buenos desarrolladores: practicar diseño, depuración y pensamiento arquitectónico.
- Algunos lo comparan con la deslocalización: ganancias a corto plazo, erosión a largo plazo de la experiencia local.
Calidad del código, riesgo y modelos mentales
- Los desarrolladores senior enfatizan que “construido” ≠ “listo para producción”: un solo error sutil puede causar incidentes graves, y los agentes pueden generar esos errores más rápido.
- Escribir código a mano obliga a aclarar requisitos y compensaciones; delegar en agentes permite que el modelo resuelva ambigüedades en silencio y tome decisiones arquitectónicas.
- Los grandes diffs autogenerados (por ejemplo, PRs de 3.000 líneas) son difíciles de revisar de verdad; los desarrolladores pierden un mapa mental profundo del sistema y se vuelven dependientes del agente para cada cambio.
Confianza, responsabilidad y dependencias
- Algunos dicen que no confían en código que no entienden, pero otros señalan que ya confiamos en capas opacas: compiladores, sistemas operativos, enormes árboles de dependencias.
- Contraargumento: las bibliotecas OSS tienen reputación comunitaria, historial y escrutinio compartido; un fragmento generado por IA es algo puntual, sin trayectoria previa.
- Debate sobre la “red de confianza”: ¿quién es responsable cuando un agente escribió la mayor parte del código? Algunos sostienen que la responsabilidad sigue recayendo en el humano que hace el commit; otros temen que la responsabilidad se vuelva difusa.
Cómo y cuándo ayudan los agentes
- Hay amplio acuerdo en que los LLM son herramientas potentes para: tareas pequeñas y bien acotadas, búsqueda de bugs, actualización de APIs, código repetitivo, funciones derivadas y experimentos rápidos.
- Varios afirman que los “mejores” desarrolladores usan agentes de forma agresiva, pero mantienen un control estricto: especifican arquitectura, pruebas y barandillas, y luego verifican los resultados.
- Otros informan que los agentes son más útiles en dominios desconocidos que en áreas donde ya tienen experiencia profunda.
Patrones de adopción, cultura y preocupaciones a más largo plazo
- Opiniones divididas: algunos ven la resistencia como terquedad o amenaza a la identidad; otros ven el uso agéntico a plena potencia como un imprudente “vibe coding”.
- Preocupación por una cultura de “si pasa las pruebas, se envía”, tickets escritos por IA demasiado especificados y gerentes que empujan a usar agentes para “ir más rápido” mientras los desarrolladores siguen asumiendo las consecuencias.
- Los temores a largo plazo incluyen atrofia de habilidades, degradación de los datos de entrenamiento y una avalancha de código “slop” de baja calidad; los optimistas prevén que barandillas más sólidas de pruebas y observabilidad harán que los detalles de implementación sean menos críticos.