Last month I spent 30 days letting AI write 100% of my code — a real SaaS, in production, no line of app code typed by me. Then I did the thing you're supposed to do after an experiment: I went and read what everyone else thinks is happening.
So I read the discourse. Not a few hot takes — I went deep, hundreds of posts, threads, and "the end of programming" essays, from both camps. The breathless "developers are obsolete by Christmas" crowd and the smug "AI is a stochastic parrot that can't count the r's in strawberry" crowd.
Here's the strange part. They agree on almost nothing — except they all make the same three mistakes. And once you see the three, you can't unsee them, because every prediction in your feed is built on at least one.
This isn't a hype post and it isn't a doom post. It's a post about why almost every hype post and every doom post is wrong for the exact same reasons.
Mistake 1: Arguing about "can AI write code?" when that was never the bottleneck
Every post, on both sides, is secretly an argument about code generation. The optimists show a model one-shotting a working app. The pessimists show a model hallucinating an API that doesn't exist. Both think they're arguing about the future of the profession.
They're arguing about typing.
Here's what 30 days of AI writing everything taught me: the typing was never the hard part. It just felt like it was. The AI wrote my CRUD, my Zod schemas, my scaffolding — flawlessly, faster than I ever could. And it changed my output by maybe 20%, because writing the code was 20% of the job. The other 80% was knowing which code, knowing when it was subtly wrong, and knowing what not to build at all.
So when someone benchmarks a model on "can it produce a working function," they're measuring the one part of engineering that was already the least of our problems. It's like judging a surgeon on how fast they can make an incision. Speed at the easy part tells you almost nothing about the hard part.
The whole "will AI replace developers" debate is conducted in the units of the thing that mattered least.
Mistake 2: Treating the skill ladder as a fixed object
This is the one that actually matters, and nobody prices it in.
The optimist's argument: "Juniors + AI will be as productive as seniors, so we'll need fewer seniors and everyone levels up." The pessimist's argument: "AI does junior work, so junior jobs vanish and it's a bloodbath." Both of them are standing on the same hidden assumption — that the ladder from junior to senior stays where it is while AI rearranges who stands on which rung.
But the ladder is made of the work. You become a senior by doing ten thousand hours of exactly the work AI is now absorbing: the scaffolding, the boilerplate, the confident-but-wrong first draft you learn to distrust by being burned. That's not busywork you graduate past. That's the curriculum.
AI didn't replace me in my experiment. It replaced the tasks I used to hand to juniors — which means it didn't flatten the hierarchy, it sawed off the bottom rungs while making the top rungs more valuable. The static-ladder crowd is arguing about who gets to climb. The real question is who's going to build the rungs now that the thing that used to build them for free is gone.
You can't skip the 10,000 hours. You can only move where they're spent. And right now the industry is quietly deleting the place they used to be spent and assuming the seniors will keep appearing anyway, the way electricity keeps coming out of the wall.
Mistake 3: Benchmarking on the demo instead of on 2am
Every prediction — hype and doom alike — extrapolates from a demo. The optimist's demo: watch it build a todo app in 90 seconds. The pessimist's demo: watch it fail a riddle. Both are the happy path. Both are the moment of the screenshot.
Production is not the screenshot. Production is 2am, a real user doing something weird, a database blip, a double-clicked button, an empty state nobody designed.
In my 30 days the scariest thing the AI wrote wasn't code that crashed — it was code that ran. A Stripe webhook that acknowledged events before persisting them. Flawless in every test. In production, one DB blip = a paying customer with no access and no record they ever paid. It passed its own tests, because the model wrote tests that agreed with its own wrong mental model. "It compiles and the tests are green" is where the demo ends and where the real work begins.
So when a post predicts the future by pointing at a demo, it's making a claim about the 10% that's easy and staying silent about the 90% that's hard. "It ran" is not "it worked." Every extrapolation from a demo to a profession quietly swaps one for the other, and hopes you won't notice.
The synthesis: stop predicting, start structuring
Here's what I actually believe after 30 days of building and 500 posts of reading.
"Will AI replace developers?" is an unanswerable, and frankly boring, question. It's astrology for engineers. The useful question is structural, and it's answerable today:
What has to be true for AI's output to be trustworthy?
My 30 days gave me the answer, and it has nothing to do with which model wins. The thing that writes the code can never be the thing that reviews it — a model grades its own homework and always passes. You need a separate reviewer whose entire job is to refute the diff, not bless it. You need a human on the merge button who can see the blast radius the model can't. Author here, skeptic there, human owning the decision.
That's not a prediction. It's a structure. And it's the same structure whether the model is GPT-9 or something we haven't built yet, because it doesn't depend on the model being good — it depends on the model being checked.
It's also, not coincidentally, exactly how we build xenition: an agent that does the work, a different agent that tries to tear it down, and a person who owns the merge. I didn't arrive at that from a thesis. I arrived at it from 9 logged breaks on a real build, every one of which was the model waving through its own mistake.
The doomers and the hypers are both waiting to find out who wins. The people shipping are busy building the structure that makes it not matter.
So, honest question for the comments: which of the three mistakes have you caught yourself making? I made all three before the experiment beat them out of me — the demo one twice. 👇
(If this reframed the argument for you even a little, a ❤️ and a 🔖 help more than you'd think.)
Top comments (9)
The Stripe webhook example captures the exact wedge between unit execution and tail liability. When an agent generates both the implementation and the test suite, it creates an endogenous verification loop. The test passes because the verification shares the exact same invalid prior as the code. You do not discover that the model traded data durability for latency until you hit a real partition in production.
The junior hiring dilemma is the macro version of the same accounting blind spot. Treating junior engineers purely as expensive, low-throughput code typists misses that entry-level payroll was never just an expense line. It was an amortization payment on the firm's future institutional memory.
By replacing junior tasks with frontier models, engineering organizations are essentially liquidating their human capital inventory to boost quarterly margins. That looks like free leverage right up until the current senior cohort retires and the company discovers it has no organic pipeline capable of debugging an un-modeled failure at 2am.
"Endogenous verification loop" is a sharper name for it than anything I used in the post — I'm stealing that. That's exactly the trap: the test isn't a second opinion, it's the same opinion wearing a lab coat. Which is why "green tests" from a single agent is closer to a confidence interval on the model's own delusion than to evidence.
And you've put your finger on the part that actually keeps me up: junior payroll as an amortization payment on institutional memory, not a throughput line item. That reframing is the whole ballgame. The liquidation looks like margin expansion precisely because the cost is deferred and off-book — you don't see the liability until the senior cohort ages out and you reach for a pipeline that was quietly defunded years ago. It's a balance-sheet decision being made with an income-statement brain.
The grim part: the bill doesn't come due on the quarter that made the cut. It comes due on some future exec's watch, at 2am, on a failure nobody on staff has the scar tissue to read. The incentives to keep sawing off the bottom rung are almost perfect.
The only hedge I've found is structural — make "someone who can debug the un-modeled failure" a role you staff on purpose, not a byproduct you assume will keep appearing. Same reason the author can't be the reviewer: you have to build the skeptic in, because the org won't grow one for free anymore.
The missing-bottom-rung point is the strongest one. If agents absorb the mistakes juniors used to learn from, teams need an explicit replacement curriculum: reviewing bad diffs, diagnosing production incidents, and defending tradeoffs before they are allowed to supervise automation. Otherwise we get fewer junior roles now and fewer capable reviewers later.
One caveat to the “different reviewer agent” structure: independence needs more than a second prompt. If both agents share the same model family, context, and assumptions, the reviewer can reproduce the author’s blind spot with a different tone.
Both of these land, and the second one is the sharpest pushback the post has gotten — so let me not wriggle out of it.
You're right: independence isn't a second prompt, it's a second prior. Same model family, same context, same training distribution → the reviewer doesn't refute the blind spot, it re-derives it in a calmer voice. In my Stripe case a same-family reviewer would've nodded right along, because it shares the exact mental model that thought "ack before persist" was fine. That's not a check — that's an echo with better manners.
So "author ≠ reviewer" is necessary but not sufficient. What actually buys independence is divergence somewhere in the stack: a different model, or — cheaper and underrated — a different frame. Don't ask the reviewer "is this correct?" (it'll agree). Give it an adversarial job: "assume this is broken; produce the input that loses a customer's money." A skeptic hunting for the failure catches what a grader blessing the happy path never will, even from the same weights. Independence of objective partially substitutes for independence of model.
And your curriculum point is the other half of the same coin. If the reviewer role is what survives, then "can review a bad diff / can run an incident / can defend a tradeoff" stops being a nice-to-have and becomes the actual job description — and it has to be taught on purpose, because the on-ramp that used to teach it for free is exactly what we automated away. Fewer junior roles now, fewer people who can supervise the automation later. Same bill, just deferred.
And you made the mistake of judging the entire future of the industry based on making a single app and then getting tired of it, and doomscrolling a bunch of bunch of opinions.
So there's that POV my friend too XD But this is I think just ad time for you, so good luck with whatever thing you are selling right now XD
Ha, fair hits — both of them XD. It was one app, and I am building something, and I said so right in the post rather than hiding it. Guilty on the facts.
But notice the one thing I didn't do: predict. "AI replaces devs by Christmas / AI is a stochastic parrot" — those are the claims that need a big representative sample, and those are exactly the ones I called astrology. My actual claim is smaller and doesn't need n=500: the thing that writes the code shouldn't be the thing that approves it. That's not a forecast about the industry. It's true on one app or ten thousand, with today's model or GPT-9, because it doesn't depend on the model being good — just on it being checked. You can knock the sample size all day and that sentence doesn't move.
And yeah, it happens to be what I'm building — because I got burned nine times on one build and wanted the structure that catches it, not because I had something to sell and reverse-engineered a thesis. If the idea's wrong, it's wrong for free. Tear the sentence apart, not the vibe 😄
The both-camps-share-the-mistakes observation is the real find. The replace crowd and the parrot crowd are arguing about the model when the divergence is in the workflow around it - your 30 days of 100% AI-written code is really 30 days of you doing review, scoping, and recovery, which is why the same headline produces opposite conclusions depending on what the reader counts as the job. The job didn't disappear; it moved up one layer of abstraction and got less photogenic.
"Less photogenic" is doing a lot of work in that sentence and it's exactly right. That's Mistake 1 restated cleanly: the job didn't shrink, it moved to the layer nobody can screenshot. You can film a model writing a function. You can't film someone deciding the function shouldn't exist, or catching that the green tests agree with a wrong mental model. So the debate naturally gravitates to the part that photographs well — which is the part that mattered least.
And your point about "what the reader counts as the job" is the mechanism behind the whole both-camps thing. Feed the same 30 days to someone who thinks the job is typing and they see a machine doing 100% of it → replacement. Feed it to someone who thinks the job is judgment and they see a machine doing 20% of it while I did review, scoping, and recovery for the other 80% → promotion. Same log, opposite headline, and the disagreement was never about the model at all. It was about the definition of the job, smuggled in before the argument even started.
Which is why I've stopped arguing about the model. The workflow is where the divergence actually lives — and it's the one part you can build deliberately instead of wait to find out.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.