loading…
[OK] dns resolved
[OK] tcp handshake
[..] waiting on payload
A lot of the current AI conversation is still trapped in the easiest possible frame: can the model produce code?
Sure. So can the intern. So can the senior engineer. So can the developer who has been awake for nineteen hours and should absolutely not be touching production.
Code generation was never the full game.
The hard part of software has always been what happens after the code exists. The bug report with no reproduction steps. The memory leak that only shows up under Friday traffic. The deploy that technically succeeded but quietly poisoned a background queue. The customer escalation where three systems all claim the other one is lying.
That is why I keep saying the same thing in slightly different ways: AI can absolutely write the function. It still cannot own the pager.
And if you don't understand that distinction, you're going to make some very expensive decisions over the next few years.
We're living through a phase where people watch a model generate 300 lines of decent-looking code and immediately jump to, "well, I guess engineers are getting replaced."
No. What you're seeing is compression of one part of the job.
Writing code matters. It is not trivial. But a production engineer is not paid mainly for making new text appear inside a file. They are paid to make systems behave under conditions that are adversarial, ambiguous, and expensive.
Those are different jobs.
If your mental model of software engineering is "person types syntax into editor," then AI looks like a total replacement event.
If your mental model is "person takes operational responsibility for systems that interact with money, customers, data, and other humans," then the picture changes fast.
The model can suggest ten ways to implement a retry loop.
It cannot feel the blast radius of being wrong when the retry loop turns a partial outage into a self-inflicted denial-of-service event.
That's not poetry. That's the actual job.
"Owning the pager" is shorthand, but I don't just mean literally responding to an alert at 2:13 a.m.
I mean owning consequences.
That includes:
AI is weak at almost all of that unless a very competent human has already framed the problem, constrained the options, and built a verification loop around it.
In other words, the more real-world the problem gets, the more the human job shifts from typing to judgment.
That's exactly why senior engineers are not becoming obsolete. If anything, their role is getting easier to misunderstand and more valuable at the same time.
A lot of AI-generated code looks impressive in the same way a movie set looks impressive. From the right angle, with the right lighting, it absolutely resembles a building.
Then you push on the wall and realize it's plywood.
The reason demos feel magical is that demos remove most of the forces that make software hard:
Production reintroduces all of that immediately.
This is also why I don't find "the AI built a clone in thirty minutes" arguments very persuasive anymore. Great. Now let it survive six months of real usage, a rushed feature request from sales, three new engineers touching the codebase, one surprise database migration, and an outage where the logs are missing the one line you actually need.
That's when we learn whether we built a product or a hallucination with a deploy pipeline.
Most engineering orgs do not have a "not enough code is being typed" problem.
They have one or more of these problems instead:
AI helps most with the part that was already the cheapest to accelerate: initial implementation.
That is still useful. I use these tools. Most good engineers should.
But let's be adults about where the real bottlenecks live.
A team that already has strong architecture, decent tests, good review habits, and operational discipline will get a serious productivity boost from AI.
A team that lacks those things will just generate mistakes faster, with better grammar.
That's the uncomfortable part people keep trying to skip.
This is the framing I keep coming back to.
Imagine an eager junior engineer who:
That person would be valuable, right?
You'd use them constantly.
You would also not hand them the production checkout service, say "you've got this," and leave your phone on silent.
That's how a lot of teams are using AI right now. Not as leverage for supervised engineers, but as a story they tell themselves to justify lowering the amount of judgment in the loop.
That works exactly until reality sends an invoice.
The engineers who benefit most from AI will not be the ones who treat it like a replacement brain.
They'll be the ones who turn it into a force multiplier inside a disciplined system.
That means a few practical things.
Generate the migration draft. Suggest the refactor. Write the boilerplate. Summarize the failing test surface. Offer three implementation paths.
All good.
"Design the architecture, implement it, secure it, ship it, and tell me if it's safe" is where people start pretending the model has earned responsibility it has not earned.
A clean explanation is not proof.
A passing happy-path demo is not proof.
Strong engineers will ask:
That habit is going to separate real engineers from prompt tourists in a hurry.
If AI makes implementation cheaper, then operational ignorance gets more expensive.
You do not need every engineer to become a world-class SRE.
But you do need more engineers who understand deploy mechanics, rollback strategy, observability, incident response, queue behavior, caching, timeouts, data integrity, and dependency blast radius.
The more code your team can generate, the more important it becomes to understand the environment that code has to survive in.
This is the part junior engineers should pay attention to.
If you want leverage in the AI era, don't obsess over sounding clever in prompts. Learn how to inspect outputs. Learn how to trace a bug from symptom to cause. Learn how to reason about tradeoffs. Learn how to ask, "what breaks if I'm wrong?"
That skill stack ages a lot better than being the fastest person in the room at generating mediocre CRUD.
AI is probably going to reduce the market value of engineers who only add value at the syntax layer.
That part is real.
If your whole contribution is turning clear instructions into straightforward code, you are standing in the blast zone of automation.
But that does not mean engineering value disappears.
It means the premium shifts.
More of the value moves toward:
In other words, the parts of the job that become more important when output gets cheap.
When everyone can generate code faster, the differentiator becomes who can keep the system legible, resilient, and sane.
That person is not obsolete.
That person is suddenly the adult in the room.
AI will absolutely keep eating the shallow, repetitive, low-context parts of software work.
Good.
It should.
But the idea that this means software engineering collapses into prompt vending is mostly the fantasy of people who have never had to own a production incident with real customers attached to it.
The code was never the entire job.
The job is responsibility.
The job is judgment.
The job is making sure the system still behaves when reality stops cooperating.
So yes: let the model write the function.
Then ask the more important question.
When the alert fires at 2 a.m., who do you actually trust to decide what happens next?