Mi flujo de trabajo de generación de código con LLM

• tldr: Hago lluvia de ideas para la especificación, trazo un plan y luego ejecuto usando codegen con LLM. Bucle iterativo individual. Entonces ocurre la magia
• Estoy usando LLM para crear rápidamente varios productos pequeños. Es divertido y útil
• Pero si caes en un enfoque equivocado, puedes desperdiciar mucho tiempo
• Muchos desarrolladores tienen enfoques bastante parecidos entre sí, y abajo está mi flujo de trabajo

  "Ahora funciona bien, pero en dos semanas podría no funcionar o funcionar el doble de bien"

• Hay 2 maneras de desarrollar
  • Código greenfield: iniciar un proyecto nuevo
  • Código legacy modernizado: mejorar o extender una base de código existente

Greenfield: empezar desde cero

• Es un proceso que encaja bien en situaciones de “empezar desde cero”
• El flujo consiste en hacer lluvia de ideas, documentarlas, armar un plan pequeño paso a paso y luego usar herramientas de generación de código para implementarlo
• Paso 1: concretar la idea
  • Mientras explicas la idea a un LLM como ChatGPT, vas guiando preguntas una por una para refinarla hasta convertirla en una especificación concreta
  • Al final, generas una especificación detallada (spec.md) y la organizas como un documento que se puede pasar a un desarrollador
  • Si hace falta, también puedes obtener material de respaldo sobre la idea con herramientas como Deep Research
• Paso 2: planificación
  • Con base en la especificación, le pides a un modelo más potente de “comprensión y razonamiento” que genere un plano detallado por pasos
  • Ya sea con TDD o no, divides cada etapa en unidades de trabajo pequeñas y las ordenas en secuencia
  • Con este proceso generas prompt_plan.md y todo.md
    • prompt_plan.md contiene el diseño de prompts necesarios para la generación de código, y todo.md incluye la lista de verificación
  • Esta planificación normalmente toma unos 15 minutos y luego también es fácil de consultar
• Paso 3: ejecución
  • Uso varias herramientas de generación y asistencia de código como Aider, Cursor y Claude para escribir el código real
  • Como ejemplos representativos, se puede hablar de Claude y Aider
  • Método con Claude
    • Después de preparar de antemano la estructura del proyecto (boilerplate, etc.), metes los prompts por etapas en Claude
    • Copias y pegas el código resultante en el IDE y ejecutas pruebas
    • Si surge un problema, le pasas la base de código actual a Claude con una herramienta como repomix para depurar
    • Flujo de trabajo
      • Configurar el repo (boilerplate, uv init, cargo init, etc.)
      • Pegar el prompt en Claude
      • copy & paste desde claude.ai al IDE
      • Ejecutar el código, correr pruebas, etc.
      • …
      • Si funciona, pasar al siguiente prompt
      • Si no funciona, usar Repomix para enviar la base de código a Claude y depurar
      • Repetir el proceso (rinse repeat)
  • Método con Aider
    • En Aider también trabajo ingresando prompt_plan.md en orden
    • Soporta ejecutar pruebas automáticamente o encontrar y corregir errores
    • Si hace falta, resuelvo problemas mediante depuración interactiva
      • Configurar el repo (boilerplate, uv init, cargo init, etc.)
      • Ejecutar Aider
      • Pegar el prompt en Aider
      • Ver a Aider bailar ♪┏(・o･)┛♪
      • Aider puede ejecutar pruebas o correr la app para validarla
      • Si funciona, pasar al siguiente prompt
      • Si no funciona, corregirlo haciendo preguntas y respuestas con Aider
      • Repetir el proceso (rinse repeat)
• Resultados
  • Con este enfoque se pueden implementar en poco tiempo varios proyectos como scripts, apps de Expo o CLI en Rust
  • Si tienes proyectos grandes o pequeños que has estado posponiendo, recomiendo intentarlo
  • Tiene la ventaja de que puedes probar rápido mientras aprendes un nuevo lenguaje o tecnología

Non-greenfield: trabajo gradual/iterativo sobre código existente

• Es un método para aplicar tareas pequeñas de forma repetitiva sobre una base de código ya existente
• Más que un gran plan general, el flujo consiste en intercambiar solicitudes concretas y resultados por unidad de trabajo
• Asegurar el contexto
  • Puedes usar una herramienta como repomix para resumir la base de código y pasársela al LLM
  • Gestionas configuraciones repetitivas con mise y similares, y guardas el resultado resumido en un archivo llamado output.txt
  • Si la base de código es demasiado grande, ajustas el resumen para incluir solo las partes necesarias
• Ejemplo de flujo de trabajo
  • Con un comando como mise run LLM:generate_missing_tests, haces que el LLM identifique las partes con pruebas faltantes
  • Luego aplicas esas sugerencias (issues) con Claude o Aider, y vuelves a probar el resultado
  • Así vas mejorando gradualmente la base de código existente

Ejemplos de prompts principales

• Code review
  “Como desarrollador senior, revisa este código a fondo. Incluye números de línea y contexto. No hagas una revisión superficial; analízalo en profundidad”
  “You are a senior developer. Your job is to do a thorough code review of this code. You should write it up and output markdown. Include line numbers, and contextual info. Your code review will be passed to another teammate, so be thorough. Think deeply before writing the code review. Review every part, and don't hallucinate.“
• Generación de GitHub Issue
  “Como desarrollador senior, revisa el código y redacta los problemas principales en formato de issue de GitHub”
  “You are a senior developer. Your job is to review this code, and write out the top issues that you see with the code. It could be bugs, design choices, or code cleanliness issues. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“
• Pruebas faltantes
  “Como desarrollador senior, revisa el código y presenta de forma concreta las pruebas faltantes o necesarias“
  “You are a senior developer. Your job is to review this code, and write out a list of missing test cases, and code tests that should exist. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“

Esquiar ᨒ↟ 𖠰ᨒ↟ 𖠰

• Cuando escribes código muy rápido usando LLM, llega un punto en que la complejidad o el contexto se enredan y todo se vuelve confuso
• Ayuda volver a revisar los documentos de la etapa de planificación (por ejemplo, el proceso Greenfield) o tener pruebas bien organizadas
• Así como te mueves rápido, también es importante tomarte un descanso o darte un espacio para ordenar las ideas

Estoy muy solo (｡•́︿•̀｡)

• La mayoría de los flujos de trabajo basados en LLM están optimizados para el ‘modo solitario’
• Si intentas programar en equipo, los conflictos o problemas de merge se vuelven complejos
• Espero que evolucione un entorno colaborativo ‘multijugador’ donde varias personas puedan usar LLM al mismo tiempo

Tiempo

• Aunque la eficiencia al escribir código ha aumentado mucho con LLM, existe cierto ‘tiempo muerto’ por la espera del procesamiento de tokens
• Aprovecho ese tiempo para pensar otras ideas de proyectos, escuchar música o conversar
• Estoy viviendo una mejora enorme en mi productividad personal

Haterade ╭∩╮( •̀_•́ )╭∩╮

• Muchos amigos tienen una actitud de “malditos LLM, esto no sirve para nada”, y la verdad no le doy demasiada importancia a esa visión
• Claro, yo tampoco comparto esa postura, pero sí es cierto que hace falta una mirada escéptica
• Hay muchísimas razones para no gustar de la IA, y lo que más me preocupa es el consumo eléctrico y el impacto ambiental
• Aun así… “el código debe fluir”, eso sí… en fin
• Si quieres saber más pero no necesariamente convertirte en un programador cíborg, mi recomendación es: “no cambies de opinión y lee ‘Co-Intelligence: Living and Working with AI’ de Ethan Mollick”
  • Este libro explica muy bien las ventajas de los LLM sin exageraciones al estilo del capitalismo tecnolibertario anárquico
  • En lo personal me ayudó muchísimo, y también pude tener conversaciones mucho más profundas con amigos que lo leyeron
  • Lo recomiendo mucho

[devs5]

Parece que Co-Intelligence: Living and Working with AI de Ethan Mollick
se publicará en marzo con el título Dual Brain.

[kipsong133]

No sabía que existía algo como Repomix. Siempre lo estaba copiando y pegando cada vez... T_T

[chugue85]

¡Gracias!

[ahwjdekf]

¿El llm también aguantará los insultos que normalmente recibe otro desarrollador?

[aer0700]

Yo todavía uso los LLM más o menos como un Google avanzado o un Stack Overflow amable, pero supongo que tendría que pensar si hay maneras de sacarles mejor provecho.
Para mí, claro que cómo se hace también es importante, pero parece que también es importante pensar junto con la IA por qué funciona. Los LLM son útiles cuando buscas documentación técnica antigua o estándares de antes.

[GN⁺]

Opiniones en Hacker News

• Los LLM son una herramienta para crear rápidamente prototipos de proyectos nuevos. Sin embargo, al hacer cambios en código existente o en proyectos maduros, tienden a aumentar la complejidad o a agregar frameworks innecesarios por falta de contexto. Los LLM no sustituyen la comprensión del código.

• Al colaborar con un LLM, es importante construir contexto mediante preguntas. Esto es más efectivo que intentar construir el contexto de forma directa.

• Últimamente, se ha estado probando el mob programming con LLM. Un LLM se encarga de la implementación y otro critica y propone mejoras.

• Es preferible no agregar frameworks demasiado opinados al proyecto. Esto aumenta el tamaño del contexto que el modelo debe reconocer. Por ejemplo, en vez de usar Plasmo, se le deja al LLM la configuración de una extensión de navegador.

• Me gustaría escuchar experiencias de personas que empezaron con el chat de Cursor y evolucionaron hacia un flujo de trabajo mejor. Me pregunto si el tiempo invertido en planificar fue útil, si disminuyeron las alucinaciones y si en general ahorraron tiempo.

• Este artículo explica cómo usar correctamente los LLM. Muchas personas no practican lo suficiente cómo comunicarse eficazmente con los modelos de lenguaje. El autor ha dominado la comunicación con los LLM, y este flujo de trabajo maximiza la eficiencia.

• Para maximizar la eficiencia en un flujo de trabajo con LLM, se necesita escribir rápido, buen criterio y familiaridad con las fortalezas y debilidades de cada modelo.

• Las herramientas de programación con LLM son divertidas, pero para comprobar si realmente ayudan hay que establecer objetivos concretos y fechas límite. Es muy probable que los LLM fallen bajo esas condiciones.

• Muchos programadores junior olvidan la parte de especificación y plan de ejecución de la programación. Para usar con éxito un LLM, hay que hacer que genere la especificación y el plan de ejecución.

• No entiendo las expectativas sobre Claude. En preguntas sobre Apache Spark hubo muchas alucinaciones. Quisiera entender por qué Claude sería mejor que otros modelos.

• Para un desarrollador individual puede estar bien, pero varias instancias de LLM analizando la misma base de código en un equipo no son económicas y pueden ser riesgosas. Me pregunto si existe algún producto que proporcione un contexto centralizado para equipos.