The repository is no longer the centre
GitHub and GitLab are bringing agents into their tools. But they are fitting them into a way of working that was built around code. When machines write the code, something else matters.
For years, our development has revolved around one thing: the repository. A ticket describes the work. Someone creates a branch, writes code and opens a pull request. A colleague reads it, asks questions and approves it. The code lands on the main branch. GitHub and GitLab turned that loop into an industry, and for a long time it worked well.
Today, agents write a large share of our code: for Workspace, for Shopcloud, for our apps and games. And the more they write, the clearer it becomes that the loop no longer fits the work we actually do.
An afternoon with three agents
Here is an example of something we run into all the time. We are building a small game. One agent works on rendering, a second on the game logic, a third writes tests that run on Linux and Windows. Each delivers solid work, each opens its pull request.
Then we play the first round, and it takes too long. Not a little too long, but long enough that the fun is gone.
That is where the real work starts, and at first it has little to do with code. Which assumption was wrong? Which of the open tasks still make sense? What the logic agent built yesterday is based on the old round length. The tests check something we no longer want. And the rendering agent knows none of this, because its session ended hours ago.
None of it is in the repository. There are three clean pull requests. What is missing is the link between what we wanted to achieve, the decision that just changed and the changes it affects.
The big platforms have noticed
It would be cheap to say GitHub and GitLab are asleep. They are not. For a year GitHub has let agents from different vendors work, be watched and be steered through Agent HQ and Mission Control. At Universe two days ago it added "Copilot Projects", announced with the line "Give Copilot a goal": agents work in parallel across several repositories towards one goal, and the session follows you between app, editor, command line and web. GitLab made its Duo Agent Platform generally available in January, with agents across the whole lifecycle, self-managed included. In May its CEO wrote: "Software will be built by machines, directed by people."
GitHub supplied the best sentence itself. Jay Parikh said at Universe: "Completed work, not more code, is the output that matters." I agree without reservation.
And yet, look closely and the loop is the same: a ticket or work item, an agent session, a branch, a pull request, a review. The agents have become faster and more numerous, but they run on tracks that were laid for people showing each other code.
More code is not more progress
The numbers match what we see every day. GitHub reports that its coding agent created more than a million pull requests between May and September 2025 alone. The 2025 DORA report calls AI an "amplifier": teams ship more, and instability rises with it. In Stack Overflow's survey, two thirds of developers name results that are "almost right, but not quite" as their biggest frustration. And open-source projects are struggling with a flood of generated contributions, so much that GitHub now lets maintainers switch pull requests off entirely.
Writing is no longer the bottleneck. Deciding is. What holds now? What do we throw away? What changed about the goal, and what follows from it? A tool that mainly makes reading lines of code easier improves the wrong step.
What we should really be keeping
When agents write the code, the code is no longer the most valuable thing we own. Code can be generated again. What cannot be generated again is the chain behind it: what are we building? Which decisions did we make along the way, and why? Which work depends on which decision? And against which goal, with which inputs, did we check a result?
When the goal changes, as with our overly long game round, that chain is what should become visible. Not as a list of changed files, but as a question: these three tasks rest on the old assumption, these tests check the wrong thing, and this decision has to be made again.
And the work should outlive a single session. An agent stops, a machine fails, another agent from another vendor should carry on. Git keeps the code safe. It does not keep the state of the work: the intent, the open questions, the checks done so far.
Four objections I take seriously
The goal has always mattered. Of course. We have always built software for customers. But the goal lived in people's heads: in the conversation with the customer, in the developer who asked when something didn't fit, in the colleague reviewing the change who knew what it was really about. Agents don't carry that knowledge. They weren't in the meeting with the customer, they don't remember yesterday, and when the goal changes, none of them finds out on their own. So what is new is not that the goal matters. What is new is that nobody can carry it around in their head on the side any more. It has to live where the work happens.
The big platforms are catching up. Yes. "Give Copilot a goal" points exactly this way, and former GitHub CEO Thomas Dohmke has founded Entire, a company that stores the reasoning of agents next to the commits. So this is not about what the platforms can do. A goal attached to a repository and a goal that repositories, agents, tests and infrastructure line up behind are two very different things.
Specs have failed before. Also true. Looking at the new spec-driven tools for Martin Fowler's site, Birgitta Böckeler warned that we might get the downsides of model-driven development and of language models at once, and said she would rather review code than piles of markdown. I understand that. But to me a goal is not a requirements document that has to be finished up front. It changes with everything we learn, and that is exactly why it needs a home.
The evidence is thin. Right again. In 2025 METR measured experienced developers being slower with AI, and its February update calls its own new data unreliable. I am not claiming agents make everything faster. They move the work: away from writing, towards leading. And for leading, we hardly have any tools yet.
Why we are building Kernonaut
We did not come up with these questions at a desk. We run into them every day, with our own software. That is why we are building Kernonaut, a platform in which the product goal is the basis of development. Agents get their assignments from it, results are checked against it, and when the goal changes, it should show which work and which decisions are affected. You work on your own machines or on cloud machines you have explicitly approved.
Kernonaut is still in development, and I don't want to promise anything here that isn't running yet. But I am fairly sure the centre is shifting. The repository will stay, just as the file system stayed. It just won't be the place where we decide what gets built.
The product goal has always been what matters most. When agents build, it also becomes the most important interface. And right now, nobody is really keeping track of it.
Sources: GitHub Universe 2026 · Mission Control and Agent HQ · GitLab Duo Agent Platform · GitLab "Act 2" · Octoverse 2025 · DORA 2025 · Stack Overflow 2025 · Switching off pull requests · Entire · Böckeler, spec-driven development · METR, February 2026