July 13, 2025
One of the defining questions for software engineers today is whether AI will accelerate what we can do as developers, or replace our jobs entirely.
I'm not in the camp that thinks mass unemployment of software engineers is only a few years away, but change is certainly rippling through the industry. We have junior engineers entering the market who've never known a world without Cursor or ChatGPT, and companies are rushing to incorporate AI everywhere, from sales to marketing to engineering.
For those of us with years of experience building systems and products, it's hard not to ask - is this new technology going to make me better at my job, or is it going to replace me?
My working theory is that experienced software engineers have two key advantages in this shift. First, our domain expertise creates a personal context window that LLMs fundamentally can't replicate, and we should lean into maintaining that. Second, we can leverage that understanding as a foundation for acceleration - doing the hard work of learning and understanding first, then using AI to move faster when it's time to build.
My perspective comes from several IC roles at startups under 15 people building 0-1 products, where I've had significant autonomy over tool choices and workflows.
While it's true that AI democratizes software development to some extent, that doesn't make deep technical understanding less valuable. In fact, it makes true understanding more valuable.
When everyone has access to the same code-generating tools, being able to write the best prompt is one way to stand out; so is being able to evaluate output effectively, spot subtle issues, think several steps ahead, and build systems that remain reliable and functional as they grow.
Yes, AI can help you write code - entire apps, even. I'm not pessimistic about this; I use these tools now too! But what AI can't replicate is my personal context window - the accumulated understanding of this specific codebase, of my co-workers and our customers, the constraints we operate under, and how technical decisions ripple through the business. That contextual knowledge is what develops into intuition and taste - the ability to know what "feels right" in ways that LLMs fundamentally can't achieve.
In a world where an increasing portion of the workforce is "AI-native", engaging with systems and technologies on a potentially superficial level, deep domain understanding becomes not just valuable but a decisive competitive advantage.
So how do we maintain that understanding while still leveraging AI's power?
Recently I was exploring a new backend framework. My initial plan was to try the "new" way - gather all of the docs, create an outline, and then have Claude Code write most of the code. But then my engineering instinct kicked in, and something felt off – I'm building something core to the business and don't really even understand how it works. I was about to skip the cognitive work that has made my years of experience valuable in the first place.
After several experiences like this, I've started thinking about my work in two distinct modes:
Learning mode: I'm exploring a new domain, framework, or codebase. I'm building mental models and understanding the "why" behind design decisions. I'm drawing and discovering the map, Fog of War style. In this mode, I actually gravitate away from AI because sitting with confusion and complexity is part of the learning process.
Building mode: I have a clear understanding of the project and the technology and am focused on implementation. I have a mental model of where to start and how each piece of work will layer on top of each other. Here, AI can significantly accelerate my work - I have a new gas pedal under my foot that wasn't there before.
What's changed isn't my approach to learning - I've always been a learn-by-doing person who builds understanding through hands-on experience. What's new is that I now have the option to accelerate dramatically once I'm ready. Before AI, there was only one speed: learn enough to de-risk, then build (think: linear progress). Now I can choose my pace: spend time deliberately building understanding, then put my foot on the gas when I feel confident about the foundation (think: hockey stick). I don't feel comfortable accelerating until I understand what I'm working on - and leaning into that instinct feels like the right move.
AI makes it tempting to skip the struggle that actually builds expertise. The reason I can effectively review AI-generated code - spot issues, evaluate trade-offs, understand future implications - is because I already have deep domain knowledge from years of getting my hands dirty.
But here's the trap: if my job slowly turns into just reviewing AI output without continuing to build that understanding myself, those skills will atrophy. Understanding might persist through reviewing code, but taste - that sense of elegance, knowing when to abstract vs. when to keep things simple, writing code that's a joy for teammates to work with - that comes from the craft of actually writing code regularly.
In other words: you can't be an effective navigator if you stop exploring the terrain yourself.
The advantages compound over time. Engineers who don't let their engineering muscles atrophy will have a better handle on the skills that every company still evaluates in their interviews:
Engineers who skip straight to prompting without building understanding will struggle when things go wrong. They won't be able to tell the difference between elegant code and code that just works. They won't know how to debug when the AI's suggestions don't pan out. And they won't have the taste or judgment to make strong technical decisions that matter for long-term success.
I'm betting that these things will still matter, which is why I'm often slowing down before speeding up.
At the end of the day, I genuinely enjoy building software. I love working with a nicely designed framework or SDK, I love problem-solving, I love breaking down large engineering projects into smaller tasks and working through them. I love creating fast feedback loops. I love using tools that are clearly built with care and craft.
What I've found while learning to use these tools is that I actually enjoy engineering more when I maintain that connection to the fundamentals. I get to spend time understanding systems deeply, developing taste, making thoughtful decisions - and then use AI to handle the execution faster than ever before (while frequently dipping into the code myself to keep those skills sharp).
I think that combining deep human understanding with AI's speed is the sweet spot in applying these tools - and I suspect maintaining that balance will become more valuable, not less, as time goes on.