The last feature I shipped was built by a team of five. None of them were human.
A backend agent handled the API layer. A mobile agent built the Swift UI. A third wrote integration tests. A fourth reviewed every pull request. And a team lead agent coordinated the whole operation — assigning work, detecting blockers, and escalating to me only when it needed a human decision.
I didn't write a single line of that code. But I architected the solution, defined the acceptance criteria, and made every judgment call that mattered. Eight issues closed, 37 story points shipped, in one execution plan. This isn't a thought experiment. It's how I build software now.
The Copilot Ceiling
The industry is stuck on the copilot metaphor. Autocomplete on steroids. A helpful assistant that sits beside you and suggests the next line while you do the real work. And sure, that's useful — the same way spell check is useful. It makes you faster at what you were already doing.
But it doesn't change what you're doing. You're still the one holding the keyboard. You're still context-switching between files, running tests, debugging failures, writing commit messages. The copilot helps at the keystroke level. It doesn't help at the outcome level.
The difference between a copilot and a teammate is ownership. A copilot suggests. A teammate delivers. A copilot waits for your prompt. A teammate picks up a ticket, figures out the approach, writes the code, runs the tests, opens a PR, and asks for review. That's not a marginal improvement. That's a fundamentally different operating model.
What Agent Teams Actually Look Like
When I built OnPlane, I didn't sit down and write code for hours. I set up an execution plan — a structured batch of issues with size estimates calibrated for agents — and kicked off a team.
The team has roles. A team lead agent reads the plan, assigns issues to specialist agents based on domain (backend, mobile, testing), and monitors progress. Specialist agents each work in their own branch, write implementation code, and create pull requests. When a PR is ready, another agent reviews it — checking for correctness, style consistency, and edge cases — before it gets merged.
The agents communicate through structured inboxes: JSON messages with defined schemas for status updates, blockers, questions, and handoffs. No free-form chat. No ambiguity. When the backend agent finishes an API endpoint, it posts a completion message with the contract details so the mobile agent can integrate against it. This is coordination, not conversation.
Size estimates are calibrated for agent execution speed, not human speed. An XS issue is under 15 minutes. Small is 15 to 45 minutes. Medium is one to two hours. Large is two to four hours. A plan that would take a human team a full sprint ships in an afternoon.
When Agents Get Stuck
Agents aren't infallible. They go down rabbit holes. They repeat the same failing test fix three times. They misunderstand a requirement and build the wrong thing confidently. The team lead agent watches for these patterns — and this is where the system gets interesting.
I use an intervention ladder with four levels:
- Nudge — The team lead notices an agent has been on the same issue too long and sends a clarifying hint. "Check the error message. The issue is in the auth middleware, not the controller."
- Guide — The team lead provides a more specific direction. "Use the existing session validation pattern from the auth module. Don't invent a new one."
- Redirect — The approach is wrong. The team lead tells the agent to stop, revert, and try a different strategy with explicit instructions.
- Replace — The agent is fundamentally stuck. The team lead reassigns the issue to a fresh agent with a clean context and a summary of what went wrong.
Most stalls resolve at Nudge or Guide. The expensive interventions — Redirect and Replace — happen maybe 10 to 15 percent of the time. The key insight is that stall detection is itself automated. When CI fails three or more times on the same issue, or an agent enters a fix-test-fail loop, the team lead flags it without me having to watch.
What I Actually Do
If agents write the code, review the code, and merge the code, what's left for the human?
Everything that matters.
I'm the architect: I decide how the system should be structured, what patterns to use, where the boundaries between services fall. I'm the product owner: I define what we're building, why it matters, and what "done" looks like. I'm the quality arbiter: I spot-check agent output, review critical PRs myself, and make the call on whether the work meets the bar.
I also manage context — which turns out to be one of the hardest problems. Each agent gets a fresh context per execution plan. Checkpoint files capture progress so work can be resumed if an agent times out. Handoff protocols ensure that when one agent's output becomes another agent's input, nothing gets lost in translation.
The human role doesn't shrink. It shifts upward. You stop being the one who types the code and start being the one who decides what code should exist and whether the code that does exist is good enough.
This is a harder job, not an easier one. It requires deeper architectural thinking, sharper product instincts, and the ability to evaluate code you didn't write at a pace you couldn't write it. Not everyone will be good at it.
What This Means for Engineering Orgs
If one engineer with an agent team can ship what used to require five engineers, the math gets uncomfortable fast. This doesn't mean 80 percent of engineers lose their jobs tomorrow. But it means the composition of engineering organizations is going to change — dramatically and soon.
Smaller teams with higher output. Senior engineers who can architect systems and direct agent teams will be worth more than ever. Junior engineers who primarily contributed by writing straightforward implementation code will need to level up — fast — into roles that involve design, judgment, and oversight.
The skills that matter shift. Reading code becomes more important than writing it. System design becomes more important than syntax fluency. The ability to decompose a problem into agent-sized work units — clear inputs, clear outputs, testable acceptance criteria — becomes a core engineering competency.
And the companies that figure this out first will have a massive competitive advantage. Not because the technology is secret — the models are broadly available — but because the operational patterns are hard-won. How do you structure agent teams? How do you write execution plans that agents can actually follow? How do you build the feedback loops that catch failures before they compound? These are organizational capabilities, not just technical ones.
The Uncomfortable Truth
I know this makes some people uneasy. The idea that AI agents can do the core work of software engineering — writing code, testing it, reviewing it, shipping it — feels like it should be further away than it is. It isn't. I'm doing it now, on production systems, on real products.
This is where software development is heading. Not copilots that help you type faster. Teammates that own outcomes. The transition won't be instant and it won't be smooth, but it's already underway. The question isn't whether your engineering org will work this way. It's whether you'll be the one leading the shift or reacting to it.
Making the Transition
At BCK Systems, this is what I help companies do. Not just adopt AI tools — everyone is doing that — but redesign how engineering work gets done. Setting up agent team architectures, building execution plan frameworks, establishing the oversight patterns that keep quality high while velocity increases by an order of magnitude.
The technology is ready. The question is whether your organization is. Let's talk about it.