I go to a lot of programming events, they’re all about AI now, and I always notice the huge gap between the developers who are at the cutting edge today, using the latest models, and regular developers.
We all know how much frontier models have advanced by now, but not every developer has spent enough time experimenting with them and with the previous models to really understand the capabilities they unlock.
Years ago we used to talk about the 10x developers. That developer who could get through the work of 10. Today people are already talking about 100x developers. The only way to get there is through the efficient use of frontier models.
Most developers are using AI models without really knowing the capabilities of each model they use, because they haven’t lived through each change, each version, and they haven’t spent enough hours trying them out or watching videos explaining them. Today, no company can provide documentation that is up to date with how to use these frontier models efficiently and that can really teach developers to become 100x directly.
Example of a 100x developer
100% of the resources a company can provide on this are outdated and will only lead to wrong ideas coming from models from months ago; they’ll end up with worse-prepared repositories and agents performing worse even though they’re frontier models.
I’d dare say that more than 90% of developers don’t know how to fully take advantage of frontier models, and using them well completely changes how programming work gets done. The confidence their code gives you, the level of parallelization they allow and the speed you achieve are not something a less intelligent model gives you.
The only way to get good is by spending hours using them, doing tasks with them and spending, even wasting, a lot of tokens.
If you’re not a developer and you learn to use models efficiently, you can become a 1x developer.
If you’re a developer, you can become one of those 10x developers if you use models efficiently.
And in some cases, developers who always go further, who are early adopters, who care about what’s new and are more into it, can become 100x developers.
For your employees to make this upgrade, they’re going to need to spend a lot of tokens.
If you have a company and you’re not paying your developers their same salary in tokens, knowing the productivity improvement you’re not allowing them to make, you’re deliberately slowing down the company.
To really multiply your productivity by 10, you need to know the capabilities of each model, know when to use a frontier model, when to use the different reasoning levels. The only way to learn that today is by letting them spend tokens on it.
Thanks to subscriptions, a developer can take a frontier model (like Fable 5.1) and try it without spending too much money, turn on ultra think mode, give it a task that spawns 100 subagents and burn a week’s token budget in a single day. And that’s fine. It’s necessary and it’s the way to learn. They have to go through it. They have to use frontier models to unlock in their minds what can be achieved with them.
Many people still have in their heads the agentic level of the old models. Once you make the jump to frontier models, there are some mistakes you shouldn’t make:
- Not working in parallel with multiple threads: while one agent works on a task, start working on another one in a different thread
- Not taking advantage of worktrees for parallelization
- Giving them tasks that are too short or too simple
- Using a classic terminal, which makes parallelization harder
- Having a harness overloaded with specific subagents; the cleaner you leave these models, the better
- Using MCPs that change how the harness works, like memory or token-saving utilities; if they only had benefits they would come built into the harness
- Using skills or agents.md designed for old models, with instructions that are unnecessary and counterproductive at these levels of intelligence
- Not knowing when to ask for computer-use
- Going overboard with the reasoning level; the intelligence is already in how the model behaves, you don’t need that many reasoning tokens for your kind of task
- Forcing delegation to subagents just to get a fresh context, instead of letting the agent use them to parallelize work
- Believing that models still get dumber at high context
- Believing that compaction is still as bad as it was a year ago and loses information
- Not allowing the agent to switch branches, commit and open PRs
- Using Gemini
If you apply these ideas with less intelligent models while trying to increase your productivity, what you’ll get is more low-quality code in your repositories, overcomplicated reviews for your teammates and more bugs.
If you block your employees’ access to frontier models because of what they cost, you’re forcing them to use only models that may look good on benchmarks. In real use, the people who have actually been able to develop that judgment by using the other models have noticed the huge difference between them, while your employees would keep using those models thinking they’re good, because you haven’t let them develop that judgment. That’s what happens with models like Opus 5 or Gemini 3.8. If you don’t encourage your employees to develop that judgment, they’ll believe the benchmarks and end up wasting money on poor inference. A decision that seems to save your company money ends up hurting and delaying your employees’ knowledge.
It got to the point where Anthropic employees apologized for their model.
Maybe you’re deliberately choosing to hold the company back; given how fast things change in this sector, committing resources to something that may change in a month can be risky. Even more so if your company isn’t competing for market share. But it’s been pretty clearly shown where the industry is heading, and it’s not only used to increase the number of features shipped per month: it frees up time for security, for improvements you’d make if you had the time, tackling technical debt, improving performance, higher test coverage. Every project starts getting better.