Usar IA para escribir mejor código, más lentamente

• La programación con IA no solo sirve para generar grandes cantidades de código de baja calidad con rapidez, sino también para revisar PR a fondo y producir código de alta calidad más lentamente
• Los agentes LLM son fuertes en la detección de bugs dentro de una base de código, pero la dificultad real está en priorizar y validar los hallazgos
• Una skill de Claude que usa varios modelos combina Claude sub-agent, Codex y Cursor Bugbot para revisar PR y elaborar un informe final que reduce los falsos positivos
• El flujo de trabajo consiste en corregir de forma iterativa los problemas critical/high, omitir los elementos con baja relación costo-beneficio y abandonar el PR si hay demasiados problemas críticos
• Este enfoque prioriza la salud de la base de código por encima de la velocidad y refuerza una programación cuidadosa que entiende los modos de fallo y los bugs existentes

---

Una forma más lenta de usar IA para programar

• La idea de que la programación con IA solo sirve para generar rápidamente grandes volúmenes de código de baja calidad subestima la flexibilidad de los LLM
• Los LLM pueden usarse no solo para generar código rápido, sino también para escribir código de mayor calidad más lentamente
• A diferencia de enfoques como slop cannons, que lanzan enormes PR sin validar, también es posible revisar los PR con mayor profundidad e insistir en verificar sus posibles fallas

Validación y priorización: más importantes que detectar bugs

• Mythos muestra que los agentes LLM pueden encontrar bugs muy bien dentro de una base de código
• En otros casos, modelos que no son Mythos también pueden encontrar muchos bugs en bases de código no revisadas
• Los modelos públicos más recientes de Anthropic y OpenAI difieren en su capacidad para detectar bugs sutiles y evitar falsos positivos, pero pueden encontrar una cantidad suficiente de bugs
• La dificultad real no está tanto en descubrir bugs como en la priorización y la validación

Una skill de Claude que revisa PR con varios modelos

• Un enfoque de revisión de código con IA que compara y hace debatir a varios modelos se centra en que, mientras más modelos distintos se incorporan, menor es la probabilidad de alucinaciones o reportes erróneos de bugs
• La skill de Claude en uso ejecuta Claude sub-agent, Codex y Cursor Bugbot para revisar PR
• Cada herramienta clasifica los bugs del PR como critical/high/medium/low y luego se integran los resultados para crear un informe final eliminando falsos positivos
• El alcance de lo que se considera un “bug” puede ampliarse según los criterios del proyecto
  • Violaciones de los principios KISS y DRY
  • Si el HTML/JSX está escrito con accesibilidad
  • Si las consultas SQL usan los índices adecuados
  • Otros criterios de calidad específicos del proyecto

Flujo de trabajo real y criterios de decisión

• Este enfoque puede encontrar muchos bugs en un PR y también reducir la tasa de falsos positivos casi a 0
• Los problemas encontrados van desde bugs críticos relacionados con seguridad o corrección, hasta problemas de rendimiento o cuestiones de baja severidad como “este comentario induce a error”

• Flujo de procesamiento general

  • Se hace que el agente corrija los problemas con clasificación critical y high, mientras que una persona orienta la solución adecuada
  • Se repite hasta que ya no queden problemas critical/high
  • Se omiten los problemas high/medium cuyo beneficio no justifica el costo de corregirlos
  • Un caso típico es cuando se necesitan 100 líneas de código para corregir un edge case muy limitado
  • Si hay demasiados problemas critical y se concluye que el enfoque completo está mal planteado, se abandona el PR

Enfocado en la salud de la base de código más que en la productividad

• Esta técnica no necesariamente acelera el desarrollo
• Durante la revisión pueden descubrirse bugs preexistentes que ya estaban antes del PR, lo que puede llevar a escribir pruebas unitarias y corregir defectos sutiles
• Se parece casi al opuesto del estilo de desarrollo de “productividad 10x” que suele asociarse con el “vibe coding”
• En arquitecturas complejas, los modos de fallo pueden ser más interesantes que el camino feliz, y entender y corregir esos puntos de fallo puede convertirse en una forma de conocer mejor la base de código
• Es útil para mejorar la salud general de toda la base de código mientras se aprenden rincones poco conocidos de ella

Cómo practicar un vibe coding lento

• Si eres un desarrollador que usa agentes para crear PR de cientos de líneas que ni tú mismo entiendes por completo, podrías probar un enfoque más lento
• Puedes preguntarle al agente cómo funciona el PR y en qué puntos podría fallar
• Si hace falta, puedes pedirle que escriba documentación en Markdown con Mermaid charts
• Puedes usar la skill Matt Pocock /grill-me hasta que entiendas el PR de principio a fin
• La “productividad” medida por líneas de código puede no aumentar, e incluso podrías gastar muchos tokens para terminar concluyendo que el plan inicial estaba mal
• Este enfoque se parece más a una versión reforzada de la programación cuidadosa, sistemática y obsesionada con la calidad que ya se buscaba incluso antes de los LLM

[GN⁺]

Comentarios de Hacker News

• Al trabajar con AI, esto ya no es un proceso simple de una sola pasada, sino un largo bucle de revisión de ida y vuelta
  Para funciones de tamaño medio que abarcan varias áreas, primero uso AI para definir el diseño de implementación y revisar los detalles; luego implemento con Claude 4.7 Max, que es lento pero da buenos resultados
  Después reviso la implementación y le pido otra revisión a Codex GPT 5.5 xhigh fast, que casi siempre encuentra casos límite. Dejo que Claude haga las correcciones: Codex es fuerte para detectar bugs y revisar, pero su código tiende a sobrearquitecturarse o a mezclar atajos, mientras que Claude suele escribir código más intuitivo y mantenible
  Luego vuelvo a revisar los cambios staged con nuevas instancias de Claude/Codex, incorporo el feedback y hasta agrego tests. Sigue siendo más rápido que escribirlo manualmente, pero la mayor parte del tiempo se va en revisión y manejo de casos límite, y al final una funcionalidad v1 ya se siente como una implementación tipo v3 tras varias iteraciones

  • Me funciona bien esa etapa de discutir el problema con la AI hasta el cansancio antes de implementar
    Se siente productivo, la salida de la AI mejora, y normalmente sigo entendiendo el código. Después de pasarme todo el día discutiendo diseño y arquitectura con robots, siento que justo ahí es donde la revolución de la AI me ha hecho mejor ingeniero
  • Lo veo exactamente así. Demasiada gente le pide a la AI que haga tareas complejas de una sola vez y luego se sorprende de que actúe como un junior al que apuraron
    Mi método es hacer 5 rondas de investigación/planificación/plan de pruebas, y yo entro al loop en cada decisión importante. Empiezo por la forma general y voy bajando al detalle; solo la planificación puede tomarme 2 o 3 días, y el agente de implementación (Opus 4.7) puede tardar varias horas
    La implementación se divide en varias etapas/commits y cada etapa tiene su propio loop de correcciones de code review. La revisión profunda final también puede tomar 1 o 2 horas; cuando abro el PR, Gemini lo revisa y yo leo eso para resolverlo
    El proyecto igual tarda varios días o semanas, pero sigue siendo 5 veces más rápido que hacerlo todo yo solo
    Extra: esa skill está en https://github.com/scosman/vibe-crafting
  • Mi flujo al programar con AI es bastante parecido, pero incluso haciéndolo bien muchas veces termina tomando un tiempo similar a escribirlo yo mismo
    En algunos casos tiré a la basura lo que hizo la AI y simplemente lo hice yo. Creo que esta es una habilidad que la gente tiene que aprender: en cierto punto hay que saber cuándo cortar por lo sano. Sobre todo en cambios simples, he visto colegas seguir discutiendo con un LLM para intentar obligarlo a hacer algo
  • Un enfoque parecido, pero primero dejo configurada una arquitectura manual básica / contratos de alto nivel / stubs para que quede alineado de forma consistente con los demás sistemas y también sea fácil de leer
  • Entonces, ¿cuando Anthropic se cae simplemente te tomas un café y esperas?
    A cambio de ir un poco más rápido mientras atiendes a varias AI, ¿no terminas perdiendo conocimiento y control sobre lo que hizo la AI?

• El artículo sobre hacer que los LLM critiquen mutuamente su code review[1], la herramienta magpie[2], y el post reciente de Cloudflare sobre su stack de code review con AI[3] resultan bastante convincentes
  Yo soy escéptico con la AI, pero más por si “es buena para el mundo” que por si “funciona”. Este tipo de trabajo de revisión se siente, rara vez, como un caso donde no se terceriza el pensamiento ni se degradan las capacidades del trabajador. No me dispara las mismas alarmas que dejar que la AI escriba código, o que una AI arregle problemas encontrados por otra AI. Claro, los problemas ambientales y otras preocupaciones éticas siguen siendo grandes
  Últimamente me ha impresionado la calidad del code review con AI, pero la experiencia de interactuar por separado con 3 revisores de AI en un PR de GitHub es horrible. Me gustaría una ronda de revisión más local-first y que entienda jj/rebase
  Contexto: un backend bastante grande en PHP/Laravel y frontend en Vue
  [1]: https://milvus.io/blog/ai-code-review-gets-better-when-model...
  [2]: https://github.com/liliu-z/magpie
  [3]: https://blog.cloudflare.com/ai-code-review/

• En promedio, el tiempo que invierto en loops de revisión/corrección con LLM es mayor que el de escribir código directamente a mano
  En parte porque cuando entro en ritmo escribo código muy rápido, y a veces termina saliendo incluso más rápido de lo que esperaba. Además, lo que entrega un LLM en los primeros intentos suele ser bastante malo
  Aun así, lo interesante es que, si yo lo reviso directamente y le pido varias rondas de revisión y corrección, en promedio el resultado termina teniendo una calidad más alta que el código que yo habría escrito en ese mismo tiempo. Al ver repetirse varias veces código hecho por otro, siento que termino entendiendo de forma más global el objetivo que quiero alcanzar, más que con algo que salió de golpe en estado de flow

  • Si la AI escribe mal código, entonces hay que cambiar de AI. Una AI avanzada actual no debería producir mal código

• Este artículo no trata de escribir código con AI, sino solo de code review
  El problema que tengo con la programación agentic es que, al programar, uno toma muchísimas decisiones microarquitectónicas. Casi nunca existe una especificación completa desde el inicio; la vas construyendo mientras ves lo que escribes
  Cuando uso Claude Code o Codex, ese proceso desaparece. Claude Code tiene un impulso demasiado fuerte por llegar al objetivo, así que la experiencia de programar con él se siente como un sueño febril. Al final terminas con menos confianza sobre los casos límite o sobre qué tan bien encaja con la arquitectura y los objetivos de diseño del proyecto
  Además, a mí me gusta programar, hacer reverse engineering, etc. Aunque un LLM pueda resolver un problema o entregar una funcionalidad, siento que también me quita esa diversión. Estoy intentando encontrar un flujo que pueda usar con confianza, pero me preocupa que al final ese flujo quede reducido a chat, búsqueda, y a que haga de rubber duck para mis ideas

• Por otro lado, algunas empresas están empujando la idea de que los agentes escriban la mayor parte del código de producción, fortaleciendo un pipeline de agentes de autoevaluación donde los ingenieros meten retroalimentación humana en el loop
  El CEO de Creao dijo en enero de este año que re-arquitecturó todo el sistema de producción en solo 2 semanas. También afirmó que los agentes implementaron demasiadas funcionalidades demasiado rápido, al punto de que tuvieron que esperar a que desarrollo de negocio se pusiera al día
  Me pregunto cómo se podría evaluar la opción de multiplicar la producción por 100 con IA frente a la opción de usar IA para desarrollar tus propias habilidades
  Por otro lado, el aumento de productividad por IA es real. Por ejemplo, una organización de ingeniería de Snowflake cumplió antes de tiempo todos sus OKR en el primer trimestre por primera vez en la historia de la empresa. Normalmente, alcanzar el 70% de los OKR planeados ya se consideraba un buen resultado, así que me imagino el estrés que deben sentir los ingenieros al ver algo así

• El título de este texto hacía pensar que tendría más profundidad, y esperaba ver ejemplos de código reales
  Pero se parece a otro texto de opinión. Básicamente propone prompts que le funcionan al autor, como pedirle a la IA que encuentre bugs, y recomienda que todos hagan eso
  Uso estas herramientas tanto en el trabajo como en proyectos personales, así que esperaba verlo y aprender, pero ya hay demasiados textos de opinión sin ejemplos

  • Me pregunto si probaste directamente el flujo que propone. A mí me parece un flujo útil, y si no hubiera encontrado ya algo parecido, habría agradecido una pista así
    El autor podría construir o improvisar un harness de código para esto, pero ahora mismo esa instrumentalización parece estar más cerca de tu terreno como practicante. Si quieres automatizarlo para experimentar, probablemente sea más rápido especificar tú mismo lo que quieres que lidiar con su código, honestamente

• Mientras leía esto, estaba trabajando en una funcionalidad bastante compleja, y necesité bastante iteración
  El resultado final terminó siendo mucho menos código que el que tenía a la mitad del proceso. Por eso me pregunté si la IA realmente ayudó, porque en el tiempo que invertí iterando quizá también habría podido escribir el código yo mismo
  Pero gracias a la IA pude armar rápidamente, de manera aproximada, 4 variantes de funcionalidad que no me convencían, y descartarlas con la misma rapidez sin que doliera

  • Uno de los mayores avances que he obtenido usando IA es justamente ese
    Antes tenía que pensar muchísimo la planificación antes de empezar a implementar una función nueva, y muchas veces solo descubría que no encajaba bien con el código existente después de haber escrito bastante implementación. Ahora puedo pedirle a la IA un plan de implementación detallado y detectar esos pequeños problemas en cuestión de horas, o incluso menos
  • Entonces, ¿la conclusión? ¿Valió la pena?

• Algo que me ha parecido interesante en los últimos años ha sido seguir el rastro de los límites de mi pereza para programar
  Como programador, odio el código boilerplate. No me gusta escribirlo ni mantenerlo. Por eso solía orientar el diseño y la arquitectura alrededor de esa preferencia; a veces era una decisión inteligente y a veces no. En cualquier caso, era mi preferencia, y evitaba las cosas que me costaba hacer
  Hace unos años, cuando los LLM empezaron a ser medianamente útiles para programar, me di cuenta de que eran muy buenos justamente para el boilerplate y que, hacia 2023, era casi lo único que hacían bien. Eso me hizo pensar en cuánto entendimiento implícito y cuánta consideración hemos tenido al diseñar sistemas y arquitecturas alrededor de las fortalezas y debilidades de las personas con las que trabajamos
  Los modelos más recientes tienen fortalezas y debilidades muy distintas a las de los humanos, y asignarlos bien es un ejercicio interesante que requiere otro tipo de arquitectura y habilidades de ingeniería. Me está gustando hacerlo y espero seguir así

  • El boilerplate se vuelve opcional o se genera automáticamente cuando hay una buena librería o framework
    Es mucho mejor obtener una salida determinística con django-admin startproject, npm init, meteor create que lanzar un prompt a un LLM sin saber qué va a salir
    En ecosistemas web maduros, el boilerplate se minimiza. Ahora que esta tarea se la estamos pasando a los LLM, me preocupa que disminuya el esfuerzo de desarrollo por crear CLIs tipo startproject y buenos valores por defecto

• Me gusta. Yo también uso un enfoque parecido de ralph-loop
  Empiezo con un plan aprobado, se lo paso a un coordinador y, simplificándolo, lo proceso en 2 sesiones: build y review, con un modelo distinto para cada sesión

• El obstáculo para mí al usar agentes de programación es que dependen de servicios externos de pago
  ¿Hay algún modelo local suficientemente bueno como para usarlo programando?

  • A estas alturas del mes, se menciona mucho Qwen3.6 (27B o 35B-A3B) o Gemma 4
    Esto también puede ayudar: https://hnup.date/hn-sota
    Los modelos de Qwen han sido mis modelos de uso diario esta semana

[GN⁺]

Opiniones en Lobste.rs

• En mi trabajo ya abandonamos el sueño de avanzar más rápido con IA. En nuestro caso, programar no es el cuello de botella
  Aun así, lo bueno de los agentes de código es que te permiten trabajar como el ingeniero que siempre quisiste ser
  Por ejemplo, crear un buen harness de pruebas que te permita empujar un poco más el código, agregar una etapa de CI que verifique si el código generado coincide con el original, y monitorear correctamente el despliegue de cambios
  Antes eran cosas que no entraban en el calendario porque había que leer el manual de GitLab CI, aprender a ajustar las condiciones y descifrar la forma enredada en que lo hacemos en la empresa, pero ahora sí es posible, y creo que ese es el futuro

• Me ha ido bastante bien usando los LLM como un compañero de exploración que conoce la API o como un dispositivo de refactorización mecánica, especialmente en lenguajes con tipado fuerte. También sirven para escribir pruebas, pero hace falta un proceso por capas para confirmar que esas pruebas realmente tengan poder de restricción
  El mutation testing ayudó bastante, y como sugería el artículo original, también hacen falta varias rondas de revisión
  Antes era mucho más negativo con los LLM, y mirando atrás, hasta de una forma irracional, pero en gran parte era por el software de baja calidad que los LLM solían escupir
  Cuando me metí de lleno, vi que lo correcto era tratarlos como una herramienta de prototipado de cartón y como un mecanógrafo mucho más rápido. Por ejemplo, si le pides “encuentra este patrón y cámbialo por este otro en todos los teoremas de este proyecto Lean, y marca los casos donde no funcione de inmediato para darme la lista restante”, te corrige más de 100 teoremas por bloques en el tiempo en que yo apenas estaría armando uno o dos primeros intentos mezclando vim, sed, awk y parches improvisados
  Lean funciona especialmente bien para esto porque, por las características del lenguaje y el tipo de trabajo que hago, la distancia entre “compila” y “funciona” es pequeña, y en Rust siento algo parecido si le sumas una buena suite de pruebas y mutation testing
  La larga cola de estas herramientas no es “aprietas un botón y sale un producto”, sino que un buen ingeniero las adopte para concentrar su energía en lo importante y delegar a la máquina buena parte del trabajo rutinario de antes

  • Yo también veía los LLM muy negativamente al principio, pero ahora creo que ya mejoraron hasta el punto de ayudar más de lo que estorban
    El ejemplo me parece interesante: antes, cuando trabajaba en un equipo de frameworks de JavaScript, yo mismo escribía codemods para tareas como upgrades o migraciones. Era el trabajo pesado de modificar ASTs
    Hoy probablemente se lo dejaría a un LLM y creo que llegaría a cubrir como el 90%

• Me gusta esta perspectiva. Parece obvio que la herramienta es flexible y que no necesariamente tiene que producir resultados de baja calidad, pero tanto quienes están a favor como quienes la rechazan suelen ignorar esa idea
  Todavía no he probado hacer code review con LLM, pero debería ponerlo en mi lista. Hasta ahora lo uso para generar ideas y para ayudar con SQL o VimScript, y el código lo escribo yo mismo
  Un riesgo es que hacer code review también es una habilidad, así que si dependes demasiado del modelo esa capacidad puede atrofiarse. Aunque en entornos comerciales, incluso el mejor code review suele ser una combinación de “tiempo razonable” y “¿confío en esta persona?”, no algo cercano a la precisión matemática

  • Eso también es cierto, pero yo sentí que este flujo de trabajo en realidad fortalecía mi capacidad de hacer code review. Porque tienes que juzgar si un “bug” realmente es posible o solo teórico, si vale la pena corregirlo o si conviene dejarlo para el siguiente PR
    Los bugs complejos prefiero pensarlos yo mismo hasta el final porque 1) las alucinaciones todavía se cuelan, y 2) de todos modos vale la pena entender el sistema de punta a punta

• Hablando en meta, no entiendo los flags que le pusieron a este post. Me parece raro que tenga 1 por fuera de tema y 3 de spam
  El post que está hasta arriba de la portada también trata sobre usar LLM, y como es sobre escritura en general, hasta parece menos relacionado con el tema que este, que sí está enfocado en programación, pero al parecer no tiene flags

  • Probablemente le pusieron flags de spam por verlo como autopromoción

• Es refrescante ver una perspectiva así en Lobsters. La actitud anti-IA generalizada ya empieza a cansarme. Creo que todos podemos estar de acuerdo en que a nadie le gustan los resultados de baja calidad
  Pero quienes optaron por boicotear por completo la IA y tomar una postura dogmática van a tener más dificultad para aceptar el futuro que quienes eligieron una actitud más práctica
  Desde el principio he dicho que la IA se parece a la invención de las herramientas eléctricas. Si quieres cambiar una llanta con una llave manual, está bien, pero cuando apareció el taladro de impacto los mecánicos no lo boicotearon. En el contexto del texto quizá no es la mejor analogía, pero sigo pensando lo mismo
  He aprendido más usando IA que leyendo documentación, porque a la documentación no puedes hacerle preguntas cuando necesitas contexto adicional, explicaciones o ejemplos. También podrías decirle “construye algo y no te equivoques”, pero prefiero un enfoque lento para realmente aprender

  • Yo no he visto aquí una actitud anti-IA generalizada. ¿Puedes enlazar algún ejemplo?
    Lo que sí he visto son críticas a cambios hechos con LLM sobre millones de líneas de código de una sola vez y desplegados sin revisión humana. En concreto, casos como el hilo sobre el port de Bun de Zig a Rust
    Este post también critica eso