The Shape of the Team Is Changing

July 19, 2026

For twenty years, “we need to ship more” had a standard answer: hire more engineers. That reflex is breaking, and nothing has replaced it.

This article is a forecast, and I am going to be explicit about which parts are measured and which parts are my bet. Organizational predictions age badly, usually because the person making them never marked the line between the two.

So: three sections. What is established. What I think happens next. What I do not know.

What Is Established#

Producing code got dramatically cheaper. Around 90% of developers now use AI daily¹. That part is settled and uninteresting.

Absorbing it did not get cheaper. The benchmark data is consistent on this: AI-assisted changes arrive substantially larger, wait several times longer to be picked up for review, and are far less likely to survive that review unmodified². I have written about that queue in detail elsewhere³. What matters here is the org-chart consequence: more work, in bigger pieces, needing more correction, arriving at a number of qualified reviewers that did not change.

Companies are visibly rewriting how they hire. Shopify requires teams to prove a job cannot be done by AI before opening a position, and factors AI fluency into performance reviews⁴. Canva replaced its computer-science-fundamentals interview with one where the candidate works with AI and is judged on what remains⁵.

Entry-level hiring has collapsed. New-grad hiring at the largest tech companies is down roughly 65% against 2019, and down about 76% at early-stage startups⁶.

That last number is where most writing on this topic goes wrong, including my own earlier draft.

The collapse is real. Its cause is not established. The report that number comes from attributes it mainly to the post-2023 correction after years of over-hiring, a deep available pool of experienced engineers, and a preference for experienced individual contributors over training anyone⁶. The report most often cited as proof that AI eliminated junior jobs does not itself make that claim.

The best evidence that AI exposure is doing some of the work is narrower: among workers aged 22 to 25 in the most AI-exposed occupations, employment shows a 16% relative decline, and it holds after controlling for firm-level shocks⁷. That is a serious result. It is also correlational and occupation-level, not a measurement of software teams deciding not to hire juniors.

Both things are true. Entry-level hiring fell hard, and the share of that caused by AI rather than by interest rates and hiring discipline is genuinely unsettled.

What I Think Happens Next#

Everything from here is inference. Treat it accordingly.

Judgment becomes the binding constraint, and it prices accordingly. The scarce skill is no longer producing code. It is looking at working-looking software and knowing whether it belongs in your system³. At fifteen engineers, the people who can do that for any given subsystem are one or two names you can say out loud, and everything the agents produce queues behind them.

This is why I think teams get smaller rather than larger - not because AI replaced anyone, but because adding a person only helps if they relieve the constraint. Every hire now either adds judgment or adds coordination cost. Coordination cost was always real⁸; what changed is that raw coding capacity no longer pays for it.

The interview converges on one question. When every candidate has the same code generator, what distinguishes them is what they do with its output: spotting the wrong abstraction, writing the test that proves the generated code wrong, saying out loud what was verified and what was assumed. Behind every AI-era interview question there is really one question - can this person be accountable for software they did not personally write?

Cutting juniors creates a shortage that arrives late. Every senior you want in 2031 is a junior somewhere today. Senior-dense is the right target and I would build for it. But a senior-dense team is a pipeline, not a purchase, and the bill for skipping the pipeline arrives several years after the quarter it improved.

I hold this one most strongly and can prove it least. It is a structural argument, not a measurement.

What I Do Not Know#

Whether AI helps junior engineers more than senior ones. The most-cited evidence is the largest field study of generative AI at work: 5,172 customer-support agents, average productivity up about 15%, concentrated almost entirely in the least experienced workers, while the most experienced saw small speed gains and small quality declines⁹. It is a real result and the mechanism is suggestive - the tool hands a beginner something like an expert’s pattern library. But support work is not software work. Resolving a ticket is bounded and immediately scored; merging a change is neither. I would not build a hiring strategy on it.

How small a team can get before resilience breaks. On-call rotations, vacations, and the departure of one person are not solved by leverage. There is a floor. Nobody has published where it is.

Whether AI-native juniors build judgment faster or just build dependency. They read far more code at the same career stage than earlier cohorts did, and write far less of it from scratch. Whether reviewing thousands of generated changes teaches judgment faster than writing hundreds of bad ones yourself is an open question, and we find out around 2030.

Whether mentorship economics work at startup scale. Which brings me to the strongest objection.

The Strongest Objection#

A ten-person startup may genuinely be unable to absorb a junior.

The real cost is not the salary. Mentorship comes out of your most constrained person, at the exact moment that person is also the review bottleneck. Twenty percent of one senior engineer is 2% of company capacity on a spreadsheet and much more in practice, because it is 20% of the individual everything already queues behind. Pre-product-market-fit, you are being asked to fund a 2031 asset out of the budget that decides whether you exist in 2027.

That objection is correct, and the answer is not to hire the junior anyway. It is that a residency is an investment with a hurdle rate, not a moral obligation. Here is the actual trade:

Run it when you have a subsystem stable enough to learn on, a senior who is genuinely good at teaching rather than merely senior, and enough runway that a twelve-month payback is a real horizon. Skip it when you are pre-product-market-fit, when your only qualified mentor is also your only person who can review payments, or when the honest forecast is that you will not exist long enough to collect.

Two of Microsoft’s most senior engineers propose exactly this, under a name also borrowed from medicine - a preceptor program, pairing early-career developers with experienced mentors inside real product teams, with learning as an explicit organizational goal rather than a byproduct of shipping. Companies must keep hiring early-in-career developers, they argue, “accept that they initially reduce capacity, and deliberately design systems that make their growth an explicit organizational goal.”¹⁰

I agree with the design and would add the thing they leave out: not every company should run one every year. A residency every other year is still a pipeline. Zero is a bet that you will never need to grow anyone.

Three Things to Do Now#

Name the judgment before you open the role. Write down the specific judgment this person will own that no agent and no current employee owns. “More coding capacity” is not an answer - capacity is the thing that got cheap. “Nobody can competently review what the agents write in payments” is an answer, and you should hire immediately. If you cannot finish that sentence, you do not have a role. You have a busy quarter.

Interview for verification, not recall. Let candidates use whatever tools they want, then grade what is left.

The last row predicts more than the rest combined, and it is the one most interviews never test.

Fund the pipeline in the open. If the residency clears the hurdle, name the mentor, put the mentoring in their compensation, and put the capacity dip in the plan where everyone can see it. A hidden dip is a broken promise. A planned dip is a budget line.

What Would Change My Mind#

A forecast that cannot be wrong is not worth publishing. Three years from now, here is what I will be reading.

Senior compensation. If cutting the junior pipeline is a real shortage in the making, senior engineering compensation should start outrunning general wage growth around 2029, first in domains where mistakes are expensive. If it does not, my structural argument is wrong and the market found another way to make seniors.

The 22-to-25 gap. If that 16% relative decline closes as the rate cycle normalizes, the cause was mostly macroeconomic and AI was a bystander. If it widens while overall tech hiring recovers, the AI explanation gets much stronger.

Reviewer-to-author ratio. Watch it inside your own company. If it keeps falling while merged volume rises, the constraint I described is tightening on you specifically, whatever the industry does.

Whether the interview converges. If verification-style interviewing is standard practice by 2029, the judgment thesis was right. If hiring drifts back to algorithm screens, then judgment turned out to be easier to automate than I expect, and this article will read as a period piece.

I would rather be checkable than right.

Closing#

Headcount is still the easiest thing to count, and it is no longer what matters. The better question - “how much system can this team hold with confidence¹¹, and who are we growing to hold more of it?” - produces no number you can put in a board deck, which is most of why it gets skipped.

You cannot buy in 2031 what you refused to grow in 2026.

References#