Coding With AI: A Realistic Workflow

The honest answer to “does AI write your code now” is: sometimes, for some of it, and only if you set it up to fail loudly instead of quietly. Here’s what an actual day looks like, not the pitch-deck version.

Where it earns its keep

Scaffolding, not architecture. New component, new endpoint, new test file — the boring, pattern-matching parts of a codebase are exactly what these tools are good at, because they’ve seen a thousand versions of the same shape before. Ask it to design your service boundaries and you’ll get something plausible-looking and wrong. Ask it to scaffold a CRUD endpoint that matches three existing ones, and it’ll nail it.

The first pass at a bug you can reproduce. Give it a failing test and a stack trace, and it’s often faster at narrowing down where the bug lives than you are, especially in a codebase you didn’t write. It’s much weaker at bugs that only show up under load, in production, or from a race condition — anything that requires reasoning about time, not just code.

Reading code you didn’t write. This might be the single highest-value use: pointing it at an unfamiliar module and asking “walk me through what this does and why it’s structured this way” turns a 45-minute read-through into a 5-minute conversation with follow-up questions.

Tests for the boring cases. Edge cases, null checks, the input-validation tests nobody enjoys writing — these are exactly the kind of exhaustive, pattern-based work that benefits from not being written by a tired human at 5pm.

Where it still needs a leash

• Anything touching auth, payments, or migrations gets read line-by-line, no exceptions. The failure mode here isn’t “slightly wrong code,” it’s “confidently wrong code that looks completely normal in review.”
• Multi-file refactors need a human tracing the actual call graph, not trusting a summary of what changed.
• Performance-sensitive code — AI suggestions optimize for “looks idiomatic,” not “is fast under your actual load pattern.”

The workflow that actually works

1. Write the function signature and a one-line comment describing intent yourself — this is the 10% that requires actually understanding the problem.
2. Let the tool draft the body.
3. Read every line before running it. Not skim — read.
4. Ask it to write the tests after you’ve adjusted the implementation, not before, so the tests reflect what the code actually does rather than what a first draft guessed it should do.
5. For anything sensitive, do a second pass specifically asking “what would break this” — it’s often better at red-teaming its own output than getting it right the first time.

The realistic version of “AI writes code” is closer to pairing with a very fast, very well-read junior engineer who has zero context on your specific system and will confidently guess when it doesn’t know. Treat it exactly that way, and it’s one of the highest-leverage tools available. Treat it like an oracle, and you’ll ship a bug with great commit-message hygiene.