Legacy in Months, Not Years: Keeping AI-Written Code Safe to Change

DevelopmentSoftware

Maria Filippova

Head of Community at The Top Voices

September 14, 20262 min

Article hero image

AI is radically changing the speed of software development, but the practices that keep code maintainable are not evolving at the same pace. As AI agents produce more code in less time, duplication, skipped refactoring, and hidden dependencies can accumulate surprisingly quickly. What used to take years to develop can now turn into a legacy problem within just a few months. This session explores how to make AI-written code understandable, controllable, and safe to change without giving up the benefits of AI-assisted development.

Speaker

Dmitriy Fedoryshchev is a Lead Software Engineer at EverCommerce. He builds and runs production systems end to end and has been using AI agents daily since May 2025, including on production systems with around 1,000 endpoints.

Legacy Is About Fear, Not Age

A codebase becomes legacy when developers are afraid to change it because they don't understand the potential blast radius of their changes.

AI accelerates this process by producing code faster than teams can review, refactor, and understand it. The result is a familiar pattern: new features break unrelated parts of the system, nobody fully understands the generated code, and code review becomes the bottleneck. AI has not changed the underlying legacy problem — it has changed the speed at which it emerges.

Why Rewriting the System Is Usually Not the Answer

Instead of completely rewriting a system, the better approach is to shrink the blast radius of changes.

With AI-written code, there may be no human who knows why a particular decision was made. This makes the system's structure and dependency map especially important: the map effectively becomes part of the project's institutional memory.

During the webinar, warpmap was used to analyze the codebase and make dependencies, hotspots, and potential risk areas visible.

How to Read a Codebase

Before changing anything, you need to understand where the risk actually lives.

Three simple signals can help:

  • Hotspots — files with high change frequency and complexity.
  • Blast radius — how many parts of the system depend on a particular component.
  • Test gaps — areas where important, frequently changing code is not sufficiently protected by tests.

These metrics do not provide ready-made conclusions. They help identify which parts of the system should be investigated first.

The warpmap tool was used throughout the webinar to perform this kind of code analysis.

How to Make AI Work Safer

Documentation alone is not enough: during long sessions, an agent can forget rules or lose them during context compression. Important rules should therefore be turned into deterministic constraints.

The presentation proposes progressively stronger guardrails: smaller tasks, separating permissions to modify code, tests, and CI, using command allow-lists, treating tests as part of the definition of done, and making invalid states impossible.

These ideas were demonstrated through agentweft, a multi-agent development workflow that formed a central part of the talk. The examples and learning curve discussed during the session were built around this workflow.

The principle is simple: don't slow the agent down — limit the ways in which mistakes can compound.

What a Team Can Do Today

A small team can start with a few practical steps:

  • Separate permissions to modify code, tests, CI, and rules.
  • Restrict agents to a set of allowed commands.
  • Replace “never do X” with a specific instruction describing what to do instead.
  • Automatically pass the most important rule to the agent when it is needed.
  • Prioritize tests for files that change frequently but have insufficient test coverage.

The practical examples throughout the talk used react-formkit as the main demo codebase.

Keep the Record of Code Provenance

There is one thing that will be difficult to reconstruct later: how much of the code was written by AI.

Instead of trying to determine AI authorship after the fact, teams should capture provenance immediately — through commit metadata, PR labels, and preserved session logs. This makes it possible to establish a defensible lower bound for the share of AI-generated code.

Conclusion

AI has not changed the fundamental reason why code becomes legacy — it has changed how quickly it happens.

The practical approach is:

Read — understand where the risk lives.
Hold — protect the system with enforceable guardrails.
Keep the record — document how the code was created.

The goal is not perfect code, but code that remains safe and predictable to change.

Stay Ahead in Tech & Startups

Get monthly email with insights, trends, and tips curated by Founders

Join 3000+ startups

The Top Voices newsletter delivers monthly startup, tech, and VC news and insights.

Dismiss