Fallow: Cleaning Up After AI Coding Agents

AI coding agents ship fast. Sometimes too fast. The problem isn't that Claude or Copilot can't write working code—it's that they optimize for getting something running, not for maintainability six months from now. Dead exports accumulate. Logic gets duplicated across files because the context window doesn't remember what happened three prompts ago. Complexity creeps in because the agent doesn't care about cyclomatic metrics.

Fallow, a new Rust-built code intelligence tool, positions itself as the cleanup crew for AI-generated JavaScript and TypeScript. It combines dead code detection, duplication analysis, complexity scoring, and architectural boundary enforcement into a single command. The pitch: instead of duct-taping together knip, jscpd, and ESLint configs, you run one tool that understands what AI agents typically mess up.

Bart, Fallow's creator, demonstrated it on a Claude-built video processing project. Running fallow --summary immediately flagged 41 files needing refactoring based on maintainability scores calculated from cyclomatic and cognitive complexity. The duplication report showed exact line numbers. The dead code detector found unused exports. All machine-readable, all ready for an agent to consume and fix.

The Actual Workflow

The interesting part isn't running Fallow manually—it's how it integrates with the same AI agents that created the mess. Better Stack's demonstration showed installing Fallow as a "skill" for Claude Code, complete with guardrails and common pitfalls. The prompt: "Study this project to understand how the code works. Then run Fallow to deal with the duplicated code, making sure removing it doesn't break core functionality."

Four minutes later, Claude had fixed three files. Not all the files Fallow flagged—the agent ignored test files, correctly reasoning that some duplication in tests is intentional. It also added a Fallow config to exclude tests from future reports. The resulting PR: 54 lines added, 43 removed, net positive on clarity.

This workflow raises a question the demo doesn't quite address: if you need an AI agent to understand your codebase well enough to safely remove duplication, why did the AI agent create the duplication in the first place? The answer probably has to do with context windows and the economics of token usage. Agents write redundant code because checking if similar logic already exists costs tokens. Cleanup happens in a separate pass when you've explicitly asked for it.

What Fallow Actually Measures

The health scoring system uses established complexity metrics—cyclomatic complexity (how many paths through the code), cognitive complexity (how hard it is to understand), and something called CRAP, which stands for "change risk antipatterns." These get combined into a maintainability index that flags files above certain thresholds.

As Better Stack's narrator notes: "This level of detail is very easy for an agent to follow and know what to fix." That's the key insight. Fallow isn't really built for humans to read and manually refactor. It's built to give AI agents structured, actionable data. Line numbers. Specific metrics. JSON export format.

The tool supports 90+ framework plugins and auto-detects configuration, meaning it works out of the box with most JavaScript projects. It can run as a GitHub Action, integrate with pre-commit hooks, or audit PRs to catch issues before merge. The "baseline" feature lets you grandfather in existing problems and only flag new issues—useful when inheriting a legacy codebase or, more likely, when you've been letting AI agents run wild for months.

The Runtime Intelligence Upsell

All of Fallow's core features are static analysis—examining code without executing it. But there's a paid tier called "runtime intelligence" that uses V8 coverage data to show which functions actually get called in production. This gets merged with the static health reports via a sidecar that can run locally or in deployment.

This matters because static analysis can't distinguish between truly dead code and code that's only called in rare edge cases. Without runtime data, you might delete error handling that only triggers when third-party APIs fail. With it, you know what's genuinely unused versus what's just infrequently used.

The pricing model makes sense—free static analysis to build trust and usage, paid runtime intelligence for teams serious about code health. It's a standard enterprise play. The question is whether enough JavaScript teams care about cleanup tooling to sustain a commercial product, or whether this becomes another open-source passion project that Bart maintains while working somewhere else.

The JavaScript Constraint

Fallow only works with JavaScript and TypeScript. It uses Oxc (the Oxidation Compiler) for parsing, semantic analysis, and module resolution—the same tooling Evan You is building through VoidZero. This makes it fast and thorough for the JS ecosystem, but completely useless for polyglot codebases.

Better Stack's narrator acknowledges this: "The fact that it only supports JavaScript and TypeScript make it less appealing for AI-assisted coders." Then immediately contradicts himself by spending six minutes showing how useful it is. The real constraint isn't technical—other languages have their own static analysis tools. It's that Fallow specifically targets the AI agent workflow, and AI agents are disproportionately writing JavaScript right now.

Claude, Copilot, and other code generation tools work best with high-level languages that don't require manual memory management. JavaScript's massive ecosystem means agents have more training data. The combination makes JS the natural first target for cleanup tooling, even if it limits the addressable market.

Who's Responsible for Code Quality?

The underlying question: should code quality be the agent's job or the developer's? Fallow suggests a third option—make it a separate tool's job, one that both humans and agents can use. This mirrors how we handle other automation. Compilers caught type errors. Linters caught style issues. Now specialized tools catch AI slop.

But there's something uncomfortable about needing a dedicated tool to clean up after another tool's output. It suggests AI agents are productive in the narrow sense (features shipped) while creating technical debt in the broader sense (maintainability degraded). Fallow exists because current AI coding workflows optimize for the wrong things.

The alternative would be agents that understand complexity metrics and avoid duplication in the first place. That's theoretically possible—you could include Fallow reports in the agent's context and prompt it to maintain health scores. But it would make generation slower and more expensive. The cleanup-later approach is probably cheaper and faster, even if it feels backwards.

Fallow works because it accepts the reality of how people actually use AI agents: fast iteration, minimal oversight, fix problems when they become painful. That's not a judgment—it's an observation about what happens when the marginal cost of generating code approaches zero. Someone still has to maintain it. Might as well have tooling for that.

Dev Kapoor covers open source software and developer communities for Buzzrag.