Self-Programming AI: Code-Learning Agents for Autonomous Refactoring and Architectural Evolution — part 5/7

Cleaned-text code points [54812, 66379). Bibliography omitted here; source.md includes it.

test assertions, the agent produced noticeably different (and incorrect) implementations, underscoring how fragile 
the loop can be if validation is imperfect 
We also encountered cases of local-optimum stagnation during refactoring. Often the agent would iterate through 
many cycles of improvement and then plateau – achieving passing tests but failing to f ind a better design. This 
suggests the agent had become trapped in a “good enough” solution that satisfied current requirements, without 
exploring more optimal architectures. Such behavior is consistent with recent findings that LLMs excel at resolving 
simple code smells but struggle with high-level architectural refactoring. For instance, in one experiment the agent 
reduced several long methods into smaller ones (addressing obvious smells), but it never reorganized the overall 
class hierarchy even though doing so would have greatly simplified the design. In other words, after addressing 
immediate syntactic issues, the code often settled into a design local optimum. This echoes the observation from 
Cordeiro et al. that current code LLMs underperform on complex modularization tasks: human developers still 
outperform LLMs on issues like broken class structure. In our case, unless manually prompted to rethink the entire 
module layout, the agent’s autonomous refactoring would typically stop at minor improvements, leaving potentially 
better designs unexplored. 
Long-Term Vision 
Looking ahead, we anticipate several enhancements that could address today’s shortcomings and greatly expand the 
agent’s capabilities. A key future direction is giving the agent persistent memory and learned preferences. 
Currently, each run is stateless: the agent does not remember past code or style choices. In a long-term system, the 
agent could accumulate knowledge of a project’s conventions – for example, preferred naming patterns, formatting 
rules, or favored architectural patterns – and enforce them automatically. This persistent context would help ensure 
consistent coding style over time. Indeed, recent analysis shows that code generated by LLMs often deviates in 
readability and style from human-authored code; an agent with memory could  learn to mimic a team’s idioms. 
Similarly, the agent might learn preferred architectures: for instance, if a codebase is organized in a functional or 
data-oriented style, the agent could bias its solutions to fit that paradigm. Over many projects, one can imagine the 
agent developing a kind of “coding personality” suited to each domain. 
In the long run, such advanced agents could act as collaborative software developers rather than mere code 
transformers. With self-programming capabilities, an agent could not only write and refactor code but 
also maintain it autonomously. For example, it could monitor dependency updates and adjust the code, regenerate 
failing tests, or even propose new features based on usage patterns. By continually running its own test suites, the 
agent could enforce long-term quality, fixing code smells or performance issues on the fly. Importantly, the human 
developer would shift into a more strategic role, guiding the agent with high-level go als or design feedback while 
the agent handles the grunt work of implementation and maintenance. We see this collaborative model as a natural 
evolution: agents that self-generate and self-validate code, working alongside human s to raise software productivity. 
Although many challenges remain, the consistency and effectiveness observed so far – combined with rapid 
advances in LLM fidelity – give reason for optimism that future iterations of these self-programming agents will 
become reliable partners in software engineering. 
Feature Codex Reflexion Voyager CodeRL Our System 
(SPA) 
Model Type GPT-3 fine-
tuned on 
code 
GPT-3.5 with 
self-feedback 
Code + skill 
memory 
CodeBERT + 
RL Critic 
GPT-3.5-turbo 
function-calling 
One-shot or Iterative One-shot Iterative (text-
level) 
Iterative 
(skills) 
Iterative (RL 
sampling) 
Iterative (code + 
tests)

Test-based Self-
Refinement 
     (reasoning 
level) 
   (Minecraft 
tasks) 
   (unit test 
pass ratio) 
   (unit tests + 
metrics) 
AST-Level Code 
Editing 
           (via 
LibCST) 
Static Metrics 
(Complexity, Lint, MI) 
           
Explainable 
Refactoring Support 
  Partial 
(reasoning 
traces) 
    Planned 
Language Support Python, JS, 
etc. 
Python Python Python Python 
(polyglot 
planned) 
Memory / Long-Term 
Learning 
  Short-term 
self-reflection 
   (persistent 
skill lib) 
  Planned 
(lifelong 
evolution) 
Tool/Environment 
Integration 
IDE plugin, 
API 
Text interface Minecraft env 
(API + UI) 
CLI for coding 
tasks 
Planned Git/PR 
integration 
Open Source / 
Extensible 
      Partially 
(CodeRL repo) 
   (modular 
Python code) 
 
 
6. Future Work 
Multi-Agent Collaboration: A promising extension is to decompose the agent’s responsibilities across a team of 
specialized sub-agents, mirroring human development workflows. For example, o ne could introduce a Planner 
agent to sketch high-level designs and task breakdowns, a Developer/Refiner agent to write and iteratively 
improve code, and a Tester agent to generate and execute test suites. This role-based approach has been shown to 
improve performance in recent systems: for instance, the HyperAgent framework explicitly employs Planner, 
Navigator/Editor, and Executor agents to manage tasks from design through verificationarxiv.org, 
and AgentCoder separates coding and testing into distinct programmer, test-designer, and test-executor 
agentsarxiv.org. Likewise, surveys of multi-agent code generation note that coordinating “coders, testers, [and] 
planners” in a structured workflow can yield efficiency gainsopenreview.net. In our future work, agents could 
communicate via a shared memory or message-passing bus, allowing parallel prog ress on different modules of a 
large codebase. For instance, while one agent refactors a data model, another could write unit tests for a separate 
component. This division of labor naturally scales to distributed systems or microservice architectures. Challenges 
to address include synchronization (e.g. merging changes from concurrent branches) and avoiding duplicated effort. 
Research from multi-agent systems suggests using consensus protocols or priority rules to manage such 
coordination, as well as hierarchical planning to keep the team aligned. By leveraging specialized roles and clear 
interfaces between agents, we expect to extend our self-programming framework to larger projects without 
overwhelming any single LLM instanceopenreview.netarxiv.org.

• Example Roles: One can imagine a set of agents with distinct roles, such as (a) Planner – analyzes project 
requirements and decomposes tasks; (b) Coder/Refiner – generates and refines code snippets based on 
feedback; (c) Tester – creates and runs test cases and reports failures. Each role mimics parts of a human 
development team, enabling parallel work on different features. Such an organization echoes recent efforts 
(e.g. HyperAgent’s planner/editor/test-executor designarxiv.org and AgentCoder’s programmer/tester 
splitarxiv.org), suggesting this is a viable path forward. 
Git Integration: To apply the agent to real-world projects, it must interface with version control. We plan to embed 
Git capabilities so that the agent can clone repositories, create branches, commit changes, and open pull requests. 
This allows incremental development in the same way human teams use CI/CD pipelines. For ins tance, the agent 
could check out a “feature” branch, modify code, run the build and tests locally, then commit the changes with an 
LLM-generated commit message. It could then push and create a pull request for review, optionally incorporating 
feedback from automated CI tests or other agents. Prior work emphasizes that toolchain integration is crucial: recent 
analyses call for multi-agent coding systems to be “better integrated with tools”open review.net, and AI-based 
refactoring tools have been advised to provide plugins or APIs for IDEs and version-control systemsmdpi.com. By 
operating through Git, our agent would naturally leverage existing workflows (e.g. code review, automated testing, 
issue tracking) and maintain a transparent history of all its edits. Early steps might include scripting Git commands 
via libraries (e.g. libgit2 or GitHub’s API) and ensuring that merges and conflict resolution are handled robustly. 
Over time, this integration would enable the agent to work alongside developers on the same codebase, submitting 
changes as pull requests and learning from the project’s history and community feedback. 
• Integration Tasks: In practice, the agent should support operations like branch creation, diff generation, and 
pull requests. For example, it might: (1) Clone and branch: use git clone and git checkout -b to isolate 
new work; (2) Commit and diff: apply AST-level patches and git commit them with descriptive messages; 
(3) Pull requests: push branches and open PRs for review, then incorporate test results or human 
comments. These steps mirror standard DevOps, and Schoemaker et al. specifically note that AI tools 
should integrate with version control for smooth developer adoptionmdpi.com . Achieving reliable Git 
interaction will be an important near-term milestone for applying the agent to complex, real codebases. 
Explainable Refactoring: As the agent becomes more autonomous, it must justify its changes to human 
stakeholders. Future work should therefore focus on explainable code transformations. Each automated edit or 
refactoring should be accompanied by a human-readable rationale. One strategy is  to produce structured AST diffs 
combined with natural-language summaries. For example, the agent could use an AST differencing tool (like 
ChangeDistiller) to identify atomic edit operations – renames, extractions, etc. – an d then output a plain-text 
explanation for each (e.g. “Renamed function foo to get_data for clarity”). This idea is supported by the XAI 
literature for software: Schoemaker and Pulvermüller emphasize that “providing explanations or rationales for each 
refactoring suggestion helps developers understand why [it is] recommended”mdpi.com. Similarly, software-
engineering research on code change visualization relies on AST-level operations to summarize 
editsweb.cs.ucla.edu. In our framework, we will extend the output of each refinement iteration to include (1) a 
precise diff of the code’s AST, and (2) a concise narrative of the intent behind each change. For instance, after a 
refactoring pass the agent might annotate its pull request with comments 
like “Extracted computeMetrics() from analyze() to reduce duplication” or “Replaced deprecated API call X with Y 
for future compatibility”. This structured explanation will improve trust and auditability: developers can review not 
only what changed but why. Designing the model to generate such justifications – possibly by prompting for 
“change description” – will be an important extension. Ultimately, we envision a pipeline where each AST-edit 
operation is traced to a semantic label and a textual justification, integrating principles of explainable AI into 
software maintenancemdpi.comweb.cs.ucla.edu. 
• Explainability Features: Future enhancements could include: (a) AST-level diff summaries: automatically 
decompose each change into basic edit types (using approaches like ChangeDistillerweb.cs.ucla.edu);