I've used AI coding tools every working day for about a year now. The reality is far less dramatic than both the hype and the doom say.
The hype crowd told me I'd be ten times faster and that junior developers were obsolete. The doom crowd told me I'd forget how to program and ship slop. Neither happened. What actually happened is more interesting and more boring: the tools quietly reshaped where my time goes, helping enormously in some places and actively slowing me down in others. The Stack Overflow Developer Survey tells a similar story — adoption is near-universal, but trust in the output is far more measured than the marketing suggests.
Here's the honest field report, with the parts nobody puts in the demo videos.
AI coding tools genuinely help with boilerplate, unfamiliar syntax, first drafts, test scaffolding, and explaining unfamiliar code. They slow you down — or quietly hurt you — on novel architecture, anything requiring deep context about your specific system, and subtle correctness, where their confident-but-wrong answers cost more to debug than writing it yourself. The skill is knowing which task is which.
There's a clear category of work where AI pair-programming is a real, daily win.
The common thread: tasks that are well-understood in general but tedious to type, or things I half-know and don't want to context-switch to look up.
For this whole category, the AI is like a fast, slightly unreliable junior who never gets tired of the boring parts. I take the draft, I verify it, I fix it. Net positive, most days.
AI coding tools are a force multiplier on the work you already understand — and a trap on the work you don't.
The losses are sneakier than the wins, which is exactly why people miss them.
The danger zone is novel work and deep-context work. When I'm designing something genuinely new for my specific system, the AI doesn't have the context — it can't know our constraints, our weird requirements, the three other systems this has to play nice with. It confidently produces something plausible that's subtly wrong for my situation, and I lose more time discovering why than I'd have spent thinking it through myself.
The most expensive failure mode is confident wrongness. The tool never says "I'm not sure." It hands me clean, well-formatted, completely incorrect code with total conviction. When I'm tired or rushing, I trust it. Then I spend an hour debugging a problem that exists only because I outsourced thinking I should have kept.
Here's the split I've learned to feel in my gut:
| AI tends to help | AI tends to hurt |
|---|---|
| Boilerplate and glue | Novel architecture |
| Familiar, well-trodden patterns | Deep, system-specific context |
| First drafts you'll verify | Subtle correctness you'll trust |
| Explaining existing code | Decisions with real trade-offs |
A year in, my actual job shifted in a way I didn't expect.
I write less code by hand, but I make more decisions about which code to accept. The valuable skill is no longer "can I produce this code" — it's "can I tell whether this generated code is right, and is this even a task I should be delegating?" That's a reviewing-and-judgment skill, and it's getting more important, not less.
The engineers getting real leverage out of these tools aren't the ones who accept everything. They're the ones who delegate the tedious, verifiable work to the AI and keep the hard thinking for themselves. I pushed this to an extreme once and wrote up what broke when I tried coding with only AI for two weeks — the failure modes there are the same ones that separate engineers who level up from those who stall, a theme running through the brutal truth about becoming a senior developer. The ones getting burned are accepting confident answers on exactly the problems where the AI has no business being confident.
There's a genuine danger the doom crowd got half right about, and I feel it.
When I let the AI handle a category of task for long enough, I get rustier at it. If I never write the boilerplate, I slowly forget the details. For genuinely rote work, that's a fine trade — I don't mourn forgetting exact config syntax. But the line matters. If I started outsourcing the actual thinking — the design, the trade-offs, the debugging reasoning — I'd be hollowing out the skills that make me worth employing.
My rule: delegate the typing, never the thinking. I let the AI draft the obvious stuff, but I keep doing the hard problems by hand often enough to stay sharp. Convenience that quietly erodes your core judgment isn't a bargain. It's a slow bill.
The broader move toward AI agents and automation in development is real and useful, but it rewards people who stay in the loop as the decision-maker, not those who hand over the wheel.
To make this concrete, here's what a normal task looks like now versus a year ago.
A year ago, I'd open the file and start typing. Now I usually start by deciding, before writing anything, whether this is a delegate task or a think task. That two-second triage is the single most valuable habit I picked up. Boilerplate-heavy, well-trodden work goes to the AI for a first draft. Novel or high-stakes work, I do by hand and maybe use the AI only to sanity-check my reasoning at the end.
For the delegated work, the loop is: prompt with enough context, read the output critically, and fix it rather than trust it. I treat every generated block as a code review where I assume there's a bug until I've found it doesn't have one. That mindset — guilty until proven innocent — is what keeps the confident-wrongness problem from biting me.
The surprising change is where my energy goes. I spend less time on the mechanical act of producing code and more on the two ends: framing the problem clearly up front, and verifying correctness at the back. The boring middle got cheaper. The thinking on either side got more important, and honestly more enjoyable, because the tedious part stopped eating my attention.
| A year ago | Now |
|---|---|
| Open file, start typing | Triage: delegate or think? |
| Look up syntax in docs | Ask the AI for the incantation |
| Write boilerplate by hand | Generate, then verify and fix |
| Trust working-looking code | Assume it's wrong until proven right |
It's not a revolution. It's a reallocation — and the people who reallocate toward judgment are the ones it makes better, while the people who reallocate toward blind trust are the ones it quietly makes worse.
One thing I didn't expect was how these tools changed the team, not just me.
Code reviews got harder in a specific way. When a teammate submitted a change, I could no longer assume they understood every line, because some of those lines came from a generated draft they'd accepted a little too quickly. The reviewer's job quietly expanded — I started asking "do you actually know why this works?" more often, and occasionally the honest answer was no. That's a new failure mode, and it's worth naming out loud on a team rather than pretending it isn't there.
The flip side was a genuine win for onboarding. New people got productive faster, because asking the AI to explain an unfamiliar part of our codebase is less intimidating than asking a busy senior engineer for the tenth time. The tool absorbed a lot of the "stupid question" load, which freed the seniors for the questions that actually needed a human.
The teams getting real value out of this aren't the ones who mandated the tools or banned them. They're the ones who talked openly about where it helps and where it hurts, and built a shared norm: generate freely, verify ruthlessly, and never submit code you can't explain. That norm — not the tool itself — is what turns AI assistance into a net positive instead of a slow accumulation of code nobody fully understands.
If this matches what you're seeing day to day, try the "delegate or think" triage on your next few tasks, and follow along for more honest field notes on building with these tools.
Q: Do AI coding tools actually make you faster? On well-understood, tedious work — yes, meaningfully. On novel, deep-context, or subtly tricky work, they often make you slower because verifying and debugging confident-but-wrong output costs more than doing it yourself. Net speed depends entirely on the task mix.
Q: What's the biggest risk of using them daily? Confident wrongness — clean-looking code that's incorrect for your specific context, delivered with total certainty. The second risk is skill atrophy if you outsource thinking, not just typing.
Q: Will these tools replace developers? They're shifting the job from writing code to judging and directing it. The skill of telling right from plausibly-wrong is becoming more valuable, which is hard to do without real engineering ability. They change the job more than they eliminate it.
Q: How do I get the most out of them? Delegate the tedious, verifiable tasks; keep the novel and high-stakes thinking yourself. Always verify generated code, especially when it looks confident. And keep practicing the hard parts by hand so your judgment stays sharp.
AI coding tools didn't make me ten times faster and they didn't make me obsolete. They moved my time from typing toward judging, rewarded me on the boring work, and punished me whenever I trusted them on the work that actually needed me.
Delegate the typing. Keep the thinking. The developers who win with these tools are the ones who never confuse the two.
Where in your week are you accepting confident answers on problems you should still be solving yourself?
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.
One person, output that looks like five. It isn't about working more hours — it's about a kind of leverage teams rarely have.
One idea a week to a published issue in under an hour. The boring system behind a newsletter I never dread sending.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!