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⁺]

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