PaperlayerView exact revision on arXiv

Source-linked AI summary

Self-Improving AI Coding Agents Through Accumulated Behavioral Rules: A Closed-Loop Framework

Aditya Aggarwal, Nahid Farhady Ghalaty

arXiv:2607.13091v1cs.SEcs.AI

TL;DR

Static coding-agent instructions do not evolve with experience through review feedback. The paper combines persistent rules derived from human review with checklist-based self-review. It reports no recurrences among tracked error classes during observation, a shift toward design-focused review, and rule transfer across boundaries.

  • Problem

    Static coding-agent instructions capture conventions but lack a feedback loop through which review outcomes strengthen future behavior.

    Source: §I · p. 1

  • Method

    The framework converts generalizable human review feedback into persistent behavioral rules loaded across sessions and pairs code generation with checklist-based self-review.

    Source: C. The Feedback Loop · p. 2

  • Results

    0 recurrences were observed across 9 tracked error classes and 74 cumulative post-rule session-exposures; review shifted toward design, and rules transferred across boundaries.

    Source: §X · p. 8

  • Takeaways & Limitations

    Human review knowledge can persist across sessions without fine-tuning or model-specific infrastructure.

    Source: §X · p. 8

    Without a controlled baseline or paired ablation, the reported error suppression and review shift provide initial empirical evidence rather than causal proof.

    Source: §VIII · p. 7

Abstract

from arXiv · show

LLM-based coding agents repeat the same classes of mistakes across sessions because they lack a mechanism to retain corrections from human review feedback. We present a closed-loop framework in which every accepted review comment is codified as a persistent behavioral rule, progressively expanding the set of error classes the agent can self-detect. The framework combines an accumulating rule set in a version-controlled instruction file, a self-review checklist executed before code submission, and automated validation that ensures rule set integrity as it grows. In deployment across a 35+ service microservices platform, the rule set grew from 5 to 18 behavioral rules, 15+ language-specific standards, and a 15-item self-review checklist, all derived from real review feedback. We present empirical results from 11 recorded working sessions spanning code generation, PR review, incident investigation, and cross service refactoring. We observe that accumulated rules shift review effort from low-level correctness toward design-level validation, achieve a measured 0% recurrence rate for ruled-against error classes, and transfer across heterogeneous agent interfaces. We compare our approach against related work in experiential LLM learning (Reflexion, ExpeL, Voyager) and automated code review (CodeReviewer, SWE-bench agents), showing that our framework achieves persistent cross-session learning without weight updates, operates on production codebases rather than synthetic benchmarks, and addresses an orthogonal dimension (behavioral consistency over time) that existing benchmarks do not measure. The result is a coding agent that improves with every review cycle, accumulating the engineering wisdom of its human collaborators without changing a single model weight.

I. INTRODUCTION · A. Scope and Positioning

The framework converts accepted human review feedback into persistent behavioral rules stored in version-controlled instruction files, without updating model weights. It targets known coding-agent failure modes within a defined codebase, augmenting human review rather than guaranteeing semantic correctness.

I. INTRODUCTION

  • Coding agents repeat reviewed mistakes across sessions, while fine-tuning, RAG, and static instructions lack a review-driven behavioral feedback loop.Fine-tuning is described as expensive and organization-specific; RAG supplies code context rather than behavioral constraints, while static instructions do not evolve with experience.Source: §I · p. 1
  • Accepted review comments become persistent self-review rules, monotonically expanding the error classes the framework aims to prevent.The proposed accumulated-behavioral-rules approach aims for zero avoidable review comments.Source: §I · p. 1

A. Scope and Positioning

  • Version-controlled instruction files provide model-agnostic, tool-agnostic operational memory without weight updates.The shared artifact is reusable across team members and immediately deployable; the framework involves neither retraining nor reinforcement learning from human feedback (RLHF).Source: §I · p. 1, A. Scope and Positioning · p. 2

I. INTRODUCTION

  • 11 recorded working sessions examine rule accumulation, error-class suppression, and knowledge transfer across code generation, PR review, cross-service refactoring, and incident investigation.The paper presents the system architecture and quantitative empirical results from production deployment.Source: §I · p. 1
  • Comparisons with Reflexion, ExpeL, Voyager [15], CodeReviewer, and SWE-agent [16] position persistent cross-session behavioral consistency as a dimension existing benchmarks omit.The comparison spans experiential LLM learning and automated code review.Source: §I · p. 1

A. Scope and Positioning

  • Organizational memory derives exclusively from accepted review outcomes, converting individual corrections into class-level behavioral constraints within a defined codebase.Unlike static instructions, the instruction file grows directly from review outcomes, with every new rule traceable to a specific accepted comment.Source: A. Scope and Positioning · p. 2
  • The framework augments human review by targeting previously seen errors, but neither proves semantic correctness nor prevents every possible failure.Its intended benefit is to free reviewers for higher-order concerns.Source: A. Scope and Positioning · p. 2

II. FRAMEWORK ARCHITECTURE · A. The Structured Instruction File · B. Rule Representation

The framework converts accepted review comments into persistent behavioral rules in a version-controlled instruction file loaded at every session. Structured rule representations connect review origins to self-review checklist items and support future validation tooling.

II. FRAMEWORK ARCHITECTURE

  • Each accepted review comment becomes a persistent behavioral rule, expanding the agent’s self-review capability across subsequent sessions.Figure 1 depicts this closed-loop feedback cycle.Source: Figure 1 · p. 2

A. The Structured Instruction File

  • Agents load a version-controlled Markdown instruction file as system context at the start of every session.Examples of this convention include AGENTS.md, rules files, and instruction files.Source: A. The Structured Instruction File · p. 2
  • The instruction file is append-friendly and monotonically growing, accumulating engineering judgment through added and occasionally refined rules that are rarely removed.This accumulation is identified as the file’s critical property.Source: A. The Structured Instruction File · p. 2
  • The deployment organizes instructions into behavioral rules, code standards, a self-review checklist, anti-patterns, and workflow rules.These cover operational guardrails, language-specific review lessons, checks before code approval, prohibited patterns with alternatives, and task-based tool or sub-agent triggers.Source: A. The Structured Instruction File · p. 2

B. Rule Representation

  • Human-readable Markdown rules implicitly encode identifiers, categories, origins, scopes, constraints, rationales, checklist mappings, addition dates, and review provenance.The illustrated R17 rule concerns new internal HttpClient registrations and maps to self-review item #9.Source: B. Rule Representation · p. 2
  • The rule schema links rules to originating review events and self-review checklist items while supporting future conflict detection and effectiveness scoring.Checklist mappings create a verifiable connection between the instruction file and pre-submission checks.Source: B. Rule Representation · p. 2

C. The Feedback Loop … F. Workspace Validation as Reliability Mechanism

The framework converts generalizable human review feedback into persistent behavioral rules that expand agents’ self-detection capabilities across sessions. Rule governance and automated session-start validation maintain the growing instruction set.

C. The Feedback Loop

  • Accepted review comments identifying generalizable mistakes become persistent rules, expanding the error classes agents can self-detect across subsequent sessions.The cycle proceeds through code generation, checklist-based self-review, human review, rule addition, and reloading updated instructions. The instruction file preserves organizational memory across sessions, models, and tool boundaries.Source: C. The Feedback Loop · pp. 2–3

D. Rule Lifecycle and Governance

  • Engineers promote plausibly recurring mistakes into rules and refine overly broad or narrow rules in place while preserving rule IDs.The engineer receiving feedback decides whether the mistake could plausibly recur in a different context.Source: D. Rule Lifecycle and Governance · p. 3
  • Periodic reviews address redundancy by letting specific rules subsume general ones, while teams resolve conflicting rules through the repository’s pull-request review process.Changes to the shared instruction file require pull requests.Source: D. Rule Lifecycle and Governance · p. 3

E. Illustrative Rule Examples

  • Rules prohibit caller disposal of factory-created HttpClient instances, require structured logging templates, and prescribe !A && !B && !C for conjunctive negation.These rules arose from review findings involving resource lifetime, interpolated log messages, and an incorrect Boolean guard clause.Source: E. Illustrative Rule Examples · p. 3
  • Other rules require explicit null validation with ?? throw new ArgumentException(...) and an SSRF policy entry for every new HttpClient registration.Reviewers identified use of the null-forgiving operator and an internal HTTP client registration missing its SSRF allowlist entry.Source: E. Illustrative Rule Examples · p. 3

F. Workspace Validation as Reliability Mechanism

  • Session-start validation checks agent definitions, skill instructions, knowledge freshness, instruction-file completeness, automation scripts, and tool-server configurations to guard against malformed additions.Checks require valid frontmatter and required fields, properly structured skill instructions, freshness dates, required instruction sections, existing scripts, and well-formed tool-server configurations.Source: F. Workspace Validation as Reliability… · p. 3

G. Session Continuity … C. Knowledge Source Distribution

The deployment preserved ongoing work context through session handoffs and task logs while agents shared one instruction file across interfaces. Human reviewer feedback accounted for 39% of the analyzed learning sources.

G. Session Continuity

  • A session handoff file preserves in-progress work, pending reviews, and suggested next actions between sessions.This extends retained knowledge beyond behavioral rules to ongoing work context.Source: G. Session Continuity · p. 3
  • A task log complements the session handoff by maintaining a chronological record of completed work.Together, the two mechanisms support session continuity.Source: G. Session Continuity · p. 3

A. Environment

  • 35+ services and approximately 50,000+ lines of shared infrastructure code formed the deployment environment, using managed container orchestration and a service mesh.Agents across multiple interfaces read the same instruction file.Source: A. Environment · p. 3
  • Agents supported code generation, review, architecture investigation, incident response, and cross-service refactoring.These activities occurred across multiple agent interfaces within the deployed platform.Source: A. Environment · p. 3

B. Rule Accumulation Over Time

C. Knowledge Source Distribution

D. Observed Effects … A. Experimental Setup

Across 11 recorded sessions following rule additions, no ruled-against patterns recurred within the observation window. Reviewers reported less time spent on mechanical issues and more on architectural appropriateness and design trade-offs.

D. Observed Effects

  • 11 recorded working sessions following rule additions showed no recurrence of ruled-against patterns within the observation window.This indicates suppression under the observed deployment conditions, not a permanent property of the underlying model.Source: D. Observed Effects · p. 4
  • Reviewers reported spending less time on mechanical issues and more on architectural appropriateness and design trade-offs.Source: D. Observed Effects · p. 4
  • New team members immediately inherited the accumulated rule set, bypassing the learning curve that originally produced those rules.Source: D. Observed Effects · p. 4
  • Specific, actionable rules were followed more reliably than general guidance as the rule set evolved from broad instructions toward precise requirements.Source: D. Observed Effects · p. 4

E. Rule Conflicts: A Concrete Example

  • One conflict between universal IDisposable using declarations and non-disposal of factory-created HttpClient instances was resolved by narrowing the general rule’s scope.Code review detected the contradiction, and resolution depended on correct framework behavior rather than a judgment call.Source: E. Rule Conflicts: A Concrete Example · p. 4

F. Multi-Interface Behavioral Transfer

  • Accumulated rules immediately transferred between IDE-integrated and terminal-based agents because both interfaces loaded the same instruction file.IDE agents excelled at repository analysis, while terminal agents excelled at execution; both benefited equally from accumulated rules. The authors suggest this could provide shared memory for specialized multi-agent workflows,.Source: F. Multi-Interface Behavioral Transfer · p. 4, D. Observed Effects · p. 4

A. Experimental Setup

  • 35+ services formed the deployment platform, with two agent interfaces consuming the same shared instruction file.The platform included 13 custom agent definitions, 10 operational skills, and 6 shared knowledge documents. Data sources comprised 11 dated task-log entries, 2 committed instruction-file revisions plus continuous local growth, 4 topic-specific memory documents, and 36 PR reviews across 6 repositories.Source: A. Experimental Setup · p. 4

B. Rule Accumulation Dynamics … E. Knowledge Transfer Patterns

The deployment recorded no post-rule recurrences, while review comments concentrated on architecture, API design, and performance. Rule growth tapered over time, and most documented knowledge transfers crossed repository or tool boundaries.

B. Rule Accumulation Dynamics

C. Error-Class Recurrence Analysis

  • 0 recurrences were observed across 9 tracked error classes over 74 cumulative post-rule session-exposures.These were the central results of the error-class recurrence analysis.Source: Table IV · p. 4, C. Error-Class Recurrence Analysis · p. 4
  • The zero-recurrence finding is observational evidence from a single deployment, not a controlled experiment or a permanent guarantee.The finding is limited to the observation window and subject to the paper’s threats to validity.Source: C. Error-Class Recurrence Analysis · p. 4

D. Review Comment Category Shift

  • 14% of review comments concerned mechanical correctness and style, while 66% concerned architecture, API design, and performance.The analysis covered 36 PR reviews across 6 repositories, using categorization criteria adapted from prior code review studies,.Source: D. Review Comment Category Shift · p. 5, Table V · p. 5

E. Knowledge Transfer Patterns

F. Rule Specificity Evolution … A. Summary of Findings

The deployment observed no recurrence of tracked, previously corrected error classes within its observation window, alongside knowledge transfer across tools, repositories, and task types. Rules became progressively more specific, while three-layer persistent memory consumed less than 5% of a 128K context window.

F. Rule Specificity Evolution

G. Multi-Layer Memory Architecture

H. Session Task Diversity

  • 39% of rules came from PR reviews and incident investigations, demonstrating contributions from non-generative tasks beyond code generation.Table IX describes the session activity distribution.Source: Table IX · p. 5, H. Session Task Diversity · p. 5

A. Summary of Findings

  • 18 behavioral rules, 15+ language-specific code standards, and a 15-item self-review checklist were derived from accepted human review feedback without model-side changes.Version-controlled instruction files stored these artifacts and were consumed by multiple agent surfaces.Source: A. Summary of Findings · p. 5
  • 0 recurrences were observed across 9 tracked error classes and 74 cumulative post-rule session exposures during the four-week deployment.This observational result is not a statistical guarantee: the deployment covered one team and one primary language, without an A/B control.Source: A. Summary of Findings · p. 5
  • 60% of observed knowledge-transfer events (9/15) crossed repository, tool, or task-type boundaries.Rules added through one interface took effect immediately in sessions using another. Declarative natural-language constraints in plain Markdown enabled transfer to agents loading the file as system context.Source: A. Summary of Findings · p. 5

B. Match and Contribution … C. ExpeL: Experiential Learning Across Tasks

The framework converts accepted human review feedback into persistent, auditable rules managed through standard engineering workflows. It distinguishes these rules from Reflexion’s episodic self-reflection and ExpeL’s autonomously extracted insights.

B. Match and Contribution

  • The framework embeds vendor-agnostic agents in code review, making organizational knowledge auditable through rules with documented origins, owners, change histories, and pre-submission checklist positions.Each rule traces to a review event, the engineer accepting the comment, and the pull request adding it.Source: B. Match and Contribution · p. 6
  • A deployable instruction file combines a rule schema, lifecycle, validation, and feedback loop using standard infrastructure without fine-tuning, model-specific tooling, or specialized memory backends.The deployment used Git, Markdown, pull-request review, and plain-text validation scripts, allowing organizations to reproduce the pattern with existing infrastructure.Source: B. Match and Contribution · p. 6
  • The evidence is limited to one team, one language, four weeks, and no controlled baseline, alongside documented rule-conflict and lifecycle-governance challenges.The paper reports a concrete rule conflict and its resolution, governance questions, and threats to empirical validity.Source: B. Match and Contribution · p. 6
  • 66% of observed PR review comments concerned architecture, API design, or performance, while 14% concerned mechanical correctness during the deployment window.Previously corrected error classes were suppressed within that window. Accumulated rules also serve as a transferable onboarding artifact, giving new team members access to organizational review history.Source: B. Match and Contribution · p. 6

A. Comparison Framework

  • Table X structures the related-work comparison across key dimensions.The supplied passage identifies the comparison table but provides no cell values or rankings.Source: A. Comparison Framework · p. 6

B. Reflexion: Verbal Reinforcement Within Sessions

  • 91% pass@1 on HumanEval is reported for Reflexion, which stores verbal reflections on task feedback in episodic memory.The paper contrasts Reflexion’s self-generated, episode-bound feedback with human-accepted rules loaded across subsequent sessions, potentially using different models or agent interfaces. It treats the mechanisms as complementary while distinguishing isolated-problem pass rates from error-class suppression across diverse production tasks.Source: B. Reflexion: Verbal Reinforcement… · p. 6

C. ExpeL: Experiential Learning Across Tasks

  • Human-validated rules differ from ExpeL’s autonomous insights through expert-review provenance and transfer across fundamentally different task types.ExpeL autonomously gathers experiences and extracts natural-language insights, transferring within the same task type. The paper argues that human validation is essential because incorrect rules loaded as authoritative context could amplify errors across sessions.Source: C. ExpeL: Experiential Learning Across… · p. 6

D. Voyager: Persistent Skill Libraries … H. Memory-Augmented LLM Systems

The framework distinguishes persistent, declarative behavioral rules from executable skill libraries, weight-trained review models, single-context self-improvement, and issue-resolution benchmarks. Its memory consists of version-controlled, human-readable Markdown rules.

D. Voyager: Persistent Skill Libraries

  • Voyager [15] stores executable Minecraft skills, whereas this framework stores declarative natural-language constraints; both use persistent, version-controlled knowledge to compound capabilities.Voyager's skill library consists of executable code functions.Source: D. Voyager: Persistent Skill Libraries · p. 6

E. Pre-trained Code Review Models

  • Unlike pre-trained review models,, this framework injects rules through context, accumulates knowledge in real time, and captures organization-specific conventions.The compared models fine-tune weights, freeze knowledge at training time, and generalize across public repositories rather than capture conventions invisible in public codebases.Source: E. Pre-trained Code Review Models · p. 6

F. SWE-bench Agents

  • 20–40% of SWE-bench Lite issues are resolved by state-of-the-art agents; SWE-bench and agent implementations [16],, [20] evaluate isolated GitHub issue resolution.This is background benchmark performance, not a measured result for the proposed framework.Source: F. SWE-bench Agents · p. 7
  • The framework targets known-mistake avoidance and behavioral consistency over time, a dimension the authors say existing benchmarks do not evaluate.SWE-bench instead asks whether an agent can solve an issue.Source: F. SWE-bench Agents · p. 7

G. Self-Taught Optimizer, Self-Refine, and Self-Debugging

  • Unlike STOP, Self-Refine, and Self-Debugging [22], which operate within one execution context, this framework retains improvements permanently.STOP recursively improves scaffolding code; Self-Refine iterates using self-generated critique; Self-Debugging [22] uses rubber-duck-style explanation.Source: G. Self-Taught Optimizer, Self-Refine,… · p. 7

H. Memory-Augmented LLM Systems

  • Compared with MemoryBank and related memory systems, the framework uses a simpler store: version-controlled Markdown rules that are human-readable and auditable.Rules reside in plain-text files.Source: H. Memory-Augmented LLM Systems · p. 7

I. Personal AI Assistants with Persistent Memory … A. Threats to Validity

The framework turns accepted code review feedback into shared behavioral constraints governed by six design principles. Its evidence remains preliminary, with limited controls, statistical power, deployment diversity, and long-term observation, alongside unresolved scaling and review-quality risks.

I. Personal AI Assistants with Persistent Memory

  • Unlike OpenClaw, which remembers conversational facts for individual users, this framework derives team-level declarative constraints from accepted code review feedback to prevent error classes.OpenClaw provides persistent memory and skill libraries for personal AI assistants.Source: §I · p. 7

VII. DESIGN PRINCIPLES

  • 0.60 to 0.78 was the specificity ratio increase; six principles emphasize monotonic growth, specificity, origin tracking, tool-agnostic encoding, validated growth, and shared ownership.Concrete constraints outperform abstract guidance; rules are refined but never removed, and trace to review comments or production events. Structured Markdown transferred across 2 platforms; additions undergo automated validation and PR-based changes in a shared repository.Source: §VII · p. 7

VIII. LIMITATIONS AND THREATS TO VALIDITY

  • ∼6,250 tokens currently fit context limits, but unbounded rule growth and multi-team governance remain unresolved scaling constraints.Larger rule sets may require hierarchical organization or summarization; multiple teams need hierarchical or namespaced rules and explicit conflict-resolution policies to avoid fragmentation or contradictions. One conflict required manual identification, motivating automated conflict detection.Source: §VIII · p. 7
  • Adoption requires accepted written review feedback, engineers’ time to codify it, and agent interfaces that load and respect project-level instructions.Missing any prerequisite can starve the feedback loop or leave its rules ignored. The authors expect strongest adoption in mid- to large-sized engineering organizations practicing peer review on every change.Source: §VIII · p. 7
  • 74 post-rule exposures across 9 error classes, 36 PRs across 6 repositories, and 11 sessions provide preliminary evidence without causal proof or formal statistical-significance claims.Observed effects included no recurrences within the window and a shift toward design-level review comments. There was no parallel control group or paired ablation against static prompt engineering or a no-rule baseline on the same task stream.Source: §VIII · pp. 7–8

A. Threats to Validity

  • One organization’s typed-language deployment with strong framework conventions limits generalizability to other codebases, languages, and less consistent framework usage.Weaker compile-time constraints or inconsistent framework usage may change the distribution of review comments and reduce benefits from rule-based suppression.Source: A. Threats to Validity · p. 8
  • Rule quality depends on human reviewers: incorrect rules amplify errors, while noisy review cultures can corrupt the rule set faster than validation catches problems.Source: A. Threats to Validity · p. 8
  • Four weeks and 11 sessions cannot establish long-term growth dynamics, and behavior when rules saturate the available context window remains unobserved.Source: A. Threats to Validity · p. 8

IX. THE MISSING BENCHMARK … Future Research Directions

Persistent, version-controlled rules turn human review feedback into cross-session guidance, with no observed recurrences in tracked error classes during the deployment’s observation window. The section outlines a temporal benchmark, incremental enterprise adoption, and further research on effectiveness, automation, and governance.

IX. THE MISSING BENCHMARK

  • The proposed benchmark tests whether corrections persist across sessions, addressing behavioral consistency over time rather than static capability alone.It combines a curated review-derived rule corpus, seed tasks triggering prohibited patterns, and task sequences testing correction persistence across session boundaries. This temporal dimension would complement SWE-bench, HumanEval, and CodeReview benchmarks.Source: §IX · p. 8

X. CONCLUSION

  • Persistent, version-controlled rules codify human review feedback, monotonically expanding self-detectable error classes without weight updates or model-specific infrastructure.The rule set grew from 5 to 18 behavioral rules, alongside 15+ code standards and a 15-item self-review checklist. No fine-tuning or changes to existing LLM architectures are required.Source: §X · p. 8
  • 74 cumulative post-rule session-exposures across 9 tracked error classes included no observed recurrences during the observation window.Production deployment covered 35+ microservices over 11 recorded sessions. This is an observational result, with limitations explicitly acknowledged.Source: §X · p. 8
  • 66% of review comments concerned architecture/API/performance versus 14% mechanical correctness, reflecting a shift toward design-level concerns.Rules transferred across boundaries in 60% of observed events.Source: §X · p. 8

Operationalizing the Framework in an Enterprise Setting

  • Enterprise adoption can proceed incrementally within existing toolchains through shared instructions, review-driven rule promotion, automated validation, and pull-request governance.A version-controlled instruction file contains behavioral rules, language-specific standards, and a self-review checklist consumed by every agent interface. Promote accepted, generalizable review comments into rules in the same PR or a follow-up, validate formatting and schema through CI or pre-commit hooks, and review instruction changes like code.Source: Operationalizing the Framework in an… · p. 8

Future Research Directions

  • Future evaluation should compare rule-loading agents against rule-free baselines and replicate across organizations to test effectiveness and boundary conditions.The proposed A/B study uses the same incoming task stream and preregistered review-comment volume, defect escape rate, and reviewer time-on-task metrics. Replication should vary programming languages, codebase sizes, and review cultures, alongside a cross-session behavioral-consistency benchmark.Source: Future Research Directions · p. 8
  • Future tooling should propose rules from similar review comments, detect conflicts before merging, and support multi-team rule composition with provenance tracking.Governance models should prevent silent contradictions and preserve provenance when rules move from team scope to organizationwide scope.Source: Future Research Directions · p. 9

Related papers

Loading 2607.13091v1…