I’m working with a customer right now who wants to enable non-technical people to ship compliant, secure and high quality code. On infrastructure they don’t have to think about. And the first bottleneck is: people don’t have GitHub accounts. And they don’t want to bother with them. We started to see the first signs of this issue a few months ago. And now it’s starting to become more and more of a problem. And we still haven’t hit the wall with code output at agentic scale.
Non-engineers
Code produced by non-engineers still has to be compliant. Secure. Of quality. There’s no way around that. Non-engineers might not produce at the scale at which engineers can produce. But they still have to be enabled to solve their business needs. For a startup that might be a non-issue. For a Fortune 500 though, this becomes an easy way to lose billions of dollars due to a silly mistake.
What Git-based systems miss though is on simplicity for the common man. Actually, their servers miss it. In an Enterprise GitHub organisation you have to:
- Have a GitHub account
- Have signed commits
- Enable SSO to certain GitHub organisations
In a high quality codebase you have to make sure that you have checks for security, regressions, performance, compliance and what-not. Things the regular business user doesn’t have the capacity to think about. Because they just have so much other stuff to do.
If I’m a non-engineer I just want to write my wish in a chat. Or say it. Or draw it. Express it in a meaningful way. And then see it live, in front of the audience I want it for. Or start using it and see real results out there. Without worrying whether financial data would be exposed, or a security loophole. This should be handled and taken care for me.
I don’t care about continuous integration. I care about continuous delivery. And I won’t name it that way. I’ll just probably name it nothing. I’ll just expect to type something and see it on my URL.
I don’t care about branches. I care that my colleague doesn’t mess my work. Or if they do, it’s integrated in a way I expect it to be integrated.
I don’t care about code reviews. I care whether the functionality I’ve created meets my expectations. And that existing functionality plays well with mine.
Scaling output
Engineers and agentic systems are also hitting limits. Anthropic had to redesign their source control. Patrick Debois talked about agentic enablement at Tessl and a big part of it is how agents communicate their changes. We’ll see this more and more in the coming year. Most organisations don’t know it yet. They’re still bottlenecked at risk, reviews and verifications. Once they figure it out they’ll scramble for solutions when their CI just can’t keep up.
Apart from continuous integration, the current git-based systems aren’t created with merges-at-scale in mind. Stacked diffs can just handle so much. Branches isolate reality in a sea of fast changing realities. Trunk-based-development should come to the rescue but it can’t without built-in canaries, feature toggles and granular isolation.
And merging code is easier to automate than merging context. As context is only grounded in human understanding. And the current version control systems are in no way ready for highly textual codebases. Where text, even if codified, still represents a valuable part of the system. Or at least of the system’s capabilities to develop itself.
How to rethink it
The last years we were just starting to rethink how to code with agents. And now I believe we are just starting to rethink how we are getting that code out there. And making it available on demand at that scale. What happened at the beginning of 2025 with the first coding agents is happening right now with agentic source control.
I can’t say how those systems will look like. We’ll have a lot of innovation in that space. But I’d say there are a few properties we should look for in a source-control system for agents. And should it be called a source-control system? I think it’s more of an integrated-live environment. A place where your agent just lives and shows at the same time. A liveshow system.
So what should be the properties?
- Change in – live out. Each wish can get out there in seconds
- Canary by default. A wish is out there but only as long as it works
- Security is cared for. Someone has set the right security constraints
- Auditability on demand, but hidden. The system can be expected for compliance if necessary
- Replicated relative changesets. Independent, everywhere-available pieces of code
- Selective integration. Components are integrated if needed, not always
I won’t be surprised if a lot of this is built on top of Git. A bit like what the folks from GitButler do. And it’ll probably utilise Cloudflare Artifacts for the wishes we want to be out in seconds. And the solutions might be highly custom. Tailor-made to each company’s needs. Because few churn out code at Anthropic scale. Or have the ambitions or conditions for non-engineers to deploy code. Some solutions might be entirely owned by platform teams. Some by the engineers who build the applications.
The key point is: start experimenting with that. And figure it out before it becomes the problem.
