Conectia AI Dev Platform: la plataforma de desenvolupament amb IA que instal·lem en 24 hores sobre qualsevol codebase — agents, connectors i gates humans

Quan vam desplegar tres enginyers sènior i un CTO fraccional a STUVEO, els enginyers no eren tota l'entrega. Van arribar amb la Conectia AI Dev Platform —la nostra pròpia plataforma de desenvolupament, construïda sobre el nostre propi loop agèntic— i la van instal·lar sobre el codebase que STUVEO ja tenia durant les primeres 24 hores. Aquesta mateixa plataforma ja està desplegada i en funcionament a BonusIuri, MintID i ZADQ, sobre codebases que no tenien res en comú abans que hi arribéssim.

He escrit tres articles sobre què fa que un loop sigui agèntic, què costa cada arquitectura i per què el que és difícil són els guardrails. Aquest és la prova de concepte: com es veuen aquests principis instal·lats en un producte real, amb tickets reals, en una empresa que ha d'entregar aquesta setmana. Em quedaré al nivell d'arquitectura —la forma del sistema, les costures i on seuen les persones— perquè el detall de sota canvia amb cada client i la forma no.

Què vol dir aquí «una plataforma de desenvolupament»

És una expressió fàcil d'inflar, i he vist massa equips declarar-se AI-first quan el que fan servir és un chatbot. La Conectia AI Dev Platform és un arnès, no un desenvolupador autònom. És un runtime que executa el nostre loop, un conjunt de connectors que li donen capacitats, ulls i mans dins de les eines del client, un elenc d'agents especialitzats amb accés restringit a eines, i un conjunt fix de gates humans que cap agent no pot saltar-se. El model de sota és una peça intercanviable; l'arnès és el que hem construït, el que hem provat en diversos codebases i el que els enginyers que despleguem saben operar.

El que fa: agafa un ticket del roadmap del client, planifica la feina, la implementa en una branca, la prova, valida el resultat amb un segon verificador independent, prepara els canvis d'infraestructura, manté la documentació al dia i s'atura a cada punt on ha de decidir una persona. El que no fa: mergear a main, desplegar a producció, canviar un esquema, esborrar res ni tancar un ticket. Això són els gates, i és aquí on són.

La forma: un loop, cinc agents, quatre connectors, cinc gates

Cada caixa és un procés amb la seva pròpia llista d'eines permeses, el seu propi pressupost i el seu propi límit d'iteracions. Les fletxes són els únics camins que existeixen; un agent no pot arribar a un sistema per al qual no té connector. El loop és l'estructura disparador-objectiu-comprovació que vaig descriure a la primera part —es dispara amb l'estat d'un ticket, l'objectiu el comprova alguna cosa diferent del model que ha fet la feina— i corre amb l'arquitectura plan-and-execute de la segona part, perquè una tasca de la mida d'un ticket no justifica el peatge de coordinació d'una orquestració multiagent completa.

Els connectors són servidors MCP en Python, i no és casualitat

El loop toca el món del client a través de connectors, i cada connector és un servidor del Model Context Protocol escrit en Python. Quatre vénen de sèrie: JIRA, Confluence, el host del repositori (amb la seva CI) i la destinació de desplegament. Un client amb un cinquè sistema —una eina de tickets de suport, un data warehouse— rep un cinquè servidor, normalment escrit el primer dia.

Per què MCP: perquè converteix «integrar l'agent amb JIRA» en un contracte que l'agent no controla. El servidor exposa un grapat d'eines tipades —llegir el ticket, llistar els criteris d'acceptació, canviar l'estat, comentar— i l'agent no pot cridar res que no hi estigui exposat. El control d'accés viu al servidor, no en un prompt. És el principi del registre d'eines com a cadena de subministrament fet concret: el registre és codi que revisem, no una llista que el model pugui ampliar.

Per què Python: perquè els qui mantenen els connectors al client passen a ser, en poques setmanes, els enginyers del mateix client, i Python és el llenguatge que la majoria ja llegeix. Un connector que només nosaltres podem canviar és una dependència de nosaltres, i la plataforma està dissenyada per no ser-ho.

Dos connectors fan alguna cosa més que llegir. El servidor de JIRA llegeix el roadmap, no només el ticket: l'orquestrador veu l'èpica, els tickets germans i l'objectiu de l'sprint, de manera que el pla d'un ticket no contradiu el següent. El servidor de Confluence escriu: cada canvi mergeat actualitza les pàgines que descriuen el mòdul afectat, i cada decisió d'arquitectura que el loop proposa queda redactada com a decision record en el mateix format que fem servir a mà. La documentació que manté el mateix sistema que canvia el codi és l'única que he vist continuar sent exacta passat el tercer mes.

El que té de valuós tot això no és només que baixi el temps de desenvolupament i que els enginyers entreguin més ràpid i millor. La barrera que hem fet desaparèixer és la gestió de projectes. S'han acabat els scrum masters, el grooming d'sprints i les reunions d'estat per reconstruir el que el tracker ja sap. CTOs, founders, CPOs i arquitectes prenen les decisions d'alt nivell sobre el roadmap; tota la resta que abans en dèiem gestió de projectes —descompondre l'èpica, ordenar els passos, mantenir alineats el ticket, la branca i la documentació— la fa la plataforma.

Cinc agents, cadascun amb accés restringit

L'especialització no és una qüestió d'estil: és la manera que el radi de dany es mantingui petit.

1. L'orquestrador llegeix un ticket i el seu context, produeix un pla amb passos i comprovacions d'acceptació explícits, i assigna els passos a la resta d'agents. Té accés de lectura a JIRA, Confluence i el repositori, i d'escriptura a res tret del mateix pla i del comentari del ticket on es publica perquè el vegi una persona.
2. L'agent dev implementa un pas en una branca, executa la suite de tests existent i obre una pull request. Pot escriure a la seva branca i enlloc més. No pot mergear.
3. L'agent QA escriu els tests que demanen les comprovacions d'acceptació del pla, els executa contra la branca i informa. És un procés a part amb un prompt a part, precisament perquè els tests no els escrigui el mateix procés que ha escrit el codi que proven.
4. L'agent infra s'ocupa del que el canvi necessita per sota —variables d'entorn, configuració de CI, infraestructura com a codi— i prepara, mai aplica, qualsevol cosa que toqui producció.
5. El validador de codi és el segon verificador de la primera part de la sèrie, pres seriosament: un prompt diferent, sovint un model diferent, amb accés només de lectura, l'única feina del qual és intentar rebutjar la PR. Contrasta el diff amb el pla, els criteris d'acceptació, les convencions del repositori i les regles de seguretat del registre d'eines. Una PR rebutjada torna a l'agent dev amb els motius; una PR aprovada passa a una persona.

Cada agent corre sota els guardrails de la tercera part: un límit d'iteracions que salta digui el que digui el model, un pressupost de tokens per ticket, detecció de bloquejos i un checkpoint abans de qualsevol acció irreversible. El pressupost és la xifra que el CTO fraccional vigila amb més atenció el primer mes, perquè és la que acaba convertida en factura.

Els gates humans són pilars de l'arquitectura

Tot l'anterior existeix per entregar la feina en cinc punts on decideix una persona. Són fixos: el client pot afegir gates, però no treure els nostres.

• Abast. El pla de l'orquestrador es publica al ticket i una persona l'accepta abans que s'escrigui una línia de codi. És aquí on s'atrapa «l'especificació estava malament», al preu d'un comentari en lloc d'un sprint.
• Merge. Cada pull request la mergea una persona, després que l'hagi aprovada el validador. El validador redueix el que la persona ha de llegir; no substitueix la lectura.
• Desplegament. El desplegament a producció és una acció humana sobre un canvi ja preparat. L'agent infra el deixa a punt; una persona el llança.
• Irreversibles. Migracions d'esquema, esborrat de dades, canvis de permisos i qualsevol cosa que toqui la ruta de dades d'un client aturen el loop i esperen. Cap agent té l'eina per fer-ho; el connector no l'exposa.
• Decision records. Una decisió d'arquitectura que proposa el loop és un esborrany fins que la signa un enginyer. El loop detecta bé que s'està prenent una decisió; qui la pren no és ell.

Això és human in the loop com a disseny. Els gates són on els enginyers sènior que despleguem passen el temps —llegint plans, mergeant, decidint—, que sempre va ser la part cara de la feina, ara sense el teclejar.

Per què s'instal·la en 24 hores: la plataforma no dona res per suposat sobre el codebase

La xifra de 24 hores no és cap truc: es deriva del que la plataforma no pressuposa. No exigeix un llenguatge, un framework, una disposició de monorepo ni un proveïdor de CI concrets. Exigeix un repositori, un gestor de tickets, un lloc on visqui la documentació i una manera d'executar els tests, i tot codebase que entrega software té aquestes quatre coses. El dia transcorre així:

• Hores 0–4: inventari i accessos. Llegir el repositori i les seves convencions, mapar la CI, llistar els entorns, aprovisionar credencials de mínim privilegi per a cada connector. El resultat és un inventari per escrit que revisa el CTO del client.
• Hores 4–12: connectors i convencions. Aixecar els quatre servidors MCP contra les instàncies del client; codificar les convencions del repositori —noms de branca, format de commit, ordres de test, lint— al context dels agents perquè la primera PR sembli una de les seves.
• Hores 12–20: replay sobre tickets tancats. Fer córrer el loop contra tickets que l'equip ja va entregar, amb els gates tancats, i comparar plans i diffs amb el que van fer les persones. És el conjunt d'avaluació: ens diu, abans de cap feina real, on s'equivoquen els plans amb aquest codebase.
• Hores 20–24: primer ticket real. Un ticket de debò, tots els gates actius, els enginyers del client a cada gate amb els nostres al costat.

A STUVEO la Conectia AI Dev Platform va quedar instal·lada sobre el codebase existent en aquelles 24 hores, i des de llavors tres dels nostres enginyers sènior i un CTO fraccional operen els gates al costat de l'equip del client. El codebase era seu, les convencions eren seves, els tickets eren seus; el que hi vam posar nosaltres va ser el loop, els connectors i les persones que saben operar-los.

Tres codebases més, tres formes diferents, la mateixa plataforma

STUVEO és la instal·lació més recent, no la primera. Si em refio de la xifra de 24 hores és perquè la mateixa plataforma corre sobre tres codebases que no comparteixen res tret de les quatre coses que exigeix.

• Bonus Iuri és un producte legaltech: una plataforma d'anàlisi de contractes amb IA que revisa documents legals espanyols contra la legislació vigent, construïda sobre encaminament multimodel i un RAG que coneix la legislació, que vam descriure amb detall quan el vam construir. Va passar del coneixement del sector del seu fundador a un SaaS amb clients de pagament sense cofundador tècnic. Avui la plataforma porta el seu roadmap: els nous tipus de contracte i jurisdiccions arriben com a tickets, i les regles de compliment que van donar forma a l'arquitectura —que cada afirmació legal es pugui resseguir fins a un article concret— són codificades a les comprovacions del validador, de manera que una PR que trenqui aquesta cadena de traçabilitat es rebutja abans que la vegi una persona.
• MintID és un protocol d'identitat sobre cadena sobirana i el codebase més exigent dels tres: el nostre squad encastat de tres enginyers i un delivery manager construeix el nucli del protocol des del març de 2026 i, des del juliol, els seus tres SDKs verificadors en TypeScript, PHP i Python. L'encàrrec va arrencar amb 200.000 € i s'ha renovat per 400.000 € més, amb tots els lliurables en data i zero bugs. En un protocol amb nou condicions d'acceptació sempre actives i zero paràmetres de política, els gates importen més que la velocitat: res que toqui la lògica d'acceptació no es mergea sense un enginyer amb nom i cognoms, i la feina de la plataforma és garantir que aquest enginyer llegeix un diff que ja ha passat la matriu de tests dels SDKs en els tres llenguatges.
• ZADQ és una plataforma d'identificació KYB per a x402: verificació d'empreses en els fluxos de pagament HTTP 402, on qui paga o cobra és cada cop més un agent i no una persona. És el codebase més jove dels tres i aquell en què el disseny de la plataforma s'assembla més al del producte: comprovar la identitat en un pagament màquina-a-màquina és un gate, i el roadmap de ZADQ és una llista de gates. L'opera un equip amb la mateixa topologia que el de STUVEO —tres enginyers sènior i un CTO fraccional—. La instal·lació va durar el mateix dia, però l'empresa en si és molt més AI-first. Totes les regles i polítiques de l'empresa estan escrites al codebase, així que la IA entén molt millor cap a on va la companyia. Cada cop que canvia una política, el canvi s'escriu al repositori i es puja a git com un commit més. És el concepte d'empresa més avançat amb què he tingut el plaer de treballar, i és una passada.

Tres productes, tres stacks, tres mides d'equip. El loop, els connectors i els gates no van canviar; van canviar les convencions codificades el primer dia i les persones als gates.

L'objecció que em prenc més seriosament: és molta maquinària per a un ticket

Sí. Un ticket solt en mans d'un bon enginyer amb un assistent de codi no necessita res de tot això, i no instal·laria la plataforma per a un equip de dos que està entregant un prototip. L'objecció l'encerta en l'escala a partir de la qual la maquinària compensa.

Compensa on el cost d'un canvi erroni és alt i el nombre de canvis és gran: un producte amb clients de pagament, un roadmap de desenes de tickets al mes, un equip que no pot revisar cada diff a mà i tampoc no es pot permetre saltar-se la revisió. Aquí la plataforma no substitueix l'enginyer; substitueix les parts de la seva setmana que mai no van ser enginyeria —reconstruir el context des de JIRA, la documentació que va quedar endarrerida, el test que ningú no va escriure, la descripció de la PR— i el col·loca als gates, on la feina és el criteri. El loop és la peça intercanviable. Els gates, els connectors i les persones que els operen són el producte.

Què comprovaria abans de deixar que un proveïdor instal·li «una plataforma de desenvolupament amb IA» sobre el teu codebase

1. On són els gates i puc afegir-ne un? Si la resposta és un diagrama sense persones, marxa.
2. En què pot escriure exactament cada agent? Demana la llista d'eines permeses per agent, no una descripció.
3. Qui podrà canviar els connectors d'aquí a sis mesos? Si només el proveïdor, has comprat una dependència, no una plataforma.
4. Quin és el pressupost per ticket i qui el veu? Un loop sense pressupost és una factura sense sostre.
5. Ensenya'm el replay. Una plataforma que no es pot fer córrer contra els teus tickets tancats abans de tocar els reals no s'ha provat al teu codebase; s'ha provat al del proveïdor.

Si el teu codebase té un repositori, un tracker, un lloc per a la documentació i una ordre de test, la plataforma s'hi instal·la en un dia, i nosaltres portem els enginyers que l'operen. La trucada de scoping dura trenta minuts; comencem per l'inventari.