A while back I wrote a short note about playing with AI almost every day. That post was about the feeling — how the distance between "what if" and "something I can click on" collapsed from weeks to an afternoon. This one is about the less glamorous half: not prototyping, but shipping. Getting AI-assisted work into production without lowering the bar.
Because those are two different disciplines. A demo has to survive one happy-path click in front of an audience that wants it to work. Shipped software has to survive strangers, bad input, the second Tuesday of the month, and the person who inherits it after you. AI makes the first one nearly free. The second one it makes faster — but only if you bring the engineering with you.
Here's what that actually looks like, day to day.
Start with intent, not a prompt
The biggest lever isn't the model; it's how well I've framed the problem before I ever type. If I can't describe what "done" looks like — the inputs, the edge cases, the shape of the output, the thing that would make it wrong — the AI can't either. It will happily fill that vacuum with something plausible and subtly off.
So I write the spec first, even a scrappy one. Three lines of "here's what this should do, here's what it must never do, here's how I'll know it works." That small act of thinking is what separates a useful collaborator from an expensive autocomplete.
Work in small, reversible loops
I don't ask for a feature. I ask for a step. Make it run, look at it, correct course, repeat. Small diffs I can actually read beat a thousand-line drop I have to reverse-engineer and half-trust.
The loop I keep coming back to:
- Make it run first. A working ugly version tells me more than a beautiful plan. Reality has opinions.
- Tests early, not eventually. I get the AI to write tests alongside the code — and then I read those especially carefully, because a test that asserts the wrong thing is worse than no test at all.
- Read every line I keep. This is the non-negotiable. If I merge something I can't explain, I haven't saved time — I've taken out a loan against a future debugging session, at interest.
Where it genuinely earns its keep
- The boring 80%. Scaffolding, boilerplate, the tenth variation of a schema, the migration nobody wants to write. It never gets tired. I stay fresh for the part that needs me.
- Unfamiliar terrain. It gets me into a new library, a new domain, a new corner of the stack astonishingly fast. It's the best "explain this to me while I look at it" tool I've ever had.
- Killing ideas cheaply. Same as with prototypes: the fastest way to find out an approach is wrong is to build a thin version and watch it fail. AI makes that loop cost an hour instead of a week.
- A patient second pair of eyes. "What am I missing here?" against a diff often surfaces the edge case I'd have shipped past.
Where I stay firmly in charge
The last 20% is exactly where judgement has to take over, and it's the 20% that decides whether the thing is any good:
- Architecture and data models. The decisions that are expensive to unwind later. AI is happy to give me a reasonable-looking schema that quietly boxes me in three months from now. That call is mine.
- Security and correctness at the boundaries. Auth, money, personal data, anything that touches the outside world. "Looks right" is not a standard I'll accept here.
- Consistency and taste. A codebase should read like it was written by one person with a point of view. Left alone, AI writes in a slightly different accent every time. Keeping it coherent is human work.
- The last mile of actually correct. It is confidently wrong often enough that you cannot outsource the thinking. The old instinct matters more than ever: assume nothing, verify everything.
The guardrails I've learned the hard way
A few rules that keep the speed from turning into a mess:
- Never merge what you can't explain. If I can't defend a line in review, it doesn't go in.
- Keep the context small. A tight, well-framed ask gets a sharp answer. Dump the whole world in and you get mush.
- Treat it like a brilliant, tireless junior with zero accountability. Fast, wide-ranging, occasionally inspired — and it will never be the one paged at 2am. That's you. Own it accordingly.
- Verifying is now the expensive part, so budget for it. AI moved the bottleneck. Building got cheap; being sure did not. Plan your time around the review, not the writing.
What this is doing to the craft
Here's the part I find most interesting as someone who leads engineers, not just writes code.
When the typing gets cheap, the value moves. It moves to the things AI can't do for you: framing the problem, choosing the architecture, smelling the bug before it happens, holding the bar in review, deciding what's worth building at all. Judgement, taste, and the ability to say precisely what you want — those go up in value, not down.
So I'm not worried about AI replacing engineers. I'm watching it raise the premium on the parts of engineering that were always the real job. The people who thrive will be the ones who were never really paid to type in the first place — they were paid to think, and to be right.
The honest close
None of this is hype. AI makes me faster on a genuinely good day and gives me a rope to hang myself with on a careless one. It has not made engineering easier; it has made the thinking the whole job, and moved the boring parts out of the way so there's nowhere left to hide from it.
I still get humbled weekly. That's the point. The tool got sharper — so the person holding it has to be sharper too. I'm building with it every day, learning the foundations properly in parallel, and writing these notes as I go: less hype, more field report from actually shipping the thing.
Top comments (0)