Every engineering team has a list it does not work on.
Not the roadmap. The other list — the small, irritating defects that are individually too cheap to prioritize and collectively never finished. They lose every planning meeting they enter, because on the day, something with a bigger number attached always wins. So they accumulate, and the team learns to describe them as acceptable.
WhyHungry’s founder describes exactly this list. In her words the team was “trying to like 10x this year”, and “there are so many initiatives that are higher” value, so “what eventually gets dropped are tiny little bugs, the really annoying ones that our developers just never get to.”
What was actually built
An autonomous bug fixer. Built in under four days. Twenty-five or more bugs fixed and shipped in the first week.
The part worth stopping on is not the count. It is which work moved. Nobody reassigned a developer. Nobody re-prioritised the roadmap. The work that got done was work that had already been decided against — repeatedly, correctly, by people applying reasonable judgment to a scarce resource.
That is the shape of the opportunity, and it is almost always misread. The question is rarely what could AI do faster than our people. It is what has this organization already decided it will never get to. The first question invites a defense of the team. The second one just needs the list.
Where the difficulty actually sat
Not in the fixing. The founder names the real constraint directly: “the biggest issue here, or the learnings, is how we can feed it enough context such that it’s self-improving.”
The model could write the patch. What it could not do was know which patch this codebase wanted — the conventions, the reason a previous fix looked wrong, the thing every engineer on the team knows and none of them has written down. Capability was not the bottleneck. Context was.
This is the failure that gets called an AI failure and is not one. A system that produces confident, plausible, wrong work is usually a system that was never told what it needed to know. That is an architecture problem, and it is solvable — but not by buying a better model.
The honest limit
The founder quotes a one-shot fix rate of roughly 60 to 70 percent, and notes “there’s a debate as to whether this is right or not.”
Take her at her word, including the debate. Nearly a third of attempts fail. That is fine for this class of work, and it is fine because of the class of work — a wrong patch on a bug nobody was going to fix costs a review, not an outage. The same rate on payment processing would be indefensible.
Which is the actual design decision, and it is not a technical one. The work chosen was work where the cost of being wrong is low and the cost of never doing it is real. That choice is what made an imperfect system worth shipping, and it is the choice most organizations skip when they pick a first use case by asking which one sounds most impressive.
What this means for an organization that is not a startup
The reasoning transfers even where the setting does not.
- The best first candidate is work already deprioritised. No one has to be persuaded to stop doing it. There is no adoption fight, because there is no incumbent process to displace.
- The blocker will be context, not capability. Expect to spend the effort on what the system needs to know, and expect that knowledge to be undocumented and in people’s heads.
- Match the error tolerance to the work. A system that is right seven times in ten belongs on work where the tenth failure is an inconvenience.
None of this requires a platform decision. It requires knowing which list the organization has quietly agreed not to look at.
Totomoko re-architects how organizations work so that AI does the job — inside the systems they already run, on an architecture built for portability: model routing and a data layer the organization owns. Built that way, swapping a vendor is a configuration change rather than a migration.