Before the Agent Runs

There's a moment most teams hit a few weeks into serious agentic development. A pull request lands. It looks correct. The agent generated it, the CI is green, and nobody on the team wrote a line of it. The developer who triggered it approves the PR in four minutes.

Three weeks later, something fails in production. It's not a crash; it's a silent wrong answer. The retry logic counted from the wrong baseline. The code was coherent, well-structured, and wrong in a way that only someone who deeply understood the domain would catch.

Nobody caught it, because the developer who approved it never really understood what it was doing. They read it the way you read a form: they checked that the fields were filled in.

This is the failure mode that doesn't show up in demos.

What building code actually taught you

For most of us, understanding and building were the same activity.

You'd write the first version of a function and discover the edge cases in the process. You'd trace through the data model while implementing and realise the schema didn't support what you needed. You'd write the retry loop and notice, mid-implementation, that you hadn't defined what "failure" meant.

This wasn't inefficiency. It was how understanding formed. The act of building was the act of learning. The two were inseparable.

That cognitive model was built through repeated manual construction. It was the byproduct of doing the work. When something failed, you knew where to look. When a PR landed, you had the context to read it critically.

Agents break that loop

When an agent does the implementation, the loop breaks.

The agent doesn't discover edge cases as it builds; it either anticipated them (if you specified them) or it missed them (if you didn't). There's no mid-implementation moment where you pause and catch something unexpected. You see the finished output, not the construction process.

This means the cognitive work has to happen before the agent runs, not during.

You need to understand the problem, the constraints, the failure modes, and the edge cases before you write the prompt. If you don't, you get back code that looks like it handles everything and actually handles a subset. The confident-looking output is the risk.

The shift sounds simple. It isn't. "Understand before you delegate" is a fundamentally different cognitive habit from "understand while you build." Most developers have spent years training the second one. They are not naturally good at the first.

What "think and explain" actually requires

The new skill is specification under uncertainty.

Before the agent runs, you need to articulate: what does done look like? What inputs are out of range? What failure is silent vs. loud? What assumption am I making that might not hold in production?

This is not writing better prompts. This is doing the mental work that the implementation loop used to force you to do automatically. You have to reconstruct the discovery process deliberately, without the act of building to guide you.

The clearest test of this skill is the one we covered in Part 3: a two-sentence requirement, and what you do in the first thirty seconds before writing anything. The developer who names five unstated assumptions first is the developer who can work effectively in an agentic environment. The developer who immediately asks which framework to use is not.

Experienced developers often underestimate how much of this they were getting for free from implementation. Junior developers often don't yet have the domain model that makes it possible at all.

You cannot just adopt the tools and keep the old habits

The failure pattern we see most often: a team adopts an agentic workflow, productivity looks good for the first two weeks, and then the defect rate climbs in ways that are hard to attribute.

The root cause is almost always the same. Developers were given the tools without being given the new cognitive model. They kept using the old one (build, check, ship) except now "build" was replaced by "prompt." The checking step stayed the same length it always was (not very long), but it was now covering far more ground.

The checking step is now the entire job. It just doesn't feel that way yet.

Adopting agentic tools without changing how you think about evaluation is the equivalent of being asked to review architectural drawings but only checking for straight lines. You'll check what you know to check.

A model for building trust incrementally

What actually works is treating agents like a new colleague on a probation period; not a feature to deploy.

When a new developer joins, you don't give them production access on day one. You give them bounded tasks. You review their output closely. Over several weeks, you expand the scope as confidence builds. The trust is task-specific, not general.

The same logic applies to agents, and to yourself learning to work with them.

Start at shadow mode. Run the task manually and with the agent, then compare outputs. Not to accept either; to understand where they diverge and why. This builds calibration before it builds dependency.

Move to bounded delegation with full review. Pick one category of task (test generation, documentation, scaffolding) and review every line of agent output before merge. This creates the habit of critical reading under low-stakes conditions.

Expand to workflow-level trust with approval gates. The agent handles more, but nothing irreversible happens without a human decision point. Deployment, schema migrations, external API calls; these stay gated until you have data on the agent's reliability in your specific context.

Monitor, don't just audit. Once autonomy is higher, the oversight mechanism shifts from reviewing individual PRs to watching system KPIs. Is the defect rate stable? Are the silent failures increasing? This requires knowing what to measure, which requires having built the mental model first.

The teams that rush this process (that go from zero to high autonomy in weeks) are the ones that produce the three-weeks-later production failures.

What atrophies if you don't watch it

Part 2 of this series covered the Anthropic research on this. AI assistants reduced developer competency on the skills that matter most for agentic work: debugging, code reading, conceptual understanding.

The painful irony is that those are exactly the skills you need to supervise agent output. The more you delegate, the worse you get at evaluating what was delegated.

The mitigation is not to avoid the tools. It's to keep the manual muscle active deliberately. Regular no-AI sessions on non-trivial features. Code review habits that require you to explain why the agent's solution works, not just that it does. Asking yourself, before you merge: can I explain the agent's architectural choices to a colleague without looking at the code again?

If you can't, you approved something you didn't understand. That's not a safe state.

Security is not a phase

In traditional development, security often lived at the end; a review before deployment, a penetration test once a year. In agentic development, that model is broken before you even try it.

Agent-generated code moves fast. If you're reviewing security as a gate at the end, you're reviewing a month of generated code in a window that hasn't grown to match. You will miss things.

The practical answer is to embed security scanning before the code ever reaches a PR. Secrets interception on prompts; developers regularly leak credentials in natural-language context without realising it. Supply chain scanning that treats hallucinated dependencies the same as real ones. Pre-commit scanning that applies identical standards to agent-generated and human-written code.

The structural answer is harder. Agents crash mid-operation. When they do, they leave intermediate states; a payment processed but not recorded, a record updated but the cache not cleared. You cannot solve this by telling the agent to be careful. You solve it by designing tools that are idempotent, with transaction coordination that handles partial failures deterministically.

Reliability is an infrastructure problem. It is not a prompting problem.

What this means for you

The Interview Skill Map shows where skills have shifted in the AI era. The ones that rose (specification quality, output evaluation, failure-mode reasoning) are exactly the ones that agentic development demands.

That's not a coincidence. The skills that make you effective as an agentic developer are the same ones that separate strong engineers from weak ones right now. You develop them the same way: by doing the deliberate work of specifying before building, evaluating output for behavioural correctness rather than style, and asking "how does this fail?" before it fails in production.

The next article goes deeper on one part of this: why the way writing code taught you to think is actively the wrong mental model for agentic work, and what to replace it with.