Taste

Programmers have taste. Good programmers have good taste.¹ Coding agents don’t have taste, so they cannot replace programmers.

That argument depends on:

1. Taste being valuable
2. Coding agents actually not having taste, or acquiring it later

Agents do seem to sometimes have taste: they can choose between implementation approaches (e.g. in Plan Mode or thinking traces) based on criteria a good human programmer would at least recognise, if not even agree with.

The taste argument is usually that the solution doesn’t make sense in the broader context - it doesn’t fit in with (or duplicates) the rest of the codebase, or doesn’t fulfil some requirement the agent didn’t take into account, or doesn’t meet some non-functional criteria like testability. The common thread is latent knowledge. A sufficiently experienced human programmer, familiar with the domain and codebase, knows these things, along with their relative importance and how and when to trade them off.

Goes the counterargument: “we just need to get better at writing down these requirements!” Latent knowledge has always been a challenge, e.g. for onboarding new contributors, or when that sufficiently experienced programmer leaves the company. It’s tempting to think that if only we had nice, well organised Markdown docs for all those conventions, gotchas and rituals, then not only would agents perform better, so would the humans on the team.²

Well, yeah. But. That argument goes both ways. It was already valuable before agents to reduce taste to a playbook. But very few organisations did it. Even among those who did, even fewer removed all their human guardrails - code review, committer rights, project leads. It’s hard to imagine having zero concerns when that critical engineer leaves because they documented everything so well.

Why not?

1. It’s very hard to extract all of the latent knowledge about a project.
2. Assuming you do extract and document enough of it, there’s probably way too much of it for any human to easily read, at least without spending enough time on the project to develop their own sense of taste. Similarly, it’s easy to blow out an agent’s context window with a project readme, never mind this hypothetical comprehensive taste playbook.
3. Keeping all that documentation organised and up to date as things change is equally hard, as anyone who’s tried searching a corporate wiki can testify.
4. Just telling new contributors what taste looks like isn’t usually enough - you want to verify their contributions meet your own sense of taste. With a human left in the loop that might look like peer review. Without, even documenting isn’t enough - you need to express all the aspects of taste as automated tests.

Ultimately I just don’t believe it’s possible to encode all the latent knowledge about a project as an automated test suite. What does a test look like for “it is appropriate in this scenario to ship with five unresolved security issues”?

That isn’t to say that a cabal of visionaries has to review every contribution forever. Organisations scale taste through trust. That’s a messy human algorithm taking into account past contributions, temperament, incentives, and relationships. Once you know someone reliably makes good decisions, and asks for a second opinion when they’re not sure, you stop needing to check their work.

How does a human develop trust in a coding agent? I think that’s an unsolved research problem. We have a bunch of anecdata with mixed results (“Claude writes all my code but I still have to check its work”, “it sometimes gets stuck in a loop”, “it just deletes the tests that don’t pass”). A common method is to just pretend the agent is a human and trust it like one, but that works very poorly, because humans don’t routinely forget everything they knew and start again from a summary of the last two hours, or change their entire personality because they read a Markdown file. Nobody has a good mental model for how to trust something that behaves like that.

This is only an argument against coding agents fully replacing human programmers. It’s not saying they aren’t useful. It isn’t even really expressing an upper bound on their usefulness: plausibly the more you can automate taste and verification, the more useful agents become.

That’s my best guess for where the industry goes - toward systematisation, but not all the way. Software engineers have always partly been process designers³: that aspect of the role will become more important, and more rigorous. That will look familiar to engineers in other fields, where “going to production” literally means “designing a process to repeatably do the thing we’ve done once”. But other fields have long had automated production lines, and they still employ humans.

Just because dark factories exist doesn’t mean all factories can, or should, be dark.

Footnotes §

1. That is, one of the ways to be a good programmer is good taste. (As is speed, debugging skill, intuition for performance optimisation, etc.) ↩

2. At least until the agents, newly empowered with taste, made them all redundant. ↩

3. So have engineering managers. I could see the two roles converging more than in the past. ↩