Recomendaciones para el coding agéntico

• Compartir casos de uso reales sobre agentic coding
• Usa principalmente el modelo Claude Code Sonnet y prefiere delegar el trabajo completo a la IA en lugar de integrarla con el IDE
• Go se recomienda especialmente para nuevos proyectos de backend gracias a su estructura amigable para agentes y la estabilidad de su ecosistema
• La velocidad y la simplicidad son la clave del agentic coding, y son importantes el caché de pruebas y un sistema de herramientas simple
• El código debe estar organizado de forma simple y paralelizable, y para maximizar el rendimiento de los agentes es muy importante elegir bien el momento del refactor

---

Preface

• Últimamente ha aumentado de forma acelerada la cantidad de desarrolladores que comparten su experiencia con el agentic coding
• Actualmente uso el modelo Claude Code Sonnet con el plan Max ($100/mes)
• El peso del IDE ha disminuido; en cambio, volví a usar Vim y trabajo delegando tareas a Claude y revisando solo los resultados
• Como la velocidad de innovación es muy alta y el contenido de esta publicación puede quedar obsoleto rápido, el enfoque está en conceptos que probablemente perduren

The Basics

• El comando claude --dangerously-skip-permissions está configurado con el alias claude-yolo para eliminar todas las restricciones de permisos
  • Esto permite gestionar el entorno de desarrollo de forma segura aislándolo con Docker
• Como Claude maneja bien la mayoría de las herramientas básicas, MCP(Multi Capability Protocol) se usa solo en casos especiales
  • Ejemplo: automatización del navegador mediante playwright-mcp
• Las herramientas hechas por uno mismo se componen como scripts normales y se procura mantener una configuración de herramientas lo más simple posible

Choice Of Language

• Tras experimentar con agentic coding en varios lenguajes, para nuevos proyectos de backend Go es lo más ideal
  • Sistema de Context: proporciona una estructura de datos que fluye claramente por todo el código, y facilita una forma explícita de pasar información al agente
  • Caché de pruebas: en comparación con otros lenguajes como Rust, la ejecución de pruebas y el caché son más simples, por lo que el ciclo código-prueba del agente es más eficiente
  • Simplicidad: la simplicidad propia de Go también juega a favor del agente
  • Interfaces estructurales: si un tipo cumple con los métodos, se reconoce como interfaz, lo que el LLM puede manejar fácilmente
  • Baja tasa de cambio del ecosistema: versiones duraderas y cambios explícitos reducen la generación automática de código obsoleto
• Python genera muchos problemas
  • Por fixtures, manejo de async y ejecución lenta, entre otros, su eficiencia baja en el agentic loop
• En frontend: Tailwind + React + Tanstack Query/Router + Vite
  • El símbolo $ en los nombres de archivo de Tanstack Router confunde al agente y causa problemas

Tools, Tools, Tools

• Los criterios para las herramientas son los siguientes
  • Ser rápidas
  • Proveer mensajes de error amigables
  • Seguir funcionando de forma estable incluso si el LLM las usa mal
  • Ser observables y fáciles de depurar
• Se ofrecen comandos como make dev, make tail-log, etc., basados en Makefile
  • Para evitar duplicación del estado de ejecución, se gestiona el pid con una versión fork de shoreman
  • Los logs se registran tanto en stdout como en archivos para que el agente pueda extraer información directamente de los logs
• Ejemplo: también se configuran los enlaces de verificación por correo para que queden registrados en los logs, de modo que sea posible completar el proceso de verificación de email con automatización del navegador

It's All About Speed

• La mayor ineficiencia del agentic coding es el costo de razonamiento y el uso ineficiente de herramientas
• La velocidad de respuesta de las herramientas es la clave de la productividad
• Cuando el agente crea y usa herramientas temporales por su cuenta, una ejecución/compilación rápida mejora enormemente la eficiencia del trabajo
• En entornos lentos conviene aprovechar alternativas como la carga dinámica de módulos (por ejemplo, vigilancia de módulos de archivos para Sentry y ejecución automática)
• Los logs deben ajustarse para ser concisos y claros a fin de optimizar el consumo de tokens y la velocidad; si hace falta, ayuda ofrecer una interfaz para que el LLM pueda ajustar el nivel de logs
• Es importante diseñar desde la etapa de generación de código para que se produzcan logs/observabilidad significativos

Stability and Copy/Paste

• La estabilidad del ecosistema es muy importante para la reutilización del código y evitar la confusión del agente
  • Se recomienda usar lenguajes y frameworks con pocos cambios y comportamiento predecible, como Go y Flask
• Cuidado con las actualizaciones automáticas de librerías, porque pueden romper los comentarios o el flujo de código que dejó el agente
• Siempre que sea posible, se recomienda la estrategia de escribir código directamente → minimizar dependencias

Write Simple Code

• Los agentes responden mejor a código simple y explícito
• Políticas recomendadas
  • Preferir funciones con nombres largos y descriptivos y escribir más con funciones que con clases
  • Evitar herencia y trucos complejos
  • Se recomienda usar SQL puro; el agente suele ser bueno con SQL y además es fácil comparar y rastrear con logs
  • Las verificaciones de permisos claras deben quedar expuestas de forma intuitiva en el código (no separarlas en archivos o configuraciones aparte)

Make It Parallelizable

• La velocidad de procesamiento de cada agente individual no es muy alta, pero la paralelización puede aumentar la eficiencia total
  • Ejemplo: copiar checkouts basados en el sistema de archivos
  • Hace falta pensar cómo separar recursos compartidos como Redis o la base de datos
  • Herramienta de ejemplo: aislamiento de sesiones basado en Docker con container-use
• También vale la pena prestar atención a herramientas como el trabajo en paralelo basado en CI y el background agent de Cursor

Learn To Refactor

• En el enfoque agéntico es importante refactorizar en el momento adecuado
  • Si la complejidad aumenta, el agente deja de poder manejar bien el código
  • Ejemplo: antes de que las clases de Tailwind queden dispersas en 50 archivos, convertirlas en una librería de componentes
• Tanto refactorizar demasiado pronto como demasiado tarde es ineficiente, así que hay que indicar mejoras estructurales en el momento oportuno

What Next?

• El agentic coding está evolucionando rápidamente, y los principios clave son ‘simplicidad, estabilidad, visibilidad y paralelismo’
  • Aunque cambien las herramientas y metodologías, estos principios siguen siendo válidos
• El objetivo no es solo mejorar la productividad, sino también buscar una mejor calidad de código
• La calidad del código que escriben los agentes ha mejorado de forma notable frente a hace unos meses
• Adaptarse con flexibilidad a los cambios y ampliar la experiencia de desarrollo

[helloppfm]

Yo también todavía solo le pregunto a la IA cosas como código de prueba simple o ejemplos, pero cada vez siguen apareciendo más personas que intentan aplicarla de forma general.

Puede que aún sea demasiado pronto, pero en unos años seguramente será algo de lo más normal.

[GN⁺]

Opiniones en Hacker News

• Estoy usando Copilot y Claude Sonnet 4 juntos en VS Code Nightly para hacer agentic coding. Incluso cuando la mitad de mi día se va en reuniones, mi historial de git no lo refleja: la mejora en productividad se siente muchísimo. Ya no estoy tan metido en la implementación minuciosa, sino en pensar si los cambios realmente funcionan, si este código se puede entender, cómo conviene estructurarlo para entenderlo mejor y qué más podría agregar al markdown de convenciones de IA para reducir malentendidos del agente. Anoche le dejé a un agente un archivo que tenía nada menos que 38 errores de mypy, me fui 15 minutos a hablar con mi familia y cuando regresé, el agente me resumió qué corrigió y por qué. Incluso discutimos uno de los cambios, pero al final concluí que el agente tenía razón. La verificación de mypy también pasó. Ahora estoy tratando de hacer que mi equipo entienda el verdadero potencial de esta tecnología, aunque hay quienes la ven con escepticismo y se oponen porque la IA no es perfecta. Pero, para citar a un amigo, el hecho de que "hoy sea el peor día que tú y esta tecnología van a vivir de aquí en adelante" me parece justamente la prueba de que estamos ante una innovación

  • En realidad, los errores del type checker son una de las partes en las que menos tiempo debería invertirse en el trabajo de desarrollo, así que me da curiosidad saber por qué esa parte les estaba consumiendo tanto tiempo. Creo que todas las discusiones sobre uso de IA serían mucho más útiles si pudiéramos ver en qué tareas concretas la está usando cada quien en la práctica, como en el post de Cloudflare

  • Personalmente confío más en un agente para código Rust que para Python. En Python, el nivel de análisis estático no es tan bueno como clippy o rust-analyzer, así que tengo que recorrer manualmente todas las rutas del código cada vez

  • Dijiste que aunque medio día se te va en reuniones, eso no se nota en tu historial de git, pero si yo fuera empleado de tu empresa, tendría muy presente que pronto esperaría este nivel de producción de forma constante

  • Me da curiosidad tu workflow. He probado Claude Code para experimentar en proyectos personales y también Copilot con cuenta de empresa en el modo agent de VS Code, mezclando varios modelos como 3.5, 3.7 Sonnet y 04-mini. Lo usé en un proyecto grande en Go y, salvo en la parte de pruebas, los resultados fueron pésimos. Pensé que quizá estaba usando mal las herramientas, así que probé todas las “mejores prácticas” más recientes: cambiar contexto, cambiar modelo, definir reglas, mejorar prompts... probé de todo y aun así no vi mejoras

  • Mencionaste si se puede agregar más contenido al markdown de convenciones de IA para reducir errores del agente; me gustaría saber si ese es un archivo que adjuntas como contexto en cada tarea, o si es una convención oficial de VS Code Copilot Agent. También quisiera preguntar si tomaste como referencia algún material para definir la estructura del documento, o si fue algo que fuiste refinando tú mismo con el tiempo a partir de los errores recurrentes de la IA

• Es realmente alentador que la mayoría de las técnicas que vuelven más eficiente el agentic coding también mejoren la eficiencia del coding humano. Antes existía la preocupación de terminar con código “gran bola de lodo” que solo la IA pudiera entender, pero en la práctica parece ser al revés. El código claro se volvió todavía más importante para la productividad de la IA, y gracias a eso la diferencia de productividad empieza a mostrarse con métricas más claras. Como Claude puede mostrar numéricamente qué tan bien funciona sobre cada codebase, las discusiones sobre si un código está bien estructurado dejan de ser cuestión de opiniones y pueden basarse en evidencia objetiva

  • La preocupación de que el código se convierta en una “bola de lodo” en realidad ha existido durante toda la historia de la programación (vean la charla de Rich Hickey). La gente suele elegir el “vamos por lo fácil ahorita” y termina cargando una deuda técnica enorme al día siguiente. Con los LLM también se vuelve más fácil producir boilerplate sin sentido. Si duele menos, quizá hasta desaparezca por completo el impulso de corregirlo

  • También quería dejar muy en claro la idea de que “la preocupación de que el código se convierta en algo que solo la IA entienda, aunque no sea así ahora, no sabemos cómo será en el futuro”

  • Esta parte me identifica muchísimo. Buenos mensajes de error, herramientas rápidas, un ecosistema estable, código simple y sin “magia”, SQL intuitivo... ese siempre ha sido el entorno de desarrollo con el que soñaba. Como los agentes trabajan tan rápido, incluso una pequeña demora se siente, así que creo que este tipo de tecnología puede elevar el nivel de toda la experiencia de desarrollo

• He escuchado decir que al usar agentes uno termina siendo empujado de forma natural hacia Go y Tailwind. Como tienen muchísimos datos de entrenamiento, la IA puede manejarlos bien. Entonces también me preocupa si, en un futuro donde todo el mundo use estas herramientas, podría volverse más difícil que aparezcan nuevos lenguajes, frameworks o librerías. Competir con soluciones existentes sería más complicado, y hasta podrían desaparecer comunidades humanas como Stack Overflow

  • No estoy de acuerdo con la preocupación de que ya no vayan a surgir nuevos lenguajes o frameworks. Los LLM son increíblemente buenos para traducir, así que incluso sin datos de entrenamiento pueden aprender directamente observando una codebase si el framework es peculiar pero tiene una estructura clara. De hecho, he visto que manejan muy bien mi framework idiosincrático de C# que nadie más ha visto. Claro, características especiales como los lifetimes de Rust quizá no se adapten de inmediato, pero algo simple como Go lo aprenden rapidísimo. En el futuro, tal vez hasta haya que diseñar nuevos lenguajes pensando desde el principio en compatibilidad con LLMs, incluyendo diseño, tooling y documentación

  • Es una pregunta realmente importante. Dicho de otro modo: a medida que internet se vaya llenando de datos generados por LLM, va a disminuir la disponibilidad de datos de entrenamiento de alta calidad, y los desarrolladores más afines a los LLM podrían sentirse más atraídos por tecnologías antiguas con “menos radiación”, como JS/React. En el futuro, incluso si JavaScript/React se convierten en el COBOL del mañana, podría llegar una era en la que ya no hagan falta consultores caros porque los LLM podrán encargarse del mantenimiento. Si quieres evitar la moda de la IA, desarrollar nuevos lenguajes —especialmente lenguajes raros como Lisp+DSL que los LLM no puedan aprender de inmediato— podría seguir siendo relativamente seguro hasta antes de la era AGI

  • El ciclo tradicional del stack de software ha sido este: (1) cuando el stack existente se vuelve complejo al tratar de abarcar todos los nichos, los expertos empiezan a lanzar “atotectura” innecesaria por todas partes; (2) por eso aparece un stack nuevo y simple que resuelve mucho mejor y con más claridad la nueva tendencia, y gana popularidad; (3) con el tiempo ese stack nuevo también se vuelve pesado por el mismo problema, y el ciclo se repite. Como el contexto de la IA para programar está expandiéndose rápidamente, no creo que este ciclo vaya a romperse tan fácil

  • La afirmación de que Go y Tailwind se imponen en realidad refleja bastante la preferencia personal del autor. Que Sonnet tenga problemas con el CLI de cargo test no significa que Rust, cargo o la IA en general sean el problema. Incluso en pruebas con PHP, Junie no usa muy bien el runner integrado, pero si le haces un script bin/test-php, sabe usarlo sin problema. Expresar explícitamente los requisitos en las guías sí ayuda, pero la diferencia real es que tienden a aferrarse a las herramientas predeterminadas. Sobre la experiencia con Stack Overflow, mi asistente de IA tiene la ventaja de que no cierra preguntas por duplicadas. Los intentos de curación de SO fueron valiosos, pero también es cierto que alejaron a muchos usuarios

  • Ayer mismo le pedí a Claude, usando Zed, que hiciera un proyecto nuevo en Elixir Phoenix dándole solo las condiciones, y lo resolvió sin problema. En CSS usó Tailwind, pero creo que fue porque Phoenix ya lo deja configurado por defecto. No coincido con la idea de que la IA te empuje a Go. De hecho, cuando preguntas sin mucho contexto, suele proponer Python por todos lados, y también he tenido buenas experiencias con Elixir, aunque su comunidad sea mucho más pequeña

• Probé Rust con Claude Code Sonnet 4.0 durante como una semana y me dejó por debajo de lo esperado (además, pasando por Bedrock sale caro). Se tarda mucho al planear al inicio, pero en la práctica muchas veces solo completa la mitad. Me pregunto si se me está escapando algo

  • A mí me pasa casi exactamente lo mismo. En el modo Edit/Agent de Cursor suele sacar casi la modificación que quiero de una sola vez, así que es súper eficiente, pero en CLI se siente muy incómodo. Me da curiosidad si lo usas dejándole a Claude Code tareas de 10 a 15 minutos y luego solo revisas el diff, o si también haces una revisión de código como tal

  • He tenido exactamente la misma experiencia. Incluso tratando de encontrarle casos de uso útiles a propósito, no lograba que funcionara bien y la verdad me sorprendió mucho

  • No debería sentirse caro. El plan Pro cuesta 20 dólares al mes y Max 100–200 dólares, así que sigue siendo más barato que usar la API y terminar gastando más de mil dólares al mes

• Me alegró bastante que se mencionara el uso de contenedores. Yo participo en dagger/container-use y en el equipo hay exmiembros de Docker e incluso el fundador de Docker. Creo que ejecutar agentes en paralelo va a ser un punto de inflexión enorme en el progreso técnico, en cuanto se pueda hacer de forma confiable. Incluso antes de eso, si mientras corre el trabajo del agente quieres dedicarte a otra cosa o te preocupa que toque partes equivocadas, contenerizar el entorno de desarrollo es muy útil. Las técnicas de uso de contenedores todavía están en etapas tempranas, pero están avanzando rapidísimo; por ahora el foco está en mejorar la estabilidad, reducir conflictos de git y reforzar la interacción entre humanos y agentes

• Mi opinión sobre la elección del lenguaje es la siguiente. 1) Java es el más abarcador gracias al enorme volumen y la antigüedad de sus datasets que los LLM pueden consultar (eso no significa necesariamente que sea el más preciso). 2) Sobre todo, hay que trabajar en el lenguaje que mejor conozcas, para poder detectar rápido cuando el LLM comete errores de razonamiento, errores comunes o alucinaciones

  • La opinión de que Java destaca por tener el dataset más grande, más antiguo y más claro me parece un consejo válido solo cuando el LLM no tiene herramientas para buscar APIs, documentación o código fuente de terceros. Si la herramienta puede averiguar automáticamente qué necesita usar, entonces da igual el lenguaje mientras el agente pueda leer el código fuente. Pero coincido totalmente con el segundo punto: la revisión minuciosa por parte de una persona sigue siendo indispensable, y en un lenguaje conocido es más fácil detectar errores

  • ¿Por qué Java tendría el dataset más grande? ¿Hay más proyectos open source en Java que en otros lenguajes, quizá por toda la suite de Apache? ¿O será porque la documentación de librerías open source en Java es particularmente abundante?

  • Yo siempre había pensado que el dataset más grande sería el de Python. Cuando no se le dice nada, la mayoría de los LLM tienden a recomendar Python primero

• Sobre la afirmación de que el sistema de context de Go (diseñado para hacer fluir datos explícitos a lo largo de la ruta de ejecución del código) aporta simplicidad a los agentes de IA, hay una crítica que dice que “meter en context.Context datos que no sean tracing data no es realmente una buena práctica”

  • De acuerdo. En chromedp (driver headless de Chrome para Go) usan context.Context como primer parámetro, pero la estructura exige usar no un simple context.Background(), sino un context obtenido desde una factoría especial. Solo manejan aparte el timeout con context.WithTimeout, y al final se termina usando casi como un puntero void*

  • No soy experto en Go, pero en la práctica sí veo muchas librerías que guardan en el context cosas como conexiones a base de datos, configuración, rate limiters o cache backends, así que por ahora no me parece algo tan problemático

• Escribir “código lo suficientemente simple para que la IA lo entienda” no era el punto de innovación que yo esperaba. También me da curiosidad cómo choca eso con mi post anterior sobre ugly code

  • Este estilo de escribir código simple y claro, en la práctica, casi siempre ayuda al trabajo en equipo. Sí hay momentos en que conviene concentrarse muchísimo en el código o escribir algo creativo, pero son excepciones y deberían estar muy conectadas con valor real de negocio. La mayor parte del código tiene una solución que “cualquiera puede ver que es la obvia”. Los desarrolladores no son lentos por teclear, sino por la cantidad de “conceptos” que tienen que sostener a la vez en la cabeza. No sobreingenierices interfaces, retrasa abstracciones, permite copiar y pegar y composición simple, usa los patterns tal como vienen en la documentación oficial y nunca intentes ser demasiado listo. La clave es remarcar que el código no debe ser “bonito”, sino claro y simple, y que lo verdaderamente difícil no es el código en sí, sino el “producto”

• Tal como escribió el autor sobre Claude Code, en la práctica sí existen varias alternativas, como OpenCode, goose, Codex, Devin, Cursor background agent, etc. También hay una pregunta sobre soluciones open source + LLM local similares a Claude Code

  • Por ahora no hay realmente una solución open source + LLM local que yo recomendaría con entusiasmo. Aun así, OpenCode de SST está evolucionando muy rápido en UX, y si aparecen mejores modelos locales en el futuro, sería fácil adaptarlos. El problema más grande es que casi no existen buenos modelos que realmente sobresalgan en “uso de herramientas”. La razón por la que Sonnet sorprende tanto es porque fue entrenado específicamente para eso. Gemini todavía está bastante por detrás; al final, esto parece un problema que se resuelve en cuanto aparezcan mejores modelos

  • En el caso de Aider, ya está muy cerca, pero intencionalmente no es totalmente agentic. Puede ejecutar pruebas y análisis estático automáticamente, corregir errores de forma automática y manejar especificaciones de proyecto completas basadas en listas de tareas. Ahora mismo tiene un límite de repeticiones de reflexión cableado a mano (3 veces), aunque se puede hackear para aumentarlo, y si se le agregara self-prompting podría convertirse en un agente completamente automatizado

  • También creo que la app que voy a lanzar pronto puede ser una buena alternativa. Se descarga como un solo archivo, no requiere instalación y funciona en Mac, Windows, Linux y Docker. Puede usar cualquier modelo compatible con la API de OpenAI, incluyendo modelos ejecutados localmente, y como está basada en navegador se siente tan cómoda como Claude Code. También permite crear apps de consola basadas en comandos. Además, puede abrir directamente una terminal y conectarse a servicios. Ahora está en alpha cerrada, pero si a alguien le interesa usarla puede contactarme por correo

  • Casi todos los días sale una alternativa nueva, o al menos un intento nuevo, así que espero que pronto podamos usar una que sí se sienta “justa” para cada caso. Por ejemplo, app.build acaba de lanzarse por parte del equipo de Neon (ahora Databricks) y se ve bastante prometedora

  • El plugin de Neovim CodeCompanion también ha ido evolucionando recientemente hacia algo más agentic. Ya soporta auto-submit loop, herramientas integradas y funciones de integración con MCP. No es una herramienta CLI independiente, pero tiene la ventaja de permitir usar de inmediato un entorno completo de editor, lo cual puede ser todavía mejor, sobre todo si te gusta hackear, personalizar o trabajar con editores ligeros

• 100 a 200 dólares al mes me parece demasiado caro para una IA que escribe código y todavía no está validada. Mi experiencia personal no ha sido tan satisfactoria, y además está la polémica ética, así que eso se vuelve una barrera de entrada

  • Claude Code se puede usar con una API key o con una suscripción Pro de 20 dólares al mes

  • Recomiendo probar Aider con esquema de cobro por API. Puedes controlar el tamaño del contexto (/clear, /add, /drop) para limitarlo a unas 25K. También puedes usar el modelo que quieras, por ejemplo Sonnet 4 o Gemini 2.5 Pro. Un script sencillo normalmente me ha costado menos de 1 dólar, e incluso al crear herramientas bastante grandes, sumando prompt + código + unas 100 pruebas, no pasé de 6 dólares. Cuando ya te acostumbres a programar con IA, entonces sí te recomendaría pasar a Claude Code, que es más potente pero si no lo usas seguido puede terminar saliendo más caro

  • Con una suscripción mensual de 20 dólares basta para probar varios proyectos pequeños y decidir si vale la pena considerar el plan de 100 dólares. O también puedes esperar unos meses más y revisar la experiencia real de otras personas antes de decidirte