Tiden puts an outside judge on agent-written code. It writes the record itself, and the gate that clears a merge is the event that bills.

Tiden prints that sentence on its own homepage, and it describes the problem the product was built to fix. A coding agent writes the implementation, writes the tests that cover the implementation, and writes the summary the next session reads as settled fact. Everything in the repository agrees with everything else because one model produced all of it. 1

Tiden is a new product from Qase Inc., the company behind the Qase test management platform. Its blog post announcing the tool is dated 6 October 2026, and the Product Hunt listing went up on the board for 14 October 2026. 23

The pitch is narrow, and narrow is the right shape. Tiden keeps a versioned record of what your product is supposed to do, hooks into the coding agent's session so every change gets checked against that record, and holds the merge until a test proves each promise the session made. 1

Whether it belongs in front of your repository turns on four things the launch copy leaves open.

Setup is a GitHub App and a CLI install. Connect your repositories and Tiden registers the component repositories in the same step, then polls each one for landed merges every 15 minutes. 6 The homepage's install line reads curl -fsSL https://tiden.ai/install.sh | bash. 1

The session machinery is the part worth conceding. Before an agent starts work, Tiden records what that session promises as a write-once snapshot, and the session cannot close while a promise is open. 6 Declining to deliver a promise requires an explicit waiver with a criterion and a reason. A finished session then records which promises were delivered, which were waived and which were dropped. 6

That is the right primitive. A record of intent that can be quietly edited after the fact is worth nothing, and the vendor shipped the escape hatch as a written waiver instead of a delete key. The alternative most teams already run is a rules file that an agent reads inside the same session that produced the work.

On a branch, the gate covers the specs the branch touched plus one hop, and a scope with no evidence behind it reads not verified. The vendor's own line for that rule is "It never passes on absence." 6 The verdict lands as pass, blocked or risk accepted, with risk acceptance on some builds offered for releases only. 7 The branch page lists every reason a merge is blocked, computed by the same code that refuses it. 6 Product agents run as their own thing, produce agents/- branches, and never write to main. 8

The homepage sentence that gives the game away is short. "Tiden reads your code and writes down each spec." 1 The changelog describes the rest of the pipeline: for each merge on your default branch, Tiden counts how many changed files a spec already anchors and how many none does, and "an agent then describes the uncovered part as requirements." 6

So the record of what the product is supposed to do is drafted by the vendor's models, reading the same repository the agent just wrote. In the documentation, a spec's sources can include repository files, documentation URLs, manual input and "agent artifacts". 9 The team that never wrote anything down gets a complete-looking spec tree by the end of the afternoon.

The vendor publishes this itself. The docs page for specs says that Tiden reads your Jira, Linear and Notion requirements along with your code, and keeps specs as its own versioned record of what the product does. 9 The product also renamed those records from requirements to specs at some point, and kept the old CLI aliases working. 10

Which leaves a question the launch post answers with a phrase rather than a fact. A judge can sit outside the session that wrote the code. Whether it sits outside the loop depends on who authored the standard the code is measured against, and here that author is the same company, reading the same files.

The most useful page Tiden publishes is its changelog, because it records what the team had to fix. One entry from 15 September matters more than the launch post. A requirement written by the merge agent, it says, carries a machine-written marker, and the Quality Gate leaves it out of the blocking set while it has no executed test. The verdict reports the excluded count, and the marker clears when a linked test runs or a session settles against the requirement. 6

Read that as the vendor's own answer to the objection above. It knows a spec drafted by its own agent cannot be trusted to block a merge, so it keeps those specs out of the gate and puts the number on the verdict instead.

The next entry up moves the human further along. When an agent declares which requirement a test verifies, the branch merge validates and applies that link, and the separate approval checklist is gone from the branch page. The merge is now the only review point. 6

Put the three facts together and the chain runs end to end. An agent writes the code. Tiden's paid plans include generated tests, and the changelog describes agent branches arriving with hundreds of test cases added. 4 An agent then declares which spec each test verifies, and that link is applied at the merge with no second approval. The gate finds the spec verified. 611 The vendor excluded its own auto-written specs from the blocking set, which is the right call, and left everything downstream of a declared link to a person reading a merge page.

The pricing page defines the unit before it prices it. A verified change is "a pull request that merges with a passing quality gate", billed once however many runs it took, with retries, failed changes and bot commits free. 4

That is an honest meter, and it puts the vendor's downside next to the customer's. A gate that keeps blocking earns nothing.

Starter covers one product, three repositories and 25 verified changes a month for $49. Team is $199 per product per month with 100 verified changes each, then $2.00 per extra change falling to $1.50 up to 1,000 and $1.00 after, totalled across products. Included changes do not travel between products, so an uneven split costs more than an even one, as the estimator's own note says. 4

Telemetry is a second meter. Team includes 100,000 error events per product and 1 million test results per product, then $0.50 and $0.10 per thousand, capped at $200 and $400 per product per month. The FAQ states the ceiling for a Team product as "$199 per product per month, plus extra verified changes from $2.00 each, plus at most $600 per product in telemetry." 4

The vendor's own estimator, left on its defaults of three products and 600 verified changes, returns $1,097 a month, $13,164 a year, and $1.83 per verified change. Annual billing drops the product fee 20% and leaves the overage and telemetry at the same monthly rates. 4

One structural point survives all the arithmetic. The verdict that decides whether a change may merge is the same object that decides whether it bills. A customer who disputes the gate is disputing the meter, and the vendor owns both.

The launch post argues from three customer stories. A gaming publisher with about 1,200 developers saw pull request volume rise four to five times while the number of features shipped stayed flat. A payments company reported ten times the coding output and 10% more delivery. A new VP of AI at a tax platform found seven issues against acceptance criteria nobody had recorded. 2

None of the three comes with a sample size, a time window or a comparison group. All three came from the company selling the tool, and the launch has drawn no coverage from outside Qase's own pages and its Product Hunt listing.

What can be checked is quieter. The changelog runs from June to 24 September 2026, and the launch post says the team ran it on its own code for months and with a small group of customers since the summer. 26 The reporters it names are Go, Playwright, Vitest, Jest and PHPUnit, with error-tracking SDKs for browser JavaScript, Go, Python, PHP and Laravel. 6 A team on JUnit, pytest or a language outside that list should ask how its results get in, because a promise with no executed test is a promise the gate cannot settle.

The docs also publish a gap: component CLI commands do not accept branch flags yet, and per-branch component reads are unavailable. 10

The terms were last updated on 14 October 2026, are governed by Delaware law, and waive a jury trial. Fees are non-refundable "including during any committed term", and the vendor reserves the right to change products and pricing at any time. 5

On data, the supplemental terms prevail over the main terms where they conflict. They say you keep ownership of what you submit, and that using the AI features consents to Tiden collecting and using "telemetry, Input, and usage patterns" to improve its features and monitor abuse. The limit written into the same clause is that Tiden will not use your Inputs or Generated Content to train "external third-party models". 5

The privacy notice published the same day is written for a website. It covers cookies, web beacons, Google Analytics, a LinkedIn advertising tag and Stripe for payments, and lists the personal categories it collects as name, email, job title, company and industry. Its stated scope is the tiden.ai website and its advertising. 12 Source code, repositories and the intent record appear nowhere in it.

Two things soften that. Intent capture runs locally: the docs say the CLI records coding-agent sessions on the machine and distils them into reviewable intent/- branches, so what leaves the laptop is the branch rather than a raw transcript. 8 And the security certificates, ISO/IEC 27001, SOC 2 Type II and SOC 3, are held by Qase Inc. rather than by Tiden, with the reports available on request. 4

What is left is a question with a clear answer somewhere and no answer on the pages. A spec drafted from your code is generated content about your code. Whether the prompt and the repository text behind it count as Input, as usage pattern, or as neither decides how much of your codebase sits inside a clause that permits use for product improvement. That is a question for the sales call, and it should be asked before the trial starts.

Tiden is aimed at a real problem and built like a real product. The write-once promise record, the session that cannot close with a promise open, the waiver that requires a written reason, and the gate that never passes on absence are the work of people who have watched agent-written pull requests pile up. For a team whose agents already open more changes than anyone reads, and whose reviewers will actually open a merge page, Tiden turns an unreadable diff into a short list of promises with tests attached.

The condition is specific. Run the 14-day trial on one product, connect three repositories, and merge a change whose spec was written by the merge agent while that spec still has no executed test. Then read the excluded count on the verdict and ask whether the change that merged and the change that billed are described by the same record. If they are, Tiden is a merge gate doing exactly what it says. If they are not, you have bought a billing meter with a review queue attached, and the review point is still you.

Green tests only prove the agent agreed with itself. Tiden's answer is a second record, kept by a second process. Whether that adds up to a second opinion depends on who wrote the first one.