Agentic Coding: What Actually Changes About the Job

Most writing about agentic coding is about the agents. Benchmarks, demos, the weekly leaderboard reshuffle. I want to write about the other half of the equation, because it's the half I actually live with: what happens to the job — the daily work of building software — when agents do most of the typing.

I'm not speculating from a weekend trial. My companies run on this stuff daily, and have for long enough that the novelty is gone and what's left is the actual shape of the work. That shape surprised me. The tools are roughly what the demos promise. The job is not.

Here's the short version: agentic coding doesn't make the old job faster. It quietly replaces it with a different job — one where specifying and verifying are the work, and typing is overhead you've delegated. Most of the frustration I see people have with coding agents comes from doing the new job with the old job's habits.

What agentic coding is, and isn't

Worth pinning the term down, because it gets used for everything from autocomplete to science fiction.

Agentic coding is delegating a goal, not dictating keystrokes. You describe an outcome — fix this bug, add this endpoint, migrate this module — and an agent plans the work, reads the codebase, edits files, runs commands, reads the errors, and iterates until the goal is met or it gets stuck. The loop — act, observe, correct — belongs to the agent. That loop is what the word "agentic" is doing in the sentence.

That's a different animal from the autocomplete era, and the difference isn't degree: you've moved up a level in the delegation stack, and everything that changes about the job follows from that move. How today's tools split across that line — and which to pick — is its own post; this one is about the shape of the work, whatever you run.

Specification becomes the work

The first thing that changes: the prompt is now the artifact that matters most, and "prompt" is the wrong word for it. It's a spec.

When typing was the bottleneck, we could be sloppy about specification, because the person doing the specifying and the person doing the implementing shared a skull. Half-formed intent got refined in flight, silently, while you typed. Delegate the typing and that free refinement disappears: the agent builds what you said, and every ambiguity you left in the request comes back as something you didn't mean.

So the leverage moves upstream. The difference between a mediocre session and a great one is almost never the model — it's whether the task was specified well. The engineers I see get the most out of agents were, without exception, already good at writing tickets, design notes, and acceptance criteria. That skill just became the profession's core loop instead of its paperwork.

This is also, quietly, a seniority inversion. We spent decades treating "writes it down precisely" as a management-track skill and "makes the code go" as the technical one. Agentic coding welds them back together: writing it down precisely is how you make the code go.

Review becomes the bottleneck — and the skill

Here's the change nobody's demo shows: you now read far more code than you write, and reading is where your time actually goes.

An agent can produce a plausible diff faster than you can evaluate one. That inverts the historical economics of software, where writing was expensive and review was the afterthought bolted onto it. In my daily use, generation is nearly free and judgment is the scarce resource. The bottleneck — and therefore the skill that separates practitioners — is how quickly and reliably you can look at work you didn't do and decide whether it's right.

Two practical consequences I've paid to learn.

Plausible is the failure mode. Agent code doesn't usually fail by looking wrong. It fails by looking right — clean, idiomatic, confidently structured — while being subtly beside the point. The old skim-review that caught a tired colleague's typos is exactly the wrong instrument for work that never gets tired and never looks sloppy. You have to review against the intent, not the surface, which means the spec you wrote upstream is also your review checklist. The two new halves of the job are the same discipline seen from both ends.

Verification beats inspection. The strongest move in the new job is refusing to argue with code when you can interrogate reality instead — converting "this looks right" into "this demonstrably works." The tactical habits that follow from that are their own post; the theme underneath all of them is this shift from inspecting output to verifying outcomes.

The codebase becomes part of the instruction

The third change is the strangest one to internalize: your repository is no longer just the thing being worked on. It's part of the instruction set.

An agent walks in with no tribal knowledge. What it knows is what it can read: your file layout, your naming, your tests, your docs, the conventions your code does or doesn't keep. Every piece of structure is effectively a standing instruction to every future agent session — and every inconsistency is a standing invitation to guess. Codebases that were merely unpleasant for humans, who could ask the person at the next desk, are actively expensive for agents, who can't.

The practice of deliberately engineering what an agent can see — the files, memory, and feedback loops around the model — is its own discipline with its own failure modes, and I've written a full working guide to it rather than compressing it badly here. The point that belongs in this post is narrower: investment in repo quality used to pay off diffusely, in future-human goodwill. It now pays off immediately and mechanically, in every agent session, which changes the economics of cleanup work you've been deferring for years.

Delegation changes size, and so does your attention

Under the old job, the unit of work you handed to a tool was a line, maybe a function. Under agentic coding it's a task — and tasks parallelize.

This is where the job stops resembling programming and starts resembling something closer to running a very fast, very literal team. You learn what delegates cleanly (well-specified, verifiable, bounded blast radius) and what doesn't (taste-heavy, underspecified, touching things that must not break). You learn to keep several streams moving and to spend your own attention where judgment is actually required, rather than watching an agent work — the machine time is cheap, and your attention is the expensive input the whole system is arranged around.

And the boundary of what delegates keeps moving, which means part of the new job is re-testing your own assumptions about it. Things I wouldn't have handed over a year ago are routine now. The practitioners I've watched plateau are the ones who calibrated once and stopped.

What doesn't change

It would be dishonest to end without this section, because the discourse needs it.

Responsibility doesn't move. The agent wrote it; you shipped it. Every line that reaches production is yours in exactly the way it always was, and "the AI did it" has precisely the standing that "the intern did it" always had — which is to say, none.

Taste doesn't transfer. What good looks like — architecture, product judgment, the sense that this abstraction is wrong even though it works — remains stubbornly human, and agents amplify whatever taste is directing them. Good judgment, delegated, scales beautifully. Bad judgment, delegated, ships faster than it ever could before. The tools are honest amplifiers; that's a compliment and a warning.

The fundamentals got more valuable, not less. Knowing how systems fail, what a good test proves, why a design will hurt in a year — agentic coding pays a premium on exactly this knowledge, because it's what specification and review are made of. The typing was never the hard part. It was just the visible part, and now that it's delegated, what's left is the hard part, undiluted.

FAQ

Is agentic coding just a fancier autocomplete?

No — the short answer is that delegation of outcomes, not better suggestions, is what changes the job. The tool-level version of that distinction is the first half of the comparison post.

Does agentic coding replace software engineers?

It replaces a portion of the work — the typing-shaped portion — while raising the value of specification, review, verification, and judgment. The engineers thriving with it aren't doing less engineering; they're doing the concentrated form of it. What it genuinely does retire is the idea that output volume was ever the measure of the job.

How should I actually start?

Small and real: one task on a real codebase, not a toy demo — a demo teaches you nothing about the review half of the job. The session habits that make early tasks go well are their own post. Expect the first week to feel slower. That's the old job's habits objecting to the new job.

What's the biggest mistake people make with coding agents?

Treating the agent as a mind-reader on the way in and as an authority on the way out. It's neither: it's an extremely fast implementer of exactly what you said, checked exactly as hard as you check it. The habits that guard both ends of that mistake live in the tips post.