Six years ago I wrote a blog post titled “Take The Fear Out Of Git Push”. The main idea was that developers should be able to write whatever code they want and then checks should happen asynchronously and eventually any issues would be discovered and corrected by the system.
Press enter or click to view image in full size
That idea became one of the core principles of my product, Reliza Hub at the time, now ReARM. One very specific use case I had in mind back then was to protect supply chains via an evidence platform over CI/CD.
Fast forward to 2026, and that same principle matters even more. AI agents can now produce orders of magnitude more code in a unit of time than humans. This is where controls, such as QA, approvals, security, and others, increasingly become major bottlenecks.
I still believe that we must build systems to optimize for development velocity, but such optimization feels very different now. If you thought back in 2020 that you could persuade developers to write secure code, adhere to all the best practices and correct anything you don’t like during one-on-ones, then welcome to 2026, where you’re dealing with agents you have no direct behavioral control over.
This is where the asynchronous control systems I have been talking about form the past 7+ years win. The key point is that you’re not trying to pinpoint every single state or every single commit. Instead, you only have two tasks:
- One - Ensure the integrity of the chain - that every single change made to the code is valid and not malicious. And this part needs to be largely automated within the evidence platform.
- Two - Assess the state that you are actually planning to release against the previously released state at well-defined release boundaries.
In other words, you want to keep track of every change that happened to make sure the integrity is preserved, but no longer review each single incremental change synchronously. Instead you would be making higher-confidence release decisions only when required, moving from one trusted releasable state to the other. And yes, you would have to do a lot of checks at such release points, but that is an order of magnitude smaller problem than the traditional SDLC we are used to.
Interested in details? I’ll be writing more posts with practical examples how to achieve that, here is a starter applicable to SBOMs that will be expanded during my talk at OWASP Global AppSec 2026 in Vienna. Also I wrote recently that we should now treat development machines as untrusted - which should make things more manageable in the world of weekly supply chain attacks.
TL;DR: We need to remove the fear of change, be it done by a human developer or an agent. Instead, we should rely on an asynchronous system of record that can guide us what is being released and what exactly we need to control.