Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Shift-Left Feedback

Pattern

A reusable solution you can apply to your work.

Move quality checks as close to the point of creation as possible, so agents catch mistakes while they can still fix them cheaply.

“The earlier you find a defect, the cheaper it is to fix.” — Barry Boehm

Also known as: Shift Left, Early Feedback, Fail Fast

Understand This First

  • Feedback Sensor – sensors provide the signals that shift-left moves earlier.
  • Feedforward – feedforward prevents errors before the agent acts; shift-left feedback catches them during or immediately after.
  • Harness (Agentic) – the harness decides when each check runs.

Context

At the agentic level, shift-left feedback sits between feedforward controls and traditional feedback sensors. Feedforward steers the agent before it acts. Feedback sensors check the result afterward. Shift-left feedback occupies the middle ground: checks that run during generation or immediately after each step, before the agent moves on to the next one.

The term “shift left” comes from the traditional software development timeline, drawn left to right: requirements, design, implementation, testing, deployment. Testing sits to the right. Shifting it left means running tests earlier in the process. Barry Boehm’s cost-of-change curve showed that defects found in testing cost 10 to 100 times more to fix than defects found during design. The same economics apply to agentic workflows, but the timeline compresses from months to minutes.

Industry practice is moving beyond “shift left” toward “shift everywhere,” where quality checks run at every stage rather than clustering at one end of the pipeline. Agentic speed makes this practical: when a type checker returns in 200 milliseconds and a focused test suite in two seconds, there’s no reason to wait. Shift-left feedback is the foundation of that broader approach.

Problem

How do you prevent mistakes from compounding across steps when an agent works through a multi-step task?

An agent that writes five files before running any checks accumulates errors. A wrong type in file one leads to compensating hacks in files two through four. When tests finally run, the failure trace points at file four, but the root cause is in file one. The agent spends three correction cycles untangling a problem that a type check after file one would have caught instantly.

The cost is real. Studies of AI-assisted development find that developers spend significantly more time debugging AI-generated code than hand-written code, largely because errors compound undetected across generated files. LangChain improved their coding agent from 52.8% to 66.5% on Terminal Bench 2.0 without changing the model. The technique: forcing agents to verify against original specs after each step rather than self-reviewing at the end. Harness quality mattered more than model quality.

Forces

  • Correction cost grows with distance. The further an error travels from its origin before detection, the more work the agent discards when fixing it. Each subsequent step built on the wrong foundation becomes waste.
  • Context windows are finite. Every correction cycle consumes tokens. An agent that spends half its context on fix-retry loops has less room for the actual task. Catching errors early preserves context for productive work.
  • Not all checks are fast enough. Running a full integration test suite after every line would be thorough but impractical. The checks you shift left must be fast enough to run frequently without blocking progress.
  • Some errors only appear late. Integration failures, performance problems, and semantic mismatches can’t always be detected at the single-file level. Shift-left feedback supplements end-of-task checks; it doesn’t replace them.

Solution

Run the fastest, most informative checks at the earliest possible point in the agent’s workflow. The goal is to shrink the gap between when an error is introduced and when it’s detected.

Arrange your checks in tiers based on speed and scope.

The first tier runs after every file change: type checkers, linters, and formatters. These are computational sensors that return results in milliseconds. They catch structural errors — wrong types, missing imports, style violations — before the agent builds on them. A harness that runs the TypeScript compiler after every file save gives the agent immediate correction signals.

The second tier runs after each logical step: the focused test suite for the module being modified. Not the full suite, which might take minutes, but the subset that exercises the code the agent just touched. This catches behavioral errors (a function that compiles but returns the wrong result) before the agent moves to the next step.

The third tier runs at task boundaries: the full test suite, integration tests, inferential sensors like LLM-as-judge reviews, and comparison against the original specification. These catch problems that span multiple files or require whole-system context. They’re slower and more expensive, so they run less often.

Each tier acts as a filter. Fast checks catch the bulk of errors at near-zero cost. Module-level tests catch behavioral mistakes at moderate cost. End-of-task checks handle the remainder. Without shift-left feedback, all errors hit that final tier, where they’re expensive to diagnose and fix.

Tip

Configure your harness to run the type checker and linter after every file write, not just at the end. In Claude Code, you can use hooks or instruction file rules to enforce this: “After modifying any file, run tsc --noEmit and eslint on the changed files before proceeding.”

How It Plays Out

A backend team asks an agent to add a new API endpoint that reads from two database tables and returns a merged response. Without shift-left feedback, the agent writes the route handler, the database queries, the response mapper, and the tests in sequence, then runs the suite. Three tests fail. The error messages point to the response mapper, but the actual problem is a misnamed column in the first database query. The agent tries to fix the mapper, introduces a new bug, and burns two more cycles before tracing back to the query.

With shift-left feedback, the harness runs the type checker after the agent writes the database query module. The checker flags a type mismatch between the query result and the expected schema. The agent fixes the column name immediately. When it writes the response mapper, the types align. Tests pass on the first run. Same task, same model, four fewer correction cycles.

You notice your agent keeps producing code that compiles but violates the team’s naming conventions. Linting at the end catches these, but by then the agent has used the wrong names throughout the file and has to rename everything. You shift the ESLint check to run after each function definition. The agent catches naming violations one at a time, when renaming costs a single find-and-replace instead of a file-wide refactor.

Consequences

Shift-left feedback reduces the average cost of errors by catching them close to their source. Agents complete tasks in fewer correction cycles, consuming less of their context window on fix-retry loops. The feedback is also more actionable: an error reported on the file you just wrote is easier to diagnose than an error reported three steps later in a file that depends on four others.

The cost is harness complexity. You need to configure multiple tiers of checks, decide which ones run when, and ensure the fast checks are genuinely fast. A “shift-left” linter that takes 30 seconds per invocation slows the agent down more than it helps.

There’s also a risk of over-checking: running too many sensors too often can create noise that obscures real signals. Match check frequency to check speed. Millisecond checks on every change. Second-range checks on every step. Minute-range checks at task boundaries.

  • Depends on: Feedback Sensor – shift-left feedback is about when sensors run, not what they are.
  • Depends on: Feedforward – feedforward prevents errors before generation; shift-left feedback catches them during.
  • Depends on: Harness (Agentic) – the harness schedules and orchestrates check tiers.
  • Enables: Verification Loop – tighter feedback loops make verification faster and cheaper.
  • Enables: Steering Loop – shift-left feedback provides the rapid signals that keep the steering loop responsive.
  • Related: Test – tests are the most common feedback sensors to shift left.
  • Related: Harnessability – codebases with strong typing and fast build tools are easier to shift left on.
  • Related: Context Window – catching errors early preserves context for productive work.

Sources

  • Barry Boehm’s cost-of-change curve, introduced in Software Engineering Economics (1981) and refined in “A Spiral Model of Software Development and Enhancement” (1986), established the empirical finding that defects caught later in the development lifecycle cost exponentially more to fix. This principle is the foundation of shift-left thinking.
  • Larry Smith coined the phrase “shift left” in a 2001 article in Dr. Dobb’s Journal, arguing that testing should begin as early as possible in the development process rather than being treated as a phase that follows implementation.
  • LangChain’s Terminal Bench 2.0 results demonstrated that shifting verification earlier in the agent loop (self-verification against original specs after each step rather than self-review at the end) improved agent performance from 52.8% to 66.5% without changing the model. This is the strongest empirical evidence that shift-left feedback applies to agentic workflows, not just human ones.
  • Birgitta Boeckeler’s “Harness engineering for coding agent users” documented the principle that agents produce better code when feedback signals are available as early as possible, framing shift-left as a harness design concern rather than a process improvement.
  • IBM’s “Beyond Shift Left” analysis introduced the “shift everywhere” framing, arguing that AI agent speed makes quality checks practical at every pipeline stage rather than just early or late. This extends shift-left thinking into continuous, distributed verification.

Further Reading