Donald Knuth once drew the line better than anyone has since: “Science is what we understand well enough to explain to a computer. Art is everything else we do.”
That is the whole argument, in one sentence.
AI has gotten very good at science. It can explain a sorting algorithm, generate a REST endpoint, refactor a tangled function, write tests for the happy path, and do it all in seconds. What it has not gotten good at — and what it cannot be prompted into — is everything else. The judgment. The taste. The decision about what is worth building in the first place.
This is not an argument against AI. If you are building software today and you are not using it, you are working with one hand tied behind your back. It is an argument for being honest about what the tool is, and what it is not. AI is a power tool. It does not become a carpenter because it can cut faster.
The science is now cheap
Let us give AI its due, because the article only works if it is fair.
Writing code used to be the bottleneck. It often is not anymore. Boilerplate, glue code, data transformations, first drafts of a feature, migrations from one library to another — these are pattern problems, and pattern problems are exactly what large language models are built for. They have read more code than any human ever will, and they can recall a plausible version of almost anything you ask for.
That is genuinely useful. It lowers the cost of starting. It lets a good developer try three approaches in an afternoon instead of one. It helps a developer working in an unfamiliar language or domain get to a workable first step instead of staring at a blank file.
But notice what happened in that sentence: a good developer tries three approaches. The tool did not choose the approach. It did not know which one fit the system, the team, or the user. It produced options. Someone still had to judge them.
That distinction matters more now than it did two years ago, because the cost structure has flipped. Code is cheap. Judgment is expensive. And judgment is where good software actually comes from.
The art starts before the first line of code
The hardest part of building software was never typing. It was deciding what to build.
A user does not come to you with a specification. They come with a frustration, half-explained, in the language of their job, not yours. “This report takes too long.” “Customers keep abandoning the checkout.” “We need this to work like the old system, but better.”
AI cannot sit in that meeting. It cannot hear what was not said. It cannot notice that the person asking for a feature is really asking for reassurance, or that two stakeholders are using the same word to mean two different things, or that the requested feature would solve this quarter’s problem while creating next year’s mess.
Humans do that work, and it is art, not science. It requires empathy, context, and the willingness to push back: Are we sure this is the problem? What happens if we do nothing? What are we choosing not to build?
There is a useful rule for this, the 20-60-20 rule: a human does the first 20 percent — framing the problem, the goal, the context, the why. AI is the middle 60 percent — generation built on that context. A human does the last 20 percent — review, selection, and prioritization. Skip the first 20, and the middle 60 is just fast work in the wrong direction. Skip the last 20, and you ship something no one actually owns.
AI can generate. It cannot frame. Framing is art.
The art is judgment under ambiguity
Even when the problem is clear, the path is not.
Should this be fast or simple? Secure or convenient? Built now or bought? Split into services or kept in one codebase? Optimized for the case we have today, or the case we might have in a year?
There is no correct answer in the abstract. There is only a trade-off, made with incomplete information, under time pressure, with real consequences. That is what Fred Brooks was getting at when he divided software into essential complexity and accidental complexity. Essential complexity is inherent in the problem itself — the conceptual structure you have to get right. Accidental complexity is the incidental difficulty of building it — the tooling, the syntax, the plumbing.
AI is very good at accidental complexity. That is why it feels so magical. It removes friction. But removing friction does not remove the essential problem. If anything, it exposes it. Once the code writes itself, what is left is the part Brooks said great designers were for: deciding what the system should be.
Consider two developers given the same AI tool and the same prompt. One ships a feature that is easy to maintain, easy to explain, and easy to change. The other ships a feature that works today and becomes a burden tomorrow. The difference was not the tool. It was taste: knowing when to stop, when to simplify, when a clever solution is actually a future bug, and when “good enough” is not good enough.
As Brooks also put it, “Good judgement comes from experience, and experience comes from bad judgement.” AI has no bad judgment to learn from. It has patterns. Patterns are not experience.
The art is knowing what “good” means here
Good software is not an abstract quality. It is good for someone, in some place, under some constraints.
Your codebase has a history. There is a library you avoid, and a reason — an incident six months ago, a licensing problem, a maintainer who disappeared. There is a pattern your team agreed on, not because it is the best pattern in the world, but because it is the pattern everyone on the team can maintain at 2 a.m. There is a customer whose data cannot leave a certain region, a regulator whose rule is ambiguous, a user who relies on a screen reader and will be locked out by a “minor” UI change.
AI knows none of that, unless you tell it, and you cannot tell it everything. Context is not a prompt. Context is years of working in a system, with a team, for real people.
This is why the most honest description of the new developer job is not “coder.” It is an editor, architect, and reviewer.. Simon Willison has made this point sharply: coding agents today work when a skilled individual with deep domain understanding poses a clear task, reviews what the agent produced, finds it has not solved the problem to their satisfaction, and uses their expertise to push it further. Without that skilled individual, he writes, the agent is useless. It may as well not exist.
That is not a limitation to be engineered away next quarter. It is the job.
The art is accountability
Here is the part no one wants to say out loud: AI cannot be accountable.
When AI-generated code ships a security flaw, no model takes the call from the customer. When it hallucinates a library, invents an API, or reproduces an insecure pattern from old training data, no model explains itself to the team. A human does. A human signs off, and a human lives with the consequences.
The research backs up why that sign-off matters. In a Stanford study, participants using an AI coding assistant were significantly more likely to write insecure code than a control group — and more likely to believe their code was secure when it was not. That gap between confidence and correctness is dangerous, because it makes bad code harder to catch in review.
A later Harvard study of more than 700 companies found a related bottleneck: AI tools generated about 30 percent more code but resolved no additional issues, because review times jumped by 49 percent and pull requests needed far more revisions. Faster drafting did not mean faster delivery. It meant more work for the humans who had to validate it.
That is not a reason to stop using AI. It is a reason to stop pretending validation is optional. Review is not bureaucracy. Review is where the art lives: a senior engineer reading code she did not write and asking, “Is this right for us?”
AI can be confident. Only a human can be responsible.
The art is making software for humans
Finally, and most simply: software is for people.
“Any fool can write code that a computer can understand,” Martin Fowler wrote. “Good programmers write code that humans can understand.” That was true before AI, and it is more true now, when more code than ever is being written by something that does not need to understand it at all.
Code is read far more often than it is written — by teammates, by future maintainers, by the person debugging an outage at midnight. Clarity, naming, structure, and restraint are not cosmetic. They are how a team thinks together. A codebase is a shared document, and like any good document, it needs an author with a point of view.
The same is true on the outside. A product is not just a set of features. It is an experience: what it feels like to use, who it includes, who it excludes, what it encourages. Those choices are aesthetic and ethical at once, and they cannot be averaged out from training data. Training data tells you what was common. It does not tell you what is right, or beautiful, or kind.
Edsger Dijkstra called programming “the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.” John Romero called it “logic-based creativity.” Both are right. The organizing, the mastering, the creativity — those are human verbs.
So what changes?
Nothing about the value of a good developer. Everything about where that value shows up.
The developers who thrive in this new world will not be the ones who type fastest, or who write the cleverest prompts. They will be the ones who frame problems clearly, who make trade-offs explicitly, who review ruthlessly, who keep systems simple enough to understand, and who care about the people on the other side of the screen.
AI knows science. It can produce the notes, at astonishing speed, in any key you ask for.
Humans still have to hear whether it is music.
