There has always been an uncomfortable truth in software engineering: performance is never measured in a vacuum.
What is changing is how directly that performance is now mediated by tools that are unevenly distributed, commercially controlled, and increasingly central to the work itself.
The industry likes to talk as if engineers are evaluated in clean, individual terms. Talent. Skill. Productivity. Output. Technical depth. But anyone who has worked across different environments knows the picture has never been that pure. Some engineers work with strong infrastructure, good internal tooling, realistic deadlines, thoughtful leadership, and enough slack to think clearly. Others work with brittle systems, thin budgets, weak tooling, constant interruption, and an atmosphere where every shortcut becomes tomorrow’s technical debt.
Now AI is intensifying that difference.
Not because unequal conditions are new, but because of the speed, visibility, and scale at which they now shape perceived engineering performance.
An engineer with access to the best models, the highest limits, the best integrations, and a company willing to spend freely on AI assistance can look dramatically more productive than the same engineer in a more constrained environment. Faster drafts. Faster debugging. Faster summarisation. Faster code review. Faster scaffolding. Faster documentation. Faster exploration of unfamiliar systems. The same person can appear sharper, more responsive, more prolific.
And that should make us uneasy. Because the closer engineering output gets to being mediated by paid cognitive leverage, the easier it becomes to confuse judgment with access.
The same engineer, different budget
This is the part people should sit with more seriously.
Take one competent engineer. Put them in a company with generous AI budgets, premium models, high usage caps, strong internal automation, well-funded infrastructure, and managers who encourage experimentation. Now put that same engineer in a company where model access is restricted, rate limits are low, approvals are slow, context windows are smaller, integrations are weak, and every token of usage is treated like a cost centre to be justified.
Those are not equivalent working conditions, and they do not produce equivalent visible performance.
In the first environment, that engineer may look unusually fast. In the second, the same engineer may look merely solid, or even slow relative to peers who have learned to optimise for scarcity in less visible ways.
This matters because the industry is beginning to talk about AI-augmented output as if it were simply personal productivity. But a growing part of that productivity is purchased.
Not entirely purchased. Judgment still matters. Taste still matters. Verification still matters. Knowing how to decompose a problem still matters. Access is a multiplier, not a substitute. But multipliers do not only amplify real strengths. They also change how those strengths are seen, and how quickly weaker work can pass as stronger than it is.
That means the performance gap we are observing is not always a pure skill gap. Sometimes it is a capital gap wearing the language of merit.
What better model access looks like in practice
The abstraction matters less once you reduce it to day-to-day engineering work.
- An engineer debugging a failing production issue with a high-context model, generous limits, and repository integration can iterate through logs, traces, likely failure paths, and code history in minutes. Another engineer with a weaker model and a copy-paste workflow spends the same hour reconstructing context by hand.
- An engineer reviewing a pull request with AI assistance can get fast summaries, risk prompts, and test suggestions before leaving a comment. Another engineer without that support may still reach the better conclusion, but more slowly and with less visible throughput.
- An engineer onboarding into an unfamiliar codebase with large context windows and solid integrations can ask better questions sooner. Another engineer may have the same underlying ability but appear less fluent simply because their tooling keeps breaking the thread of understanding.
None of this invalidates the first engineer’s output. It means the visible difference is no longer easy to read as an individual property.
Richer environments make mediocre engineers look better too
There is another uncomfortable point here.
Better models do not only help great engineers. They also help mediocre ones appear more capable for longer.
A weaker engineer with powerful tools can produce cleaner-looking drafts, more plausible explanations, more complete-seeming implementations, and more polished communication than they could have produced on their own a few years ago. Sometimes that lift is genuinely useful. Sometimes it makes them operationally better. But sometimes it mainly improves surface performance.
This creates a new problem of legibility.
If better access can elevate everyone’s visible output, how do we distinguish between:
- strong judgment and strong assistance
- real depth and fluent assembly
- durable engineering ability and temporary model-backed competence
- someone who understands the system and someone who is good at navigating augmented workflows around the system
This is not an argument against augmentation. It is an argument against naivety.
AI compresses visible differences in some layers of work while amplifying hidden differences in others. Engineers who can decompose problems well, ask better questions, and verify aggressively often get far more leverage than engineers who cannot. So the effect is not that skill disappears. It is that skill becomes harder to read quickly, because access and ability are now more entangled on the surface.
And in a fast industry, harder to read quickly is a serious problem.
The old signals are getting noisier
Software engineering has never had perfect performance metrics. But many of the usual signals are becoming less reliable in an AI-heavy environment.
- Large output volume? That may reflect good model access.
- Fast prototype delivery? That may reflect better tooling and paid inference.
- Polished internal docs? That may reflect better AI assistance.
- Quick onboarding into a codebase? That may reflect premium context windows and better integrations.Strong pull request throughput? That may reflect a well-funded augmentation stack as much as personal efficiency.
None of this means those outputs are fake. It means they are no longer easily interpretable as individual signals.
The risk is that companies, managers, and even engineers themselves start mistaking tool-mediated acceleration for personal superiority. Once that happens, the mythology rebuilds itself very quickly. The high-performing engineer. The ten-times team. The unusually productive hire. The engineer who just gets more done.
Maybe. Or maybe they sit closer to capital.
The industry already knows this pattern, but prefers not to say it plainly
This is where the broader economic parallel becomes hard to ignore.
Modern industries are very good at turning environmental advantage into stories about individual merit. Better schools become talent. Better networks become hustle. Better tools become personal brilliance. Software engineering has never been immune to that pattern. People already know that prestige companies, strong peers, better hardware, stronger internal platforms, and healthier engineering cultures can radically change how capable someone appears.
With LLMs the effect becomes more immediate and more intimate, because the augmentation sits so close to the act of thinking and producing.
The tool is no longer just around the work. It is embedded directly in it: drafting, exploring, reframing, and accelerating.
So unequal access to the tool starts to shape not only output, but the social interpretation of intelligence and competence.
That should make us more cautious about how quickly we attach status to visible performance.
Great engineers still exist, but it may take longer to recognise them
I do not think this makes engineering judgment less important. If anything, it makes it more important.
The best engineers will still be the ones who can evaluate bad suggestions, spot hidden risk, reason about tradeoffs, notice when the model is confidently wrong, preserve simplicity, and make decisions that hold up after the first draft. They will still be the people who can operate under ambiguity, understand consequences, and see the system rather than just the generated artifact.
But here is the catch: those qualities may become slower to detect.
When tools make mediocre work look more competent on first impression, the gap between a great engineer and an average one may reveal itself less in raw speed and more in second-order effects:
- what breaks later
- what remains maintainable
- what scales cleanly
- what survives ambiguity
- what still makes sense six months after the sprint demo
- who can still deliver when the model is wrong, limited, unavailable, or misleading
In other words, the difference may become less obvious in immediate output and more obvious in accumulated consequences.
That is a harder kind of excellence to measure, and a less convenient kind for an industry that increasingly wants instant signals.
Big tech benefits from blurred attribution
This part is less about conspiracy than incentive structure.
The companies selling the strongest models benefit from a story in which access to their systems looks increasingly similar to access to intelligence itself. The more engineering success is narrated through model quality, model tier, model integration, and model scale, the easier it becomes to normalise an industry where cognition is rented through large platforms.
That does not mean the tools are useless. Many of them are genuinely useful. It means the surrounding incentives are not neutral.
If the dominant story becomes the best engineers are the ones who perform best with the best paid models, then providers are not merely selling tools. They are also benefiting from a standard of competence that becomes harder to separate from subscription tier, integration depth, and spending power.
That should concern people even if they are optimistic about AI.
Because once a profession starts tying visible excellence too tightly to expensive proprietary augmentation, it becomes easier for power to consolidate around whoever controls the highest leverage.
Open access is not a complete answer, but it matters
One reason open models and more accessible tooling matter is not only competition. It is legibility and fairness.
If meaningful AI leverage is available only through the most expensive systems, then the profession drifts toward a world where capital increasingly determines who gets to look fast, polished, and capable. Wider access does not remove inequality, but it does reduce one layer of artificial advantage.
That matters for individuals. It matters for smaller companies. And it matters for the health of the engineering profession.
A field that cannot distinguish between deep skill and expensive augmentation becomes easier to manipulate, easier to stratify, and harder to trust.
What we should be more honest about
We are entering a period where some engineers will genuinely become better because of AI, and some will merely become better-presented.
Those are not the same thing.
The distinction will often be hard to see early. It will take better judgment from managers, better skepticism from teams, and more patience from the industry than the industry usually likes to show.
We should be more honest that money now buys not only infrastructure and labor, but increasingly buys cognitive amplification. We should be more honest that this will distort performance comparisons. We should be more honest that some of the new language of merit will quietly be language of access. And we should be more honest that the market has a direct interest in making this dependence feel natural, inevitable, and desirable.
This does not mean rejecting AI. It means rejecting the fantasy that a heavily capitalised form of augmentation is the same thing as neutral progress.
The question underneath the question
The real issue is not whether tools improve engineers. Of course they do.
The real issue is what happens when the means of improvement are unevenly distributed, commercially controlled, and socially misread as proof of individual superiority.
At that point we are no longer just talking about productivity.
We are talking about who gets to appear excellent, who gets mistaken for mediocre, who gets hired faster, who gets promoted sooner, whose judgment is trusted, and whose limits are treated as personal failure when they may actually be budgetary conditions imposed from above.
That is not a side issue. It is the issue.
The earlier the industry learns to say that plainly, the better its chances of using these tools responsibly rather than drifting into a future where engineering merit becomes difficult to separate from purchased advantage.
Top comments (0)