Comment by warmedcookie

This sounds good in theory, but have you hired someone in 2026?

Developers are really lazy in general and don't want to work. The more people you hire, the more you run into the chance of gumming up productivity with unproductive developers.

Even if they are productive, once you cross the threshold of 30 people even productive developers become lazy because of entitlement, bad resource distribution, or complexities from larger teams.

We don't even have to talk about teams of 1000+. Ownership is just dead at that point.

In 2026, having just 5 engineers with AI means you can cut through all the waste and get stuff done. If they start being weird, you can see it pretty easily vs. when engineers are being weird in a team of 50-1000+.

It's not rocket science to see leadership decide to cut down on teams to better manage weirdness in devs. More people doesn't mean more results unfortunately because of work culture nowadays.

Will the modal developer of 2030 be much like a dev today?

Writing software was a craft. You learned to take a problem and turn it into precise, reliable rules in a special syntax.

If AI takes off, we'll see a new field emerging of AI-oriented architecture and project management. The skills will be different.

How do you deploy a massive compute budget effectively to steer software design when agents are writing the code and you're the only one responsible for the entire project because the company fired all the other engineers (or never hired them) to spend the money on AI instead?

Are there ways of factoring a software project that mitigate the problems of AI? For example, since AI has a hard time in high-context, novel situations but can crank out massive volumes of code almost for free, can you afford to spend more time factoring the project into low-context, heavily documented components that the AI can stitch together easily?

How do you get sufficient reliability in the critical components?

How do you manage a software project when no human understands the code base?

How do you insure and mitigate the risks of AI-designed products? Can you use insurance and lower prices if AI-designed software is riskier? Can we quantify and put a dollar value on the risk of AI-designed software compared to human-designed?

What would be the most useful tools for making large AI-generated codebases inspectable?

When I think about these questions, a lot of them sound like things an manager or analyst might do. They don't sound like the "craft of code." Even if 1 developer in 2030 can do the work of 10 today, that doesn't mean the typical dev today is going to turn into that 10x engineer. It might just be a very different skillset.

I don't think it necessarily scales that way. Larger organizations need more communication channels and coordination. If anything, assuming AI does give you 10x ability, there's probably a sweet spot where you have just enough developers that churn out code at a good pace but not too many that it gets too chaotic.

If you compare one developer to 10, for instance, one developer doesn't have to deal with communicating with 9 other people to make sure they're working on things that align with the work everyone else is doing. There is no consensus that has to be reached. No meetings, no messages that have to be relayed, no delays because someone wasn't around to get approval. That one developer just makes a decision and does it.

There are lots of big companies out there and in the past, small startups have been able to create successful products that never would have been created at the big company even though the big company hired way more developers.

Yeah I think this is a good way to think about it. I mean Google, MSFT for example have effectively unlimited developers, and their products still suck in some areas (Teams is my number one worst) so maybe AI will allow them to upgrade their features and compete