What agentic software development actually is
The phrase gets used loosely, so let me be precise about what I mean by it. Agentic software development is the practice of giving an AI a goal and letting it execute multiple steps autonomously against your real codebase — read the relevant files, plan against them, edit a dozen files coherently in one pass, run the tests, and present a finished end state — rather than asking it for a snippet and pasting the snippet in yourself. The defining shift is autonomous multi-step execution. It is the difference between an assistant that answers questions about your code and a worker that changes your code.
That distinction is not academic. I had filesystem-aware AI editing tools in late 2024 and they did not change my practice much. What changed it, in August 2025, was the first tool that could take a goal, decompose it, and ship a structural deliverable I had not myself written. The capability that matters is not access to your files. It is the ability to carry a task across a dozen edits without losing the thread. Once an agent can do that, your job stops being authorship and starts being direction — and almost everything hard about the practice follows from that one change.
I think about my own arc through this in three stages, and I have written the long version with the charts on /practice. AI as an advisor: an expert inside my IDE I consulted constantly and never let touch the code. AI as a collaborator: it began authoring whole features that I reviewed line by line. AI as a workforce: orchestrated agents executing at a volume I govern rather than read. Agentic development proper begins at the second stage and only becomes sustainable at the third. The rest of this guide is about how to get to the third stage without the wheels coming off — because when I first tried, they nearly did.
Why conversation alone has a hard ceiling
The default way everyone works with a coding agent is conversational. You describe what you want. The agent does most of it and gets a piece wrong. You explain the piece it got wrong. It fixes that and breaks something adjacent. You explain again. Anyone who has spent real hours with these tools knows this loop, and it genuinely works — up to a point. The point where it stops working is the point where the rule you keep having to restate is unusual relative to the entire corpus of public code the model was trained on. When your codebase enforces a convention almost no other codebase in the world enforces, no amount of conversation makes it stick. The model regresses to the mean of everything it has ever seen, and the mean does not include your rule.
I learned this the expensive way. My engine has a rule that systems must be stateless across simulation frames — a determinism requirement with a long lineage, the same discipline I learned writing lockstep RTS networking in 2003. Within a frame, caching component data in a field is fine and useful. Across frames, it is a desync waiting to happen. I had that rule written down everywhere: context files, conventions docs, the subagents I run, the skills they load. And it still leaked into real code on a semi-regular basis, from agents and, honestly, from me. It leaked because through the lens of all the code in the world, a field that holds state between frames is the most normal thing imaginable. Nearly every class in nearly every codebase does it. The rule asks the model to suppress its single strongest prior about how objects work on the basis of a paragraph it read twenty thousand tokens ago. Prose was never going to win that fight.
This is the first thing I would tell anyone adopting agents seriously: context is necessary, but it degrades over a long session, it competes with ten thousand training examples pulling the other way, and it can always, in principle, be missed. I have made the full argument that you should stop only talking to your agents, and the short version is that conversation is a probabilistic lever on a probabilistic system. There is a more durable lever available, and reaching for it is what separates a practice that scales from one that plateaus.
Constraining the agent with the compiler and the environment
The more durable lever is to change the environment the agent operates in so that the wrong answer is no longer reachable. In a C# codebase that lever has a specific name. It is the compiler. Roslyn — the compiler-as-a-platform — lets you run your own analysis as part of every build, which means you can take a rule that lives only in prose and make it a property of the build itself.
I now ship a set of compile-time diagnostics with my engine, sixteen of them, each one taking a failure mode that used to surface at runtime — or worse, in a multiplayer desync three weeks later — and moving it to the moment of compilation. A component that exceeds the engine's byte ceiling is a build error, not a runtime crash during buffer allocation. A system that writes to a component it never declared access to is caught the instant you type it, not deep inside query construction at runtime. The stateless-across-frames rule that prose could never enforce became a second analyzer, and the leak stopped. Not mostly stopped — stopped. Because now, on every violation, the agent receives the rule restated at full strength at precisely the moment it matters, in a channel it cannot ignore.
The trick that makes this possible is worth naming, because it generalizes. My engine was historically authored through a GUI tool that wrote the runtime code — a pipeline built for a human carrying a gameplay concept across each tool boundary. When I pointed an agent at that pipeline, the work fell apart; the agent could not coherently shuttle between a proprietary editor and the IDE, because it had been trained on essentially zero repositories that work that way. So I inverted the pipeline. Instead of forcing the agent to drive the editor, I let it do the single most in-distribution thing a coding model can do — write a class and put an attribute on it — and a build-time pass reconstructs the data layer from those attributes. The asset database flipped from source of truth to generated artifact; code became the source of truth. Over a hundred hand-coded boilerplate files retired in one pass, and the migration is what gave the compiler something to reason about in the first place.
The principle is portable beyond C# and beyond games. When an agent hits friction in a workflow, the highest-leverage move is rarely to teach it the workflow with a better prompt. It is to ask whether the workflow was built for the right user, and to rebuild it for the new one — then to encode your hard invariants wherever your toolchain can refuse to advance until they are satisfied. A linter, a type system, a schema validator, a pre-commit hook: each is a place to put a rule that an agent cannot be talked out of. The reframe is that the most valuable thing you can do for an agent's reliability is often not to write a better prompt but to build a better failure.
Codebase-aware agents and the context you feed them
None of this means context is worthless. The opposite: getting the context right is the whole game in the collaborator stage, and the discipline carries forward. When Claude Code first arrived in my practice, the first 48 hours did not go smoothly — a code-generation bug quietly stripped most of the components I asked it to create down to stubs. We worked through it across one long day, and the pattern that emerged is the one I still use. Treat the agent like a senior engineer who just joined the team. Give it documentation of the conventions, the constraints, the patterns, the antipatterns. When it gets something wrong, iterate on the docs the way you would iterate on onboarding docs after a confusing first week. Every mistake the agent made in those early sessions became a paragraph in a context document that prevented the same mistake from recurring.
The docs are the leverage point; the agent is the thing that exposes the gaps in them. And there is a quiet bonus the industry took another six months to start saying out loud: the docs you write to make an agent reliable are genuinely good documentation for human collaborators too, because the discipline of writing them honestly forces your conventions into a form anyone can read. Deciding what context the agent sees, before it can see anything on its own, is a skill. It later acquired a name — context engineering — but I was doing it deliberately, attaching specific files to specific questions, well before I had a word for it. A codebase-aware agent is only as good as the slice of the codebase you have made legible to it.
Why validation is the real bottleneck — and the fix
Here is the part that surprised me. Once the context discipline held, the share of code I let an agent author went from zero to the majority in a single month, and my measurable monthly output went up roughly fivefold and stayed there. But I had not gotten faster at typing or thinking. I was the same engineer. What had changed was the bottleneck: I was no longer rate-limited by what I could write. I was rate-limited by what I could review. That single sentence shaped everything that came after.
Then March 2026 nearly broke the practice. The orchestration was producing far more code than I could review. Hallucinations slipped through. Subtle regressions accumulated. Architectural drift crept in at the edges. The code velocity kept climbing while the business value created started to fall — I had raised the ceiling on what I could attempt without building the matching floor on what I let through. A morning of agent output runs to tens of thousands of lines. You can read a junior engineer's daily output; you cannot read an agent's. If you try, you are the bottleneck, and you are looking at the wrong things — surface grammar instead of structural integrity.
The fix was not to slow down so I could read every diff. It was to stop reading the diffs and start reading the proof. I moved my attention up a layer, from the code to the systems that grade the code. Comprehensive automated testing went in everywhere. Warnings became errors. Aggressive static analysis. A CI harness with as much coverage as practical, enforced with a hard fail gate. Cross-vendor audits where one model checks another's work. And two in-house agents — a verifier and an integration-auditor — that grade every task against its acceptance criteria before it reaches me. Most of these systems have been essential for teams operating at scale for years. What is new is that AI made them practical to build and maintain as a solo operator: the infrastructure that used to cost a quarter now costs an afternoon, so the gate is no longer effort, it is whether you have the reflex.
The honest measure of how far this goes: when I open-sourced wood-fired-tasks, I had pre-read about 3% of the AI-written files in it, and none of the security-critical ones. What I read was the harness that proves the code works — the tests, not the implementation. That sounds reckless stated baldly, so let me defend it precisely in the next section, because the defense is the method.
Validation as a system, not a feeling
There is a recursion in this practice that took me a while to notice. The validation infrastructure that grades the AI-written code is itself AI-written code I never typed by hand. Every CI workflow I own was written by an agent following a specification I wrote in plain English; I genuinely no longer know how to configure a modern CI pipeline by hand, and it would be dishonest to imply I do. If trust were the right frame, that would be two leaps of faith stacked on each other.
The thing that makes it tractable is that the layers grade each other. Tests describe behavior. Behavior is independent fact. A test failure is true regardless of who wrote either side of it — the code or the test. The CI runs the tests. A cross-vendor audit grades the CI. I read the verdicts, not the diffs. Some of the checking does not even wait for a test run: the hard rules — never amend a commit, never let a secret into a push, never touch a protected branch — live in hooks, small deterministic scripts that intercept an agent's action before it executes and refuse anything policy forbids. A rule written in prose is a request, and a request competes with everything in the model's training pulling the other way. A hook cannot be talked out of its job. It is the same move as the compiler diagnostic, one layer up the stack.
This is the core claim of the whole practice, so I will state it plainly: trust is a feeling, and validation engineering is a system. The first scales with attention; the second scales with infrastructure. Over the course of two years I migrated almost entirely from the first to the second. The two standard responses to AI output are both losing positions — trust less, which leaves the velocity on the table, or trust more, which is hope wearing a process costume. The third option is overlapping systems that do not require trust at all: write the test that grades the behavior, wire the hook that refuses the forbidden action, run the verifier that grades the acceptance criterion, configure the CI that grades the integration, and add a second vendor's audit to grade the first's. Arrange them so that no single layer, and no single person, has to be right.
The human's changed role: from author to governor
For twenty-five years my job was to read code. I read what other engineers wrote, what I had written, what I was about to land. Code review was the surface where the human caught what would otherwise ship wrong. Agentic development does not eliminate that responsibility — it relocates it. The artifact I now validate is the validation infrastructure itself: the test harness that proves the code works, the CI that runs the harness, the static-analysis rules and cross-vendor audits that grade each other, the telemetry that captures every model call so I can ask what every agent actually did against my repository.
What stays mine, and will stay mine, is the work that sits above the code. The architectural decisions. The design judgement. The specifications, written in plain English, that the agents execute against. And the review of the validators themselves — because the open question I am always instrumenting is whether my graders are catching the failures I would have caught by reading. That is a question you answer the way you answer every question about a system at scale: you add the telemetry, watch it for a few weeks, and adjust. I ran exactly that loop for fifteen years tuning game mechanics from player telemetry. The method transfers cleanly to agents; only the thing under observation changed.
There is also a hard limit on the role, and I want to state it because it is the part the hype skips. AI can write the code. It cannot ship the game. The judgement about what is worth building, the taste about how it should feel, the accountability when it goes wrong — none of that delegates. And the agent's reach is not uniform across all software work. From two years of first-hand evidence, AI is markedly stronger on server, DevOps, and SaaS work than on game development proper, because the public training corpus skews heavily toward backend code while game tooling is graphical, the engines are mostly proprietary, and the patterns the industry actually uses rarely reach public repositories. Where the work is proprietary game-tech, the judgement stays mine — both because I do not need the help and because the help is not there. A one-size adoption policy under-invests where the upside is largest and over-invests where the friction is structural. Adoption has to be surface-specific.
Orchestrating multiple agents at scale
The final stage is fan-out. A single agent working a single task is the unit; orchestration is what you build when you want many of those units running at once without stepping on each other. My answer is a task graph: one shared backlog that any number of agents can drain in parallel, where every closed task is graded by an independent agent before the close sticks. One subagent does the work, another grades it against the acceptance criteria, a third checks integration. I read the verdicts.
I measured this against the alternative rather than assuming it. My big batches used to run on a third-party orchestration framework I used daily and modified heavily but did not write. I had a theory my own task system could do the same job, so I instrumented both. Per token generated they cost about the same; structurally they were not close. A long-lived single thread re-reads an enormous accumulated context across days of phase-gated execution. A task-DAG run fans the same work into short-lived parallel subagents, each graded independently — a scoped batch lands five to twelve times cheaper and an order of magnitude faster, ten-plus verified tasks an hour instead of a phase a day. The verification being built into the unit of work is exactly why speed and reliability rise together instead of trading off.
Orchestration also unlocks economics that single-agent work cannot. Once each task is independently graded, you can route different models to different roles in the pipeline — a frontier model planning and grading, cheaper models doing the bulk execution. Workers burn the overwhelming majority of the tokens; verification is a sliver. Putting frontier-quality grading on top of mid-tier execution can cost roughly a third of running your most expensive model everywhere, with every task still passing its verifier on the first try. The grading does not just protect quality — it is what makes the cheap worker safe, and therefore what unlocks the savings. That is the whole practice compounded: the discipline that makes the output trustworthy is the same discipline that makes it affordable at scale.
Where to start
If you are adopting agents seriously, the order that worked for me is this. First, get the context discipline right — treat the agent as a new senior hire and write the onboarding docs it exposes the need for. Second, find the rules that keep leaking despite the docs, the ones unusual relative to the rest of the world's code, and move them out of prose into something the toolchain can refuse to compile or commit. Third, build the validation layer before you scale the volume, not after — the floor before the ceiling. Only then turn up the fan-out, because orchestration multiplies whatever discipline you already have, including the absence of it.
I document this practice as I build it, in essays that go deeper than any single guide can. The three that anchor this one: the full two-year arc from advisor to workforce, the case for constraining agents with the compiler instead of conversation, and how I replaced line-by-line review with overlapping systems that grade each other. The studios that get the most from me pull me in before the AI mess compounds, not after. If your team is somewhere on this arc and the next stage is the one that worries you, that is exactly the conversation I want to have.