Ask HN: ¿Está experimentando alguien con diferentes formas de usar LLMs para programar?

Discusión en Hacker News ↗

Programación guiada por especificaciones vs. programación agéntica/orquestada

  • Muchos sostienen que la mayor mejora proviene de especificaciones más claras, no de una orquestación compleja: una sola intención, contratos de entrada/salida explícitos, restricciones y precondiciones, además de una clarificación progresiva.
  • Algunos prefieren un uso de “lienzo en blanco”: memoria de largo plazo mínima o nula para evitar la “putrefacción del contexto” y la dilución de la intención; usan Markdown/docs externos que el modelo puede buscar.
  • Las “skills” (instrucciones y herramientas estrechas y reutilizables) se consideran infravaloradas; los “agents” ayudan sobre todo con la gestión del contexto y las restricciones.
  • Otros reportan éxito con equipos multiagente, flujos de trabajo basados en grafos y modelos con roles fijos (baratos para la mecánica, fuertes para la planificación/revisión), pero reconocen altos costos en tokens y complejidad.

Estado de flujo y experiencia humana

  • Queja común: la interacción tipo chat y la espera rompen el flujo; los usuarios sienten que son gerentes supervisando a un dev junior en vez de estar programando.
  • Algunos recuperan el flujo mediante:
    • Hacer un trabajo profundo de planificación/especificación y luego dejar que los agents corran sin supervisión, revisando después.
    • Usar herramientas estilo programador en pareja donde la persona lleva el mando y la IA asiste en pequeños incrementos.
    • Ejecutar múltiples tareas/agents en paralelo y tratar la “orquestación” en sí como la actividad de flujo.
  • Otros sienten que alternar entre muchos agents es agotador, no induce flujo.

Flujos de trabajo prácticos y harnesses

  • Patrones frecuentes:
    • Flujos centrados en issues/PR donde los LLMs implementan tickets, generan planes e iteran mediante comentarios.
    • Documentos de tres niveles (filosofía → especificación → diseño) antes de generar código.
    • “Workboxes” / sandboxes por funcionalidad con ramas automatizadas, PRs e instancias de prueba desplegables.
    • Agents herméticos: generar por separado código y tests a partir de la misma especificación para evitar sesgo de confirmación.
  • Los harnesses personalizados abarcan terminales, sandboxes basados en navegador, motores DAG/grafo y VMs/contenedores locales, a menudo con permisos y tooling estrictos (por ejemplo, bucles de búsqueda de bugs, sandboxes de seguridad).

Autocompletado, pairing e integración con el editor

  • Gran interés en flujos centrados en el editor: autocompletado inline, completado de ediciones, múltiples conversaciones ancladas por región de código y terminales donde los agents trabajan en paneles paralelos.
  • Algunos creen que el harness de autocompletado y la UX son más importantes que exprimir modelos ligeramente mejores.

Aprendizaje, calidad y seguridad

  • Preocupa que la programación totalmente agéntica perjudique la comprensión y el aprendizaje, especialmente para juniors; como alternativa, se propone que el LLM produzca documentos instructivos detallados o actúe como tutor/revisor.
  • Muchos insisten en usar LLMs para mejorar la comprensión humana (diagramas, resúmenes, explicaciones) porque ahora el cuello de botella es la comprensión humana del código.
  • La seguridad y los guardrails son temas recurrentes: agents aislados en sandbox, herramientas restringidas y comprobaciones/tests automáticos entre iteraciones.