Written from using these on shipping work rather than on demos. The line between useful and expensive is consistent enough to describe.
Where they are genuinely faster
Code that is tedious rather than hard. Serialisation, data classes, editor tooling, converting one format to another. Work where the shape is obvious and only the typing is slow.
Reading unfamiliar code. "What calls this and what breaks if I change it" is answered faster by something that can read the whole project at once than by a person scrolling.
The first draft of anything mechanical. A state machine, a pooling system, a save format. Not because the output is final, but because editing a draft is faster than starting from nothing.
Test scaffolding. Writing the boring half of a test suite is exactly the kind of work that is slow for a person and quick for a machine.
Where they cost you time
Anything that needs to feel right. Game feel — jump arcs, camera lag, hit pause, input buffering — is tuned by playing. An agent cannot play it, so it produces something plausible that is subtly wrong, and plausible-but-wrong takes longer to fix than empty.
Performance work. Optimisation requires a profiler and a device. An agent will confidently suggest the standard advice, which may be irrelevant to your actual bottleneck.
Architecture under real constraints. It does not know your team, your deadline or what you already decided to live with.
Anything where being confidently wrong is expensive. They do not signal uncertainty well. Code that looks right and is not is the most costly output there is.
The practical rule
Use them where you can check the answer quickly. The moment verifying the output costs more than writing it yourself, you have crossed the line — and that line moves depending on the task, not on the tool.
This is what we do day to day — the AI Game Generator at Factorial Studio.
