Warp's Self-Improving Claude Agents: The Feedback Loop Architecture

The Raw Play: What Warp Actually Built

Warp, the terminal reimagined as a modern Rust app, faced a classic AI engineering problem: getting an LLM to consistently produce correct, idiomatic Rust code for terminal operations. One-shot prompting wasn't cutting it. So their team built a system where Claude doesn't just generate code—it learns from its own failures and gets better over successive runs.

The core insight is dead simple. Instead of writing ever-more-elaborate system prompts by hand, Warp built a pipeline where:

1. Claude generates code for a given terminal task.
2. An automated test harness scores the output against a suite of unit and integration tests.
3. Failures are automatically converted into few-shot examples that get injected back into the prompt for the next attempt.
4. The loop repeats until the code passes or a budget is exhausted.

This isn't fine-tuning. It's not reinforcement learning from human feedback. It's a purely prompt-engineering approach that treats the conversation history as a self-curating dataset of what works and what doesn't. The Warp team detailed this architecture on Anthropic's blog, and the results were striking: agents that started with mediocre pass rates climbed to near-perfect performance after a handful of feedback cycles.

The Feedback Loop Architecture in Detail

Let's break down the components. This is a system of four cooperating pieces, and understanding each one is the difference between cargo-culting the idea and actually shipping it.

The Test Harness Is the Real Secret

The test harness isn't an afterthought—it's the engine of the whole system. Warp wrote a battery of tests that exercise the generated code against real terminal scenarios: Does the output parse correctly? Does it handle edge cases like empty input or Unicode characters? Does it respect the terminal's state machine invariants?

Each test returns a structured result: pass/fail, the specific assertion that broke, and—critically—the expected vs. actual output. This structured failure data is what makes the feedback loop work. Without it, you're just telling Claude "try again," which is about as useful as a compiler that only says "error."

The Failure-to-Example Pipeline

When a test fails, the system doesn't just log it and move on. It programmatically constructs a new few-shot example with three parts:

1. The original prompt (what we asked Claude to do).
2. The incorrect output (what Claude actually produced).
3. The corrected output (what the test expected, or a human-verified fix).

This triplet gets stored in a vector database or simple key-value store, indexed by the error signature. On subsequent runs, the prompt constructor retrieves the most relevant failure examples and prepends them to the system prompt as "Here's what went wrong last time, and here's the fix."

The Prompt Constructor: Dynamic Assembly

The prompt constructor is where everything comes together. It takes the raw task, pulls relevant few-shot examples from the store (both positive and negative), and assembles a prompt that gives Claude the full context of what's been tried and what's worked. The key design choice here is recency weighting: examples from the most recent failures get higher priority, because they're more likely to be relevant to the current state of the agent's output distribution.

Why This Matters for Engineers and FDEs

If you're shipping AI features into production—especially as a Forward Deployed Engineer bridging the gap between model capabilities and customer reality—this pattern is gold. Here's why.

It Solves the "Last Mile" Problem

General-purpose models are great at the 80% case. It's the last 20%—the domain-specific edge cases, the quirky API contracts, the undocumented behavior—that kills production deployments. Warp's feedback loop directly attacks this: every customer-reported bug or integration test failure becomes training data for the next invocation. The system gets narrower and sharper over time, not broader and more generic.

It's Auditable and Explainable

When a customer asks "why did the agent do that?" you can point to the exact few-shot examples that influenced the output. This is a massive advantage over fine-tuning, which bakes knowledge into opaque weights. For enterprise deployments where compliance and explainability matter, the feedback-loop approach leaves a clear paper trail. This connects directly to the kind of customer health monitoring we discuss in Reading the Tea Leaves: Customer Health Signals an FDE Monitors During an AI Rollout.

It Aligns With How FDEs Actually Work

Forward Deployed Engineers thrive on tight feedback loops with customers: ship, observe, adapt, repeat. The Warp architecture formalizes this pattern for AI agents. Instead of throwing the model over the wall and hoping, you build a system that gets better every time a customer hits an edge case. This is exactly the kind of thinking that makes FDEs indispensable in how AI-native startups use Forward Deployed Engineers to win enterprise deals.

It's Cheaper Than Fine-Tuning

Fine-tuning requires curated datasets, GPU hours, and model versioning headaches. The feedback-loop approach uses the same base model API and only increases prompt length (and thus token cost) as the example store grows. For many use cases, the total cost of ownership is lower, and the iteration speed is dramatically faster—you can add a new failure example and see the improvement on the very next API call.

How to Prototype a Self-Improving Loop Today

You don't need Warp's infrastructure to try this. Here's a minimal viable feedback loop you can build in an afternoon.

Step 1: Pick a Narrow, Testable Task

Don't start with "build a full-stack app." Start with something where correctness is binary and easy to verify. Good candidates:

• Generate a SQL query from a natural language question (test: does it execute and return the right rows?)
• Write a regex that matches a given set of strings and rejects another set (test: exact match on test cases)
• Format a JSON response to match a specific schema (test: jsonschema.validate())

Step 2: Build a Minimal Test Harness

Write a Python script that takes a string (the model's output) and returns a structured result:

import json

def evaluate(generated_code: str, test_cases: list[dict]) -> dict:
    results = []
    for case in test_cases:
        try:
            # Execute the generated code in a sandbox
            actual = execute_in_sandbox(generated_code, case["input"])
            passed = (actual == case["expected"])
            results.append({
                "input": case["input"],
                "expected": case["expected"],
                "actual": actual,
                "passed": passed
            })
        except Exception as e:
            results.append({
                "input": case["input"],
                "expected": case["expected"],
                "actual": str(e),
                "passed": False
            })
    
    return {
        "overall_pass": all(r["passed"] for r in results),
        "failures": [r for r in results if not r["passed"]]
    }

Step 3: Implement the Feedback Loop

import anthropic

client = anthropic.Anthropic()
few_shot_examples = []  # Will grow over time
MAX_RETRIES = 5

def build_prompt(task: str, examples: list[dict]) -> str:
    example_text = ""
    for ex in examples[-3:]:  # Last 3 most relevant
        example_text += f"\nBad output: {ex['bad']}\nGood output: {ex['good']}\n"
    
    return f"""You are a precise code generator.
Here are examples of mistakes to avoid:
{example_text}

Task: {task}

Return ONLY the code, no explanation."""

for attempt in range(MAX_RETRIES):
    prompt = build_prompt(task, few_shot_examples)
    
    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}]
    )
    
    generated = response.content[0].text
    result = evaluate(generated, test_cases)
    
    if result["overall_pass"]:
        print(f"Passed on attempt {attempt + 1}")
        break
    
    # Convert failures to few-shot examples
    for failure in result["failures"]:
        few_shot_examples.append({
            "bad": failure["actual"],
            "good": failure["expected"]
        })

Step 4: Watch It Improve

Run this on a batch of tasks and track the pass rate per attempt. You'll typically see a sharp improvement curve—50-60% on attempt one, climbing to 85-95% by attempt three or four. The examples that accumulate are worth their weight in gold; they're a structured record of exactly what your model gets wrong on your specific domain.

For a more polished version of this pattern applied to content generation, check out our guide on building a Twitter thread writer that drafts from rough outlines using Groq's Llama 3. The same feedback-loop principles apply: generate, evaluate against criteria, feed failures back as examples.

A Balanced Look: Strengths, Limits, and Failure Modes

This architecture is powerful, but it's not magic. Let's be honest about where it shines and where it breaks.

Strengths

• Zero new infrastructure: Works with any LLM API. No training pipelines, no model weights to manage.
• Fast iteration: Adding a new failure example improves the very next call.
• Domain-specific precision: The system specializes to your exact test cases, not a general distribution.
• Auditability: Every example in the prompt is inspectable and explainable.

Limits and Failure Modes

• Prompt length explosion: If your failure store grows unbounded, you'll blow through context windows and token budgets. You need a pruning strategy—recency, relevance scoring, or hard caps.
• Overfitting to tests: The agent can learn to game your specific test cases without generalizing. This is the same problem as teaching to the test in education. Mitigate by rotating test cases and including held-out evaluation sets.
• Garbage in, garbage out amplified: If your test harness has bugs or your "correct" examples are wrong, the feedback loop will systematically steer the model toward incorrect behavior. Validate your test suite independently.
• No transfer learning: Unlike fine-tuning, the improvements don't carry over to new model instances or different tasks. Every new session starts from scratch (unless you persist and share the example store).
• Cost per call increases: Each retry burns tokens, and the prompt grows with each failure example. Budget for 2-4x the token cost of a single-shot approach.

When to Use This vs. Alternatives

For an architectural perspective on structuring these kinds of agent systems, our piece on Domain-Driven Agents: Bounded Contexts for Reliable AI Workflows provides a complementary framework. The feedback loop is one mechanism within a bounded context; domain-driven design tells you where to put the boundaries.

FAQ

Does this require Claude specifically?

No. The architecture is model-agnostic. Warp used Claude because of its strong code generation and instruction-following, but the same loop works with GPT-4, Gemini, or open models. The key requirement is that the model can reliably follow the "here's what went wrong, here's the fix" pattern in prompts.

How many failure examples before I see diminishing returns?

Anecdotally, 5-15 well-chosen examples cover most common failure modes. Beyond that, you're often adding noise rather than signal. Focus on diversity of failures, not volume.

Can I share the example store across users or sessions?

Yes, and you should. A shared, curated example store is the system's institutional memory. But be careful about leaking sensitive data between customers—scrub examples of PII and proprietary logic before sharing.

What if my task can't be automatically tested?

Then this architecture doesn't directly apply. You can approximate it with LLM-as-judge evaluation (have another model score the output), but that introduces its own biases and failure modes. The power of Warp's approach comes from deterministic, automated testing.

How does this relate to the Forward Deployed Engineer role?

This is peak FDE territory. Building feedback loops between AI systems and real-world usage data is exactly the kind of work that bridges engineering and customer success. If this pattern excites you, understanding the FDE interview process at companies like Cohere and Anthropic will give you a sense of how these organizations evaluate this skillset.

Won't the prompt eventually exceed the context window?

Yes, if unmanaged. Implement a retention policy: keep only the N most recent failures, or use embedding similarity to retrieve only the most relevant examples for each new task. Think of it as a cache with an eviction policy, not an append-only log.