More AI to fix AI problems won't work, Agentic coding needs enforceable verification boundary.

Agents now write a large share of the world's code. Yet in Stack Overflow's 2025 Developer Survey, trust in the accuracy of AI output fell to 29%, down from 40%. Forty-five percent named "AI solutions that are almost right, but not quite" as their number one frustration, and 66% said they spend more time fixing almost-right code.

The code got faster. The delivery did not.

A tool for every phase

Agentic coding is no longer an experiment. It is how most developers work now. And the market has responded the way markets do: with a point solution for every pain.

Some tools manage context, feeding the agent rules and conventions through markdown files and prompt libraries. Some generate tests from the code the agent just wrote. Some review PRs, checking whether the change follows the technical spec and the coding standards. Some sit at the end and try to give you a release signal.

Many of them are good. Some are open source, some are commercial, and nearly all of them plug neatly into the workflow you already have.

That last part is the problem.

Faster cars on old roads

The software development lifecycle we all know was designed for humans. Requirements, then code, then tests, then review, then release. Each handoff assumes a person who reads the spec, remembers the edge cases, and follows instructions.

Coding agents are not that person. Sometimes they follow instructions. Sometimes they do not. Sometimes they invent things that were never there. Andrej Karpathy, OpenAI co-founder, described them at Sequoia's AI Ascent in 2026 this way:

“They're a bit fallible, a little bit stochastic, but they're extremely powerful.”

The invention is measurable. A study of 576,000 code samples found that 19.7% of the packages the models recommended did not exist. Hallucinations have not gone away; they have simply got more confident.

So when you bolt AI onto each phase of a human lifecycle, you do not remove the bottleneck. You move it. The research says exactly this.

Faros AI analysed telemetry from more than 10,000 developers across 1,255 teams. Teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. PR review time went up 91%. And at the company level, Faros found no significant correlation between AI adoption and improvement.

Google's DORA research team saw the same pattern. Their 2024 report estimated that as AI adoption increased, delivery throughput fell by 1.5% and delivery stability by 7.2%. By 2025, throughput had turned positive, but stability had not. Their conclusion:

“AI doesn't fix a team; it amplifies what's already there.”

And the reason, in their words: "Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability."

Faster code piles up at review. Faster review piles up at CI. Faster CI piles up at release. Meanwhile, your team is maintaining five tools, five sets of rules and five partial views of what is actually going on.

You can go a little way like this. You cannot go all the way.

Start from a blank slate

If agentic coding is going to deliver the productivity it has promised, the lifecycle itself has to change. Not another tool per phase. A system built with agents in mind from the first step to the last.

Karpathy said it plainly when talking about the tooling agents need: "Everything has to be rewritten."

We felt every one of these pains ourselves. So for the last six months, the team behind Qase has been building exactly that. It is called Tiden: a continuous verification system for agentic coding teams.

The idea at its heart is simple. Every change gets an enforceable boundary: a living specification of what the system should do, and a living test suite that proves it does. The agent works inside that boundary. Nothing leaves it without proof.

The requirement specs and the tests are the boundary. The context graph is what holds it together: it keeps every relationship between requirements, tests and components, so the boundary is not a document someone forgot to update but a live structure the agent has to answer to.

It also opens the black box. Every step in the flow, from intent to test result to release evidence, is visible. Anyone on the team can cross-check what the agent was asked to do, what it actually did and how it was proven.

This is where much of the market gets it wrong. One AI writes the code, another writes the tests, a third reviews the PR: that is still a chain of guesses grading each other. Throwing more AI at the problems AI creates is not a solution. It is an illusion. Agents need a boundary they cannot talk their way around.

Here is how that plays out across the life of a single change.

Before a single line of code

Most defects are not coding mistakes. They are requirement mistakes: a change captured as a one-liner, with nobody quite sure what else it touches.

Tiden starts there. It builds a system context graph of your software: every feature, the requirements inside each feature, the links between them, organised by component. It is a navigable map of your product that both people and agents can read.

When a change comes in, the agent does not guess. It walks the map, finds the requirements the change affects, spots the gaps and fills them in, before any code exists. Quality moves to the extreme left of the lifecycle.

The result is captured as intent. That intent becomes the enforceable boundary the code has to deliver against.

And when the coding agent finally starts, it gets clear context instead of all of the context. This matters more than it sounds. More context does not make an agent smarter; it makes it confused. Structured, relevant context from the system map means the agent ships the change in far fewer iterations, and gets it right far more often.

This is not a hunch. Chroma's 2025 study of 18 leading models found that "model performance consistently degrades with increasing input length." The fix is not a bigger context window. It is a better map.

Before the PR, not after it

The agent has finished. In most teams, this is where a PR gets opened and the waiting begins.

With Tiden, the PR waits. The same context graph that holds your requirements also holds your tests, each one linked to the requirement it proves. So Tiden knows two things the moment the code is done: which functional tests prove this change does what was intended, and which regression tests matter given the risk and impact of what was touched.

It runs exactly those tests, right there, before a PR exists. Only when that quality gate passes is the agent allowed to open the PR.

This protects the most expensive resource in your pipeline. Remember Faros: 98% more PRs, 91% more review time. Greg Brockman, co-founder and president of OpenAI, put it this way at Sequoia's AI Ascent:

“Human attention is going to be this incredibly scarce resource.”

With Tiden, reviewers stop being the first line of defence against broken code. They get to do what only they can do, which is judge whether the change is the right one.

After the merge, the loop keeps going

Once the PR is open, your existing CI/CD carries on as it always has. Tiden does not ask you to rip anything out.

What changes is what the reviewer sees. The intent, the context, every test that was run and why: it is all attached to the change. Visibility stops being a private conversation between one developer and their agent and becomes something the whole team shares. Reviews get shorter. Merges get easier.

Tiden also does not stop at the merge. As the change moves to production, it assembles release evidence: a record of what was intended, what was built and what was proven.

After release, it watches production for issues, much as Sentry would, and makes them visible against the requirements they affect. Those issues feed the next iteration. The map gets sharper with every change.

Intent, build, verify, release, observe, and back again. That is the whole loop.

What we saw

We measured cycle time: from the moment someone starts working on a change to the moment it is released. With Tiden, that time came down by almost half.

The gain does not come from writing code faster. Agents already do that. It comes from the loops that never happen: the CI failures caught before the PR, the regressions found before review, the third and fourth pushes that are no longer needed. Less rework, less risk per change, and far less time spent chasing regressions after the fact.

Put your organisation back in control

There is a quieter benefit that leaders notice first. With Tiden, the entire agentic lifecycle lives in one place, from the moment someone starts building a feature to the moment it is released.

That means visibility across every team, not just inside one developer's terminal. It means auditability: a clear trail of intent, verification and evidence for every change. And it means your organisation owns its agentic delivery process, rather than renting it piece by piece from whichever point solution changed its workflow last month.

The people building the most capable models agree on where accountability sits. At OpenAI, Brockman said, "we still want a human to be accountable for all code that gets merged." Karpathy's advice to builders at Y Combinator in 2025 was shorter: "keep AI on the leash." Tiden is that leash, and the evidence trail that makes accountability possible.

Agents build. Tiden verifies. Your team decides.

Verification is the new bottleneck

Seventy-five percent of new code at one of the world's largest engineering organisations is now written by AI. Writing code is no longer the hard part. Proving it is right, quickly, before it reaches a reviewer or a customer, is.

That is the job Tiden was built for.

If your agents are already fast and your releases are not, give Tiden a try. Start a 14-day trial at tiden.ai, or write to us at hello@tiden.ai.

Ship faster, safer and with proof in ADLC.