Robert Polding's Home

Why AI didn’t make programming easier, and what that means for anyone learning it now.

I learned to program on an Amiga, typing listings out of magazines and getting them wrong in ways that could swallow an entire afternoon before I found the one character that was out of place. Most of what I knew in those days was recall, which is to say syntax, function names, and the shape of an idiom I had already typed a hundred times, so getting better mostly meant getting more of that material into my head and then finding ways to keep it there.

That stayed a fair description of the job for about forty years, and the research broadly agreed with it. Brooks described programming as a process of holding several interacting abstractions in mind at the same time, Pennington showed that programmers work from mental models of control flow and data flow rather than from the text on the screen, and Siegmund and colleagues eventually put developers in fMRI scanners and found that reading code activates the networks associated with working memory, attention and language processing. Programming was expensive in cognitive terms, and memory sat right at the centre of it, functioning simultaneously as the thing that made expertise possible and the thing that put a ceiling on it.

What has happened over the past few years is that we have handed every developer an external memory system, and the consequences of that are stranger and less comfortable than most of the enthusiasm around these tools would suggest.

What actually got offloaded

Coding assistants are genuinely good at a fairly narrow set of things – generating boilerplate, retrieving syntax you only half remember, reconstructing the context you lost when you switched tasks, and producing a plausible first draft of something you would otherwise have had to assemble by hand. Barke, James and Polikarpova found precisely this pattern in how developers actually use Copilot, with people offloading the low-level work and then spending the time they recovered on validating and integrating whatever came back.

It helps to be clear that this is not simply a faster search engine, because the relationship people form with these tools is qualitatively different from the one they had with Stack Overflow. Hutchins used the term distributed cognition to describe systems where the thinking extends beyond the individual and into the surrounding environment, and that is a reasonable description of what a developer and an assistant look like when they are working well together. Cognitive load theory offers a slightly different angle, suggesting that the tool strips out the extraneous load of recalling syntax and boilerplate and thereby frees working memory for the parts of the problem that genuinely require thought. The Extended Mind Hypothesis pushes the idea furthest of all, arguing that once an assistant is reliably available, habitually used and broadly trusted, it stops being something you reach for and becomes a component of how you think in the first place.

Whichever of those framings you find most convincing, the practical consequence is the same, which is that the penalty for imperfect recall has more or less collapsed.

What did not get offloaded

The parts that require you to understand why something works have stayed exactly where they were, and if anything they have become more prominent because there is now so much more generated code to evaluate.

Anyone who has used these tools for real work knows that they produce code which is syntactically flawless and semantically wrong on a regular basis, and catching that requires a working model of what the system is actually supposed to do, which is not something you can request from a prompt. Architectural reasoning, impact analysis, debugging, refactoring and the long slow business of maintaining something over several years all depend on a structural understanding of the codebase that remains firmly the developer’s responsibility.

The evidence coming out of education is worth paying attention to here. Shihab and colleagues found that students working on brownfield tasks with Copilot finished substantially faster and made more progress than those without it, but a striking number of them admitted in exit interviews that they did not really understand why the suggestions had worked. Alanazi and colleagues, reviewing controlled studies across a range of these tools, found that AI assistance reliably improves task performance and efficiency while delivering only small and statistically unstable gains in actual learning. Output goes up, comprehension stays where it was, and the gap between those two things is where most of the interesting problems now live.

The hard part, in other words, has moved rather than disappeared. It used to sit in the question of how you write something, and it now sits in the question of whether what you are looking at makes any sense, which is a shift from recall to judgment and a considerably less comfortable place to spend your working day.

Four things this changes

The first is that the field opens up, and I think this is genuinely good news. A great many capable people bounced off programming because of the sheer overhead of memorising libraries, syntax variations and error handling idioms rather than because they could not think clearly about systems, and that particular barrier is now much lower than it was. There is a paradox sitting inside this, though, because while the barrier to producing code has dropped, the barrier to producing code worth keeping has probably risen, and judgment turns out to be considerably harder to develop than recall ever was and much harder to fake convincingly.

The second is that the work has become differently difficult rather than simpler. My students used to get stuck on missing semicolons and misapplied APIs, whereas now they get stuck on whether a generated solution is appropriate, maintainable and consistent with the rest of the system they are building, which is a more sophisticated kind of stuck that demands software engineering principles rather than familiarity with language features. It also arrives much earlier in their education than it used to, before they have accumulated the experience that would normally support that kind of judgment.

The third is that education has to move in response, shifting away from syntax and towards architecture, interface design, state management, failure modes, constraint negotiation, test construction, security and long term maintainability, with code understood as one representation of thought among several rather than the only one that counts. I have been pushing final year students to treat these tools as something they direct rather than something they consult, and the difference in outcome between the students who can do that and the students who cannot has become the most visible division in the cohort.

The fourth, and the one I care most about, is that the programmer remains essential, though not in the way we used to describe it. The value has moved away from being a vessel of accumulated knowledge and towards being the orchestrating agent who understands the parts, knows how they fit together, protects the integrity of the whole thing and decides what actually matters. The strongest developers of the next decade will not be the people who type fastest or remember the most obscure API, but the ones who can hold a durable mental model of a large system in their head while offloading everything that would otherwise interfere with holding it.

The uncomfortable part

There is a real risk buried in all of this that I do not think we have taken seriously enough yet. Stable internal models of a codebase are what allow you to simulate execution mentally and trace cause and effect through a system, and if you outsource enough of the thinking those models quietly get thinner, which means you can spend months shipping faster while understanding less and never notice until something breaks in a way the assistant cannot explain to you.

Medicine went through a recognisable version of this transition some time ago, when diagnostic tooling reduced the need to memorise obscure clinical detail and simultaneously raised the stakes on interpretation and error detection. Expertise did not disappear in that case, it changed shape, and the practitioners who adapted well were the ones who understood what the tooling could and could not tell them.

My own view is that AI has not diminished the craft of programming so much as widened it, deepened it and made a great deal more of the work explicitly intellectual. We are asking people for judgment where we used to ask for recall, for architecture where we used to ask for syntax, and for orchestration where we used to ask for implementation, and none of those are easier skills to acquire or to demonstrate. They are simply different ones, and I suspect that over time they will prove to be considerably more demanding than what they replaced.

---

This is a shorter and more personal take on a piece from Communications of the ACM, which sets out the full argument along with the references: AI Didn’t Make Programming Easier, It Just Made It Differently Difficult