Humans Think, AI Does the Rest: How We AI-fied Our Development Process

In February we admitted that we haven't written a line of Metapad's code by hand. In May we described how we build Metapad's models by talking to them. Since then the process has moved one step further, and it is worth saying plainly what it has become:

We work at the conceptual level. AI does the rest.

The people on the team decide what to build, why, and how it should feel. Everything below that — writing the work items, the code and the tests, merging, building, deploying, triaging the regression run, writing the help pages and the changelog — is done by AI agents, several at a time. We come back down from the conceptual level only where we have decided in advance that a person needs to look.

That sounds like a claim about AI. It turned out to be a claim about something else: keeping everyone, human and machine, working from the same picture. That is what this post is about.

---

At a Glance

• Humans think, AI does the rest. One person works on concepts and decisions. AI agents (Claude Code) write the Issues, the code and the tests, run the release, triage the regression run and write the documentation.
• Since January 2026 we have built 334 versions of Metapad: more than one per calendar day, each followed by a full regression run.
• The codebase is substantial: at image 334, about 355,000 lines of Rust, about 60,000 of them dedicated test code, plus about 77,000 lines in our two Python test suites for end-to-end and API tests.
• The plan, every decision, every test verdict and every review lives in a Metapad model: today 3,975 elements, including 946 work items, 1,328 automated end-to-end tests and 344 test scenarios.
• The documentation lives in a second Metapad model, bilingual, written by Claude, with screenshots and the changelog generated automatically.
• Every project gets its own model, forked from one shared template. AI agents connected to several models at once work across them.
• AI helps set the roadmap. Agents use Metapad through the same MCP interface our customers use, and they find problems we would not have found ourselves.
• Behind the agents stand people at transentis and at our clients who build with Metapad every day. Their feedback sets the roadmap too.
• The bottleneck is not the AI. It is human attention, so we budget it, release by release.
• The same pattern works for any organisation that delivers change: your delivery process is an enterprise system, and it deserves a digital twin.

---

1. Two levels of work

It helps to draw the line explicitly, because it is the line the whole process is built around.

People work at the conceptual level. AI agents do the rest, reading from and writing to one shared model. People are pulled back into the detail only where the review budget says so.

The top level is where people add the most and AI the least: it is about intent, taste and responsibility. The levels below are where AI is now faster and more thorough than we are. The arrow back up matters as much as the levels themselves: a person is pulled back into the detail only where the review budget says so, and that budget is set when the work is planned, not when something goes wrong.

2. The problem with more than one agent

One AI assistant in one conversation is easy to work with: you both see the same history. Run three in parallel and that shared history is gone. Agent A doesn't know that agent B changed the data format an hour ago. The agent fixing a bug tomorrow doesn't know that we decided today not to fix it that way. And the person in the middle — me — becomes a human message bus, repeating context from one window to the next. That is the opposite of working at the conceptual level.

We tried the obvious remedies: longer prompts, shared notes files, more careful handovers. They all decay. A notes file is out of date the moment someone forgets to update it, and nobody can ask it a question.

What we needed was a shared record that every participant reads and writes, that knows the difference between a concept, a plan, a decision and a verdict, and that can answer questions like "what is still waiting for a review?" without someone reading through everything.

We already had one. It is the product we are building.

3. The release is a graph

Metapad's own development is described in a Metapad model. Its structure is deliberately simple:

Node type	What it holds
Phase	The roadmap: a rough order of themes, each with a main track and parallel tracks
Concept	Design ideas and the reasoning behind them
Implementation Plan	For the bigger jobs: phases, affected parts, migration steps, test checklist
Issue	A unit of work: what to do, how we'll know it's done, how much human attention it needs
Image	One build of the application, numbered — "image 334"
Test Scenario	What a test is supposed to prove, written in plain language
Test and Test Run	Each automated test, and each regression run against a build

The conceptual level lives in the top three types. When we talk an idea through, the result is a Concept: what we want, why, what we considered instead, and which phase of the roadmap it belongs to. Many Concepts sit for a while before anyone designs them in detail — on purpose. Good ideas get better when they have time to meet other ideas.

Claude writes the Issues. A bug report, an idea from a customer call or a gap found during testing becomes a conversation. Claude reads the relevant code, proposes the root cause and the fix, and writes the Issue into the model with the affected files, a testing note and links to the Concepts it touches. I confirm the decisions; I don't type the ticket.

We plan releases for the week, on a rolling basis, in a Metapad grid view: Issues as rows, upcoming images as columns. Assigning an Issue to a release is one click; moving it to a later one when something slips is another.

The value is in the relationships. An Issue ships in an image: before the build, that's the plan; after it, it's the release manifest. "What's in 334?" is a single question to the graph. A test run ran against an image, and each test that flipped from red to green is linked to the run where it turned. So "what did this build fix, and what did it break?" is a walk across the graph, not an afternoon with log files.

Two properties on every Issue carry most of the discipline:

• A gate. One line naming the condition that closes the Issue, checkable by someone who isn't the one who wrote the code: "this end-to-end test passes", "this log line appears after the next run", "Oliver decides". Every check records whether it is met or not yet met.
• A review budget. none (an automated test is enough), glance (a person needs to see it — layout, wording, a rendered PDF) or judgment (a person needs to try it and decide). This is the arrow back up in the picture above.

The agents connect to this model over Metapad's MCP interface, the same way your own AI tools can. When an agent finishes, it writes its results onto the Issue. When I decide something, the decision is written onto the Issue too. Nothing important lives only in a chat window.

4. A release day: image 334

Here is one day, more or less as it happened.

Morning — concepts. The day started with an Issue we had moved from release to release for weeks, because we weren't sure what we wanted. Talking it through, it turned out to be one half of a bigger idea our clients had been asking for: forking a model, making a large change in the fork while small fixes keep reaching the published version, and merging the fork back. That became a new Concept, with its stages, the reasoning about where it sits on the roadmap, and the one small step worth taking now so that today's forks can be merged later. The original Issue shrank to something we could ship in a few days. None of this involved code. All of it ended up in the model.

Late morning — planning image 334. The main item was gating multiplayer games: hosting a game session becomes a Team-plan feature with a monthly allowance. The release manager — itself an agent — read the image's Issues, flagged the decisions still open and brought each one to me with a recommendation. Two items didn't fit and moved out. One was cut down to the part we actually needed. Then it bundled the rest into three topic branches and briefed an implementation agent for each.

Midday — three agents in parallel. Each agent works in its own isolated copy of the code, with its own database and its own server, and writes and runs the tests for its own feature before it reports back. One of them made a design call better than the one I had proposed: the brief said to show other players' inputs by widening what the server sends to each player; the agent found that a player's decision is an input, which the server's computed results never contain, and delivered the decisions from the game's decision log instead — and only for rounds that are already resolved, so nobody sees a move before the round commits. The setting it built ("Visible to other players") turns out to be useful for a whole class of scenarios: the same game played once with and once without transparency.

Afternoon — reviews as a gallery. Of the seven Issues in the image, two needed me, both glance. The agents attached screenshots in English and German to the Issues, the release manager looked at them first, and my review took a few minutes. The release manager wrote the review onto each Issue, because a review that isn't recorded didn't happen.

Evening — merge, build, deploy, regress. The release manager merged each branch only after the combined code passed the full test suite, because two branches that each pass on their own can still break each other. The build runs on a dedicated build machine in the cloud; then a deployment to our test environment and a full regression run: every automated test, against the build that will go to production. The run is triaged by another agent, in its own copy of the code.

And along the way. A flaky database test, chased down by one of the agents, turned out to be a symptom of something structural in how our development setup reaches a shared database. Ten minutes of conversation later, that was a new Concept with a clear first step, planned into the next image. That is the conceptual level at work: the agent found the problem; the person decided what it meant.

5. More than one project

Metapad is not our only project. transentis runs several: some change every day, some only a few times a year. We give each project its own model, all forked from one shared template that holds the delivery structure from section 3 — Phases, Concepts, Issues, releases, test scenarios, gates and review budgets.

Why not one big graph for everything? Because projects differ in rhythm, in who has access and in how much noise they produce. A project that changes twice a year shouldn't have to live inside one that ships every day, and a client project often shouldn't be visible to everyone. Separate models keep each project's picture clean.

What connects them is the AI. An agent can be connected to several models at once, so a question that spans projects — "what does the new account service mean for each app that uses it?" — is answered by an agent reading all the models involved, and the result is written back into each one. The shared template keeps the models comparable: the same types, the same gates, the same review budgets, so a person who knows one project's model can read any of them.

6. The documentation is a model too

Metapad's help pages, feature descriptions and blog — including this post — live in a second Metapad model, in English and German. Claude writes and maintains it the same way it maintains the code: proposing changes, which we review before anything is published. From that one model we generate the website, the in-app help and the knowledge our in-app AI assistant draws on.

Two parts of it run on their own:

• The changelog is filled from the release. Because the model knows which Issues shipped in which image, the changelog entries for a release are written from exactly that list, by the AI, and signed off by a person before they go out.
• Screenshots are generated, not taken. Each screenshot in the help is a recipe in the model: which model to open, what to click, what to capture. A script produces it in both languages, and an agent checks every image before it is published. When the user interface changes, the screenshots follow.

7. Who sets the roadmap: people — and AI

Agents can build a feature. On their own, they can't tell us which feature matters. That comes from people using Metapad for real work — at transentis and at our clients.

Modellers build with Metapad every day: the 16 substantial showcase templates in our template library, and more than 20 substantial production models, ours and our clients'. They are our most demanding users. When something is awkward to do, slow on a large model or confusing in German, we hear about it — usually the same day, and usually together with the model where it happened. The fork-and-merge Concept from section 4 started exactly like that, with clients who need to prepare a large change without disturbing what is already published.

But there is a second source we didn't expect to matter this much: AI that uses the product it builds. Most of those models are built with AI too, through the same MCP interface our customers use. An agent that builds, queries and simulates real models runs into problems no human tester would hit, because it uses the product differently, more often and more literally. One example from the week of image 334: while preparing a demo, an agent ran a simulation of a translated model through MCP and noticed that the German run produced different numbers from the English one — with no error, just plausible-looking wrong results. A person would almost certainly not have compared the two. The fix shipped in the same image.

That is why we built Metapad MCP first: every capability an agent might need is available to it through the same interface, from the start. It is what lets agents build the product, use the product and report on the product. And it is a pattern we expect to hold far beyond Metapad: give AI the tools to work with the products it creates, and it gets a better picture of the product than any specification could give it. Products whose AI can only write code, but not use what it wrote, will learn more slowly.

8. What we learned

Draw the line between the levels, and keep people above it. The people's job is the conceptual level: intent, trade-offs, responsibility. The moment a person starts relaying context between agents or typing tickets, the process has slipped.

The human is the bottleneck — so spend the human deliberately. AI agents produce code and tests faster than anyone can review them. Without a budget, every change waits for a person and the release stalls. With one, most changes are proven by automated tests, and the person's time goes to the handful of things only a person can judge.

A review that isn't recorded didn't happen. A review done weeks ago, never written down, was still listed as pending — so "review done" became a property a tool can read, and the release tooling now warns when one is missing. A step that gets forgotten twice becomes a tool's job.

Test the feature before the build; test the build for regressions. Every feature's test is written together with the feature, by the same agent, and runs green before anything is merged. The full regression run on the build is there to catch what nobody expected, not to find out whether the new feature works.

Give the agents your production logs. Our servers report to a cloud logging service, and Claude can query it directly. Instead of guessing why a test failed only under load, the agent lines up the failing test with what the server recorded at that moment, and comes back with evidence rather than a theory.

Make the shared record the path of least resistance. Agents write to the model because it is how they get their instructions and where their results go. If writing to the record were an extra step, it would be skipped.

9. Why this matters beyond us

Nothing in section 3 is specific to software. Replace "image" with "release", "quarterly plan" or "change request", and "test" with "acceptance check", and you have the structure of almost any organisation that delivers change.

That is the point we keep coming back to on this blog. Metapad is a platform for enterprise digital twins, built on computational knowledge graphs. A delivery process is exactly the kind of organisational system that benefits from one. It has state (what is planned, what is done), responsibility (who decides, who reviews) and change over time (what each release fixed and broke). Your version-control system, your ticket tool and your CI pipeline are the detailed systems; each one is authoritative for its own slice. The twin is the overall picture that connects them and answers the questions none of them can answer alone: what is this release waiting for? Who needs to look at what? Did we keep the promise we made in that decision?

And as AI agents join your team as colleagues rather than tools, that shared, queryable record is what lets your people stay at the conceptual level — and lets the AI do the rest.

10. What's Next

Want to try it? Metapad is free to begin at app.metapad.ai. Connect your AI assistant over MCP and start modelling your own delivery process.

Want a head start? Fork our delivery template — the same structure we use for every project: phases, concepts, work items, releases, test scenarios, gates and review budgets, with a starter guide for connecting your AI agents.

Want to see it in action? Join one of our free webinars at academy.transentis.com.

People think. The AI does the rest. The graph remembers why.