Tiden 为 AI 编程智能体提供意图校验，把需求记录成可分支合并的规范，并在本地跑测试验证代码是否真正符合你的要求，供使用编码智能体的开发团队确保合并质量。
热门评论
PH 用户
Hi Product Hunt, I'm Nikita, and this is Tiden, the product we've been building for the past year. It's for engineering teams shipping agent-written code every day who want to let agents do the coding while keeping control of what ships.
Qase is a software testing platform used by tens of thousands of builders, and 9 years of building it for them taught us a lot about how quality work gets done. Last year that changed on our own team: agents started producing most of the code, and the rest of our process didn't speed up with it. Review, testing, release, keeping requirements current: all of it became bottlenecks.
Other engineering teams tell the same story. A gaming publisher I talked to, with about 1k+ developers, saw pull request volume go up 4 to 5 times while the number of features they shipped stayed flat. A payments company described 10 times the coding output and 10% more delivery.
The problem underneath it
An agent session produces the code, the tests that pass on that code, and the docs describing what it built. The next session reads those docs as fact. Every artifact agrees with every other one, because they all came from the same place. A QA automation lead at a tax and accounting platform put it best: "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, but it wasn’t what you wanted."
The two usual fixes, another rules file in the repo and better AI code review, both sit inside that same loop. The judge has to sit outside it.
What Tiden does
Tiden is that judge. It's intent verification for coding agents: it sits beside your agents, whichever ones you use, and verifies that what they built is what you actually asked for. It keeps that intent as specs, versioned like code, and checks every change against them rather than against the session that produced it.
Every agent session becomes a closed loop:A session hook captures what you asked for before the first editThe change comes back as a requirement for you to review; requirements branch and merge like codeTiden picks the tests the change touches, runs them in your environment, and the agent fixes what fails before anything mergesThe gate is tied to the spec. Red tells the agent what to fix. Green is a pass you can defend, with the evidence attachedIn production, an error traces back to the release, the change and the prompt behind it, and the fix comes with the test that was missingTiden works beside Claude Code, Cursor, Codex and Copilot, and belongs to none of them. Specs live as one versioned record every agent reads from, instead of a growing pile of markdown. You set the thresholds and the gates, and a person approves anything the loop can't settle.
One limit, stated plainly: Tiden checks the work against what you asked for. Whether you asked for the right thing is still a human judgment.
Get started
Tiden is live at https://tiden.ai. The CLI installs in one command, the docs are at https://docs.tiden.ai, and Starter and Team both come with a 14-day free trial. If you'd rather talk to us first, there's a short form on the site: https://tiden.ai/contact.
What I'd like from you
Honest feedback over upvotes. Where does your team feel this gap most: review, regression, release, or production? What would make you trust an external check?
PH 用户
A green test suite can still be answering the wrong question. I like that Tiden keeps the request as a separate record for checking what ships.
PH 用户
Hey 👋 Another engineer from Tiden is here, too!
It's a really interesting experience to use Tiden to build Tiden. I think it could be interesting for other people too!
At first, changing so many domains at once seemed risky to me, but with Tiden, the process went smoothly.
Tiden helps track every detail and edge case while your product keeps changing, especially over the long term.
I believe you should give it a try!
PH 用户
Hi Product Hunt Community,
I am Nitin, and I am product manager for Tiden. Today, after six months of building, we are finally sharing it with you.
Here is the problem in one line: your agents are fast, but your delivery is not.
Coding agents can write a change in minutes. Yet that same change often takes days to reach production. The PR waits because nobody is sure what else it touches. CI catches a regression on the second push. A reviewer spots a function the agent invented. The code got faster. The delivery did not.
The data backs this up. In Stack Overflow's 2025 Developer Survey, trust in AI accuracy fell to 29%, and 66% of developers said they spend more time fixing "almost right" code. Faros AI found that teams with high AI adoption merge 98% more PRs, while review time rises 91%. Google's DORA research put it simply: AI amplifies what is already there.
The market's answer so far has been a point AI tool for every phase: one for context, one for tests, one for PR review, one for release signals. They are faster cars on old roads. The lifecycle underneath was designed for humans who read specs and follow instructions. Agents sometimes do, sometimes do not, and sometimes invent things that were never there. Throwing more AI at the problems AI creates is not a solution. It is an illusion.
So we started from a blank slate. Tiden is a continuous verification system for agentic coding teams, built around one idea: an enforceable boundary.
Here is how it works:
1. Before a single line of code: Tiden builds a context graph of your system, linking features, requirements, tests and components. When a change comes in, the agent walks that map, finds what is affected and fills the gaps. The result is captured as intent, and that intent becomes the boundary the code must deliver against.
2. Clear context, not all the context: the coding agent gets exactly what is relevant, so it ships in fewer iterations and gets it right more often.
3. Before the PR, not after it: Tiden picks the functional and regression tests that matter for this change, based on requirements and risk, and runs them before a PR exists. Only when that quality gate passes can the agent open the PR.
4. After the merge: release evidence is assembled automatically, and production issues are tracked, feeding the next change.
In our own use, cycle time from starting a change to releasing it came down by almost half. Not because code was written faster, but because the most of rework loops simply stopped happening.
Tiden is built by the team behind Qase, so almost a decade of quality assurance thinking has gone into how verification should work when agents write the code.
We would love your honest feedback:
- Where does your agentic workflow break down today?
- What would you need to trust an agent's change without reading every line?
- What is missing?
You can start a 14-day trial at tiden.ai. I will be here all day answering questions.
Agents build. Tiden verifies. Your team decides.
PH 用户
Love how Tiden is addressing the gap where AI coding assistants and agents can generate 1000s of lines of code in seconds, but it’s very difficult to validate the quality of that code, especially at enterprise scale. Tiden with Claude looks like a killer combination.
PH 用户
我不是一开始就加入 Tiden 团队的，所以当时已经有很多功能、已经定下的决策和其他东西，而这些在我加入新团队时总会让我紧张。尤其是在这个 AI 时代，连最前沿的模型都可能为了完成自己的工作，想去塑造它周围的现实。
但一边用 Tiden、一边构建 Tiden，让我担心少了很多很多；我知道 Tiden 会迫使我的智能体把之前的决定和现有 specs 考虑进去，相邻功能也不会因此被弄坏。
Qase is a software testing platform used by tens of thousands of builders, and 9 years of building it for them taught us a lot about how quality work gets done. Last year that changed on our own team: agents started producing most of the code, and the rest of our process didn't speed up with it. Review, testing, release, keeping requirements current: all of it became bottlenecks.
Other engineering teams tell the same story. A gaming publisher I talked to, with about 1k+ developers, saw pull request volume go up 4 to 5 times while the number of features they shipped stayed flat. A payments company described 10 times the coding output and 10% more delivery.
The problem underneath it
An agent session produces the code, the tests that pass on that code, and the docs describing what it built. The next session reads those docs as fact. Every artifact agrees with every other one, because they all came from the same place. A QA automation lead at a tax and accounting platform put it best: "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, but it wasn’t what you wanted."
The two usual fixes, another rules file in the repo and better AI code review, both sit inside that same loop. The judge has to sit outside it.
What Tiden does
Tiden is that judge. It's intent verification for coding agents: it sits beside your agents, whichever ones you use, and verifies that what they built is what you actually asked for. It keeps that intent as specs, versioned like code, and checks every change against them rather than against the session that produced it.
Every agent session becomes a closed loop:A session hook captures what you asked for before the first editThe change comes back as a requirement for you to review; requirements branch and merge like codeTiden picks the tests the change touches, runs them in your environment, and the agent fixes what fails before anything mergesThe gate is tied to the spec. Red tells the agent what to fix. Green is a pass you can defend, with the evidence attachedIn production, an error traces back to the release, the change and the prompt behind it, and the fix comes with the test that was missingTiden works beside Claude Code, Cursor, Codex and Copilot, and belongs to none of them. Specs live as one versioned record every agent reads from, instead of a growing pile of markdown. You set the thresholds and the gates, and a person approves anything the loop can't settle.
One limit, stated plainly: Tiden checks the work against what you asked for. Whether you asked for the right thing is still a human judgment.
Get started
Tiden is live at https://tiden.ai. The CLI installs in one command, the docs are at https://docs.tiden.ai, and Starter and Team both come with a 14-day free trial. If you'd rather talk to us first, there's a short form on the site: https://tiden.ai/contact.
What I'd like from you
Honest feedback over upvotes. Where does your team feel this gap most: review, regression, release, or production? What would make you trust an external check?
It's a really interesting experience to use Tiden to build Tiden. I think it could be interesting for other people too!
At first, changing so many domains at once seemed risky to me, but with Tiden, the process went smoothly.
Tiden helps track every detail and edge case while your product keeps changing, especially over the long term.
I believe you should give it a try!
I am Nitin, and I am product manager for Tiden. Today, after six months of building, we are finally sharing it with you.
Here is the problem in one line: your agents are fast, but your delivery is not.
Coding agents can write a change in minutes. Yet that same change often takes days to reach production. The PR waits because nobody is sure what else it touches. CI catches a regression on the second push. A reviewer spots a function the agent invented. The code got faster. The delivery did not.
The data backs this up. In Stack Overflow's 2025 Developer Survey, trust in AI accuracy fell to 29%, and 66% of developers said they spend more time fixing "almost right" code. Faros AI found that teams with high AI adoption merge 98% more PRs, while review time rises 91%. Google's DORA research put it simply: AI amplifies what is already there.
The market's answer so far has been a point AI tool for every phase: one for context, one for tests, one for PR review, one for release signals. They are faster cars on old roads. The lifecycle underneath was designed for humans who read specs and follow instructions. Agents sometimes do, sometimes do not, and sometimes invent things that were never there. Throwing more AI at the problems AI creates is not a solution. It is an illusion.
So we started from a blank slate. Tiden is a continuous verification system for agentic coding teams, built around one idea: an enforceable boundary.
Here is how it works:
1. Before a single line of code: Tiden builds a context graph of your system, linking features, requirements, tests and components. When a change comes in, the agent walks that map, finds what is affected and fills the gaps. The result is captured as intent, and that intent becomes the boundary the code must deliver against.
2. Clear context, not all the context: the coding agent gets exactly what is relevant, so it ships in fewer iterations and gets it right more often.
3. Before the PR, not after it: Tiden picks the functional and regression tests that matter for this change, based on requirements and risk, and runs them before a PR exists. Only when that quality gate passes can the agent open the PR.
4. After the merge: release evidence is assembled automatically, and production issues are tracked, feeding the next change.
In our own use, cycle time from starting a change to releasing it came down by almost half. Not because code was written faster, but because the most of rework loops simply stopped happening.
Tiden is built by the team behind Qase, so almost a decade of quality assurance thinking has gone into how verification should work when agents write the code.
We would love your honest feedback:
- Where does your agentic workflow break down today?
- What would you need to trust an agent's change without reading every line?
- What is missing?
You can start a 14-day trial at tiden.ai. I will be here all day answering questions.
Agents build. Tiden verifies. Your team decides.
但一边用 Tiden、一边构建 Tiden，让我担心少了很多很多；我知道 Tiden 会迫使我的智能体把之前的决定和现有 specs 考虑进去，相邻功能也不会因此被弄坏。