DEV Community: Info Inlet

Everyone's learning to prompt better. That's the wrong skill.

Info Inlet — Sat, 26 Sep 2026 05:18:08 +0000

I have a bookmark folder called prompting. Forty-one tabs in it.

"The 12 prompts that 10x your engineering." "Context engineering for agents, explained." "The system prompt that changed how I ship." A course I finished at 1am, certain I'd finally cracked the thing — that if I just learned to ask well enough, the output would come out right.

I built that folder the same way I once built a GitHub full of dead repos: convinced the scarce skill was the one everybody was selling me.

It wasn't. And I want to say the thing nobody says at the top of the "master prompt engineering, learn context engineering, become an AI-native engineer" sermon:

Getting better at prompting is getting better at the wrong skill. Not a useless one — the wrong one. And the reason is worse than "the models will get better and the prompt won't matter." That's true, but it's the boring half. The sharp half is that even a perfect prompt can't touch the thing that was actually going to hurt you.

Stay with me, because this isn't a doomer post. There's exactly one skill in this whole stack that's still worth every hour — and the logic is what tells you which one.

The three things we tell ourselves about why prompting is THE skill

Nobody grinds prompt guides for no reason. You do it because you believe one of three things:

It'll make the output better. ("Better prompt, better code. Obviously.")
It'll make me employable. ("'AI-native,' 'prompt engineer' — this is the moat now.")
It's the new literacy. ("This is the fundamental skill of the era. Learn it or fall behind.")

All three are real motivations. All three are, as usually practised, pointed at the wrong target. Let me take them one at a time, because the miss is instructive — it points straight at the one skill that survives.

Belief #1, because it's the load-bearing one: a better prompt can't catch the bug that hurts you

Let's do the one everybody believes hardest.

Yes, a better prompt gets you better-looking output. Cleaner structure, fewer obvious mistakes, code that reads like a senior wrote it. That part is real. Here's the part the courses skip:

A better prompt raises how convincing the output is. It does nothing to whether it's correct. And those two dials were never connected.

Think about the failure mode that has actually cost you. It was never "the AI misunderstood me and produced obvious garbage" — you catch that in two seconds. The one that hurts is the opposite: the output that matched your request perfectly, read beautifully, passed the tests you thought to write, and was still wrong in a way you only discovered in production. Plausible. Confident. Broken.

Now watch what a better prompt does to that failure. It makes the output more polished, more authoritative, more obviously-fine at a glance. Which means the wrong ones get harder to catch, not easier. You didn't improve your defense. You upgraded the disguise on the thing you were supposed to be defending against.

That's the whole trap in one line:

A better prompt just gets you to a more convincing wrong answer, faster.

You cannot prompt your way out of this, by construction. The correctness of the answer isn't decided at ask time. It's decided at review time, on your side of the desk, by whether you can look at a clean, confident diff and say no. Prompting optimizes the question. The bug lives in the answer.

Belief #2: prompting is recall wearing a new hat

"But it's a moat. 'AI-native' is what gets hired now."

Here's what nobody wants to hear about their new favorite skill: prompting is recall. The same recall AI just made worthless, re-manufactured one layer up and sold back to you as expertise.

For twenty years, "knowing how to code" was quietly two different things bundled together: recall — the syntax, the API surface, the flag order, the incantation — and judgment — knowing what to build, what to distrust, what breaks at 2am when a real person does something strange. AI ate recall first, and good riddance; it was never the valuable part. Testing for it in 2026 is testing for penmanship.

So what did we do? We rebuilt recall at a higher altitude. "The exact phrasing that makes the model behave." "The context pattern that gets the right output." "The system-prompt incantation." It's the same muscle — memorize the magic words, produce the output — just moved up the stack. We fled the thing AI made free and ran straight into a fresh version of it.

And this version has a shrinking half-life. Every model release infers your intent better than the last. The gap between a novice prompt and an expert prompt narrows with each update, because closing that gap is literally what the labs are optimizing. You are grinding a skill the vendor is actively deleting. You cannot build a moat on the exact thing your supplier ships as a feature next quarter.

Belief #3: the fundamental was never the asking

"Fine — but it's the new literacy. The base skill everything else sits on."

The fundamental skill of working with a system that produces confident, plausible, occasionally-wrong output was never how you ask it. It's what you do with the answer.

Prompting is a UI over the model — and UIs get better on their own, without you. Distrust is a stance toward the output — and it's the one thing that doesn't improve while you sleep. One is a feature. The other is a muscle only you can carry into the room.

There's a completely different skill hiding under "get good at AI," and it only shows up under one specific condition — when the output is wrong and everything about it looks right:

A better prompt produces more convincing output. Only distrust decides whether it's right. The asking is free now — the refusing is the entire job.

You don't earn that by writing better prompts. You earn it by shipping a confident answer to a real person, watching it break, feeling the consequence — and carrying the scar into every diff after. That's the forge. Everything before it is a tutorial with better phrasing.

The moment a perfect prompt handed me a perfect-looking disaster

Let me make this concrete, because I earned it the expensive way.

I once shipped a write path that acknowledged the request before it had actually persisted the row. The prompt that produced it was clean. The code that came back was clean — it read like something a careful engineer wrote. In the demo, in the tests, on my machine: flawless. Exactly what I asked for.

Then one day a retry hit at the wrong moment. The ack went out, the save didn't land, and a paying customer got locked out of their own account with no record they'd ever done the thing. Ack-before-persist. I can still feel it.

No prompt was going to save me there. A better prompt would have made it worse — cleaner code, more convincing, even harder to doubt. The thing that would have caught it wasn't a sharper question. It was the trained reflex to look at a diff that acknowledges before it persists and think that breaks under a retry — before a real human's bad night taught it to me.

That reflex is distrust. It's the only skill in this whole stack that AI can't hand you, can't improve for you, and can't make obsolete. It's the one line on my résumé that would've been worth an entire interview — and no course sells it, because you can't.

Be clear about what I'm actually saying — because it's not "stop prompting"

I am not the guy telling you prompting is beneath you. I prompt all day. AI writes most of my code and I'd never go back — the typing was never the hard part, and neither is the asking. Prompt well. A sloppy prompt wastes everyone's time, yours included.

What I'm saying is narrower and, I think, freeing:

Prompting is table stakes, not the edge. It's the cost of entry now, like knowing how to use a keyboard — necessary, and worth exactly zero as a differentiator, because everyone has it and the tool keeps closing the gap. Grinding it harder is polishing a skill whose ceiling the vendor lowers every month. The edge — the only part that compounds — is what you do after the model answers:

After the AI answers, before you accept it, try to break it. Ask what it does under a retry, at 2am, when the input is hostile, when the customer does the dumb thing. Attack the answer instead of admiring it.
Make something other than the author be the skeptic. The thing that produced the diff is the worst possible judge of the diff — it's proud of it. The doubt has to come from a different seat.
Ship it to someone who can hurt you. That's the only way the wrong ones actually cost you, and cost is the only thing that grows the muscle. A distrust you never had to use isn't a skill. It's a slogan.

Do that, and you're building the one thing that survives every model release. Skip it, and you're the guy with a beautiful prompt library who can't tell when the beautiful answer is going to lock a customer out at 2am.

Why this is the exact reason I build the way I do

Here's the part that goes one level up, because it's the same logic.

I build an agent platform, and the temptation in this whole industry right now is to worship the author — the thing that generates. Look how well it responds to a good prompt! Look how clean the output is! But an author that produces gorgeous, confident output is producing gorgeous, confident output whether or not it's right — and a better prompt only turns the polish up, never the truth. The convincing-ness and the correctness are two different dials, and the whole market is cranking the one that doesn't matter.

So I never let the thing that writes the code be the thing that blesses it. There's an author that produces the diff — prompt it as well as you like. There's a separate skeptic whose only job is to try to break the diff rather than admire it — institutionalized distrust, the "no" made into its own seat. And there's a human on the merge button who can see the blast radius the model can't. That separation — author, skeptic, human — is the whole shape of xenition, and it's the same lesson the bookmark folder taught me: asking is free and getting freer; deciding whether the answer survives contact with reality is the entire job. The prompt is cheap. The "no" is the product.

Your folder of prompt guides isn't a sign you're serious. It's a sign you were optimizing the free thing. Stop grinding the question. Learn to doubt the answer.

Honest question for the comments: what's the most convincing, cleanest, best-prompted AI answer you ever rejected — and how did you know to say no? I want to hear about the one your distrust caught, not the one your prompt produced. 👇

(If this made you close a few prompt-guide tabs with a little less guilt, a ❤️ and a 🔖 help it reach the next person grinding the wrong skill on a Saturday.)

Stop building side projects. Nobody cares — and here's the uncomfortable math.

Info Inlet — Wed, 23 Sep 2026 05:48:57 +0000

Open your GitHub. Go on. Count the repositories that have a README, a clean commit that says initial commit, maybe a second one that says wip, and then… nothing. No third commit. No user who isn't you. No issue filed by a human you've never met.

I'll wait.

I count nine on mine. Nine little tombstones. A URL shortener. A habit tracker. Two different note-taking apps because I didn't like how the first one turned out. A "Twitter but for X" from a week I should have been sleeping. Each one started on a Saturday with the specific electric feeling that this was the one, and each one died on a Wednesday when the part that was actually hard showed up.

I built the graveyard. Most of us did. And I want to say the thing nobody says at the start of the "build in public, ship every weekend, your portfolio is your résumé" sermon:

Nobody cares about your side project. Not one person. And the math on why is worse than you think.

Stay with me, because this isn't a doomer post. There's exactly one kind of side project that's still worth every hour — and the math is what tells you which one.

The three lies we tell ourselves before the first commit

You don't build a side project for no reason. You build it because you believe one of three things:

It'll teach me. ("I'll finally learn Rust / Kubernetes / that framework.")
It'll get me hired. ("Recruiters will see this and know I'm serious.")
It'll make me money. ("Maybe this one's a business.")

All three are real motivations. All three are, as usually practised, mathematically doomed. Let me take them one at a time, because the doom is instructive — it points straight at the one version that survives.

Lie #2 first, because it's the load-bearing one: nobody is reading your code

Let's do the one everybody believes hardest.

A recruiter has never, in the history of hiring, cloned your repo. They have not read your code. They did not git log your commit hygiene at midnight and think ah, a craftsman. The eye-tracking studies on résumés put the average first pass at somewhere around six or seven seconds — and your GitHub link, if it's clicked at all, gets the profile page, the green squares, and a scroll. That's it.

Here's the part that actually stings, and it's new. The day an AI could scaffold a polished, deployed, nice-looking side project in an afternoon, the signal value of "I built a side project" fell to zero. Not low. Zero. Because the thing the portfolio was supposed to prove — "this person can take an idea to a running app" — is now something a motivated teenager does over lunch with a chat window. You cannot signal scarcity with a thing that just became free.

So the résumé math is: N polished repos × (signal that anyone can now generate for free) = 0. Adding more repos multiplies zero. It's still zero. You cannot out-volume a value that collapsed.

Lie #3: the user math is even more brutal

"But maybe it's a business."

Okay. Count your users. Not signups — the number who came back on day seven and did the thing again. For nine out of ten side projects that number is, precisely, one. You.

10 side projects × 0 real users each = 0. And here's the trap the AI era set: it made the building free and did nothing about the zero. The hard part of a product was never the code. It was getting one stranger to care, come back, and hurt you when it broke. AI compressed the easy 20% — the typing — to nothing, and left the impossible 80% — distribution, retention, trust — exactly as impossible as it always was. So the modern graveyard fills faster than ever, because building the tombstone got cheap and burying it still costs the one thing nobody can generate: another human's attention.

Lie #1 is the only one with a survivor in it

"Fine — but at least I learned something."

Did you? Be honest about what.

If you followed the shape of a tutorial, wired up the same auth-and-CRUD you've wired up before, deployed it, screenshotted it, and moved on — you produced output. A thing that exists. And output, again, is now free. You learned the syntax, the flag order, the incantation. That's recall, and recall is the part AI ate first and you're better off without.

There's a completely different thing hiding inside "I learned something," and it only shows up under one specific condition:

A side project produces output. Only a side project with a real user who can hurt you produces judgment. Output is now free. Judgment is the entire game.

You do not earn judgment by building. You earn it by shipping to someone who can churn, complain, refund, and file a furious bug at 2am — and then living through the consequence. That's the forge. Everything before it is a tutorial with your name on the commit.

The one project that was worth all nine tombstones

I have one repo that isn't in the graveyard. One thing I shipped that a real, paying stranger actually used.

And it taught me something no tutorial could, because it cost me a real person's bad night. I had a write path that acknowledged the request before it had actually persisted the row. In the demo, in the tests, on my machine — flawless. Then one day a retry hit at the wrong moment, the ack went out, the save didn't land, and a paying customer got locked out of their own account with no record that they'd ever done the thing. Ack-before-persist. I can still feel it.

No course gave me that. No amount of scaffolding a tenth side project would have. I earned it the slow, expensive, humiliating way — because there was a real human on the other end of the glass who could be hurt by my mistake, and was. That single scar is worth more than the other nine repos combined, and it's the only line on my GitHub that would have been worth an entire interview.

That's the math nobody puts on the "ship every weekend" poster: nine projects with zero users taught me nine times nothing. One project with one real user taught me the thing I now build my whole career around.

Be clear about what I'm actually saying — because it's not "don't build"

I am not the guy telling you to stop making things. I make things constantly. I let AI generate output all day long — it writes most of my code, and I'd never go back. Building is joyful and you should do it for the joy alone, no defense required.

What I'm saying is narrower and, I think, freeing:

Stop building side projects as a strategy. They were never the scarce thing, and the day AI made them free, "I built ten of these" stopped meaning anything to anyone but you. The strategy that's left is the boring, terrifying one nobody screenshots:

Build one thing.
Put it in front of one real stranger who can hurt you — someone who will churn, complain, or ask for their money back.
Keep it alive. Maintain it through the 2am. Feel the ack-before-persist for yourself.

One shipped-and-maintained thing that a real person depends on will teach you — and, incidentally, show an interviewer — more than a hundred green-squared weekends. Not because it's more impressive. Because it's the only place judgment is actually minted.

Why this is the exact reason I build the way I do

Here's the part that goes one level up, because it's the same math.

I build an agent platform, and the temptation in this whole industry right now is to celebrate the author — the thing that generates. Look how fast it ships! Ten side projects an afternoon! But an author that produces infinite output is producing infinite unblessed diffs. A GitHub graveyard is exactly that: a pile of things generated and never judged, never shipped into contact with a reality that could hurt you. The volume was never the point. The volume is now free.

So I never let the thing that writes the code be the thing that blesses it. There's an author that produces the diff, a separate skeptic whose only job is to try to break it rather than admire it, and a human on the merge button who can see the blast radius the model can't. That separation — author, skeptic, human — is the whole shape of xenition, and it's the same lesson the graveyard teaches: generating a thing is free and always will be; deciding whether it survives contact with a real user is the entire job. Output is cheap. Judgment is the product.

Your GitHub graveyard isn't a sign you're lazy. It's a sign you were optimizing for the free thing. Stop. Build one thing that can hurt you, and stay.

Honest question for the comments: how many tombstones are on your GitHub right now — and which one project, the one you actually shipped to a stranger, taught you something none of the others did? I want to hear about the one that survived. 👇

(If this made you close a few dead tabs with a little less guilt, a ❤️ and a 🔖 help it reach the next person staring at their graveyard on a Saturday.)

I interviewed the people who rejected me. Here's what their hiring process is actually optimizing for.

Info Inlet — Tue, 22 Sep 2026 04:51:00 +0000

Last week I wrote about getting rejected from a job for "relying on AI" in the coding round — by an interviewer I'd watched read an AI answer off his own screen forty minutes earlier. I thought the story was about hypocrisy.

Then a reader replied with something sharper, and it reframed the whole thing for me.

He'd been through the opposite version. Told "please, no AI," so he stuck to it — and blanked on a manual code review of a file that couldn't even compile, because of external calls he was never shown. He walked out certain he'd be lowballed. And buried in his comment was the sentence that's been rattling around my head since:

The interview isn't for judging competence. It's for judging value — and for seeing how far they can degrade your perceived value before they name a number.

I read that and something clicked into place that my own rejection had only hinted at.

So I did the thing the rejection process never lets you do: I put it on the table and interrogated it. Not the interviewer — the machine. Two rounds, mine and his, treated as evidence about what the whole apparatus is really built to do. Here's what their hiring process is actually optimizing for.

The test I thought I was failing

Both of us walked into our rounds thinking the same thing: this is a competence test. Prove you can do the work.

That's the wrong frame. It's not a competence test. It's a pricing test.

The company already believes you can probably do the job — your résumé got you in the room, your GitHub is right there, they can read. What they don't know yet is the one number that decides whether hiring you is a good deal: how little you'll accept. And the interview is the instrument they use to find it.

Once you see it that way, a lot of otherwise-baffling interview behavior snaps into focus.

Why they need you to fail at exactly one thing

Here's the part that sounds cynical until you've lived it.

The ideal interview outcome for the company is not "flawless candidate." A flawless candidate is expensive. If you sail through every stage, you walk into the offer conversation with leverage, and you'll refuse a lowball because you have every reason to.

The ideal outcome is a candidate who is clearly good — good enough to hire — but who fumbled exactly one thing. Not zero (then they can't discount you). Not everything (then there's no offer). One clean, legible stumble. Because that one stumble is the whole negotiation:

"You're strong. Really. But you're not quite as senior as you think — remember that code review? So here's what we think you're worth."

And you, still stinging from the one thing you got wrong, nod and accept a number well under where you walked in. The stumble wasn't a bug in the interview. It was the product.

The tell is in the questions they ask

You want to know whether an interview is measuring your competence or pricing your floor? Listen to how they ask about money.

"What are your salary expectations?" asks for your ceiling — the most you think you're worth.
"How much do you currently earn?" asks for your floor — the least they can get away with.

Guess which one gets asked. Nearly every time, it's the second. They are not trying to find out what you're worth. They're trying to find out what you'll settle for — and anchoring the entire offer to a number from your past instead of the value in front of them.

That single swap tells you which game is being played. It was never "can you do this." It was always "how little can we pay you to."

Value in the room, priced off the floor

The reader's story is the whole argument in one interview.

Walk in and bring real value — spot the bottlenecks their own team hasn't named out loud, demo something that plugs straight into their stack and beats what they're running now, watch the interviewer get visibly taken aback by how much you see. That's the entire job. That's the thing that's supposed to be rare and worth paying for.

Then fumble one manual code review — reading a file cold that can't compile because of calls you were never shown — and that gets to veto all of it. Not because it revealed you can't do the work. Because it handed them the discount they needed.

Value shown at the ceiling. Priced at the floor. The stumble laundered a lowball into "honest feedback."

And here's the tell inside the tell: the code you were failed for reading? It was running deprecated patterns on their live service. You got marked down for not fluently reviewing code that their own production shouldn't be running. The abstinence test and the code-review test are the same test — both grade you on a skill the job itself no longer rewards, precisely because that's the skill you're most likely to visibly miss.

This is the same failure as the AI thing

When I put the two stories side by side — mine and his — they're the same shape.

Mine: rejected for using the tool everyone in the room was already using. His: rejected for not fluently performing a skill the company's own production had already abandoned. Both interviews measured the cheap, legible thing instead of the expensive, real one. Both optimized for a stumble they could point at, not the value they could actually use.

Because the stumble is legible. "He used autocomplete." "He couldn't read the file cold." Those go in a scorecard. Judgment doesn't. The bug I flagged unprompted — persist-before-ack, the one that locks a paying customer out with no record on the worst possible day — never made it onto anyone's scorecard, because you can't screenshot it and you can't discount someone for having it. So it got ignored in favor of the thing they could.

So what do you actually do about it

You can't fix their instrument. But you can stop mistaking their price for your worth.

Know your floor and refuse to hand it over. When they ask what you currently earn, answer with what you're looking for. You are allowed to move the anchor from your past to your value.
Treat the one stumble as their tool, not your verdict. You did not fail the interview because you blanked on cold code review. You "failed" because the interview needed you to fail at something, and that was the cheapest thing lying around.
Have enough runway to walk. The only real leverage in a pricing negotiation is the credible ability to say no. If you can let them make the junior offer and keep it — and let the runner-up have the seat — you've flipped the game. For once, you're the selective one.
Sell the value they can't screenshot. Make the bottleneck you spotted, the bug you caught, the thing-that-breaks-at-2am you predicted — make those the loudest part of the conversation. If they still price you off a compile error, that's your answer about them, not about you.

Why this is exactly how I build

Here's why this isn't just an interview rant.

The failure in both of those rooms was a process that measured the legible thing instead of the valuable one — that couldn't tell the difference between "stumbled on something easy to point at" and "can't actually do the work." That is precisely the mistake I refuse to build into an agent.

I never let the thing that produces the work be the thing that grades it, and I never let the most legible signal stand in for the most valuable one. There's an author agent that writes the diff, a separate skeptic agent whose only job is to refute it rather than admire it, and a human on the merge button who can still see the blast radius — the value and the risk the model can't screenshot. The point isn't to find the one flaw and discount everything around it. The point is to judge the actual output. That separation between author, skeptic, and human is the whole shape of xenition, the agent platform we build.

An interview that hunts for your one stumble so it can price you off your floor is running the same broken evaluation I spend my days designing out of software. The company that prices you at your ceiling — that pays for the bottleneck you spotted instead of discounting you for the file you couldn't read cold — is rare. But they exist. And the only way you ever get to work for one is if you've kept enough self-respect to turn down the ones who don't.

Honest question for the comments: have you ever felt an interview go looking for your one stumble — the moment where you could feel them setting up the discount? Or been on the hiring side and watched a process reward the legible miss over the real value? I want to know how common this actually is. 👇

(If this landed, a ❤️ and a 🔖 help — and tell me the moment you realized they were pricing your floor, not testing your ceiling.)

How to stop AI from confidently shipping broken code (a pattern that actually works)

Info Inlet — Mon, 21 Sep 2026 05:14:58 +0000

The scariest diff passed every test — and would've lost a customer money.

The scariest diff AI ever handed me passed every test, read beautifully, and would have lost a paying customer their money the first bad night in production. It didn't look risky. It looked finished. That's the whole problem.

AI doesn't ship broken code because it's dumb. It ships broken code because it's confident, and almost nothing in a normal dev loop is trying to prove it wrong. You ask it to write the thing, it writes the thing, the tests go green, and every signal you have says ship. Confidence is the output. Correctness is a coincidence you're hoping rides along.

I spent 30 days letting AI write 100% of my code — refused to type a line of application logic myself — specifically to find out what actually stops this. Not the demos. The real thing, in production, with money on the line. Here's the honest answer: it wasn't a smarter model, and it wasn't a cleverer prompt. It was one structural rule, and you can adopt it today without changing a single tool.

Why "review this code" does nothing

The instinct, when you don't trust the output, is to ask the AI to check its own work:

"Review this code and tell me if it's correct."

This is worse than useless, because it feels like a safeguard while doing nothing. An LLM asked "is this correct?" is being asked to agree with itself, and it's exceptionally good at agreeing with itself. It grades its own homework in a slightly more formal voice and hands you back an A. You didn't add a check. You added a second layer of confidence on top of the first one.

The failure isn't that the model is bad at reviewing. It's that "confirm this" and "break this" are different jobs, and confirmation is the one thing the model will always deliver. You have to stop asking for the job you'll always get.

The pattern: the Refutation Gate

Here's the entire rule, and it's boring on purpose:

Nothing merges until a second reader — whose only job is to break it — has tried and failed.

Three parts make it actually work. Skip any one and it collapses back into an echo.

1. The reviewer is not the author

The thing that wrote the code cannot be the thing that blesses it — even if it's the same model, it has to be a separate, clean context that never saw the code get written. The author's context is poisoned: it already "knows" the code is right, because it just spent 4,000 tokens convincing itself. A fresh reviewer with no memory of the writing is the cheapest independence you can buy.

Better still: make the reviewer a different model family. Different training distribution, different blind spots. Two models from the same family share the same idea of what "clean" looks like — so they share the same landmines. The single highest-leverage change I made all month was pointing the reviewer at a different model than the author.

2. The reviewer gets a break-it brief, never a bless-it brief

This is the part that does the work. Don't ask the reviewer to review. Give it a job it can only do by finding the failure.

Instead of this:

Review this diff and tell me if it looks correct.

Do this:

This code is broken. I know it is — I just don't know how yet.
Your job is to produce the specific input, sequence, or state that
makes it fail. Assume:

- the network drops a packet at the worst possible moment
- two of these run at the same time
- the database write fails AFTER the external call succeeds
- the user does the thing no sane user would do

Give me the exact scenario that loses data or loses a customer money.
If you truly cannot find one, say so explicitly and explain what
would have to be true for that to be the case.

Notice what changed. The reviewer is no longer looking for reasons to say yes. It's hunting a specific, concrete failure, and its default is "this is broken — prove otherwise." Same model. Same weights. Completely different output, because the objective is the reviewer, not the model.

3. A human owns the merge

Not to out-code the machine — it out-codes you. To hold the one thing neither agent has: the memory of having been burned. More on this below, because it's the part that can't be automated and shouldn't be.

The bug it catches that everything else waves through

Let me make this concrete with the exact diff that started all of this.

The AI wrote a Stripe webhook handler. Simplified:

app.post('/webhook', async (req, res) => {
  const event = verify(req);
  res.sendStatus(200);        // tell Stripe "got it"
  await db.savePayment(event); // then write the row
});

Read it. It's clean. It's fast — it acks Stripe immediately so the webhook latency is low. Every test passes, every single time. If you asked an AI "is this correct?" it would say yes and compliment the low-latency acknowledgement. Mine did.

Now run it through the Refutation Gate. The break-it brief says "the database write fails after the external call succeeds." And there it is: it acknowledges the event before it persists it. One database blip in the gap between the 200 and the savePayment — and Stripe believes the event is delivered, your DB never heard about it, and a customer who just paid you has access to nothing and no record they ever paid. On a bad night, silently, to real people.

That bug is invisible to "review this." It is glaringly obvious to "produce the input that loses money." The code didn't change. The question did.

The fix is one line of ordering — persist first, ack after — but you only ever write that fix if something in your loop was actively trying to break the happy path. Confidence would have shipped it. Refutation caught it.

Why the human still can't leave the room

Here's the limit I hit, and I want to be honest about it instead of selling you a fully-automated fantasy.

I fed that exact webhook to a second AI with a perfect break-it brief — and when the author and reviewer were the same model family, it still sometimes approved it. Why? Because both models were trained on the same million examples of "clean webhook code," and both of them believed ack-before-persist was fine. The reviewer didn't refute the blind spot. It re-derived it, more confidently, and called it good taste.

Then I showed the same code to a senior engineer with no special prompt. Five minutes: "it acks before it writes — I got paged for exactly this in 2021, it's a nightmare to reconcile."

She wasn't smarter than the model. She'd been burned. She had scar tissue you cannot train into a context window, because the model has read a million descriptions of the dual-write problem and she has lived one. That's the difference, and it's the entire reason a human stays on the merge button: to catch the one bug that lives inside the machine's blind spot, which is exactly the bug the machine will confidently wave through.

The whole pattern, in one place

Steal this. It costs nothing and it's tool-agnostic:

Never ask AI to confirm its own code. Confirmation is the one output it can't fail to produce, so it tells you nothing.
Add a second reader in a clean context — different model family if you can. Independence is divergence, not a second seat.
Give that reader a break-it brief, not a bless-it brief. "Produce the input that loses money," never "does this look right."
Keep a human — ideally a burned one — on the merge. Their job isn't to write better code. It's to remember what hurt.

A confident AI is not a checked AI. The only thing that turns confidence into correctness is something whose entire job is to try to prove it wrong.

That, exactly, is the shape of what we build at xenition: an agent that does the work, a different agent whose only job is to tear it down, and a person who owns the merge. I didn't start from that thesis. I arrived at it from 30 days of watching confident, beautiful, green-checkmarked diffs that would have quietly hurt real people — and finding the one pattern that caught them.

Questions I'd genuinely like answered in the comments:

What's the confident-but-broken diff AI handed you — the one that passed every test and would've bitten you in prod?
Do you run an AI reviewer? Is it the same model as your author, and have you ever measured what a different family catches?
Has anyone A/B'd "review this code" against a break-it brief on the same diff? I want numbers.
If AI does all the entry-level work, where does the next senior's scar tissue come from — the scar tissue that catches what the agents wave through?

10 VS Code Extensions I Can't Code Without in 2026

Info Inlet — Sun, 20 Sep 2026 06:41:47 +0000

Every "best VS Code extensions" list is the same 30 icons with a one-line blurb. This isn't that.

A few months ago my Extensions panel had crept past 40. Startup was sluggish, half of them I'd forgotten installing, and a good chunk were AI helpers all fighting to finish my sentences. So I did the thing you're supposed to do once a year: I disabled everything and turned them back on one at a time, only when I actually reached for one.

I ended up keeping 10. And when I looked at the survivors, they had one thing in common — a filter clean enough that I now install by it:

A good extension makes the decision faster to make. A bad one makes the decision for you.

Every extension below shows me something I'd otherwise have to go dig for, then gets out of the way and lets me choose what to do about it. The ones I deleted were the opposite: they decided, then told me after (if at all). Hold that line and the list writes itself.

Here's the 10.

1. Error Lens

The single highest-leverage extension in my setup. It takes the diagnostics VS Code already has and prints them inline, at the end of the line, instead of hiding them in the Problems panel or behind a hover.

That sounds cosmetic. It isn't. It collapses the loop between "I wrote something wrong" and "I know I wrote something wrong" from go-hunt-for-it to zero. You stop context-switching to a panel forty times an hour. The error is just… there, red, next to the thing.

It's the purest example of the filter: it makes the problem impossible to miss, and does nothing about it. You still decide the fix.

2. GitLens

git blame as an ambient sense. Put your cursor on any line and GitLens tells you who last touched it, when, and in which commit — inline, without leaving the file.

The reason it earns a permanent seat: the question it answers isn't "who do I blame," it's "what was the author thinking, and is that still true?" Before you rip out a weird-looking guard clause, you can see it was added in the commit titled "fix: race when webhook acks before the row is persisted" — and now you don't rip it out. That's judgment the tool fed you, not judgment it made for you.

3. ESLint

Non-negotiable, and not for the style nits. A good ESLint config catches a whole class of real bugs before you run anything — the floating promise you forgot to await, the exhaustive-deps you missed, the === you meant. Wire it to fix-on-save for the mechanical stuff (import order, quotes) and leave the logic rules as warnings you read and act on.

The distinction matters: auto-fix the things with one correct answer; surface the things that need a human call. Same filter again.

4. Prettier

I stopped having opinions about formatting in 2019 and I've never been happier. Prettier on save means every diff is a content diff — never a "someone's editor re-tabbed the file" diff. Pair it with ESLint (eslint-config-prettier so they don't fight) and code review stops wasting its first ten minutes on whitespace.

This one does decide for you — and that's fine, because formatting is the rare case with no judgment in it. That's exactly why it's safe to automate. Keep that in your back pocket; it's the whole test for what you let a tool own.

5. Pretty TypeScript Errors

If you write TypeScript, this gives back hours of your life. It takes those 40-line, deeply-nested "Type 'X' is not assignable to type 'Y'" walls and formats them into something a human can actually read — indented, syntax-highlighted, with the actual mismatch pulled out.

It doesn't fix the error or guess your intent. It makes the compiler's own message legible so you can. Perfect fit.

6. Import Cost

Renders the size of every imported package right next to the import line. You import { format } from 'date-fns' and it quietly tells you that just cost you 20KB.

It won't stop you. It won't rewrite it to a lighter import. It just makes the cost visible at the moment you're making the choice — which is the only moment the information is useful. Nine times out of ten you shrug and move on; the tenth time it saves you from shipping a 300KB date formatter.

7. Path Intellisense

Autocomplete for filesystem paths in your imports and src attributes. Small, boring, and I'd riot if you took it away. It removes an entire category of dumb typo bugs (../../ off by one) by showing you what's actually there as you type. Pure surfacing, zero magic.

8. Todo Tree

Scans your workspace for TODO, FIXME, HACK, NOTE and lists them in a tree in the sidebar, colour-coded by tag. It turns the notes-to-self you scatter while heads-down into an actual, visible worklist you can't pretend you didn't leave.

I add a // REVIEW: tag for "I wrote this fast, come back with fresh eyes." Todo Tree makes future-me's judgment call impossible to lose. That's the whole job.

9. Code Spell Checker

Underlines typos in your code — variable names, comments, strings. Sounds trivial until the day it saves you from shipping recieveWebhook as a public function name that then lives in your API forever, or a retreive that breaks a string match three files away. It flags; you decide if it's a real word or your weird domain term (and you add it to the dictionary). Surfacing, not deciding.

10. REST Client (or Thunder Client)

Write HTTP requests in a plain .http file, hit send, see the response — without leaving the editor or opening a separate app. The .http file lives in the repo, so your API calls are version-controlled, diffable, and right next to the code that serves them.

The reason I prefer a file-based client over the big GUI apps: the request is text I can read and own, sitting in git, not state trapped inside another program's cloud. Same instinct as the rest of the list — keep the thing you need to reason about in front of you and under your control.

Honorable mentions

Docker — manage containers/images from the sidebar; great when you're not living in the terminal.
GitHub Actions — edit and read workflow files with schema validation, so you stop pushing "fix CI" commits blind.
Even Better TOML / YAML — schema-aware editing for the config files that silently break everything when a key is off by one space.

The ones I deleted — and why

Here's where the filter earns its keep. Most of what I removed was AI assistance, and I want to be precise about why, because I am not anti-AI — I let a model write most of my code.

I killed the extensions that decide silently: the ones that auto-accept a completion before I've read it, the "fix all problems" button that rewrites logic I didn't inspect, the assistant that quietly refactors on save. Not because they're wrong often — because when they're wrong, they're wrong invisibly, and they were training me to approve instead of decide.

The AI tooling I kept is the tooling that behaves like Error Lens: it shows me its reasoning and waits. Suggests the diff, explains the risk, and leaves my hand on the button. That one distinction — surfaces vs. decides — sorted 40 extensions into 10 in about an hour.

It's the same rule I hold one level up, for the agents that write the actual code. I never let the tool that writes something be the tool that blesses it. There's an author, a separate skeptic whose only job is to try to break the diff, and a human on the merge button who can see the blast radius the model can't. Your extensions shelf is that same architecture in miniature: keep the tools that make you a better decider, delete the ones quietly relieving you of the decision. (That separation is the whole idea we're building xenition around — but you can apply the filter tonight without us.)

Your turn for the comments: what's the one extension you'd fight to keep — and does it surface something for you, or decide something for you? 👇

(If this thinned out someone's Extensions panel, a ❤️ and a 🔖 help it reach the next dev whose editor takes nine seconds to open.)

I got rejected for using AI in an interview. Then I watched the interviewer do it.

Info Inlet — Sat, 19 Sep 2026 07:53:38 +0000

I got the rejection email on a Tuesday. I've been rejected before — everyone has. This one broke something.

"While your technical skills are strong, we felt your reliance on AI tools during the assessment didn't reflect the independent problem-solving we're looking for."

Rejected. For using AI.

By a man who — forty minutes earlier, on the same video call — had quietly done the exact same thing right in front of me.

Let me tell you how I know.

It was a normal live-coding round

Screen shared, camera on, the usual. A medium problem: parse some messy input, transform it, return something structured. Nothing exotic. The kind of thing I do at my actual job every single day.

So I did it the way I do it every single day. I broke the problem down, wrote the core logic myself, and let the assistant stub the boilerplate so I could spend my attention on the edge cases. And I said so, out loud, on the call: "I'll let the assistant scaffold this part so I can focus on where it'll actually break."

I wasn't hiding anything. That, it turns out, was the mistake — thinking honesty was the safe choice.

Then he went quiet

Not thinking-quiet. Uncomfortable-quiet.

I didn't clock it in the moment. You never do. You just feel a small temperature drop on the other side of the glass and tell yourself you're imagining it.

The follow-up that gave him away

He asked a follow-up about time complexity. Then his eyes did the thing.

The flick. The half-second reading pause. The answer that came back a beat too clean, too structured, too formatted to be something a person says off the top of their head on a Tuesday afternoon.

I'm not going to pretend I could read his screen. But I've used these tools every day for two years. I know exactly what someone reading a generated answer looks like, because I look like that too. He was reading an AI's answer while quietly marking me down for reaching for one.

Here's what actually broke me

It wasn't the hypocrisy. Hypocrisy I can file away.

What broke me was realizing the rule was never "don't use AI."

The rule was "don't let us see you use AI."

Pretend you didn't. Perform the 2019 version of yourself. Hide the tool that everyone in the room — interviewer included — is already using. They didn't reject someone who couldn't do the work. They rejected someone who was honest about how he does it. Those are not the same person, and only one of them is a problem.

The test they thought they were running

Here's the part I've actually been chewing on, past the sting.

They believed they were testing whether I could solve the problem without AI. But that's a test for a job that no longer exists. Nobody on their team ships without AI. He couldn't get through a follow-up question without it.

The test that would have actually told them something is the opposite one: give me the AI, then watch whether I can tell when it's lying to me.

Because that's the only skill that survived a year of me leaning on these tools as hard as humanly possible. A month ago I ran an experiment where I let AI write 100% of my code for 30 days and refused to type a line of application logic myself. It shipped a real product. And the thing that made it shippable wasn't the AI — it was the times I looked at a clean, confident, plausible diff and said no.

The tell they never asked about

During that same round, before the boilerplate, I'd flagged something in the problem's framing: the write path needed to persist before it acknowledged, or a retry could double-count. It's the exact ack-before-persist bug that bit me during the 30-day run — the one where acknowledging before you save leaves a paying customer locked out with no record on a bad day.

No AI gave me that. I earned it the slow, expensive way, years before any of this. It's the thing that would have been worth an entire interview.

They didn't ask about it. They were too busy noting that I'd used autocomplete.

The two skills we keep pricing as one

There are two different things hiding inside the word "coding," and hiring is still pricing them as one.

Recall — the syntax, the API, the flag order, the incantation. AI has made this obsolete, and good riddance; it was never the valuable part. Testing for it in 2026 is testing for penmanship.
Judgment — knowing what to build, what to distrust, what breaks at 2am when a real person does something strange. AI cannot hand you this. You can only earn it by doing the work AI now does for you — and you can only demonstrate it by catching the AI when it's wrong.

An interview that punishes you for using AI is measuring recall and calling it character. An interview worth passing hands you the AI and measures whether you can overrule it.

Why this is the whole reason I build the way I do

I didn't quit AI over one bad interview. It still writes 100% of my code and always will — the typing was never the hard part, it just felt like it was.

But that call crystallized something I already believed about how these systems should be built. The failure in that room wasn't the AI. It was a process that couldn't tell the difference between using a tool and being unable to judge its output — so it optimized for hiding the tool instead of testing the judgment.

That's precisely the mistake I refuse to build into an agent. I never let the thing that writes the code be the thing that blesses it. There's an author agent that produces the diff, a separate skeptic agent whose only job is to refute it rather than admire it, and a human on the merge button who can still see the blast radius the model can't. The AI's role is never hidden and never trusted by default — it's made explicit so a human can judge it. That separation between author, skeptic, and human is the entire shape of xenition, the agent platform we build. That interviewer and I were both using AI. The only difference worth hiring for is whether you're honest enough to admit it and sharp enough to overrule it.

Honest question for the comments: have you ever hidden the fact that you used AI in an interview — or been on the other side of the glass, marking someone down for it? I want to know how common this actually is, because I don't think I hit a rare bug. I think I hit the norm. 👇

(If this landed, a ❤️ and a 🔖 help — and tell me the moment you realized the rule was "don't get caught," not "don't use it.")

Claude Code vs Cursor: 10 Coding Tasks, 2 Very Different Workflows

Info Inlet — Wed, 16 Sep 2026 06:33:39 +0000

"Claude Code or Cursor?" is the wrong question — like asking "terminal or editor?"

They're both very good, and they're good at different jobs. If you pick one out of loyalty and use it for everything, you'll spend half your time fighting the tool on the tasks it wasn't built for. So instead of a winner, here's the thing that actually helps: a breakdown by task, so you know which one to reach for and when.

What each one actually is

Claude Code — Anthropic's agentic coding tool. It's terminal-first, with a desktop app and IDE extensions (VS Code, JetBrains). Its whole personality is agentic: you describe an outcome, it plans, edits across many files, runs commands, and iterates. It reads your whole repo, not just the tab you have open.
Cursor — an AI-native editor (built on VS Code). Its personality is in-the-flow: fast Tab autocomplete, tight inline edits, and chat/agent panels a keystroke away. You stay in the editor and the AI meets you there.

One is an agent you hand a task to. The other is an editor that makes you faster while you drive. That difference explains almost every "which is better" argument you've ever seen.

Task by task

Whole-repo refactors and "just fix this project" → Claude Code

When the change spans a dozen files, or you can only describe the goal ("migrate this to the new API," "make these modules share one config"), the agentic model wins. Claude Code holds the repo in context and marches file to file. Driving that same change by hand-editing tabs is exactly where an editor-first tool feels like swimming upstream.

Fast, local edits and autocomplete → Cursor

Renaming a thing, reshaping a function, filling in the obvious next lines — Cursor's Tab and inline edit are hard to beat for tight, low-latency changes where you already know what you want and just want it typed. This is the flow-state stuff.

Terminal / CI / scripting workflows → Claude Code

Because it lives in the terminal, Claude Code is a natural fit for tasks that are really command sequences: run the tests, read the failure, fix, re-run; wire up a script; drive a one-off migration. That loop is native to it.

Explaining unfamiliar code → roughly a tie

Both are strong here. Cursor's edge is that the explanation happens right where you're reading. Claude Code's edge is that it can pull in the rest of the repo to explain how a file actually connects to everything else. Pick by whether you need local or repo-wide context.

Writing tests → slight edge to Claude Code

Tests usually need to see more than one file (the code under test, its collaborators, existing test patterns). The agentic, whole-repo view tends to produce tests that match your conventions rather than generic ones — though for a single focused unit test in the file you're already in, Cursor is faster.

Where they overlap (and why "just pick one" is tempting)

Chat, ask-about-this-code, generate-a-function, small edits — both do all of it competently. If your work is 90% small, local edits, Cursor alone is a complete setup. If it's 90% multi-file, agentic tasks, Claude Code alone is. Most people are somewhere in the middle, which is why the honest answer is often "both."

How to run both without paying twice for the same job

A setup that works well:

Cursor as your daily editor for the minute-to-minute typing and small edits.
Claude Code (extension or desktop) for the heavy lifting — the big refactor, the "fix the whole project," the test suite, the terminal loops.

They're not really competitors in this configuration; they're an editor and an agent, and you switch based on the size and shape of the task, not brand loyalty.

The honest caveats — for both

None of this is magic, and it's the same list for either tool:

They ship subtle bugs with total confidence. You review every diff. Non-negotiable.
Bad prompt, bad code. The quality of what you get out tracks the context you put in. "Here's the file, the bug, and what I already tried" beats "fix this."
They make it easy to stop understanding your own codebase. The most dangerous failure isn't a wrong line — it's approving a diff you didn't really read because it looked plausible.

That third one is the real reason I don't think "which tool" is the most important question.

How to actually choose

Mostly small, local edits, want flow → Cursor.
Mostly multi-file / agentic / terminal work → Claude Code.
A real mix (most of us) → both, split by task size.
Whatever you pick: keep a human who genuinely reads the diff. The tool that writes the code should never be the only thing that blesses it.

Disclosure / builder's bias: I work on xenition — [FILL: one honest line about what xenition is, e.g. "a layer that separates the agent that writes a change from a second agent that tries to refute it, with a human on the merge"]. So take my "always keep a skeptic on the diff" opinion as coming from someone who builds exactly that. It's a bias; I'd rather name it than hide it.

Your turn: if you use both, what's the split that actually works for you — and which tool did you stop forcing into the wrong job? 👇

(If this saved you a comparison-tab rabbit hole, a ❤️ and a 🔖 help.)

I deleted every AI tool for 7 days to see if I still know how to code. I didn't.

Info Inlet — Tue, 15 Sep 2026 06:44:18 +0000

I opened a blank file. No Copilot ghosting the next line. No chat window one alt-tab away. Just me, a cursor, and a feature I've built a hundred times.

And I sat there. For four minutes. Not thinking about the problem — thinking about how to start.

That was the moment I knew this experiment was going to hurt.

The rule

One week. No AI in the loop. Not "AI-lite." No chat, no autocomplete beyond my editor's dumb built-in, no "just ask it for the boilerplate." If I wanted a Zod schema, I typed the Zod schema. If I forgot the exact Intl.NumberFormat options, I read the docs like it was 2019.

Some context on why this was even a question: a month ago I ran the opposite experiment — I let AI write 100% of my code for 30 days and didn't type a line of app logic myself. It shipped a real product. I came out of it using AI for all of my typing, permanently, and I meant it.

So this wasn't me trying to prove AI is bad. I wanted to know something scarier: after leaning on it that hard, what had I actually lost?

Day 1–2: the muscle had atrophied

The first thing that broke wasn't knowledge. It was initiative.

I knew how to build the thing. I just wasn't used to being the one who starts the sentence. For a month my whole workflow had been describe → review → approve. Take that away and you find out you've quietly outsourced the hardest ten seconds of programming: the blank-page moment where you decide the shape of the solution before a single line exists.

I could still read anything you put in front of me. Generating from zero felt like speaking a language I only ever listen to now.

Day 3–4: my recall was shot — my judgment wasn't

Here's the split that surprised me, and it's the whole point of the piece.

The thing I lost was recall. Exact API signatures. The flag order. The name of that one array method. Embarrassing amounts of docs-tab-opening for things I "knew." That felt bad in the moment and turned out not to matter at all — it was always cheap knowledge, and good riddance.

The thing I kept was judgment. I still knew the billing webhook had to persist before it acknowledged — the exact bug that bit me during the 30-day run. I still smelled the N+1 before I ran the query. I still knew which abstraction would rot in six months. AI never gave me any of that. I earned it before AI, the slow way, and it stuck.

AI erodes your recall fast and your judgment not at all. So the real danger isn't for me. It's for anyone who never got to build the judgment in the first place.

Day 5–7: I got faster, and it got quiet

By day five the initiative came back. Blank files stopped scaring me. I was still slower than AI on raw output — obviously — but something else happened that I didn't expect.

I understood my own codebase again.

When AI writes it, you approve it, and you carry a fuzzy, approximate model of what's actually in there. When you type it, you carry an exact one. I caught two design mistakes that week purely because the whole system was genuinely in my head instead of sitting in a diff I'd skimmed and blessed.

The uncomfortable synthesis

There are two skills hiding inside the word "coding," and we've been treating them as one:

Recall — remembering the syntax, the API, the incantation. AI makes this obsolete, and I'm glad. This was never the valuable part.
Judgment — knowing what to build, what to distrust, what breaks at 2am. AI cannot give you this. You can only earn it by doing the work AI now does for you.

The trap isn't that AI makes us dumber. It's that it removes the exact practice reps that used to build the judgment — the scaffolding, the boilerplate, the wrong first draft you had to debug — and it removes them so smoothly you never notice the ladder is gone until you reach for a rung and there's nothing there.

That's the same conclusion my 30-day experiment landed on from the other direction. Letting AI do everything showed me it had replaced the junior work. Turning AI off showed me why that matters: the junior work was never busywork. It was the gym where judgment gets built.

What I actually changed

I didn't quit AI. It still types 100% of my code and always will — the typing was never the hard part, it just felt like it was.

What I added is one small ritual: once a week I open a blank file with everything turned off, on purpose. Not because I need to ship it by hand. Because the day I can't start from zero is the day I stopped being the engineer and became the guy who approves things — and an approver who can't tell right from plausible is just a rubber stamp with a job title.

It's also why, when I build agents, I never let the thing that writes the code be the thing that blesses it. An author agent, a separate skeptic agent whose only job is to refute the diff, and a human on the merge button who can still see the blast radius the model can't. That last seat — the human judgment one — is precisely the thing seven days off reminded me you can't automate away, because you can't automate the reps that build it either. That separation is the whole shape of how we build xenition, and a week coding blind is the only stress test I trust for it.

So, honest question for the comments: when's the last time you wrote real code with everything turned off — no chat, no autocomplete, nothing? And be honest about how it actually felt. Because I think how uncomfortable that answer is might be the most important metric none of us are tracking. 👇

(If this was worth your time, a ❤️ and a 🔖 help — and tell me the moment you realized you'd forgotten something you "knew.")

Green tests are lying to you.

Info Inlet — Mon, 14 Sep 2026 08:25:43 +0000

There's a reflex every engineer has, and I had it for a decade: the test suite goes green and my shoulders drop. Green means safe. Green means ship. Green means someone checked.

That reflex is now wrong, and it took 30 days of letting AI write 100% of my code to see exactly how wrong.

Here's the sentence I want you to sit with: a passing test proves your code agrees with your test. It has never proved your code is correct. Those were the same thing for years — but only by accident, and the accident just ended.

This isn't a hype post and it isn't a doom post. It's about why the most trusted signal in your CI pipeline quietly stopped meaning what you think it means.

What green used to mean

For most of software history, a passing test carried a hidden second signal you never had to think about: a human, at some point, wrote that test on purpose.

Even when the same person wrote the code and the test, there was a gap in time and attention between the two acts. You wrote the function believing one thing, then you sat down later — different mindset, slightly more skeptical, sometimes after lunch, sometimes after a bug — and tried to pin down what "correct" meant. The test was a second pass by a second version of you. Not a perfect check. But a real one, because the person writing the assertion was at least trying to catch the person who wrote the code.

Green meant: two attempts, made at different times, agreed. That's a weak form of independence, but it's genuine, and it's the entire reason the green checkmark ever earned your trust.

What green means now

When AI writes the code, it also writes the test. And it writes both in the same pass, from the same context window, holding the same mental model of what the code is supposed to do.

There is no second version. There is no gap in time or attention. The thing that decided what "correct" means is the exact same thing that decided what the code does — in the same breath, from the same prior.

So when the test passes, it's telling you something real. It's just not the thing you think:

The test doesn't confirm the code is correct. It confirms the code matches the assumption the model already had when it wrote the code.

If that assumption was right, green means right. If that assumption was wrong, the model writes wrong code, then writes a test that asserts the wrong behavior is the expected behavior — and the test passes, bright green, confirming the bug as a feature.

The test isn't checking the code. It's a mirror held up to the code's own assumptions. And a mirror never disagrees with you.

The exam nobody proctored

The cleanest way I can put it: the model is a student who writes its own exam, takes its own exam, and grades its own exam — all in one sitting, from one understanding of the material.

Of course it passes. It would be shocking if it didn't. But "the student passed the exam it wrote for itself" tells you the student is consistent. It tells you nothing about whether the student understands the subject. Consistency and correctness feel identical right up until the moment the student's understanding is wrong — and then they diverge completely, silently, with a 100% score stapled on top.

Green tests measure "did I build what I intended?" They have never once measured "was my intention correct?" We got away with conflating those two questions for years because a human's intention was checked by other humans — in review, in production, in the 2am page. Hand both the intention and the verification to the same model and the conflation isn't a shortcut anymore. It's the whole failure.

The bug that ran green all the way to production

Let me make this concrete, because it's not hypothetical — it cost a version of me real trust.

During my 30-day experiment, the AI wrote a Stripe webhook handler. It acknowledged the event — returned 200 to Stripe — and then persisted the row to the database. Ack first, write second.

The tests were green. All of them. The model wrote a test that fired a webhook, asserted a 200 came back, and asserted the happy-path row got written. Textbook. Beautiful coverage numbers.

But look at what the test couldn't assert, because the model that wrote it didn't believe there was anything to assert: what happens if the database blips in the gap between the ack and the write? In production, that gap is real. One hiccup and you've told Stripe "got it, we're done" while your own database never heard about the payment. The result is a paying customer with access to nothing and no record they ever paid. Stripe considers it delivered. You have no idea it happened.

The test didn't miss this because it was a bad test. It missed it because it was written by the same mind that thought ack-before-persist was clean. You cannot write an assertion against a failure mode you don't believe exists. The green checkmark wasn't a lie about the code. It was an honest report of a wrong belief.

Let me be fair to the tests

I'm not telling you to delete your test suite. That would be the doom-post version of this, and it's just as wrong as the hype.

Tests written this way are still genuinely good at one thing: catching the code from drifting away from itself later. Regression is a real category of bug — you change one thing, something three files over quietly breaks — and a green-agrees-with-green suite catches exactly that, cheaply, forever. That's worth a lot. I run more tests now than I ever did, not fewer.

What I stopped doing is treating green as a verdict. Green is a consistency check. It proves today's code still agrees with the day it was written. It cannot, structurally, tell you whether the day it was written was already wrong. Those are different jobs, and the green checkmark only ever did one of them. We just never had to notice, because a human used to do the other.

What makes green mean something again

The fix is the same structural move I keep landing on, and it's not "write better tests." It's who writes the test.

A test only checks an assumption when it's written by something that doesn't already hold that assumption. So you buy that separation deliberately, in three places:

A different author for the assertion than for the code. Not "write tests" bolted onto the same agent in the same pass — a separate reviewer whose entire job is to write the test the author would never think to write, because the author can't see the state that would break it. The test that asserts the row exists after a simulated DB failure between ack and write. That test only gets written by something looking for the failure, not confirming the success.
A different frame. Stop generating tests that ask "does the happy path work?" It always does. Generate the ones that ask "produce the input that loses a customer money, then assert we don't." A test hunting a specific failure is worth ten that bless the demo. Same model, completely different output — because the objective, not the model, is what's doing the checking.
A human on the merge who's been burned. Some failure modes don't live in any prompt because they live in someone's scar tissue — the memory of the 2am reconciliation, the paged-at-3am dual-write nightmare. That person reads ack-before-persist and goes pale in five minutes. No coverage number produces that flinch. It has to be lived.

Stack those and green starts meaning something again, because now a bug has to survive a test it didn't get to write, a frame built to break it, and a human who's paid for it before. Any one of those alone, and the checkmark is decoration.

The structure, not the prediction

Here's what I actually believe after 30 days of watching green tests pass over landmines:

A test written in the same pass as the code checks consistency, never correctness.
To check correctness, the assertion has to come from something that doesn't share the code's assumptions.
And a human owns the merge, because the assumption most likely to be wrong is the one nobody — no model, no test — thought to question.

That's not a claim about which model wins. It's a structure, and it holds whether the author is today's model or GPT-9, because it doesn't depend on the model being good. It depends on the check failing differently than the thing it checks.

It's also, not coincidentally, exactly how we build xenition: an agent that does the work, a different agent whose job is to write the test that breaks it, and a person who owns the merge. I didn't arrive at that from a thesis. I arrived at it from watching a suite go fully green over a webhook that quietly loses paying customers.

"All tests passing" is the beginning of review. It has never been the end of it. We just had a human quietly doing the rest, and we called it green.

Three questions I'd genuinely like answered in the comments:

Does your AI-generated test suite get written by the same agent, in the same pass, as the code it tests? Have you ever measured what a separate adversarial test-writer catches that it doesn't?
What's a bug you've shipped with 100% green tests — the one where the test and the code were wrong in the exact same way?
If tests only prove consistency now, what's the signal you actually trust before you merge — and where does it come from?

I made two AIs review each other's code for 30 days. A human still caught the bug in 5 minutes.

Info Inlet — Sun, 13 Sep 2026 04:33:36 +0000

Last month I let AI write 100% of my code for 30 days. The single loudest lesson wasn't "AI is amazing" or "AI is useless." It was one sentence: the thing that writes the code can never be the thing that reviews it. A model grades its own homework and it always passes.

So this month I did the obvious next experiment. If the author can't be the reviewer — fine. Make a second AI the reviewer. Author agent writes the feature. A separate skeptic agent tries to tear it apart. No human in the review loop at all, on purpose, to find out how far the structure alone could carry me.

It worked far better than I expected. Right up until the one moment it mattered most.

The setup

Two agents, deliberately given different jobs — because I'd already learned the hard way that "independence" is not a second prompt to the same model asking "is this correct?" It just agrees with itself in a calmer voice.

The author got the normal brief: build the feature, make the tests pass.
The skeptic got an adversarial brief, never a blessing brief. Not "review this diff." Instead: "Assume this is broken. Produce the input that loses a customer money. Find the thing that already exists that this reimplements. Find the state nobody designed for."

Different frame, different objective. A grader looks for reasons to say yes; a skeptic hunting for the failure looks for the one input that breaks it. That gap is the whole reason the second agent is worth its tokens.

I logged everything for 30 days. Every issue the skeptic caught, every issue it missed that I caught in my own final read, every false alarm. 41 real issues that a competent reviewer should have caught. Here's the honest scoreboard.

What the skeptic caught — 38 of 41, and some of them impressed me

This is the part that surprised me, so let me be fair to the machine first.

Architecture drift, gone. The author wrote a second formatCurrency because it didn't know the first existed. The skeptic, pointed at the whole diff and told to "find what this reimplements," caught it in one pass. Same with an inline auth check that duplicated my middleware, and a subtly-different User type in a new module. The stuff that compiles, passes, and quietly rots your codebase — the skeptic was genuinely good at it, better than a tired human at 6pm.

Swallowed errors, flagged. The author's instinct is to wrap everything in try/catch and move on. The skeptic's adversarial frame — "what failure does this hide?" — caught the catch blocks that logged and continued as if nothing happened.

A real race condition. Two requests, one counter, no lock. The author never sees it because it works every time in testing. The skeptic reasoned about concurrent callers because I'd told it to assume the worst input, and the worst input is two of them at once.

If I'd stopped here I'd be writing the "you don't need human reviewers anymore" post. Eight of nine break-classes from last month's experiment, caught by a machine, for pennies. Then I looked at the three it missed.

The three it missed were the same species

All three survivors were the same kind of bug: a silent data-integrity failure on the unhappy path. The flagship was one you've heard me tell before, because it keeps happening and it keeps being the one that matters.

The author wrote a Stripe webhook handler that acknowledged the event before persisting it. Return 200 to Stripe, then write the row. Works flawlessly in every test. In production, one database blip between the ack and the write = a paying customer with access to nothing and no record they ever paid. Stripe considers it delivered. Your DB never heard about it.

I fed that exact handler to the skeptic, with its adversarial brief, and asked it to find the input that loses a customer money.

It approved it. Confidently. It even praised the "clean early acknowledgement to keep webhook latency low."

Why it missed it — the part that changed how I build

Here's the thing I actually want you to take away, because it's not "the AI wasn't smart enough."

The author and the skeptic are the same model family. Same training distribution, same instincts, same idea of what "clean webhook code" looks like. The author thought ack-before-persist was fine. And when I handed that code to the skeptic, the skeptic shared the exact mental model that thought it was fine. It didn't refute the blind spot. It re-derived it, in a more confident voice, and called it a strength.

That's not a review. That's an echo with better manners.

"Author ≠ reviewer" is necessary. It is not sufficient. If both agents reason from the same prior, the second one isn't a check — it's the first one wearing a lab coat. Point them both at a bug that lives inside their shared blind spot and they will agree, twice, and hand you a green checkmark over a landmine.

Then a human caught it in five minutes

I gave the same handler to a senior engineer. No special prompt, no framing. She read it, went slightly pale, and said: "it acks before it writes — I got paged for exactly this in 2021, it's a nightmare to reconcile."

Five minutes. And notice why. It wasn't that she was smarter than the model, or reasoned more carefully. She'd been burned. She had scar tissue the model doesn't have and can't get, because you can't train the memory of a 2am reconciliation into a context window. The model has read a million descriptions of the dual-write problem. She has lived one. Those are not the same knowledge, and the difference is the entire margin.

That's the missing rung again, by the way — the one I keep coming back to. The reason she could catch it is that early in her career she shipped something like it and paid for it. If AI does all the entry-level work, nobody accumulates that scar tissue, and then nobody can catch the bug that the two agents will keep waving through. The skeptic and the senior aren't interchangeable. One pattern-matches on everything it's read; the other remembers what hurt.

What actually buys independence

So the second agent isn't useless — it caught 38 of 41, and I'd never ship without it now. But the experiment taught me exactly where its ceiling is, and how to raise it. Independence isn't a second seat. It's divergence, and you can buy it in three places:

A different model family. Different training distribution, different blind spots. The single cheapest way to stop the reviewer from sharing the author's delusion. This one change would have caught the webhook — a model trained on different data doesn't necessarily think ack-before-persist is clean.
A different frame. Don't ask "is this correct?" (it agrees). Give it a job it can only do by finding the failure: "assume this loses money; produce the transaction that does it." A skeptic hunting a specific failure beats a grader blessing the happy path even from the same weights. This is what got me to 38.
A human with scar tissue on the merge button. Not to out-code the machine — the machine out-codes the human. To hold the one thing neither agent has: the memory of having been burned by exactly this before.

Stack all three and the blind spot has nowhere to hide, because a bug has to survive a different model, an adversarial objective, and a human who's paid for it before. Any one of those alone, and the landmine ships with a green check on top.

The structure, earned instead of asserted

Last month I asserted this structure. This month I have the log that proves it:

The thing that writes the code can't be the thing that reviews it.
The thing that reviews the code can't share the writer's mental model, or it reviews nothing — it re-derives.
And a human owns the merge, because the one bug that survives two agents is precisely the one that requires having lived it.

That's not a prediction about which model wins. It's a structure, and it holds whether the author is today's model or something we haven't built yet — because it doesn't depend on the model being good. It depends on the model being checked by something that fails differently than it does.

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 30 days of watching two AIs agree with each other over a bug a human spotted in five minutes.

The two-agent setup caught 38 of 41. The 39th is why there's still a person on the merge button — and why there needs to keep being one who's been burned.

Four questions I'd genuinely like answered in the comments:

If you run an AI reviewer, is it the same model as your author? Have you ever measured what it catches versus a different family?
What's your "I got paged for exactly this in 2021" bug — the one you'd catch in five minutes that a model waves through every time?
Has anyone A/B'd "review this diff" against an adversarial frame ("find the input that loses money") on the same code? I'd love numbers.
Where does the next reviewer's scar tissue come from, if the entry-level work that used to grow it is the first thing we automated?

I read 500 'AI will replace developers' posts. They all make the same 3 mistakes.

Info Inlet — Sat, 12 Sep 2026 05:51:11 +0000

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.)

I let AI write 100% of my code for 30 days. Here's what broke.

Info Inlet — Wed, 09 Sep 2026 09:08:18 +0000

Not "AI-assisted." Not "copilot suggestions I edited." I mean I made a rule: for 30 days, I don't type application code. The AI does. My job is to describe, review, and approve.

I shipped a real product this way — a small SaaS with auth, Stripe billing, a dashboard, and a public API. It works. It's in production. And along the way I found out exactly where the "AI writes everything now" dream holds up and where it quietly falls apart.

This isn't a hype post and it isn't a doom post. It's a field report.

The rules

To keep myself honest:

I don't write application logic by hand. I prompt, the AI writes.
I can read every line, reject it, and ask again — but I can't fix it myself in the editor.
Config, secrets, and "click the button in the dashboard" steps are mine (the AI can't do those anyway).
If I get truly stuck for more than an hour, I log it as a "break" and write the code myself.

By the end I had 9 logged breaks. Those breaks are the interesting part.

What worked shockingly well

Let me be fair to the machine first, because a lot of this genuinely surprised me.

Greenfield scaffolding is basically solved. "Set up a Next.js app with Postgres, Drizzle, and auth" — done, correctly, in one shot. The first 40% of the project flew by faster than I've ever built anything.

Boilerplate it never gets wrong. CRUD endpoints, form validation, Zod schemas, a table component with sorting and pagination. This is the stuff I hate writing and it produced it perfectly, every time, no notes.

It's a phenomenal rubber duck. "Why is this query slow?" got me a better answer than I'd have reasoned to alone — it spotted a missing index and an N+1 in the same breath.

For the first week I genuinely thought I'd write the "developers are obsolete" post. Then week two happened.

What broke — the 9 breaks, honestly

Break 1–3: It can't hold the whole system in its head

The AI is brilliant at the file in front of it and blind to the one three folders over. It happily wrote a second formatCurrency helper because it didn't know the first one existed. It re-implemented my auth check inline instead of using the middleware I already had. It introduced a subtly different User type in a new module.

None of these are "bugs" — everything compiled, everything passed. They're architecture drift. And architecture drift is invisible until the day it costs you a week.

The AI optimizes locally. Coherence across a system is still a human job.

Break 4–5: It confidently writes plausible, wrong code

The scariest failures weren't crashes. They were code that looked right and ran fine on the happy path.

The billing webhook handler it wrote acknowledged Stripe events before persisting them. Works perfectly in testing. In production, a DB blip = a paid customer with no access and no record. I only caught it because I've been burned by exactly this before. A junior copying this AI's output would not have caught it. That's the part that keeps me up.

Break 6: Debugging its own code is a loop of despair

When something broke that the AI couldn't see, asking it to fix it produced changes, not fixes. It would confidently rewrite the function, swear the bug was gone, and reintroduce it two prompts later. Without the ability to drop into the debugger myself and actually understand the state, we'd have spun forever. This was the single biggest time sink of the month.

Break 7–8: Taste, and saying "no, less"

Asked for a settings page, it gave me 14 options no user asked for. Asked for error handling, it wrapped everything in try/catch and swallowed the errors. The AI's instinct is to add. Knowing what to leave out — the actual product-design part of engineering — it has none of.

Break 9: The last 10% is still 90% of the work

Getting to "demo works" took a week. Getting to "handles a real user doing something weird at 2am" took the other three. Edge cases, race conditions, the empty state, the error state, the "what if they double-click" state — the AI does none of this unless you know to ask, and knowing to ask is the job.

The uncomfortable synthesis

Here's what I actually believe after 30 days:

AI didn't replace me. It replaced the *tasks I used to give juniors.* The scaffolding, the boilerplate, the first draft — that's exactly the work a junior learns on. And that's the real problem nobody's pricing in: if the AI does all the entry-level work, where does the next senior come from? You can't skip the 10,000 hours; you can only move where they're spent.

The skill that mattered every single day wasn't writing code. It was:

Knowing the code it gave me was subtly wrong.
Knowing what to not build.
Holding the whole system in my head so I could catch the drift.

Those are all senior skills. Which means AI didn't flatten the hierarchy — it made the top of it more valuable and kicked away the ladder to get there.

What I actually changed

I didn't stop using AI — I use it for 100% of the typing now and always will. I changed the guardrails around it, and every one of them maps to a break above:

The thing that writes the code is never the thing that reviews it. A separate reviewer, prompted to refute the diff, catches the plausible-but-wrong code the author will always wave through.
Nothing merges without a human who can see the blast radius the model can't.
"It compiles and the tests pass" is the start of review, not the end — because the model will write tests that agree with its own wrong mental model.

That separation — author here, skeptic there, human on the merge button — is the whole reason I could hand the typing to a machine and still sleep. It's also, not coincidentally, exactly how we build xenition: agents that do the work, a different agent that tries to tear it down, and a person who owns the decision. Dogfooding that on a real 30-day build is the only benchmark I trust.

Would I do it again?

For a prototype? In a heartbeat — I'd never scaffold by hand again.

For production? I'll use AI for 100% of the typing and 0% of the thinking. The typing was never the hard part. It just felt like it was.

So, honest question for the comments: if AI is doing the junior work, how does your team plan to grow the next generation of seniors? Because I don't think "they'll figure it out" is an answer anymore. 👇

(If this was worth your time, a ❤️ and a 🔖 help — and tell me your worst "the AI wrote something that looked totally fine" story below.)