I know of teams who have taken on developers and given them starter projects. The kind of thing you might ask an intern to do - build a small utility for internal use, create a standalone tool for a specific workflow, automate a reporting process. Reasonable latitude, clear spec, then let them get on with it.

These developers are moving ridiculously fast.

If you can build a multiplayer calculator app in a few minutes, why wouldn’t you expect other things to go quickly too? But still - doesn’t experience count? Knowing where the pitfalls are, spotting risks early before they mushroom into something that kills the project. Surely you need at least some book knowledge, if not scar tissue, around that stuff.

It would seem these developers are going a lot further than you’d expect.

The obvious objection

Internal tools and greenfield projects are famously only the first few percentage points of the difficulty of anything real. The stuff I’m describing is a far cry from maintaining a legacy codebase or navigating a complex domain.

Fair enough.

But something confounding is happening. Deep knowledge should be higher leverage than before - we’re orchestrating up the abstraction ladder after all. Yet the juniors keep shipping.

The theory

I think there’s a genuine tradeoff with experience. Memories of pain build aversion. I’m probably much less adventurous now than ten years ago, simply because I’ve seen things go wrong. That’s what caution is, in most cases.

But things are shifting so fast that what looks reckless or naive might be smart. We’re constantly surfacing things models can do that people struggle with. Over the Christmas break I knocked out something my team had considered a real blocker - half a day, higher standard than expected. My 2020 self would have called it hard work.

So there’s that.

But I don’t think it’s the main thing.

The real variable

I wrote before about how human coordination is becoming the binding constraint. LLMs get faster, humans start to stick out as the bottleneck. You end up wanting to reduce headcount. One person per project. Then less than one.

Here’s the thing: if you throw a solo developer at a project with nothing but a parachute, they get all the benefits I described in that post. No coordination overhead. No waiting for alignment. No context-switching between people’s mental models.

It might be that inexperience does hurt in the aggregate. But the benefits of being unconstrained by Brooks’ Law offset the cost.

Maybe we’re seeing the first glimmers: coordination costs can outweigh inexperience.

And the effect of Brooks’ Law is changing dramatically over time. The gap between solo and team will keep widening.