Many coding tasks can be automated
But I think you know this already
Many coding tasks can—and should—be automated.
I’m guessing that you now want to object, that you’re here because the title pulled you in for a hate-read. I am aware that, in the parlance of our times, saying this makes me sound like an AImaxxer. But this never used to be controversial. Much of what programmers do is mechanical, and programmers are often frustrated that not enough of these mechanical tasks can be performed by a machine.
These were once all pretty standard complaints:
Programmers, inexplicably stingy, and will not buy coding tools or software libraries despite being paid more than well enough to.
The industry as a whole exhibits a tragedy of the commons as every business is happy to accept free programming tools but few are willing to contribute to them.
An old sentiment1 that it should not be possible for programming to become dull, because any rote tasks can be turned over to the machine, has sadly fizzled out.
In 2010, my employer bought some IntelliJ licenses. It was reliable, fast, and ergonomic. You could pull up the call hierarchy of any function. Jump-to-source worked with external libraries. Renaming anything would automatically update its use sites. You never looked at the import statements. If you stopped using something, the import disappeared automatically. If you cut some code into the clipboard and pasted it into a different file, the import list in the target file would update automatically and flawlessly. 2010 was the last time I felt like programming tools were on an upward trajectory. I have not been delighted by a new editing experience ever since, many of the features I had in Java I don’t have anymore in other languages, and much of time spent in programming is still a dull slog.
And then came Claude
It is difficult to have a public conversation about tools like Claude Code, because they are at once everything and nothing, and rarely are we ever talking about the same thing. For this discussion I wish to select a narrow focus: Does this tool offer anything that reproduces or exceeds the modest but useful editing conveniences that were introduced into my job by IntelliJ in 2010? I think the answer has to be a qualified yes. There are more editing commands at my disposal now that will reliably work, and they’ll work even if the language hasn’t seen the amount of tooling investment Java has.
The major qualification is that, compared to actual tools, agentic refactoring can be slow, both in the speed of each step, and in the overall methodology which usually involves a trial-and-error interaction with the compiler to finish ironing out the details. Still, even if it takes longer, there is value in not being hands-on with the code constantly. It’s too easy to “get lost in the weeds” when programming. You start sifting through error messages and forget what the high-level goal you had been pursuing even was. Even if the tool is slower than you, applying it to some drudgery may make it easier to keep in mind what the hell you are even trying to do.
One can fail to accept this blessing. AI is known to intensify work: “When generative AI tools enter the workflow, employees often expand the scope and pace of their work rather than reducing hours.” To me this is a false dichotomy that neglects a third approach, which is to take advantage of the tool to perform the same work in the same amount of time, but do a better job at it. There’s a common perception among the hypebeasts that you should be using AI to work on three different tasks at once. Instead of trying to multitask to fill in the gaps of Claude’s latency, give it some tasks where it is unlikely to fail, and step outside and weed the garden while it runs. Don’t intensify or speed up your work. Use the breaks to give yourself space to think more clearly (which will, in the bigger picture, speed up your work).
The overall cost/benefit is hazy, as of course there are plenty of other costs not addressed here. But on the question of “does the thing really work,” constrained to the domain of this discussion and ignoring loftier aims, one must concede that it does. Just because there are a lot of applications of AI that are dumb (hello, Mr Dawkins), doesn’t mean it has no applications. Probably the majority of the applications are bad, like trying to turn a prompt into an app. The world doesn’t really need more apps, let alone vibe-coded ones. But what the monkey chooses to do with the technology is not necessarily an indictment of the technology itself. It has real, modest uses for computer programmers, even (or perhaps especially) those who care about code quality and maintenance.
That’s all, folks
What captivates the imagination is when we seem to be getting something for nothing. Even when achievements of Claude are minimal, seeing a machine gain capability out of thin air is just not something we’re used to. IntelliJ, which bestowed some ergonomics unto Java, was born out of the efforts of a bunch of people working to serve a rare market of programmers willing to pay for something. For a lesser-used language, say Haskell, lacking such a market, conventional wisdom suggests that no comparable functionality ought to emerge. And yet here we are. It did.
The truly captivated appear to the rest of the world as the Seers of Bird Box. These monomaniacal followers of an eldritch horror, convinced that they have seen something truly wonderful, now live only to show others. Everyone else would surely see the beauty too, if they would only look. But whatever it is, it only makes most people want to die.
There’s one narrative that says AI contains a spark of magic that programmers are best positioned to recognize. There’s a simpler explanation: There aren’t very many things that this iteration of AI is capable at. Coding (specifically, a subset of coding work) is one of the few applications that shows any promise, thus coders are the few people who perceive some value.
So what does that say about programming?
Even if all the AI companies disappeared tomorrow, we still could be thinking about what we learned from all this.
A lot of computer programming is translation in various forms. Let’s say you speak English, and you might know a few programming languages. But you don’t know every programming language, every library, every DSL, the specific language used by every tool and every service provider ever. So a lot of your day is spent translating between English and a bunch of conlangs, and between different conlangs, including the one you have been inventing for yourself as you have been writing your program and defining new terms. Machine translation is what corpus linguistics (which would give rise to LLMs) was designed for. It’s proficient at that.
Programming involves a lot of tedious cleanup chores. At least, for some people it does. Some prefer to let a mess rot, because organization is dull work that confers no glory. The AI tools excel at cleanup, because reorganization is just another facet of translation. A thinking being must direct, judge, and understand what qualities are valuable. But the execution, the means of translating mess into order, is mere mechanism. It chiefly entails translation of intent into mechanical steps.
I want to reiterate this point because I think it’s underappreciated. If I had to use AI tooling for exactly one kind of task, I would choose cleanup. If you know what code quality looks like and are willing and able to prioritize it, you can often write higher-quality software with AI assistance than without it. This is going to be a controversial point because vibecoding has a well-deserved reputation for churning out nonsense. It’s true, you can’t just tell your agent “make the code good” and expect anything good to happen.
This is because the tool is dumb. It does not know what is good. You are still driving. And most people (in increasing proportion, now that more people are producing code) are either not experienced enough to know what is good and how to make it happen, or are unable or unwilling to put in the time. An AI tool is just a fancy editor, so it cannot get there on its own. But getting there involves a lot of editing! So, of course, a fancy editor can help.
Programming involves consulting an ungodly amount of reference material, something which I think we have known and reflected in the “I don’t actually know anything, all I do is Google stuff all day” meme. This has always been half truth and half false modesty, and I don’t hear it so much now that perhaps we feel we can’t afford to be self-deprecating anymore.
Codebases are big, and a change to “the code” can often mean changing a few things here and there in a bunch of different places. Corporate wikis, full of company documentation and historical lore about the old timers who know exactly why this piece of duct tape is in this file, are big. The public web is big. Claude will search it all for you. It will use all the same tools you would: find, grep, pull a web page of documentation, submit a search query to Jira. It’ll be using curl instead of a web browser, but same concept. For you, it’s a pain that each of those tools and services has a slightly different interface, speaks a slightly different language. For a translation machine, these bumps create no impediment.
And what does this say about AI?
To use AI tools in effectively programming, you have to understand the limitations of their scope and apply them primarily to search and translation tasks.
You probably can’t extrapolate from any AI successes in programming to predict AI successes in domains that aren’t dominated by search and translation tasks.
Machine learning has plenty of other avenues for search and translation work that predate and continue alongside LLMs, which are neither the first nor the last word in this space.
I thought this was a quote by John von Neumann, but now I can’t find it anywhere, so maybe I made it up.