Loading
Blog
The way we measure software developers is changing.
For years, developers have been evaluated by the number of features they build, the quality of their code, the bugs they fix, and how quickly they deliver projects. But as AI becomes a core part of software development, a new metric may eventually enter the conversation:
How efficiently does a developer use AI?
Imagine a future where developers don't just have code commits and Jira tickets attached to their performance reviews. Their dashboards also show AI usage: tokens consumed, tasks completed, code generated, bugs resolved, and the amount of work completed per AI request.
At first, this might sound strange. But companies are already paying for AI usage, and AI-assisted development is becoming increasingly common. As that cost becomes part of engineering budgets, organizations may start asking a simple question:
Are we getting enough engineering value from the AI we're paying for?
Today, most developers don't think much about how many tokens their AI coding assistant consumes.
They open their AI tool, provide context, ask questions, generate code, review it, and continue working.
But imagine an engineering team where every developer has an AI usage budget.
Developer A uses 10 million tokens to complete a feature.
Developer B uses 3 million tokens to deliver a similar feature with comparable quality.
Developer C uses 1 million tokens while producing cleaner code, fewer bugs, and better documentation.
Who is the most efficient developer?
The answer wouldn't necessarily be the person who uses the fewest tokens.
The real metric would be value generated per unit of AI consumption.
This isn't completely different from what companies already do with infrastructure.
Developers aren't usually rewarded for simply using more AWS resources. Instead, companies care about performance, reliability, scalability, and cost efficiency.
AI could eventually be treated the same way.
A company might measure:
AI cost per feature
Tokens consumed per completed task
AI-assisted bugs resolved
Code review efficiency
Development time saved
Number of successful AI-generated changes
Rework caused by AI-generated code
Human review required after AI assistance
This could create an entirely new dimension of developer productivity.
This is where things become interesting.
A developer who consumes millions of tokens isn't automatically more productive.
They might simply be asking the AI unnecessary questions, repeatedly generating code they don't understand, or sending huge amounts of irrelevant context.
Another developer might use significantly fewer tokens because they understand the problem, provide precise prompts, know the codebase, and use AI only where it provides real value.
So the future metric shouldn't be:
"Who uses the most tokens?"
It should be:
"Who creates the most value with the least unnecessary AI consumption?"
That's a very different measurement.
Developers already differentiate themselves through technical skills such as system design, debugging, architecture, and code quality.
In an AI-first development environment, another skill could become increasingly valuable:
Knowing how to communicate with AI effectively.
A developer who can provide the right context, break complex problems into smaller tasks, identify hallucinations, review generated code, and guide an AI agent effectively could potentially outperform someone with similar coding ability who doesn't know how to work with AI.
In other words, developers may eventually need to become good at managing both:
Code + Intelligence
rather than simply writing code themselves.
This is where the idea becomes particularly interesting.
Imagine a developer's annual performance review in 2030.
Instead of only seeing:
Features delivered: 42
Bugs fixed: 137
Pull requests: 284
The company might also show:
AI-assisted tasks: 620
AI cost: $1,840
Average tokens per task: 42K
Rework rate: 4%
Estimated engineering time saved: 1,200 hours
AI efficiency score: 94/100
Now AI usage becomes part of the developer's professional profile.
A promotion might depend not simply on how much code someone produces, but on how effectively they combine their own expertise with AI.
However, there is a major problem.
Token consumption is a terrible standalone performance metric.
A developer working on a complex distributed system may naturally need more AI context than someone fixing simple UI bugs.
Someone working on a massive legacy codebase may consume more tokens simply because the AI needs more context.
And a senior developer might intentionally spend more tokens asking AI to analyze architecture, security, scalability, and edge cases.
So rewarding developers purely for low token usage could actually encourage bad engineering behavior.
The goal should never be:
"Use fewer tokens."
The goal should be:
"Use AI efficiently while producing high-quality engineering outcomes."
The most valuable developer in the future may not be the person who can write the most code manually.
It may be the person who can:
Understand the problem → design the solution → guide AI → review the output → test it → improve it → ship it.
AI will increasingly handle portions of implementation.
Developers will increasingly be responsible for direction, judgment, architecture, verification, and ownership.
That means the definition of a "good developer" is likely to evolve.
And perhaps one day, during a promotion review, a manager won't just ask:
"How much did you build?"
They might also ask:
"How effectively did you leverage AI to build it?"
The companies that understand the difference between AI usage and AI productivity will probably be the ones that build the strongest engineering teams.
Because in the AI era, the competitive advantage may not come from using the most AI.
It may come from using the right amount of AI, in the right way, to create the most value.
