Can repository-level coding assistants detect their own unsafe code changes?

What does 'unsafe code change' actually mean for these tools?

In the context of repository-level coding assistants, 'unsafe' primarily means code that introduces dependency errors (like undefined variables or missing imports), fails to compile, or breaks existing functionality across multiple files. The papers consistently measure safety through metrics like static validity rate, compile rate, and pass rate on tests. [1] explicitly defines dependency errors such as 'undefined-variable and no-member errors' and measures how often generated code avoids them using a new metric called Static Validity Rate. [2] uses compile@k and pass@k scores to capture whether generated code compiles and passes tests. [4] goes further, requiring that edited repositories 'build without errors and make correct code edits' as a validity check. So 'unsafe' in this research means code that introduces concrete, detectable failures, not subtle security vulnerabilities.

The core finding: these tools have no built-in self-detection

Across all five papers, none describe a mechanism where the coding assistant monitors or evaluates its own output for safety. The tools are designed to generate code, not to audit it. [4] makes this limitation explicit: it shows that baseline LLMs without a planning framework 'cannot get any of the repositories to pass' validity checks (building without errors and making correct edits), while their CodePlan system with explicit planning succeeded on 5 out of 7 repositories. This means even the best-performing systems still fail on a significant fraction of repositories, and they have no way to detect those failures themselves. [1] reports that even with their ToolGen approach, which uses autocompletion tools to reduce dependency errors, the Static Validity Rate improved by 44.9% to 57.7% across three LLMs — but that still leaves 42-55% of generated code with unresolved dependency errors. The tools cannot flag which outputs are unsafe.

Why self-detection is harder than it seems

The complexity of repository-level code makes self-detection fundamentally difficult. Code in a repository is 'inter-dependent' [4], meaning a change in one file can break functionality in another file that the tool may not have even seen. [2] notes that successful generation requires 'both general, context-agnostic knowledge and specific, context-dependent knowledge' spread across multiple files. [3] shows that even retrieval-based methods struggle: their reinforcement learning framework improved retrieval quality by 12.2% in exact match over previous methods, but still relies on an external retriever to find relevant context — it does not evaluate whether the final generated code is safe. [5] similarly uses an iterative retrieval-generation pipeline but measures success only by whether the code matches a ground-truth completion, not by whether it introduces unsafe changes. In short, the research community treats safety as an external evaluation problem (measured by compilers, tests, or human judges), not as something the tool itself can assess.

Could future tools detect their own unsafe changes?

The evidence suggests that self-detection would require fundamentally different system architectures. [4]'s CodePlan comes closest by incorporating 'incremental dependency analysis' and 'change may-impact analysis' as symbolic components that guide the LLM, but even this system does not have a self-detection loop — it plans edits but does not verify them after generation. [1]'s ToolGen uses autocompletion tools to reduce errors at generation time, but again, the safety check is external (static analysis tools). None of the papers propose or evaluate a system that generates code, then checks its own output for safety, then flags or corrects unsafe changes autonomously. The research consistently treats safety as something to be measured by external tools (compilers, static analyzers, test suites) or human reviewers, not by the coding assistant itself. So while future work could integrate such verification loops, the current generation of repository-level coding assistants cannot detect their own unsafe code changes.

About These Sources

This answer is built on 5 peer-reviewed studies — published from 2023 to 2025, 4 from 2024 or later, 2 in Q1 journals, collectively cited 175 times — selected as the most relevant from 5 studies that passed quality screening, drawn from 51 papers retrieved from a database of over 500 million.

Sources used in this answer

Related research questions