The models generate faster than you can type, but they do not own the architecture, the responsibility, or the judgment about what is worth building. A grounded take on staying valuable as a developer: fundamentals, communication, and building something unmistakably yours.
Yogesh Mishra
11 hours ago10 min read
There's a specific kind of dread floating around developer communities right now. Scroll through any timeline and you'll find someone announcing that the profession is over, that the models write the code now, that the junior pipeline is dead and the seniors are next. It's loud, it's confident, and it's worth taking a breath before you let it rewrite your career plans.
I recently watched an interview on YouTube with Scott Hanselman, VP of Developer Community at Microsoft, and the thing that stuck with me wasn't a prediction about the future. It was a reminder about the past. Because we have been here before, more than once, and every single time the panic followed the exact same script.
AI TL;DR
The panic is a rerun. Every major jump in tooling (high-level languages, garbage collection, syntax highlighting, autocomplete) was first mocked as a crutch, then became the floor everyone stands on. - AI is a power tool, not a craftsperson. It's great at generating code and bad at deciding what code should exist. Architecture, data modeling, and understanding the real problem are becoming the majority of the job. - Agency is the whole game. The model doesn't carry the pager. Treat its output like a PR from a stranger: read it, understand it, own it. - Build a career on three things: deep fundamentals, real communication, and a project that is unmistakably yours. - Juniors still learn. The reps just moved from typing code to understanding it. Use the model as a tutor you interrogate, not an oracle you obey.
The "death of coding" is a rerun, not a premiere
// tags AI · Career · Engineering · Craft
— Reactions
If this hit, tap a reaction. It tells me what to write next.
Every meaningful jump in developer tooling has arrived wearing the same costume: a promise to some, a threat to others. When assembly gave way to higher-level languages, the old guard warned that nobody would understand what the machine was actually doing. When garbage collection removed manual memory management from the day-to-day, people said it would breed a generation of programmers who couldn't reason about resources. Stack Overflow showed up and the refrain became "these kids just copy answers, they can't think."
My favorite example, though, is the small stuff. There was genuinely a time when using syntax highlighting marked you as a lesser programmer, real developers read monochrome text and kept the structure in their heads, thank you very much. There was a time when turning on autocomplete or IntelliSense meant you didn't really know the language or the API. Think about how absurd that sounds today. Nobody is bragging about disabling their editor's autocomplete to prove their worth. Those tools didn't make us weaker; they moved our attention up a level, away from remembering exact method signatures and toward the actual problem we were trying to solve.
That's the pattern. Each abstraction gets mocked as a crutch, then quietly becomes the floor everyone stands on. AI-assisted coding is the newest layer, and it's provoking the loudest version of the reaction precisely because it's the most capable tool we've had. But the shape of the story is old. Understanding that shape is the first thing that lets you stop panicking and start positioning yourself.
AI is a power tool, and power tools don't design the house
Here's the distinction that actually matters in practice: AI is extraordinary at generating code and genuinely bad at deciding what code should exist.
Give a model a well-scoped function and it will write it faster than you can. Give it an ambiguous, sprawling system and it will happily produce something that runs, and is quietly a mess underneath. Left unsupervised, it drifts toward god objects, tangled responsibilities, and abstractions that look reasonable in isolation but don't compose into a coherent architecture. It optimizes for "this compiles and does the thing" because that's what it was rewarded for, not for "this will still make sense to a team in eighteen months."
The failure mode worth watching for isn't the code that's obviously broken. You catch that instantly. It's the code that's confidently plausible. Ask for a function to fetch and cache user data and you'll often get something that works perfectly in the demo and hides a landmine: an unbounded cache that leaks memory, a race condition when two requests arrive at once, an N+1 query that's invisible at ten users and fatal at ten thousand, a swallowed error that turns a real failure into silent bad data. None of that shows up in a quick read. It shows up in production, three weeks later, as a graph nobody can explain. The model wasn't lying; it was answering the question you asked, not the question you actually needed answered. Knowing the difference between those two questions is the job.
The carpentry analogy is the one that landed for me. A table saw made furniture-making dramatically faster, but it never once decided what to build or whether the joinery would hold. The saw handles the cutting so the craftsperson can spend their judgment on proportion, structure, and how the whole thing fits together. AI is that saw for us. It absorbs the mechanical toil (boilerplate, translations between formats, the tenth CRUD endpoint that looks like the previous nine) and hands you back the time to do the part that was always the real job: deciding what to build and how the pieces should relate.
Architecture, data modeling, understanding the actual human problem behind the ticket: none of that is being automated away. If anything, it's becoming the majority of what "engineering" means, because the typing part just got cheap.
Agency is the whole job now
This is where I think a lot of developers are going to sort themselves into two camps.
The uncomfortable truth is that these models are, in Hanselman's framing, sycophants. Ask for code and you get code, enthusiastically, without pushback, without a moment of "are you sure this is a good idea?" The model does not carry the pager. It will not get the 3 a.m. call when the thing you shipped falls over in production. It doesn't feel the consequences of a bad decision because it has no stake in the outcome. You do. That asymmetry is the entire game.
“
Treat every AI-generated block like a pull request from an anonymous contributor you've never met.
You would never merge a stranger's PR without reading it, understanding why it works, checking the edge cases, and running it through your tests and review process. AI output deserves exactly that same suspicion. Fold it into your normal software development lifecycle instead of treating it as a shortcut around the lifecycle. The moment code lands in your repository, it's yours. The model's name isn't in the git blame, and it certainly isn't in the incident retro.
In practice, the review is the same one you'd run on any teammate's work. You've just stopped skipping it because the code arrived quickly.
Reviewing AI output like the PR it is
1
Can I explain every line?
critical
If a block works and you cannot say why, you have not reviewed it; you have adopted it. Read until you could defend it in a design discussion. Anything you would not write yourself, you should at least fully understand.
2
Where does it break?
critical
Null inputs, empty arrays, concurrent calls, the network failing halfway, the 10,000th record instead of the 10th. The happy path is the part the model gets right. The edges are where your judgment earns its keep.
3
Does it fit the system we already have?
important
A locally correct block can still be globally wrong, duplicating an existing utility, ignoring your error-handling conventions, introducing a third way to do a thing you already do two ways. Consistency is architecture.
4
Is it tested and observable?
important
Run it through the same tests, types, and linting as everything else. If it fails at 3 a.m., will the logs tell you why? Code you cannot debug in the dark is a liability no matter who wrote it.
That pause, that refusal to be a slop cannon, is a differentiator now, not a weakness.
How to actually build a career from here
If AI handles more of the typing, then the things that were always underneath the typing become the things that define you. Three of them stand out.
Own the fundamentals like your career depends on it, because it does
When you drive an automatic transmission, you never think about the gears, right up until the car breaks down on a hill and you desperately wish you understood what was happening underneath. AI tools are that automatic transmission. They're wonderful when everything's smooth and useless the instant something subtle goes wrong. The developer who understands how HTTP actually works, what DNS is resolving, how a distributed system fails under partition, how a database chooses a query plan, how memory and connections and queues behave under load, that person can debug the situation the model confidently got wrong. Knowing how to drive the stick shift is what makes you the person in the room who can fix it when the automation runs out of road. Fundamentals were always valuable; now they're the thing that separates you from someone who can only prompt.
Communication is not a soft skill. It's the core one
As the mechanical act of writing code gets commoditized, your ability to explain your reasoning, justify a design tradeoff, write a clear proposal, and align a team on a direction becomes the scarce resource. An engineer who can articulate why they chose eventual consistency over strong consistency, and defend it against pushback, is doing something no model does on your behalf. Interviews reward it, teams promote for it, and honestly it's what makes the difference between a coder and an engineer.
Build something that is unmistakably yours
This is the advice I'd tattoo on every portfolio. Stop shipping another Tic-Tac-Toe, another Minecraft clone, another to-do app that looks like the last ten thousand to-do apps. Those prove you can follow a tutorial; they prove nothing about your judgment. Build the thing only you would build, a tool for your family, your community, a problem from your own life that nobody handed you as an assignment. That kind of project demonstrates high agency, genuine problem-solving, and the willingness to sit with an ambiguous human need and turn it into working software. It's the single most legible signal that you're the kind of engineer worth hiring, precisely because it can't be generated on demand.
"But how does a junior ever learn this now?"
This is the objection I take most seriously, because it's the one with real teeth. If the model writes the boilerplate a beginner used to grind through, where do the reps come from? How do you build intuition for a system you never had to struggle against?
I don't think the answer is to ban the tools and grind manually out of nostalgia. That's the syntax-highlighting argument again, refusing the floor everyone else is standing on. The answer is to change what you struggle with, on purpose.
The developers who come up in this era won't be weaker because they had AI. They'll be weaker only if they let it think for them instead of with them. Read the code you didn't write. Break it on purpose. Rebuild the thing by hand once, just to feel where the hard parts are. The reps are still available; they just moved up a level, exactly like they did every time before.
§
The takeaway
Don't let the noise reprice your ambition. Use AI the way you'd use any excellent tool: to move faster, to learn quicker, to offload the toil. But never confuse the tool for the craftsperson holding it. The models don't own the architecture, they don't own the responsibility, and they don't own the judgment about what's worth building in the first place. You do.
Every previous wave of tooling ended the same way: the people who leaned in and kept their fundamentals sharp got dramatically more powerful, and the tools they were once told to fear became the ordinary floor beneath their feet. This wave won't be different. If you care about the craft, this might genuinely be the best time in history to be building software, as long as you remember, through all of it, that you are still the engineer.
