In 1968, researchers Harold Sackman, W. J. Erikson and E. E. Grant published a study examining differences in programmer performance. It was a small experiment, involving only a handful of programmers, but the differences they observed were enormous. Some participants completed programming and debugging tasks many times faster than others. The study subsequently became part of a much larger discussion about whether exceptional programmers could be ten times—or even more—productive than their peers.
Over the decades, the idea evolved into one of the software industry's favorite characters: the "10x developer," sometimes called the "rock star programmer." Companies competed for unusually talented engineers on the assumption that one exceptional developer might accomplish what several ordinary developers could not.
Whether a small experiment conducted in 1968 ever justified all the mythology that followed is debatable. Software development has changed enormously since then, and measuring a developer by the speed with which someone completes a programming exercise tells us surprisingly little about the value that person might contribute to a complicated modern system.
But the old study raised a question that has never really gone away:
Why are some software developers so much more effective than others?
In 2026, that question has become considerably more interesting.
Artificial intelligence has changed software development remarkably quickly. Coding agents can generate functions, modify existing applications, write tests, diagnose errors, explain unfamiliar code, work with development tools and carry out increasingly complicated sequences of software-engineering tasks. Recent industry research suggests that professional developers are already allowing AI to generate substantial portions of their code.
That would have sounded extraordinary only a few years ago.
For most of the history of software development, knowing how to express a solution in a programming language was a scarce and valuable skill. Someone had to understand Java, C++, Python, SQL or another language well enough to translate an idea into instructions a computer could execute.
That skill still matters.
But the economics surrounding it are changing.
If a competent developer can describe a task to an AI system and receive hundreds of lines of usable code within minutes, then the ability to produce those hundreds of lines manually becomes less important as a measure of productivity.
The question shifts from:
How quickly can you write the code?
to:
Do you know what code should be written?
Those are very different abilities.
Our original 2020 article made an observation that has become more relevant with time: coding is a tool used to solve a problem. It isn't the solution itself.
A better way of putting it today might be:
Code is the medium through which we build the solution.
Imagine asking an AI coding agent to build exactly what appears in a specification. The agent produces elegant code. The application performs well. The tests pass. The documentation is excellent.
There is only one problem.
The specification describes the wrong system.
Nothing about syntactically perfect code fixes that.
Someone still has to understand what the organization is trying to accomplish. Someone has to recognize contradictory requirements, questionable assumptions, security risks, inappropriate architecture, missing data and unintended consequences.
And someone occasionally has to say:
We shouldn't build this at all.
That person may be considerably more valuable than the person who can type code the fastest.
The difference between an adequate developer and an exceptional one has never simply been knowledge of syntax.
Experienced developers develop judgment.
They begin recognizing patterns. They've seen systems fail. They've watched seemingly harmless shortcuts become expensive problems several years later. They understand why a solution that looks elegant on a whiteboard may become difficult to maintain in production.
They also learn to ask questions before reaching for technology.
What problem are we actually trying to solve?
Who will use this?
What happens when the number of users increases dramatically?
What happens when the data is wrong?
What happens when another system changes?
Who will maintain this five years from now?
What information are we exposing?
What assumptions are we making?
What happens when something fails?
AI can help investigate every one of those questions.
But someone has to know that the questions should be asked.
There is an interesting paradox here.
One might assume that as artificial intelligence becomes better at programming, experienced software developers become less valuable.
In some circumstances, the opposite may happen.
Consider two developers using the same capable coding agent.
One has relatively little experience. The AI produces a solution. It compiles, passes basic tests and appears to work. The developer accepts it.
The other has spent twenty years building systems.
That developer looks at the same solution and notices that the database design will become troublesome at scale. An authentication decision creates an unnecessary security exposure. An external dependency could become a point of failure. A supposedly convenient abstraction will make future changes harder. Or perhaps the entire feature duplicates something the organization already possesses.
The AI made both developers faster.
But it may have made the experienced developer disproportionately more capable because that person knows what to accept, what to question and what to reject.
AI supplies leverage.
Experience determines where to apply it.
This may be the most important change to the old "rock star developer" idea.
The exceptional developer of the AI era may actually write less code personally.
Instead, that person may spend more time defining problems, decomposing work, designing systems, directing AI agents, reviewing their output, testing assumptions and integrating the resulting components into something reliable.
That transition is already visible. Current research on agentic coding describes workflows in which developers initiate tasks while agents perform multiple rounds of inference and tool execution with relatively little human intervention during the individual task.
The developer increasingly becomes an architect, reviewer and decision-maker as well as a programmer.
That doesn't eliminate programming expertise. Quite the opposite.
It is difficult to evaluate generated code if you don't understand code.
It is difficult to recognize a poor architecture if you've never designed one.
And it is difficult to recognize an unusual failure mode if you've never watched systems fail.
AI reduces the cost of producing an implementation.
It doesn't eliminate the need to understand the implementation.
There was another weakness in the mythology surrounding the "rock star programmer": important software systems aren't created by programmers alone.
A successful system may require business knowledge, architecture, user-interface design, database expertise, cybersecurity, infrastructure, testing, project management and an understanding of the people who will actually use it.
Our original article made this point in 2020. Modern AI makes it even more relevant.
The future probably isn't a collection of individual programmers competing to see who can generate the most code.
It is more likely to involve people with different expertise working alongside increasingly capable machines.
The valuable person will be the one who can contribute judgment to that environment—whether that judgment comes from software engineering, business analysis, cybersecurity, data, user experience or deep knowledge of the industry for which the system is being built.
This creates an interesting problem for technology education.
We still need to teach programming fundamentals. A developer should understand variables, control structures, data structures, databases, APIs, object-oriented design, testing, algorithms and the principles behind the systems being built.
But teaching someone merely to reproduce syntax from memory makes less sense when a machine can generate that syntax almost instantly.
Technology education needs to move further toward understanding.
Why is one design preferable to another?
Why did this query perform poorly?
Why is this code insecure?
What happens if this service becomes unavailable?
Why should this data be normalized—or perhaps deliberately not normalized?
What assumptions did the AI make?
How would you verify its answer?
And perhaps the most important question:
What problem are we trying to solve?
Those are much harder questions than asking someone to remember the
syntax of a for loop.
They are also much closer to the questions professional developers actually encounter.
Looking back, perhaps the software industry misunderstood part of the lesson from those early productivity studies.
The most valuable developer isn't necessarily the person who produces the greatest number of lines of code or completes an isolated programming exercise the fastest.
It is the person whose contribution makes the entire system better.
Sometimes that means writing brilliant code.
Sometimes it means simplifying someone else's code.
Sometimes it means finding a flaw before it reaches production.
Sometimes it means helping another developer understand a problem.
And sometimes the most valuable contribution a developer can make is recognizing that the organization is about to spend six months building the wrong thing.
Artificial intelligence doesn't make those abilities obsolete.
It makes them easier to distinguish from typing.
Nearly sixty years after that small programmer-productivity experiment, we may finally be reaching the point where measuring great developers by how quickly they produce code makes very little sense.
The machines are becoming remarkably good at producing code.
Knowing what to do with it remains the harder problem.
Part of The Ego Tax series — stories on how overconfidence and inexperience quietly bankrupt software projects.A few years ago, the credential everyone suddenly needed was a Scrum certification. Companies that had never run a single sprint were requiring it in job postings for roles that had nothing to do with software delivery. Consultants built entire practices ...
Part of The Ego Tax series — stories on how overconfidence and inexperience quietly bankrupt software projects.Seventy percent of software projects fail or fall short. In the United States alone, the cost of software failure — projects abandoned, systems that don't work, money spent building the wrong thing — runs past two trillion dollars a year. That's not a ...
A student reached out recently with a question I hear constantly: what should she study to make sure she's employable when she graduates? She'd heard cybersecurity was booming. A friend said cloud computing was the safer bet. Someone else swore by data science.I gave her the same advice I'd give anyone asking this question, whether they're in school or already working: stop ...
In the early years of the commercial Internet, spam was more than an annoyance. It became an industry.Millions of unsolicited emails poured into inboxes advertising everything imaginable. Internet providers built increasingly sophisticated filters to stop them, lawmakers tried to regulate them, and companies began taking the people ...







