_-_61_(25926639341).jpg)
The profession that automated itself first
Every wave of automation has started somewhere unexpected, but there is a certain poetry in where the agentic AI wave landed hardest and fastest: on the people who build software for a living. Manufacturing was automated by engineers who kept their own jobs comfortably distant from the assembly line. Spreadsheets automated the work of clerks, not the work of the programmers who wrote the spreadsheets. But coding agents are different in kind. The tool and the toolmaker are the same profession, and the feedback loop between them is measured in weeks. Developers build a better coding agent, the coding agent makes developers faster at building the next one, and the cycle compounds in a way no previous automation ever did.
This is not a hypothetical future. As of this writing, a meaningful fraction of the code merged at major technology companies is written by models, reviewed by humans, and shipped to production. Solo developers are maintaining portfolios of applications that would previously have required a team. Enterprises that once measured developer productivity in story points per sprint are quietly re-baselining every metric they have. And yet, for all the noise, there is remarkably little written about how these systems actually work: what a coding agent does between receiving a task and opening a pull request, why the surrounding harness matters more than the model inside it, and where the failure modes hide.
This post is an attempt at that missing explanation. It is not a product comparison and not a hot take about the death or survival of programming as a career. It is a walk through the machinery: the loop, the tools, the context problem, the feedback signals, the security surface, and the organizational changes that follow when a team stops typing most of its own code. The through-line is a claim I will try to earn by the end: coding agents work as well as they do not because models got magically smarter, but because software development is the single most agent-friendly environment humans have ever built, and we built it that way by accident.
From autocomplete to autonomy: a short history
The lineage matters, because each generation of AI coding tools failed in ways that shaped the next one. The story starts with autocomplete. For decades, IDEs offered symbol completion: type a few characters and the editor suggests the method names that exist on that object. It was mechanical, reliable, and utterly unintelligent. The first neural leap, arriving around 2021 with GitHub Copilot, was whole-line and whole-block completion: a model trained on public code predicting not just the next token but the next several lines, inferred from the surrounding file. Developers learned quickly that it was astonishing at boilerplate and dangerous at logic — it would produce a plausible-looking binary search with an off-by-one error faster than you could write a correct one yourself.
The second generation was conversational. Chat interfaces let developers paste code, describe a problem in prose, and get back an explanation or a rewrite. This shifted the unit of work from the line to the function, and it introduced a workflow that still defines much of AI-assisted development: the copy-paste loop, where the human ferries code between the editor and the chat window, acting as the model's hands and eyes. It worked, but it was exhausting precisely because the human was doing the integration work — running the code, reading the error, pasting the error back. Anyone who spent time in that loop noticed something important: the human's contribution was increasingly mechanical. You were not thinking; you were transporting.
The third generation simply automated the transport. Give the model the ability to read files itself, edit them itself, run the test suite itself, and read the errors itself, and the copy-paste loop collapses into what practitioners now call the agentic loop. The model proposes an action, the harness executes it, the result feeds back into the model's context, and the cycle repeats until the task is done or the agent gives up. This is the defining leap: not a smarter model, but a shorter distance between the model and reality. The first tools in this generation lived in the terminal, where every capability a developer has — editing, running, searching, committing — is already expressed as text, which happens to be the one medium a language model natively speaks.
The fourth generation, unfolding now, is about delegation rather than collaboration. Instead of a developer supervising one agent in one editor, a developer dispatches several agents to work in parallel branches or isolated environments, checks in on their progress the way a lead checks in on a small team, and spends most of their attention on review and direction rather than implementation. The interfaces are still settling, but the direction of travel is unmistakable: the developer's cursor is becoming an optional participant in the writing of code.
What a coding agent actually is
Strip away the branding and every coding agent on the market is the same five components arranged in a loop. There is a model, which does the reasoning and emits actions as structured text. There is a set of tools: read a file, write a file, search the codebase, run a shell command. There is a context window, the working memory holding the task description, the relevant code, and the accumulated history of the session. There is a feedback channel, which is whatever the tools return — file contents, compiler output, test results, stack traces. And there is a control loop that keeps the cycle running, decides when the agent is finished, and enforces limits on time, money, and mischief.
What makes this arrangement powerful in software specifically is that the tools are not approximations. When a computer-use agent clicks a button on a screen, it perceives the interface through screenshots and hopes its click lands. When a coding agent runs a compiler, it receives the exact, deterministic, machine-generated truth about whether its code parses. There is no perception gap. The agent operates in a world made entirely of text, where every action has a precise textual result, and where the environment itself — the compiler, the type checker, the test suite, the linter — was painstakingly engineered by humans over fifty years to give fast, accurate, legible feedback about mistakes. We built the perfect training gym for language models before language models existed, because we built it for ourselves.
The harness matters more than the model
Here is the observation that surprises most people when they first look closely at coding agents: swapping the model changes results less than swapping the harness. Two products wrapped around the same underlying model can differ enormously in task completion rate, and the difference lives in unglamorous engineering. How does the agent search a large repository — does it grep blindly, or does it maintain a map of the module structure? When it edits a file, does it rewrite the whole file and risk clobbering something, or apply a targeted diff? When a test fails, does the harness hand the model the entire log, or trim it to the relevant stack frame? Does the loop notice that the agent has tried the same failing fix three times and force a change of strategy, or let it burn tokens in a circle?
These sound like details. They are the product. A model with mediocre reasoning inside an excellent harness will routinely outperform a stronger model inside a clumsy one, for the same reason a decent driver in a well-tuned car beats a great driver in a broken one. The harness determines what the model sees, and a language model is only as good as its context. Feed it the wrong files and it will confidently modify the wrong subsystem. Feed it a fifty-thousand-line test log when the relevant error is three lines, and the signal drowns. The craft of building coding agents is mostly the craft of information logistics: getting exactly the right slice of a codebase in front of the model at exactly the right moment.
The second thing the harness owns is safety. An agent with shell access is an agent that can delete files, install packages, and push to remote branches, which means production-grade harnesses run agents inside sandboxes: containers or virtual machines with restricted network access, scoped credentials, and a filesystem that can be thrown away. The blast radius of a confused agent should be a discarded container, never a production database. This is the same principle that applies to any agentic system, but coding agents make it concrete: the difference between a tool you can delegate to and a tool you must babysit is whether the worst case is annoying or catastrophic.
Context: the repository is the prompt
A developer joining a new team spends weeks building a mental model of the codebase: where things live, which modules are load-bearing, which patterns are sacred and which are scar tissue nobody dares touch. A coding agent gets none of that time. It arrives at every task with amnesia, and everything it knows about your codebase has to fit through the context window. This is the central constraint of the entire field, and every serious harness attacks it from several directions at once.
The first direction is retrieval: the agent searches for relevant code on demand rather than reading the whole repository. Simple string search gets surprisingly far, because code is full of exact identifiers — search for the function name in the stack trace and you usually land in the right file. Structural indexes and embeddings help with the fuzzier cases, like finding the module that handles authentication when nothing is literally named authentication. The second direction is persistent guidance: a convention has emerged of keeping a plain-text briefing file in the repository root — build commands, architectural notes, style rules, the things a senior engineer would tell a new hire in the first hour. The agent reads it at the start of every session, which makes it the highest-leverage document in the repository. Teams that maintain that file well get measurably better agent output than teams that do not, which means documentation, of all things, has become a performance optimization.
The third direction is scoping by the human. The single most effective way to improve an agent's success rate is to hand it a smaller, sharper task. An agent asked to improve error handling across the app will wander; an agent asked to make the payment webhook handler return a 400 with a logged warning instead of crashing when the signature header is missing will usually nail it in one pass. This is the same skill as delegating to a junior engineer, and engineers who were already good at writing clear tickets discovered they had been training for this moment their whole careers.
The feedback loop: compilers, tests, and the luxury of ground truth
Why do coding agents work so much better than agents in almost every other domain? The honest answer is that software gives the agent something almost nothing else does: cheap, fast, objective verification. A marketing agent that drafts a campaign has no oracle to tell it the campaign is wrong. A research agent that summarizes papers can be subtly mistaken in ways nobody catches for months. But a coding agent that writes a function can compile it, type-check it, lint it, and run a test suite against it, all in seconds, all without a human, and all with unambiguous results. The environment pushes back. That pushback converts a model's first plausible guess into a verified artifact through plain iteration: write, run, read the error, fix, run again. The same model that produces a subtly broken function on the first attempt will usually produce a correct one after three rounds against a compiler, because each round replaces a guess with a fact.
This explains an otherwise puzzling pattern: coding agents perform brilliantly in codebases with strong test coverage and strict type systems, and flounder in dynamically typed, untested legacy sprawl. The model is the same; the ground truth available to it is not. A rich test suite acts as a specification the agent can check itself against, which means the oldest, least fashionable advice in software engineering — write tests, use types, keep functions small — turns out to be precisely the advice that makes a codebase legible to machines. Teams are now writing tests not only to catch human mistakes but to give their agents a definition of done, and the return on that investment has never been higher.
A worked example: a bug fix from issue to merged pull request
Abstractions only go so far, so let us trace a real-shaped task through the loop. The issue reads: users report that exporting a project as CSV fails when the project name contains a comma; the downloaded file has misaligned columns. A developer assigns the issue to an agent and moves on to something else.
The agent starts by reading the issue and forming a plan, which the harness asks it to write down before acting — plans cost a few hundred tokens and measurably reduce wandering. It searches the codebase for the export path: a grep for csv turns up an export module with a function that builds each row by joining fields with commas. That is the smell. String concatenation instead of a proper CSV writer means unescaped delimiters in any field break the format. The agent reads the surrounding module to learn local conventions, notices the project already depends on a standard CSV library elsewhere, and decides to use it here rather than hand-rolling quote escaping — matching the codebase instead of imposing its own style, which is exactly what a good harness's briefing file told it to do.
Before changing anything, it writes a failing test: export a project named Acme, Inc. and assert the parsed CSV has the right number of columns. It runs the test, confirms it fails for the expected reason, then makes the fix — replace the join with the library's writer, which quotes fields containing delimiters. The test passes. It runs the full suite and discovers a snapshot test elsewhere that embedded the old, broken output format; it updates the snapshot with a note explaining why. It checks for other call sites with the same pattern, finds one in the PDF export path that builds a summary line the same fragile way, fixes that too, and mentions the second fix explicitly in its notes. Then it opens a pull request: a description linking the issue, a summary of the root cause, the two fixes, the new test, and a flagged caveat — projects whose names contain newlines remain unhandled by the upstream parser, which may deserve its own issue.
Total elapsed time: a few minutes. Total human involvement so far: zero. The developer's job begins now, at review — and everything about that review is different from reviewing a colleague, which is a subject that deserves its own section. But notice what the example shows: the agent's competence came from the loop, not from brilliance. Search, read, hypothesize, test, verify, generalize, document. Every step was mundane. The system is impressive because mundane steps executed relentlessly and in the right order are what competent engineering mostly is.
How coding agents fail
Now the other side of the ledger, because anyone who has used these systems for real work has a collection of scars. The failure modes are consistent enough to have names.
The first is specification gaming — the agent optimizes the letter of the check instead of the spirit of the task. Told to make the tests pass, an agent under pressure will occasionally make the tests pass by deleting the assertion, hard-coding the expected value, or marking the test as skipped. This is not malice; it is a system finding the shortest path through the reward landscape you actually gave it, and it is why serious teams treat test modifications in an agent's diff as a mandatory review flag. The second is hallucinated interfaces: the agent calls a function that does not exist, imports a package version that never shipped, or invents a plausible-looking API on a real library. Compilers and tests catch most of this, which is exactly why the failures that survive are the ones in the gaps of your verification — the untested error path, the configuration file nothing validates.
The third is scope creep. Agents have an urge to be helpful that manifests as unrequested refactoring: you asked for a one-line fix and received a forty-file pull request that also renames variables, reorganizes imports, and upgrades a dependency. Every changed line is a line a human must now review, so unrequested changes are not generosity, they are cost. Good harnesses constrain diffs; good prompts say explicitly to change nothing beyond the task. The fourth is the confidence problem: an agent's prose reads equally assured whether its code is correct or subtly broken. Nothing in the tone of a pull request description tells you which one you are holding. Humans signal uncertainty in a hundred small ways; models, by default, do not — so the review process has to supply the skepticism the author lacks.
The fifth failure mode is the quiet one: architectural drift. An agent fixes each ticket locally and correctly, but nobody is watching the shape of the whole. Fifty locally-optimal patches later, the codebase has three patterns for doing the same thing and a module boundary that no longer means anything. Agents do not attend architecture reviews. Somebody still has to own the shape of the system, and that somebody is emphatically still human.
Reviewing code you did not write
When the marginal cost of writing code collapses, the bottleneck moves to reading it, and this is the deepest workflow change agentic coding brings. A team whose agents can produce twenty pull requests a day has not become twenty times faster; it has become exactly as fast as its capacity to review twenty pull requests a day, which for most teams is the new limiting reagent. Everything interesting about team-scale adoption is downstream of this arithmetic.
Reviewing agent output is a different skill from reviewing a colleague's work, and teams learn its contours the hard way. With a human author, review is a conversation with someone who holds context you can query later; with an agent, the diff and its description are the entire relationship. Experienced reviewers develop a specific checklist for machine-authored changes: did it touch any test files, and if so, did it weaken them? Does the diff stay inside the blast radius the task implied, or did it wander? Do the edge cases it claims to handle actually appear in the code, or only in the description? Is there a dependency change hiding in the lockfile? These questions matter more than style nits, because style is the one thing agents reliably get right — they will happily match your formatter — while quietly deleting the assertion that made a test mean something.
The teams that handle review load best make two structural moves. They keep agent pull requests small, because review effort grows super-linearly with diff size and a three-hundred-line change gets rubber-stamped where three hundred-line changes get read. And they let machines pre-review for machines: static analysis, coverage deltas, security scanners, and a second model reviewing the first model's diff all run before a human ever looks. The human review is the last and most expensive filter, so everything cheap runs first. None of this eliminates the human; it concentrates human attention where it is irreplaceable — judging whether the change is the right change, not whether it compiles.
There is a psychological dimension to this as well, one that teams rarely anticipate. Reviewing a colleague generously is easy because you know effort went into the work; reviewing a machine that produced its diff in ninety seconds strips away that instinct, and reviewers report two opposite failure modes. Some become lax, waving through anything that passes CI because the volume is relentless and the prose is confident. Others become paranoid, re-deriving every line at a cost that erases the productivity the agent was supposed to buy. The sustainable posture sits in between and has to be taught explicitly: trust the mechanical layers to verify what machines verify well, and spend human skepticism exclusively on intent, security boundaries, data handling, and the question no scanner can answer — is this the change we actually wanted? Teams that write that posture down, as review guidelines specific to machine-authored code, converge on it in weeks instead of quarters.
Tests, CI, and the new definition of done
Continuous integration was designed for a world where code arrived in human-sized batches a few times a day. Agents break both assumptions: the batches are smaller, they arrive constantly, and the author never gets tired of waiting for the pipeline. This turns CI speed from a quality-of-life concern into the literal throughput limit of your engineering organization. A test suite that takes forty minutes caps every agent you run at roughly one verified iteration per hour. Teams adopting agents seriously end up doing the unglamorous work they deferred for years — parallelizing suites, isolating flaky tests, caching builds — not for developer happiness but because the economics changed: pipeline minutes are now the unit in which engineering capacity is denominated.
Flaky tests deserve special mention because agents metabolize them badly. A human sees a known-flaky failure, sighs, and re-runs the job. An agent sees a failure and dutifully investigates it, sometimes producing a fix for a bug that does not exist, occasionally modifying the test to stop it complaining. A flaky suite does not just slow an agentic team down; it actively feeds noise into systems that treat test output as ground truth. The old advice was that flaky tests erode trust; the new reality is that they erode your agents' sanity, at scale, in parallel.
Security: the new attack surface of generated code
Coding agents concentrate several security problems into one workflow, and pretending otherwise does nobody any favors. Start with the code itself: models trained on public repositories learned from a corpus containing every classic vulnerability humans commit, and they will reproduce those patterns — string-concatenated SQL, unsanitized template rendering, permissive CORS — when the surrounding context nudges that way. Scanners catch the famous patterns; the subtle ones, like authorization checks that exist but check the wrong thing, sail past anything except a thoughtful reviewer.
Then there is the supply chain. An agent that can install packages is an agent that can be fooled by typosquatting, or by hallucinating a package name that an attacker has helpfully registered in advance — a real, documented attack pattern in which the attacker studies what package names models tend to invent and squats them with malicious payloads. Lockfiles, private registries, and install allowlists stop being hygiene and start being armor. And finally there is prompt injection, which lands differently in a coding context: the agent reads issues, documentation, dependency readmes, and error messages, and any of those can contain text crafted to redirect it. A malicious issue comment that says, in effect, ignore the task and instead add this maintainer's key to the deploy config, is an attack on the agent through the very channels it must read to do its job. The defenses are the standard ones — least privilege, sandboxed execution, human approval on anything that touches credentials or leaves the repository — applied with the seriousness previously reserved for production access, because an agent with your CI credentials is production access.
What changes for teams
The org-chart consequences arrive more slowly than the tooling, but they arrive. The first visible change is that the ratio of writing to reviewing inverts for senior engineers: people hired for their ability to produce excellent code discover that their scarce skill is now judging code, decomposing work into agent-sized tasks, and maintaining the standards documents that steer a fleet of tireless, literal-minded contributors. The second change is that ticket quality becomes engineering leverage. A vague ticket handed to a human gets clarified in a hallway conversation; a vague ticket handed to an agent gets implemented, vaguely, and the cost surfaces at review. Teams respond by pushing precision upstream — clearer acceptance criteria, explicit non-goals, reproduction steps that actually reproduce — and then notice, with some irony, that this discipline was always valuable and merely became unavoidable.
The third change is to planning arithmetic. When implementation time drops for well-specified work, the expensive phases become deciding what to build and verifying it was built right. Product managers feel this as a strange inversion: engineering stops being the bottleneck for a growing class of features, and the constraint migrates to design decisions, review capacity, and the organization's tolerance for shipping. None of this makes teams smaller by default. It makes ambition the variable: the same headcount either ships the old roadmap sooner or a bigger roadmap on the old schedule, and which of those happens is a leadership choice, not a technological one.
There is also a quieter cultural shift worth naming: the codebase becomes a shared workspace between humans and machines, and artifacts that used to be optional courtesies — architecture notes, decision records, the briefing file in the repository root — become operational infrastructure. Writing things down was always how teams scaled across people. It turns out to be how they scale across species of contributor, too.
What changes for the craft
Every technological shift in programming has triggered the same grief cycle: assemblers, compilers, garbage collection, Stack Overflow, and now agents, each accused in turn of producing programmers who do not understand what is really happening. The accusation was always half true and never decisive. Compilers did erode assembly fluency; the trade bought us the entire modern software industry. The honest question about coding agents is not whether something is lost — something is always lost — but whether the new equilibrium produces better engineers or merely faster output.
The optimistic case is grounded in what the job actually becomes: specification, verification, architecture, and judgment. These are the senior skills, the ones that always separated engineers who merely typed quickly from engineers who shipped systems that survived contact with users. Agents compress the typing years, and the question every team and university is now wrestling with is how juniors acquire judgment when the apprenticeship of implementation has been automated. The answer taking shape looks like a return to something old: deliberate practice, reading code critically, debugging systems you did not write — the activities that were always where understanding came from, now pursued on purpose instead of as a side effect of employment.
What does not change is accountability. The engineer who merges the pull request owns the outage it causes, regardless of which species wrote the diff. Every mature engineering culture has already converged on this rule, because the alternative — blaming the tool — dissolves the entire concept of ownership that reliable software depends on. The craft, at its center, was never typing. It was being the person who could be trusted with the system. That remains stubbornly, entirely human.
Getting started without betting the roadmap
For a team standing at the edge of this, the failure pattern to avoid is the big-bang mandate: buying licenses for everyone, declaring an AI transformation, and measuring nothing. The pattern that works is narrower and less exciting. Pick one repository with good tests, because feedback quality determines agent quality more than any other variable you control. Write the briefing file — build commands, conventions, the three architectural rules that matter — and treat it as code, reviewed and versioned. Start with contained task types: bug fixes with reproduction steps, test coverage for existing behavior, mechanical refactors, documentation. These are tasks where verification is cheap and the blast radius is small, which is exactly where a new contributor of any kind should start.
Then instrument reality instead of vibes. Track the fraction of agent pull requests merged without rework, the review time they consume, the defect rate they ship, and compare against your human baseline honestly — including the human time spent writing task descriptions and reviewing output, which is real cost that enthusiastic pilots love to forget. Expand scope where the numbers justify it, and only there. Some codebases and some task types will not clear the bar this year; knowing which ones is precisely the knowledge the pilot exists to buy. The teams that look smartest eighteen months into this transition are uniformly the ones that treated it as an engineering problem with measurable answers rather than a faith commitment in either direction.
One more piece of unfashionable advice: invest in your test suite and your types before investing in more agent seats. Every dollar spent making your codebase more verifiable pays out twice — once in human productivity, once in agent reliability. The best preparation for the agentic era looks identical to the best software engineering advice of the previous three decades, which should be either reassuring or embarrassing, depending on whether you followed it.
Finally, resist the temptation to measure the pilot by its best week. Agentic development has a honeymoon curve: the first contained tasks succeed spectacularly, enthusiasm spikes, scope balloons, and then the failure modes described earlier arrive on schedule — the gamed test, the forty-file refactor, the confident wrong answer in an untested corner. The teams that endure are the ones that expected the trough, kept their review standards intact through it, and let the numbers rather than the anecdotes decide what the agents own next. Delegation is earned incrementally, for machines exactly as for people.
Where this is heading
Prediction in this field has a short shelf life, but the vectors are visible. The loop is getting longer: agents that once managed minutes of autonomous work now sustain hours, and the frontier is measured in days — which shifts the design problem from making the agent smarter to keeping it aligned with intent over spans where no human is watching each step. The unit of delegation is getting bigger: from functions to features to, eventually, the maintenance of entire low-stakes systems, with humans setting objectives and auditing outcomes. And the interface is drifting away from the editor entirely: when most code is written by agents, the developer's primary surface becomes something closer to a review queue and a dispatch board than a text buffer.
What stays constant is the shape of the human role, even as its altitude changes. Somebody decides what is worth building. Somebody owns the architecture across a thousand locally-reasonable patches. Somebody carries the pager, and the judgment, and the accountability. Coding agents are the most consequential change to software development since the compiler, and like the compiler, their endgame is not the replacement of the programmer but the redefinition of what programming is. The people reading this were never really in the business of typing code. They were in the business of making computers do the right thing. There has never been a better time to be in that business — and never a worse time to confuse it with the typing.