Where We Put Ourselves in an AI Workflow
Full-Stack Developer
Most arguments about AI at work end up being about the wrong number. People ask what share of the code a model wrote, as if that answered anything.
The better question is where the person sits, and who is on the hook once the work leaves the building.
We already say a short version of this on our service page for IT operations. AI takes the repetitive parts, triage, routine checks, reporting, data handling, and people keep the judgment calls. This post is the longer version of that line.
What Actually Got Faster
Production got faster. Deciding did not.
A model can write a migration, a report, or a whole screen faster than anyone can describe one properly. What it cannot do is carry the result of being wrong. That stays with the person on the pull request, and with the company that picks up the phone.
So the bottleneck moved. It used to be writing. Now it is checking, which is a worse place for it, because checking is slow and easy to fake.
The Seat Moves
There is no single right place for a person to stand in an AI workflow. Looking for one is how a team ends up with a rule nobody follows.
Autocomplete inside a small helper asks almost nothing of me. If it is wrong, a test fails or a colleague says so. A schema change on a live database is a different job, even when its diff is smaller.
So we decide it per task, never per tool:
- Cheap to reverse, small audience. The model drafts, a person skims, the test suite is the real reviewer.
- Expensive to reverse, or the client sees it. A person reads it and runs it before it goes out. On repeatable work the review sits on the procedure, and a person reads the exceptions.
- Irreversible. A person does the work. The model gets to be a second opinion.

Same tools on all three rows. What changes is how far along the line a person has to sit.
None of this is process for the sake of process. It is there so a typo fix and a change to how money moves stop getting the same attention.
The cost of being wrong never went down. Only the cost of producing something wrong did.
That gap is the whole problem. It is why "the AI wrote it" is not an excuse anyone gets to use twice. The volume went up. The number of people who can judge it did not.
Reviewing Work You Did Not Write
Reading code you did not write is a different skill from writing it, and right now it is the one that pays.
Model output is fluent, and fluency reads as correctness. A wrong function that compiles and carries a confident comment gets less suspicion than a messy one from a colleague. That is our bug, not the model's. So it needs a process, not good intentions.
What that looks like on our side:
- Write the rules down where the model reads them. For us that is a
CLAUDE.md, because Claude is what we mostly use. A rule given in a chat is gone tomorrow. - Ask for the plan before the diff. A plan is short enough to argue with. A diff is long enough to nod at.
- Review with a second model. Tell it to attack the first one's work, then read both. Where they disagree is where a person looks.
- Tests and coverage matter more than they did. Writing code got cheap. Testing it did not.
- Reproduce, do not assume. Run it, break it on purpose, watch it fail.

Cheap steps stack up as high as you like. The final push is the one that does not scale.
And keep the specification in human words. If nobody can say what correct means, no reviewer can find wrong.
The Learning You Skip
The other cost is harder to see. The bug gets fixed and you have not learned anything. Do that for a year and you have traded what you could do later for speed today.
Nothing in the tools will stop you. That part has to come from the person.
So we read what we ship, we ask why it works, and we leave the newest engineer room to be stuck on something for an afternoon.
Where We Put Ourselves
Three seats we do not hand over, and we say which they are before the work starts:
- At the specification, because a model cannot want an outcome for a client.
- Answering for anything a client sees, because our name is on it and not the tool's.
- At anything irreversible, because being able to undo it is the only real safety net.
Whether that middle seat means reading each item or signing off the procedure behind it differs by project. We agree which one it is, rather than leaving it to the day.
Everything else is up for discussion, and we discuss it again every time the tools get better. That is not a hedge. It is what taking the tools seriously looks like.
AI changed who produces the work. It did not change who answers for it.
Hero photo by Yancy Min on Unsplash (https://unsplash.com/photos/842ofHC6MaI)