A few months ago I was debugging a max-flow algorithm for an ant-farm pathfinding project — the classic lem-in problem. No AI assistant was going to save me there. I had to actually understand Edmonds-Karp, trace the flow through the graph by hand, and figure out why my residual edges were wrong. That kind of struggle is exactly what taught me how the algorithm worked, and no amount of autocomplete shortcuts that.
Last month, I was writing CRUD handlers and SQL queries for a Go forum app with my team — posts, comments, the usual. Completely different experience. I described what I needed, got a solid first draft in seconds, and spent my actual thinking time on schema design, edge cases, and making sure my SQL didn't leave room for injection. The boilerplate wasn't where the value was. The decisions were.
That contrast is basically my whole argument: AI coding assistants aren't making developers obsolete. They're shifting the line between "work that proves you understand the system" and "work that's just typing." And depending on where you are in your career, that shift either frees you up or quietly removes the ladder you were supposed to climb.
**The skills that got cheaper **
If your value as a developer was mostly "I can produce correct boilerplate fast," that value just dropped — hard. This isn't a hypothetical for me. I've watched myself reach for an assistant to scaffold a handler instead of typing it from memory, and the honest truth is I don't miss typing it. The muscle memory for syntax was never the interesting part of the job. It just used to be unavoidable overhead. This is also why a lot of "AI will replace programmers" takes feel shallow to anyone who's actually shipped something nontrivial with these tools. They're very good at producing code. They're not automatically good at producing correct, secure, maintainable code for a system with real constraints — and that gap is exactly where developers still earn their keep.
**The skills that got more valuable **
Knowing what to ask for. An AI assistant can't read your actual requirements off your forehead. If you don't understand the problem — concurrency in a Go chat server built on a channel-per-client pattern, milestone-based fund release in a donation smart contract, why a Bitcoin node behaves differently in regtest mode versus mainnet — you'll get confident-sounding code that's wrong in ways you won't catch until it's in production. The assistant will happily generate a beautifully formatted function that solves the wrong problem if you described the wrong problem.
Debugging systems you didn't fully write. AI-generated code still breaks. When it does, you need the same mental model of the system you'd have needed before — arguably a better one, since you didn't build it line by line and don't have the same intuition for where the bodies are buried. Debugging someone else's code (even when "someone else" is a model) is a harder skill than debugging your own, not an easier one.
Architecture and tradeoffs. Should this be event-driven or polling? Does a donation platform's smart contract need an oracle for milestone verification, and what happens when that oracle is wrong or gets bribed? Should likes and filters live in the same service as posts and comments, or stay decoupled? No assistant has battle scars from your specific system's failure modes the way someone who's been paged at 2am over it does. These are judgment calls, and judgment doesn't come from a faster autocomplete — it comes from having been wrong before.
Security and edge cases nobody asked about. This is the one I'd flag loudest. Generated code tends to handle the happy path well and the adversarial path not at all — SQL injection, malformed input, race conditions under concurrent load. Those don't show up in a quick demo. They show up three weeks later, in production, when someone least expects it.
**Where this hits hardest: junior developers **
If AI assistants handle the repetition, juniors skip straight to needing the judgment that used to come from the repetition. That's a real gap, and I don't think "just use the AI more" closes it — if anything it widens it, because the assistant removes the friction that used to force learning. I think about this from my own position as an apprentice developer. The projects that actually built my skills — the pathfinding algorithm, networking fundamentals like DNS resolution and the OSI model, building a NetCat-style chat server with mutex-protected shared state — were the ones where I had no shortcut. I had to sit with the problem until it made sense. If I'd had a capable assistant for every one of those, I'd have working code faster and a shallower understanding slower. You still need reps somewhere, even if it's slower and less efficient than just asking for the answer.
The honest advice I'd give any junior dev right now: use the assistant for the boring 80%, but deliberately seek out problems where you turn it off. Not because the tool is bad, but because some understanding only forms under friction.
**The blockchain/Bitcoin angle nobody talks about **
When I was building a Bitcoin blockchain explorer in Go and setting up a node in regtest mode, the assistant was a decent rubber duck for explaining concepts I already half-understood, but a bad primary source. The actual protocol documentation and source code mattered more, not less, in that context. I'd guess the same is true for anyone doing serious smart contract work — the cost of a confidently wrong answer about an oracle problem or a reentrancy vulnerability is just too high to skip reading the real material.
The lesson generalizes: the newer and higher-stakes the domain, the less you should treat the assistant as ground truth, and the more you should treat it as a faster way to navigate documentation you're still going to read yourself.
**What I've actually changed about how I work **
I let AI handle first drafts of anything mechanical — handlers, test scaffolding, config boilerplate, the parts of a task that are mostly typing.
I never skip understanding the generated code before it goes in a PR. If I can't explain why a line is there, it doesn't ship, full stop.
I spend the time I saved on the stuff that actually breaks in production: concurrency bugs, malformed input, what happens when a third-party API — or a Lightning node — does something unexpected.
For genuinely new territory — Bitcoin internals, Lightning mechanics, anything protocol-level — I still go read the source and the docs first. AI assistants are decent explainers but bad ground truth for that kind of work. When I'm coordinating with teammates on a shared codebase, I'm more careful, not less, about reviewing AI-assisted contributions. Code that nobody fully understands is a liability regardless of who — or what — wrote it.
The honest take
AI coding assistants are a real productivity gain, not hype. Anyone telling you otherwise probably hasn't used one seriously. But the "10x developer" framing misses what's actually happening underneath: it's not that everyone got 10x better at the same job. It's that the job quietly stopped being "write code" and started being "make good decisions about code, faster, and verify the decisions you didn't make yourself."
If you only ever practiced the first one, the second one doesn't come for free. And if you're early in your career, the uncomfortable but useful move is to keep doing some of the slow, friction-heavy reps on purpose — not because the tools aren't good, but because the judgment they can't give you still has to come from somewhere.