Four Horsemen, or Four Decisions?

Alex Martsinovich wrote "The Four Horsemen of Agentic Coding," which says that agentic coding is damaging us in four ways he can name and can't fix: slop, alienation, deskilling, and team fallout.

In his article, LLM code has a smell that drives humans out of a codebase; distance from the artifact erodes care; skills atrophy and nothing replaces them; and team chat goes quiet because everyone is talking to their own set of homunculi.

He closes by saying he doesn't know what to do with any of it.

He's... not wrong, and he's eminently quotable. But it's a bleak read, and it's bleak because he's reading choices as fate. Choices can be changed.

Deskilling is an audit

The deskilling argument assumes the skill being lost is the one worth keeping. That feels almost like a zero-sum engagement, where we gain one skill and lose another in equal measure, and that's not what our field ever entailed.

As programmers, we like writing code: it's "what we do." But we rarely know how, really, and the way we work hides that. We get a spec, like "write hello world," we churn out instructions for a CPU, and think we're done - and maybe for that specification we are. But then a specification like "just mount the filesystem" gets submitted, and the thinking gets deferred to someone who wants to write code rather than think about what "mounting a filesystem" means in context. And since the issue's getting worked on, everyone's happy until it's deployed and everyone goes "no, no, we needed to look at the filesystem state, not read files."

An agent is, well, a lot worse at deferring it, although it can be instructed to prefer code over analysis. But even then, it has to understand what "just mount" means before it can do anything, so it asks or guesses, and either way the gap shows up on the first pass instead of the fourth sprint. That's not a skill being taken away. That's the job revealing which skill it always required. The skill that everyone feels like they're losing is popular. The skill being exposed... is necessary. Deskilling here isn't really net deskilling as much as it's leveling up the skills that actually get exercised, and as with physical exercise, we choose what to focus on.

Alienation is a trust process without a review step

Martsinovich undersells alienation by describing it as a feeling. The problem isn't that distance makes us care less; it's that trust accrues per task and never gets re-evaluated. The agent handles something reasonably, so the next thing gets a lighter look, and the thing after that gets "okay, I trust this model, it's fine." A week later you go back and find an assumption it made in flight, which was reasonable at the time and which everything since has been built on, and realize it should have been a much bigger deal than it was.

That filesystem example again: the agent might say "Cool, you need to iterate through the files, because that's what a filesystem contains," and the human nods wisely and says, "Yes, yes, exactly, give me the files." But what if the program needs to analyze the state of the filesystem? That's not just "read the files" but looking at slack space, allocation, deleted file state, inodes, the gamut - it's a fundamentally different workload than "give me the files," even though "give me the files" might be a large part of the intent. But if you don't catch that intention early, especially if you're thinking the model guessed right in prior efforts, well...

You get to look at the code "you" wrote, as a stranger.

That's not alienation in the affective sense. People who care a great deal get burned by it. It's a process failure, and process failures have shapes: the assumptions a model is allowed to make need the same periodic re-examination as the ones a human teammate makes, and right now almost nobody schedules that, because it's a drag, man.

Slop is a budget line and an onboarding step

Slop has a floor and a ceiling, and they have different causes. The floor is procurement. Choose a small open model with a short context window for an application with real-world consequences and you'll get what you paid for, in the same way you'd get it from a contractor at a fifth of the going rate. That's not an AI problem. Someone has approved it.

The ceiling is where Martsinovich's examples live, and there the complaint is about style persisting regardless of spend. But at the top, what's left isn't slop. It's a model with defaults that don't match the codebase, which is what every strong senior hire brings on their first PR, and nobody calls that slop. They call it onboarding, and they fix it with a conventions file and a set of review processes.

There's a third cause nobody talks about: frontier models aren't the hammer for every nail. What you find is that the top tier earns its keep on analysis and design. The middle tier is better at writing the code, not just cheaper, and asking a frontier model for a "really good hello world" gets you something thorough, hedged, over-general, and expensive¹. A fair amount of what reads as frontier slop is an analyst being asked to do production work and doing it the way an analyst would.

Ask someone who designs CPUs for a light switch, and they'll bring CPU-grade engineering to it. You'd get the most fantastical light switch ever... and it would exceed your requirements for a simple toggle, just like the frontier models overachieve by default.

Team fallout is the one he's most right about

The quiet Slack channel observation is hard to impugn, and it isn't fixable by a single team's practice, because the incentive to ask a colleague instead of an agent has to be rebuilt deliberately, and the field has been terrible about interactions almost as a rule.

Some communities avoided it - programming an Apple //e or the Commodore 64 made community almost mandatory, and those environments lived in programming clubs, sharing software and ideas and observations like mad, in rooms where nobody would have noticed if you'd shown up in a cape². But professionally, we tend to be loners; without intent, we often isolate from our peers, because we don't want to seem ignorant. The agents don't suffer that exposure - an agent might tell you that you're wrong, but it doesn't have a social cost; you don't lose face when an agent informs you of a concern you should have thought of already, and thus...

Martsinovich lands a strike that hits pretty close to home. It takes intention and effort to overcome, and that's an investment on the part of the teams involved³.

Deskilling is the wrong skill mourned; alienation is the wrong trust horizon, and slop is the wrong model for the budget, or the wrong model for the task; team cohesion is a matter of acceptance and intent. Martsinovich's piece says the technology is costing us. I think it's making the cost of our choices visible, which is less comfortable and more useful, because choices can be changed.