El bucle que viene

Artículo original ↗ Discusión en Hacker News ↗

Sentimiento general

  • La discusión está dividida entre el entusiasmo por los “bucles” (flujos de trabajo de codificación agéntica) y la profunda preocupación por la calidad del código, la mantenibilidad y el agotamiento de los desarrolladores.
  • Muchos coinciden en que la publicación es una de las posturas más claras y matizadas, pero rechazan su tono de “este futuro es inevitable”.

Bucles, agentes e “inevitabilidad”

  • Quienes apoyan los bucles ven los modelos actuales como los primeros “coches” que aún no han alcanzado la “velocidad de autopista”; expectativas como “startups de mil millones de dólares de una sola persona” se consideran prematuras, pero plausibles en la dirección general.
  • Los escépticos sostienen que esta analogía es mala: los coches Mach 1 nunca fueron un objetivo real de producto, mientras que las empresas de mil millones sí lo son; ven los bucles como impulsados por marketing y muy dependientes de subsidios.
  • Algunos rechazan el “no puedes quedarte al margen”: tú puedes evitar usar agentes por tu cuenta, pero no puedes impedir que atacantes, directivos o colegas los usen.

Calidad del código, invariantes y “slop”

  • Hay un fuerte consenso en que el código generado por LLM actuales tiende a: ser excesivamente defensivo, añadir soluciones alternativas ad hoc, duplicar lógica y evitar invariantes y tipos claros.
  • La gente ve patologías sistemáticas: comprobaciones excesivas de null, valores por defecto arbitrarios, manejo de estados imposibles y aumento de LOC en cada iteración.
  • Varios atribuyen esto al entrenamiento con código mediocre y al RL que penaliza en exceso los errores en tiempo de ejecución, recompensando un manejo de errores “a escopetazo”.
  • Algunos tienen éxito parcial mediante:
    • Forzar arquitecturas sólidas (hexagonal, límites estrictos entre módulos).
    • Usar pruebas y listas de verificación como “oráculos” del bucle.
    • Tener un segundo modelo “juez” que revise DRY, estilo y reglas de diseño.
  • Incluso los defensores dicen que la refactorización totalmente agéntica y los grandes bucles sin supervisión son peligrosos para la calidad en este momento.

Rol humano, comprensión y flujo de trabajo

  • Muchos insisten en que no deberías delegar decisiones ni código que “te importe profundamente”; los bucles solo son aceptables para tareas bien especificadas, de bajo juicio o desechables.
  • Un tema recurrente: no puedes saltarte la fase humana y desordenada de averiguar qué quieres realmente; los bucles solo pueden aprovechar la claridad, no crearla.
  • Otros describen flujos de trabajo en los que escriben especificaciones detalladas, usan agentes para implementar y luego hacen una revisión humana estricta del PR y refactorizaciones dirigidas.
  • Hay debate sobre si la comprensión de la base de código se atrofiará si los humanos se convierten en meros orquestadores; algunos lo ven inevitable, otros como una línea que no cruzarán.

Psicología del desarrollador y trayectorias profesionales

  • Varios desarrolladores veteranos dicen haber perdido la alegría de programar; los proyectos paralelos parecen inútiles frente a la producción acelerada por IA, como “transcribir una guía telefónica junto a una fotocopiadora”.
  • Otros dicen que los LLM reavivaron su interés al reducir la fricción para pequeñas herramientas y experimentos.
  • Un subconjunto está planeando activamente dejar la programación (por ejemplo, hacia la diplomacia, las relaciones internacionales, trabajos no tecnológicos) debido a la “carrera de ratas” impulsada por la IA y la cultura del slopware.

Economía, presión organizacional y adopción

  • Algunos equipos pequeños informan grandes ganancias de productividad y mejores métricas de desarrollo usando agentes; otros señalan facturas de tokens de cientos a miles por mes y cuestionan el ROI a largo plazo frente a contratar personal.
  • Hay preocupación de que el entusiasmo actual se sostenga con precios de tokens subsidiados; si los costos subieran 5–10x, muchas organizaciones podrían reducir el uso de bucles.
  • Varios comentarios describen a la dirección y a los inversores empujando mandatos “AI-first”, normalizando PRs de 10k líneas y desalentando la revisión cuidadosa o el escepticismo; los intentos de documentar desventajas han sido etiquetados como “retórica anti-IA”.

Seguridad, responsabilidad y mantenibilidad

  • Los comentaristas señalan que atacantes e investigadores de seguridad usarán bucles para fuzzing a gran escala y búsqueda de exploits; los mantenedores no pueden “optar por no” ser objetivo.
  • Otros sostienen que no se puede confiar verdaderamente en los agentes porque carecen de identidad duradera y personalidad jurídica; los humanos siguen cargando con toda la responsabilidad por los fallos.
  • Algunos prevén bases de código que en la práctica solo podrán ser mantenidas por LLM; otros insisten en que la mantenibilidad sigue importando porque los cambios futuros y la depuración siguen siendo costosos, independientemente de quién o qué escriba el código.