AI-Native Software Delivery

We kicked off the AI software delivery discussion with 1769 Denis Diderot - so we really went back. Diderot wrote a short essay about a scarlet dressing gown. He had lived modestly, came into some money, and bought the gown. Next to it his straw chair looked shabby, so he replaced it. The desk no longer suited the chair, the prints did not suit the desk, and before long he had refurnished the whole study and slipped into debt. "I was the absolute master of my old robe, but I have become the slave of my new one."

That is what happened to us with AI. We added a licence, and everything around it had to change to keep up. One licence became nine changes to how we deliver software. This is the order they hit us in.

One licence, and what a licence alone gets you

We started early, with a couple of projects run with AI assistance in early 2025, and since then we have been a bit maniacal about it. We tried GitHub Copilot, Codex, Cursor and recently Antigravity. Claude Code took over everything for us once Opus 4.5 and 4.6 arrived.

We are not alone. The JetBrains developer survey from August 2026 has 90% of professional developers using coding agents at least weekly and 68% daily, with Claude Code the most used at 39%, up from 18% in January.

Here is what a licence gets you on its own, though. Code gets written much faster. Finished work barely moves. Our chart of weekly commits against weekly issues resolved, both indexed to the pre-rollout average, shows the commits line climbing away from the issues line from the week we rolled Claude in. That difference defines today's story.

AI-assisted versus AI-native

AI-assisted delivery keeps the process and makes each step faster. Developers use agents to help them write code, but everything still comes from the developer and goes through the developer. AI-native delivery redesigns the process around the fact that implementation is now cheap, so the bottleneck moves.

The way I put it live: not people have agents. Agents have people. Development no longer has to originate with a developer, even if it still passes through one before it reaches the codebase.

Not people have agents. Agents have people.

Three things follow. Specification matters far more, because a vague ask now produces confidently wrong code in minutes. Verification becomes the constraint on speed: tests, reviews, CI. And the repository has to become machine-readable. Those three run through every domino below.

The nine dominoes

1. The developer's day. The developer is no longer the bottleneck on implementation. We have fewer developers than we have ever had, and the ratio of product people to developers is closing in on one to one. Our developers work in an internal tool called Swarm Worker: as many terminals running Claude Code as they want, across as many projects and branches as they can track.

One developer I asked to record five minutes of his day typically has four tickets in flight and spends most of his time verifying, not typing. Our best developers have not hand-written code in a year, maybe a year and a half. Around 90 shared skills, written-down processes for review, research, commits and dependency checks, do the routine work. We measure cycle time per ticket and pull requests per engineer per week.

2. A machine-readable codebase. Agents are only as good as what the repo tells them, so every project carries curated Claude files: rules for the language, the infrastructure modules, the schema conventions, what to do and what not to do.

A rule change goes through a board. The effect I can measure is onboarding: the time from a developer joining a project to their first commit is 30 to 50 percent shorter than before. We also track agent first-attempt success, and it comes straight back to these files.

3. A shared context database. Context files are not enough on a big monorepo, so every repository has its own Qdrant vector index, hosted on our own cloud: PRDs, plans, meeting and call notes, tickets, incidents. Only facts go in, so a PO or PM approves everything before it lands, and agents reach it through an MCP server when the repo files do not answer their question.

The failure mode is the poisoned well: one wrong fact shaping every later decision. Two conflicting claims are never merged; the system refutes, asks a human which is true, and archives the loser as superseded. Two people have to fail for poison to get in: the one who added it and the one who approved it.

4. CI as the trust mechanism. Fast developers with good context produced a lot of pull requests of uneven quality, not because of speed but because the rules were not institutionalised. So we became CI freaks. The analogy on the call was a busy airport: packages arrive too fast to open each one by hand, so you need a scanning machine.

Ours, on a trunk-based Go backend: a much stricter semantic PR check, linters, ticket and title checks, then an AI review, then code generation and drift checks, then unit, feature and end-to-end tests on dev containers. The AI review runs on GLM 5.2; Sonnet was expensive, and GLM cut that cost by around 80 percent for us.

Where a project allows it we also run Claude Security. All of this happens before a developer sees the pull request. No human reads a diff before the machine has said yes. We measure coverage, CI duration, which is a real problem for us right now, and the defects that escape into production.

5. Code review. More code made review the bottleneck. Our PR volume grew by around 50 percent in the last year, and we have people whose time is only review. So the agent reviews first: it labels severity, quotes the exact line, explains the failure mode and proposes two fixes, inline on the diff, advisory only. Another person still reviews what you built, but they do not get the pull request until the agents have accepted it. We measure time to merge, review turnaround, and the defects that still reach production, which should be zero and never is.

6. Requirements and the backlog. Then the pressure moved to the people writing tickets. PMs and BAs had an easier job when development was slow; now they have to feed the developers. Our BAs review tickets with their own skills, and we moved from Jira, which was too slow for us, to Plane (Linear was the runner-up, nearly the same product, noticeably pricier).

Our own agent, Greybox, is an agent swarm on the Claude API that anyone can call from Slack: a project manager describes the change in a thread, Greybox files the ticket, runs, and comes back with a pull request. On small changes in smaller projects that works about 99 percent of the time. What we have not solved is the other direction: telling the PM whether something is feasible.

7. Environments. Product people who generate code need somewhere to run it. We went from no licence and a laptop, where a prototype was a meeting, to a licence, where prototypes were shared as screenshots, to today: template repos with the guardrails and skills baked in, so a PM or BA deploys their own prototype to an internal container and shares a URL. Next is Pengu, a research project: point it at an existing repo and it spins up a dev container with generated mock services and seed data.

8. Security. Our own security action runs on every project: Trivy, token and API key scans, the static checks. Where it has been accepted we also run Claude Security, which is genuinely something else at finding problems in a repo.

9. Team and culture. A five-person project squad, BA, PM, front-end, back-end, infra, has merged into one or two product-minded developers we call product builders. We changed 20 to 25 percent of our roster over this and we are still hiring for people who take ownership of the whole thing. We still measure DORA, plus the agents' success rate and how often a human was actually needed.

What the big shops do

Where the human stays

Agents will need the engineers, not engineers will need the agents. There are four places where AI is still particularly bad, and that is where the engineer lives now: deciding what to build; architectural judgement, which is improving fast; ownership and accountability; and stakeholder management. Developers no longer have the luxury of not talking to people.

Agents will need the engineers, not engineers will need the agents.

From licence to rollout

If you are the CTO of a fifty-person team and the subscription is live and nothing else is, this is the order that worked for us. Add the licence; that is the whole first step. Assess the codebase: agents produce fact sheets, humans verify them. Set up measurement before you change anything: Jira and GitHub exist almost everywhere and show where tickets pile up.

Then tooling, then tests first, because agents work well when the core business logic is covered end to end and stays green whatever they do. Those four usually go in one batch. Then one owner per module, review agents on main, a re-assessment after each cycle, and repeat. We only have clean data for this from one project this year, and the curve does what you would hope.

Questions from the room

What does token usage cost per developer? We are not on enterprise yet, so our developers are on the team subscription, around 90 euros a month per seat. Above roughly fifty developers the pricing moves to API calls and gets considerably more expensive. The cost people forget is the pipeline: ours has grown by about 300 percent since we started.

Do you force Claude on clients, and do you adapt to their CI/CD? We are partners, not restricted. On a document-processing project where Claude is bad at the multimodal OCR work we use DeepSeek, Kimi and fine-tuned Hugging Face models. And when we join a company we adapt to their process.

Balázs asked about clients and time-and-materials. Coding has become a commodity and clients know it; some arrive with a vibe-coded tool and ask us to finish it, and that pushes prices down. Moving from five-person teams to two-person teams is not good for revenue. It is the only way forward.

Adam Drobinoha, CEO, Adroit Group