What we let the model do, and what we keep human

On every build we end up making the same call: which steps can a model own, and which stay with a person. Get that wrong and you either babysit the tooling all day or ship work nobody trusts.

Start from the workflow, not the tool

Most teams drop an assistant into the old workflow and hope for speed. Someone asks for a function, pastes the result, moves on. That helps a little. It rarely changes how the team ships.

The useful version looks more like this: a senior engineer breaks the work into small, unambiguous tasks, writes down the context the model needs (conventions, data model, what not to touch), and reviews what comes back. Parallel agents can draft an API, tests, and a migration — but only if the tasks were clear enough that “sensible” isn’t a guess.

What we keep human

• What to build, and whether it’s worth building
• Architecture and data-model calls
• Security and anything that can hurt users or the bill
• Final say on whether a change is ready to merge

Models are fine at drafting inside a fence you set. They are a poor substitute for the fence.

A practical split we use on client work

1. Person writes the outcome and the constraints (acceptance, data, what must not break).
2. Model proposes a change inside that fence.
3. Person reviews, runs the checks that matter, and merges or sends it back.

If step 1 is vague, step 2 will look busy and still be wrong. If step 3 is skipped, you don’t have a process — you have autocomplete with deploy access.

What this is not

It isn’t a headcount argument, and it isn’t a pitch for more licences. It’s an operating habit: put judgment where mistakes are expensive, and put drafting where mistakes are cheap to catch.

If you’re sorting that split on a product that’s already live, I’m happy to compare notes — tim@quolo.io.