A few weeks ago my lead engineer and I shipped a project in about two weeks that I would have planned a month for, minimum, before any of us had agents. We did it by not writing any code for the first several days. I’ve been turning that over since, because it says something about how engineering teams get built, and it isn’t the thing everyone is afraid of.
The fear is everywhere right now. AI is going to take engineers’ jobs. Teams are going to shrink. The ladder is getting pulled up behind the people already on it. I don’t think any of that is crazy. I’ve watched a very small team do an absurd amount of work with AI, provided it’s the right engineers. And the numbers are real. A Stanford study found employment for software developers aged 22 to 25 down close to 20% since late 2022, while employment for experienced developers held steady or grew. The industry is hiring fewer people, and the people it isn’t hiring are the young ones.
But “fewer engineers” is the lazy lesson. The one I keep landing on is that AI changed the order you build a team in, and what each hire is for. To explain why, I have to walk through how we used to do it.
How we built teams before
Every startup engineering team I’ve built or joined followed roughly the same sequence. Not because anyone wrote it down. Because it’s what the money and the work demanded at each stage.
You started with a few senior engineers. People you could hand a feature to on Monday and trust to have it in production by the time Sales needed to demo it, with no oversight and not much of a spec. That’s the getting-shit-done phase. Everybody cranking, pushing code as fast as the pipeline would take it, because every feature on the board was blocking a deal.
Then the first round of real hiring. A QA engineer, a mid-level engineer or two. The seniors gave up some of their coding time to plan, so the mids knew what to build, and to mentor, so the mids built it well. You got a real QA process out of this phase, and usually a real deployment pipeline, because now there were enough people touching the code that “just be careful” stopped working.
Next came leadership. A manager and a lead, usually. The manager took on project planning: what are we building, for whom, by when. The lead took on system design: how. Together they produced the specs that the seniors and mids executed.
Last, juniors. Cheaper, in exchange for being taught the trade. They needed a lot of senior attention, which meant your seniors wrote less code than ever, and by this point your leads and managers were spending most of their week with Product and Sales figuring out what to build so they could decide how to build it.
That’s the whole arc. I’ve lived it more than once.
Notice the order, though. Every phase was driven by how much code you needed written. Planning, design, supervision, teaching: all of that came last, as overhead you could only afford once there were enough hands to plan for and supervise. The first thing a team did was write code. The last thing it did was think carefully about what code to write.
What AI actually changed
The obvious take goes like this. A senior with good agents pushes a lot more code than a senior without them, so you hire four or five seniors and skip everyone else. Smaller team, same output, nobody to babysit.
I don’t buy it, and I want to be careful about why, because the first half of that is true. Seniors with agents are dramatically more productive. It’s the conclusion that’s wrong.
Start with where the bottleneck went. Writing the code was never the hard part of a feature, but for twenty years it was the slow part, and everything about how we staffed teams was organized around that. Now the slow part is figuring out what to build and checking that what got built is right. That’s judgment. It’s the scarcest thing on any team, it’s what you’re paying your seniors for, and every hour one of them spends typing out a well-specified CRUD endpoint is an hour of it wasted. The agents can type.
Then look at what happened to juniors. The agents know Rails better than any junior will for years. They know Postgres, they know the testing framework, they know the idioms. A junior who’s been shown how to direct them can land working code in their first weeks instead of their first months. What they can’t do, and what no amount of prompting fixes, is tell good code from code that merely looks good. So the training changes. You don’t spend six months on syntax. You spend it on what a clean API boundary looks like and why, how errors should propagate through a service, why this query falls over at ten times the data, when a class has picked up too many reasons to change. I made this argument from the hiring side in the last post: the fundamentals were always the point, and the code was a proxy for them. Same lesson, applied to the people you already hired.
And then there’s the part nobody wants to say out loud. Seniors come from somewhere. Hiring for mid and senior roles recovered after the 2023 layoffs. Hiring for new grads did not. Every team that decides it can skip juniors is deciding, quietly, that someone else will train the seniors it needs in ten years. That’s a fine plan right up until everyone has it. I’d rather not outsource the future of my own team to whoever is still willing to teach.
Two weeks
So here’s what my lead and I actually did, now that the old sequence is in front of you.
A project came down with the usual startup timeline, meaning not enough of one. The old instinct, mine included, was to start on the foundational code we knew we’d need regardless of the final design. Models, migrations, the obvious endpoints. Get moving.
We didn’t. We spent several days in calls with each other writing the project description and the tech design. Multiple iterations. A call about each one. Revisions during the call. We kept going until we’d answered every question we could think to ask and had a design that covered the business need and left room for the thing to grow.
Then we turned the agents loose on it. We watched every change. We reviewed every PR the way we’d review a junior’s, which is to say skeptically and with the design open in the next tab. We ran AI debugging tools against the result, fed what they found back to the agents, and had them push corrections. Concept to production in about two weeks. My guess is a month or more the old way, and I’m not confident the old way would have come out as clean.
Look at what that is, though. Two people doing the planning and design work from phase three, supervising execution the way seniors supervised juniors in phase four. No phase one at all. We didn’t speed up the old sequence. We started at the end of it.
Build it backwards
Which is the whole point. I think the new sequence is the old one reversed.
Day one is planning and review. Your first hires are the people who can design a system and recognize when an agent is confidently wrong, which is a specific skill and not the same thing as being a strong coder. The agents are your first juniors. They execute fast, they don’t know what they don’t know, and someone has to check their work.
Your second hires are actual juniors, and you hire them into the supervision structure you already built for the agents. They’re cheap. They ramp faster than any junior you’ve hired before. And the thing you’re teaching them is judgment, which is the one thing you’ll need more of in two years than you have today.
The role I’d be slowest to hire for now is the one the old sequence reached for first after the founding seniors: the mid-level engineer whose job is to take a well-specified feature and execute it without much oversight. That’s not a knock on anyone with the title. It’s that the job description is, almost word for word, what the agents do. If you’re hiring for it, you’re hiring hands.
The layoff fear gets the headcount right and the heads wrong. Teams will be smaller. I’m fairly sure of that. But if you’re building one, the mistake isn’t hiring juniors. It’s hiring for execution when what you’re short on is judgment.