How we actually use AI in the studio

The honest position first: we do not ship an AI product, and we are not going to claim numbers for one. What we do have is a studio that uses language models daily as part of how software gets written here — and opinions earned from that.

Where it pays off is the work that is mechanical but not trivial: reading an unfamiliar codebase and reporting where a behaviour lives, sweeping a repository for every place a pattern repeats, generating the first draft of a migration or a test suite, and reviewing a diff with fresh eyes at three in the afternoon. Model-written code that no human read is not shipped.

Where it does not pay off is judgement about what to build. A model will happily produce a confident answer to a question the business has not decided yet, and a confident answer to an undecided question is worse than silence.

The practice we settled on is narrow: give the model a task with a verifiable outcome, let it work, then verify. Tests pass or they do not. The page renders or it does not. The audit finding reproduces or it gets thrown out. Anything that cannot be checked does not get automated.

When we do build AI into a client product, we scope it the same way — by the specific task it replaces and the check that proves it worked. If the check cannot be defined, that is a sign the feature is a demo, not a product.