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

Aditya Aggarwal; Nahid Farhady Ghalaty

Source-linked AI summary

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

Aditya Aggarwal, Nahid Farhady Ghalaty

arXiv:2607.13091v1Jul 13, 2026cs.SEcs.AI

TL;DR

Coding agents lack a feedback loop that preserves human review corrections, while existing benchmarks do not measure behavioral consistency over time. This paper introduces persistent behavioral rules derived from accepted reviews and reports no recurrence of tracked error classes during deployment, with knowledge transferring across agent boundaries.

Problem
Existing coding agents lack a feedback loop that automatically strengthens future behavior from review outcomes, and benchmarks do not measure behavioral consistency over time.
Method
The framework converts accepted human review comments into persistent version-controlled rules, reinforced by self-review and loaded across subsequent sessions.
Results
0 recurrences were observed across 9 tracked error classes and 74 cumulative post-rule session exposures, while 60% of knowledge-transfer events crossed repository, tool, or task-type boundaries.
Takeaways & Limitations
The framework addresses persistent behavioral consistency across sessions, a dimension that existing coding benchmarks do not measure.
Takeaways & Limitations
Without a controlled baseline or paired ablation, the suppression and review-shift findings are initial empirical evidence rather than causal proof.

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 paper proposes accumulated behavioral rules as a closed-loop mechanism that converts accepted human review feedback into persistent, reusable constraints for coding agents. Unlike static prompting, retraining, or general memory systems, the framework targets known coding-agent failure modes while preserving human review for higher-order concerns.

A. Scope and Positioning: Unlike static prompt engineering, the instruction file evolves directly from review outcomes, with every new rule traceable to a specific accepted comment.This feedback loop is what makes the system self-improving rather than passively maintained.
I. INTRODUCTION: Accepted review comments become persistent self-review rules, creating a ratchet effect in which prevented error classes grow monotonically over time.The goal is zero avoidable review comments through repeated prevention of previously identified mistake classes.
I. INTRODUCTION: The framework implements operational memory through version-controlled instruction files rather than weight updates, making it model-agnostic, tool-agnostic, and immediately deployable.The shared artifact can be reused across models, tools, and team members.
I. INTRODUCTION: Across 11 recorded sessions, the study evaluates rule accumulation, error-class suppression, and knowledge transfer across code generation, PR review, refactoring, and incident investigation.The deployment environment is a production setting, and the reported sessions span heterogeneous coding-agent tasks.
I. INTRODUCTION: The contribution addresses persistent behavioral consistency across sessions, distinguishing it from experiential learning work such as Reflexion, ExpeL, Voyager [15] and code-review systems such as CodeReviewer and SWE-agent [16].Existing benchmarks do not measure this cross-session behavioral dimension.
A. Scope and Positioning: The framework is a persistent organizational memory mechanism whose content derives exclusively from accepted review outcomes and converts point corrections into class-level constraints.Its scope is coding-agent behavior within a defined codebase rather than unrestricted general-purpose memory.
A. Scope and Positioning: The system augments rather than replaces human review by eliminating known error classes, but it is not a proof of semantic correctness and cannot prevent all possible failures.It is explicitly not weight updating, model retraining, or reinforcement learning from human feedback (RLHF).

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

The framework uses a version-controlled structured instruction file loaded at every session to preserve behavioral guidance and expand self-review capability. Its human-readable rules implicitly follow a schema that traces review origins, links rules to checklist items, and enables future validation tooling.

II. FRAMEWORK ARCHITECTURE: Each accepted review comment becomes a persistent behavioral rule in a version-controlled instruction file, expanding the agent’s self-review capability across subsequent sessions.The closed-loop process is summarized in Fig. 1.
A. The Structured Instruction File: The instruction file is loaded as system context at the start of every coding-agent session and follows version-controlled Markdown conventions such as AGENTS.md or rules files.Its specific section names and contents are domain-dependent.
A. The Structured Instruction File: The deployment-specific file contains Behavioral Rules, Code Standards, a Self-Review Checklist, Anti-Patterns, and Workflow Rules.These sections cover operational guardrails, review-derived language standards, pre-submission checks, prohibited patterns with alternatives, and workflow constraints.
A. The Structured Instruction File: Behavioral Rules encode high-level operational guardrails, while Code Standards capture language-specific requirements derived from review feedback.Examples include approval before commits and template-based logging instead of string interpolation.
A. The Structured Instruction File: Anti-Patterns document prohibited generation patterns together with explanations and correct alternatives, complementing the file’s operational and coding guidance.The source also identifies Workflow Rules as a distinct file section.
B. Rule Representation: Each Markdown rule implicitly conforms to a structured schema containing fields such as ID, category, trigger origin, scope, constraint, rationale, validation failures, checklist mapping, date added, and review traceability.The supplied example links an architecture rule to a human PR reviewer, a self-review item, and a PR comment about missing SSRF-policy validation.
B. Rule Representation: The schema makes rule origins concrete by linking each rule to the review event that produced it.This provides explicit provenance for accumulated behavioral guidance.
B. Rule Representation: The schema maps rules to self-review checklist items and supports future tooling for conflict detection and rule-effectiveness scoring.This creates a verifiable bridge between the instruction file and the pre-submission check.

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

The framework turns accepted review feedback into persistent behavioral rules loaded across future sessions, while governance and workspace validation preserve rule quality as the instruction set grows. Rules capture recurring engineering mistakes and are maintained through refinement, deduplication, team arbitration, and schema checks.

C. The Feedback Loop: Accepted review comments identifying generalizable mistakes become new rules, and the updated instruction file is loaded in every subsequent session.The agent first performs a self-review, then human feedback drives rule additions rather than encoding one-off typos.
C. The Feedback Loop: The instruction file serves as organizational memory that persists across sessions, models, and tool boundaries.
D. Rule Lifecycle and Governance: Engineers promote comments to rules when they plausibly recur in different contexts, distinguishing generalizable mistakes from one-off issues.
D. Rule Lifecycle and Governance: Existing rules are sharpened in place when feedback reveals overbreadth or excessive narrowness, preserving the rule ID.
D. Rule Lifecycle and Governance: Periodic review lets specific rules subsume overlapping general rules, while pull-request review resolves conflicts through team arbitration.
E. Illustrative Rule Examples: Representative rules address resource lifetime management, structured logging, and Boolean guard correctness, including preventing caller disposal of factory-created HttpClient instances.
F. Workspace Validation as Reliability Mechanism: Automated session-start validation checks file frontmatter, instruction structure, knowledge freshness, scripts, and tool-server configurations before rule growth continues.These checks guard against malformed additions that could silently degrade the system.
F. Workspace Validation as Reliability Mechanism: Validation supports monotonic rule growth by checking every addition against a known-good schema.

G. Session Continuity … C. Knowledge Source Distribution

The framework preserves continuity through handoff and task-log artifacts while operating across a 35+ service microservices platform and multiple agent interfaces. During deployment, behavioral rules accumulated from four learning sources, with human reviewer feedback contributing the largest share at 39%.

G. Session Continuity: Session continuity combines a handoff file for in-progress work, pending reviews, and next actions with a chronological task log.Together, these artifacts preserve ongoing work context alongside accumulated behavioral rules.
A. Environment: The deployment covered 35+ microservices and 50,000+ lines of shared infrastructure code on managed container orchestration with a service mesh.Agents performed code generation, review, architecture investigation, incident response, and cross-service refactoring across multiple interfaces.
A. Environment: All participating agent interfaces read the same instruction file while supporting varied engineering activities across the deployed platform.This shared-file setup enabled the framework to operate across code generation, review, investigation, incident response, and refactoring workflows.
B. Rule Accumulation Over Time: The rule set grew over a multi-week deployment period, with its end-of-observation composition reported in Table I.The supplied passage identifies the temporal accumulation and table, but does not provide the table’s cell values.
C. Knowledge Source Distribution: Analysis of the first 18 accumulated behavioral rules identified four distinct learning sources, summarized in Table II.The reported source distribution frames rule accumulation as drawing on multiple kinds of experience rather than a single input.
C. Knowledge Source Distribution: Human reviewer feedback supplied 39% of the first 18 behavioral rules, making it the largest identified knowledge source.The paper presents this distribution as support for using human review as the highest-quality signal for rule generation.

D. Observed Effects … A. Experimental Setup

Across 11 working sessions on a 35+ service platform, accumulated rules suppressed observed recurrences, shifted review toward design, transferred across interfaces, and accelerated onboarding. The results also exposed one scope conflict, resolved by refining a rule, while supporting shared behavioral memory across specialized agents.

D. Observed Effects: 0% recurrence of ruled-against error classes was observed across 11 recorded sessions, under the deployment conditions and observation window.This indicates observed suppression rather than a permanent change to the underlying model.
D. Observed Effects: Reviewers spent less time on mechanical issues and more on architectural appropriateness and design trade-offs.
D. Observed Effects: New team members inherited the accumulated rule set immediately, bypassing the learning curve that originally produced it.
D. Observed Effects: Specific, actionable rules were followed more reliably than broad guidance as the rule set evolved.Early rules were broad, whereas later rules became precise.
E. Rule Conflicts: A Concrete Example: One genuine conflict between disposal rules was resolved by adding a scope qualifier to the general rule after verifying the correct framework behavior.The conflict involved IDisposable types and HttpClient instances created through IHttpClientFactory.
F. Multi-Interface Behavioral Transfer: Rules transferred across IDE-integrated and terminal-based agents because both consumed the same instruction file, despite differing strengths in analysis and execution.This supports using behavioral rule sets as shared memory for multi-agent architectures,.
A. Experimental Setup: The evaluation covered a 35+ service microservices platform with 13 custom agent definitions, 10 operational skills, 6 shared knowledge documents, 11 task-log entries, 2 committed instruction-file revisions, 4 memory documents, and 36 PR reviews across 6 repositories.Two agent interfaces consumed the same shared instruction file.

B. Rule Accumulation Dynamics … E. Knowledge Transfer Patterns

Across the observation period, the rule set grew rapidly before tapering, while tracked error classes showed zero observed recurrence after rule addition. Review comments shifted toward design-level concerns, and most documented learnings transferred across repository or tool boundaries.

B. Rule Accumulation Dynamics: The rule set followed a logarithmic accumulation curve, with rapid initial growth tapering as frequently encountered patterns became covered.Table III reports rule-set growth across the observation period.
B. Rule Accumulation Dynamics: The combined instruction file reached approximately 4,809 words (∼6,250 tokens), using less than 5% of a 128K-token context window.This size reflects the accumulated behavioral rules and associated instructions.
C. Error-Class Recurrence Analysis: 0 recurrences occurred across 9 tracked error classes and 74 cumulative post-rule session-exposures after rules were added.This observational result comes from a single deployment and does not establish a permanent guarantee.
C. Error-Class Recurrence Analysis: The recurrence analysis tracked 9 error classes over 74 cumulative post-rule session-exposures within one deployment.The reported window is bounded by the threats to validity discussed in Section VIII.
D. Review Comment Category Shift: 66% of review comments concerned architecture, API design, and performance, compared with 14% for mechanical correctness and style.The analysis covered 36 PR reviews across 6 repositories, using criteria adapted from prior code review studies,.
E. Knowledge Transfer Patterns: 60% of documented knowledge transfers (9/15) crossed repository or tool boundaries, supporting broad applicability of tool-agnostic encoding.The transfer taxonomy classified 15 documented review learnings.

F. Rule Specificity Evolution … A. Summary of Findings

The deployment shows that persistent behavioral rules become increasingly specific, remain compact, generalize across tasks and interfaces, and suppress recurrence of previously corrected errors without model updates.

F. Rule Specificity Evolution: The rule specificity ratio increased monotonically as concrete review comments produced specific rules and refined existing general rules.Table VII tracks linguistic specificity over time.
G. Multi-Layer Memory Architecture: Persistent memory totaled ∼4,809 words (∼6,250 tokens), consuming <5% of a 128K context window within a three-layer architecture.The framework evolved this three-layer memory architecture as its persistent representation.
H. Session Task Diversity: PR reviews and incident investigations contributed 39% of rules despite being non-generative tasks, demonstrating application beyond code generation.Table IX reports the session activity distribution.
A. Summary of Findings: The closed loop derived 18 behavioral rules, 15+ language-specific standards, and a 15-item self-review checklist from accepted human feedback.These artifacts were stored in version-controlled instruction files consumed by multiple agent surfaces without model-side changes.
A. Summary of Findings: 0 recurrences occurred across 9 tracked error classes and 74 post-rule session exposures during the four-week observation window.This observational result shows visible suppression without a controlled baseline and is not a statistical guarantee.
V. DISCUSSION: The framework’s suppression and transfer findings remain observational because deployment lacked a controlled baseline and covered a limited observation window.The suppression effect was visible within four weeks but does not constitute a statistical guarantee.
A. Summary of Findings: 60% of knowledge-transfer events (9/15) crossed repository, tool, or task-type boundaries, with rules taking effect across heterogeneous agent interfaces.Declarative natural-language constraints in plain Markdown enabled transfer without model-side changes.

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

The framework turns coding-agent behavior into a persistent, auditable engineering artifact governed through human review, while differing from experiential approaches through cross-session persistence, human validation, and transfer across task types. Its deployment suppresses recurring errors and shifts reviewer attention toward higher-level concerns, while acknowledging important empirical limitations.

B. Match and Contribution: The framework operationalizes opaque, nonreproducible coding agents within code review, making organizational engineering knowledge a first-class, auditable artifact and remaining vendor- and tool-agnostic.It integrates agent behavior into an existing engineering workflow rather than leaving knowledge as tacit session-specific context.
B. Match and Contribution: Every behavioral rule records its originating review event, responsible owner, pull request, and self-review-checklist position, creating an explicit governance model for agent behavior.These records make operational behavior auditable, reviewable, and manageable with established engineering practices.
B. Match and Contribution: The deployable artifact uses a structured instruction file with rule schema, lifecycle, validation, and feedback-loop mechanisms, requiring only Git, Markdown, pull-request review, and plain-text scripts.It requires no fine-tuning, model-specific tooling, or specialized memory backend, enabling reproduction with existing organizational infrastructure.
B. Match and Contribution: The reported deployment surfaces a real rule conflict, governance questions, and validity threats, with limitations including one team, one language, four weeks of observation, and no controlled baseline.These constraints bound interpretation of the empirical results rather than being hidden.
B. Match and Contribution: 66% of observed pull-request review comments addressed architecture, API design, or performance, while 14% concerned mechanical correctness, indicating that suppressed recurring errors freed attention for higher-level concerns.The accumulated rule set also serves as a transferable onboarding artifact that preserves organizational review history.
A. Comparison Framework: Table X structures the comparison across key dimensions, framing how the accumulated-rule framework differs from related experiential-learning and agent-review approaches.The comparison covers the framework’s persistence, feedback source, transfer scope, and operational properties as described in the surrounding subsections.
B. Reflexion: Verbal Reinforcement Within Sessions: Reflexion uses verbal reflection, episodic memory, and self-generated feedback within sessions, whereas accumulated rules persist across sessions, use human expert feedback, and target error-class suppression across diverse production tasks.The approaches are complementary: Reflexion supports within-session iteration, while accumulated rules prevent known mistakes from the start of later sessions.
C. ExpeL: Experiential Learning Across Tasks: ExpeL autonomously extracts experiences and transfers insights within one task type, whereas the framework uses human review to produce human-validated rules that transfer across fundamentally different task types.Human validation is necessary because authoritative rules loaded into every session could amplify errors if they contained hallucinated generalizations.

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

Prior work spans persistent executable-skill libraries, weight-based code-review models, isolated issue-solving benchmarks, single-context self-improvement, and persistent-memory systems. The framework instead accumulates auditable natural-language rules across sessions, targeting behavioral consistency and organization-specific conventions without changing model weights.

D. Voyager: Persistent Skill Libraries: The framework stores declarative natural-language constraints, whereas Voyager [15] stores executable code functions in an ever-growing skill library.Both approaches use persistent, version-controlled knowledge to support compounding capability growth.
E. Pre-trained Code Review Models: Pre-trained code-review models fine-tune weights and freeze knowledge at training time, while this framework injects rules through context and accumulates them in real time.The framework captures organization-specific conventions that may be invisible in public codebases, whereas those models generalize across public repositories.
F. SWE-bench Agents: SWE-bench agents [16] [20] resolve isolated GitHub issues, with state-of-the-art systems solving 20–40% of SWE-bench Lite issues.This benchmark evaluates issue-solving capability rather than persistent avoidance of known mistake classes.
F. SWE-bench Agents: The framework addresses a distinct evaluation dimension—behavioral consistency over time—and no current benchmark measures it.SWE-bench asks whether an agent can solve an issue; this framework asks whether it avoids known mistake classes.
G. Self-Taught Optimizer, Self-Refine, and Self-Debugging: STOP, Self-Refine, and Self-Debugging [22] improve scaffolding or outputs within a single execution context, whereas this framework captures improvements permanently.The cited methods use recursive scaffolding improvement, self-generated critique, or rubber-duck-style explanation, respectively.
H. Memory-Augmented LLM Systems: MemoryBank and related systems provide persistent LLM memory, while this framework uses simpler plain-text Markdown files that are version-controlled, human-readable, and auditable.The storage format makes accumulated rules directly inspectable and maintainable by collaborators.

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

The framework differs from personal-assistant memory systems through team-level, review-derived constraint injection, while its principles support validated, transferable rule growth. Evidence remains preliminary because deployment, language, reviewer quality, governance, context capacity, and statistical controls limit generalizability and causal interpretation.

I. Personal AI Assistants with Persistent Memory: Unlike OpenClaw, the framework derives team-level declarative constraints from accepted code-review feedback rather than storing facts from free-form, single-user conversations.Its purpose is preventing recurring error classes through persistent rule injection.
VII. DESIGN PRINCIPLES: Specificity, origin tracking, and monotonic rule growth are core principles, with specificity increasing from 0.60 to 0.78.Rules are added or refined rather than removed, concrete constraints are preferred, and each rule traces to a review comment or production event.
VII. DESIGN PRINCIPLES: Tool-agnostic Markdown, automated validation, and shared repository ownership support transfer across 2 platforms and PR-based rule governance.The encoding is intended to be readable by any LLM while each addition is checked for integrity.
VIII. LIMITATIONS AND THREATS TO VALIDITY: The current rule set is approximately 6,250 tokens, but continued growth may require hierarchical organization or summarization as context limits become binding.One rule conflict was encountered, and automated conflict detection could reduce reliance on manual identification.
VIII. LIMITATIONS AND THREATS TO VALIDITY: Scaling beyond one team remains an open governance problem because centralized rules may fragment across teams or accumulate unresolved contradictions.Multiple teams would require hierarchical or namespaced rule sets and policies for resolving cross-team conflicts.
VIII. LIMITATIONS AND THREATS TO VALIDITY: Without a parallel control group or paired ablation against static prompting or no rules, suppression and review-shift findings provide initial evidence rather than causal proof.A future A/B deployment would compare rule-loading and rule-free agents on the same incoming task queue.
VIII. LIMITATIONS AND THREATS TO VALIDITY: Adoption depends on sustained written review feedback, engineer effort to codify comments, and agent tooling that loads project-level instruction files.Missing any precondition can starve the feedback loop or prevent the agent from respecting the rule set.
A. Threats to Validity: Evidence is limited to 1 organization, a typed language, 4 weeks, 11 sessions, and small counts, so reviewer quality, language, deployment context, and long-term saturation constrain generalizability.The dataset includes 74 post-rule exposures across 9 error classes and 36 PRs across 6 repositories; no formal statistical significance claim is made.

IX. THE MISSING BENCHMARK … Future Research Directions

The framework turns human review feedback into persistent, version-controlled behavioral rules whose self-detection coverage grows monotonically across sessions. The paper proposes benchmarks, operational practices, and research directions for measuring, deploying, and extending this form of behavioral consistency.

IX. THE MISSING BENCHMARK: Existing coding benchmarks measure static capability but do not measure behavioral consistency over time or whether corrections survive session boundaries.The proposed benchmark would complement SWE-bench, HumanEval, and CodeReview benchmarks rather than replace them.
IX. THE MISSING BENCHMARK: The proposed benchmark combines a rule corpus, seed tasks that trigger ruled-against patterns, temporal task sequences, and cross-session evaluation of correction persistence.These components directly test whether earlier corrections remain effective on later tasks after session boundaries.
X. CONCLUSION: Across 35+ microservices and 11 recorded sessions, the rule set grew from 5 to 18 behavioral rules, 15+ code standards, and a 15-item self-review checklist.This production deployment also provides the empirical basis for the framework’s claimed improvement over time.
X. CONCLUSION: No recurrences occurred across 9 tracked error classes during 74 cumulative post-rule session-exposures, while review comments shifted toward design-level concerns and rules transferred across boundaries in 60% of observed events.The authors explicitly identify this as an observational result with limitations discussed elsewhere.
X. CONCLUSION: The framework’s central mechanism is a ratchet effect: persistent, version-controlled review rules monotonically expand the error classes the agent can self-detect.It combines human-sourced feedback with cross-session persistence without weight updates, fine-tuning, model-specific infrastructure, or architecture changes.
Operationalizing the Framework in an Enterprise Setting: Enterprise adoption can proceed incrementally by versioning project instructions, promoting generalizable review comments into rules, and connecting the file to existing agent surfaces.The practices are presented as requiring no change to the organization’s existing toolchain.
Future Research Directions: Future research should test causal effectiveness through controlled A/B studies, replicate across organizations and programming contexts, and establish pre-registered metrics for review and defect outcomes.The proposed studies target review-comment volume, defect escape rate, reviewer time-on-task, and the boundary conditions of the suppression effect.
Future Research Directions: Additional directions include automated rule proposal and conflict detection, plus multi-team governance with composable rule sets and provenance tracking across scopes.These mechanisms aim to prevent contradictory rules and preserve the origin of rules promoted from team-level to organization-wide use.