Por qué fracasan las fábricas de software (o: la ingeniería de herramientas no basta)
Las “fábricas de software” impulsadas por IA que buscan generar y entregar código con mínima intervención humana se están encontrando con límites duros en torno a la calidad del código, la mantenibilidad y el diseño a largo plazo. Los comentaristas sostienen que, aunque los modelos modernos pueden producir funciones y refactors impresionantes, tienden a acumular “basura” arquitectónica sin una planificación, verificación y criterio humanos estrictos, especialmente en bases de código grandes y en evolución. Muchos ven la vía más prometedora como equipos de alta disciplina que usan agentes como multiplicadores de fuerza dentro de especificaciones, pruebas y procesos de revisión sólidos, en lugar de una automatización total en modo “apagado”.
Estado de las “fábricas de software” y contexto de StrongDM
- Algunos comentaristas señalan que el trabajo de IA de StrongDM se escindió en una firma de consultoría, interpretándolo como éxito (las ideas tienen valor) o como una señal de que el producto necesitaba muchos servicios.
- Un miembro del laboratorio de StrongDM aclara que su “reporte meteorológico” ha visto actualizaciones regulares y afirma que la mayoría de los problemas de software ceden ante sus técnicas de fábrica, especialmente con modelos más nuevos.
- Otros argumentan que seguimos en días tempranos y experimentales; todavía no existe una “metodología estándar” estable.
Rigor, mantenibilidad y especificaciones
- Hay un amplio acuerdo: los equipos que más sacan provecho de la IA ya tenían alta disciplina, código limpio, pruebas e higiene.
- Muchos ven la mantenibilidad como el problema central no resuelto: los modelos pueden implementar funciones, pero degradan lentamente la arquitectura y el acoplamiento con el tiempo.
- Se exploran especificaciones normativas al estilo RFC y restricciones tipadas para delimitar agentes, pero se señala que las especificaciones muy detalladas empiezan a parecerse al código y no está claro que ahorren esfuerzo.
- Algunos proponen configuraciones de RL que recompensen la salud a largo plazo de la base de código, pero señalan que no existe un oráculo rápido y objetivo para el “buen diseño”.
Revisión de código, PR y proceso
- Hay una fuerte división sobre la revisión de código:
- Un bando cree que la revisión humana es esencial para compartir conocimiento, criterio, supervisión del diseño y cumplimiento; usar LLMs para fingir revisiones se ve como una dejación.
- Otro bando automatiza las revisiones y afirma que las organizaciones se preocupan sobre todo por prevenir errores y por la velocidad; sostiene que deberíamos revisar software en ejecución, no diffs.
- Muchos se quejan de la UX de los PR, de los diffs excesivamente grandes generados por agentes y de los comentarios en “LLMese”.
- Algunos abogan por minimizar las barreras de los PR mediante comprobaciones automáticas intensivas, pruebas, linters y facilidad para revertir; otros argumentan que aun así se pierden problemas de arquitectura y compatibilidad hacia atrás.
Capacidades del modelo, RL y contexto largo
- Hay desacuerdo sobre cuánto cambiaron las cosas los modelos de frontera (Opus, Fable, GPT-5.6, etc.). Algunos informan haber entregado funciones completas a agentes; otros dicen que los intentos en modo “apagado” seguían produciendo basura o diseños malos que se reforzaban a sí mismos.
- Varios observan que los modelos pueden refactorizar bien cuando se les pide explícitamente, pero no detectan de forma autónoma cuándo hacen falta refactors.
- El comportamiento con contexto largo es mixto: algunos ven poca degradación; otros muestran ejemplos de modelos que olvidan flujos de trabajo simples en contextos grandes.
- Muchos enfatizan que hoy el RL optimiza sobre todo el éxito en la tarea, no la calidad del diseño, por lo que el reward hacking y las pruebas frágiles son comunes.
Rol de los ingenieros y el “gusto”
- Varios comentarios enmarcan la principal tarea de un ingeniero de software como la propiedad del sistema, el diseño a largo plazo y el gusto, no solo escribir código.
- La buena arquitectura se describe como sutil, difícil de medir y aprendida mediante experiencia dolorosa; los comentaristas dudan de que los modelos actuales puedan hacer de forma fiable estos juicios de diseño.
- Un tema recurrente: los patrones de la base de código actúan como “prompts implícitos”, así que los humanos deben proteger vigilante y cuidadosamente las abstracciones y los patrones o la basura se acumula.
Dónde pueden funcionar las fábricas hoy
- Muchos ven las “fábricas oscuras” como más viables para:
- Apps pequeñas, de bajo riesgo o de afición.
- Experimentos y scripts de vida corta.
- Para sistemas complejos, que generan ingresos o están regulados, la mayoría aboga por fábricas con humano en el circuito, con más planificación previa (producto, sistema, diseño de programa) y restricciones más estrictas, no autonomía total.