Introduction

Here are four realities of modern software development:

1. Agents can write code well.
2. Real software is still built by teams.
3. Teams that don't use agents are getting out-built by teams that do.
4. Letting each developer pair with agents however they like cannot scale.

Any useful development process has to be designed with these realities in mind. The rest of this introduction takes each one in turn. What follows is Atomic's project-tested software-development process, built around them.

Agents can write code well.

Agents complete much of the coding now, and the teams that use AI tools well are shipping software products faster than the teams that aren't. That's a change in tools, but there’s a more meaningful change software teams need to grapple with: the development process has new bottlenecks.

When writing code was the expensive part, it was also the constraint. Healthy teams organized around making that part go faster. Once agents take over the bulk of the coding, the bottleneck shifts into deciding what to build and into verifying what the agents produce.

The first of those constraints is less familiar to seasoned developers because it used to be handled automatically. In pre-agentic software delivery, experienced developers supplied missing interpretation. Vague direction and tribal knowledge didn't block progress because people bridged the gaps. Agents can’t do this well; they fill ambiguity with costly guesses unless the direction is explicit.

The process must evolve, not be reinvented

The agile fundamentals still hold, and several of them matter more than they did before.

Agents amplify good design and engineering. Strong product foundations let them reach further; weak ones are cheaper to fix than they used to be, but they still cap how far agents go.

Automated testing used to be a quality investment. With agents in the loop, it's the thing that lets them work safely at all. Without it, regressions compound faster than reviewers can catch them.

Developer tooling matters more too. Agents work better when the project has clear setup instructions, fast tests, reliable local environments, and repeatable commands for common tasks. Those investments used to save developer time; now they also give agents a safer, faster path through the work.

Architecture matters more for the same reason. Clear boundaries, fast checks, and well-factored modules let agents work on smaller pieces without breaking the whole system. A tightly coupled system pushes more decisions back onto people, because every change requires someone to understand and coordinate more of the whole system.

The disciplined version of all this—leaning hard on agents to ship quality software without losing the craft—is what we're calling agentic engineering.

What that development process has to do

A useful process has to do two things at once: absorb the new constraints that agents bring and protect the team coordination that makes software work in the first place. In practice, three things shift to make that possible.

Definition runs in parallel with Implementation to keep the next iteration fed with clear specs. Direction has to be written down, kept current, and ready before each build cycle starts, because the developer who used to carry it in their head isn't the one doing the building anymore.

The development iteration cadence gets shorter. A team leaning on agents produces more in a week than it can keep coherent over a multi-week sprint, so the iteration has to shrink to keep up. We recommend two iterations a week. Planning and Review tasks become the human checkpoints that hold the line. Shorter cycles sound like more intensity, and in the delegation itself, they are more intense. The rest of the time saved goes to protecting and expanding the human space around that work. A good process has to do both at once; teams must slow down some activities to speed up the whole process.

Direction has to be more concrete. A developer would absorb leftover ambiguity at the keyboard, so the questions that used to get resolved mid-build now have to be settled before handoff to an agent.

Investing in sustainable speed

All of these process changes cost time and attention. They’re worth it because this work is what lets a team stay fast. Not fast for a week, but fast for the life of the project.

A pre-agentic team delivers at a steady pace, bounded by how fast people can write code. An agentic team with no process delivers in an early burst and gets bogged down: drifting architecture, review that can't keep up, a codebase neither the team nor its agents can move through confidently. An agentic team with this process delivers faster than the pre-agentic team and keeps delivering because the definition, the cadence, and the handoffs are what hold the speed-up instead of letting it collapse.

So the extra work is the thing that converts a short-lived burst into a durable pace, and the agentic coding speed-up pays for that time investment with room to spare.