AI in the Developer Workflow: A Practical, Stage-by-Stage Guide

The useful framing for AI in software work is not "the machine writes the code." It is that AI collapses the time between "I have a question" and "I have a concrete answer to evaluate." Research that took an afternoon of open tabs takes a few minutes. A first implementation of a bounded piece of code arrives in seconds instead of an hour.

That shifts where your time goes. Less of it is spent typing; more of it is spent on the two things that were always the hard part — framing the problem precisely and judging whether the output is correct. This guide walks the development lifecycle and is specific about where that trade lands well and where it does not.

What actually changed#

Three things, concretely:

• Research is faster. You can map the shape of an unfamiliar problem — the common approaches, their trade-offs, the usual failure modes — before you commit to one.
• First drafts are cheap. Boilerplate, schemas, migrations, glue code and table-driven tests can be generated and then reviewed rather than written from a blank file.
• Exploring alternatives costs less. Trying a second approach to see if it is cleaner is now a five-minute experiment, not a sunk afternoon.

What did not change: the model does not know your system, your users, or your constraints unless you tell it, and it cannot verify its own output. The bottleneck moved from keystrokes to specification and review.

Where AI fits in the development lifecycle#

Research#

Ask for the landscape, not the answer: "What are the common approaches to rate-limiting a public API, with the trade-offs of each?" Then confirm the details against primary documentation, because models are frequently a version or two behind on APIs.

It is also good at the unglamorous parts of research — reading an unfamiliar stack trace, explaining a cryptic error, or comparing two libraries you have never used.

Planning#

Turn a vague ticket into a checklist, then ask the model to attack it: "What am I missing? What breaks under load? Which of these steps is riskiest?" Keep the checklist; throw away the prose around it.

Implementation#

AI is strongest on well-specified, bounded units: a pure function with a clear contract, a data schema, a migration, a parser, repetitive boilerplate. Give it the surrounding code and the exact contract you want. A vague prompt produces generic code that technically runs and quietly ignores your conventions.

Read every generated line the way you would read a pull request from a capable but new teammate — because that is what it is.

Debugging#

Paste the error, the relevant code, and what you expected to happen. Ask for ranked hypotheses, not "the fix":

Here is the error, the function that throws, and the calling code.
Expected: the request returns 200 with the created record.
Actual: 500, stack trace below.
Give me the 3 most likely root causes, ordered by probability, and how I'd
confirm each one.

Reproduce the bug yourself first. AI is good at narrowing a search space and poor at confirming a fix — that part is yours. If you want a repeatable structure for the "diagnose, then verify" loop, AIWorkMasters' Complete Code Review Workflow is a reasonable template to adapt.

Refactoring#

Excellent for mechanical, repetitive edits across a file — renaming a concept, migrating a call pattern, extracting a helper in twelve places. Diff every change. It is poor at open-ended "make this better" with no target; you get motion without improvement.

Code review#

A useful automated first pass catches the obvious: missing error handling, unhandled promise rejections, an N+1 query, a null check that is not there, a resource that is never closed. Treat it as a linter with opinions.

It does not review intent, security posture, or whether the design fits the system. A human still owns that pass.

Documentation#

Draft a README section, docstrings, or a changelog entry from a diff, then edit for accuracy — the model will confidently describe behaviour that is subtly wrong. Keep humans on why; let AI handle the first pass at what. Run the result through a Markdown formatter so the spacing and list nesting are consistent before it lands.

Testing#

Ask for edge cases you have not considered, and for the boring exhaustive cases — empty input, unicode, off-by-one boundaries, timezone edges. Do not trust generated assertions without reading them; they encode the model's guess at what your code is supposed to do, which is exactly the thing you are trying to pin down.

Why better prompts matter — the practical version#

A prompt is a specification. An underspecified spec produces generic output, and you spend the time you just saved fixing it. Four things reliably raise quality:

1. Role and goal. "You are reviewing a TypeScript API handler for correctness and security."
2. Real context. The actual code, the actual error, the actual schema — not a paraphrase.
3. Constraints. Language version, style, libraries to use or avoid, and explicitly what not to do.
4. Output shape. "Return a numbered list of issues, each with a severity and a one-line fix."

Two habits make this repeatable. The first is using a structured prompt builder — something that forces the role / task / constraints / output shape and lets you test the same prompt against different models before committing. The second is reuse: keep the prompts that work in a prompt library instead of rewriting them each time, the way you keep a snippets folder. When a prompt is close but not landing, running it through a prompt optimizer that scores clarity, specificity, context and structure is faster than guessing at which part is weak.

Here is the difference in practice:

# Weak
"why is my API slow"

# Stronger
"This Express route (code below) does ~40 sequential DB reads per request and
p95 latency is 1.8s. Node 20, Postgres 15, Prisma. Without adding a cache,
what are the 2–3 highest-impact changes, and roughly what latency each buys?"

Small, focused tools still matter#

AI does not remove the need for deterministic, single-purpose utilities — often it increases it, because you are now generating more code and data that needs a quick, reliable check.

When you are debugging an API response you want a JSON viewer and formatter with a collapsible tree — not a chat window — and when a payload will not parse, a JSON validator that points at the exact line and column beats counting braces. The same applies to decoding a token to inspect a claim, or checking a regex before it ships.

I go through a full set of these in the companion piece, Small Developer Tools That Quietly Save Hours Every Week.

A practical AI-assisted workflow#

This is the loop I actually use — it is the same shape as the idea-to-production pipeline on this site, with AI as leverage on the mechanical parts:

| Stage | What AI does | What stays with you | | --- | --- | --- | | Research | Maps approaches and trade-offs | Choosing the approach | | Plan | Pokes holes in the checklist | Owning the plan | | Prompt | — | Writing a precise spec | | Build | Drafts bounded units | Reviewing every line | | Test | Suggests edge cases | Confirming intent | | Review | Flags obvious defects | Security, design, correctness | | Refactor | Mechanical, repetitive edits | Deciding what "better" means | | Ship | — | Verifying it in production |

What AI still should not decide for you#

• Architecture and the data model. The parts that are costly to change later.
• Security boundaries. Auth, secrets, trust zones, what is exposed.
• Business-logic correctness. The model does not know your domain rules.
• Dependency choices. Supply-chain risk, licensing, and who maintains it.
• Production verification. "It compiled" and "it passed the generated tests" are not "it works."
• Privacy. What you are comfortable pasting into a third-party model.
• Cost at scale. Tokens are a real line item once a feature ships. Do the token estimation and cost estimation up front rather than finding out from the invoice.

Useful resources#

If you bookmark a few things from this:

• Prompting — Prompt Studio for building structured prompts, and the Prompt Optimizer for scoring a draft that is close but not landing.
• Checking output — a JSON Viewer & Formatter for reading responses and generated fixtures.

Final takeaway#

AI is leverage on the parts of engineering that were always mechanical — research, first drafts, repetitive edits, the boring half of testing. It does not remove the need to understand the system you are building or to verify that it behaves. Used that way, it is a genuine multiplier. Used as a replacement for judgement, it just moves the bugs around faster.

I build software this way day to day, and I have shipped an AI-assisted product end to end on my own. If you have an interesting technical problem or a product idea, get in touch.