For six years, I’ve been a software engineer, C#, .NET, React, Azure, the whole stack. In that time, the way I write code has changed more than in all the years before it. The code that used to take me a day now takes an hour.
And yet, I’ve never felt more essential to a project.
That contradiction is worth sitting with, because I think a lot of engineers are quietly anxious about it. Let me tell you what I’ve actually seen, from the inside of real teams shipping real software.
The bottleneck moved
When I started out, the scarcest resource on a team was code output. Typing out features was the slow part. Everything, sprint planning, estimates, hiring, was built around the assumption that producing working code was expensive.
AI tooling flattened that assumption. The bottleneck isn’t writing code anymore. It’s deciding what deserves to exist.
That sounds abstract, but it shows up in very concrete ways. On a recent project, I watched a feature go from prompt to working prototype in an afternoon, something that would have been a two-week ticket in 2021. The code was good. Clean, even. But the feature itself was wrong. It solved a problem our users didn’t have, in a way that would have been a maintenance bomb six months down the line. The AI did exactly what it was asked. The asking was the failure.
What hasn’t gotten easier: knowing what to build, how systems fit together, and when to say no to the feature that sounds good in a demo and rots in production.
What I tell juniors now
Don’t race the AI on output. Race it on judgment.
I get the temptation, when a tool can scaffold in seconds what took you a week to learn, it’s easy to feel like your learning was wasted. It wasn’t. The most valuable thing you can build right now is an understanding of why systems are shaped the way they are. Why does this service exist? Why does the data flow this way? Why was this trade-off made?
That knowledge doesn’t compress into a prompt. It’s the context that turns you from someone who generates code into someone who owns outcomes. When you review AI-generated code, and you will, constantly, your judgment is the thing being paid for. The senior in the room isn’t the one who types fastest; they’re the one who says “this looks right but it’ll break under this specific failure mode” before it ships.
If you’re early in your career: get your hands dirty in the fundamentals. Read the codebase. Ask why the architecture looks the way it does. That understanding compounds, and AI can’t shortcut it for you.
What I tell seniors now
Your experience is worth more than ever.
Nobody prompts their way into understanding failure modes, trade-offs, and the politics of a good API design. The things that took you years, the outage at 2am that taught you why idempotency matters, the migration that went sideways and taught you to ship incrementally, that’s the taste that AI-generated output needs.
The bottleneck moved. It used to be writing code. Now it’s deciding what deserves to exist.
I’ve stopped measuring my days by lines of code. I measure them by the number of bad ideas I killed early, the number of systems I kept simple, and the number of juniors who are learning to ask “why” before they ask “how fast.”
The honest version
I’m not going to pretend there are no hard questions here. Some roles that were purely about translating specs into code will shrink. That’s real, and it matters for people’s livelihoods. But engineering was never really about typing. It was about understanding a problem deeply enough that the solution becomes obvious, and then, yes, typing.
The engineers who are thriving right now aren’t the ones who refused the tools or the ones who surrendered to them. They’re the ones who let AI do the mechanical work and spent the freed-up hours on the part that was always the actual job: thinking.
Taste was always the job. We just couldn’t see it while we were drowning in boilerplate.
What do you think, what’s the one thing in your stack that AI genuinely can’t do yet?
