Tiden

Tiden is an intent verification platform for coding agents. It verifies that your agents built what you actually asked for, and it keeps your specifications versioned beside the code. Tiden is built for engineering teams that ship agent-written code every day, and it works beside Claude Code, Cursor, Codex and Copilot. The product reads your code and writes down each spec, keeps your intent as requirements that branch and merge like code, and checks every change against that record rather than against the session that produced it. A verdict comes from tests run in your own environment, and no model grades the diff. You decide what merges. Coding speed went up. Delivery failed to keep pace. Agents write features in minutes, and then someone, usually you, spends the day checking them. The problem is not that the pipeline stops running; it is that the pipeline cannot tell you whether the agent built the right thing. Most checks run inside the session that wrote the code, so the tests agree with it by construction. Put another way, green tests only prove the agent agreed with itself. Tiden exists to close that gap, giving teams a way to show that agent-written code actually does what was asked before it reaches production, and to keep that proof attached to the code as it evolves. Tiden maps what your product does. It reads your code and writes down each spec, then marks the ones that no test proves. The website shows a product snapshot in which Tiden summarises components and specs, for example components such as web (TypeScript, 1,204 files), api (Go, 2,318 files) and billing (Go, 396 files), alongside connected sources such as Jira with 312 issues and error tracking across 3 environments. Each spec is labelled either as proven by a test or as having no test yet; the example given is TIDEN-377, "Billing tier caps volume", marked with no test. The snapshot reports how many specs sit under each area, including Web App, Public API, Billing, Reporters, Search and Auth, so a team can see at a glance where proven coverage exists and where it does not. Mapping the codebase this way turns implicit knowledge about product behaviour into an explicit, inspectable record. Each promise is proven by a test. When an agent starts a session, it begins from a working contract, and the session cannot close while a promise is open. The website illustrates this with an intent called rate-limit-public-api, whose task is to add rate limiting to the public API, worked on by Claude Code. The session moves through four states, Started, Coding, Settle and Close, and carries a list of promises. In the example, "Free returns 429 above 60 requests a minute" is running with 2 tests passed, "Every 429 carries Retry-After in seconds" is running with 1 test passed, and "Pro returns 429 above 600" is still open, so the interface reports that it cannot close yet because 1 promise is open. Attaching promises to a session this way means an agent cannot quietly declare work finished while something remains unproven. The spec changes with the code. Because green tests only prove the agent agreed with itself, Tiden drafts the update on every merge, even ones that skip Tiden. The example shows a Git change to api/public/v1/limiter.go, where a TODO comment about rate limits is replaced by an Allow function that consults the tier limits for a workspace key. Beside that diff, Tiden shows what the code was supposed to do: the spec TIDEN-377, "Billing tier caps volume", moves from the previous line "Unlimited for all tiers" to a new set of statements, that free returns 429 above 60 requests per minute, that Pro returns 429 above 600, and that every 429 carries Retry-After in seconds. In this way the record of intent stays current even when a change arrives outside the normal flow, so the documentation of what the product promises does not drift away from what the code does. You review what was promised and proven. Each branch shows what changed and what proves it, while code review itself stays with your reviewer. On a branch such as intent/rate-limit-public-api heading into main, Tiden reports a pass with 3 of 3 promises delivered and 0 open, listing the spec (TIDEN-377, 3 lines) and the tests that were added: free_tier_returns_429_above_60, retry_after_header_in_seconds and pro_tier_returns_429_above_600, all running and passed. When merging into main, the choices presented are to merge, to ask for a test, or to accept the risk. Release level reporting gives one verdict per release, part by part, with coverage and component figures, for example release 2.6.0 in production reporting 205 of 205 coverage and 12 of 12 components, plus per component status such as Web App pass, Public API pass and Billing pass with risk indicators. Errors in production point back to the release, and a warning such as a feature flag warning on Search, first seen in 2.5.0 with no test covering it, can be fixed with the agent, which adds the missing test. Tiden's approach differs from checks that happen inside the generating session. Because most checks run inside the session that wrote the code, those tests agree with the code by construction. Tiden instead keeps your intent as requirements that branch and merge like code, effectively versioning specifications alongside the software, and checks every change against that record rather than against the session that produced it. The verdict comes from tests run in your environment, and no model grades the diff. The system is built around an explicit, versioned record of what the product is supposed to do, proven by tests, updated when code changes, and traceable back to releases in production. The stated outcome is straightforward: ship agent code you can prove is right. Teams get an account of what was promised and what proved it, so review focuses on what changed and what backs it rather than on re-deriving whether the agent built the right thing. Because a session cannot close while a promise is open, work is not quietly finished without tests. Because a verdict is issued per release, part by part, and production errors point back to the release, failures can be connected to a specific change instead of being hunted down manually. And because the record lives outside the session, merges that skip Tiden still cause an update to the spec to be drafted, keeping intent and reality aligned. Concrete scenarios appear throughout the site. A team adding rate limiting to a public API can watch an agent work through that intent, see which promises are proven by tests and which remain open, and decide whether the branch is ready. A reviewer can look at a branch and see its promises, the tests added and the spec lines that changed before choosing to merge, ask for a test, or accept the risk. A release owner can read one verdict per release with coverage and component counts, and trace a production error back to the release that introduced it. When a coverage gap appears, such as a feature flag warning first seen in an earlier release with no test covering it, the gap can be routed to the agent, which fixes it and adds the missing test. Onboarding onto an existing codebase follows the same path: connect GitHub, and Tiden maps the rest. Tiden is aimed at engineering teams that ship agent-written code every day. It works beside Claude Code, Cursor, Codex and Copilot, and connects to the tools teams already use: GitHub, Jira, Linear, Notion and Azure DevOps. The recommended starting point is to connect GitHub, after which Tiden maps the rest of the product. Installation is available through a shell script served from tiden.ai, and the product offers a free trial alongside a separate pricing page. Tests that produce a verdict run in your environment, which is where the evidence is generated. In short, Tiden treats intent as something to be written down, versioned and proven, not something to be re-checked by hand after every agent session. It maps what your product does, marks what is unproven, holds a session contract open until each promise is proven by a test, drafts spec updates on every merge, reports one verdict per release part by part, and traces production errors back to a release. For teams whose coding agents now write the code, it is a way to verify that the code does what was actually asked for.