One active request: why an unlimited development subscription ships verified work
AI sped up code production, not the time to review, test and decide. Why one active request at a time is what makes review possible, and what that changes about price.
“Is it AI writing the code, or you?” We hear the question on every first call, and it deserves better than a tagline. Short answer: both, in that order. Engineers scope the request, choose the approach, review and sign off every delivery. AI speeds up production between those steps. It decides nothing and never ships alone.
Why that order matters, why it requires handling one active request at a time, and why that is what makes a fixed-price development subscription possible without cutting quality: here is what we observe at Figue since AI entered our production chain.
02
What did AI change, and what did it not change?
The speed gain depends heavily on the task. On a simple, isolated exercise, an experiment published by GitHub in 2023 measured developers 55.8% faster with an AI assistant. On real code, in projects they had known for years, a controlled trial published by METR in 2025 found experienced developers 19% slower with early-2025 tools, while they believed they had gained 20%. AI saves time when the frame is clear. It does not save time on judgement.
What did not move: the time to understand what the client really wants, to choose between three ways of doing it, to check that it works with real data, to review the produced code to find the silent error, and to decide it is ready. That time is human, and it is incompressible. It now represents the larger part of the work on a request.
Review
has become the longest step of a request at Figue, ahead of writing the code. It is the sign that AI does its part, and that we do ours.
The risk, when code becomes cheap, is to treat it as such: generate, ship, move on. It works for a prototype. On a product with customers, every error that slips through costs more than the time it saved. AI did not change that arithmetic; it made it more tempting to ignore.
Development subscriptions that keep their promises have one thing in common: one active request per slot, the rest in an ordered queue. It is not a trick to limit the work. It is the constraint that makes review possible.
An engineer following three requests in parallel reviews none of the three properly: they switch context, forget where they were, miss what they would have caught by staying focused. The same engineer on a single request finishes it, reviews it, tests it, ships it, then moves to the next. Total throughput is higher, not lower, because nothing lingers half done.
There is a second effect, on the client side. When a place in the queue has a cost (the time to wait your turn), requests arrive better written. You think about what you really want before dropping it, you split, you order. A queue handled in unlimited parallel receives ten half-ideas; a queue handled one at a time receives requests.
Reviewing does not mean glancing. Here is what happens on every delivery at Figue before it reaches your preview, and why each step exists.
01
Scoping, before the code
An engineer reads the request, asks the missing questions, and writes in a few lines what we are going to build. It is the moment we discover the request contained three, or that a simpler solution exists. AI is not involved yet.
02
The approach, chosen by a human
Where it fits in the existing code, what we reuse, what we avoid. AI quickly proposes ten paths; the engineer keeps one, for reasons the product taught them and the model does not know.
03
Production, accelerated
This is where AI saves the most time: writing, refactoring, generating tests, documenting. Under control, within the frame set in the two previous steps.
04
Review before delivery
An engineer reviews what was produced before delivery. Not to check that it compiles, to check that it does what the request says, that it broke nothing elsewhere, and that it will hold in six months. It is the longest step.
05
Testing with real data, then the preview
We try real cases, not the ones the code expects. Then the delivery goes to a preview, and you approve it or ask for an adjustment.
Three of these five steps are entirely human, and the fourth is the one that takes the longest. That is what “augmented with AI” means: AI in the middle, engineers at both ends.
05
Why does it change the price?
A freelancer bills days. An agency bills a quote. An employee costs a salary. In all three cases, the price measures time. AI lowers production time, but none of these three models passes the drop on: the day rate does not move, nor does the quote.
A subscription sells something else: a verified result, not days. If the team produces twice as fast with the same review, it can charge less per delivery. That is what makes Figue Unlimited possible at €1,990 per month ex VAT at public price, with lower launch pricing for the first clients, no commitment, with engineers in France. Not a cheaper team, a team selling the right thing.
Doing it yourself with AI, without reviewing, iterating until it looks like it works: it has a name, and it has its place. For a prototype, a personal tool, a page to test, it is the best option there is. Fast, almost free, and you learn.
Things change the day someone else depends on what is online. From then on, every error has a cost, and someone has to review. That someone can be you, if you know how and have the time. Otherwise, that is what you buy with a subscription: the review, not the generation.
A large share, and it varies by request. It is not the right question: what matters is what share is reviewed. At Figue, everything that goes to production has been reviewed before delivery by an engineer who knows your product.
Why not handle several requests in parallel with the same slot?
Because attention does not divide. An engineer on three requests reviews all three badly. One at a time, total throughput is higher and nothing stays half done. For real parallelism, there is the second slot, with its own review.
Can AI get it wrong without you seeing it?
That is exactly what the review and the tests with real data are there to catch. They do not make errors impossible; they make them rare, and they make them visible before production rather than after. It is also why, during the subscription, we fix as a priority blocking defects reported within thirty days of go-live, without it counting as a new request.
Do you use my data to train models?
No. The model providers we use are listed on our subprocessors page, with their terms. Your code stays in your repository, which you have access to from day one.
Will it go faster if I ask for less review?
No, and we do not offer it. Review is the part of the work that cannot be removed without making you pay for the error later. What really speeds things up is splitting your requests well and answering questions fast.
