Beyond AI Slop: A Verifiable Agent-Centric Development Cycle

AI coding has crossed an important threshold. The interesting question is no longer whether a model can produce a useful function, test, or pull request. It is whether an engineering system can absorb machine-generated change without losing correctness, security, maintainability, and architectural coherence.

That distinction matters because code generation and software engineering are not the same activity.

A coding agent can produce code that compiles, passes a narrow test, and appears reasonable in review. Yet the same change can still violate an architectural boundary, duplicate an existing capability, mishandle an edge case, introduce a vulnerable dependency, or make the next change harder. The output may be locally correct while the system becomes globally worse.

This is the more useful meaning of AI slop in software development: not merely ugly code, but plausible code produced faster than an organization can establish trust in it. The same underlying failure appears outside engineering when professional reports contain hallucinated facts or legal submissions contain invented citations. Code feels different because parts of it can be compiled, tested, analyzed, and—in narrow cases—formally proved. But those mechanisms do not automatically prove that a large software system satisfies every business, architectural, security, and operational expectation.

The answer is not to abandon coding agents. It is to redesign the development loop around them.

The bottleneck has moved from generation to verification

Traditional software delivery assumes a human-paced stream of relatively small changes. A developer understands the intent, writes the code, runs tests, and submits a pull request that another human can inspect.

Agents change that operating model. They can work asynchronously across many files, take multiple tool-driven steps, and return a large change set after a long reasoning loop. The cost of producing code falls, but the cost of understanding and validating the resulting change does not fall automatically.

Think of it as widening one part of a pipeline:

The evidence is nuanced, but the direction is clear. Sonar’s 2026 developer survey found that 82% of respondents believed AI helped them code faster, while 96% did not fully trust AI-generated code to be functionally correct. Only 48% said they always checked AI-assisted code before committing it. The survey was vendor-sponsored and self-reported, so it should not be treated as a universal benchmark, but it captures the central tension: adoption is moving faster than confidence and verification discipline. (Sonar, State of Code Developer Survey 2026)

Capability is also improving rapidly. METR measures an agent’s task-completion time horizon: the duration of a task, expressed in estimated human-expert time, at which an agent reaches a specified probability of success. Its evaluations show frontier agents handling progressively longer software-oriented tasks. But METR explicitly warns that these are mostly clean, self-contained tasks with clear scoring criteria—not proof that an agent can autonomously perform every real-world engineering task of similar duration. (METR, Task-Completion Time Horizons of Frontier AI Models)

That caveat is crucial. Longer autonomous runs increase both opportunity and risk. A small mistaken assumption near the beginning of a run can propagate through design, implementation, tests, and documentation before a human sees the result.

Why functional correctness is not enough

Enterprise-grade code must satisfy several kinds of correctness at once:

• Functional correctness: Does the code produce the expected result?
• Contextual correctness: Does it use the right internal APIs, patterns, libraries, and conventions?
• Architectural correctness: Does it preserve intended boundaries and dependency direction?
• Security correctness: Does it avoid unsafe data flows, exposed secrets, vulnerable dependencies, and insecure defaults?
• Operational correctness: Does it behave properly under failure, concurrency, scale, and observability requirements?
• Evolutionary correctness: Will the code remain understandable and changeable after the original task is finished?

Most prompts describe the first item. Production systems depend on all six.

The keynote behind this article described Sonar benchmarking in which coding models were asked to solve more than 4,000 problems and were then evaluated not only for functional correctness, but also for complexity, bugs, and security issues. The speaker’s central observation was that strong functional performance can coexist with variable complexity and residual reliability or security findings. Because public methodology and complete results were not supplied with the transcript, this should be treated as Sonar’s reported internal benchmarking, not as an independently reproducible industry ranking.

This also explains the keynote’s language about model “bias,” “character,” or “personality.” Different models and scaffolds can exhibit different recurring failure patterns. The practical conclusion is not to anthropomorphize them, but to avoid relying on one probabilistic system as both author and sole judge of its own work.

This creates a predictable failure mode: an agent optimizes for the visible acceptance criteria while silently violating constraints that were never supplied or checked. The problem is not necessarily that the model is careless. The development environment has given it an incomplete definition of success.

AC/DC: a control system around code generation

The Agent-Centric Development Cycle (AC/DC) is a framework introduced by Sonar for reorganizing software delivery around agent-generated change. It should be understood as a vendor-originated architectural model—not an industry standard—but its central idea is broadly useful: generation must be surrounded by a continuous control loop. (Sonar, The Future Is AC/DC)

Sonar positioned this framework as an answer to a specific enterprise problem: organizations usually have existing codebases containing millions of lines, legacy dependencies, accumulated debt, and architecture known partly through tribal knowledge. In that environment, verification cannot remain an old-style review step attached after a long agent run. It has to become part of the system that drives the run.

The model consists of Generate at the center, surrounded by three disciplines:

1. Guide the agent with relevant context and explicit constraints.
2. Verify its output using independent, layered evidence.
3. Solve detected problems, retest the repairs, and feed useful lessons into the next iteration.

A helpful mental model is an industrial robot inside a controlled work cell. The robot supplies speed and repeatability. The cell supplies boundaries, sensors, stop conditions, and quality inspection. Removing the cell does not make the robot more autonomous; it makes the overall system less dependable.

1. Guide: define the playing field before generation

The cheapest defect is the one the agent never creates.

Guidance is more than attaching a repository and writing a long prompt. The agent needs a task-specific view of both the current system and the allowed solution space.

Context: what the agent needs to know

Useful context may include:

• the task specification and acceptance criteria;
• relevant modules, symbols, interfaces, and data contracts;
• current and intended architecture;
• examples of approved patterns;
• test conventions and expected non-functional behavior;
• recent design decisions that affect the task.

For a large repository, dumping the entire codebase into the context window is not a strategy. Too little context leaves the agent guessing; too much can bury the important signals. The goal is task-relevant retrieval: provide the smallest set of evidence that lets the agent navigate the change correctly.

A semantic code index, architecture model, dependency graph, repository instructions, and targeted symbol retrieval can act as the agent’s map. The map does not replace the territory, but it reduces blind exploration. The keynote connected this idea to Sonar Vortex, announced around the event as a product for bringing context and verification into agent workflows. That product reference is useful as an example of the pattern, but the architectural principle is product-agnostic.

Constraints: what the agent must not violate

Constraints turn implicit team knowledge into machine-checkable boundaries. Examples include:

• approved and prohibited dependencies;
• supported runtime and language versions;
• required API and authentication patterns;
• architectural dependency rules;
• data-handling restrictions;
• performance budgets;
• minimum test expectations;
• files or modules the agent may not modify.

Constraints must also describe the intended architecture, not merely document the current one. An agent that perfectly imitates today’s structure may preserve exactly the coupling or obsolete pattern the organization is trying to remove. Guidance should therefore separate “this is how the system works now” from “this is the direction in which new changes must move.”

The strongest constraints are executable. A sentence saying “preserve the layered architecture” is useful; a dependency rule that fails the build when the agent crosses a forbidden boundary is stronger.

2. Verify: require evidence, not confidence

An agent saying “the implementation is complete” is not verification. It is a claim made by the same system that produced the change.

A more robust design uses independent and diverse verification signals. Different layers catch different classes of failure:

The layers are complementary. Deterministic analysis is repeatable and explainable, but limited to rules it can express. Agentic review can reason about intent and compare behavior with natural-language requirements, but it is probabilistic and can miss defects or invent concerns. Tests provide executable evidence, but only for the behaviors they cover.

This is why “use another model to review the first model” is not enough. Model diversity may reduce shared failure modes, but it does not create certainty. Agentic review should be grounded in deterministic findings, tests, architecture data, and the original acceptance criteria.

Zero trust is a workflow principle, not a slogan

In this context, zero trust means that code is not accepted because it came from a capable model, produced a persuasive explanation, or passed one happy-path test. Every change must earn trust through evidence appropriate to its risk.

That also applies to generated tests. An agent can write an implementation and a test that encode the same misunderstanding. Independent requirements, contract tests, mutation testing, property-based tests, or separate test-generation passes can reduce this correlated-error problem.

3. Solve: repair without creating a second verification gap

Verification creates findings. The Solve stage turns those findings into validated changes.

A remediation agent can:

1. read the specific finding and supporting evidence;
2. identify the affected code and likely root cause;
3. propose the smallest safe repair;
4. apply the change in an isolated environment;
5. rerun the relevant checks;
6. stop when the issue is resolved—or escalate when it cannot establish confidence.

The important word is validated. A fix generated by an agent is still generated code and must pass through the same trust machinery. Otherwise, remediation simply moves the verification gap one step downstream.

Solve also has a broader meaning: keep the codebase legible enough for future agents and humans to reason about. High complexity, duplicated logic, dead code, and unclear boundaries increase the search space for every subsequent task. Clean code is therefore not cosmetic housekeeping; it is part of the context infrastructure for agentic development.

Two loops, not one giant pull request

The fuller keynote described three operational loops: an agentic loop, a CI verification loop, and a code-maintenance loop. Sonar’s later published AC/DC material also uses the simpler language of an inner loop and an outer loop. These views are compatible if we treat the first two as execution-time verification and the third as repository health over time. This is a stronger mental model than waiting for one enormous pull request and reviewing it at the end.

The inner loop: fast feedback inside the agent’s workspace

The inner loop runs while the agent is working in a sandbox or isolated branch:

Retrieve context → plan → change a small unit → verify → repair → continue

Checks should be fast, relevant, and high-signal. The purpose is to catch a wrong turn before it spreads across the change set. Examples include compiling changed files, running targeted tests, checking new dependencies, scanning modified code, and comparing the implementation with the active plan.

The outer loop: independent validation before acceptance

The outer loop begins when the agent believes the task is complete. In the keynote’s three-loop vocabulary, this is largely the CI verification loop: the pull request is reviewed at machine speed using deterministic and agentic analysis, followed by evaluations and quality gates.

Review final diff → run full quality gates → execute broader tests
→ validate architecture and requirements → approve, remediate, or reject

This loop should evaluate the complete outcome, including non-functional requirements. It is also where accountable human review remains important, especially for high-impact changes, ambiguous trade-offs, security-sensitive paths, or modifications that are difficult to reverse.

Continuous maintenance: preserve the environment agents depend on

The source article described a third, repository-level maintenance loop. It is useful to retain that idea, but it should not be confused with the two execution loops in Sonar’s formal model.

At the repository level, teams can continuously monitor:

• complexity and duplication trends;
• dependency and vulnerability exposure;
• architecture drift;
• flaky or low-value tests;
• unresolved quality findings;
• generated-code hotspots;
• recurring agent failure patterns.

The purpose is not to chase a perfect codebase. It is to prevent the development environment from becoming increasingly difficult for both humans and agents to understand.

What the evidence does—and does not—prove

Claims about AI coding productivity require care. Some controlled studies show meaningful gains on bounded tasks, while field studies can show smaller, mixed, or even negative effects depending on the developers, repositories, tools, and measurement method.

For example, a 2026 study of 806 open-source projects adopting Cursor reported a sharp initial rise in code output followed by a return toward baseline, alongside increases in static-analysis warnings and complexity. That is relevant evidence that generation speed can outrun quality practices, but it should not be generalized into a universal “AI gains disappear after 90 days” law. Repository selection, adoption behavior, study period, and output-based productivity measures all affect interpretation. (Gorilla Logic summary and link to the CMU study, Speed at the Cost of Quality)

The keynote also presented three directional outcome claims from Sonar’s testing or customer observations:

• more than 30% lower token consumption when agents received better context and constraints for a given problem;
• 44% fewer AI-derived production outages among partners and customers using multi-layered verification;
• up to 92% fewer issues in a large-bank test when Guide, Verify, and Solve were repeatedly applied inside agentic loops.

These figures are part of the source knowledge and are therefore worth recording, but they require strict qualification. The transcript does not provide sample sizes, baselines, study design, confidence intervals, workload definitions, or a public primary report from which the results can be independently reproduced. They should be read as vendor-reported, environment-specific observations, not universal expected outcomes. The 92% figure was also described as a compounded result across repeated loops—not a claim that every individual pass was 92% better.

The underlying mechanism is still plausible without depending on the exact percentages: better navigation can reduce unnecessary model work; independent verification can catch defects before production; and repeated repair-and-retest cycles can reduce the remaining issue count. Teams should measure those effects in their own repositories rather than importing headline numbers into a business case.

The defensible conclusion is simpler:

A practical adoption sequence

AC/DC does not require replacing an entire delivery platform. It can be introduced incrementally.

1. Define what “acceptable” means

Document functional and non-functional acceptance criteria. Turn critical standards into tests, analysis rules, policy checks, and architecture constraints where possible.

2. Start with changed-code verification

Apply quality gates to code modified by the agent. This keeps feedback focused and avoids blocking adoption on an unrelated historical backlog.

3. Give the agent scoped context

Provide repository instructions, relevant architecture, approved patterns, and task-specific retrieval. Measure whether the agent still searches excessively, edits unrelated files, or repeats failed approaches.

4. Move fast checks into the inner loop

Let the agent compile, test, and scan each meaningful increment inside an isolated environment. Do not wait until pull-request time to reveal basic failures. Give the agent the finding, let it repair the problem, and immediately rerun the check so that verification actively shapes generation rather than merely scoring the finished output.

5. Keep the outer loop independent

Run full validation outside the generating agent’s immediate reasoning loop. Preserve auditability: record the requested outcome, context supplied, files changed, tools invoked, findings produced, repairs applied, and final evidence.

6. Automate repair selectively

Begin with narrow, well-understood findings. Require retesting and constrain the repair agent’s scope. Escalate ambiguous or high-impact changes to a human.

7. Measure outcomes, not output volume

Lines of code and commit counts are weak proxies for value. Better signals include escaped defects, change-failure rate, review effort, rework, lead time, architecture violations, security findings, and the percentage of agent tasks that complete with acceptable evidence.

The compounding payoff

The central promise of an agent-centric development cycle is not that verification makes every generated line correct. No realistic process can guarantee that.

The payoff is that quality becomes part of the agent’s control loop rather than a debt assigned to future humans.

Good guidance reduces avoidable wandering. Inner-loop checks prevent early mistakes from compounding. Independent verification changes “the agent says it works” into a body of evidence. Validated remediation closes the loop. Continuous maintenance improves the environment in which the next task will run.

That creates a healthier flywheel:

Cleaner system
    ↓
More relevant context
    ↓
Better-scoped generation
    ↓
Faster, stronger verification
    ↓
Safer remediation
    ↓
Cleaner system

AI slop is not an unavoidable property of machine-generated code. It is often a symptom of a development system optimized for generation but not for trust.

The durable advantage will not come from the team whose agent writes the most code. It will come from the team that can guide, verify, and improve machine-generated change at the same speed it is produced.

References

• Tariq Shaukat, Sonar CEO. Conference keynote transcript supplied as the original knowledge source for this article. Claims described above as keynote- or vendor-reported originate from this transcript.
• METR. Task-Completion Time Horizons of Frontier AI Models. Updated May 8, 2026.
• Sonar. The Future Is AC/DC: The Agent Centric Development Cycle. March 2, 2026.
• Sonar. Agent Centric Development Cycle.
• Sonar. State of Code Developer Survey 2026.
• Carnegie Mellon University research, linked via Gorilla Logic. Speed at the Cost of Quality: The Impact of AI Coding Assistants on Software Development.