Tonkotsu is very clear on what it does. It lets you be the technical lead of your project, lets you build in a self documenting way.
It wins on UX alone, if you are someone who builds in concrete steps you can now automate those while your documentation and journey write themselves.
For anyone who likes a structured workflow, and likes things being separated into tasks and is content with building in an organized way, Tonkotsu is a winner.
The team cares about users. They care about the tech. It shows.
My brain is a bit too chaotic sometimes so I will still make my own agentic coding harness, perhaps with Tonkotsu.
As a note, I used it for some minor features in vibecoder.date and a couple of test projects. I will keep using it, sharing feedback with the team and spreading the word.
Tonkotsu
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.
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?
Tonkotsu
@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.
Tonkotsu
@build_with_aj Awesome, let us know what you think!
Humans in the Loop
@derekattonkotsu ooc - what % of contributions to Tonkotsu is currently written by Tonkotsu?
Tonkotsu
@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.
Humans in the Loop
@derekattonkotsu lfg!
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?
Tonkotsu
@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!
Tonkotsu
@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.
Product Hunt
Tonkotsu
@curiouskitty - great question! Tonkotsu's planning agent helps build your doc and it starts from a description of the project you want to build (or a Linear issue) and then inspects your codebase to construct a plan with the dependencies worked out. As part of this process, the planning agent determines correct task sizing (we tweaked this a ton) and task dependencies.
Then when Tonkotsu executes these coding tasks, it schedules them so that dependencies are respected. We hide these details under the hood so it's a clean, simple handoff interface.
Curious what your setup is - how do you currently managing dependencies between tasks?
I love the clean GUI approach, but I wonder how much control we actually have over the 'team' through that doc. Is it mostly for giving high-level commands, or can we jump in and micro-manage the specific logic if an agent starts heading in the wrong direction?
Tonkotsu
@theaxx thanks for the support! You have total control with Tonkotsu: nothing gets committed into your repo without your approval. At the same time, we structure interactions so you don't have to micromanage. Delegation is a hand-off, not the start of a babysitting session. Then, when Tonkotsu has code ready for you, you can quickly review it in the product and give line-by-line feedback and approve the commit. So you have a great deal of control, but we free you up so you don't have to watch it as it works. Would love to hear your reaction to the interface when you get a chance to try it!
Well done on the launch — this is a genuinely interesting project, and the workflow aligns closely with how I approach agentic development myself. I also noticed the SOC 2 audit and the emphasis on keeping everything within the local development environment, which is reassuring.
One question I had relates to data handling during LLM processing: what information, if any, leaves the local machine, and which providers are involved? Are there guarantees that this data is not retained or used for future model training by the underlying LLM vendors?
This is an area I often struggle to fully square from an enterprise adoption perspective, though it feels much less problematic for personal or side projects.
Tonkotsu
@reestit thanks for your support! Like all other coding agents, we send relevant snippets of code to the LLM to reason over and generate edits to. We use Anthropic models, and Anthropic does not train on data passed to its API. Yes, completely agree with your observation about enterprise adoption requiring high standards for data usage.
In terms of your workflow, I'm curious how you have things set up right now - what patterns do you find working well for you?
@derekattonkotsu
My approach is still fairly cautious by agentic standards, but it delivers a clear force multiplier compared to non-AI development.
I only work with a single agent on tasks that I believe I could implement myself in a day or two at most. This keeps the blast radius small enough that the results remain genuinely reviewable by a human, without cognitive overload.
I treat the agent as a pair-programming partner: the AI is the driver - albeit a driver that can operate at something closer to 1,000 mph - and I’m the navigator. That speed is precisely why I try to be very explicit about what we’re trying to achieve. Every task starts with a discussion phase where I instruct the AI not to change anything. We explore options, and I ask the AI to assess the likely blast radius across the codebase before deciding on an approach. On more than one occasion, the AI has offered genuinely useful caution or alternative strategies during this phase.
Once we agree on a plan, I ask the AI to document the discussion and the decision. I expect that future documentation will be needed, and these pre-implementation notes should provide useful raw material when that time comes.
At the end of each task, I also ask the AI to write tests, rerun the existing test suite, and confirm that nothing has been broken.
By keeping tasks small and well-bounded, I can usually get what I want in under an hour, which is still roughly a 10× productivity gain. When the AI surprises me in unhelpful ways, it can take maybe 2–4 hours to pull things back on track - which is still a 2-4× multiplier overall.
I’ve been trying to find a name for this strategy. On reflection, it looks a lot like Extreme Programming. Ironically, I’ve never consciously practised XP before, yet I seem to have drifted into it as my default way of keeping the AI on a short leash.
Tonkotsu
@reestit That's really interesting - thanks for sharing that so clearly. The spirit of that resonates a lot with me. I think there's a lot of room to establish disciplined practices that get the most out of LLMs without throwing caution to the wind and YOLOing everything.
The way we've approached it in Tonkotsu is first with a planning phase where the key, consequential decisions are surfaced and where feedback can be given so you can quickly iterate over alternatives. Once Tonkotsu has written the code, we also help you through a test planning phase, where the changes made are assessed and covered with new tests.
Much more to do still, but the key is to place you, the developer, in a position where you can weigh in on the critical decisions/judgments.
If you get a chance to try out Tonkotsu, I'd love to get your take on how it fits your workflow and if anything's missing.
@derekattonkotsu
It’s on my shortlist. I’m still getting a feel for Antigravity at the moment, while working towards the release of a project that I think is genuinely interesting - and may well get an announcement here once it feels mature enough to inflict on the wider world. I only really committed to agentic coding over Christmas, having spent much of 2025 firmly on the cynical side of the debate.
More likely, I’ll try Tonkotsu on a completely new project. The blank-sheet approach is what allowed me to dive into Antigravity with both feet - zero risk of carefully curated legacy code being accidentally rearranged into modern art.
I also have another project on the back burner that I could dust off for a Tonkotsu trial. I wrote a fairly clear specification for it originally in an attempt to rope in my son (an apprentice application developer at a well-known investment management firm, not long out of school). He declined - hence the spec being quietly filed away.
On reflection, Tonkotsu might be the ideal proving ground: there’s already a decent starting specification, and it would benefit from having its tyres kicked before going anywhere serious.