AI has made building feel ridiculously fast. I can describe something in normal English, get a starting point, test an idea, fix a bug, and have a proper shape of a product much quicker than before.
That bit is exciting. But I have been thinking about the other side of it as well.
Technology is changing so fast that it is easy to let AI make every decision for us. One day it is a new framework, next week a new agent tool, then another model that claims it can build the whole app. If I accept every output just because it works, I do not end up with leverage. I end up with a codebase I cannot explain.
And that is where I draw the line.
My rule: no magic code
The goal is not only to produce working code. I still need to be able to explain it, debug it, and maintain it after the AI has moved on to the next prompt.
If I cannot answer these questions, the code is not ready for me to merge:
- What changed?
- Why was this approach chosen?
- Where does execution actually start and where does it go?
- What fails if an API, dependency, or database is unavailable?
- Where are auth and permission checks enforced?
- What would I inspect first if the feature breaks tomorrow?
That is not me trying to slow down AI. It is me making sure speed does not become debt wearing a nice shirt.
The workflow I actually want
When I use an AI coding agent, I want it to behave more like a sharp engineering partner than a code vending machine.
1. Understand before changing
Before writing code, read the files that matter. Understand the existing conventions, packages, scripts, and data flow. Do not redesign half the project because a cleaner pattern exists in theory.
Small change? Keep it small. Big change? Explain the approach first.
2. Make decisions visible
Not every line deserves a diary entry. But meaningful choices do.
If we picked a storage layer, changed the auth boundary, added a dependency, or chose one architecture over another, I want the context written down privately with the trade-offs. Future me should not have to reverse engineer a decision from a random commit at 1 AM.
3. Keep the flow explainable
For anything substantial, I want a simple flow note:
User action
↓
Page or API entry point
↓
Validation and authorisation
↓
Business logic
↓
Database or external service
↓
Response and error handlingIt sounds basic. But if we cannot draw this, it is usually a sign we are not clear about where state changes, where an external call happens, or what protects the data.
4. Test the behaviour, not the feeling
“It worked once on my screen” is not a test strategy.
For code that changes behaviour, start with the expected behaviour, make the test fail for the missing feature, then make the smallest change that turns it green. For content or configuration work, use the most direct checks available instead of pretending every sentence needs a unit test.
The point is evidence. Not vibes.
5. Verify before making big claims
Build output, type checks, relevant tests, and a quick real interface check are all different signals. A successful linter does not prove the app builds. A page that loads does not prove authorisation is correct.
I want the agent to say exactly what it ran and what happened. If something is unverified, say that too. That is more useful than a confident “done mate” with no proof behind it.
AI should raise the floor, not remove ownership
I am not interested in going back to doing everything manually just to prove I can. That would miss the point.
I want AI to take the repetitive load away: first drafts, repo orientation, test scaffolding, refactors, documentation, edge cases I might miss. But ownership stays with me. The tool can move fast; I still need to know what I am putting my name on.
Because the technology will keep changing. New models will arrive, old frameworks will disappear, and the next “build an app in one prompt” demo will be around the corner.
The habit that will still matter is simple: use the speed, keep the understanding.
The actual win
The best AI-assisted code is not the code that looks impressive in a demo. It is code you can confidently own when the demo is over.