AI Agents Are Repealing the 'Never Rewrite' Rule

Coding agents are overturning Joel Spolsky's 25-year-old 'never rewrite' rule, as regenerating code becomes cheaper than reviewing it, according to an essay by Seoul-based developer Hichoi-Dev. The new discipline, 'project distillation,' focuses on preserving only contracts, domain knowledge, and external interfaces while deliberately discarding implementation details, with context files like AGENTS.md, used by over 60,000 open-source projects, now serving as persistence layers for assumptions that can regenerate legacy code.

AI https://sourcefeed.dev/c/ai Article AI Agents Are Repealing the 'Never Rewrite' Rule Code generation is cheap now; the scarce skill is deciding which project knowledge deserves to survive the rewrite. Priya Nair https://sourcefeed.dev/u/priya nair For 25 years, one piece of engineering folklore has held up better than almost any other: Joel Spolsky's "Things You Should Never Do" https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ , the essay that branded the ground-up rewrite as the single worst strategic mistake a software company can make. The logic was economic. Old code encodes thousands of hard-won bug fixes, and re-earning that knowledge by hand costs years. So we built an entire discipline — strangler figs https://martinfowler.com/bliki/StranglerFigApplication.html , branch-by-abstraction, compatibility shims — around never having to start over. Coding agents just knocked out the load-bearing assumption. When an agent can regenerate a 40-file subsystem faster than you can review it, the cost of writing the new system stops being the reason to avoid a rewrite. A recent essay by Seoul-based developer Hichoi-Dev gives the emerging replacement discipline a name worth stealing: project distillation — extracting only the knowledge that deserves to survive into the next version of a project, and deliberately destroying the rest. That framing is more useful than it sounds, because it names the failure mode most teams haven't hit yet but will. Legacy can now be regenerated Here's the counterintuitive part. In the pre-agent world, deleting code killed it. In an agent-driven workflow, your project's assumptions live in more places than the repo: in AGENTS.md and CLAUDE.md files, in specs and ADRs, in the agent's session memory, in the old code the agent reads for "context." Delete the implementation, keep the context, and the agent will cheerfully rebuild the architecture you were trying to escape. The legacy isn't copied — it's regenerated , like a weed growing back from the root. This is a genuinely new problem. Those context artifacts barely existed three years ago; now they're standardized infrastructure. AGENTS.md https://agents.md is used by over 60,000 open-source projects and is stewarded by the Agentic AI Foundation under the Linux Foundation, with support across Codex, Copilot, Cursor, Jules, Zed, and a couple dozen other tools. Claude Code https://code.claude.com loads CLAUDE.md automatically at every session. GitHub's Spec Kit https://github.com/github/spec-kit pushes teams to make versioned specs — not code — the source of truth, feeding 30-plus agents from the same documents. All of that is good practice, and SourceFeed has generally argued for it. But every one of those artifacts is a persistence layer for assumptions. Teams have spent two years learning to accumulate context. Almost nobody has a story for retiring it. The essay calls the resulting drag "epistemic debt": the ongoing cost of figuring out which of your own documents are still true. Anyone who has watched an agent confidently follow a six-month-old ADR into a wall knows this isn't theoretical. What actually survives a rewrite The practical core of distillation is deciding what goes in the seed of the next version. The answer is narrower than most teams' instincts: Contracts and invariants , not implementations. "Replaying the same payment request must produce exactly one charge" survives; "PaymentService calls PaymentRepository once" does not. If your test suite is full of the second kind, it's an anchor, not an asset — it will drag the old object graph into the new system. Domain knowledge and constraints : rate limits you learned the hard way, the regulatory rule behind that weird branch, the vendor API's undocumented behavior. This is the stuff Spolsky was right about, and it's the part that still can't be regenerated. External interfaces : wire formats, schemas, public API shapes — anything a consumer depends on. Everything else — internal structure, module boundaries, the accumulated CLAUDE.md folklore about how to navigate the old codebase — gets deliberately left behind. Then you enforce the boundary: fresh repo or fresh directory, fresh agent sessions with memory cleared, and the old codebase excluded from the agent's reachable context. Have the agent read the seed and explain it back before it writes a line. That last step sounds like ritual; it's actually a cheap check that your distilled spec is self-sufficient, because if the agent can't reconstruct the intent, neither will your successors. If you're running long-lived agent memory — Claude Code's auto-memory, Copilot's repo instructions, a vector store of past sessions — treat a major version boundary as a memory boundary too. Stale agent memory is the new stale wiki, except it acts autonomously. The honest trade-offs Is this a real shift or a rebrand of "write good docs"? Mostly real, with two caveats. First, the cost didn't disappear; it moved. Agents made code generation cheap, which makes verification the bottleneck. A regenerated system is only as trustworthy as your contract-level test suite, and distilling that suite — separating true invariants from incidental implementation detail — is slow, senior-engineer work. Teams that hear "rewrites are cheap now" and skip this step will rediscover exactly why Spolsky's essay survived 25 years. The Netscape failure mode wasn't typing speed; it was losing knowledge nobody had written down. Distillation only works if you actually do the extraction. Second, the strangler fig isn't dead. When you can't fully specify the contract — sprawling systems whose real behavior is only defined by production traffic — incremental migration with the old system as the oracle is still the right call, and it's also getting cheaper: Spotify has publicly discussed Honk, its agent-driven migration tooling, drastically compressing cross-codebase migration timelines. Distillation is for the narrower, more painful case where the foundational architecture itself is the problem and compatibility layers would just embalm it. The meta-point is the one worth internalizing. In 2024 the scarce skill was prompting. In 2025 it was context engineering — feeding agents the right knowledge. The next turn of the wheel is knowledge lifecycle management: versioning your context, testing it for staleness, and periodically boiling it down to what's still true. Your AGENTS.md deserves the same hygiene as your dependencies. Nobody's built the npm audit for stale context yet — someone should — but until then, distillation is a manual skill, and the teams that practice it will be the ones whose agents build the system they meant, not the one they used to have. Sources & further reading - Distillation Is a New Engineering Skill - Project Distillation in the Age of AI Agents https://dev.to/casamia918/distillation-is-a-new-engineering-skill-project-distillation-in-the-age-of-ai-agents-3o44 — dev.to - AGENTS.md - a simple, open format for guiding coding agents https://agents.md — agents.md - Spec-driven development with AI: Get started with a new open source toolkit https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/ — github.blog - Things You Should Never Do, Part I https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ — joelonsoftware.com - Strangler Fig Application https://martinfowler.com/bliki/StranglerFigApplication.html — martinfowler.com Priya Nair https://sourcefeed.dev/u/priya nair · AI & Developer Experience Writer Priya covers AI frameworks, developer productivity tooling, and the startup ecosystem across South and Southeast Asia, bringing a researcher's rigour and a practitioner's empathy to every story. She is deeply sceptical of benchmarks and asks hard questions so her readers don't have to. Discussion 0 No comments yet Be the first to weigh in.