There's a popular narrative right now: let AI handle your code, review the output, ship faster. I bought into it. I still use AI for coding every single day.
But after months of daily use, I've developed a very specific list of things I will and won't let AI touch. Not from theory — from watching things break.
If you're in the same position — using AI daily but building up a quiet list of "not this" — I think you'll recognize what's here. And I'm curious what's on your list that isn't on mine.
What AI is genuinely great at
Boilerplate. CRUD endpoints, validation schemas, form wiring, data transformation layers. AI handles repetition without getting bored or introducing typos. What used to take 30 minutes of mechanical typing now takes 3 minutes of review.
Refactoring with clear instructions. "Separate business logic from the transport layer" — give AI a well-scoped structural task and it produces directionally correct results. Not perfect, but a solid starting point that saves real time.
Test scaffolding. Happy path tests, edge case templates, baseline coverage expansion. AI can generate 20 test cases in the time it takes me to write 3. The catch is that I still need to review every assertion for domain correctness.
What I've stopped trusting it with
Anything involving implicit system knowledge.
Your codebase has invisible dependencies. A 30-second timeout that exists for a reason nobody documented. A cache that depends on referential equality. A hook that adds global listeners. AI doesn't know these things exist. It will confidently change them, and everything will compile. The bug shows up three weeks later.
Architectural decisions across files.
AI optimizes locally. It writes clean code for the file you're looking at. But it doesn't protect global coherence. I've watched AI introduce three slightly different patterns for the same abstraction across different files in the same PR. Each file looked great in isolation. The codebase got worse.
Error handling in async code.
This one bit me hard. AI generates async/await code that looks correct but has subtle issues: missing error propagation, overly optimistic null assumptions, try/catch blocks that swallow important failures. The code compiles and passes basic tests. Then production surfaces the edge cases.
The mental model that works
I treat AI like a fast junior engineer who has read every Stack Overflow answer but has never maintained a production system. That means:
- Great for generating options. "Show me three ways to structure this." Then I pick the one that fits the existing codebase.
- Bad for making judgment calls. "Should we add a cache here?" requires understanding traffic patterns, consistency requirements, and operational complexity that AI simply doesn't have.
- Excellent for the first 80%. AI gets me to a working draft fast. The last 20% — making it production-ready — still takes the same human effort it always did.
The era we're in
Here's what I keep thinking about:
Nobody knows what software engineering looks like in 2 years. That's terrifying. The skills that matter are shifting under us in real time. Last month @gass left a blunt comment on my METR post: "If you are programmer, program you lazy bastard." It made me laugh, but there's something real underneath it — if you outsource everything to AI, you lose the judgment that makes you valuable.
But also — a solo developer can now build things that took a team of 10. That's unprecedented and genuinely exciting. The developers who'll thrive aren't the ones who generate the most code. They're the ones who reject the most output.
The only way I've found to stay sane is to build in public and learn from people who push back on my assumptions. @mahima_heydev has left several comments across my posts about the hidden cost of AI not being time but confidence — people ship changes they don't fully understand. That observation keeps evolving my thinking.
The real shift isn't in typing speed
The biggest change isn't that I code faster. It's that I think differently.
I spend more time on constraints before I start. I write clearer specifications. I think about edge cases upfront because I know AI won't catch them later.
AI didn't reduce the thinking. It moved where the thinking happens — from implementation to design. And honestly, that's probably where it should have been all along.
One thing I wish someone told me earlier
Don't let AI handle something you couldn't review yourself. If you don't understand the output well enough to spot a subtle bug, you're not saving time — you're creating debt.
The best AI-assisted developers I know aren't the ones who generate the most code. They're the ones who reject the most output. That judgment is the actual skill.
What's on your list?
I genuinely don't take your attention for granted. You could be scrolling past this, but you stopped to think about where AI actually fails. If you've hit a wall I haven't described — or if you trust AI with something I've written off — I want to hear it.
Some of the best corrections to my workflow came from someone saying "actually, that's not right" in a comment section. That's worth more than any tutorial.
I'm a developer who uses AI tools every day and writes about what actually works — so far.
P.S. I package what I learn into tools. If you want structured review checklists your AI follows before you merge: 3 Skill Files.
Top comments (6)
This is a great take Mathew, I think you are heading upwind. By the way, it was funny to see a reference to my comment 😝 glad you took it the right way. I actually wondered in deleting it, so not to offend someone.
If you are interested in diving deeper into this topic I can recommend reading a few papers with real data.
Ha, I'm glad you didn't delete it! That comment genuinely shifted how I was thinking about the topic — it deserved the reference. And yes, I'd love those paper recommendations. Always looking for more real data to ground these discussions. Drop them here or DM me, either way works.
from the international journal of mathematics and computer science: ijmcr.in/index.php/ijmcr/article/v...
how AI impacts skill formation: arxiv.org/pdf/2601.20245
Oh nice, thanks for sharing that paper. The academic framing around AI's impact on programming productivity is catching up to what practitioners have been experiencing. I'll dig into it — always useful to have proper research to reference instead of just anecdotes. The gap between what the research says and what the marketing says is... instructive.
that‘s cool！
Thanks! The trust boundary thing keeps evolving for me — what I don't trust AI with today might change in six months. But having explicit boundaries beats just hoping it works out.