Consultoría de desarrollo agéntico

Casi todos los equipos que me encuentro han probado ya los agentes de programación. La historia se repite: alguien instala Copilot o abre un chat, la primera demo genera una función espectacular y, tres semanas después, el veredicto del equipo es que produce código malo o directamente humo.

El diagnóstico suele ser equivocado. El problema no es el modelo: es que el agente trabaja a ciegas. No conoce tu arquitectura, no puede ver tus logs, no sabe cómo se abre un PR en tu repo ni qué convenciones sigue tu equipo. Un agente sin contexto alucina con fluidez.

Desarrollo agéntico es montar esa infraestructura de contexto —y la forma de trabajar que la rodea— para que el agente deje de adivinar. Eso es lo que ofrezco como consultoría, y lo que uso yo mismo a diario.

Qué es desarrollo agéntico de verdad

No es darle un chat a los desarrolladores. Es un sistema de trabajo en el que el agente:

• Lee tu código sobre un índice real del repositorio, no con búsqueda de texto plano.
• Consulta tus sistemas: logs, base de datos, documentación de frameworks, tickets.
• Ejecuta el ciclo completo: rama, commit, PR, CI y corrección de los fallos que él mismo provoca.
• Trabaja bajo control humano: cada cambio pasa por revisión, como el de cualquier compañero.

La diferencia con el autocompletado es de categoría, no de grado. Y la diferencia con «la IA que programa sola» es que aquí un humano dirige y revisa cada paso.

Lo que se monta: la infraestructura de contexto

Esto es lo que separa un agente útil de uno que inventa. Las piezas concretas, tal como las tengo montadas en este repositorio:

• Un devcontainer como casa del agente. Todo el equipo —humano o no— trabaja dentro del mismo entorno reproducible. El de este portal levanta Postgres, Keycloak, Typesense y el gateway de modelos; el agente vive ahí dentro, con las mismas herramientas y servicios que yo.
• Servidores MCP a medida. MCP es el protocolo con el que el agente habla con tus sistemas. En este proyecto: logs en Axiom, GitHub para PRs y reviews, Postgres de solo lectura, Playwright para probar la web, documentación de Payload y Next.js vía llms.txt, y el propio CMS. Cada equipo necesita los suyos; montarlos es parte del trabajo.
• Documentación escrita para el agente. Un AGENTS.md en la raíz que orienta al agente como orientarías a un compañero nuevo, y skills con los procedimientos del equipo —incluida la skill con la que se redactan los posts de este blog—.
• El codebase indexado. GitNexus mantiene este repo mapeado: 4.925 símbolos, 11.501 relaciones y 300 flujos de ejecución. Preguntar «qué rompe si cambio esto» deja de ser un acto de fe.

Hay datos detrás de estas decisiones. Los benchmarks de LangChain muestran que llms.txt más un agente que razona qué páginas consultar supera a un RAG de embeddings para documentación de frameworks; el equipo de Claude Code trabaja sin indexación alguna, solo con búsqueda agéntica. Menos infraestructura pesada, más criterio.

La especificación manda: spec-driven development

El contexto le dice al agente dónde está; falta decirle qué hay que construir. Para eso trabajo con spec-driven development, y en concreto con SpecKit: cada funcionalidad nace como una especificación numerada en el repo —spec.md, plan de implementación, lista de tareas— que un humano revisa antes de que el agente escriba una línea. El prompt se olvida; la spec queda.

En Konect lo llevamos al extremo: una constitución del proyecto versionada con semver —sí, con sus propias notas de release— y diez specs por feature, de la transcripción de audio a los informes. El agente implementa contra la spec, no contra lo que recuerda de una conversación.

Y ahora mismo lo estoy aplicando en una demo propia: un motor de flujos y encuestas dirigido por eventos en TypeScript, construido íntegramente spec-driven. El núcleo y el adaptador React ya funcionan con sus tests; el adaptador MCP es la siguiente spec del backlog. Cada pieza tiene su spec, su plan, sus contratos y sus tests. Es la forma más limpia que he encontrado de que un agente programe lo que pediste, y no lo que entendió.

Cómo se trabaja: una mañana real de este repo

Esto pasó tal cual, desarrollando este portal. Tengo la transcripción completa:

1. Le pido al agente que consulte los logs del entorno en Axiom. Lista los datasets, lanza sus consultas y vuelve con un diagnóstico: más de mil errores en 24 horas, un NaN que llega como parámetro al filtro de taxonomías del admin y rompe las queries de Drizzle.
2. Le pido que separe el trabajo en dos PRs distintos. Clasifica los ficheros tocados, crea las ramas, commitea y abre los PRs #59 y #60, cada uno con su resumen y su plan de pruebas.
3. El CI del PR #60 falla. El agente reproduce el fallo en local, rebasea sobre main, corrige el lint y enmienda el commit con --force-with-lease.
4. Un bot de review (Devin) deja un comentario acertado: la regex \s{2,} también se tragaba los saltos de línea y destrozaba el markdown antes de indexarlo. El agente evalúa el comentario, aplica el fix sugerido y actualiza el PR.

Ninguno de estos pasos es magia: yo marco qué hay que hacer, el agente ejecuta, y todo queda en PRs que un humano revisa antes de mergear. Esa es la dinámica que hay que implantar, y es muy distinta de soltar un prompt y cruzar los dedos.

De dónde viene la experiencia

No vendo una metodología leída en un informe. Este portal —la web que estás leyendo— se construye exactamente así: devcontainer, MCP servers propios, gateway de modelos con el egress cerrado y PRs efímeros con su propio entorno. Y este mismo post lo ha redactado un agente con ese workflow: la skill de redacción de la casa, las fuentes del repo y un script propio que compila Markdown a Payload.

Antes, en Konect, montamos la misma idea en un equipo más grande: devcontainers para todo el mundo y un entorno de preview completo por cada pull request. La convicción es la misma en los dos sitios: el entorno es parte del equipo, y un agente solo es útil cuando vive dentro de él.

Cuándo tiene sentido (y cuándo no)

Encaja si tu equipo tiene un repo real, CI y revisión de código, y habéis probado los agentes sin ver resultado. También si te preocupa regalar el código a terceros: el montaje vive dentro de tu infraestructura, el acceso a modelos pasa por un gateway que controlas tú y, cuando el problema lo exige, se trabaja con modelos privados.

No encaja si no hay tests, ni CI, ni costumbre de revisar código: el agente amplifica lo que encuentra, y sin esas bases amplifica el caos. Tampoco si lo que buscas es que «la IA programe sola» sin que nadie revise.

Si tu equipo ha probado los agentes y se ha llevado una decepción, casi seguro que falta contexto, no modelo. Cuéntame cómo trabajáis y te digo qué montaría primero. Reserva una toma de contacto y lo vemos.