Cuando rechazo código de IA aunque funcione

Cuando el código “funciona” sigue siendo rechazado

• Muchos argumentan que “se ejecuta y las pruebas están en verde” es solo un mínimo.
• Razones comunes de rechazo: no poder explicar el enfoque, un diff mayor que el problema, abstracciones prematuras, peor razonamiento/mantenibilidad, o confiar más en la salida de la IA que en la propia comprensión.
• Varios señalan que esto es idéntico a cómo los buenos revisores deberían tratar el código escrito por humanos (por ejemplo, de personas junior o contratistas).

Riesgo, responsabilidad y dominios

• Se exige un escrutinio mayor para sistemas críticos para la seguridad o de alto valor (pagos, infraestructura, backends centrales) que para herramientas internas, proyectos hobby o sitios estáticos simples.
• Expectativas de guardia y soporte: si no puedes depurar o explicar el código a las 3 de la madrugada, no deberías enviarlo a producción.
• Algunos consideran poco ético fusionar código de IA que no han revisado de verdad para sistemas críticos.

Calidad del código generado por IA

• Quejas frecuentes: abstracciones excesivas, sobreingeniería, utilidades duplicadas, columnas/campos innecesarios, manipulación de datos en el front-end en lugar de un uso adecuado del backend/DB, y “ensalada de código” en dominios complejos.
• Los LLM se describen como agentes que aumentan la entropía, divergiendo en lugar de converger sin restricciones fuertes.
• Errores sutiles (por ejemplo, fuga de datos en ML, casos límite de contabilidad) son fáciles de pasar por alto para la IA y difíciles de detectar para principiantes.
• Otros responden que los agentes promedio ya superan a muchos programadores “enterprise” en estructura básica y limpieza.

Flujos de trabajo y barandillas

• Algunos construyen arneses elaborados: linters personalizados para “AI-isms”, comprobaciones estrictas de pre-commit, TDD impuesto por scripts, revisión cruzada con múltiples modelos y auditorías periódicas asistidas por IA.
• Otros usan la IA principalmente como pareja de programación: planes, pequeños fragmentos, ayuda de sintaxis, portado entre lenguajes/frameworks, o expansión de pseudocódigo a nivel de comentarios.
• Unos pocos fusionan abiertamente código de IA que no entienden del todo, confiando en las pruebas y en una reacción rápida ante fallos; otros califican esto de arriesgado o irresponsable.

Dinámicas organizativas e incentivos

• Se considera que los malos incentivos existentes—premiar los commits grandes y rápidos y el comportamiento cowboy—se ven amplificados por la IA, lo que lleva a una acumulación más rápida de deuda técnica.
• Algunos prevén fallos estilo “bancarrota de software”, o al menos una entrega más lenta, alta rotación de seniors e intentos de reescritura que también podrían fracasar.

Punto intermedio y preocupaciones a largo plazo

• Debate sobre si existe un “punto intermedio” estable entre no usar IA y el desarrollo agéntico completo.
• Preocupación por la descalificación, la deuda de comprensión y los sistemas futuros que nadie entienda.
• Otros ven la IA como un “teclado más rápido” y sostienen que la verdadera limitación sigue siendo la comprensión humana y la arquitectura, que no deben subcontratarse.