AI writes code fast. Too fast, sometimes — I’ve reviewed AI-generated pull requests that looked perfect and hid three bugs in the error handling. After two years of pairing with these tools daily, here’s my AI coding workflow: the senior discipline for shipping fast without shipping garbage. Not prompts to copy-paste — judgment to internalize.
The short answer
A safe AI coding workflow has four gates: context in (give the agent your repo conventions, not vibes), small diffs out (never accept 500-line generations), tests as the contract (generated code earns trust through green tests), and you own the design (AI implements decisions; it doesn’t make them). Everything below is how those gates work in practice.
Gate 1: context in — garbage in, garbage out
The single biggest predictor of AI output quality isn’t the model. It’s what you feed it. An agent pointed at your repo with a sentence like “add dark mode” produces confident nonsense; the same agent given the theme file, one example component, and the constraint “follow the existing token system” produces a mergeable diff. My rule: never prompt without pointing — attach the relevant files, paste the convention, state what “done” looks like. Five minutes of context saves an hour of corrections. Every time. Yes, every time.
Gate 2: small diffs out — the 50-line rule
Here’s my hard rule, no exceptions: no AI-generated diff over ~50 lines gets approved without line-by-line review. Big generations feel productive (“wow, a whole feature!”) and that’s exactly the danger — review fatigue sets in around line 80 and bugs sail through. When the agent produces something large, I make it split the work: scaffolding first, logic second, tests third. Three small reviews beat one heroic one. This single habit eliminates most AI horror stories.
Gate 3: tests are the contract, not the code
AI code doesn’t earn trust by looking right. It earns it by passing tests — preferably tests written (or at least specified) before the implementation. My loop for anything non-trivial:
# the loop that keeps AI honest
1. Describe behavior + edge cases in plain words
2. Have AI write the TESTS first, review them yourself
3. Have AI implement until tests pass
4. You review the diff (50-line rule), then merge
Notice what this does: the tests pin down what “correct” means in your words, and the agent can’t weasel out of it. Bugs that slip through AI code cluster exactly where tests are thinnest — error paths, edge cases, concurrency. So that’s where I read hardest.
Gate 4: you own the design — always
The failure mode I see in seniors and juniors alike: letting the agent choose the architecture. “Refactor the auth system” without constraints gets you an architecture — plausible, idiomatic-looking, and wrong for your constraints in ways that surface six months later. AI implements decisions; humans make them. I decide the shape (modules, boundaries, data flow) in a short design note — sometimes three bullet points — and the agent fills it in. The day you catch yourself approving a design you don’t fully understand is the day to stop and take the wheel back.
What never to delegate (my list)
Security boundaries. Database migrations on live data. Anything with money, passwords, or PII flowing through it. Public API shapes other teams depend on. These get human-first design with AI as a typist, never AI-first design with human rubber-stamping. I don’t care how good the model gets this year — the blast radius math doesn’t change.
The AI coding workflow on one card
Point at files, not vibes. Cap diffs at ~50 lines. Tests before implementation. Own the design. Review error paths hardest. Never delegate blast-radius decisions. Tape it to your monitor until it’s muscle memory — mine took about three weeks.
This pairs with
AI code assistants compared (pick your tool) and AI frontend tools (pick your design loop) — same track, same no-fluff policy: Frontend Development.
Images: dejankrsmanovic, Lachlan Hardy, HALDANE MARTIN (CC BY) via Flickr / Openverse.