Ask HN: ¿La programación agéntica realmente funciona?

• He intentado usar programación con agentes, pero me está volviendo loco la brecha entre lo que veo en línea y los resultados que realmente obtengo al implementarlo; ¿hay evidencia de que de verdad produzca resultados positivos?
• Más allá del hype exagerado, si alguien ha implementado con éxito la programación con agentes, por favor comparta en detalle cómo lo hizo
• "Implementarlo con éxito" significa algo como esto
  • Generar más valor que deuda técnica
  • Escribir código estructuralmente sólido al nivel que un responsable de arquitectura pueda aprobar
• Últimamente parece haber una tendencia a minimizar o incluso eliminar las revisiones de código, con el argumento de que hay que pasar de la "validación de arquitectura" a la "validación de funcionamiento"
• En la práctica, esto parece significar desplegar si pasa las pruebas y el CI sin mirar el código, y dudo que este enfoque pueda sostenerse a largo plazo

• En mi opinión, si usas Codex, puede funcionar en el camino feliz, pero es muy probable que termine convirtiéndose en código espagueti con errores sutiles y difíciles de depurar que se acumulan con el tiempo
• Cuando he aplicado Codex a una base de código existente, con o sin lineamientos definidos, la mitad de mi tiempo se va en corregir errores sutiles o código duplicado generado por Codex

• El fin de semana pasado intenté rehacer desde cero una app de iOS para recordatorios de comida de mascotas
  • Le pedí a Codex que primero investigara y propusiera un plano de arquitectura basado en SwiftUI, y redacté junto con Codex una especificación que explicaba qué había que implementar y cómo
  • La primera implementación tenía algunos bugs, pero inesperadamente no estaba mal; después de eso, todo se deterioró muy rápido
  • Durante el resto del fin de semana intenté que Codex funcionara correctamente, corrigiera errores sin crear nuevos bugs y estudiara buenas prácticas en lugar de escribir código al azar
  • Hice que Codex registrara cada nuevo lineamiento o regla que íbamos descubriendo, pero la situación no mejoró y al final me rendí
• Personalmente, me parece inaceptable desplegar código que no ha sido revisado
• Siento que algo anda mal. El producto tiene que funcionar bien, pero la calidad del código también debe ser alta

[GN⁺]

Opiniones de Hacker News

• Se está apostando muchísimo dinero a que los LLM sean la clave para la reducción de costos
  Incluso influencers o expertos conocidos a veces exageran para mantener una imagen de estar en la “vanguardia”
  Pero en la práctica, todavía no se ha establecido el mejor enfoque para el desarrollo basado en LLM
  En este momento, más que creer por fe, considero importante mirar directamente cómo funcionan por dentro

  • Hace poco también recibí una oferta de 200 dólares de una empresa para promocionar una nueva “agentic coding platform”
    Que este tipo de propuesta le llegue incluso a usuarios al azar significa que ya hay una campaña de marketing considerable en marcha
  • Los LLM sin duda son una herramienta de gran salto, pero no son la llave maestra para un desarrollo totalmente autónomo
    Son divertidos para tareas CRUD sencillas, pero en proyectos complejos más bien generan frustración
    Ahora mismo, con la competencia de benchmarks y el dinero de VC entrando a raudales, es una época en la que cuesta tener una discusión serena
  • Igual que cuando apareció por primera vez la GUI, creo que ahora estamos en una etapa de percibir su valor intuitivo
    Aún faltan pruebas cuantitativas, pero aunque los desarrolladores no vayan a desaparecer por completo, la forma de desarrollar ya cambió para siempre

• Un Principal Engineer de Google tuiteó que “Claude Code hizo en 1 hora algo que habría tomado 1 año”
  Pero después se supo que lo que la IA había hecho era solo una “versión de juguete”
  Este tipo de afirmaciones exageradas distorsionan las expectativas y terminan provocando decepción
  Enlace al tuit relacionado

  • Este tipo de tuits muchas veces se deben a presión interna para mostrar resultados del liderazgo en IA
  • Alguien reaccionó diciendo: “No tiene sentido decir algo así”
  • Otra persona señaló que “los resultados con IA dependen del nivel de experiencia y del costo de inversión”
  • También hubo reacciones escépticas diciendo que “la IA todavía solo entrega código que no se puede desplegar”
  • Incluso hubo quien ironizó diciendo que “esto representa muy bien a Google”

• Viéndolo en retrospectiva, en los últimos 6 meses sí obtuve una mejora de 10x en código de infraestructura (por ejemplo, Terraform)
  Pero el desarrollo de funcionalidades especializadas sigue siendo muy irregular
  Aun así, el tiempo que se ahorra al reducir tareas repetitivas permitió mejorar la calidad de pruebas y seguridad
  Y sobre todo, me devolvió el placer de programar

  • Yo también llevo 35 años haciendo desarrollo como hobby, y la IA me quita el tedio de teclear y potencia la creatividad
  • En mi caso también fui más del doble de rápido en scripts de build o tareas de CI, pero los proyectos complejos de HPC siguen siendo difíciles, y
    el enfoque más eficiente fue el de assisted coding
    Enlace al proyecto
  • Hice con Claude un buscador de archivos para el NAS de mi casa, y completé en un día un backend en Go con indexación automática diaria y una interfaz web
    Ese tipo de proyectos personales sí me parecen un verdadero game changer
  • Si divides el trabajo en partes pequeñas, los agentes funcionan muchísimo mejor
  • Aun así, la calidad del código de pruebas sigue siendo baja. Los propios datos de entrenamiento son débiles en escritura de tests

• Yo tuve mucho éxito con el enfoque de añadir agentes a una app existente
  Los agentes son débiles para diseñar arquitectura, pero funcionan muy bien en código ya estructurado
  Mientras más estricto sea el sistema de tipos y mayor sea la cobertura de pruebas, mejor resultado dan

  • Ahora mismo estoy experimentando con dejar que un proyecto en Rust sea gestionado y desarrollado directamente por un LLM
    El trabajo avanza con base en ROADMAP.md, TASKS.md y STATUS.md escritos por Claude, y
    sorprendentemente ya está terminado en un 20% aproximadamente
  • C# combina bien con agentes gracias a su compilador estricto y entorno basado en reglas
    En cambio, Python o JS son difíciles de confiar por su sistema de tipos débil
  • Mientras más ordenada esté la base de código existente, mejor rinden los agentes
    Empezar desde cero es difícil, pero si les das una especificación clara, la eficiencia sube
  • Go es fácil de manejar para los LLM por su lenguaje simple y patrones consistentes
  • Typescript es ideal para agentes gracias a su compilación rápida y sistema de tipos fuerte
    En cambio, el tipado opcional de Python más bien propaga errores

• Escribí al 100% con Claude Code un monitor en tiempo real de frecuencia cardíaca por Bluetooth para Linux
  Enlace al proyecto
  Está hecho en C puro, e incluso la interfaz web y los gráficos en tiempo real quedaron listos en un solo día
  Esta vez sí logré implementar con éxito la comunicación dBus–blueZ, que antes me había fallado

  • Pero cuando otro usuario revisó el código, vio que la implementación de SSE en realidad no funciona
    En la documentación dice SSE, pero internamente solo devuelve una respuesta HTTP normal
  • Otra persona señaló que “el código escrito por IA al principio se ve bien, pero poco a poco baja de calidad”
  • También hubo quien agradeció que se compartiera un ejemplo real así, valorándolo como un caso sin exageraciones
  • Hubo incluso comentarios preguntando por el diseño, diciendo que el estilo de la UI era interesante

• Yo uso Augment + Claude Opus 4.5 todos los días
  Casi no escribo código directamente, sino que termino proyectos mediante trabajo iterativo basado en especificaciones
  Lo más eficiente es correr varios agentes en paralelo y revisar sus resultados
  La clave está en redactar especificaciones claras y dar retroalimentación por etapas

  • No conozco bien Ruby, pero me ha ayudado muchísimo para desarrollar apps en Rails
    Se siente como el cambio más revolucionario en mis 30 años de carrera, y estoy convencido de que toda la industria va a cambiar
  • Alguien bromeó con que “llamar de tamaño medio a un proyecto de 1 semana es llamarlo pequeño”
  • Otra persona comentó que “esto no se parece tanto a desarrollo con agentes como a desarrollo colaborativo con LLM”
  • También hubo quien opinó que el desarrollo centrado en especificaciones (spec-driven) es la clave de la calidad en producción
  • Yo agrego una etapa en la que hago que Claude primero plantee preguntas para aclarar bien los requisitos
    Ahora mismo estoy trabajando con Claude en un proyecto de diccionario japonés–inglés
    GitHub, sitio web

• Como desarrollador con 20 años de experiencia, gracias a los LLM mis predicciones sobre tiempos de trabajo fallan por completo
  Lo que antes tomaba 2 semanas, ahora se termina en 2 días
  Sigue haciendo falta revisión de código e interacción, pero siento que es mejor que la mayoría de los desarrolladores humanos
  Conversar con un LLM se parece más a colaborar con un desarrollador senior, y
  mi experiencia de muchos años en revisión de código y reparto de trabajo me ayuda mucho

  • Alguien dijo que una mejora de velocidad de ese nivel era difícil de creer y preguntó por el tipo de problema
  • Otra persona comentó brevemente que “esperaba pruebas, pero no las hubo”

• El método más estable que he probado es darle a Claude unidades de trabajo pequeñas y claras
  Se repite el ciclo de planear, revisar, implementar y volver a revisar
  No es perfecto, pero resulta muy útil para desbloquear puntos atascados
  Aun así, como no sigue bien las guías, es indispensable verificar y ordenar todo manualmente

  • Yo también uso Claude de forma parecida al rubber duck debugging.
    Le asigno una sola función a la vez y, a partir del resultado, saco ideas mejores
  • Los LLM son especialmente potentes en documentación y análisis
    Pero cuando el problema está más centrado en diseño, las limitaciones se vuelven muy claras
  • Ante la pregunta de “dónde poner las guías”, recomendó incluir la información de build y test en CLAUDE.md

• Mucha gente malinterpreta la programación asistida por IA
  La IA no es un compañero de equipo, sino un ayudante
  La clave no es ver bugs o fallos como un fracaso, sino entenderlo como el proceso en el que un desarrollador experimentado ordena ese caos

  • Alguien preguntó: “Si requiere tanta mano, ¿en qué se diferencia del autocompletado del IDE?”
  • Otra persona preguntó si existe algún caso donde las técnicas más recientes hayan demostrado una mejora real en calidad
  • También hubo quien se burló diciendo que al final todo suena a “simplemente lo estás usando mal”
  • Y alguien bromeó: “Si esperabas que te hiciera una app perfecta mientras veías béisbol, no compraste una IA sino un mago”

• Yo también uso Claude todos los días, pero el código de pruebas generado por IA a menudo es un desastre
  En la práctica produce en masa tests sin sentido como expect(true).to.be(true)

  • Los modelos anteriores fallaban, pero vi una publicación sobre cómo los modelos más recientes generan código que pasa haciendo trampa
  • Por eso yo escribo y reviso primero los tests con un enfoque de TDD
    Si le encargas implementación y pruebas al mismo tiempo, aparece el problema de autoevaluarse con sesgo
  • Alguien dijo que “ya se rindió con escribir tests usando Claude”
  • Otra persona se rió diciendo que “esta es una solución demasiado humana”