The premise most agencies get wrong
The pitch usually goes: we use AI, so we are faster, so you pay less. The problem is that speed is not the constraint on most product builds. Decisions are. A team that generates forty screens in an afternoon and cannot say which three matter has not gone faster. It has moved the bottleneck downstream, into review, into build, and eventually into a rewrite.
The useful question is narrower: which specific steps in a product build are genuinely bounded, repetitive, and cheap to verify? Those are the steps where AI pays. Everywhere else it borrows time from a later week.
Where it actually saves days
Four places, consistently, across the work we have shipped:
- Research synthesis. Twenty interview transcripts into themed clusters is genuinely tedious and genuinely verifiable: you can check any claim against the transcript in seconds. This is the strongest case.
- First-pass content. Empty states, error copy, form labels, the ninety strings nobody wants to write. A designer edits rather than originates, which is a faster mode.
- Edge-case enumeration. Asking what breaks in a flow surfaces the expired-card, half-typed-address, two-tabs-open cases earlier than a review would.
- Boilerplate in build. Types, test scaffolds, migrations, the parts where correctness is machine-checkable.
Notice the pattern. Every one of these is verifiable in less time than it took to produce. That is the whole rule.
Where it quietly costs a week
Interface design from a text prompt is the obvious failure, and not because the output looks bad. It often looks fine. It fails because a screen encodes decisions about hierarchy, about what the user is here to do, about what happens on the unhappy path. A generated screen has the appearance of those decisions without any of them having been made. You find out in build.
The second failure is subtler: AI is confidently wrong about domain specifics. Ask it to design a freight quoting flow and it will produce something that looks like a freight quoting flow to someone who has never quoted freight. We have shipped in logistics, in regulated finance, in clinical practice. In each, the thing that made the design correct was a conversation with someone who does the job.
AI is good at the shape of an answer. It is unreliable about whether the answer is true. Design is mostly the second thing.
The four checks before anything AI-assisted ships
These are not policy theatre. Each one has caught a real problem:
- Provenance. Can we say where every factual claim came from? Anything we cannot source gets cut, not softened.
- A human made the structural call. Hierarchy, flow order and what gets cut are decided by a person who can explain the decision to the client.
- It survives the real data. Generated layouts assume tidy content. We run them against the longest real name, the empty list, the 400-character description.
- Someone who does the job has read it. For domain work, a person from the client's team reads the flow before we build it.
What this looks like on a real engagement
On a six-week MVP, AI touches week one heavily and week five barely. Week one is synthesis, edge cases and first-pass content: the bounded, checkable work. By week five we are making judgement calls about what to cut to hold the date, and those are conversations between people who will be accountable for the result.
The honest summary: it removes maybe a fifth of the hours from a build, almost entirely from the parts nobody enjoyed. It does not remove the part where someone has to decide what the product is.