ローカルLLMにC言語レガシープロジェクトの循環依存リファクタリング計画書を書かせた This article shows how a local LLM was used to generate a refactoring plan for circular de…

A recent blog post on Zenn documents a practical experiment in which a locally hosted large language model was tasked with producing a refactoring plan for circular dependencies inside a legacy C codebase. The exercise is notable less for any single technical breakthrough than for what it suggests about where local LLMs are becoming useful in everyday software maintenance, particularly when the source code cannot leave an organization's own machines.

Circular dependencies are a familiar problem in long-lived C projects. They occur when two or more translation units or headers depend on one another, directly or through a chain of includes, so that no clean build or initialization order exists. In C the issue is aggravated by the preprocessor's textual include model, header guards, and the frequent use of shared global state. Over years of incremental changes, these cycles tend to accumulate, making the code harder to test in isolation, slower to compile, and riskier to modify. Untangling them usually requires introducing forward declarations, splitting headers, moving type definitions, or applying dependency inversion so that lower-level modules no longer reach back into higher-level ones.

The reported approach uses the model not to rewrite the code automatically but to analyze the dependency structure and draft a written plan describing how the cycles could be broken. That distinction matters. A refactoring plan is a lower-risk deliverable than a direct code change: it can be reviewed by an engineer, discussed by a team, and executed incrementally, while the model's reasoning remains advisory. For legacy systems where regressions are expensive, this human-in-the-loop framing appears to be a sensible way to apply a technology that still makes mistakes.

The central argument in the article is about privacy and control. Because the model runs locally rather than through a hosted API, proprietary or security-sensitive C code never crosses a network boundary. This addresses a common blocker for teams that would otherwise be barred by policy or contract from sending source code to third-party services. Running offline also removes per-token costs and usage limits, which makes it more practical to feed large amounts of context, iterate repeatedly, or batch-process many files without watching a metered bill.

Local execution has become considerably more accessible thanks to runtimes such as Ollama, llama.cpp, and LM Studio, which package models with quantization so they can run on consumer GPUs or even CPUs. Alongside general-purpose models, code-specialized families such as Code Llama, DeepSeek-Coder, and the Qwen and CodeGemma lines have narrowed the gap with hosted offerings on programming tasks. Their quality on a specific codebase still depends heavily on the amount of context that can be supplied, and C projects with deep include trees can quickly exceed a model's context window, so some form of selection or summarization of the relevant files is typically required.

It is worth stressing that an LLM does not natively understand a build graph. To reason accurately about dependencies, it benefits from structured input produced by conventional tooling. Established static-analysis and tooling options in the C ecosystem include cppcheck, Clang-based tools such as clang-tidy and the libclang APIs, include-what-you-use for pruning unnecessary headers, and Doxygen, which can emit include and call graphs. Feeding a model the output of such tools, rather than raw source alone, is likely to yield a more grounded plan and reduce the chance of the model inventing relationships that do not exist. The blog frames its work as an experiment rather than a validated methodology, so readers should treat the generated plan as a starting point to be checked against the actual build system and tests.

The broader context is a steady move toward using local models for tasks that touch confidential material, from code review to documentation. Refactoring planning is a reasonable fit because it rewards pattern recognition and produces text that a developer must verify anyway. The main caveats remain the risk of hallucinated dependencies, the difficulty of fitting a large codebase into limited context, and the reality that breaking circular dependencies safely still requires strong test coverage and careful, staged execution. As an illustration of how a private, offline model can assist with an unglamorous but common maintenance problem, the article offers a concrete data point rather than a finished solution.