Ya no existe algo así como un pequeño equipo de software
Las afirmaciones de que los agentes de codificación de IA convertirán a cada grupo de ingeniería en un “gran equipo” al permitir cientos de cambios en paralelo están recibiendo un gran escepticismo. Los comentaristas sostienen que dividir los sistemas en miles de microservicios para alimentar a los agentes básicamente traslada la complejidad a las operaciones, dificulta la coordinación y arriesga una avalancha de código de baja calidad optimizado para el conteo de PRs en lugar del valor para el usuario. Muchos ven a los LLM como herramientas potentes para desarrolladores individuales y monolitos pequeños y bien diseñados, pero advierten que depender en exceso de los agentes amenaza la mantenibilidad, el enfoque del producto y el papel a largo plazo de los ingenieros de software humanos.
Agentes, “pequeños equipos” y métricas de productividad
- Varios comentaristas dudan que los “pequeños equipos” que hacen 100 PRs/día mediante agentes representen un progreso significativo.
- Los altos conteos de PR/commits se ven como métricas de vanidad fáciles de manipular, cada vez más alejadas del valor para el usuario en la era de la IA.
- Según se informa, algunas organizaciones ahora presionan a los “rezagados” para usar más la IA, incluso cuando el trabajo generado por IA tiene que rehacerse en silencio.
Microservicios vs monolitos con IA
- Muchos sostienen que los microservicios añaden complejidad operativa (despliegues, redes, reintentos, consistencia, versionado) sin eliminar la complejidad inherente del producto.
- Varios dicen que los monolitos bien estructurados, con código modular y límites claros, siguen siendo superiores, especialmente porque un LLM puede retener más contexto.
- Otros afirman que los servicios de grano fino (incluso “nano-services”) encajan mejor con los límites de contexto de los LLM y con el paralelismo de los agentes, pero esto es discutido.
Calidad, corrección y coordinación
- Hay un fuerte escepticismo sobre que los agentes puedan modificar con seguridad miles de servicios: carecen de contexto de todo el sistema y pueden introducir fallos sutiles entre servicios.
- Los “enjambres de agentes” en paralelo corren el riesgo de generar conflictos semánticos en lugar de simples conflictos de merge, lo que dificulta la integración y la coordinación de lanzamientos.
- Algunos proponen usar la IA para mantenimiento: imponer invariantes, simplificar código o reducir sistemáticamente la deuda técnica; pero otros informan que los modelos a menudo ignoran las invariantes a medida que crece el contexto.
Experiencia del desarrollador e impacto laboral
- Las experiencias divergen: algunos desarrolladores en solitario o en equipos pequeños afirman una productividad drástica e incluso reescrituras completas de aplicaciones habilitadas por LLMs; otros son eficaces sin ellos.
- Debate sobre los futuros roles: desde “eres un ingeniero de prompts o estás despedido” hasta la idea de que el diseño de sistemas, la comprensión y la artesanía siguen siendo esenciales.
- Preocupa que el conocimiento arquitectónico de los seniors sea reemplazado por cambios opacos generados por IA, lo que podría aumentar las interrupciones cuando el personal con experiencia se vaya.
Preocupaciones éticas, económicas y sociales
- Hay inquietudes sobre la dependencia de proveedores externos de LLM, costes impredecibles, riesgos de privacidad, problemas de copyright y atrofia de habilidades.
- Algunos ven la productividad impulsada por IA como desalineada con las necesidades sociales (“más apps crud”, no software “mejor”), y conducida por el FOMO de los inversores y el “tokenmaxxing”.
- Otros argumentan que la IA es una ola tecnológica permanente y transformadora; puede haber un invierno de capex, pero no un retorno al desarrollo de software anterior a la IA.