Agente de programación Pi: Creando herramientas de IA flexibles para flujos de trabajo reales

Introducción

El código nunca es gratuito. Ese es el argumento central que Mario Zechner, creador de Pi, plantea al discutir el estado del desarrollo asistido por IA en 2026. Aunque los agentes pueden generar grandes cantidades de código rápidamente, las consecuencias de ese código terminan alcanzándote. Pi existe porque Zechner descubrió que los agentes de programación existentes no se ajustaban a sus flujos de trabajo y, en lugar de adaptarse, construyó una herramienta que se adapta a él.

Esta conversación cubre por qué la estabilidad del flujo de trabajo es más importante que la velocidad de las funciones, cómo trabajar realmente con agentes de programación sin agotarse y por qué la industria podría estar repitiendo un error de hace 30 años con el desarrollo basado en especificaciones.

Por qué existe Pi: Flexibilidad del flujo de trabajo sobre la estabilidad

Cuando Claude Code se lanzó por primera vez, Zechner estaba contento con él. Sin embargo, con el tiempo, la alta frecuencia de lanzamiento de la herramienta se convirtió en un problema. Claude Code recibe de una a tres actualizaciones al día, y con cada lanzamiento vienen cambios en las definiciones de herramientas, los prompts del sistema y el comportamiento subyacente. Para alguien que construye plantillas de prompt personalizadas, comandos de barra diagonal y descripciones de flujo de trabajo, estos cambios invisibles rompen las cosas.

El modelo en sí parecía comportarse de manera diferente día a día, aunque la versión del modelo seguía siendo la misma. Zechner atribuye esto en parte a los cambios en el “arnés”: la infraestructura y los prompts del sistema que dan forma a cómo responde un modelo. Probar los efectos de los cambios en el arnés sobre la calidad de la salida es difícil porque no hay una forma determinista de medirlo. El resultado es que los desarrolladores como Zechner no pueden confiar en que la herramienta se comporte de manera consistente, lo que anula el propósito de construir flujos de trabajo personalizados a su alrededor.

Pi nació de esta frustración. Es un agente de programación minimalista y extensible que puede modificarse a sí mismo para adaptarse a tus flujos de trabajo en lugar de obligarte a adaptarte a sus limitaciones. La arquitectura subyacente abstrae a los proveedores de LLM, incluye una biblioteca de interfaz de usuario de terminal y proporciona abstracciones generales de bucle de agente. Pero la diferencia clave es el control: Zechner dicta el diseño y puede cambiarlo sin esperar al ciclo de lanzamiento de un proveedor.

Cómo funciona realmente Pi: Procesamiento paralelo y revisión manual

El flujo de trabajo diario de Zechner con Pi es metódico y deliberadamente de baja tecnología. No ejecuta un ejército de agentes en paralelo. En cambio, utiliza un enfoque rudimentario: pone en cola múltiples sesiones, cada una analizando un problema diferente del rastreador, luego revisa e itera sobre cada una.

Para correcciones de errores e implementaciones de funciones, el proceso comienza con una descripción del problema. Zechner alimenta el problema a un agente con una plantilla de prompt personalizada que dice: extrae toda la información relevante, ignora el análisis en el problema y haz tu propio análisis basado en lo que queremos lograr. Este paso de análisis toma unos cinco minutos por problema. Abre una segunda sesión para el siguiente problema, una tercera para otro, creando una tubería de preprocesamiento paralelo.

Una vez que el agente termina de analizar un problema, Zechner revisa las sugerencias, verifica el código él mismo y reproduce los problemas manualmente si es necesario. Utiliza al agente como un patito de goma (un compañero de pensamiento) hasta que está de acuerdo consigo mismo sobre el enfoque de implementación. Para cuando le dice al agente que implemente, el contexto contiene tantas barandillas que el agente sabe exactamente qué interfaces modificar, qué módulos tocar y cómo deberían funcionar las pruebas.

La implementación toma otros 10 a 30 minutos. Cuando el agente señala la finalización, Zechner abre un visor de diferencias y anota líneas individuales con comentarios. Hace clic en finalizar, los comentarios se envían al agente automáticamente y la iteración continúa hasta que el código es bueno. Para la mecánica central, revisa cada cambio como lo haría con un humano. Para otras piezas, aprueba sin una inspección profunda.

Este flujo de trabajo funciona porque Zechner tiene más de 10 años de experiencia en bases de código. Sabe lo que funciona y lo que no. Para los nuevos desarrolladores o aquellos sin esa experiencia, el enfoque sería diferente y más arriesgado.

La realidad del desarrollo basado en especificaciones

La industria está repitiendo un error de hace 30 años. El desarrollo en cascada demostró ser ineficaz hace décadas, pero con los agentes de IA, hemos vuelto a la hiper-cascada: escribir especificaciones detalladas y hacer que los agentes las implementen. La única diferencia es que ahora ni siquiera escribes la especificación tú mismo: le das un “vibe prompt” a un agente para que escriba una especificación muy detallada, que luego otro agente implementa.

El problema es fundamental. Una especificación completa es esencialmente el programa mismo. Si escribes una especificación en prosa en lenguaje natural, estás dejando lagunas. El agente llena esas lagunas con cualquier patrón que haya aprendido de 20 años de código en Internet, gran parte del cual es basura. El resultado es una base de código que parece software “vibe-coded”, porque lo es.

Existe un contraargumento: el código ahora es barato y la iteración es rápida. Anteriormente, una especificación en cascada podría tardar meses en implementarse. Ahora podría tomar un día. Puedes probar tu camino a través de él manualmente. Pero Zechner aún no ha visto evidencia de que esto realmente funcione para el software de producción. Sospecha que, eventualmente, los desarrolladores se despertarán por la noche dándose cuenta de que todo está roto.

Dicho esto, hay limitaciones donde el desarrollo impulsado por agentes tiene sentido. La reescritura de Bun de Zig a Rust funcionó porque el proyecto tenía un conjunto de pruebas extenso. El agente pudo verificar su propio trabajo hasta cierto punto. En esos casos, herramientas como esta son genuinamente útiles. Pero para la mayoría del software, el enfoque es arriesgado.

Gestión de código abierto a escala: El problema de los “clankers”

Antes de los agentes, un proyecto de código abierto exitoso podía recibir una o dos solicitudes de extracción por semana. Pi ahora recibe de 50 a 60 solicitudes de extracción por día, todas de agentes (Zechner los llama “clankers”). Cada PR tiene una descripción como un libro completo de Harry Potter e incluye de 10 a 1,000 cambios de archivo.

La posición predeterminada es declarar cada PR generado por agente como basura y cerrarlo automáticamente. Pero Zechner encontró una solución: exigir a las personas que primero escriban un problema con su propia voz, no más largo que una pantalla, explicando exactamente qué quieren hacer y por qué. Si el problema es bueno, lo aprueba y la persona puede enviar un PR. Esto demuestra que son humanos, que entienden el problema y que entienden la solución.

Una vez aprobados, llegan PRs significativos. Los PRs de los “clankers” dejan de aparecer. Los problemas siguen llegando, pero Zechner los clasifica manualmente. Lee de 30 a 60 problemas cerrados por día, identificando cuáles son legítimos y cuáles son basura. En su última ronda de clasificación, llegaron 50 problemas y sobrevivieron 2. Toma unos 30 minutos porque la mayoría son fáciles de identificar como ruido.

Para proyectos a la escala de OpenClaw, este enfoque manual no funciona. El consumo de tokens de Peter Steinberger alcanzó 1.3 millones de dólares por mes, en parte porque automatizar el filtrado de problemas y PRs a esa escala requiere una infraestructura sofisticada. Zechner escribió algunas herramientas de visualización para ayudar a agrupar problemas similares, pero incluso eso no fue suficiente. El volumen es órdenes de magnitud mayor.

Inferencia local y el futuro de los modelos más pequeños

Zechner es optimista sobre la ejecución de modelos de IA capaces localmente en hardware de consumo. Para su proyecto de robot (un juguete con un teléfono inteligente como microcontrolador ejecutando un agente de programación), utiliza Gemma 4 y Qwen 3.6, modelos de mezcla de expertos más pequeños. Son más que adecuados para un chatbot con control de motor y cámara, y son rápidos.

La configuración es asequible. La conversión de voz a texto con Parakeet toma unos 10 gigabytes de memoria unificada. La conversión de texto a voz con Qwen TTS toma otros 10 gigabytes. Qwen 3.6 toma 4 gigabytes. Total: 14 gigabytes de memoria unificada en macOS o una configuración NVIDIA equivalente en Windows. Eso es asequible para muchas personas, no para todo el mundo, pero sí para una parte significativa.

Denise Asaves de DeepMind ha sugerido que los modelos gigantes actuales no necesitan todos sus parámetros y pueden destilarse en modelos mucho más pequeños sin perder mucha calidad de salida. La esperanza de Zechner es que el futuro implique destilar modelos grandes en otros más pequeños que conserven la mayoría de las capacidades, en lugar de entrenar modelos especializados para tareas específicas. Antirez de Redis ha comenzado a trabajar en un motor de inferencia personalizado para DeepSeek V4 llamado ds4, ejecutándolo en un portátil de 128 gigabytes. Es un modelo realmente capaz que podría manejar del 60 al 70 por ciento de los problemas que Zechner maneja con Pi.

El costo del código y la disciplina del oficio

Zechner ha visto a personas generar 500,000 líneas de código a través de agentes en una semana. El resultado es siempre el mismo: desastre. El código nunca es gratuito porque las consecuencias eventualmente te golpean. Si crees que cualquier cantidad de código es buena ahora, solo has retrasado el castigo.

El verdadero cuello de botella en el desarrollo de software no es la velocidad de escritura o la generación de código. Es pensar, diseñar y explorar el espacio de soluciones. Los agentes son genuinamente útiles para esa fase: puedes decirle a múltiples agentes que exploren diferentes enfoques y ver los resultados más rápido. Pero el resultado de esas exploraciones no es automáticamente reutilizable. Todavía necesitas entenderlo, refactorizarlo y mantenerlo.

Para Zechner, el mayor aumento de productividad de los agentes proviene de la naturaleza asíncrona del trabajo. Puede darle a un agente una tarea, ir a una reunión y volver a los resultados. Pero no cree que ejecutar 10 agentes en paralelo multiplicará por 10 su producción. El cambio de contexto por sí solo es agotador. Lo ha hecho una o dos veces al mes, procesando 30 problemas en un día, y su cerebro queda hecho puré después.

El aspecto colaborativo es lo que más valora. Tener un agente como compañero de programación en pareja (haciendo preguntas, proponiendo opciones, explicando código) es como una bicicleta para la mente. Le ayuda a pensar mejor en los problemas que estar sentado solo. Pero eso requiere disciplina: no delegar todo a la máquina, porque cada vez que lo hace, termina en un rincón llorando porque nada es bueno y todo se desmorona.

Refactorizando Pi: Construyendo para el futuro

Pi ha acumulado equipaje histórico. Partes de él son anteriores al uso de agentes por parte de Zechner y son sólidas. Otras partes, como la exportación HTML, nunca las ha mirado y no le importan mientras se rendericen. Algunas piezas son “vibe-coded”.

El esfuerzo de refactorización tiene varios objetivos. Primero, expandirse a otros tipos de interfaces de usuario más fácilmente (web, nativa, lo que sea) sin romper las extensiones existentes. Segundo, habilitar la capacidad remota: ejecutar una sesión de Pi en una máquina y conectarse a ella desde otra, con la durabilidad y observabilidad adecuadas. Tercero, hacer que el SDK de Pi sea desplegable en Cloudflare Workers, Vercel y otros entornos, no solo en computadoras locales con bash.

Zechner está refactorizando en la rama principal porque no le importa la estabilidad en el sentido tradicional. Lo está haciendo pieza por pieza, comenzando con los paquetes de nivel más bajo que hablan con los proveedores de LLM. El agente de programación en sí seguirá viéndose y funcionando igual, pero toda la infraestructura subyacente estará limpia y será reutilizable. Espera terminar esa fase en una o dos semanas, luego pasar unas semanas más en el nuevo mecanismo de extensión donde las extensiones tienen componentes del lado del servidor y del lado de la interfaz de usuario.

Por qué Pi se ejecuta en modo YOLO por defecto

Pi no pide permiso antes de ejecutar código. Esto es intencional. Al decirle a la gente que el modo YOLO es peligroso y que deberían pensarlo, Zechner realmente hace que la gente piense en la seguridad. Quiere que miren dentro de sí mismos para buscar conciencia de seguridad y decidan cómo salvaguardar el trabajo agéntico en su propio entorno.

La respuesta suele ser la contenedorización. Si no quieres que el agente rompa tu computadora, contenedoriza el agente o las herramientas que utiliza (lectura/escritura de archivos, bash, lo que sea). Eso resuelve el problema. Pero Zechner no puede decidir esto por ti. Podría incluir el sandbox de Anthropic o bubble wrap, pero estas son soluciones incompletas. En un entorno empresarial con restricciones de infraestructura específicas, un sandbox incorporado podría no funcionar en absoluto.

Lo que existe en Claude Code es principalmente teatro de seguridad. Claude Code ahora le pregunta a un LLM si un comando bash es seguro antes de ejecutarlo en modo automático. Zechner no cree que eso sea bueno. Un LLM no puede determinar de manera confiable si un comando es seguro; solo puede adivinar basándose en patrones.

Conclusión

Pi representa una filosofía diferente: construir herramientas que los desarrolladores puedan poseer y modificar, no herramientas que posean a los desarrolladores. El éxito de Pi no se mide en funciones o puntos de referencia, sino en si Zechner puede mantener vivo a un pequeño equipo y continuar explorando aplicaciones del trabajo agéntico, desde la programación hasta la robótica y la inferencia local.

La lección más amplia es que los flujos de trabajo importan más que el hype. La estabilidad, la previsibilidad y la capacidad de personalizar tus herramientas valen más que la última función. Y el código nunca es gratuito: las consecuencias de tus acciones eventualmente te alcanzarán.