Hey everyone - we re tremendously grateful for our fantastic launch yesterday, ending at #1 for the day. Thank you all for your support!
I started Tonkotsu because I saw a huge opportunity for a complete rethink of AI coding not just incremental adjustments to established tools and workflows. Having managed teams of hundreds of engineers at Meta, Microsoft, and Atlassian, it s been fascinating to me to find that the role of the developer has shifted overnight: you're now the manager of a team of agents. We're building Tonkotsu to help you succeed in that new role.
Managing agents from a doc instead of CLI or IDE is an interesting surface choice. The human-as-editor flow (agents commit, you refine before PR) makes sense... curious if Tonkotsu has guardrails for scope creep when multiple agents run in parallel on the same codebase.
Tonkotsu
@piroune_balachandran Yeah, the design choice to use a doc as the vehicle for agent interactions is very much at the heart of the product. We chose a doc because it's familiar, and it gives you enough space to think through things and also naturally delegate work to agents. When parallel work is being done, each agent works on its own clone of the repo and they can rebase and resolve conflicts if needed before pushing back. git is actually perfectly suited to this development already!
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.
Tonkotsu
@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.)
Tonkotsu
@divyaprakash_d the core mechanism is the doc becomes a central repository of context. Tonkotsu's planning agent helps you break down a big project into individual tasks, and each task gets its own context window, with access to relevant information from the doc.
In terms of manager, we see the developer as the manager here. Your job is to weigh in on key decisions and judgments while delegating away the implementation to your team of agents. We see Tonkotsu's role as providing all the tools so you can stay high level.
looks interesting quick question is my code stored on your servers or does everything run locally
curious about the security side does tonkotsu have access to my codebase or api keys
Tonkotsu
@topfuelauto thanks for the questions! We do not store a copy of your repo on our servers - your repos stay on your machine. Like all coding agents, we send snippets of your code to the LLM so it can reason over it and generate edits to do your coding tasks.
Makers Page
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.
Humans in the Loop
@alexcloudstar likewise!!
Tonkotsu
@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!
This is such a clever approach to managing AI coding agents! Having everything controlled from a simple doc feels much moreintuitive than juggling multiple terminal windows. The "Plan → Code → Verify" workflow looks really well thought out.
Quick question: Does it support multiple agents working on different parts of a project simultaneously?
Congrats on the launch! 🍜
Tonkotsu
@bow_8_vegeta Yes, absolutely. A huge design goal for us with Tonkotsu is to enable parallel work: multi-tasking and even multi-projecting. This maps really well to a manager's role: they lead their team to work across many projects concurrently, and we think that's key to leveraging AI to its fullest as well.
Congrats on the launch, Derek. Tonkotsu feels like a genuinely fresh take on AI-assisted development. I really like the positioning of the developer as a manager of agents rather than being buried in tools, configs, or constant micromanagement. The calm, decision-first workflow is a strong and much-needed contrast to the usual noisy IDE experience.
Also, the ramen noodle logo is a great touch; it’s memorable, playful, and immediately sets Tonkotsu apart in a sea of very “serious” dev tools. One opportunity I see is refining how that logo scales and adapts across product surfaces (app UI, docs, marketing). A slightly more flexible system, variations for dark/light modes, or simplified marks for small UI contexts, I would be happy to help strengthen brand consistency as Tonkotsu grows.