Conectia AI Dev Platform: the AI Development Platform We Install in 24 Hours on Any Codebase — Agents, Connectors and Human Gates

When we deployed three senior engineers and a fractional CTO into STUVEO, the engineers were not the whole delivery. They arrived with the Conectia AI Dev Platform — our own development platform, built on our own agentic loop — and installed it on STUVEO's existing codebase in the first 24 hours. The same platform is already deployed and running at BonusIuri, MintID and ZADQ, on codebases that had nothing in common before we arrived.

I have written three posts on what makes a loop agentic, which architectures cost what and why the guardrails are the hard part. This one is the proof of concept: what those principles look like installed on a real product, with real tickets, in a company that needs to ship this week. I will stay at the architecture level — the shape of the system, the seams, and where the humans sit — because the detail below that changes per client and the shape does not.

What «a development platform» means

The phrase is easy to overclaim and I've seen way too many teams claiming they are AI-first while they are just using a chatbot. The Conectia AI Dev Platform is a harness, not an autonomous developer. It is a runtime that runs our loop, a set of connectors that give the loop capabilities, eyes and hands, inside the client's tooling, a roster of specialised agents with narrow tool access, and a fixed set of human gates that no agent can bypass. The model underneath is a commodity for swap; the harness is what we built, what we have proven across several codebases, and what the engineers we deploy know how to operate.

What it does: takes a ticket from the client's roadmap, plans the work, implements it on a branch, tests it, validates the result with a second, independent checker, prepares infrastructure changes, keeps the documentation current, and stops at every point where a human has to decide. What it does not do: merge to main, deploy to production, change a schema, delete anything, or close a ticket. Those are gates and this is where they sit.

The shape: one loop, five agents, four connectors, five gates

Every box is a process with its own tool allowlist, its own budget and its own iteration cap. The arrows are the only paths that exist; an agent cannot reach a system it has no connector for. The loop is the single trigger-goal-check structure I described in part one — trigger from a ticket state, goal checkable by something other than the model that did the work — run with the plan-and-execute architecture from part two, because the coordination tax of full multi-agent orchestration is not earned by a ticket-sized task.

Connectors are Python MCP servers, and the choice is deliberate

The loop touches the client's world through connectors, and every connector is a Model Context Protocol server written in Python. Four ship by default: JIRA, Confluence, the repository host (with its CI), and the deployment target. A client with a fifth system — a ticketing tool for support, a data warehouse — gets a fifth server, usually written on day one.

Why MCP: because it turns «integrate the agent with JIRA» into a contract the agent does not own. The server exposes a small set of typed tools — read the ticket, list the acceptance criteria, transition the state, comment — and the agent can call nothing that is not exposed. Access control lives in the server, not in a prompt. That is the tool-registry-as-supply-chain principle made concrete: the registry is code we review, not a list the model can extend.

Why Python: because the engineers who maintain the connectors at the client are the client's engineers within a few weeks, and Python is the language most of them already read. A connector that only we can change is a dependency on us, and the platform is designed so that it is not.

Two connectors do more than fetch. The JIRA server reads the roadmap, not just the ticket: the orchestrator sees the epic, the sibling tickets and the sprint goal, so a plan for one ticket does not contradict the next one. The Confluence server writes: every merged change updates the pages that describe the affected module, and every architecture decision the loop proposes is drafted as a decision record in the same format we use by hand. Documentation that is maintained by the system that changes the code is the only documentation I have seen stay accurate past month three.

The virtue of all this is not only that development time drops and the engineers ship faster and more capably. The one barrier we have obliterated is project management. No more scrum masters, no more sprint grooming, no more status meetings to reconstruct what the tracker already knows. CTOs, founders, CPOs and architects take the high-level decisions on the roadmap; everything else that used to be called project management — breaking the epic down, sequencing the steps, keeping the ticket, the branch and the documentation in agreement — the platform handles.

Five agents, each with restricted access

Specialisation is not a stylistic choice; it is how the blast radius is kept small.

1. The orchestrator reads a ticket and its context, produces a plan with explicit steps and explicit acceptance checks, and assigns steps to the other agents. It has read access to JIRA, Confluence and the repository, and write access to nothing except the plan itself and the ticket comment where the plan is posted for a human to see.
2. The dev agent implements a step on a branch, runs the existing test suite, and opens a pull request. It can write to its branch and nowhere else. It cannot merge.
3. The QA agent writes the tests the plan's acceptance checks call for, runs them against the branch, and reports. It is a separate process with a separate prompt precisely so that the tests are not written by the process that wrote the code they test.
4. The infra agent handles what the change needs beneath it — environment variables, CI configuration, infrastructure-as-code — and prepares, never applies, anything that touches production.
5. The code validator is the second checker from part one of the series, taken seriously: a different prompt, often a different model, with read-only access, whose only job is to try to reject the PR. It checks the diff against the plan, the acceptance criteria, the repository's conventions and the security rules in the tool registry. A PR it rejects goes back to the dev agent with the reasons; a PR it passes goes to a human.

Each agent runs under the guardrails from part three: an iteration cap that fires regardless of what the model claims, a token budget per ticket, stall detection, and a checkpoint before anything irreversible. The budget is the number the fractional CTO watches most closely in the first month, because it is the one that turns into an invoice.

The human gates are true pillars of the architecture

Everything above exists to deliver work to five points where a person decides. They are fixed; a client can add gates but cannot remove ours:

• Scope. The orchestrator's plan is posted on the ticket and a human accepts it before any code is written. This is where «the specification was wrong» gets caught, at the cost of a comment instead of a sprint.
• Merge. Every pull request is merged by a human, after the validator has passed it. The validator reduces what the human has to read; it does not replace the reading.
• Deploy. Production deployment is a human action on a prepared change. The infra agent stages; a person ships.
• Irreversibles. Schema migrations, data deletion, permission changes and anything that touches a customer's data path stop the loop and wait. No agent has the tool to do these; the connector does not expose it.
• Decision records. An architecture decision the loop proposes is a draft until an engineer signs it. The loop is good at noticing that a decision is being made; it is not the one who makes it.

This is human-in-the-loop as a design. The gates are where the senior engineers we deploy spend their time — reading plans, merging, deciding — which is the work that was always the expensive part, now with the typing removed.

Why it installs in 24 hours: the platform assumes nothing about the codebase

The 24-hour figure is not a stunt; it follows from what the platform does not assume. It does not require a particular language, framework, monorepo layout or CI vendor. It requires a repository, a ticket tracker, a place documentation lives and a way to run tests — and every codebase that ships software has those four. The day runs like this:

• Hours 0–4: inventory and access. Read the repository and its conventions, map the CI, list the environments, provision least-privilege credentials for each connector. The output is a written inventory the client's CTO reviews.
• Hours 4–12: connectors and conventions. Stand up the four MCP servers against the client's instances; encode the repository's conventions — branch naming, commit format, test commands, lint — into the agents' context so the first PR looks like one of theirs.
• Hours 12–20: replay on closed tickets. Run the loop against tickets the team already shipped, with the gates closed, and compare the plans and diffs with what humans did. This is the eval set: it tells us, before any live work, where the plans are wrong for this codebase.
• Hours 20–24: first live ticket. One real ticket, every gate on, the client's engineers at each gate with ours beside them.

At STUVEO the Conectia AI Dev Platform was installed on the existing codebase in those 24 hours, with three of our senior engineers and a fractional CTO operating the gates alongside the client's team from then on. The codebase was theirs, the conventions were theirs, the tickets were theirs; what we brought was the loop, the connectors and the people who know how to run it.

Three more codebases, three different shapes, the same platform

STUVEO is the most recent installation, not the first. The reason I trust the 24-hour figure is that the same platform is running on three codebases that share nothing but the four things it requires.

• Bonus Iuri is a legaltech product: an AI contract-analysis platform that reviews Spanish legal documents against the actual legislation, built on multi-model routing and a legislation-aware RAG that we described in detail when we built it. It went from a founder's domain expertise to a paying SaaS without a technical co-founder. Today the platform runs its roadmap: new contract types and jurisdictions arrive as tickets, and the compliance rules that shaped the architecture — traceability of every legal claim to a specific article — are encoded in the validator's checks, so a PR that breaks the transparency chain is rejected before a human sees it.
• MintID is a sovereign-chain identity protocol, and the hardest codebase of the three: our embedded squad of three engineers and a delivery manager has been building the protocol core since March 2026 and, since July, its three verifier SDKs in TypeScript, PHP and Python. The engagement opened at €200,000 and renewed for €400,000 more, with every deliverable on date and zero bugs. On a protocol with nine always-on acceptance conditions and zero policy knobs, the gates matter more than the speed: nothing that touches the acceptance logic merges without a named engineer, and the platform's job is to make sure that engineer is reading a diff that already passed the SDK test matrix in all three languages.
• ZADQ is a KYB identification platform for x402 — business verification for the HTTP-402 payment flows where the party paying or getting paid is increasingly an agent, not a person. It is the youngest codebase of the three and the one where the platform's own design is closest to the product's: an identity check on a machine-to-machine payment is a gate, and ZADQ's roadmap is a list of gates. A team with the same topology as STUVEO's — three senior engineers and a fractional CTO — operates it. The install took the same day, but the company itself is far more AI-first. All of the company's rules and policies are written into the codebase, so the AI has a much deeper understanding of where the company is going. Whenever a policy changes, the change is written into the repository and pushed to git like any other commit. It is the most advanced company concept I have ever had the pleasure to work with, and it is a blast.

Three products, three stacks, three team sizes. The loop, the connectors and the gates did not change; the conventions encoded on day one and the people at the gates did.

The objection I take most seriously: this is a lot of machinery for a ticket

Yes. A single ticket handled by a good engineer with a coding assistant needs none of this, and I would not install the platform for a team of two shipping a prototype. The objection is right about the scale at which the machinery pays.

Where it pays is where the cost of a wrong change is high and the number of changes is large: a product with paying customers, a roadmap of dozens of tickets a month, a team that cannot review every diff by hand and cannot afford to skip the review either. There, the platform is not replacing the engineer; it is replacing the parts of the engineer's week that were never engineering — the reconstruction of context from JIRA, the documentation that drifted, the test nobody wrote, the PR description — and putting the engineer at the gates where judgement is the work. The loop is the commodity. The gates, the connectors and the people at them are the product.

What I would check before letting any vendor install «an AI development platform» on your codebase

1. Where are the gates, and can I add one? If the answer is a diagram with no humans in it, walk away.
2. What can each agent write to, exactly? Ask for the tool allowlist per agent, not a description.
3. Who can change the connectors in six months? If only the vendor, you have bought a dependency, not a platform.
4. What is the per-ticket budget and who sees it? A loop without a budget is an invoice without a ceiling.
5. Show me the replay. A platform that cannot be run against your closed tickets before it touches live ones has not been tested on your codebase; it has been tested on the vendor's.

If your codebase has a repository, a tracker, a documentation home and a test command, the platform installs on it in a day, and we bring the engineers who run it. The scoping call is thirty minutes; we start with the inventory.