Del prompt al entorno profesional: el stack de desarrollo con agentes de IA

Escribir código con inteligencia artificial es cada vez más accesible. Construir software que resuelva el problema correcto, sea mantenible y no introduzca riesgos sigue requiriendo criterio.

Por eso, aprender a trabajar con agentes no debería reducirse a encontrar el prompt perfecto. También necesitamos entender qué modelo utilizamos, qué entorno lo ejecuta, qué información recibe, qué puede modificar y cómo comprobaremos el resultado.

Esta guía está pensada para quienes comienzan con estas herramientas y para quienes ya las usan, pero quieren ordenar las piezas de su flujo de desarrollo.

La idea central es sencilla: la IA amplía nuestra capacidad de producir software; nosotros seguimos siendo responsables de dirigir y verificar ese trabajo.

Adaptarnos sin renunciar a comprender

En un mensaje de octubre de 2026 sobre contribuciones al kernel, Linus Torvalds rechazó prohibiciones generales sobre el uso de herramientas de IA y exigió que los desarrolladores entendieran lo que estaban haciendo. Eso no significa que obligara a utilizar IA ni que considerara absurdo trabajar sin ella.

Robert C. Martin, conocido como Uncle Bob, explicó en una entrevista publicada por Aviator que había cambiado su opinión sobre estas herramientas al observar su evolución. Su entusiasmo no elimina la disciplina de pruebas ni la responsabilidad humana.

Son opiniones relevantes para entender el cambio, no pruebas de que cualquier adopción de IA mejore nuestros resultados.

La conclusión que propongo es adaptarnos con responsabilidad, sin convertir ni el rechazo ni el entusiasmo en sustitutos del análisis.

Más código no equivale a mejor software

El Octoverse 2026 de GitHub muestra un crecimiento importante de actividad. Sus cifras redondeadas pasan de 538 millones de pull requests fusionadas en 2025 a unos 1.300 millones en 2026.

La comparación incluye repositorios públicos y privados, en períodos de doce meses terminados en septiembre. GitHub recalculó los años anteriores con las mismas definiciones.

Estos datos describen volumen. Por sí solos no demuestran mayor calidad, más valor entregado ni que todo el crecimiento se deba a la IA.

Podemos producir más cambios y, al mismo tiempo, generar más trabajo de revisión, duplicar lógica o implementar requisitos mal entendidos. La productividad necesita considerar también correcciones, mantenimiento y utilidad para las personas que usan el sistema.

Soy fiel creyente de que para aprovechar esta capacidad, primero necesitamos entender qué hay detrás de la herramienta.

LLM, harness y agente: tres conceptos distintos

Para esta guía, usaremos estas definiciones operativas:

Las fronteras terminológicas varían entre proyectos. La distinción útil es separar el modelo del sistema que le permite actuar.

Por ejemplo: el modelo propone ejecutar una prueba; el harness llama a la herramienta, recoge su salida y la devuelve al modelo; el agente usa ese resultado para decidir qué hacer después.

En la distinción de Anthropic entre workflows y agentes, un workflow sigue rutas predefinidas, mientras que un agente deja al modelo decidir dinámicamente parte del proceso. No toda automatización que usa un LLM es, por eso, un agente autónomo.

Qué significa harness engineering

Podemos entenderlo como diseñar, probar y mejorar el entorno donde trabaja el agente.

Incluye decidir qué contexto recibe, qué herramientas puede utilizar, qué permisos necesita y cuándo debe detenerse o pedir ayuda. También exige definir cómo se verifica lo que produce.

La pregunta deja de ser solamente «¿qué le escribo?» y pasa a ser «¿qué condiciones necesita para trabajar correctamente?». El artículo de Anthropic sobre diseño de harnesses desarrolla esta perspectiva.

La complejidad debe justificarse

Añadir herramientas, reglas o agentes puede resolver una necesidad. También puede introducir ruido y más puntos de fallo.

Dos casos ayudan a entenderlo, sin convertirlos en una ley universal:

• Anthropic: en evaluaciones internas de MCP, reportó que Opus 4 pasó del 49% al 74% de precisión al descubrir herramientas bajo demanda. El cambio fue cómo se cargaban sus definiciones, no eliminar la biblioteca de herramientas. Fuente original.
• Vercel: al simplificar su agente interno de consultas SQL, reportó pasar de cuatro a cinco consultas resueltas sobre una muestra de cinco. También cambió la arquitectura y el contexto: el resultado no aísla solamente la cantidad de herramientas. Fuente original.

No son experimentos equivalentes ni estudios independientes que prueben que «menos siempre es mejor».

El criterio práctico es utilizar la complejidad suficiente para resolver la tarea y conservar los controles necesarios. Quitar una integración innecesaria puede ayudar. Quitar validación o revisión para simplificar puede empeorar el sistema.

Orquestación: cuándo tiene sentido delegar

Un orquestador puede dividir un objetivo en encargos, proporcionar contexto a subagentes e integrar sus resultados. Es el patrón orchestrator-workers.

Un ejemplo: mientras el coordinador revisa la implementación de un fallo, un subagente investiga el comportamiento de una dependencia. Si las tareas son independientes, pueden avanzar en paralelo. Si una necesita el resultado de la otra, esa dependencia no desaparece por utilizar varios agentes.

Cada encargo necesita alcance, contexto, límites y un criterio de finalización. El coordinador no debería asumir que el subagente recibe automáticamente todo su historial ni aceptar sus conclusiones sin evidencia.

Delegar consume contexto, tiempo y revisión. Para una tarea pequeña, un solo agente puede ser la mejor decisión. Abrir varias terminales tampoco equivale a coordinar trabajo.

Agentes que podemos utilizar

Probablemente ya escuchaste hablar de Claude Code, Codex y OpenCode. Quiero detenerme en Pi porque propone un enfoque que me resulta especialmente interesante: partir de un núcleo mínimo y ampliarlo según las necesidades del proyecto. Más que presentarlo como una evolución superior a los demás, lo veo como una alternativa para quienes buscan adaptar el entorno del agente a su propia forma de trabajar.

Pi: un núcleo mínimo que se adapta al flujo

Mario Zechner creó Pi porque quería recuperar el control sobre la herramienta con la que trabajaba: entender qué contexto recibía el modelo, inspeccionar lo que ocurría y modificar el entorno cuando lo necesitara. En su artículo original cuenta cómo llegó a esa decisión.

Lo interesante de Pi es que parte de un núcleo pequeño que podés ampliar según tu forma de trabajar. Permite leer y modificar archivos, ejecutar comandos, cambiar de proveedor y ajustar el flujo mediante extensiones y skills.

Para mí, ahí está su atractivo: tener una base que podés adaptar sin incorporar de entrada funciones que quizás no necesitás. Esa libertad también exige prestar atención a los permisos y controles que requiere tu proyecto.

Y hay un detalle importante si buscás información sobre Pi: en aquel artículo Mario explicaba por qué no incorporaba MCP, pero el sitio actual ya anuncia soporte integrado. Conviene separar la historia del proyecto de lo que ofrece hoy.

Skills: procedimientos reutilizables

Una skill reúne instrucciones y recursos para una tarea. En el formato Agent Skills, una carpeta contiene un archivo SKILL.md y puede incluir referencias, ejemplos o scripts. El cliente puede descubrirla y cargar sus instrucciones cuando corresponde.

La skill orienta el procedimiento. Una herramienta ejecuta acciones. Una skill de Playwright, por ejemplo, enseña cómo utilizar Playwright CLI; no reemplaza esa herramienta.

Estos ejemplos cubren necesidades diferentes:

No hace falta instalar todas (ni lo recomiendo, ya lo expliqué más arriba). Algunas se solapan y sus instrucciones pueden competir. Conviene revisar su contenido y procedencia, especialmente si incluyen scripts.

Una skill no reentrena el modelo ni garantiza que siga siempre el procedimiento (mantené esto siempre en mente). Las promesas de ahorro de código o tokens también necesitan evaluarse en el contexto real.

Contexto y memoria no cumplen la misma función

El agente necesita información del trabajo actual y puede beneficiarse de recuperar conocimiento anterior. Son necesidades relacionadas, pero distintas.

El servidor Memory es una implementación de referencia, no necesariamente un sustituto completo de los otros productos.

La memoria útil requiere mantenimiento: seleccionar qué guardar, recuperar lo pertinente y corregir información obsoleta. Un grafo desactualizado o una decisión antigua pueden orientar mal al agente. No conviene guardar secretos ni asumir que instalar memoria captura automáticamente todas las conversaciones. En lo personal, he trabajado mucho con Engram y ha sido de mucha ayuda para trabajar en equipo o trabajar entre distintos proveedores de modelos o agentes sin perder contexto.

MCP: conectar al agente con el trabajo del equipo

MCP es un protocolo de integración, no una categoría funcional como memoria o análisis estático. Un servidor puede ofrecer información, acciones o ambas.

Tres integraciones ilustran el flujo:

• GitHub MCP: repositorios, issues, pull requests y ejecuciones de Actions.
• Notion MCP: documentación, páginas y conocimiento del proyecto.
• Figma MCP: contexto de diseños, componentes y variables para orientar la implementación.

Obviamente hay muchísimos mcp para múltiples casos de uso, pero al igual que te dije en las skills, no es necesario que los instales todos; úsalos en base a la necesidad de los proyectos.

Un ejemplo práctico de los anteriores mencionados puede ser imaginar un cambio que parte de requisitos en Notion, consulta un diseño en Figma y termina en un PR de GitHub. La conexión no autoriza cualquier operación: leer un documento y modificarlo son permisos diferentes.

Verificar antes de aceptar

El código generado necesita controles independientes de la explicación del agente. Una respuesta convincente no demuestra que el cambio funcione.

En este caso te recomiendo que revises los tipos de perfiles que ofrece gentle-shell para cubrir este escenario de verificación de lo que genera el agente.

Análisis estático con SonarQube

SonarQube ayuda a identificar defectos potenciales, riesgos de seguridad y problemas de mantenibilidad. Puede aportar reglas y criterios de calidad al flujo de revisión.

Complementa las pruebas. La cobertura que muestra procede de reportes generados por otras herramientas: no significa que SonarQube haya ejecutado esas pruebas ni que sean suficientes.

Dependencias y configuración con Trivy

Trivy permite buscar vulnerabilidades conocidas, secretos y configuraciones inseguras en objetivos compatibles. Lo que revisa depende del objetivo y de los escáneres habilitados.

También necesitamos verificar la procedencia de nuestras herramientas de seguridad. Trivy sufrió un incidente de cadena de suministro en marzo de 2026; el proyecto publicó sus conclusiones y medidas de remediación. Antes de incorporarlo a una demo o pipeline, corresponde revisar los avisos y la integridad de la distribución elegida.

Ningún escáner limpio demuestra ausencia de vulnerabilidades. Estas herramientas no sustituyen pruebas funcionales, revisión humana ni una evaluación de seguridad cuando el riesgo la exige.

Organizar sesiones y continuar desde el celular

Después de preparar un agente y definir sus controles, podemos pensar en gestionar varias sesiones.

Herdr TUI es un multiplexor de terminal orientado a agentes. Organiza paneles y sesiones y permite observar qué trabajos necesitan atención.

Orca se presenta como un ADE: un entorno de desarrollo para agentes que combina terminales, navegador y trabajo por tareas con git worktrees. Un worktree es otra carpeta de trabajo del repositorio; separa cambios, pero no es un sandbox de seguridad.

Para acceder desde otros dispositivos, las piezas vuelven a tener funciones diferentes:

En un flujo remoto, el celular puede actuar como cliente mientras el agente trabaja en otra máquina. Esa máquina debe seguir encendida y accesible. El multiplexor, el cliente móvil y la red no se reemplazan entre sí.

El cifrado tampoco reemplaza permisos o autenticación. Y que una conexión utilice Tailscale no significa que todas las comunicaciones de las aplicaciones circulen por ella. Conviene revisar por separado la privacidad de Moshi, sus notificaciones y la configuración utilizada.

Un ejemplo de flujo completo, sin instalarlo todo

Supongamos que necesitamos corregir una validación incorrecta en un formulario. Un recorrido posible sería:

1. Definir el comportamiento esperado y cómo comprobarlo.
2. Pedir al agente que identifique el código relevante, utilizando contexto adicional solo si hace falta.
3. Consultar documentación de una dependencia si existe una duda concreta.
4. Solicitar el cambio mínimo que resuelva el caso y una prueba que lo verifique.
5. Ejecutar las comprobaciones pertinentes y revisar el diff y los resultados.
6. Documentar una decisión duradera si realmente aporta valor y preparar el PR para revisión.

Es un ejemplo propuesto, no una demostración ejecutada ni una receta que exija todas las herramientas mencionadas.

La orquestación, la memoria y el acceso móvil entran cuando resuelven una necesidad observada. No deberían convertirse en requisitos previos para comenzar.

El stack profesional empieza por el criterio

Un buen entorno de desarrollo con agentes permite saber qué está ocurriendo: qué se pidió, qué información recibió el sistema, qué acciones realizó y qué evidencia respalda el resultado.

El punto de partida puede ser pequeño: un agente, una tarea delimitada y una forma de comprobarla. Las demás piezas se incorporan cuando justifican su coste.

La ventaja no está en producir la mayor cantidad de código. Está en convertir esa capacidad en cambios útiles, verificables y mantenibles.