Advice to "work in small steps" is easy to agree with and surprisingly easy to follow badly.
People who take it seriously often over-correct. They break work into pieces so small that each one does nothing on its own — add a field, then wire the field, then handle the field — and discover that this is somehow worse. More steps, more requests, more reviewing, and still no point at which they can say the thing works.
The instruction was never really "make it small". It was "make it checkable". Those pull in the same direction for a while and then part company.
Two ways to get the size wrong
Too large is the familiar failure. You describe the whole feature, receive a few hundred lines across several files, and now have to verify all of it at once. If something is wrong you cannot easily tell which part, and the only safe fallback is everything you started with. Most of the difficulty of AI-assisted development lives here.
It is worth understanding why a large request goes wrong rather than merely slowly. A long description contains many more unanswered questions than a short one, and every one of them gets an answer — silently, and consistently with all the others. What arrives is not obviously broken. It is coherent, plausible, and resting on a set of assumptions nobody stated, which is considerably harder to unpick than a single visible fault. The size of the request decides how many of those assumptions turn up at once.
Too small is less discussed and quietly expensive. A step that cannot be run and observed cannot be verified, so you are not actually checking anything — you are accumulating unverified changes in smaller portions, which is the same risk with more overhead. Worse, half-finished work tends to be where you leave off, and coming back to three-fifths of a feature is a poor place to resume.
The useful size sits between them, and there is a single test for it.
What "useful" adds
An increment is the right size when it produces something you can observe from outside the code, and check on its own.
That one condition carries a lot. If you can observe it, you can describe it beforehand, which means you can test it afterwards. If you can check it on its own, you can accept it on its own — and if it turns out to be wrong, you can go back to a state that was right without losing unrelated work.
"Add a field to the form" fails that test: nothing happens that you can look at and judge. "Saving the form stores the new reference number, and it is shown when the record is reopened" passes, and is barely bigger.
A reduction, worked through
Suppose the idea is an expense claim tool: staff submit claims with receipts, managers approve or reject them, and approved claims are exported for payroll.
That is not one increment. It is not really one project — it is three, tangled together. The temptation is to describe it fully and hope, and the result is invariably a large amount of plausible code that nobody can verify.
The first useful increment might be:
A logged-in member of staff can submit a claim with a date, amount and description, and see it listed afterwards with the status "Submitted".
That is still noticeably smaller than the idea. It has no receipts, no approval, no export, no email, no editing and no rules about who can see what. But it does something real: a claim can go in and be seen, which is the spine of the whole thing.
What makes it the right size is that it can be checked in a minute. Submit a claim; it appears; the details match; the status says Submitted. If any of that is wrong you know immediately, and the amount of work at risk is small.
Everything else follows as its own step, each starting from something that already worked: attaching a receipt, a manager seeing claims awaiting approval, approving one, rejecting one with a reason, then the export.
Note what the sequence is not: it is not architectural layers, and it is not "build the database, then the back end, then the screens". Slicing that way produces steps you cannot observe until the last one, which puts you back in the too-small trap with extra ceremony.
Checking the size before you commit to it
Three questions, answered honestly, will catch nearly every mis-sized request.
Can I describe what will be observably different when this is done? If the answer involves the words "the code will", it is too small or too internal. If it takes several sentences and the word "and" keeps appearing, it is too large.
Could I check it in a couple of minutes? Not exhaustively — enough to know whether it did the thing. If checking properly would take twenty minutes, you will not do it, and an increment you will not verify is one you should not build.
If it goes wrong, what do I lose? The answer should be "this piece". If it is "an afternoon", the increment is carrying too much.
Why this makes corrections cheap
The real payoff arrives when something is wrong.
With a well-sized increment, the fault is somewhere in a change you can hold in your head, made against a description you wrote, on top of a version you know worked. Diagnosis is usually a matter of comparing what happened with what you said should happen. The correction is small because the search space is small.
With an oversized one, you are looking for an unknown fault somewhere in a large amount of code you did not write, with no reliable earlier state to compare against. This is the situation in which people start asking the AI to "fix it", accept a broad rewrite, and set off a chain of changes nobody is really tracking — the beginning of drift.
Sizing is not really a productivity technique. It is what keeps the cost of being wrong low enough that being wrong stays survivable.
It also matters more as a project grows, because a late change has more to avoid disturbing than an early one did. That rising cost is its own subject: why AI software projects make fast progress and then stall.
The exception worth naming
Throwaway work does not need this. If you are finding out whether an idea is worth pursuing at all, asking for the whole thing in one go and looking at the result is a perfectly sensible use of the tools — provided you are honest that what comes back is a sketch, and that keeping it means rebuilding it properly.
The discipline is for software you intend to rely on. That distinction is worth making deliberately, at the start, rather than discovering three weeks later that a prototype quietly became the real thing.
Deciding what a given increment should do, before asking for it, is the other half of this: how to plan an app before you ask AI to build it. Both belong to the same cycle, set out in full in the PDAID method.