Atomic recently published Agentic Engineering for Teams, our process-level guide to pairing with AI agents for sustainable speed. This post is the view from the trenches. For the past two months, my team has been piloting agentic development on a HIPAA-compliant healthcare application, following a version of that process. An AI agent ships pull requests end-to-end: not autocomplete, but a pipeline where the agent implements the feature, writes the tests, and opens the PR.
Two months in, the surprise isn’t how much we handed off. It’s how much of our job stayed the same. If anything, the human work didn’t shrink; it condensed.
A note before the details: we treated the guide as exactly that, a guide rather than law. Everyone on this team splits time across other projects, so we couldn’t hold the full-team cadence the process describes. We also had a tight budget paired with unusually deep product definition, and that combination shaped everything below. This is one project’s experience, not a prescription.
Here’s our agentic development process.
Definition happens twice, at two altitudes. First, we meet as a team and refine a brief: the product-level shape of the feature, hashed out by humans. We talk a lot, but we can’t count on everyone being in every conversation, so those conversations don’t evaporate: we record and transcribe most of our meetings and team chats and feed them into the system’s knowledge base. By the time a developer picks up a brief, the AI agent can find what the team decided last Tuesday. That knowledge base isn’t a dumping ground, though. It gets curated like code: superseded decisions are marked as replaced, and summaries stay current, because an agent grounded on stale context is worse than one that has to ask.
That developer then runs a spec-writing skill with the agent. It reads the brief, greps the codebase, checks the knowledge base for prior decisions, and comes back with only the genuinely open questions: the key decisions that need a human answer before implementation starts. The resulting spec is held to a demanding bar. The agent must be able to ship it end-to-end without asking a single follow-up question. The spec is reviewed and committed to the repo like code, and then one command executes it. From there, the agent:
- works in an isolated branch
- implements the spec
- runs the test gates
- opens the PR
Every human decision gets front-loaded into a cheap conversation instead of surfacing mid-implementation as a guess.
We went slow before we went fast.
None of this speed showed up in our first two sprints, and that was deliberate. We spent them laying foundations:
- whiteboarding the core schema and architecture ourselves
- defining the layer rules and patterns we wanted followed
- refining the skills the agent uses to spec and ship
- writing it all into the instructions the agent reads on every run
We reviewed those early PRs closely and tweaked the system after each one until we were satisfied with what came out the other end. Only then did we open the throttle. That order matters. The agent extends our patterns; it doesn’t originate them. Wholesale delegation is only safe once there’s something solid to extend.
Here’s what we handed over.
Implementation, wholesale. A feature spanning a new database table, API routes, a background job, a new page, and end-to-end tests routinely went from committed spec to reviewable PR in a day. The spec sticks around as documentation afterward.
The tedium around the code. Test writing, review-feedback fixes, branch and PR mechanics, even the recurring environment snags that used to eat a morning. The pipeline also enforces part of our compliance posture by running our PHI-pattern guard on every spec before executing it.
The first pass of code review. An automated reviewer comments on every PR, and resolving every thread is a merge requirement. Human review happens by exception. Consequential designs get talked through at the spec stage, before any code exists. If an implementation PR diverges meaningfully from its spec, we record the divergence and have that conversation too.
This is where humans stayed in the loop.
Each of these lessons became an explicit rule the agent now follows.
Deciding what “shippable” means. Left alone, the agent split features across multiple tidy PRs that were miserable to test end-to-end. The rule: a feature never spans PRs; it ships as atomic commits within one. Only a human doing the testing feels that pain, so a human had to define the standard.
Accepting the work. Early on, “fixes TICKET-123” magic words in PR descriptions auto-closed tickets at merge, before QA had touched anything. The rule: our Linear automations move tickets through every other state as branches and PRs progress, but nothing automated touches the Done column. QA owns “done.” Merging is not acceptance.
Refereeing parallel work. Two agent runs on parallel branches claimed the same next database migration number, a collision that serial human work almost never hits. Our tooling resolved it silently rather than loudly. The rule: the repo docs now spell out how to renumber safely. Sequencing parallel work is still a human judgment call.
The Takeaway
Notice what’s left on the human side. We still refine product direction as a team and make the judgment calls on specs. We still handle the consequential reviews, decide what “done” means, and sequence the parallel work. None of that is a new job description. It’s what good software teams have always done. We just don’t type most of the code anymore.
There’s an honest cost to name, too. The bulk of our day-to-day shifted into testing and a much tighter feedback loop, and in its own way that’s more exhausting than writing the code was. When reviewable work arrives every day instead of every week, verification becomes the job, and the pace of change never lets up. That’s what “condensed” means in practice: the hours are denser, because nearly all of them are judgment.
What the pilot really changed is legibility. When implementation is delegated, the human contributions stop hiding inside it, and you can finally see which decisions genuinely need a person. That’s what sustainable speed has looked like for us. The agent provides the speed, while the conversations, reviews, and acceptance calls we’ve always made are what make it sustainable.