Agents change the physics of development. They can watch, adapt, and coordinate continuously, yet we force them into branch-centric workflows built around the limitations of human developers. How can we move toward an Agent-Native development workflow? What if we stopped treating branches as the default unit of parallel work and started treating change sets, contracts, and live verification as the unit of collaboration?
Rather than adapting AI agents to human-centric workflows, we should redesign software development with agents as primary users.
The workflow we inherited
Software development has always been shaped by human constraints. Processes are built around limited attention spans, the human brain's capacity, and developers’ uneven skill levels. Then there’s the common tale passed down through generations of engineers: if two engineers edit the same file at the same time, they will, sooner or later, collide. After the dark ages of locked files and isolated copies, Git branches emerged as a pragmatic compromise. We isolate work, reduce interference, and then merge it all together.
Not because it is the optimal solution, but it is merely the best compromise, a coping mechanism for the cognitive limits of humans.
The new contributor we pretend is a faster human.
Now, we’re adding a new type of contributor type to the team. AI agents that don’t have the same limits as human team members. They can write code, refactor modules, generate tests, and keep documentation in sync, all at a speed that makes human developers feel extremely slow.
Industry narratives frame this as replacement: agents will replace developers. So we plug them into the same assembly line, expecting increased output. Predictably, we take a workflow built for humans and turn the dial up to eleven.
Soon, pull requests pile up on the human developers' to-do list. Reviews stop being about quality and become quick triage decisions. Under pressure, humans approve quickly out of 'pragmatism' or delegate reviews to agents and call it 'at scale'. Just to preserve familiar processes rather than question whether they still make sense. Not long, and both approaches will be promoted as best practices.
However, this shift leads to downstream consequences. Quality metrics suffer as bugs slip through unchecked and technical debt accumulates, eroding overall code stability and undermining the agent’s contribution.
Human morale declines when developers feel their contributions are reduced to a mechanical process devoid of craftsmanship and creativity.
Where the friction concentrates
Let’s take a step back. Much of the frustration in modern development workflows comes from branch isolation. Branches help, but they also create separate timelines in which assumptions change, context is lost, and the real impact only becomes apparent when we merge everything back together.
When you look at what slows teams down, the pattern is clear. Duplicate work occurs when two people fix the same problem without knowing about each other’s progress. Isolated changes can seem fine and pass tests, but fail when combined. New features that work independently might break after merging because parts don’t fit. The more complex the codebase, the more complex the PR reviews. The longer a branch exists, the more likely it is to cause merge conflicts and the less likely it is to be thoroughly reviewed.
Even our tools are a confession that we accept this as normal. We invent rituals, write more tickets to keep changes small and the scope narrow, push for immediate PR reviews, and have CI pipelines to prove that merges were safe and that the code still works. We introduce naming conventions, stricter PR templates, more checks and branch rules, stronger definitions of done, appoint sheriffs, add rules against opportunistic refactoring, and hold more meetings to align on changes. While many of these practices are useful, they still rest on the assumption that parallel work requires isolation, because human attention is the bottleneck and integration is a separate phase.
This attachment to our rituals reflects our identity within a human-centric development culture, pointing to the broader challenge of embracing the necessary cultural shift toward a mindset in which process and mindset are inseparable.
Agents change the physics of development
Human developers compromised on branches because they need a stable context bubble. They can’t keep the entire system in mind. They can’t constantly adapt to new contexts. They require uninterrupted time to think, concentrate, to reach “the flow”. Branching is a cognitive prosthetic to solve one problem at a time.
Agents do not have those limitations; they can adapt to changes instantly and are not interrupted. Not long, and they can work with nearly unlimited context, watch files, rerun suites, and update approaches immediately as context changes. Agents retrieve details on demand and coordinate at a pace humans can’t match. One agent may own tests, another may focus on implementation, a third may handle documentation, and another may manage performance.
And yet we treat agents like humans who type a bit faster and don’t rest. We use the same process: hand them tickets, send them to work in isolation, and wait until they return with pull requests ready for human review. We funnel everything through the same integration bottleneck. We scale output without scaling the coordination model.
This is where a branch-centric workflow falls short. If your team has many contributors who can act continuously, isolation is not the only way to work in parallel. Isolation keeps changes hidden until the pull request is merged, so other agents can't adapt to or use new code until it’s merged. Humans solve this through communication, daily standups, and async updates.
But how does this work when much of the team is software? What does alignment look like for agentic AI?
Do agents dream of electric sheep?
One obvious approach is to assign a 'coordinator' or 'orchestrator' agent that mimics the role of a human lead developer or project manager. We are seeing workflows built on existing version control systems increasingly emphasize change sets over branches.
Both models (and there are a few more) are still centered on human cadence. Humans supervise, Humans review, humans approve, humans merge - because the human mind is limited in its capabilities and human developers have different skill levels.
The harder question isn’t about new tools. It’s whether we’re ready to let go of the workflows and habits that have shaped software development for decades. This questions the deep-rooted mindset associated with human cadence, underscored by an ingrained belief that human supervision is essential at every step.
How can we achieve unparalleled parallelism?
This mindset shift is simple to say and hard to implement. We should move away from treating branches as the default unit of parallel work. Instead, parallel work should be seen as collaboration, with changes, contracts, and live verification as the unit of collaboration.
Future workflows should focus on evolving change sets within a single review thread, enabling a truly continuous process. We should also consider APIs for change sets to facilitate agent communication within the same codebase.
In this agent-oriented workflow, the codebase remains shared. Each contributor’s changes are tracked as first-class objects with clear ownership, traceability, and interfaces to ensure visibility and responsiveness. Instead of separate branches, imagine a continuous stream of proposed changes that are combined, tested, and accepted in real time.
Now imagine a 'change ledger' that lets each agent track its own change sets. This ledger would expose an API that other agents can use to verify changes and receive real-time updates. Agents could subscribe to changes they need and use them as soon as they are stable. Humans could also see what’s happening and what’s stable in real time. At any given time, the workflow and codebase are transparent, the system is easy to observe, and progress is visible in real time.
What becomes possible when work is visible
A traditional branch-centric workflow is like a series of cascading waterfalls, each branch representing an isolated stream. Work progresses independently through various channels, only to merge at the end, often resulting in sudden turbulence and inefficiencies. In contrast, imagine a live mesh, a flexible, interconnected network where changes flow freely and dynamically adapt to one another in real time. A mesh-like coordination that allows for seamless integration and continuous collaboration.
Agents can act as watchers, not just workers. If one agent owns the API contract and another handles implementation, the implementation agent can adjust as soon as the change is stable. A third agent building a consumer can do the same. Coordination is no longer the bottleneck; now it happens in real time through clear interfaces.
The mental model of code quality and code testing could shift from a binary gate to a live dashboard that monitors the entire application.
In an agent-first model, stakeholders could see which system components are functioning, which tests are failing, who is responsible, and what actions are underway in real time. Not only after they ran all test suites in a separate step once a feature's development is done.
Humans no longer need to review every change to assess product health; they can monitor signals, review contracts, and focus on critical behaviors. When issues arise, agents can be deployed immediately to address problems and facilitate real-time recovery.
As a result, the perception of collaboration changes. Instead of treating isolation as the default, we can design for structured concurrency, real super-charged parallel engineering. One agent produces a change set. Another checks it for consistency. A third expands test coverage. A fourth looks for performance regressions. If all happens at the same time, integration is no longer a conflict between timelines. Then, it is a shared view of the same change and the evidence that it works in a running application.
The Future of Dev Workflows Is Not a Better Branch Strategy
Our workflows always mirror the capabilities of our contributors. As software development teams evolve, our workflows and models must adapt as well.
We stand at a critical juncture in the evolution of software development. We can keep evolving branch management and spend the next decade fighting the same problems at a higher velocity. Or we can step back and ask what it would mean to design development around shared reality, explicit contracts, live verification, and traceable change ownership.
With agents as part of the team, we redefine what it means to collaborate. The team is no longer constrained by the same parameters that shaped our previous processes.
I don't have a ready-made solution, a tool to sell, or a workflow to promote, but it’s time to talk about what a true agentic workflow could be. I’d love to hear your ideas and thoughts: let’s figure this out together.
Top comments (0)