How I Actually Use AI to Write Better Code
A practical, no-hype workflow for using AI coding tools to write better code — where it helps, where it hurts, and the habits that make it worth it.
AI does not write your code for you. Used well, it makes you faster at the parts of programming that are not the actual thinking — boilerplate, refactors, test scaffolding, and explaining unfamiliar code. Used badly, it quietly degrades your understanding and ships bugs you cannot explain.
This is the workflow I actually use, after a year of daily AI-assisted development.
Where AI genuinely helps
The honest answer: AI helps most with work that is well-specified but tedious. If you can describe the task precisely, AI is excellent at producing a first draft.
| Task | How AI helps | How much I trust it |
|---|---|---|
| Boilerplate & scaffolding | Generates the skeleton in seconds | High — I review structure |
| Refactors | Renames, extracts, rewrites safely | High — tests catch regressions |
| Test writing | Drafts table-driven test cases | Medium — I check edge cases |
| Explaining unfamiliar code | Summarizes what a function does | Medium — I verify against source |
| Debugging | Suggests hypotheses from an error | Medium — I reproduce first |
| Architecture | Offers options and tradeoffs | Low — I decide |
The workflow I use
1. Write the spec first. Before I open an AI tool, I write one or two sentences about what I want and why. This forces me to think before I prompt.
2. Give context, not just a question. I paste the relevant function, the error message, and the constraint. “Make this faster” is a bad prompt. “This function is O(n²) because of the nested loop — suggest a linear approach that keeps the same output” is a good one.
3. Treat the output as a draft. I never accept the first answer. I ask for alternatives, I ask it to explain its reasoning, and I run the tests.
4. Keep a “why” note. When I accept a non-obvious AI suggestion, I add a comment explaining why. Future me will thank present me.
Where AI hurts
AI is weakest when the problem is ill-defined. If you do not know what you are building, AI will happily build the wrong thing very quickly. It also tends to:
- Suggest plausible-looking but subtly wrong code.
- Hide complexity behind confident prose.
- Make you slower at the skill you are trying to build — reading and writing code.
The rule I follow: if I cannot explain the code, I do not ship it.
A concrete example
I asked an AI tool to “optimize a slow function.” It rewrote a clear loop into a clever one-liner using a generator expression. It was faster. It was also harder to read, and it broke an edge case the original handled correctly.
When I instead asked it to “explain why this function is slow and suggest the simplest fix that preserves readability,” it pointed at the nested loop and suggested a dictionary lookup. That was the right answer — because the prompt rewarded clarity over cleverness.