Conectia AI Dev Platform: la plataforma de desarrollo con IA que instalamos en 24 horas sobre cualquier codebase — agentes, conectores y gates humanos

Cuando desplegamos tres ingenieros senior y un CTO fraccional en STUVEO, los ingenieros no eran toda la entrega. Llegaron con la Conectia AI Dev Platform —nuestra propia plataforma de desarrollo, construida sobre nuestro propio loop agéntico— y la instalaron sobre el codebase que STUVEO ya tenía en las primeras 24 horas. Esa misma plataforma ya está desplegada y en funcionamiento en BonusIuri, MintID y ZADQ, sobre codebases que no tenían nada en común antes de que llegáramos.

He escrito tres artículos sobre qué hace que un loop sea agéntico, qué cuesta cada arquitectura y por qué lo difícil son los guardrails. Este es la prueba de concepto: cómo se ven esos principios instalados en un producto real, con tickets reales, en una empresa que tiene que entregar esta semana. Me quedaré en el nivel de arquitectura —la forma del sistema, las costuras y dónde se sientan las personas— porque el detalle por debajo cambia con cada cliente y la forma no.

Qué significa aquí «una plataforma de desarrollo»

Es una expresión fácil de inflar, y he visto a demasiados equipos declararse AI-first cuando lo que usan es un chatbot. La Conectia AI Dev Platform es un arnés, no un desarrollador autónomo. Es un runtime que ejecuta nuestro loop, un conjunto de conectores que le dan capacidades, ojos y manos dentro de las herramientas del cliente, un elenco de agentes especializados con acceso restringido a herramientas, y un conjunto fijo de gates humanos que ningún agente puede saltarse. El modelo de debajo es una pieza intercambiable; el arnés es lo que construimos, lo que hemos probado en varios codebases y lo que los ingenieros que desplegamos saben operar.

Lo que hace: toma un ticket del roadmap del cliente, planifica el trabajo, lo implementa en una rama, lo prueba, valida el resultado con un segundo verificador independiente, prepara los cambios de infraestructura, mantiene la documentación al día y se detiene en cada punto en el que tiene que decidir una persona. Lo que no hace: mergear a main, desplegar a producción, cambiar un esquema, borrar nada ni cerrar un ticket. Esos son los gates, y ahí es donde están.

La forma: un loop, cinco agentes, cuatro conectores, cinco gates

Cada caja es un proceso con su propia lista de herramientas permitidas, su propio presupuesto y su propio límite de iteraciones. Las flechas son los únicos caminos que existen; un agente no puede llegar a un sistema para el que no tiene conector. El loop es la estructura disparador-objetivo-comprobación que describí en la primera parte —se dispara con el estado de un ticket, el objetivo lo comprueba algo distinto del modelo que hizo el trabajo— y corre con la arquitectura plan-and-execute de la segunda parte, porque una tarea del tamaño de un ticket no justifica el peaje de coordinación de una orquestación multiagente completa.

Los conectores son servidores MCP en Python, y no es casualidad

El loop toca el mundo del cliente a través de conectores, y cada conector es un servidor del Model Context Protocol escrito en Python. Cuatro vienen de serie: JIRA, Confluence, el host del repositorio (con su CI) y el destino de despliegue. Un cliente con un quinto sistema —una herramienta de tickets de soporte, un data warehouse— recibe un quinto servidor, normalmente escrito el primer día.

Por qué MCP: porque convierte «integrar el agente con JIRA» en un contrato que el agente no controla. El servidor expone un puñado de herramientas tipadas —leer el ticket, listar los criterios de aceptación, cambiar el estado, comentar— y el agente no puede llamar a nada que no esté expuesto. El control de acceso vive en el servidor, no en un prompt. Es el principio del registro de herramientas como cadena de suministro hecho concreto: el registro es código que revisamos, no una lista que el modelo pueda ampliar.

Por qué Python: porque quienes mantienen los conectores en el cliente pasan a ser, en pocas semanas, los ingenieros del propio cliente, y Python es el lenguaje que la mayoría ya lee. Un conector que solo nosotros podemos cambiar es una dependencia de nosotros, y la plataforma está diseñada para no serlo.

Dos conectores hacen algo más que leer. El servidor de JIRA lee el roadmap, no solo el ticket: el orquestador ve la épica, los tickets hermanos y el objetivo del sprint, de modo que el plan de un ticket no contradice el siguiente. El servidor de Confluence escribe: cada cambio mergeado actualiza las páginas que describen el módulo afectado, y cada decisión de arquitectura que el loop propone queda redactada como decision record en el mismo formato que usamos a mano. La documentación que mantiene el mismo sistema que cambia el código es la única que he visto seguir siendo exacta pasado el tercer mes.

Lo valioso de todo esto no es solo que baje el tiempo de desarrollo y que los ingenieros entreguen más rápido y mejor. La barrera que hemos hecho desaparecer es la gestión de proyectos. Se acabaron los scrum masters, el grooming de sprints y las reuniones de estado para reconstruir lo que el tracker ya sabe. CTOs, founders, CPOs y arquitectos toman las decisiones de alto nivel sobre el roadmap; todo lo demás que antes llamábamos gestión de proyectos —descomponer la épica, ordenar los pasos, mantener alineados el ticket, la rama y la documentación— lo hace la plataforma.

Cinco agentes, cada uno con acceso restringido

La especialización no es una cuestión de estilo: es la manera de que el radio de daño se mantenga pequeño.

1. El orquestador lee un ticket y su contexto, produce un plan con pasos y comprobaciones de aceptación explícitos, y asigna los pasos al resto de agentes. Tiene acceso de lectura a JIRA, Confluence y el repositorio, y de escritura a nada salvo el propio plan y el comentario del ticket donde se publica para que lo vea una persona.
2. El agente dev implementa un paso en una rama, ejecuta la suite de tests existente y abre una pull request. Puede escribir en su rama y en ningún otro sitio. No puede mergear.
3. El agente QA escribe los tests que piden las comprobaciones de aceptación del plan, los ejecuta contra la rama e informa. Es un proceso aparte con un prompt aparte, precisamente para que los tests no los escriba el mismo proceso que escribió el código que prueban.
4. El agente infra se ocupa de lo que el cambio necesita por debajo —variables de entorno, configuración de CI, infraestructura como código— y prepara, nunca aplica, cualquier cosa que toque producción.
5. El validador de código es el segundo verificador de la primera parte de la serie, tomado en serio: un prompt distinto, a menudo un modelo distinto, con acceso de solo lectura, cuyo único trabajo es intentar rechazar la PR. Contrasta el diff con el plan, los criterios de aceptación, las convenciones del repositorio y las reglas de seguridad del registro de herramientas. Una PR rechazada vuelve al agente dev con los motivos; una PR aprobada pasa a una persona.

Cada agente corre bajo los guardrails de la tercera parte: un límite de iteraciones que salta diga lo que diga el modelo, un presupuesto de tokens por ticket, detección de bloqueos y un checkpoint antes de cualquier acción irreversible. El presupuesto es la cifra que el CTO fraccional vigila con más atención el primer mes, porque es la que acaba convertida en factura.

Los gates humanos son pilares de la arquitectura

Todo lo anterior existe para entregar el trabajo en cinco puntos donde decide una persona. Son fijos: el cliente puede añadir gates, pero no quitar los nuestros.

• Alcance. El plan del orquestador se publica en el ticket y una persona lo acepta antes de que se escriba una línea de código. Aquí es donde se atrapa «la especificación estaba mal», al precio de un comentario en lugar de un sprint.
• Merge. Cada pull request la mergea una persona, después de que la haya aprobado el validador. El validador reduce lo que la persona tiene que leer; no sustituye la lectura.
• Despliegue. El despliegue a producción es una acción humana sobre un cambio ya preparado. El agente infra lo deja listo; una persona lo lanza.
• Irreversibles. Migraciones de esquema, borrado de datos, cambios de permisos y cualquier cosa que toque la ruta de datos de un cliente detienen el loop y esperan. Ningún agente tiene la herramienta para hacerlo; el conector no la expone.
• Decision records. Una decisión de arquitectura que propone el loop es un borrador hasta que la firma un ingeniero. El loop detecta bien que se está tomando una decisión; quien la toma no es él.

Esto es human in the loop como diseño. Los gates son donde los ingenieros senior que desplegamos pasan el tiempo —leyendo planes, mergeando, decidiendo—, que siempre fue la parte cara del trabajo, ahora sin el tecleo.

Por qué se instala en 24 horas: la plataforma no da nada por supuesto sobre el codebase

La cifra de 24 horas no es un truco: se deriva de lo que la plataforma no presupone. No exige un lenguaje, un framework, una disposición de monorepo ni un proveedor de CI concretos. Exige un repositorio, un gestor de tickets, un sitio donde viva la documentación y una forma de ejecutar los tests, y todo codebase que entrega software tiene esas cuatro cosas. El día transcurre así:

• Horas 0–4: inventario y accesos. Leer el repositorio y sus convenciones, mapear la CI, listar los entornos, aprovisionar credenciales de mínimo privilegio para cada conector. El resultado es un inventario por escrito que revisa el CTO del cliente.
• Horas 4–12: conectores y convenciones. Levantar los cuatro servidores MCP contra las instancias del cliente; codificar las convenciones del repositorio —nombres de rama, formato de commit, comandos de test, lint— en el contexto de los agentes para que la primera PR parezca una de las suyas.
• Horas 12–20: replay sobre tickets cerrados. Correr el loop contra tickets que el equipo ya entregó, con los gates cerrados, y comparar planes y diffs con lo que hicieron las personas. Es el conjunto de evaluación: nos dice, antes de cualquier trabajo real, dónde se equivocan los planes con este codebase.
• Horas 20–24: primer ticket real. Un ticket de verdad, todos los gates activos, los ingenieros del cliente en cada gate con los nuestros al lado.

En STUVEO la Conectia AI Dev Platform quedó instalada sobre el codebase existente en esas 24 horas, y desde entonces tres de nuestros ingenieros senior y un CTO fraccional operan los gates junto al equipo del cliente. El codebase era suyo, las convenciones eran suyas, los tickets eran suyos; lo que pusimos nosotros fue el loop, los conectores y las personas que saben operarlos.

Tres codebases más, tres formas distintas, la misma plataforma

STUVEO es la instalación más reciente, no la primera. Si me fío de la cifra de 24 horas es porque la misma plataforma corre sobre tres codebases que no comparten nada salvo las cuatro cosas que exige.

• Bonus Iuri es un producto legaltech: una plataforma de análisis de contratos con IA que revisa documentos legales españoles contra la legislación vigente, construida sobre enrutamiento multimodelo y un RAG que conoce la legislación, que describimos con detalle cuando lo construimos. Pasó del conocimiento del sector de su fundador a un SaaS con clientes de pago sin cofundador técnico. Hoy la plataforma lleva su roadmap: los nuevos tipos de contrato y jurisdicciones llegan como tickets, y las reglas de cumplimiento que dieron forma a la arquitectura —que cada afirmación legal se pueda rastrear hasta un artículo concreto— están codificadas en las comprobaciones del validador, de modo que una PR que rompa esa cadena de trazabilidad se rechaza antes de que la vea una persona.
• MintID es un protocolo de identidad sobre cadena soberana y el codebase más exigente de los tres: nuestro squad integrado de tres ingenieros y un delivery manager construye el núcleo del protocolo desde marzo de 2026 y, desde julio, sus tres SDKs verificadores en TypeScript, PHP y Python. El encargo arrancó con 200.000 € y se renovó por 400.000 € más, con todos los entregables en fecha y cero bugs. En un protocolo con nueve condiciones de aceptación siempre activas y cero parámetros de política, los gates importan más que la velocidad: nada que toque la lógica de aceptación se mergea sin un ingeniero con nombre y apellidos, y el trabajo de la plataforma es garantizar que ese ingeniero lee un diff que ya ha pasado la matriz de tests de los SDKs en los tres lenguajes.
• ZADQ es una plataforma de identificación KYB para x402: verificación de empresas en los flujos de pago HTTP 402, donde quien paga o cobra es cada vez más un agente y no una persona. Es el codebase más joven de los tres y aquel en el que el diseño de la plataforma se parece más al del producto: comprobar la identidad en un pago máquina-a-máquina es un gate, y el roadmap de ZADQ es una lista de gates. Lo opera un equipo con la misma topología que el de STUVEO —tres ingenieros senior y un CTO fraccional—. La instalación llevó el mismo día, pero la empresa en sí es mucho más AI-first. Todas las reglas y políticas de la empresa están escritas en el codebase, así que la IA entiende mucho mejor hacia dónde va la compañía. Cada vez que cambia una política, el cambio se escribe en el repositorio y se sube a git como un commit más. Es el concepto de empresa más avanzado con el que he tenido el placer de trabajar, y es una gozada.

Tres productos, tres stacks, tres tamaños de equipo. El loop, los conectores y los gates no cambiaron; cambiaron las convenciones codificadas el primer día y las personas en los gates.

La objeción que más en serio me tomo: es mucha maquinaria para un ticket

Sí. Un ticket suelto en manos de un buen ingeniero con un asistente de código no necesita nada de esto, y no instalaría la plataforma para un equipo de dos que está entregando un prototipo. La objeción acierta en la escala a partir de la cual la maquinaria compensa.

Compensa donde el coste de un cambio erróneo es alto y el número de cambios es grande: un producto con clientes de pago, un roadmap de decenas de tickets al mes, un equipo que no puede revisar cada diff a mano y tampoco puede permitirse saltarse la revisión. Ahí la plataforma no sustituye al ingeniero; sustituye las partes de su semana que nunca fueron ingeniería —reconstruir el contexto desde JIRA, la documentación que se desactualizó, el test que nadie escribió, la descripción de la PR— y lo coloca en los gates, donde el trabajo es el criterio. El loop es la pieza intercambiable. Los gates, los conectores y las personas que los operan son el producto.

Qué comprobaría antes de dejar que un proveedor instale «una plataforma de desarrollo con IA» sobre tu codebase

1. ¿Dónde están los gates y puedo añadir uno? Si la respuesta es un diagrama sin personas, márchate.
2. ¿En qué puede escribir exactamente cada agente? Pide la lista de herramientas permitidas por agente, no una descripción.
3. ¿Quién podrá cambiar los conectores dentro de seis meses? Si solo el proveedor, has comprado una dependencia, no una plataforma.
4. ¿Cuál es el presupuesto por ticket y quién lo ve? Un loop sin presupuesto es una factura sin techo.
5. Enséñame el replay. Una plataforma que no se puede correr contra tus tickets cerrados antes de tocar los reales no se ha probado en tu codebase; se ha probado en el del proveedor.

Si tu codebase tiene un repositorio, un tracker, un sitio para la documentación y un comando de test, la plataforma se instala encima en un día, y nosotros traemos a los ingenieros que la operan. La llamada de scoping dura treinta minutos; empezamos por el inventario.