How we use AI in development — and where we don't

Discovery and research: summarising interviews, mapping competitors, turning a scoping call into a first draft of user flows. In the build: boilerplate, data models, API clients, test suites and migrations — the code that is tedious to write and easy to check. It also gets a first pass of a screen from the Figma file, which a designer and an engineer then finish by hand.

Architecture decisions, anything that touches payments, personal data or security, performance work and the last ten percent of UI polish. These are exactly the places where a plausible-looking answer is the most expensive kind of wrong, so they stay with the senior engineer from the first line.

No line ships without a senior review, whether a person or a model wrote the first draft. Generated code is covered by the same tests and held to the same standard, and there are no AI-only pull requests. When AI is a product feature — a scanner, an assistant, a recommendation — its prompts are evaluated on real data before release, not on a demo.

Discovery gets shorter and a clickable prototype arrives in days. Sprints keep their two-week rhythm with a TestFlight build every Friday, but more of each sprint goes to the product instead of the plumbing. And the codebase you receive is written to be read by your next engineer — that is the bar, not how fast it was produced.