Our first production test of Fable

At MarsBased we work on big projects for big companies, and also on smaller ones for startups and SMEs. And whenever a new AI model drops, it always takes us a few weeks before we can say anything useful about it. We can't compromise the quality of our service, so before a new model or methodology makes it into client work, we have to test it properly.

This is also why we wanted to write this article. When a new model launches, the internet is immediately full of opinions, and you never really know if the person sharing them has used it on a real production project or just played with it for an afternoon. In our case, the opinions come after actually shipping client work with it.

Where we were coming from

Since Opus 4.6 came out in February, our default way of working with AI agents has been the Research, Plan, Implement methodology. We documented it in our AI-augmented development guide, and it has worked well across almost all kinds of projects.

The exception is front-end styling. Models are still not good at designing interfaces or translating designs into HTML and CSS, so RPI doesn't help much there. But for everything else, the results have been very good.

And this is not light usage: we're a 30-people company, most of us software engineers developing projects, and we spend around $2000 per month on AI. So when we say RPI worked well, it's after months of intensive use across the whole company.

What's different about Fable

When Fable dropped, we took some time to research it and understand how to use it. The big difference is context management and size.

With Opus, you always have to manage context carefully. That's largely why RPI exists in the first place: you break down the work and feed it to the model in a controlled way. With Fable, you can give it very large tasks, or even several tasks at once, and it works through them one after another without the typical degradation you see when context grows too big.

You don't need special instructions either. Well-defined tasks and a clear data model, and it works.

Two weeks of work in four hours (sort of)

Our experience so far is limited to one project, and it's important to understand what kind of project it was. It's a codebase we had already built with Opus and RPI, so it was in very good shape. The application is essentially a CRUD with a lot of business logic underneath: a user panel with a dashboard, lots of pages, tables and forms. Fable already had examples of every kind of page and component in the codebase, so its job was to read the new issues, research the existing code, and implement pages similar to ones that already existed.

In those conditions, Fable implemented in about four or five hours a package of tasks we would normally estimate at around 80 hours. Two weeks of development work in an afternoon.

Now, this number is misleading, and this is the part you're probably not going to read elsewhere.

For that to happen, a lot of work had to be done before Fable touched anything. The issues were defined from a functional standpoint with very detailed acceptance criteria. The data model was defined beforehand, which I think was one of the most important factors. And the codebase already had implemented examples of everything Fable needed to build.

And there's also a lot of work after Fable delivers. A developer needs to go through all the changed files, preview everything, and QA it in a test or local environment. There are always a few fixes to make. Realistically, you need two or three days of review work on top of those four hours.

There's another reason not to skip that review, beyond quality: if you don't keep up with how the platform is evolving, you forget very quickly how it works. And a team that doesn't understand its own product is in a very bad position, no matter how fast the model is.

So it's not really 80 hours turned into 4. It's good functional definition, plus a fast implementation run, plus a few days of serious review. Still a very big win, but not magic.

Our take

We're quite happy with Fable so far, but we want to be careful with the conclusions. This was one project, and a favorable one: CRUD work on top of an established codebase with examples to follow. We don't know yet how it behaves on greenfield projects, on messier domains, or on the front-end work where models still struggle.

What we can say is that the things that made it work (a clean codebase, a defined data model, well-written acceptance criteria) are things a good team should be doing anyway.

We'll be using it on different kinds of projects in the coming months, and we'll share what we find.