Back to Blog

The One-Person Engineering Team

Boris Cherny, the creator of Claude Code at Anthropic, recently wrote that “pretty much 100% of our code is written by Claude Code.” For him personally, it had been 100% for over two months — he doesn’t even make small edits by hand. He shipped 22 PRs in one day and 27 the day before, each one entirely written by Claude.

I think he’s right. And I think most engineering teams aren’t ready for what that means.

What Changed

About ten months ago, I lost my last engineer. One day I had a team; the next, I was the entire engineering department — responsible for a Ruby on Rails web application with PostgreSQL, Redis, and Sidekiq, plus the DevOps, infrastructure, CI/CD, and deployment pipelines to keep it all running. Architecture decisions, code review standards, product strategy — all of it.

I had a choice: lobby for headcount and wait, or figure out how to operate at a fundamentally different level.

I chose the latter. And what I found is that the tools available today don’t just help you work faster — they change the nature of the work itself. The shift happened when I stopped thinking of AI as an autocomplete tool and started thinking of it as a team of junior engineers that I orchestrate.

Since then, I’ve applied the same approach to my personal projects. A web application I’ve maintained since 2016 got a complete modernization. A native iOS app and a macOS desktop application — both built from scratch in the last few months. The scope of what one person can take on has fundamentally expanded.

The Workflow

Here’s what a typical feature build looks like:

Before AI augmentation, I’d estimate one to two weeks for a meaningful full-stack feature. Write the migration, build the model, write the controller, build the view, add tests, handle edge cases, deploy. Serial work, one step at a time. And that’s assuming nothing unexpected comes up.

Now, I define the architecture and acceptance criteria. I spin up AI agents across parallel workstreams — one handling the backend, another on the frontend, another writing tests. I maintain automated quality gates: linters for style, test suites for correctness, system tests for integration. Each agent’s output goes through verification loops before it touches the main branch.

My job shifted from writing code to defining intent, reviewing output, and making judgment calls. The code still gets written. It still gets tested. It still gets reviewed. But the bottleneck moved from typing speed to thinking speed.

The result: features that took a week or two now take hours or a day. The quality is the same or better, because every change goes through automated gates that catch the things humans miss when they’re tired at 4pm on a Friday.

The Engineer as Orchestrator

This is the part that most conversations about AI in software development get wrong. The narrative is usually “AI writes code for you” — which makes it sound like the engineer becomes unnecessary. The reality is the opposite. The engineer becomes more necessary, but in a different capacity.

Each AI agent effectively fills a role that might have been held by an individual on a traditional engineering team. One handles backend implementation. Another writes frontend components. Another generates test coverage. Another reviews for security concerns. The orchestrator — the engineer — is the one who:

  • Decomposes the problem into parallel workstreams that won’t conflict
  • Writes precise specifications so each agent knows exactly what “done” looks like
  • Builds verification loops that catch errors before they compound
  • Makes judgment calls that require understanding the system as a whole
  • Recognizes when the AI is confidently wrong — and this happens more often than you’d think

It’s not management in the traditional sense. It’s closer to conducting an orchestra. You need to understand every instrument, even if you’re not playing any of them.

What It’s Not

Let me be clear about what this isn’t.

It’s not “paste requirements into ChatGPT and ship whatever comes out.” That’s how you build a mess. AI without engineering judgment produces code that works in demos and breaks in production.

It’s not a replacement for understanding systems. You still need to know why an N+1 query will crush your database at scale. You still need to understand authentication flows, data modeling, and deployment architecture. The AI doesn’t know your system — you do.

And it’s not easy. Orchestrating AI agents effectively is a skill that takes months to develop. You need to learn how to decompose problems, write specifications that leave no room for misinterpretation, build quality gates that actually catch issues, and develop an intuition for when to trust the output and when to push back. Most developers I talk to are still using AI as a fancy autocomplete. They’re leaving 80% of the capability on the table.

Why This Matters Now

The landscape is shifting fast. Gartner predicts 90% of software engineers will shift from coding to AI orchestration by 2027. Entry-level hiring at the 15 biggest tech firms fell 25% from 2023 to 2024. The economics of software development are being rewritten in real time.

If you’re a startup founder, the team you need to build in 2026 looks different than the team you needed in 2023. The roles are changing. The skills that matter are changing. Understanding this shift is the difference between hiring well and hiring for a world that no longer exists.

If you’re a CTO or engineering leader, your team is almost certainly underutilizing the tools available to them. The transformation isn’t about buying AI subscriptions — it’s about restructuring how your team decomposes problems, reviews output, and maintains quality. That’s an organizational change, not a tooling change.

If you’re a developer at any level, the ceiling on what you can build has never been higher. But only if you invest the time to learn orchestration as a skill — not just prompting, but the full workflow of specification, delegation, verification, and iteration.

The gap between engineers who have embraced this shift and those who haven’t is widening every month. Don’t wait to figure this out. Pick up the tools. Experiment aggressively. The learning curve is real, but the compounding returns are enormous.

The role of the software engineer isn’t disappearing. It’s evolving — from writing code to directing intent. And the engineers who make that transition first will have an outsized advantage for years to come.