Evidence reviewed through 25 August 2026.
I use coding agents constantly, and I assume their work can be wrong. Those positions fit together perfectly well.
The more work I delegate, the more deliberate I become about requirements, tests, isolation, review and deployment. Those controls are what make the speed usable.
AI-assisted development is still software development. The change still enters a codebase, pulls dependencies, handles data, receives permissions and eventually runs somewhere. Customers do not care whether a vulnerable function was typed by a person or generated by a model. The organisation remains accountable for what it ships.
I avoid the phrase "vibe coding" because it tells us almost nothing about how the software was specified, tested or operated. This article is about engineering with agents, regardless of who typed the code.
Speed changes the risk model
A coding agent can produce a change faster than most people can review it. One developer can also supervise several agents at once. That creates a new imbalance: production capacity grows before review capacity does.
When I supervise several agents, each can inspect the repository, change files, run commands and prepare a pull request. That gives me a pool of parallel implementers. It does not give the organisation more review capacity or operational discipline.
In that high-throughput workflow, code generation stops being the main constraint. Attention becomes the constraint. The scarce work is understanding what changed, checking the assumptions and deciding whether the result should be allowed into production.
This is why generated lines and completed pull requests are weak productivity measures. Review, rework, incidents and value delivered all count. Producing ten times more code is no gain if the team spends the following month untangling it.
A March 2026 DORA synthesis, drawing on its 2025 report and a Q3 2025 survey of 1,110 Google engineers, describes AI as an amplifier. Higher adoption was associated with both greater delivery throughput and greater instability. Strong platforms and good tests become more valuable. Weak processes generate debt faster.
Understanding does not require typing every line
Some criticism of AI-generated code rests on a romantic idea of handwritten software. I do not find the distinction useful. Handwritten code can be careless, insecure and impossible to maintain. Generated code can be clear, tested and boring.
Provenance is worth recording, but provenance by itself is not a quality measure.
Understanding a change can rest on more than line-by-line reading. We build confidence through focused review, automated checks and observed behaviour. The depth should follow the risk. Authentication, permissions, migrations and sensitive data deserve close human attention. A generated fixture or mechanical refactor can rely more heavily on automated evidence.
What matters is that the team understands the intended behaviour, the important risks and the evidence supporting the change. "The agent wrote it" is not evidence. "All checks passed" is not enough on its own either.
The harness is where distrust becomes useful
A long prompt gives a model instructions. A harness gives it context and tools, maintains state and feeds results back into the next step.
The sandbox is related but different. A correctly configured sandbox provides operating-system, network and resource enforcement independently of model cooperation. Identity and access controls define what the agent can reach. CI and deployment policy decide what may leave the development environment.
I think of these shared controls as the engineering control plane. It covers identities and permissions, sandbox templates, release gates, provenance and audit. The harness governs how agents execute. The control plane governs shared authorisation, policy and promotion across executions.
This distinction matters because a model cannot be trusted to enforce its own limits. A prompt saying "never access production" is weaker than an identity with no production permission. An instruction saying "do not reveal secrets" is weaker than keeping those secrets outside the environment.
What the security results actually show
Security research on AI-generated code often ages badly because it compares one dated model and usage mode on a narrow task set. With security agents, the search strategy, validation and available budget also shape the result.
An August 2026 Aikido comparison is useful for illustrating this. On one private application containing 89 known vulnerabilities, Aikido reported finding 68 for $75. According to the same vendor-run comparison, Claude Security found 60 for $157 and Codex Security found 58 for $125. Aikido attributed the difference to its harness, which used smaller specialised models to explore more hypotheses and reserved expensive frontier reasoning for selected stages.
We use Aikido at ANA Healthcare, and what I have seen in practice gives me reason to take this result seriously. The comparison is consistent with the product's broader approach: combine several kinds of security analysis, add exploitability context and reduce the noise that reaches developers. It is a credible signal, not something I would dismiss merely because the vendor ran it.
The caveats define how far I am willing to take that signal. Aikido ran the benchmark on a private target while evaluating a product it sells. The repository, prompts and traces are not public. The post gives recall but not precision, false-positive effort or variation across repeated runs. Those gaps do not make the report untrustworthy. They mean we cannot reproduce the result or know how well it generalises. I would welcome independent tests that confirm it, narrow it or show where another approach wins.
My conclusion is cautiously optimistic. The comparison suggests that Aikido's harness can outperform larger frontier-agent approaches on this target, at a lower reported cost. It does not establish a lasting vendor ranking. What it supports more strongly is the broader point: security performance belongs to the model and harness together. Breadth, validation and cost allocation can materially affect results alongside model choice. Harness-Bench also found that capability should be reported for the model-and-harness configuration, although it did not evaluate vulnerability discovery.
Controls that scale with agents
The right controls depend on the system, but I would expect four things wherever agents contribute production code.
Define and bound the work. State the intended outcome, important constraints and evidence required before completion. Keep changes small enough to review, and isolate parallel work so one agent cannot quietly interfere with another.
Demand executable and independent evidence. Tests, type checks, dependency policy and security scanning should run automatically. An agent reviewing its own work can help, but it is not independent evidence. Sensitive changes need another review path with different context or human judgement.
Constrain authority. Give agents distinct workload or session identities where the platform supports them, narrow permissions and short-lived credentials. Allow local compilation inside the sandbox. Gate commands that can change production or another shared system.
Preserve provenance and accountability. Record which agent changed what, the tools it used, the evidence that passed and the person who approved release. An agent cannot be accountable to a customer for a trade-off or carry responsibility after an incident. The developer and the organisation still own the decision to ship.
<!-- Before publishing: add one anonymised first-hand example of a test, sandbox or security gate catching an agent mistake. -->Security enables more aggressive use
Security is often presented as a tax on AI productivity. My experience is the opposite. Strong boundaries let me delegate more work with less hesitation.
An isolated environment makes it safer to let an agent run commands, and good tests allow longer iterations without constant supervision. Scoped credentials reduce the consequence of a mistake. Automated security checks give every change attention that a human team could not provide manually at the same volume.
None of these controls makes the agent trustworthy. They reduce the amount of trust the system requires.
Give people and agents room to move inside clear boundaries. Enforce those boundaries mechanically, then escalate the decisions that genuinely require judgement.
The bottom line
Frontier use and serious security are entirely compatible. In fact, frontier use depends on serious security.
Requirements, review and controlled deployment still matter. They need more automation because human attention cannot scale with agent output, and firmer boundaries because agents exercise tools at machine speed. Responsibility for the result stays with the team.
AI-assisted development is still software development, only at a throughput that forces the controls to grow up.