Warp's self-improving AI agents run on a text file

A self-improving AI agent sounds like it should need a training cluster. It doesn't. In how Warp builds self-improving agents on Claude, the Warp team describes a loop where the thing that improves is a plain file in a git repo, edited by a second agent, merged through normal code review.

That detail is the whole story. Not the model. The storage format.

---

🔍 The architecture is two skills and a pull request

Warp is an AI terminal, founded in 2020, led by CEO Zach Lloyd. Their setup has three moving parts:

1. The inner (base) skill — a file holding domain knowledge and task instructions. For their code-review agent, that's what to look for in a diff.
2. Human feedback — captured where work already happens, mostly as PR comments. Affirming ("this comment was useful") or corrective ("here's why this review was wrong").
3. The outer (improver) skill — a scheduled agent that reads accumulated feedback, compares what the agent suggested against what the human actually said, and opens a PR editing the base skill.

Merge the PR, and the next run of the inner skill inherits the change. That's it. No weights move.

"File-based skills are a way of encoding knowledge for agents without putting that knowledge directly in the prompt." — Zach Lloyd

Every other approach to "make my agent better at my codebase" costs money you probably don't have.

---

💰 Compare the three ways to teach an agent

Approach	What you need	Cost to start	Who can audit the change
Fine-tuning	Labelled dataset, GPU time, eval harness	High, recurring	Nobody — it's in the weights
RAG / vector DB	Embedding pipeline, vector store, retrieval tuning	Moderate, recurring	Sort of — you can inspect chunks
Self-editing skill file	A markdown file and a git repo	Effectively zero	Anyone who can read a diff

The last column is the one I'd point at. When your agent gets worse, a fine-tune gives you nothing to look at. A skill file gives you git log. You can find the commit where the review agent started nagging about something useless, and revert it.

Key takeaway: The most copyable idea here isn't the loop. It's that agent knowledge lives in a reviewable text file, which makes "the AI got worse" a debuggable event instead of a mystery.

---

🌐 Why this lands differently on a small Sri Lankan team

If you run a four-person product team in Colombo, or freelance across three long-running client codebases, the usual advice about improving AI output assumes an ML engineer and a budget you don't have. This technique assumes neither. What it needs:

• A repo you already have
• A place feedback already lands (PR comments, a Slack thread, a feedback.md)
• A scheduled job — a cron entry, a GitHub Action on a timer
• One extra agent run per week

That's the entire bill of materials. If you're wiring the schedule yourself and second-guessing the syntax, our cron expression builder will save you the usual twenty minutes of getting the day-of-week field wrong.

There's a second reason this suits small teams: the feedback is yours. A generic model doesn't know your client insists on Sinhala-safe string handling, or that your team treats any in TypeScript as a blocker rather than a smell. Those are the corrections that pile up in review comments and get forgotten. The improver loop is a way of not forgetting them.

---

⚠️ Where the scale gap actually bites

My honest reservation is about volume, not technique.

Warp's numbers are large: 10M Claude Code sessions run inside Warp to date, 400K+ sessions per week, 40M total agent conversations, 800K monthly developers. At that scale, even a thin feedback rate produces a usable signal every week. (That arithmetic is mine, not theirs — they don't publish a feedback rate.)

Your team does not have that. Four engineers might generate a dozen meaningful corrections a week. Run an improver agent nightly against a dozen data points and it will invent patterns that aren't there, because that's what an agent asked to find gaps does when there are no gaps.

Practical adjustments:

• Run the improver monthly, not nightly, until you have real volume.
• Gate on quantity — skip the run if fewer than N new feedback items landed.
• Never auto-merge. Warp routes changes through normal code review for a reason. A self-editing file with no human gate is a system that drifts somewhere nobody chose.
• Cap the file size. Warp's own advice is to keep skills small with progressive disclosure. An improver agent's natural tendency is to append forever, and a 4,000-line skill file is just an expensive prompt.

Warp's other stated best practices are worth stealing verbatim: write principles over rules, and explain the rationale for each one. A rule says "flag functions over 50 lines." A principle says why, and generalises to the case you didn't anticipate.

---

🛠️ The friction point is the only hard part

Lloyd's sharpest line in the piece is the one that sounds least technical:

"Low friction is what keeps signal flowing."

If leaving feedback means opening a separate tool, nobody does it, and the loop starves. Warp's answer is to capture feedback inside the workflow that already exists — the PR comment thread. Nothing new to open, nothing new to remember.

This is an organisational problem wearing an engineering costume, and the part I'd expect most teams to get wrong. You can build the two-skill architecture in an afternoon. Getting four busy engineers to consistently say why a suggestion was bad, rather than silently ignoring it, takes months.

Warp also runs separate spec-writing, review, and triage agents, each with its own improvement loop. That's a reasonable end state to aim at, but it's the wrong place to start. One agent, one skill file, one feedback channel.

---

💡 What this means for you

The headline reads like a well-funded startup ($73M raised, used at 56% of the Fortune 500) doing something you can't. The mechanism says otherwise.

If you build with AI agents in any form, whether code review, ticket triage or drafting, the move to copy this week is narrow:

1. Take the prompt you keep pasting into your agent and put it in a file in your repo.
2. Add a place for corrections to land, in a tool your team already opens.
3. Once a month, have an agent read the corrections and propose an edit to that file as a PR.
4. Review it like any other PR. Reject freely.

Step 1 is worth doing even if you never build steps 2 to 4. A prompt in a file is versioned, diffable and shared. A prompt in someone's clipboard is none of those.

The real shift here isn't that agents can improve themselves. It's that the improvement got small enough and legible enough to fit in a pull request, which moves the bottleneck from compute to whether your team writes down why something was wrong.