Something shifted in the last year and I don't think we've named it properly yet.
I know a lot of developers. Not Twitter developers, real ones. People who've been writing code for a decade, who read source code for fun, who can debug a memory leak by staring at a heap dump. Serious people.
Eighteen months ago they laughed at Copilot. Twelve months ago they tolerated it. Six months ago they started using it quietly. Today some of them are shipping features they don't fully understand, generated by tools they don't fully trust, into codebases they're responsible for, because if they don't, the person next to them will.
Nobody says this out loud. Not in standups, not in performance reviews. But it's happening.
The pressure isn't coming from managers saying "use AI or else." It's subtler. It's the junior who joined six months ago shipping features at a rate that doesn't make sense. It's the team down the hall that went from four engineers to three and is somehow shipping faster. It's the recruiter who asks in the screening call whether you're "comfortable with modern AI tooling" and everyone knows what that means.
The market decided something before any of us had time to have an opinion about it.
Here's the honest part. I've been writing code for years. I trust my instincts. I can read a stack trace and know what's wrong before I open the file. That's a skill that took a long time to build and I'm proud of it.
And yet. In the last six months there have been moments where I opened Cursor, described what I wanted, and got a working implementation before I would've finished typing the first function signature by hand.
Not always. Not for anything subtle. But for the boring 70 percent of code that is CRUD and glue and boilerplate and wiring, yes. Every time.
So I use it. I use it reluctantly, and I use it while feeling like I'm cheating at something that used to be a fair game, and I use it while knowing that the thing it's good at is exactly the thing that pays my bills.
The phrase "vibe coding" bothered me when I first heard it. It sounds unserious. It sounds like somebody describing playing with a toy. Then I watched a friend of mine, a senior engineer at a large company, describe a feature to Claude, paste the result into his editor, tweak two lines, and commit. He didn't read most of it. He didn't need to. It worked.
He's not a bad developer. He's a very good one. He just figured out that reading every line of generated code is the same as reading every line of a library you installed. Nobody does that. You trust it or you don't.
The line I keep hearing, and I've started repeating, is: AI won't take your job. Someone who uses AI better will.
I resisted that line for a while. It felt like cope. It felt like something middle managers say to make the transition sound less brutal than it is. But I've started believing it because I've watched the mechanics play out.
The developers who are thriving right now aren't the ones who are best at writing code. They're the ones who are best at deciding what code should exist, describing it clearly, and then evaluating whether the result is correct. That's a different skill set. It's not lesser. It's just different from the one the industry spent twenty years rewarding.
The people getting squeezed are the ones who were paid for typing speed and pattern recall. The ones who could write a Redux reducer from memory or scaffold a React component in their sleep. That knowledge is worth less today than it was eighteen months ago. Not worthless. Less.
The people doing well are the ones who were already thinking in systems, who care about architecture more than syntax, who can look at a spec and know whether it's going to work before anyone writes a line. Those people are faster now. Much faster. They're not writing code they don't understand. They're just not writing the boring parts.
I don't have a clean conclusion here. I don't think there is one.
The uncomfortable truth is that the tool is real, the productivity gain is real, and the disruption is real. Anyone who tells you to just ignore it and keep coding by hand is giving you bad advice, and anyone who tells you to trust the output blindly is giving you worse advice.
The middle path is harder than either. Use the tools, but don't stop understanding the code. Ship faster, but don't ship what you can't debug. Be willing to be the person who reads the generated diff line by line and rejects it, and also be willing to be the person who accepts it when it's genuinely fine.
That's a narrow window to work in and I don't know anyone who's gotten the balance perfect yet.
What I do know is that every developer I respect has quietly moved to the middle of that window in the last six months, regardless of what they post publicly.
I'd like to hear from people who are resisting. What's the argument that keeps you writing everything by hand? Is it principle, is it craft, is it distrust, or is it just that the current tools aren't good enough for what you build?
I'm genuinely curious. Every answer I've gotten so far has been more interesting than the takes I see on Twitter.
Top comments (0)