The Rise of the Invincible Software Engineer
Agentic coding is awesome. The feeling it gives you is the problem.
Agentic coding is awesome.
Let me say that plainly before the grumbling starts. Not hype. Not a demo trick. Not a passing fad that peaks at the prototype. I ship more working code before my second coffee than I used to ship in a sprint — and I’m not special. The tools got that good, that fast.
But every awesome thing has an ugly underbelly, and this one’s underbelly isn’t what you think. It isn’t hallucination. It isn’t security. It isn’t even cost.
It’s overconfidence.
This post may feel a little jaded… but I am so sick of MVPs and fake user experiences, full of bugs… PMs just blasting that agents can “do anything” cause they can write seriously buggy and immature code or script. It’s like the entire industry has completely gone nuts and forgotten that the difference between life and death is whether a customer likes our service, and the last 10% of the journey - making a quality experience - is typically what drives this customer decision.
Somewhere between the first perfect pull request and the fortieth, something shifts in an engineer’s head. The friction that used to define the job — the compile errors, the arcane docs, the afternoons lost to a missing semicolon — evaporates. And into that vacuum rushes a feeling. A dangerous, intoxicating, entirely understandable feeling.
Invincibility.
Here’s why that feeling is a trap.
Two facts that refuse to die
Two facts about software engineering have survived every platform shift, every methodology war, every hype cycle.
Fact one: the last 10% is still the most expensive part. The distance between “works on my machine” and “a Fortune 500 customer will bet their quarterly close on it” is where the money has always gone. Observability. Failure modes. Compliance. Data migration. The upgrade path nobody budgeted for. Agents compress the first 90% into an afternoon. The last 10% didn’t get the memo.
Fact two: software engineering is a team sport — and the value moved. The preponderance of value in this profession is no longer in the typing. It has fully shifted into understanding your customer: what they actually need, what they’ll actually adopt, what will survive contact with their Tuesday morning.
Hold those two facts in your head. Now watch what happens when they slam into the defining attribute of agentic coding.
AI slop or MVP? Yes.
Like most things in the LLM era, it’s nearly impossible to put a precise value — or a precise quality judgment — on the output. The code compiles. The tests pass. Is it good? Is it right? Is it done?
Depends entirely on who’s looking.
The half-empty crowd looks at agent output and sees AI slop. The half-full crowd looks at the same artifact — same commit, same diff — and sees an MVP. Two mutually exclusive realities. One codebase. And neither camp can prove the other wrong, because the traditional proxies for quality — effort, time, the seniority of the author — just got deleted from the equation.
Now add the very human urge to slow the pace down so the readers can catch up with the writers. Reviews stretch. Approvals queue. Committees convene.
Congratulations. You now have a train wreck brewing on the only question that actually matters: how do you release this software?
Five things just broke
When velocity outruns valuation, the game shifts to a new set of problems. And here’s the kicker — they’re exactly the problems that are brutally expensive to model with tokens.
One: the end-to-end test becomes the product spec.
You have to model the customer’s experience — their real workflows, their real edge cases, their real Tuesday — into E2E tests that genuinely test it end to end. This is not a happy-path canary, folks. A canary tells you the service is up. It tells you nothing about whether the customer’s job got done. Encoding that understanding is the hardest writing your team will do all year. The prompt is the design. The E2E is the spec.
Two: your pipeline is now the bottleneck.
You need CI/CD that deploys — and rolls back — software changing at a velocity nobody has ever operated at. The immutable deployment, the gold standard of the last decade, is suddenly too slow to keep up. Even stacked. And oh, right — those E2E suites from problem one? They have to run inside this pipeline. On every change. At full speed. And the common refrain is that CI/CD is a myth, nobody has achieved it, so we won’t be able to. Well, it’s basically step one of agentic development.
The real problem is that the final stage of the CI/CD pipeline has to be an actual human. The invincible software engineer often neglects this point (or is the human).
Three: every mechanism built for humans breaks.
Task tracking assumes tasks take days. Code review assumes a human wrote the code and another human can hold the diff in their head. Performance evaluation counts commits and pull requests like it’s counting keystrokes. I’m looking at you, GitHub. None of these mechanisms were designed for a world where one engineer directs a fleet.
Four: the identity crisis. Layer on the culture shock — the quiet, gnawing question every engineer is asking in the shower: what does it even mean to be a software engineer now?
Five: the doomscroll. And to top it off, the ambient radiation of LinkedIn — an infinite feed of how fast the industry is moving, how behind you are, how someone else just 10x’d something. It’s toxic. It converts uncertainty into paralysis at industrial scale.
All the mechanisms break at once. And what emerges is a power law of coping: roughly 5% of the organization figures it out — rebuilds their workflow, retools their instincts, compounds.
The other 95% are white-knuckling it.
The lazy default — and why it’s wrong
Left uncontained, this resolves the lazy way: we produce the same amount of software with 95% fewer people.
That’s the default. It is not the destiny. Because the default rests on a single assumption — that the demand for software is fixed.
It isn’t. Not even close.
Start with the analysts. IDC projects one billion new logical applications by 2028 — an explosion they attribute to the industry relentlessly lowering the barrier to creating and running software. The same firm tracked the global shortage of full-time developers growing from 1.4 million in 2021 to a projected 4 million by 2025, and pegged the cost of the broader IT skills gap at $5.5 trillion by 2026. That is what unmet demand looks like on a balance sheet.
Then the labor statisticians. The U.S. Bureau of Labor Statistics projects software developer employment growing 15% from 2024 to 2034 — five times the average across all occupations — explicitly driven by the expansion of AI, IoT, robotics, and automation. About 129,200 openings a year.
And buried in the same dataset is the detail everyone misses: “computer programmer,” the occupation defined as writing code to someone else’s spec, is projected to decline 6% over the same decade. Read that again. The typing occupation is shrinking. The judgment occupation is growing. The government’s own statisticians already drew the line I’m arguing about.
Then the economists. When DeepSeek rattled the markets in early 2025, Satya Nadella reached for a 160-year-old idea: Jevons paradox — the observation that making a resource cheaper to use doesn’t shrink demand for it; it detonates demand. Coal then. Compute now. Software next. And I’ll give you the honest caveat straight: the rebound in software demand does not automatically rescue every software engineer. It rescues the ones who move to the work that can’t be automated.
Which is precisely my point.
Is the world demanding exactly 10x the software? I don’t know. Nobody does. But every credible signal — analyst forecasts, labor projections, basic economics — points the same direction, steeply. The demand curve is not the problem.
Our aim is.
The flight to the legible
Which brings me to the part of this shift that genuinely worries me.
Engineers are flooding toward the tasks that are easiest to see and least ambiguous to grade. I see this in my team. Feeling good happens to be the gradient that apparently all developers gravitate towards.
I could’ve seen this coming a mile away — because it’s rational. Working backwards from a customer is taxing. It’s ambiguous. It’s political.
It involves talking to humans who don’t know what they want until you show them the wrong thing twice. So engineers gravitate to the fun, legible problems instead: the CI/CD pipeline, the dev process, the agent harness, the eval framework. And there is a new spin on it - skills, workflows, harnesses, de jour. I’m starting to call it agentic development <insert adult literature term>.
(Note to developers looking to grow their career - find, research, spy, or invent a customer problem to solve. Or make the pipeline super safe and fast. Two options. Pick.)
Here’s the brutal part. Legible is exactly what gets automated next. The plumbing — however elegant — is replaceable. Replaceable by the next tool, the next agent, the next platform release.
Customer obsession and insight is not fungible.
So now I have to teach engineers to become product managers?
Probably? Let’s just be honest about it. If the durable value of a software engineer is customer understanding, then I am, in effect, signing up to convert an entire profession into something adjacent to product management — while it’s mid-flight, mid-identity-crisis, and mid-doomscroll.
And “go be more customer obsessed” is a poster, not a plan. Good intentions don’t scale. Mechanisms do.
So here are five mechanisms. Not a curriculum — a machine.
1. Make the E2E suite the customer document. Working backwards, but executable. No feature work begins until the customer journey exists as a running end-to-end test, written in the customer’s language, covering the ugly paths — the expired credential, the half-migrated tenant, the user who clicks back twice. Here’s why this works as training: you cannot write that assertion without understanding the customer. The test suite becomes the spec, the spec becomes the curriculum, and the curriculum compiles. Fakeable in a doc. Not fakeable in an assertion.
2. Build a customer flight simulator. Take everything you already know about your customers — support tickets, sales-call transcripts, telemetry, win/loss notes — and stand up synthetic customer panels an engineer can interrogate before writing a line of code. Pitch the feature to the simulated CFO. Watch the simulated admin fail to find the button. Pilots don’t attempt their first crosswind landing with passengers aboard; engineers shouldn’t attempt their first customer conversation with a real customer’s roadmap on the line. Simulation isn’t a substitute for real customers. It’s reps. And reps are the thing that never scaled before. I do this myself. I recommend it.
3. Measure what you actually want. Commit counts and PR velocity were always weak proxies; now they’re actively corrupt — the agent inflates them for free. Rebuild evaluation around customer artifacts: journeys authored, adoption moved, defects escaped on customer-critical paths, time-to-insight on a customer problem. Promotion requires demonstrated customer understanding, in writing, with receipts. What you measure is what you get — and right now, most organizations are measuring typing.
Side note: revenue is not actually the right proxy - it is uncontrollable. And you don’t want your developers becoming sales reps. Rather, you want them to be unlocking workloads and value. Kill the FDE team concept - it’s just one development team, and it creates a false and flimsy differentiation. You don’t need that till you scale.
4. Rotate everyone through the pain. Every engineer does time in the support queue. Every engineer shadows customer calls. Every engineer reads the win/loss reviews. And here’s the mechanistic part — AI removed the excuse. Transcription is free. Summarization is free. The only thing that still costs anything is the synthesis, so that’s the deliverable: you sit in the calls, you write the voice-of-customer digest, you present it, you defend it. The empathy isn’t the assignment. The insight is.
5. Pave the ambiguous path. Engineers follow gradients the way water follows slope. Today, the customer-first path is uphill: the tooling makes it trivially easy to scaffold a repo and brutally annoying to encode a customer journey. Flip the gradient. Make the project scaffold start from a journey, not a directory structure. Make the PR template demand the customer link before it shows the diff. Make the dashboard open on customer truth, not build status. When the taxing path becomes the paved path, people walk it — without a single motivational speech.
Invincible, redefined
The invincible software engineer was never going to be the one who ships the most code. The agents took that title, and they are not giving it back.
Invincibility was never about output. It’s about being irreplaceable.
And in this entire stack — the models, the pipelines, the harnesses, the process — exactly one thing cannot be replaced: the person who truly understands the customer.
The tools will change. The pipelines will change.