Autodev

Published on Jul 2, 2026 by P. Kerim Friedman · 4 min read

Claude’s new Fable model is so powerful that it was temporarily banned by the Trump administration. Before the ban, however, I had been able to test it for a few days. What I really liked about it was that it could run much more autonomously than previous models. That is, I didn’t need to babysit it through every decision to ensure it wasn’t making some stupid mistake. However, Fable burns through your token allowance much fastter, and Anthropic has also threatened to switch it to entirely metered billing. (Right now you can use half your monthly tokens and then it switches to metered usage.) The solution is to have a less expensive model (Opus or Sonnet) do most of the heavy lifting, with Fable acting as a manager, checking the other model’s work.

During the brief peiod of access before Fable was banned, I created a skill to do this, called “autodev.” Now that Fable is back I can finally share it.

How it works

Autodev splits the work across two different models. Sonnet or Opus does the actual coding, runs the tests, and narrates progress as it goes, but Fable makes every decision that matters: whether a plan is good enough to build, whether a review finding is real or noise, whether the finished work actually matches the task. To save on tokens, Fable is only ever sent a small distilled summary (the plan, the findings table, or a diff stat and test output), never the full conversation.

One Skill, Multiple Workflows

Autodev sizes its own process to the task:

Small (a one-line fix, low risk): worktree, implement, test, present.
Medium (multiple files, or a real design choice): adds a written plan before coding, and a code review after tests pass.
Large (architecture change, unfamiliar code): adds a scouting pass before the plan, plus a second independent reviewer.

The steps, in order

Worktree. Sets up the isolated copy of the repo.
Scout (large tasks only). A subagent reads the relevant code and produces a short brief: files, patterns, constraints.
Plan (medium and large). A subagent drafts a plan, including the exact commands to test it and what a passing result should look like. The plan must be approved before any code is written.
Implement. A subagent writes the code in the worktree, following the plan (or the task description directly, for small tasks). It never commits anything.
Test. The actual test commands run directly, not by asking a subagent whether tests passed. Only the exit code counts. A failure gets handed to a subagent to fix, and it tries again, up to three rounds before stopping to reconsider rather than grinding.
Review (medium and large). A subagent reads the full diff and lists any problems it finds. Findings get sorted into real issues versus noise, real ones get fixed, and tests run again.
Acceptance. A final check compares the diff and test results against the original task to confirm the work actually matches what was asked for.
Present. A short handoff: what changed, where the worktree is, exactly how to test it yourself, and a one-line status on tests and any decisions made along the way. Then it waits for approval, feedback, or rejection.

Worktrees for Safety

Autodev never touches your actual project files directly. It creates an isolated copy of your repository, a git “worktree,” and does all its work there. Nothing merges into your checkout until you approve it at the end.

After you approve

Approval hands off to a separate wrap-up step: tests run one more time, then lint, then a commit inside the worktree, then a merge back into your actual branch, then the worktree and its branch get deleted. Rejecting deletes nothing. You’re given the commands to inspect or discard the work yourself.

The Skill Files

These skill files are designed for my own workflow. For instance, they make use of my Obsidian Wiki. So anyone else trying to implement it will have to make modifications to suit their own setup.

The skill is two files: autodev, which runs the whole process, and ad-wrap-up, which closes out an approved run (merge, cleanup). Both are plain markdown, no code to install. Get them from this gist:

Create two folders: ~/.claude/skills/autodev/ and ~/.claude/skills/ad-wrap-up/.
Save autodev-SKILL.md from the gist as SKILL.md inside the first folder, and ad-wrap-up-SKILL.md as SKILL.md inside the second.
Start a new Claude Code session. Skills are picked up automatically, there’s no separate registration step.
Describe a task and say “autodev this” or “run autodev.” Approving the presented work at the end triggers ad-wrap-up automatically.