Blog

Claude Fable 5 Worked Unsupervised for 4 Hours and Got 95% Right: What Base44 Learned

July 2026 · 5 min read · AI Strategy

A desk monitor with lines of code flowing down an arrow into a neat terracotta stack of papers
← Back to all posts

Base44 is a vibe-coding platform that lets non-technical users build full-stack apps, and its engineering team runs every new Claude model through production evals as soon as it ships. According to Yoav Orlev, Base44's Head of Product, Claude Fable 5 is the first model his team has trusted with engineering work that used to sit exclusively with their three most senior engineers. For an Australian business trying to work out whether that kind of claim holds up outside a vendor blog post, the Base44 story is worth walking through in detail.

It is worth walking through precisely because it is specific and checkable. Orlev names the two jobs, the time window, and the accuracy figure, rather than gesturing at productivity gains in the abstract, which makes it a reasonable proxy for what an Australian dev team could expect to test for itself.

The work only senior engineers used to touch

Two jobs at Base44 had always been reserved for specialists. One was rebuilding the platform's system prompt, which runs to hundreds of permutations depending on user tier, app category, and feature set. The other was rewiring the native mobile infrastructure, work that only engineers with deep mobile experience could safely attempt.

  • Rebuilding the system prompt across hundreds of tier, category, and feature permutations

  • Rewiring native mobile infrastructure that only specialist engineers could touch safely

Earlier Claude models could contribute to smaller, self-contained features, but stalled once a task touched multiple interdependent parts of the platform. Orlev says that when those models hit an error, they tended to keep grinding on the same spot instead of recognising that the fix probably already existed somewhere else in the codebase.

What changed with Claude Fable 5

Pointed at the system prompt rewrite, Claude Fable 5 spent about an hour asking clarifying questions, then ran unsupervised for roughly four hours. It returned 90 to 95 percent of what the team needed, without a senior engineer sitting alongside it for that stretch. Along the way it flagged a gap in Base44's own test suite: a missing cache-hit check that nobody on the team had caught.

That combination matters more than the raw hours saved. A model that can work independently for an extended stretch, ask for clarification when it is genuinely stuck, and notice gaps in existing test coverage is doing something closer to the reasoning work a senior engineer does, not just typing out code from a specification someone else already wrote.

The test-suite gap is the detail worth sitting with. Nobody at Base44 had asked Claude Fable 5 to audit their tests; it surfaced the missing cache-hit check as a side effect of doing the refactor properly. That is the kind of thing a careful senior engineer notices on a good day, not something you can script a smaller model to do reliably.

What this means if you're running a dev team

For an Australian business, the maths is straightforward. A fully loaded senior engineer in Sydney or Melbourne typically costs $180,000 to $220,000 a year, and that is exactly the resource multi-day, multi-system refactors have always consumed. If a model can independently deliver 90 percent of that work in an afternoon, with a senior engineer reviewing rather than authoring, the constraint shifts from headcount to review capacity.

That does not mean shipping unreviewed AI output straight to production. It means treating Claude Fable 5 as capable of the reasoning step, not just the typing step: working out where a bug has probably already been solved elsewhere in the code, deciding what to try next, and knowing when to ask a clarifying question instead of guessing.

  • Run your own before-and-after evals on real, previously shelved refactors rather than toy problems

  • Keep a senior engineer in the review seat for anything touching shared infrastructure

  • Track how many hours of waiting for a senior engineer to be free disappear once a model can take the first pass

Where to start if you have a backlog nobody's touched

Most engineering teams already know which two or three changes they have been avoiding. Usually they are the ones that touch shared infrastructure, have unclear ownership, or would take a senior engineer a week they do not have spare. That backlog, not a greenfield project, is the best place to find out whether a model like Claude Fable 5 changes the equation for your team.

If the work touches customer data, it is also the point to loop in whoever owns your Privacy Act obligations before any code goes near production, the same as you would for a new human hire. Automata AI runs structured pilots for Australian teams that want to test this against a real backlog item instead of a demo.

A pilot like this usually starts with picking one piece of shelved work, the kind that keeps getting bumped to next sprint, and scoping it with your senior engineer before any model touches the code. The engineer stays in the review seat throughout, and the point of the exercise is a plain answer to a specific question: on work like yours, how much of the first pass can Claude Fable 5 genuinely take off your most expensive engineers' plates.

Start with a short scoping call: book a time with Automata AI.

Ready to move from AI pilot to production?

We help mid-market Australian businesses deploy AI automations that actually reach production and deliver measurable ROI.