Intent verification for coding agents. Meet Tiden.

Today we're launching Tiden. It's a new product from the team behind Qase, built for one job: checking that the code your agents write does what you asked for.

We've been running it on our own code for months, and with a small group of customers since the summer.

Tiden works beside your agents, whichever ones you use. It reads your code and writes down what your product does, as requirements kept versioned beside the code. Before a session starts, your agent gets a working contract: what you asked for, as promises, each one proven by a test. The session can't close while a promise is open. The requirement changes with the code on every merge. When something breaks in production, the error points back to the release and the change behind it. Every release carries its evidence: what was asked, what changed, what passed, and what happened after.

Coding got fast but everything else didn't

Coding is the one step in the SDLC that sped up, and every other step now lags behind it: review, testing, release, incident response, keeping requirements current.

The teams I talk to make the numbers clear. A gaming publisher with about 1,200 developers, all using agents, saw pull request volume go up 4 to 5 times while the number of features they shipped stayed flat.

A global payments company described 10 times the coding output but only 10% more delivery.

The generative ratification loop

The obvious fix is to have the agent check its own work, but that's a job it shouldn't have.

Think about the workflow: the code, the tests that pass on that code, and the docs describing what was built. The next session reads those docs as settled fact. Every artifact agrees with every other one, because they all came from the same place. A person used to catch this by comparing code they understood against a requirement they’d written by hand. Now the agent compares code nobody has time to read against its own generated requirements.

At a tax and accounting platform, a newly hired VP of AI spent his first week on a feature where every agent-written test passed. He found 7 issues against acceptance criteria nobody had recorded, and sent the work back. Their QA automation lead had spent a year building his own fix before deciding it couldn't work:

If you have an agent that decides what to build, and then another agent is grading what's being built against what was actually built, you're essentially encoding the wrong thing. Your tests will pass, they'll be green, and then what goes to production will be something completely different than what was intended.

Another rules file won't fix this, and better AI code review won't either, because both sit inside the loop that produced the code. Swapping in a second model to do the checking doesn't change that: it grades the work against the tests and docs the first one wrote, with no independent record of what was asked. Our team calls it the generative ratification loop. It can only be escaped when the judge sits outside it. Tiden is that judge.

How Tiden works

Tiden builds a live map of your product from your repos, requirements, tests and docs, and keeps requirements versioned and merged like code.

Agents read from one record instead of a growing pile of markdown.

A session hook captures intent before the agent starts, and the change comes back as a requirement for you to review.

Verification runs on the branch, scoped to what the change can affect, and the agent fixes what fails before anything merges.

Gates are tied to the requirement rather than a static config, and a person approves anything the loop can't settle.

Why we're going after this

I've spent 9 years building software quality tools. 2,000+ teams use Qase. Tiden is what we built when the way our own teams write software changed.

Most tools in this space speed up one step of a process built around people writing the code. Tiden starts from a different assumption: agents write the code now, so every step around the code has to work differently.

Requirements are the record of what was asked for. Each change an agent makes is checked against them before it merges. Releases are gated on test evidence instead of a sign-off meeting. When something breaks in production, it goes back into the requirements, so the next change is checked against what actually broke.

That covers the whole cycle, from intent to production, and it keeps up with the agents.

Tiden is live at tiden.ai. Connect GitHub, and it maps the rest.

Tiden is also on Product Hunt. If you try it, we'd like to hear what you think there.