Hey Product Hunt! 👋 I’m Derek, founder of Tonkotsu.
We believe developers need a fundamentally new tool for this moment, not another IDE or CLI. Tonkotsu elevates you as the manager of a team of coding agents: you make the key decisions and delegate the rest. It’s a calm, modern workflow without endless knobs and config, but a lot more leverage.
We’re so excited to share Tonkotsu today with the Product Hunt community 🚀
Ask us anything, give us feedback, or share how your AI-powered development workflow is changing. We’ll be around to chat all day.
Doc-as-control panel for coding agents feels right. I’m tired of juggling prompts in five places. How do you keep context clean with a few agents at once? I’ll try it after standup. Free early access helps. Also, the name makes me want ramen.
@alexcloudstar Yeah agree with you. Centering on a doc was our most consequential design decision and we think it's the right one because it gives you a clean delegation interaction that's a handoff rather than babysitting a chat session, plus it gives you composability (Notion inspired us with their lego blocks approach).
In terms of context: the doc is also the vehicle for shared context, both for agents and humans on a team. When you do planning and coding tasks, they have the doc as context. I'm curious what you use to manage context now and what challenges you encounter. Would love your feedback once you give it a go!
@build_with_aj - great questions! At the moment, we're in a free public beta, so no keys or billing. We're focused on learning more from our users and further refining the product.
The biggest project is Tonkotsu itself. It's split across three repos - frontend, backend, and Electron app - and we use Tonkotsu to build itself everyday. We also see our users do 100 tasks each daily on a regular basis.
Last year? Claude code with plenty of homebrew for context management and project state management. Global context continuity, and memory. Still not ideal but quite good. Lacks an initiative loop.
This year: I tried opencode and gemini cli. They are good but not quite my speed.
I do not like Antigravity. It is technically competent but not my kind of thing.
I'm gonna give Tonkotsu a shot with a challenging project. Let's see what happens.
@fmerian - at this point, almost all. Tonkotsu does all the planning and then does the implementation. We use our Test Plans feature and built-in code review to guardrail quality. There might be a few touch ups by hand, but otherwise, Tonkotsu's writing the code.
@marek_nalikowski Thanks! It's been a blast to build in this space given how fast everything is moving.
Report
Hunter
Thanks for the continuous support, Marek ❤️
Curious - do you have a preferred AI model for coding tasks?
Report
Managing a team of coding agents from a doc feels like the next evolution of AI dev workflows 🚀 Curious when delegating parallel tasks, how do you handle conflicting suggestions or overlapping context between agents? I’ve seen a couple patterns that help keep agent output consistent and reviewable if you want me to share. �
Product Hunt
@chimeremeze Tonkotsu starts by working with you to make a plan. The plan is a coherent set of tasks to be done to implement the feature/project you're working on. So the tasks will be consistent with each other. Each task is done in an isolated repo clone and Tonkotsu will rebase and resolve conflicts as necessary using standard git mechanisms.
Report
@derekattonkotsu That makes sense planning first + isolated repo execution is a solid way to avoid agents stepping on each other.
One thing I’ve seen become important at scale is how intent drift gets handled mid-execution e.g. when a task is technically correct but diverges from the original design goal.
Do you rely purely on the initial plan + git conflict resolution, or is there a checkpoint/review layer where humans can steer or veto an agent before rebase? Curious how you’re thinking about that tradeoff.
@fmerian@josemarin Thanks for your support! Happy to be mentioned in the same breath as Linear and Confluence. The last part of it is also built-in verification with Test Plans and diff reviews. Excited to have you try it - let us know what you think!
@abod_rehman Thanks Abdul! The balance we aim for is -- exactly as you say -- keeping things transparent while also avoiding sucking the developer into micromanaging/babysitting the agents. We think the document UX is key to this. We'd love to hear your thoughts once you get a chance to try the product!
Report
This looks great. I've been using Claude Code with a small army of focused agents recently and have been really happy with the results - but having something like this where it can help manage them all is exciting.
I have an old project which is severely deprecated. Interested to see how this would handle a major refactor!
@tokengeek thanks for your support! We think there's so much potential in recentering developers as managers of agents - with clean delegation, no micromanagement, but clarity into what the agents are doing and final approval over commits. Would love to hear your feedback from your refactor.
Just curious - when you use CC with a bunch of agents, are you starting up a bunch of terminal windows in parallel?
When it comes to the agents, I build them out dependant on the project - but as an example:
Top Level: Orchestrator Second Level: Backend, Frontend, Backoffice, Database Third Level: API, Testing, Security, Documentation
The orchestrator has no write permissions, but does have access to certain MCPs and Skills. The other agents have permissions, MCPS and skills granted to them depending on their role in the flow. They always report back to the orchestrator who keeps everything in check.
I can run these in parallel if the orchestrators are working on separate parts of the system and are both writing back to the documentation to detail what they have performed, are about to perform and are currently doing.
I find that instruction sets have to be concise enough that we don't fill context, but detailed enough that they tell the agent exactly what to do - it's a balancing act, but a very fun one to figure out.
Most importantly, having very clear documentation is vital - with clear acceptance criteria throughout.
@tokengeek Super interesting - thanks for sharing your setup.
Agree with the point about calibrating the right level of detail in the instruction sets. What we've also found important is to focus attention on the parts of the instructions that represent the key, consequential design decisions. Those are the parts that are the most leveraged for me to spend time thinking about.
On MCPs and skills - curious what are your go-tos in your setup?
Report
Really like that you’ve framed the interface as “manage a team from a doc” instead of yet another chat or IDE sidebar; that mental model feels closer to how senior engineers already reason about work.
The big tension I keep seeing with agent tools is between hiding complexity so it feels magic vs exposing enough of the chain-of-thought that people can actually debug when things go sideways.
Your UI looks intentionally minimal, so I’m curious how you’re thinking about surfacing “just enough” of what the agents are doing under the hood without turning it into an observability dashboard.
@devin_owen you really hit the nail on the head on a couple of fronts.
Re the document interface - this is the core design decision for the whole product and we made this decision in part because it leans into existing, organic behavior. Whenever a new project comes down, often you see a tech lead spin up a new Notion doc or Confluence page and then the project team jams on that, brainstorming, discussing, surfacing technical decisions. We're inspired by that behavior and that's a big reason for why we center on the document.
Re hiding complexity - we've learned a ton about this from users by observing revealed preferences. First, they want to act at a big picture level - plan, delegate, and verify entire features, not tasks. But second, they want to observe progress at a much finer-grained level. At first this felt a bit contradictory to us, but it makes sense when you think about it from the point of view of a manager: "I don't want to micromanage all the granular details myself, but I want to know you are taking care of things at that level".
So it's been a journey to be honest to calibrate the experience correctly, but we think we've hit a good balance: planning and delegation are done at the project level, but we give visibility into execution progress at the task level, including what the agent is currently doing. (Sorry, a bit of a longwinded answer, but we've thought long and hard about this and done a ton of data analysis on user behavior.)
Replies
Handle
Hey Product Hunt! 👋 I’m Derek, founder of Tonkotsu.
We believe developers need a fundamentally new tool for this moment, not another IDE or CLI. Tonkotsu elevates you as the manager of a team of coding agents: you make the key decisions and delegate the rest. It’s a calm, modern workflow without endless knobs and config, but a lot more leverage.
We’re so excited to share Tonkotsu today with the Product Hunt community 🚀
Ask us anything, give us feedback, or share how your AI-powered development workflow is changing. We’ll be around to chat all day.
Product Hunt Wrapped 2025
Doc-as-control panel for coding agents feels right. I’m tired of juggling prompts in five places. How do you keep context clean with a few agents at once? I’ll try it after standup. Free early access helps. Also, the name makes me want ramen.
@alexcloudstar likewise!!
Handle
@alexcloudstar Yeah agree with you. Centering on a doc was our most consequential design decision and we think it's the right one because it gives you a clean delegation interaction that's a handoff rather than babysitting a chat session, plus it gives you composability (Notion inspired us with their lego blocks approach).
In terms of context: the doc is also the vehicle for shared context, both for agents and humans on a team. When you do planning and coding tasks, they have the doc as context. I'm curious what you use to manage context now and what challenges you encounter. Would love your feedback once you give it a go!
vibecoder.date
Am I upvoting because I am craving ramen. yes.
Is this super cool and looking a lot better than antigravity, yes.
Do I have to bring my own API keys? Do you manage that? How is usage billed?
What's the biggest project you have built with this?
Handle
@build_with_aj - great questions! At the moment, we're in a free public beta, so no keys or billing. We're focused on learning more from our users and further refining the product.
The biggest project is Tonkotsu itself. It's split across three repos - frontend, backend, and Electron app - and we use Tonkotsu to build itself everyday. We also see our users do 100 tasks each daily on a regular basis.
Curious - what is your current stack?
And yes, we are big ramen fans also :)
vibecoder.date
@derekattonkotsu
Last year? Claude code with plenty of homebrew for context management and project state management. Global context continuity, and memory. Still not ideal but quite good. Lacks an initiative loop.
This year: I tried opencode and gemini cli. They are good but not quite my speed.
I do not like Antigravity. It is technically competent but not my kind of thing.
I'm gonna give Tonkotsu a shot with a challenging project. Let's see what happens.
Handle
@build_with_aj Awesome, let us know what you think!
@derekattonkotsu ooc - what % of contributions to Tonkotsu is currently written by Tonkotsu?
Handle
@fmerian - at this point, almost all. Tonkotsu does all the planning and then does the implementation. We use our Test Plans feature and built-in code review to guardrail quality. There might be a few touch ups by hand, but otherwise, Tonkotsu's writing the code.
@derekattonkotsu lfg!
bunny.net
Congrats on the launch!
Handle
@marek_nalikowski Thanks! It's been a blast to build in this space given how fast everything is moving.
Thanks for the continuous support, Marek ❤️
Curious - do you have a preferred AI model for coding tasks?
Handle
@chimeremeze Tonkotsu starts by working with you to make a plan. The plan is a coherent set of tasks to be done to implement the feature/project you're working on. So the tasks will be consistent with each other. Each task is done in an isolated repo clone and Tonkotsu will rebase and resolve conflicts as necessary using standard git mechanisms.
Crisp
Here for the food, not the AI agents 😂 Congrats on the launch!
Handle
@ant0ine_gt Thanks for your support! We do love our ramen :)
Great job @derekattonkotsu and @fmerian
exiting to test it! I like a new way of linear and confluence, I like this approach!
Handle
@fmerian @josemarin Thanks for your support! Happy to be mentioned in the same breath as Linear and Confluence. The last part of it is also built-in verification with Test Plans and diff reviews. Excited to have you try it - let us know what you think!
@fmerian @derekattonkotsu Yeah, installed and testing right now!
Triforce Todos
It is the first tool that treats AI like a team, not a trick. How do you keep things transparent when agents make decisions?
Handle
@abod_rehman Thanks Abdul! The balance we aim for is -- exactly as you say -- keeping things transparent while also avoiding sucking the developer into micromanaging/babysitting the agents. We think the document UX is key to this. We'd love to hear your thoughts once you get a chance to try the product!
This looks great. I've been using Claude Code with a small army of focused agents recently and have been really happy with the results - but having something like this where it can help manage them all is exciting.
I have an old project which is severely deprecated. Interested to see how this would handle a major refactor!
Handle
@tokengeek thanks for your support! We think there's so much potential in recentering developers as managers of agents - with clean delegation, no micromanagement, but clarity into what the agents are doing and final approval over commits. Would love to hear your feedback from your refactor.
Just curious - when you use CC with a bunch of agents, are you starting up a bunch of terminal windows in parallel?
@derekattonkotsu Hey Derek, thanks for the response.
When it comes to the agents, I build them out dependant on the project - but as an example:
Top Level: Orchestrator
Second Level: Backend, Frontend, Backoffice, Database
Third Level: API, Testing, Security, Documentation
The orchestrator has no write permissions, but does have access to certain MCPs and Skills. The other agents have permissions, MCPS and skills granted to them depending on their role in the flow. They always report back to the orchestrator who keeps everything in check.
I can run these in parallel if the orchestrators are working on separate parts of the system and are both writing back to the documentation to detail what they have performed, are about to perform and are currently doing.
I find that instruction sets have to be concise enough that we don't fill context, but detailed enough that they tell the agent exactly what to do - it's a balancing act, but a very fun one to figure out.
Most importantly, having very clear documentation is vital - with clear acceptance criteria throughout.
Handle
@tokengeek Super interesting - thanks for sharing your setup.
Agree with the point about calibrating the right level of detail in the instruction sets. What we've also found important is to focus attention on the parts of the instructions that represent the key, consequential design decisions. Those are the parts that are the most leveraged for me to spend time thinking about.
On MCPs and skills - curious what are your go-tos in your setup?
Really like that you’ve framed the interface as “manage a team from a doc” instead of yet another chat or IDE sidebar; that mental model feels closer to how senior engineers already reason about work.
The big tension I keep seeing with agent tools is between hiding complexity so it feels magic vs exposing enough of the chain-of-thought that people can actually debug when things go sideways.
Your UI looks intentionally minimal, so I’m curious how you’re thinking about surfacing “just enough” of what the agents are doing under the hood without turning it into an observability dashboard.
Handle
@devin_owen you really hit the nail on the head on a couple of fronts.
Re the document interface - this is the core design decision for the whole product and we made this decision in part because it leans into existing, organic behavior. Whenever a new project comes down, often you see a tech lead spin up a new Notion doc or Confluence page and then the project team jams on that, brainstorming, discussing, surfacing technical decisions. We're inspired by that behavior and that's a big reason for why we center on the document.
Re hiding complexity - we've learned a ton about this from users by observing revealed preferences. First, they want to act at a big picture level - plan, delegate, and verify entire features, not tasks. But second, they want to observe progress at a much finer-grained level. At first this felt a bit contradictory to us, but it makes sense when you think about it from the point of view of a manager: "I don't want to micromanage all the granular details myself, but I want to know you are taking care of things at that level".
So it's been a journey to be honest to calibrate the experience correctly, but we think we've hit a good balance: planning and delegation are done at the project level, but we give visibility into execution progress at the task level, including what the agent is currently doing. (Sorry, a bit of a longwinded answer, but we've thought long and hard about this and done a ton of data analysis on user behavior.)