Fourteen days and hundreds of tiny edit-test-commit cycles was the scale of a recent experiment in which developer Jesse C. Hopkins let a local LLM agent work on a legacy Python module. Hopkins gave the agent full read/write access to a single module of a Python 3.8 authentication microservice he wrote in 2019, but only inside a sandbox and with two hard rules: public API signatures couldn't change and tests must not be deleted. He ran the agent locally because cloud calls were too expensive, and the stated goals were clearer type hints, fewer lines of code where possible, and improved cyclomatic complexity while preserving behaviour as captured by a regression harness. Hopkins completed the 14-day experiment in January 2026 and documented the workflow and guardrails he used, stressing the importance of strict test coverage and narrow, reviewable changes.

The read here is simple. Constrained, local AI can be used to chip away at brittle legacy code, provided you bring tests and strict limits to the process. Hopkins didn't set the agent loose on a whole repository. He aimed small and watched closely.

The code and the guardrails

The module in question was compact but battle scarred. Hopkins wrote the authentication microservice in 2019. It had survived three framework upgrades and two team reorganisations. Inside the file were deeply nested code paths, sometimes six levels deep, and generic variable names such as data and temp_list that made intent hard to read. Hopkins said he had been avoiding edits for years because small changes previously introduced unexpected failures.

That history shaped the experiment. Hopkins scoped the agent to a single module and created a sandboxed environment. He imposed explicit guardrails, most notably two hard rules: public API signatures must remain unchanged, and tests must not be deleted. He also limited the agent's commit surface and mixed automated cycles with human oversight. The workflow was hundreds of short generate-test-commit iterations, executed locally to avoid heavy cloud bills.

The aims were procedural and measurable. Hopkins wanted to increase type hint coverage, reduce lines of code where safe, and adjust cyclomatic complexity scores. At every step the priority was preserving existing behaviour as captured by tests and a small regression harness, rather than chasing a big, sweeping cleanup.

Hopkins' approach mirrors recommendations found across practitioner how-to guides. One common sequence those sources suggest is: first use AI to summarise architecture and identify hotspots, second add characterization tests that lock down observable behaviour, and third deploy AI-driven refactors in small, focused pull requests so reviewers can reason about each change.

Mastheads

The guides also urge generating test cases after refactors to confirm behaviour remains the same.

There are two recurring risks these guides try to mitigate. First, silent behavioural drift, where a refactor changes edge-case behaviour that tests don't cover. Second, verification debt, created when a large diff or sweeping cleanup makes regressions hard to debug. Best practice therefore calls for characterization tests, golden-file or snapshot checks, and a small regression harness before allowing an agent to modify production code. It also calls for tiny, single-intent pull requests so human reviewers can follow the logic in minutes.

Hopkins answered those risks directly. By forbidding deletion of tests and keeping the agent local and sandboxed, he limited both the accident surface and the cost of iteration. By insisting on narrow commits and human review at each step, he reduced the verification debt that comes with big, automated merges.

The wider statistics explain why such caution matters. Sonar's State of Code Developer Survey reports that developers estimate 42% of their committed code is AI-assisted, yet 96% don't fully trust AI output to be functionally correct and only 48% always check AI-assisted code before committing. Put bluntly, teams are using AI but they still lack trust in its results. That trust gap is why Hopkins emphasised safe scaffolding and test coverage over bulk rewrites.

When those precautions are followed, practitioners report clear practical advantages. Across multiple guides and case studies, authors say AI helps to modernise syntax, split monolithic functions into single-responsibility components, identify redundant code for consolidation, and accelerate test creation for previously untested paths. Many of those accounts also recommend running models locally for high-iteration experiments, both to control cost and to keep sensitive code off third-party APIs.

Hopkins' experiment didn't treat the agent as an autonomous maintainer. Human oversight remained central. That mirrors the practical playbook used by teams who accept AI as an assistant rather than a replacement. The difference between the two approaches isn't rhetorical. An assistant run from a laptop with a tight regression harness creates a reviewable trail and a bounded risk profile. An autonomous, cloud-driven sweep creates verification debt and potential blind spots.

There are trade-offs. Running locally increases iteration speed and keeps secrets in-house, but it shifts the compute cost and tooling burden back to the developer. Limiting the agent to one file reduces blast radius but also constrains how much systemic improvement you can achieve in a short burst. Hopkins chose to accept those trade-offs in order to keep the experiment small, explainable and reversible.

For teams thinking about following the same path, the practical sequence is clear. First, map the legacy codebase and identify hotspots. Second, add characterization tests to capture current behaviour. Third, run local, short AI cycles limited to a narrow change surface and never delete tests. Fourth, ship each intent as a small pull request so reviewers can absorb the change quickly. Those steps are present in the how-to guidance Hopkins mirrored and in the case studies the literature collects.

Related Articles

Hopkins completed the experiment in January 2026 and published his workflow and guardrails, most notably the emphasis on characterization tests and tiny, reviewed pull requests as a practical, reviewable blueprint for cautious AI-assisted refactoring.

This article was created with AI assistance.