Why We Teach Agentic Coding Backwards

When we designed the agentic coding curriculum for our work with Odevo — moving 100+ developers to agentic workflows across a large engineering organisation — we made one decision early on that shaped how the training ran: we spent significant time on how models fail before teaching what they do well.

Our Head of Product Daniel Jones covered the reasoning at the AI for the Rest of Us meetup in London in February (Meetup #13, February 19, 2026). The full recording of Daniel's talk is here. This post explains it.

Why most training leads with the happy path

The instinct in most training programmes is to open with a compelling demonstration of what the tool can do. Show developers a clean agentic coding session — requirements translated to working code, iterative refinement, a genuinely impressive output. Get them excited. Build the case for adoption.

This makes sense as a positioning move. As a training methodology, it creates a problem.

Developers who've only seen the tool performing well have no framework for what to do when it doesn't. The first time they hit a hallucination — the model generating code that looks right but contains a subtle error — they don't know how to read what happened. Is this a fluke? A sign the tool isn't reliable for this type of work? Something they did wrong? Without context, the instinct is to lose confidence in the tool and fall back on what they know works.

Developers who understand failure modes before they encounter them have a completely different experience of the same moment. They recognise what happened and know what to do next.

Where agentic coding breaks down

In the curriculum we developed, we focused on three categories of failure.

Hallucinations at the specificity sweet spot

Models hallucinate most often when a request lands in a particular zone: similar enough to training data to generate a confident-sounding response, but distinct enough that the response is wrong. Very general requests and very specific ones tend to be handled differently — the dangerous middle ground is where the model has just enough context to be convincingly wrong.

Developers who understand this learn to recognise the conditions that make hallucinations more likely and adjust how they frame requests. Developers who only know that "models sometimes hallucinate" have a harder time working with this in practice.

Context pollution

A long conversation accumulates history. The longer a session runs — and the more the conversation has drifted off-topic, debugging something unrelated or exploring an idea that didn't pan out — the more that accumulated context can start distorting outputs.

Experienced practitioners clear context frequently and deliberately, and keep conversations focused on a single task. For developers encountering this for the first time, the symptom often looks like the model "getting worse" during a session without an obvious reason. Understanding why it happens makes it manageable.

MCP server overload

Running too many active Model Context Protocol (MCP) servers simultaneously degrades model performance in ways that aren't immediately visible. The outputs look plausible. The errors are subtle. This tends to surface in production rather than development, which makes it expensive.

Developers who know about this use MCP servers deliberately — activating what's needed for a specific task rather than running everything available.

What this produced

Across the Odevo engagement, developers who came into training with an understanding of these failure modes were more effective than those who'd only seen the tools working well. The difference showed up most clearly in how they responded when things went wrong — which, at production scale, they do.

Leading with failure modes gives developers calibrated confidence: a realistic model of what the tool does and doesn't do well, grounded in understanding its behaviour rather than its best-case performance. That kind of confidence holds up under real conditions in a way that demo-driven confidence tends not to.

Agent usage across the Odevo engineering organisation increased by 500% over the six-week curriculum. More meaningfully, the developers who went through the training became active practitioners — people who applied the tools to real work, not just people who could demonstrate them in a controlled setting.

What this means for how you design training

Tools that behave non-deterministically — where the same input produces different outputs — require a different approach than tools with predictable behaviour. With deterministic software, leading with the happy path mostly works. With agentic tools, the non-determinism is a feature, and understanding the failure modes is how practitioners develop the judgment to use that feature well.

Training that skips this tends to produce developers who are effective in demonstrations and uncertain in real use. The curriculum we ran at Odevo was built around the alternative.