Everyone spent two years arguing about whether AI would kill the craft. Turns out it might be the thing that saves it.
Here’s a thing nobody wants to admit out loud: while half the dev community was busy writing “AI is going to take our jobs” threads, the other half was quietly shipping more software than ever before. Solo. Faster. With fewer standups.
There’s something deeply ironic about that.
For the past two years, the loudest conversation in tech has been about what AI is taking away from software development. The junior roles. The craft. The thinking. And look some of that is real. Nobody’s going to pretend the job market looks the same as it did in 2022. But here’s the angle that keeps getting skipped in all those LinkedIn hot takes: software development as a practice the act of building systems, shipping products, solving real problems with code is quietly having a moment.
Not a crisis. A comeback.
GitHub recently had to redesign its entire infrastructure to handle 30x its previous scale not because of more developers, but because agentic workflows and AI-assisted development exploded so fast the old architecture couldn’t keep up. That’s not a dying field. That’s a field that just found a second gear.
This article is about that second gear.
TL;DR: AI didn’t kill software development. It stress-tested it, stripped out the tedious parts, and handed the keys back to engineers who know what to do with them. Here’s what that actually looks like.
The myth of the dying craft
Let’s get something straight. “AI is killing software development” is doing a lot of heavy lifting as a take, and most of the people repeating it are confusing two very different things: the job market and the craft.
The job market? Yeah, it’s shifting. That’s real and worth a separate conversation. But the craft the actual act of designing systems, writing code, shipping things that work is not dying. It’s redistributing. And there’s a massive difference.
Here’s the tell: if software development were actually collapsing, you wouldn’t see GitHub scrambling to redesign its infrastructure for 30x capacity because agentic development workflows accelerated faster than anyone predicted. You wouldn’t see repository creation, pull request activity, and API usage all trending sharply upward at the same time. Those aren’t the numbers of a dying discipline. Those are the numbers of a discipline that just removed a ceiling.
Think about what the day-to-day used to look like. I remember spending a full afternoon building a pagination component. Not because it was intellectually interesting. Not because it required deep thought. Because there was no faster way. Someone had to write it, so someone did. That was the job a mix of genuinely hard problems and an enormous amount of mechanical, repetitive work that just had to get done.
AI ate the second category. Almost entirely.
And this is the part people keep misreading as loss. Calculators didn’t kill mathematicians. They killed arithmetic drudgery, which freed mathematicians to do more actual mathematics. Same play. Different stack. The pagination component was never the craft it was the toll booth before the craft.
The craft is still there. It just finally got a fast lane.
The 50-year debt AI is finally paying off
Software development has been dragging a 50-year backpack of accumulated bad decisions. Bad abstractions that got copy-pasted into frameworks. Over-engineered patterns that became industry standards before anyone could stop them. Wheels reinvented so many times they stopped being round.
Every senior dev has a version of this story. Mine involves a codebase where three different teams had independently written three different date formatting utilities none of which talked to each other, all of which were “the right way” according to whoever wrote them. Nobody meant for it to happen. It just did. Because software moves fast, documentation is always someone else’s problem, and the cost of fixing old decisions is always higher than the cost of living with them.
For decades, that debt just… compounded. Quietly. In the walls.
Here’s what’s actually interesting about AI: it’s the first thing that moves fast enough to surface and bypass that debt at the same time. Auth systems that used to take a week to spec out and another two to implement correctly? Afternoon work now. CI/CD pipelines that felt like a rite of passage the kind where you hadn’t really earned your DevOps stripes until you’d genuinely cried over a YAML indent? Scaffolded in minutes, debugged in context.
It’s not just that things are faster. It’s that old patterns are getting stress-tested at a pace humans alone never could have managed. The bad abstractions are getting caught earlier. The reinvented wheels are getting spotted before they ship.
Think of it like inheriting a house with thirty years of questionable DIY plumbing except now you have a contractor who can see every pipe in the wall before touching a single one.
The debt isn’t gone. But for the first time, we have a tool that doesn’t just add to it. Sometimes it actually pays some of it back.
That’s not a small thing. That’s kind of a big deal.
One dev, infinite surface area
Here’s the shift that doesn’t get talked about enough and it’s the one that actually changes everything.
The real unlock from AI-assisted development isn’t that code gets written faster. It’s that one engineer can now own and reason about dramatically more surface area than before. Not a little more. A lot more. Backend, DevOps, frontend, QA, monitoring the full stack of concerns that used to require four different people with four different specializations can now live inside one person’s working context.
I watched a friend ship a SaaS product in six weeks. Solo. Full auth layer, billing integration, CI/CD pipeline, a halfway decent UI. In 2020, that same scope took his startup four months with a team of three. Same person. Same skills. Wildly different output. The only meaningful variable was the tooling.
Tools like Cursor, Aider, and Claude Code aren’t just autocomplete on steroids. They’re surface-area expanders. They let a single engineer hold more of the system in their head or at least in their context window without dropping pieces of it on the floor.
This is the second chance for an archetype that never quite fit the enterprise era: the solo builder. The person who could see the whole product but never had the hours to execute all of it alone. That person now has a legitimate shot.
It’s not that one player got dramatically better overnight. It’s that the map got smaller and the spawn points moved. A solo dev in 2025 starts the game with resources that a small team in 2019 would’ve spent months unlocking.
The surface area didn’t shrink. The headcount required to cover it did.
What “good engineering” means now
Something quiet is happening to the definition of a good engineer. It’s not being announced anywhere. There’s no RFC, no industry memo, no Stack Overflow post with 4,000 upvotes explaining it. It’s just… shifting. And if you’re not paying attention, you’ll miss the transition entirely.
For most of software’s history, “good engineer” meant someone who could write correct, efficient code across a broad range of problems. The person who knew the right data structure without Googling it. Who could debug a memory leak at midnight without losing their mind. Who had enough language fluency to move fast without making a mess.
That still matters. But it’s no longer the whole game.
A colleague of mine spent three hours chasing a bug that an AI tool introduced into a service. Genuinely frustrating, genuinely subtle. Then he spent thirty minutes giving the same tool the right context the actual constraints, the edge cases, the downstream dependencies and watched it fix the bug cleanly. The skill wasn’t in writing the fix. It was in knowing exactly what information to hand over and when.
That’s the shift. Good engineering now has a new layer on top: judgment, taste, and the ability to reason about systems at a level where you’re directing work rather than just executing it.
Think less “master chef who cooks every dish” and more “executive chef who knows exactly what to order, from where, and what to do when it arrives wrong.”
AI is a very fast, occasionally overconfident intern. It needs direction. It needs someone who can spot when it’s confidently wrong which, if you’ve used any of these tools seriously, you know happens more than the demos suggest.
The engineers who’ll thrive aren’t the ones who out-type AI. They’re the ones who out-think it.
The uncomfortable truth about the second chance
Second chances come with conditions. This one’s no different, and it would be dishonest to skip past that part.
Junior developers have a harder path right now. The entry-level roles that used to absorb new grads the ones that were repetitive enough to be learnable and scoped enough to be survivable a lot of those look different now. Some are gone. That’s worth saying clearly, without dressing it up as “the market is evolving” or some other phrase that means the same thing while feeling less uncomfortable.
But here’s where it’s worth zooming out.
Every major shift in this industry looked like the end from inside it. Cloud computing arrived and everyone asked why anyone would ever manage their own servers again. Docker showed up and the “but it works on my machine” era started dying. Each time, the engineers who leaned in early who treated the new thing as infrastructure to understand rather than a threat to outlast came out with more leverage, not less.
This moment is opt-in. That’s the uncomfortable part. The second chance doesn’t land in your inbox automatically. It goes to the people who decide to pick it up.
The craft is still here. The problems are still real. The systems still need someone to design them, reason about them, and take responsibility when they fall over at the worst possible moment.
AI doesn’t do that last part. Not yet. Probably not for a while.
That gap is the opportunity.
The craft didn’t die. It leveled up.
Here’s where I land on this, for whatever it’s worth from someone who’s been watching this industry long enough to have strong opinions about tab versus space debates that nobody asked for.
Software development isn’t being replaced. It’s getting a difficulty reset. The grind that used to live in the boilerplate, the scaffolding, the “I’ve written this exact thing four times across three jobs” work that part is going away. And honestly, good riddance. Nobody got into this field because they loved writing the fifteenth variation of a user authentication flow.
The second chance is real. But it belongs to engineers who are willing to see AI as infrastructure the same way we eventually stopped arguing about whether to use the cloud and just started building on it.
The next decade of software will be built by fewer people, moving faster, covering more ground. The quality ceiling on everything they ship will depend almost entirely on the judgment, taste, and systems thinking of the humans steering it. That’s not a demotion. That’s actually a more interesting job than the one that came before it.
So the question worth sitting with isn’t “is AI taking over software development?”
It’s: are you picking up the controller or not?
Because the game didn’t end. The respawn screen just looked a lot like a warning, and most people stopped reading before the countdown finished.
Drop your take in the comments second chance or last chance? I want to know where you land.
Top comments (0)