AI Won't Make You Faster. Your Workflow Will.
One study found developers 19% slower with AI while feeling faster. Seven workflow habits that turn AI into a real speed-up.
CarnielOn this page10 sections
In early 2025, the research group METR gave 16 experienced open-source developers 246 real tasks from their own projects. Before starting, the developers guessed AI tools would make them 24% faster. With AI, they were actually 19% slower. The strangest part: after finishing, they still believed AI had sped them up by about 20% (The Decoder on the METR study).
Google's 2025 DORA report, a survey of nearly 5,000 tech professionals, tells a different story. 90% now use AI at work, over 80% say it makes them more productive, and AI use is now linked to higher delivery throughput (Google). But the same report found AI still correlates with more instability: more failed changes, more rework, longer fixes (Splunk's summary of the report).
Both can be true. AI speeds up typing code. Whether it speeds up shipping depends on everything around the typing. DORA's own phrase for it is that AI is "a mirror and a multiplier": it makes a good process faster and a messy one messier.
Here's the workflow that puts you on the right side of that.
Where the time actually goes
In the METR study, the lost time didn't come from bad code. It came from prompting, waiting for responses, reviewing output and sitting idle while the model worked. Participants also pointed to "context rot": long chats where the model slowly loses track of what you're doing.
So the goal isn't to type better prompts. It's to cut the three hidden costs:
Explaining the same context again and again.
Reviewing big changes you didn't ask for.
Fixing output that was almost right.
Every habit below targets one of those.
1. Write your context down once
If you start every session with "we use Next.js, TypeScript, Tailwind, Prisma, and please don't use any", you're paying the context tax every time. Put it in a file at the root of your repo instead. Most coding agents read AGENTS.md automatically, and Claude Code reads CLAUDE.md.
# Project notes for AI agents
## Stack
Next.js 16 (App Router), TypeScript strict, Tailwind v4, Prisma + Postgres.
## Commands
- `pnpm dev` starts the app
- `pnpm check` runs typecheck, lint and tests. Run it before you say you're done.
## Rules
- Server Components by default. Add 'use client' only when you need state or effects.
- Validate all form and API input with Zod schemas in `lib/schemas`.
- Money is stored in kobo as integers. Never use floats for amounts.
- Don't add new dependencies without asking.The best lines are the ones a new teammate would get wrong in their first week. "Money is stored in kobo" saves more mistakes than "write clean code" ever will. I wrote more about this file in AGENTS.md in Next.js 16.3.
2. Ask for a plan before any code
The most expensive AI output is a 400-line change built on a wrong assumption. You read it, realise the approach is off, and throw it all away. A plan is ten lines you can correct in ten seconds.
I want to add a "Download statement" button to the transactions page.
Don't write code yet. First tell me:
1. Which files you'll change or create
2. Where the data comes from
3. Anything you're unsure about
Keep it short.Read the plan, fix what's wrong, then say "go". You'll often find the model planned to fetch data on the client when you already have it on the server, or planned a new API route you don't need. Catching that before the code exists is the single biggest time saver in this list.
3. Keep each change small
DORA lists working in small batches as one of the seven practices that decide whether AI helps or hurts a team. It's just as true for one developer. A change that touches two files gets reviewed properly. A change that touches fifteen gets skimmed, and skimmed code is where bugs hide.
A good rule: one task should fit in one commit you could describe in a single sentence. "Add the statement button and its server action" is fine. "Add statements, refactor the table and update the types" is three tasks.
4. Let the tests be the referee
"Almost right" is the most tiring kind of AI output, because you have to find the part that's wrong. Don't make yourself the only judge. Give the agent a command that says pass or fail:
{
"scripts": {
"check": "tsc --noEmit && eslint . && vitest run"
}
}Then make it part of the task: "Run pnpm check and fix anything that fails before you stop." Agents that can run commands will loop on their own until the types compile and the tests pass. You only look at the result once it's already green.
For logic that matters, go one step further and write the test first. Describe the behaviour, ask for a failing test, check that the test is actually right, and only then ask for the implementation. A wrong test is quick to spot. A wrong implementation that passes a wrong test isn't.
5. Start a new chat more often than feels natural
Long conversations drift. The model starts mixing up an old version of a file with the current one, or keeps applying a decision you reversed an hour ago. When a task is done, or when answers start getting strange, start fresh. Your AGENTS.md means a new session costs you nothing to set up.
6. Hand over the chores, keep the decisions
AI is at its best on work that's tedious for you but easy to check. On a typical frontend project, that includes:
Turning a sample API response into TypeScript types and a Zod schema.
Writing test fixtures and mock data.
Converting a pile of similar components to a new prop API.
Writing a regex, then explaining it back to you with examples.
Reading a long stack trace or a failing CI log and pointing at the likely cause.
Drafting PR descriptions and migration notes from the diff.
Keep these for yourself, or review them line by line:
Architecture choices. Where state lives, what's a server action and what's an API route, how the data model fits together. AI will happily build the wrong thing quickly.
Auth, payments and permissions. If you work on anything that touches money, read every line. A missing ownership check on a transfer endpoint won't fail a single test.
Code you can't verify. If you don't understand the output well enough to know it's right, you haven't saved time. You've borrowed it.
7. Review AI code like a junior's pull request
Treat the diff with the same care you'd give a smart new hire who doesn't know your codebase yet. A quick checklist I'd run on every change:
Did it delete or skip any tests to make them pass?
Did it add a dependency, or quietly use
anyor@ts-ignore?Did it change files outside the task?
Is there input reaching the database or an API without validation?
Would I be able to explain this code to someone else tomorrow?
That last question catches the most. If the answer is no, ask the model to explain it, or rewrite it until the answer is yes.
Measure it, don't feel it
The METR developers felt faster while being slower. You're not immune to that, and neither am I. So check.
For one week, write down the tasks you do and roughly how long each took, and mark whether you used AI. You don't need a tool for this. A note in your editor is enough. At the end of the week, look for the pattern. You'll probably find AI is a big win on some kinds of task and a slow detour on others. Then use it where it wins.
The short version
Write your project context down once in
AGENTS.md.Get a plan before any code.
Keep each change small enough to review properly.
Give the agent a check command and make it pass.
Start fresh chats often.
Hand over chores, keep decisions.
Review every diff like it came from a new hire.
None of these are about a particular tool, and they'll still apply when the next model comes out. The developers who get faster with AI aren't the ones with the best prompts. They're the ones with the best process around the prompts.