New Programmers Don't Really Have a Choice About AI
Every day I see another heartfelt post on Reddit about “resisting AI use” or “keeping the craft pure.”
Those posts remind me of myself. If you met me two years ago, you’d see me tastefully craft each line and function of the code I write.
Fast forward to today, and I’ve let go of control and I let the AI handle a lot of my codebase. Not because I necessarily want to, but because I’ve realized that programmers simply don’t have a choice anymore.
The industry has already decided, and it’s not waiting for any of us to catch up.
When react was a new thing
In 2016, I had a couple of years experience as a developer and was making sites serving millions of users with pure HTML, CSS, JS, and a little bit of jQuery.
Around that time, I was seeing React gain popularity— and I wasn’t a fan at all.
SPA frameworks increased load times (remember waiting 10 seconds for a simple landing page?), were worse for SEO (Google was terrible at indexing JS-rendered content back then), and downright bad for accessibility. I was confident that the trend would die out.
And I wasn’t alone. There were a lot of people like me on Reddit, as evidenced by Mr. [deleted]’s rant:
Convinced, I doubled down on using plain old JS, no framework. I was writing pure code. I was crafting “elegant” solutions. And I knew that the world would eventually see reason, and return to simpler approaches.
Want to guess how that turned out?
Spoiler alert: no one cared about my “pure” code. What actually happened was:
- Developers who embraced React shipped more applications faster.
- Companies that adopted it could iterate quicker and push features that users actually noticed.
- Meanwhile, my “elegant” vanilla JS solutions took three times as long to build.
The industry had simply moved on, while I was busy being “right”.
Economies of Code
Let’s take some time to think about why so much code exists in the first place.
Code written for businesses allows executing repeatable processes that increase profits and/or save time. It is a means of delivering specific business objectives, not an “art.”
Put another way, when was the last time your manager celebrated your beautiful code architecture? Or, when did your CEO personally thank you for following perfect design patterns?
Never, right? Because from a business perspective, code is a liability, not an asset.
The cold, hard truth is that companies don’t want more code. The only thing that matters is results.
I learned this lesson from my former engineering manager. We were celebrating after a product launch, and I was complaining about some tech debt we’d accumulated.
“You know what?” he said. “I’ve never once heard the CEO care about our code quality. The only thing that matters is if we can deliver before deadlines or not. Nobody’s getting promoted for clean code if the feature ships late.”
It was disappointing, but also… enlightening?
As a programmer, since I live inside my codebase, I want to make it perfect exactly the way I want. I still get a dopamine hit when I refactor a messy function into something elegant.
But if I think about this from the perspective of a business, my code is merely a tool to earn profits.
And that’s why I feel that we really don’t have any choice about using AI. The painful reality is that someone using AI will outpace someone who is not, not by a small margin, but by orders of magnitude.
And what employer wants to hire the slower programmer?
Changing definitions of a “Good Programmer”
Remember what defined a good programmer a few years ago?
Back when I first started, being “senior” meant you had encyclopedic knowledge of your stack. I paired with a guy recently who could recite the exact syntax for obscure Python functions from memory. Like a programming savant.
You were expected to know your framework’s internals so well that you could debug issues without even looking at logs. “Oh, you’re getting that error? That’s a known issue with how React handles nested Suspense components.”
And let’s not forget the badge of honor that came with using APIs and libraries without needing to look at docs, because you already remember it.
With AI, that definition needs to be updated. Much of the lower levels of programming is handled by an AI, the developer’s role is more of a “orchestrator.”
Now, a good programmer needs totally different skills:
- Translating business needs into technical specifications that AI understands
- Then, using AI to get results quickly
- And finally, being an expert at reading and validating code.
How to Keep Up
It’s a completely different mental process to be programming with AI. I’ve been experimenting with ways to get comfortable with it. Here’s what’s actually working:
- Ask better questions. This seems obvious, but there’s an art to it. The quality of your AI output directly corresponds to your prompt skills. I keep a list of effective prompts for different situations.
- Build your verification instincts. AI will confidently generate complete nonsense. Getting good at identifying it quickly is a superpower.
- Operate at the edge of your abilities. Use AI for the mundane stuff (boilerplate, standard patterns, typical integrations), then apply your creativity to the novel problems AI can’t handle yet.
- Deep dive when things break. The best learning happens at failure points. When AI-generated code breaks, that’s your cue to really understand the underlying system. Add logs, use the debugger, manually go through each part of the code flow.
I went through the various stages of grief about these changes. I was angry (these tools are stealing our jobs), in denial (they’ll never replace real programming skill), tried to bargain (maybe I’ll just use it for documentation).
But eventually, I accepted it: programming as I knew it is changing. Something new is being born.
The programmers who will survive this transition are the ones who will understand and use AI as the powerful tool that it is.
- They’re the ones who can identify what AI is terrible at. And trust me, despite all the hype, there are still plenty of things AI sucks at.
- They’re the ones who know when to trust and when to verify. (My rule of thumb: trust AI for anything that has clear correctness criteria and standard patterns. Be skeptical of anything security-related, performance-critical, or novel.)
- Most importantly, they’re the ones who focus their limited mental energy on truly novel problems. The parts of programming that require creativity, deep understanding of user needs, or complex system design.
With AI, I’m spending less time googling errors and more time thinking about the actual problems I’m trying to solve. I don’t need to go through pages of docs to implement third party code. My PRs are bigger, my features ship faster, and honestly? The code quality is often better because I’m less fatigued from writing boilerplate.
Here’s how I see productivity of programmers using AI vs those who are not:
AI makes you better at boilerplate and third party code, but QA takes more time. Still, this is just the start. Over time, this graph will get better in favor of those using AI.
What Happens Next
The uncomfortable truth is that AI is not optional for programmers anymore. Just like frameworks, high-level languages, and Stack Overflow before it, AI is now part of the workflow.
The developers who adjust to this new reality fastest will have the most interesting careers over the next decade. They’ll be working on problems that push the boundaries of what’s possible.
The future belongs to the developers who see AI not as a threat to their craft, but as the key that finally lets them build what they’ve always imagined, but never had the time to create.
Thanks to John, Cyrene, and Mikhail for helping me think deeper about these ideas and for sharing feedback on my drafts
P.S. My AI code reviewer is saving 15 hours/week per developer. Used by developers & teams worldwide. Check out Giga AI (7 day free trial).
