Agentic Development

Continuous AI and the self-merging repository

Continuous AI is the practice of running AI-assisted improvement as an ongoing software delivery capability, alongside continuous integration and continuous deployment. Instead of treating a coding agent as a one-off productivity tool, teams give it structured work, specifications and test gate.

MMichael SwindellSeptember 5, 202618 min read

Continuous AI is the practice of running AI-assisted improvement as an ongoing software delivery capability, alongside continuous integration and continuous deployment. Instead of treating a coding agent as a one-off productivity tool, teams give it structured work, durable specifications, test gates, and feedback from production. The goal is not blind automation or automatic releases. It is a repository that can continuously propose, implement, test, review, and sometimes merge small changes under rules engineers trust. An agent-first control plane such as Levr can centralize the issues, acceptance criteria, tests, approvals, and activity history needed to make that workflow observable, embodying what agentic software development actually means in practice.

At a Glance

Self-merging pull requests only work when the delivery system has stronger rules than the agent prompt.

Third pillar: Continuous AI extends CI/CD by making AI-driven improvement a recurring delivery process.
Safety model: Automated pull request merging should be conditioned on explicit, independently verifiable quality gates.
Source of truth: Tests must represent intended behavior and should not be casually changed to make an implementation pass.
Operating model: When an agent fails, improve the specifications, tools, tests, or workflow that led to the failure.
Context layer: Shared organizational knowledge helps agents and humans retrieve decisions, standards, and delivery context without hunting through files.

What is continuous AI in software delivery?

Continuous AI applies the operating principles of CI/CD to AI-assisted engineering work. It creates a repeatable loop where agents receive structured context, make bounded changes, run validation, and feed outcomes back into the delivery system so future work becomes more reliable rather than merely faster.

CI established that code should be integrated and validated continuously. CD extended that idea toward repeatable release processes. Continuous AI adds a third concern: continuously improving code, documentation, specifications, operational knowledge, and the systems that guide coding agents.

This differs from asking a coding agent to complete an isolated task in a local editor. Individual use can be valuable, but it makes the engineer the bottleneck for requirements, review, context transfer, quality judgment, and coordination. A continuous model moves more of that work into shared, inspectable systems.

Examples include:

Agents that identify low-risk repository improvements and open pull requests.
Automated documentation updates linked to implementation changes.
Reusable specifications that define behavior before code changes begin.
Test suites that validate acceptance criteria rather than only implementation details.
Observability signals that reveal regressions and guide improvements to the delivery workflow.

The important shift is architectural. The agent is not the system. The system includes the work definition, repository context, tools, tests, CI/CD checks, review policy, and production feedback that shape the agent's actions.

Why is individual coding-agent productivity not enough?

Individual productivity is not enough because software delivery requires coordinated decisions about priorities, quality, releases, and operational risk. If all context flows through one engineer, agent output may increase while planning drift, incomplete validation, and unclear accountability increase with it.

A developer working with an agent still has to decide what matters, translate ambiguous requests, check the result, reconcile it with adjacent work, and determine whether it is safe to ship. That is manageable for a few tasks. It becomes harder when several people and several coding agents work against the same codebase.

Continuous AI addresses this by making project context a shared asset rather than private prompt history. A useful shared context includes:

Clear issue definitions and expected outcomes.
Structured acceptance criteria.
Relevant prior decisions and constraints.
Linked tests and test results.
Pull request, commit, and CI/CD history.
Human approvals and exception records.

This does not eliminate engineering judgment. It gives that judgment a durable place to live. Agents can then work from the same operational objects as humans, while engineering managers can inspect progress without relying on status updates reconstructed after the fact.

How can a pull request merge itself safely?

A pull request can merge itself safely only when a repository enforces clear merge conditions that the agent cannot bypass. Required checks, review rules, protected branches, test validation, and release gates should determine eligibility, not an agent's confidence in its own output.

A self-merging pull request is best understood as an automated decision made by a controlled pipeline, helping teams determine when it's actually safe for an AI agent to merge its own code. The pipeline can allow a merge only after required signals are present and passing. The agent may open the pull request, respond to feedback, make a correction, and request another validation cycle. It should not get to declare its own work complete.

GitHub supports this pattern through protected branches and required status checks. Its documentation explains how repositories can require selected checks to pass before changes are merged into protected branches. See GitHub's protected branch documentation and GitHub's automatic merge documentation for the available controls.

A practical gated workflow may include five distinct checks:

Work definition gate: The issue has a specific outcome and acceptance criteria.
Implementation gate: The change is scoped, traceable, and attached to the relevant issue.
Automated validation gate: Unit, integration, and other relevant checks pass in CI.
Review gate: Required human or policy review is complete, including requested changes.
Release validation gate: Post-merge user acceptance testing or another deployment safeguard confirms the change is safe to release.

These gates can be fully automated, partly automated, or human-controlled depending on change risk. A documentation correction and a database migration should not carry the same autonomy policy.

Why should tests be the source of truth for agent-written code?

Tests should be the source of truth because they encode the expected behavior used to judge a change. If an agent can alter tests simply to make its code pass, the validation layer stops being independent and cannot reliably distinguish a fixed implementation from a weakened requirement.

For a self-merging workflow, test integrity matters as much as test coverage. An agent that changes an assertion, removes an edge case, or updates a snapshot without understanding the business reason can create a clean CI run that validates the wrong behavior.

That does not mean tests are immutable. Product requirements change, and tests must change with them. The difference is whether the test change is backed by an explicit decision and acceptance criteria. A reliable workflow asks:

What user-visible or system behavior changed?
Which requirement authorizes the new behavior?
Does the test change clarify the requirement or hide a regression?
Is the implementation changing to satisfy a stable contract, or is the contract legitimately changing?
Does the pull request make that distinction easy to review?

Tests can be especially effective when linked directly to acceptance criteria. That creates a visible chain from requested outcome to implementation evidence. In Levr, teams can keep tests, runs, results, and issues in one shared graph, making it easier to see which evidence supports each requirement and which failed checks produced a defect.

Separate user acceptance testing can provide another safeguard after merge. A merged change is not automatically a released change. If UAT detects a regression, the delivery pipeline should block release until the underlying problem is resolved.

Give coding agents context they can act on safely.

Levr keeps issues, acceptance criteria, tests, gates, and attributed agent activity connected, so your team can automate delivery steps without separating planning from proof.

Explore agent-first workflows with Levr

Why should teams fix the system instead of patching each agent mistake?

Teams should fix the system when agents repeatedly fail because the durable solution usually lies in better specifications, tools, tests, or feedback loops. Patching a single output may solve today's task, while improving the system reduces the chance of the same failure returning tomorrow.

When a coding agent produces an incorrect change, the natural reaction is to take over and repair the code. That may be appropriate for urgent incidents. But it does not answer the more useful engineering question: what allowed an ambiguous or unsafe outcome to reach this point?

Common system-level causes include incomplete requirements, hidden repository conventions, poorly scoped tool access, missing test cases, stale documentation, and insufficient observability. Each one can be improved in a reusable way.

Turn failures into reusable improvements

Missing requirement: Add structured acceptance criteria that define expected behavior and known constraints.
Repeated code-pattern failure: Add repository guidance, examples, linting, or a validation script.
Regression found after merge: Add or strengthen a test that fails before the implementation is corrected.
Agent lacks context: Capture the relevant architecture decision, runbook, or prior incident lesson in shared knowledge.
Unsafe action path: Reduce permissions, introduce a sandbox, or add a human approval boundary.

This approach resembles good platform engineering. Build the environment that produces reliable work, then keep improving that environment. Coding agents make the feedback cycle more visible because they can repeat an error quickly and at scale.

Anthropic's Claude Code best practices similarly emphasizes clear project guidance, verification, and structured workflows. The model may change, but the underlying discipline remains familiar: explicit expectations and automated checks beat informal memory.

What does a practical continuous AI workflow look like?

A practical continuous AI workflow starts with explicit intent, gives agents only the context and permissions needed for a task, validates output through automated and human gates, then records results so the project system improves after every success, failure, and production signal.

Use the following operating loop as a starting point.

1. Define intent before execution

Write issues in terms of an observable outcome, constraints, and acceptance criteria. Avoid vague assignments such as “improve checkout.” Specify what should happen, where it applies, what must not change, and how success will be verified.

2. Provide bounded project context

Give the coding agent the relevant repository guidance, architectural constraints, linked work, and test expectations. Avoid dumping every available document into a prompt. More context is not always better. Relevant, maintained context is better.

3. Require verification before completion

Run the tests, static analysis, build steps, and security checks appropriate to the change. For higher-risk modifications, require review or explicit approval. Use CI/CD as the gatekeeper of merge eligibility.

4. Separate merge from release

A successful merge means repository checks passed. A release decision may need additional signals, including UAT, staged rollout checks, monitoring, or a release owner approval. Keep those decisions visible and traceable.

5. Feed outcomes back into the system

When a check fails or production exposes a regression, update the relevant test, specification, agent guidance, workflow gate, or observability rule. The goal is compounding improvement, not a growing pile of manual exceptions.

How should teams manage shared knowledge for coding agents?

Teams should manage shared knowledge as searchable, maintained operational context rather than a collection of disconnected files. Agents and engineers need to retrieve decisions, patterns, requirements, and current priorities in plain language while still being able to trace information to authoritative sources.

Knowledge systems are useful when they answer real delivery questions quickly. An engineer may need to retrieve a prior decision about CI/CD stages, find the rationale behind an architecture constraint, or understand whether a proposed change conflicts with planned work.

A useful company knowledge layer does not need to replace every document repository. It should reduce the cost of finding the right context when work begins. It can also support proactive research workflows, such as scheduled monitoring of selected technical topics and a daily briefing of relevant changes.

Be careful with automated research. Treat external content as input, not instruction. Summaries can inform backlog decisions, but they should not silently modify code, policy, or deployment behavior. Every external source has a different reliability level, and context can be stale, incomplete, or misleading.

How can Levr support continuous AI delivery?

Levr can support continuous AI delivery by making issues, acceptance criteria, test evidence, workflow gates, and agent activity part of the same project control plane. This keeps the work definition, implementation progress, and validation record connected as agents and humans collaborate.

One way to structure this workflow in Levr is:

Define intent: Create an issue with clear acceptance criteria, scope, and linked context.
Assign or route work: Let a coding agent pick up the task through MCP, with access to the same project object used by the team.
Verify the result: Connect tests and execution evidence to the issue, then use workflow states and quality gates to prevent premature completion.
Review and approve: Keep human checkpoints where risk warrants them, with a visible history of each action and decision.
Learn from outcomes: Use failures, blocked work, and test health to improve task definitions, agent guidance, and delivery practices.

Levr's agentic workflow is designed around this shared process rather than a separate prompt-driven side channel. Teams can mix Claude Code, Cursor, Codex, Copilot, and other MCP-capable tools while keeping work, tests, and accountability in the same project context.

See Every Merge Decision, Not Just the Diff

A self-merging repository is only as safe as the gates it can't see past. The Levr Dashboard shows every quality gate result, test outcome, and merge decision an agent makes in real time, so continuous AI stays a visible, auditable process instead of a black box merging code on its own.

Agentic Software Development | Control Plane | Manual & Automatic Verification Issue Tracking |Levr

Agents propose the merge; Levr's dashboard shows you exactly why it passed.

What mistakes make self-merging repositories unsafe?

Self-merging repositories become unsafe when teams automate merging before they establish trustworthy requirements, independent checks, and clear release boundaries. The most common failures come from weak test integrity, excessive agent permissions, ambiguous completion criteria, and treating merged code as automatically safe to deploy.

Using green CI as the only signal: A passing pipeline is meaningful only if the pipeline checks the behaviors that matter.
Letting agents edit tests without review: Test changes may be legitimate, but should be traceable to a changed requirement.
Giving agents broad credentials: A coding agent rarely needs unrestricted repository, infrastructure, or production access.
Skipping post-merge validation: Merge and release should remain distinct decisions when real user behavior can reveal regressions.
Keeping key context in private chats: If a requirement only exists in someone’s memory, the agent and the rest of the team cannot reliably act on it.
Measuring output instead of outcomes: Pull request count and lines changed are not substitutes for quality, reliability, or customer value.

Start with low-risk work, stable tests, and a narrow merge policy. Expand autonomy only as the team develops evidence that its system catches the failures it expects to see.

Technical Deep Dive FAQ

What is a self-merging repository?

A self-merging repository is a software repository where a pull request can be merged automatically after it satisfies predefined policy and validation conditions. The automation is not a substitute for review or testing. It is the final step of a controlled process that can require passing CI checks, approvals, branch protections, and other quality gates. A mature setup usually separates automatic merge from automatic release, so a merged change can still face staged deployment checks or user acceptance testing before it reaches production.

What is continuous AI?

Continuous AI is an engineering approach that treats AI-assisted work as an ongoing, governed delivery capability. It extends the habits of continuous integration and continuous deployment to coding agents, documentation agents, knowledge retrieval, and automated improvement workflows. Rather than relying on one engineer to manually coordinate every prompt and result, continuous AI uses structured context, reusable specifications, verification gates, and operational feedback. Its aim is to improve the system that produces software, not simply to increase the amount of code generated.

Can an AI coding agent safely auto-merge pull requests?

An AI coding agent can participate in safe automatic merging when repository policy, not the agent, determines whether a pull request qualifies. Require checks that run independently of the agent’s self-assessment, such as tests, builds, static analysis, branch protection rules, and required approvals. Limit the policy to low-risk change types first, and keep deployment behind separate controls. If failures frequently escape, pause expansion of autonomy and improve the relevant test suite, specification, or review gate before allowing more automated merges.

How many quality gates should an agentic CI/CD pipeline have?

There is no universal number because gates should reflect the risk and architecture of the change. A practical baseline includes work-definition validation, automated CI checks, code review or policy review, merge protection, and release validation. Some teams combine these steps, while others add security scanning, change-management approval, staging checks, or UAT. The goal is not to maximize gate count. It is to create independent evidence that a change meets its expected behavior and can be released without bypassing important safeguards.

Should coding agents be allowed to modify tests?

Coding agents can modify tests when the underlying requirement changes and the pull request makes that relationship explicit. They should not casually weaken tests, delete edge cases, or rewrite assertions simply to make a failing implementation pass. Treat test modifications as product or engineering-contract changes that require a rationale, review, and traceability to acceptance criteria. For sensitive workflows, require a separate approval for test changes or use policies that flag pull requests where both production logic and validation logic changed together.

What should be included in acceptance criteria for coding agents?

Acceptance criteria for coding agents should state the desired behavior, relevant user or system conditions, constraints, non-goals, and evidence required for completion. Include known edge cases, compatibility requirements, affected interfaces, and any security or performance boundaries that matter. Avoid instructions that describe only implementation preferences unless those preferences are required. A good criterion lets a reviewer and a test suite independently evaluate the outcome. It also prevents agents from filling gaps with assumptions that may be technically plausible but productively wrong.

How do you keep agent context from becoming stale?

Keep agent context current by linking it to maintained project objects, source-controlled guidance, test suites, and decision records rather than copying it into isolated prompts. Review repository instructions when architecture, conventions, or tooling changes. Remove superseded rules and preserve a visible record of decisions that still constrain current work. When a recurring mistake exposes missing or outdated context, update the shared source immediately. The goal is a small set of authoritative artifacts that agents can retrieve, not a large archive of conflicting documents.

What is the difference between auto-merge and continuous deployment?

Auto-merge is a repository action that integrates an approved pull request into a target branch once required conditions are met. Continuous deployment is a release practice where validated changes are automatically deployed to an environment, potentially including production. They can be connected, but they are not the same control. A team can auto-merge changes into the main branch while requiring staging validation, UAT, monitoring checks, or a human release approval before production deployment. Keeping the distinction clear reduces avoidable release risk.

How should engineering managers measure continuous AI performance?

Engineering managers should measure continuous AI through flow, quality, and control metrics rather than raw agent activity. Useful signals include issue cycle time, blocked-work duration, test pass trends, regression rates, reopened work, review load, deployment frequency, and the proportion of changes that clear gates without human rework. Also track attribution and exception patterns: which work types need intervention, which agents struggle with specific tasks, and which process improvements reduce recurrence. These measures reveal whether automation improves delivery or only increases throughput.

How can teams introduce self-merging pull requests gradually?

Introduce self-merging gradually by choosing narrow, reversible use cases with stable tests and low blast radius. Start with documentation, dependency updates, lint fixes, or well-specified maintenance tasks. Require all normal CI checks and retain human approval while measuring failure patterns. Next, allow automatic merge only for selected repositories or labels. Expand policy only after test integrity, release controls, and observability prove reliable. This staged approach creates evidence for more autonomy instead of assuming every type of change deserves the same level of trust.

Key Takeaways

Continuous AI is less about autonomous code generation than about building a delivery system that gives automation clear intent, hard boundaries, and feedback that compounds.

Reliable autonomy comes from process design, not prompt optimism.

Extend CI/CD: Treat continuous AI as a third discipline focused on persistent improvement across code, context, and workflow.
Protect the merge: Use independent CI checks, review policies, and branch protections to determine merge eligibility.
Preserve test integrity: Connect test changes to real requirement changes rather than letting validation bend around implementation.
Improve recurrence: When an agent gets work wrong, strengthen the specification, toolchain, or feedback loop that produced the error.
Share context: Keep issues, decisions, tests, and delivery evidence discoverable by both humans and coding agents.

The fastest repository is not the one that merges everything automatically. It is the one that can automate the right work while catching failure before customers do.