You're Not a Developer Anymore. You're an Engineering Manager.
In six months of building CrewDeck, I have opened more than three thousand pull requests.
I want to be precise about what that number does and does not mean. It does not mean I wrote three thousand pull requests' worth of code. It means I supervised three thousand units of work produced by AI engineers — and somewhere in the middle of that, I stopped being a developer and became something else entirely.
Nobody warned me about the transition. There is a great deal written about how to prompt well, and almost nothing about what happens after the tenth session, or the hundredth, when the thing you are actually managing is not a codebase but a workforce.
The Skill That Stopped Transferring
My stack is Salesforce. I have been on that platform for about fifteen years, which is long enough to be genuinely good at it and long enough to feel the walls.
Every time I wanted to build something outside it — a desktop app, a mobile app, a web product of my own — I ran into the same problem. I was too busy with client work to experiment, and when I did find time, I discovered how little transfers. If you are technical you already know this: the concepts do not map cleanly. Building on an enterprise cloud platform and building an Electron desktop application are not the same discipline wearing different clothes. They are different disciplines.
So I had ideas I could describe precisely and could not build.
That is a very specific kind of frustration, and I do not think I am unusual in having it. Most experienced engineers are deep in one place. The economy increasingly rewards people who can ship across many.
The Part That Actually Broke
AI closed that gap for me faster than I expected. Within weeks I was producing working software on stacks I had never touched. That part worked.
What broke was everything around it.
The moment I moved past a single session — the moment I had three, then five, then a dozen streams of work running against the same repository — the bottleneck moved. It was no longer can I get the model to write this correctly. It was can I keep track of what a dozen workers are doing to my codebase at once.
The tools generate so much code that no human has the cognitive capacity to follow it all. You cannot read it. You cannot hold it in your head. And critically, you cannot catch the things that are wrong in it by sheer diligence, because diligence does not scale at that volume. I was reviewing output faster than I could understand it, which is another way of saying I was not really reviewing it.
This is the problem I now think of as AI code sprawl, and it arrives much earlier than people expect.
Every Task Is a Hire
Here is the reframing that finally made the work tractable.
Working with an AI engineer is structurally identical to working with a human one, with the timeline compressed to minutes. For every single task, you are:
- Hiring — choosing who does this work and whether they are suited to it
- Onboarding — giving them the context, the standards, the constraints, the surrounding code they need
- Supervising — staying available while they work, redirecting when they drift
- Offboarding — reviewing what they produced, merging it, and closing them out
With a human hire, you do that a handful of times a year and there is an entire profession built around doing it well. With AI engineers, you do it thousands of times, and you do it with no tooling at all.
That asymmetry is the whole problem. Three thousand pull requests is three thousand onboarding cycles. If each one costs you even a few minutes of context-setting that you have to reconstruct from memory, you have lost weeks — and the quality drifts, because consistency across three thousand briefings is not something a person can hold in their head.
If you have never managed engineering resources before, this is where standards quietly collapse. Not dramatically. Just gradually, one under-briefed task at a time.
The Cost Curve Nobody Mentions
There is a second thing that scales badly, and it costs real money.
When you build a small application from a single prompt, your cost is trivial. It feels like the economics of this are basically free. But two things change as your repository grows.
First, every prompt now triggers the same expensive re-orientation. The agent has to rediscover your architecture, your conventions, your file layout — over and over, for each task, because each session starts cold. The work of understanding your codebase gets paid for again and again.
Second, the surface area you need reviewed grows at the same time. So your per-task cost rises exactly when your task count rises.
Those two curves multiply. What looked cheap at the prototype stage becomes a real line item at the product stage, and most people discover this well after they have committed to the approach.
The fix is not a cheaper model. The fix is not re-paying for the same context on every task, and not running orchestration through infrastructure you are billed for twice.
What Management Tooling Would Actually Look Like
If you accept that you are now managing a workforce, the requirements follow naturally from what human engineering management has always needed.
Isolation
Workers need their own desks. Two agents editing the same working directory will collide — not occasionally, but as a matter of course, because they have no awareness of each other.
Git worktrees solve this cleanly. Each agent gets a real, complete working directory on its own branch, all sharing one underlying repository. No stashing, no branch switching, no waiting for a turn. We wrote about the mechanics of this in Git Worktree Isolation.
Visibility
You cannot manage what you cannot see. Twenty terminal windows is not observability — it is a wall of text with no structure. You need to know what each worker is doing, what stage it is at, and where it is stuck, in a form you can scan in seconds.
This is why a board works. Not because Kanban is fashionable, but because the fundamental question — what is everyone working on right now — has a well-understood visual answer.
Verification you don't perform yourself
This is the one that matters most, and the one people resist.
If you are the only reviewer, you are the ceiling. Three thousand pull requests do not get meaningfully reviewed by one person, no matter how disciplined that person is. The only way through is to build verification into the pipeline itself — self-checking runs, validation stages, agents reviewing other agents' work before it reaches you.
You stay in the loop for judgment. You stop being in the loop for detection.
Cost control by architecture
Keep the orchestration local. When the coordination layer runs on your own machine rather than a remote service, your code does not leave your environment and you are not paying a second time for the privilege of managing your own work.
How We Built It
CrewDeck is the tool I needed and could not find.
It takes the entire software development lifecycle — mock-up, tasking, execution, pull request lifecycle, validation — and puts it in front of you as one surface. Underneath, it orchestrates your Engineering Workforce across isolated git worktrees on your local machine. Up to twenty parallel sessions, powered by Claude and Codex.
Nothing runs on a remote server. Nothing is handed to an external service. That is a privacy property and a cost property at the same time.
A few things fell out of building it this way that I did not anticipate:
- Structured debate between agents. For architectural decisions, you can have several specialized agents argue a question — propose, critique, and converge — before anyone writes code. A single agent gives you a single model's biases. Several give you something closer to a design review.
- Self-validating work. Once validation is a pipeline stage rather than a personal obligation, your confidence in the output goes up and your involvement goes down. Those are supposed to move in opposite directions, and it took me a while to trust it.
- Consistency by construction. When onboarding context lives in the platform instead of your head, briefing number three thousand is as good as briefing number one.
If You're Starting Down This Road
A few things I would tell myself six months ago.
Do not scale to twenty on day one. Run two. Learn what failure looks like when you can still see all of it. The failure modes at scale are the same as the failure modes at two — they are just harder to attribute.
Invest in the briefing, not the prompt. The difference between a good result and a bad one is almost never phrasing. It is whether the agent had the context to make the right call unprompted.
Decide where humans stay in the loop, explicitly. Not everywhere — that does not scale — and not nowhere. Pick the gates deliberately and make them consistent.
Watch your cost curve early. Look at what a task costs you at month one and what the same task costs at month four. If that number is climbing, the architecture is the reason, not the model.
The Broader Point
I think a lot of engineers are about to find themselves in the position I was in — with deep expertise in one place and a real need to build in several. Some by choice, some not.
The good news is that the constraint has genuinely moved. You are no longer limited by which stacks you happen to have learned. You are limited by how well you can direct a workforce that will build in any of them.
That is a learnable skill. It is closer to management than to programming, and the tooling for it is only now being built.
Orchestration beats raw model power. That is the whole bet.
Start building with CrewDeck — extend your builder superpowers to any platform.
Want the shorter version? There's a 7-minute video overview and a podcast episode covering the same ground. Questions about orchestrating AI agents at scale? Find us on Discord or Twitter.