El método de codificación con IA de correa corta para vencer a Fable

Reacción general al método de “correa corta”

  • Muchos ven el flujo de trabajo (supervisión cercana, permisos paso a paso, humano en el bucle) básicamente como la forma en que los desarrolladores cuidadosos ya usan la IA para código importante.
  • Otros creen que es una “microgestión” excesivamente cautelosa, que ralentiza las cosas frente a dejar que los agentes trabajen con más autonomía en un sandbox y simplemente revisar diffs/PRs.

Autonomía vs supervisión en la codificación con IA

  • Fuerte bando a favor del control estricto:
    • Sostiene que los modelos siguen alucinando, ignorando instrucciones e introduciendo errores sutiles y problemas de seguridad (p. ej., IDORs, mala concurrencia, malos patrones de acceso a BD).
    • Afirma que es “humanamente imposible” confiar por completo en agentes autónomos, especialmente en sistemas regulados o de alto riesgo; los humanos siguen siendo responsables.
    • Enfatiza que la revisión frecuente mantiene un modelo mental manejable de la base de código.
  • Fuerte bando a favor de correas más largas:
    • Ejecuta agentes en VMs/contenedores o con usuarios separados y claves restringidas, y luego les deja hacer “yolo” dentro de ese límite.
    • Trata a la IA como a un ingeniero junior–medio muy rápido: dejar que construya funcionalidades y luego hacer revisión humana y pulir el resultado.
    • Algunos informan buenos resultados en grandes bases de código en producción con tareas de tamaño medio gestionadas de forma autónoma.

Arneses, herramientas y patrones de seguridad

  • Patrones comunes:
    • Entornos aislados (contenedores, VMs, usuarios dedicados, shells de Nix).
    • Listas de अनुमति de herramientas / MCPs con solo comandos seguros, o listas de अनुमति de comandos bash más hooks.
    • Flujos de trabajo en modo automático / semiautomático para reducir los avisos constantes de permiso.
  • Desacuerdo:
    • Algunos dicen “nunca omitas permisos” fuera de un sandbox; otros dicen que un sandbox estricto + autonomía total es mejor que aprobaciones interminables.

Calidad del código, pruebas y revisión

  • Amplio acuerdo en que:
    • El código generado por IA debe revisarse; las pruebas y CI son cruciales.
    • Múltiples pasadas de IA (planificación, implementación, revisión, análisis de seguridad) más la revisión humana funcionan mejor que la generación de una sola pasada.
    • Usar un modelo para revisar el código de otro puede detectar más problemas que la auto-revisión.

Capacidades del modelo e “inteligencia”

  • Vistas divididas sobre la capacidad:
    • Algunos dicen que los modelos punteros actuales rivalizan o superan a muchos ingenieros de nivel staff en muchas tareas; otros los encuentran débiles en problemas difíciles (concurrencia compleja, sistemas grandes de múltiples servicios).
  • Larga subdiscusión filosófica sobre:
    • “Predictor del siguiente token” vs inteligencia real; razonamiento humano vs del modelo; justificaciones post hoc y “mentir”.
    • No hay consenso; varios señalan que lo que importa es la fiabilidad práctica, no las etiquetas.

Impacto en la práctica del software

  • Algunos temen un futuro en el que los humanos ya no comprendan las bases de código y la IA las “conduzca”; otros ven eso como inevitable para muchos dominios, pero no para sistemas críticos para la seguridad.
  • Varios destacan que la IA es más efectiva cuando los humanos se centran en la arquitectura, las especificaciones y las pruebas, y dejan que los modelos hagan más de la implementación rutinaria, con revisiones lo bastante estrictas como para mantener la comprensión.