5 first things we did with Fable 5 and why you should too

I had a list ready before Fable 5 even dropped. Every item on it was something Opus 4.8 had repeatedly failed at.

#1 - Security audit

We are taking security as a top concern and investing a lot in it. That includes internal work, tests, external reviewers and state of the art cyber experts doing manual pen tests constantly, yet if Mythos (Fable's base model) has shown it is able to find 23-year-old bugs in the kernel, obviously something is happening in the cyber security space.

We have run Opus 4.8 checks on the code many times, often at least once a week. It never found a lot, and we fixed the findings when it made sense (80% are noise to begin with).

The first thing I did when it was first released was run Fable as a hacker. It claimed it found something, which after 3 hours of work turned out to be correct. At this point I took Fable and all the latest pentest info, where we prepared an arch overview, attack surface docs, potential weakness points - essentially redirecting the model to "Dig hard here".

7 zero-day bugs found, 5 critical proven attack vectors (that our outer-ring defenses guarded against - which was nice to find out, it's not a fantasy safety mechanism, investing the time in proper sandboxing).

Once Fable came out again, the first thing we did was the same thing, this time we prepared fresh and much more detailed context for it since it earned it. It paid for itself again, we did several iterations until Fable could not find anything meaningful. There is no longer a question in my mind, Cybersecurity expertise is now commoditized, on defense and offense, the best models should be released, under KYC, and allow companies to protect themselves.

Run Fable on your code now. Yet running Fable as-is will yield very little, proper surface mapping against arch and design on the right places is crucial.

#2 - Performance

Performance is hard, it is hard on backend, on frontend. Performance is very similar to security in a sense where it's also a non-functional requirement but it also has to be baked in from the ground up. We have it baked in from the ground up, yet, as you work with agentic coding your code starts to drift, each time a little more, Claude Code session after the other (a topic we will discuss in the future in more detail).

While functional requirements have a lot of testing (see next section), performance testing has much less. Coding agents are bad for performance by design - they will constantly increase timeouts, add gaps and relaxation to make tests pass - and I wish I had a dime for every time I asked Claude Code to respect timeouts, never change them to make a test pass and never add delays to make things pass -- it is hard coded to make the test pass and sweep things away, no worries, it will apologize if caught. the two dashes btw were written by human.

Fable ran the performance tests and came back with a list of improvements. 50% were not acceptable, we tested the first one. The performance went 5X, the app is broken. This is still an open matter on our table and honestly (still human) on the industry table. Coding agents are a performance (which also means operation cost) nightmare.

#3 - Quality

We have thousands of tests, 12 families of them, from basic unit all the way to what we call agentic scenarios. You can't make 10x engineering without extreme testing, this is another topic worth a whole section, but I will say we probably invested $100K on this skill of fine tuning and execution, this skill is our QA team.

So far until today we have failed to complete a single QA cycle, 100% automatic. Opus 4.8 constantly fails, drifts and gives up. Most of the time it will end with a system crash in phase 12.

Phase 12 is the agentic scenarios phase. In this phase the agent is testing the system and can do a lot of things "standard" testing methods can't - it can launch instances, containers, services - it is designed to be the super QA mode. It runs on well defined scenarios, all validated to be legit and passing in isolation. Opus 4.8 constantly breaks at some point, going into a rabbit hole it fails to exit from, times out or just exhausts the system resources to a crash.

We let Fable 5 run the QA. It failed, yet if the average score of Opus phase 12 is 40%, Fable got to 60% on its first attempt. 3 Opus sessions, $150 / 7 hours each, are needed to get to this 40%. Fable did that in a single session, 3 hours, 60%, $500 cost.

#4 - Compress

Another topic that is worth a post by itself is code compression, but here is the gist of things.

Coding is essentially an attempt to compress part of the world into logic. Since the world is analogue and the computers are digital - we are guaranteed to have discrepancies, often leading to code being full of corner cases. As time progresses we get more features, more edge cases, more code and the most important - better understanding of the customers, the problems, the needs. As time goes by we also learn about past mistakes, redundancies and obsolete cases until at some point we will go for a refactoring, which is saying - given what we know, we can now bring the same value with 30% of the code, 90% less corner cases, 5X speed and 10X faster development of new features.

Coding agents require more refactors, and they are very poor at doing them themselves - refactoring means less code, less functions, less files, fewer parameters per function, less types, the exact opposite of what the average LLM likes to do.

The first compression task with Fable failed - a single, detailed and accurate "Plan, execute, test" loop - the app had A LOT of glitches, errors and issues.

The second attempt was different:

Start with the same prompt like done in attempt #1, yet don't code - this is just for context loading.

Take the info and assign it to all docs, the agent prep area and documentation. Output is updated existing architecture and interfaces.

Identify the gap in the arch, prompt the updated arch, interfaces and instructions and proceed to testing the refactor.

Plan, testing lead the way.

Code.

The refactor was completed successfully.

#5 - Async flow

Most of our code tends to be synchronous and serial, which means it is running in the order we read it. It's easy for us and it's easy for Claude, yet real-world apps demand a lot of parallel execution:

• Events - whether it's UI reactivity or backend web sockets
• Parallel execution - threads, processes
• Non-blocking IO
• Multi-service communication data flow

We have a complete phase dedicated to that in our tests (phase 11) and a dedicated section to that in phase 12.

Fable completed phase 11 3x faster than average Opus.

Fable covered 2x more scenarios in phase 12.

Summary

Fable 5 is awesome. It's a step forward in agentic coding and I hope there are more leaps like that coming. There are issues requiring attention from teams and from the industry, where non-functional requirements should gain more focus.

Run security tests on your code using Fable ASAP. Regulation and model companies should release the full capability of these models under proper KYC, the industry needs to defend itself from what is coming. The bad guys are already waiting, while the good guys are denied the tools to defend themselves.

Getting this right in one session is a good day. Getting it right across the team, every session, is the actual problem. That is where Flowpad comes in. Try it with your team.