Cómo crear un agente de programación

• A partir de 2025, crear directamente un agente de programación es uno de los mejores proyectos que un desarrollador individual puede intentar
• Un agente funciona solo con 300 líneas de código y un bucle de tokens de LLM, y construirlo ofrece la oportunidad de pasar de consumidor a productor de IA
• Los componentes básicos son herramientas como lectura de archivos, listado de archivos, ejecución de Bash, edición de archivos y búsqueda de código, con las que se implementa automatización real
• En la elección del modelo, son adecuados los modelos agentic como Claude Sonnet y Kimi K2; si hace falta, se puede conectar un modelo oráculo como GPT como herramienta para realizar verificaciones de mayor nivel
• De hecho, productos comerciales como Amp, Cursor, Claude Code y GitHub Copilot también tienen una estructura similar

---

Resumen del taller

• Taller gratuito impartido por Geoffrey Huntley que guía, con enfoque práctico, sobre cómo crear un agente de programación y entender sus principios
• Compara la estructura y los principios de asistentes de IA comerciales existentes como Roo code, Cline, Amp, Cursor, Windsurf y OpenCode, y ofrece la oportunidad de implementarlo directamente
• A través de la experiencia de construcción, es posible dejar de ser un simple usuario de IA y crecer como desarrollador que crea herramientas de automatización usando IA
• La estructura central consiste en usar un bucle de tokens de LLM dentro de unas 300 líneas de código para crear funciones de agente
• Se agregan primitivas por herramienta (lectura, listado de archivos, ejecución, edición, búsqueda de código), y los ejemplos reales de funcionamiento y el código están publicados en el repositorio de GitHub

Qué es un agente

• Últimamente el término "agente" se usa de forma muy amplia, pero su significado real y su principio interno de funcionamiento no están claros
• A medida que baja la barrera de entrada para crear agentes, se vuelve posible pasar de consumidor de IA a productor capaz de liderar la automatización del trabajo
• En 2025, al igual que conceptos básicos de bases de datos como la Primary key, los principios para crear agentes se están convirtiendo en conocimiento esencial
• Empresas como Canva ya recomiendan usar IA en sus procesos de entrevista, y la capacidad de automatizar con IA se está volviendo un factor clave de contratación
• Ahora quedarse atrás no es por la IA, sino por no aprender nuevas herramientas mediante el desarrollo personal

Principios clave de un agente de programación

• Un agente de programación está compuesto solo por 300 líneas de código y un bucle de tokens de LLM, y ejecuta funciones mediante entradas repetidas de tokens
• El concepto de trabajo concurrente (concurrent work) es importante
  • Ejemplo: incluso durante una reunión de Zoom, el agente puede avanzar en paralelo, mejorando mucho la eficiencia del trabajo
• No todos los LLM son agentic
  • 'Alta seguridad' (ej.: Anthropic, OpenAI)
  • 'Baja seguridad' (ej.: Grok)
  • 'Oráculo' (ventajoso para resumir y razonamiento de alto nivel)
  • 'Agentic' (sesgo a la acción, iteración rápida y llamadas a herramientas)
• Los desarrolladores deben entender las características de cada modelo y elegir el modelo según el objetivo
• Asignar contexto sin medida perjudica el rendimiento, y hay que tener presente que "cuanto menos se asigne, mejor será el resultado"
  • Registrar demasiadas herramientas MCP también lleva a una caída de rendimiento
• Regla: “Less is more” → para lograr el mejor rendimiento, hay que colocar en el contexto solo las herramientas y los datos necesarios

Flujo del proceso de construcción de un agente de programación

• 1. Registro de herramientas y llamadas a funciones

  • Por ejemplo, se registra en el LLM una herramienta para consultar el clima y se permite que el LLM responda en formato de llamada a función cuando corresponda
  • MCP (Model Context Protocol) es similar a un "banner informativo sobre una función"; con solo registrar la descripción de la función, es posible invocarla automáticamente

• 2. Funciones clave por herramienta primitiva

  • Lectura de archivos (ReadFile): al pasar una ruta, lee el contenido del archivo al contexto
  • Listado de archivos (ListFiles): entrega la lista de archivos y carpetas dentro de un directorio
  • Ejecución de comandos (Bash): el LLM ejecuta comandos del shell del sistema y devuelve el resultado
  • Edición de archivos (Edit): automatiza la creación o modificación del archivo indicado
  • Búsqueda de código (CodeSearch): busca rápidamente en toda la base de código según patrones, palabras clave o nombres de funciones (usando ripgrep)

• 3. Ejemplos y flujo de resultados

  • Al integrar cada herramienta con el LLM, se automatizan tareas continuas usando solo prompts en lenguaje natural (por ejemplo, generar código de FizzBuzz → verificar la ejecución, explorar un directorio → analizar el contenido)
  • Las funciones de herramienta se invocan secuencialmente según la entrada del usuario o el escenario, repitiendo dentro del bucle la devolución de resultados
  • Secuencia principal de operación del agente: entrada del usuario → decisión sobre si llamar una herramienta → ejecución de la herramienta → asignación del resultado al contexto → repetición

Posibilidades de expansión y código abierto

• Actualmente, la mayoría de los agentes de programación funcionan sobre la base de herramientas open source existentes como ripgrep
• En GitHub existen proyectos de agentes simples pero potentes, implementados en apenas 100 líneas, como SST Open Code y mini-swe-agent, que sirven como referencia para rendimiento y estructura
• Se recomienda que los desarrolladores entiendan y aprovechen los principios construyéndolos directamente, en lugar de limitarse a comparar productos existentes
• Al aplicarlos a trabajo real y automatización, crear agentes propios y difundirlos dentro de la organización se convierte en una ventaja competitiva

Conclusión e implicaciones

• Los agentes de programación no son una tecnología compleja, sino una combinación de una estructura de bucle simple y herramientas
• La clave para crear agentes de programación es entender la estructura y ejecutar con rapidez, y la experiencia de construirlos directamente permite responder de forma activa a los cambios en la tecnología de IA
• Más importante que la IA en sí misma es la inversión personal, como el desarrollo constante y la capacidad de crear herramientas, que hoy es la estrategia de crecimiento individual más importante
• “La IA no te quitará el trabajo; la amenaza es que tu colega se equipe con agentes, automatice y trabaje más rápido”

[GN⁺]

Comentarios en Hacker News

• Nuestro equipo de Princeton SWE-bench hizo un agente de unas 100 líneas de código que logra buenos resultados en SWE-bench; si les interesa, vale la pena echarle un vistazo a mini-swe-agent

  • Me sorprende que de verdad tenga una estructura bastante simple; gracias por compartir algo así.
    En realidad, todo el código funciona con estos prompts código fuente del prompt base del agente

    Your task: {{task}}. Please reply
    with a single shell command in
    triple backticks.
    
    To finish, the first line of the
    output of the shell command must be
    'COMPLETE_TASK_AND_SUBMIT_FINAL_OUTPUT'.
    

  • De los prompts de ejemplo del agente, resulta útil la parte de “1. encontrar y leer archivos relevantes en la base de código 2. crear un script para reproducir el issue 3. corregir el issue 4. verificar la corrección con el script 5. probar casos límite”.
    Yo también uso prompts parecidos en mis bucles de depuración.
    El enfoque de “analizar la base de código, listar posibles causas, ordenarlas por probabilidad y validar las hipótesis con scripts o logging de depuración” me ayuda mucho en mi propia rutina para resolver problemas.

  • Cuando el problema está contenido de forma autosuficiente en un solo archivo, es muy fácil corregirlo usando un LLM.
    Pero en una base de código normal, los archivos y el contexto están dispersos por todos lados, así que no es fácil entenderlo siguiendo la intención de diseño estructurada y la organización del desarrollador.

  • Aplaudo el gran intento, aunque me deja con ganas de más herramientas.
    La mayor parte del código corresponde al framework del agente, y el código realmente especializado para SWE no es tanto como uno pensaría.
    Yo también hice un agente SWE por diversión, así que quizá valga la pena revisar autocode.

  • Lo agregué a los materiales de referencia como forma de agradecimiento.

• También existe una “guía de cómo construir un agente” muy parecida, escrita por Thorsten Ball, en AmpCode How To Guide.
  En general, Amp también es bastante interesante.
  Ya no es un servicio secreto, pero da gusto que sigan saliendo a la luz herramientas relacionadas con agentic coding.
  Creo que en adelante este tipo de modelos de agente vendrán incluidos por defecto en distintos tipos de software.

  • Esto se ve mucho mejor, así que se agradece.

  • También se menciona que el propio autor trabaja en Amp.

  • Ghuntley también trabaja en Amp.

• Dicen que una imagen vale mil palabras, pero en este material siento que las imágenes tienen un descuento del 99.6%.
  Me pregunto qué es esto.

  • Son diapositivas para un workshop de conferencia.
    El texto es una transcripción literal de lo que se dijo en la presentación real.

• Me gustaría saber si alguien puede confirmar cómo funciona el uso de herramientas.
  Entiendo que Claude, ChatGPT y otros ofrecen “herramientas” vía API, y que cuando entra una solicitud de llamada de herramienta, quien responde ejecuta realmente la herramienta y luego devuelve el resultado.
  Pero como el modelo en sí, estrictamente hablando, está basado en texto, me da curiosidad cómo la API transforma la respuesta del modelo en varias estructuras.
  Supongo que en el proceso de fine-tuning hubo ejemplos donde cierta llamada de herramienta se metía en forma de bloque especial para que el modelo la entendiera, y que luego los servidores de Claude/ChatGPT interpretaban eso.
  Me pregunto si hay documentación al respecto o información sobre tokens especiales usados internamente, y también cómo evitan que la entrada del usuario abuse de esos tokens que “llevan el significado”.

  • Hay documentación pública de implementación por parte de Anthropic.
    Anthropic Tool Use Documentation
    Ahí se ve con claridad que el modelo en realidad no opera sobre “texto”, sino a nivel de tokens.
    Es parecido a cómo un compilador parsea código fuente y construye una secuencia de “tokens” como keywords, paréntesis y estructura.
    En la salida puede ir incluido metadato junto con las palabras reales.

  • Conceptualmente lo entendiste bien.
    La única interfaz real con un LLM son los “tokens”, y no hay separación entre canal de control y canal de datos.
    En la capa de API del modelo se insertan en el prompt las instrucciones para llamadas de herramientas y la lista de herramientas disponibles, junto con la descripción de cada una.
    Cuando hace falta llamar una herramienta, el modelo inserta en la respuesta un bloque especial —con tokens especiales, nombre de la herramienta y parámetros— y la capa de API extrae eso y lo transforma a JSON.
    El resultado de la herramienta también se inserta codificado con tokens especiales.
    La capa de API impide que el usuario inyecte por su cuenta ese tipo de tokens.
    Los modelos más recientes (SoTA) han recibido bastante fine-tuning para llamadas de herramientas, tanto para uso genérico de herramientas como para casos específicos de ciertas herramientas (por ejemplo, el modelo Claude Sonnet especializado para las herramientas de Claude Code).
    Casi sorprende que todo esto funcione tan bien; en llamadas de herramientas, el fine-tuning realmente juega un papel clave.
    Puede funcionar incluso sin fine-tuning, pero la tasa de éxito baja mucho.

  • Creo que la suposición de “hicieron fine-tuning para devolver ejemplos que requieren llamadas de herramientas en bloques especiales” es correcta.
    El modelo fue entrenado para responder en formato de llamada de herramienta cuando no sabe bien la respuesta o cuando se le indica hacerlo.
    Hubo tanto entrenamiento con ejemplos de llamadas de herramientas que siguen el formato como entrenamiento especializado en algunas herramientas concretas.
    Por ejemplo, gpt-oss tiende a querer usar una herramienta de búsqueda aunque nadie la mencione.
    En la documentación de Anthropic también hay una lista separada de herramientas familiares (por ejemplo, text_editor, bash), y es muy probable que además se haya entrenado el significado profundo de cómo usar esas herramientas.
    En la práctica, la estructura es bastante frágil y se apoya en señales de bajo nivel como “tokens especiales o secuencias de tokens”.

• La frase “si sigues metiendo tokens en el loop, aparece un agente” se siente como una sátira muy realista si cambias “tokens” por “dinero”.
  Al final, sería como decir que si sigues quemando dinero, aparece un agente.

  • No creo que sea correcto decir que todos los tokens son dinero.
    Los modelos locales también siguen mejorando.
    Por ahora todavía hacen falta tokens (= dinero) para lograr los mejores resultados, pero es muy posible que eso cambie en el futuro.

• Cuando ya todo está lleno de imágenes, se vuelve demasiado difícil de leer.
  Se siente como estar viendo un simulador de scroll.

• Me pregunto por qué harían falta otras herramientas aparte de bash.
  Cosas como listar archivos, buscar y explorar un repo, o editar el contenido de archivos, ¿no se pueden hacer todas solo con bash?
  O quizá se trate del caso que muestran arriba en el ejemplo de mini-swe-agent.

  • Técnicamente, con solo bash ya se puede hacer una variedad bastante grande de tareas, y de hecho he tenido experiencias exitosas así.
    Lo interesante es que mientras más limitas las herramientas, más creativamente aborda el agente el problema.
    Pero si le das varias herramientas ya entrenadas, como el modelo ya conoce bien cómo usar cada una, el consumo de tokens se vuelve más eficiente y en general la tasa de éxito también mejora.
    Cuando solo usas bash, también es común que se enrede con bashisms, manejo de argumentos o manejo de espacios.

  • Usar herramientas separadas es mucho más simple que meter todo dentro de bash.
    Si procesas todo con bash, tendrías que implementar por separado un sistema donde comandos siempre seguros de ejecutar (por ejemplo, listar archivos) se ejecuten de inmediato, mientras que otros comandos más riesgosos requieran aprobación del usuario.
    Si ofreces el listado de archivos como una herramienta aparte, también puedes evitar exponer archivos fuera del directorio del proyecto.

  • En la práctica, con una herramienta de bash y una de Edit ya basta para que funcione un agente de programación (aunque Edit no es estrictamente obligatoria, sí vuelve todo mucho menos eficiente).
    Aun así, puede haber dificultades en cosas como la búsqueda de código.
    Por ejemplo, quizá se pueda cubrir ajustando el prompt para que use ripgrep desde bash.

  • ¿Por qué hace falta un IDE? En el shell se puede hacer todo; entonces, ¿para qué usarlo?
    Una UI (interfaz) sirve precisamente para ofrecer la información y las acciones necesarias en el momento exacto.

  • Sobre por qué había algo más además de la herramienta de bash: supongo que fue porque empezaron dando solo el conjunto mínimo de herramientas, y luego siempre se puede agregar bash después.

• En vez de explicar largamente “cómo hacer un agente”, preferiría que mostraran un proyecto real hecho por el agente.

  • Estaría buenísimo que alguien construyera un agente por su cuenta y lo compartiera en HN como “Show HN”.

• Preguntan si alguien puede explicar qué significan los ejes de Oracle, Agent, high safety y low safety.

• Lo probé directamente con los modelos on-device de Edge y Chrome (phi4-mini, gemini nano), y me sorprendió que funcionara bastante bien para el tamaño del modelo.
  caso experimental de how to build an agent on device

[crawler]

Se supone que una imagen vale normalmente 1000 palabras, pero en este material siento que el valor de las imágenes tiene un descuento del 99.6%. Me da curiosidad saber qué es esto.

Está buenísimo, jajajaja. No entendía a qué se refería, pero entré al enlace y lo entendí clarísimo.

[savvykang]

Las miniaturas de las otras publicaciones del blog también son pésimas; tienen una pinta que hace que no quieras hacer clic en ellas bajo ninguna circunstancia.

[nemorize]

jajajajajajajajajajajajajaja