Inspiration
AI can generate code quickly, but a plausible patch is not necessarily a correct one. Refactoring becomes risky when a small change affects multiple files, hidden call paths, or existing behavior. I built Principal to address this gap: make AI-assisted refactoring depend on verification, not confidence.
What it does
Principal is an AI-powered refactoring system designed to analyze code changes, map their potential impact, generate competing patches, and evaluate candidates in isolated environments. It combines dependency-aware planning, parallel patch generation, and automated verification. The goal is simple: generated changes should earn approval through evidence, not just a model's confidence.
How I built it
I designed Principal around a staged workflow combining code analysis, model-driven planning, parallel candidate generation, isolated sandbox execution, and verification gates. The workflow examines the target code and its dependencies, plans the change, generates candidate patches, and evaluates them before considering a result for publication. I structured the architecture to separate inexpensive local checks from model inference and sandbox execution. This helps reject unusable candidates early and keeps verification central to the process.
Challenges I ran into
The hardest part was making generated patches verifiable across a codebase rather than judging them by how reasonable they looked. A patch can pass a syntax check and still break a caller, miss a dependency, or change existing behavior. I also had to consider the cost of parallel candidate generation and sandbox execution. I approached these challenges through staged checks, isolated execution, and explicit verification criteria.
Accomplishments I'm proud of
I built a working demonstration of a verification-gated refactoring workflow, with visible pipeline stages, candidate-generation activity, verification results, and run-level evidence. What I'm most proud of is the central engineering principle: an AI-generated patch should not be considered successful simply because it was generated. It must be evaluated, and the system must make the outcome clear.
What I learned
Building Principal reinforced that automated refactoring involves much more than generating code. Understanding dependencies, preserving existing behavior, testing relevant paths, and handling failures are equally important. I also learned that verification must be built into the architecture from the beginning, rather than added as a final step.
What's next for Principal
I plan to strengthen verification across larger repositories and more complex changes, improve coverage of indirect and dynamic call paths, and measure candidate quality against verification coverage, execution cost, and time saved. I also want to make the evidence behind each decision easier to inspect, so developers can understand why a candidate passed, why it failed, and when the system should decline to offer a patch.
Log in or sign up for Devpost to join the conversation.