DEV Community: Info Inlet

How I built a SaaS in a weekend with Claude + Next.js — the honest breakdown

Info Inlet — Sat, 17 Oct 2026 07:32:53 +0000

I built the first working version of my SaaS in a weekend with Claude and Next.js. That sentence is true, and it's also the least interesting thing I can tell you about the weekend.

The genre this headline belongs to is mostly a lie — not the "I did it" part, the implied part. "Weekend SaaS" posts sell you the fantasy that the hard thing is production: that if you could just type the code fast enough, you'd have a business by Monday. So they show you the scaffold, the pretty landing page, the Stripe button, and they stop exactly where the real work starts. The typing was never the hard part. The machine made that obvious by doing most of it while I watched.

So this is the other breakdown. The honest one. It's a story about one clean, green, perfectly-typed diff the model handed me on Sunday afternoon that would have quietly eaten a paying customer's money — and the one change to how I work that caught it. That change is the whole product now. The weekend just taught me what it was.

What actually happened, hour by hour, with no flexing

Let me get the "breakdown" people clicked for out of the way, because it's genuinely short.

Friday night was scaffolding, and it was stupid fast. create-next-app, the App Router, Tailwind, a Postgres instance, auth wired through a provider, the schema for the core objects. Claude wrote most of it and I steered. The stuff that used to be a Saturday of yak-shaving — config, boilerplate, the fourteenth time I've set up the same middleware — compressed into a couple of hours of me describing and the model producing. This part of the hype is real. Setup is solved.

Saturday was the actual feature: the one thing the product does that's worth paying for. Here the rhythm changed. I'd describe a slice, the model would produce a confident, plausible, well-structured implementation, and I'd spend most of my time reading it rather than writing it. Not reviewing in the "LGTM" sense — reading it the way you read a diff from a very fast junior who is never, ever unsure of themselves. Most of it was good. Some of it was good-looking and wrong, and the ratio is the entire story of building this way.

Sunday was supposed to be payments and polish. It became the reason this post exists.

The diff that looked perfect

Sunday afternoon I asked for the webhook handler — the thing that receives the payment event and updates the account. The model gave me back exactly what you'd want to see. Typed end to end. Idiomatic. Error handling in the right places. It even added a comment explaining the retry semantics, which is the kind of thoughtful touch that makes you trust the author. It compiled, it passed the test it had helpfully written for itself, and it read clean.

It acknowledged the webhook before it persisted the row.

If you've never been burned by that line, it looks like nothing. The handler returns its 200 OK to the payment provider, and then writes the record to the database. 99.9% of the time those two things happen microseconds apart and you never notice. But the provider retries on anything that isn't a fast 200, and the write can fail or lag — and on the one bad night where the ack goes out and the save doesn't land, the provider sees success, never retries, and you have a customer who paid you with no record that they did. Locked out of the thing they just bought, nothing in the logs to say they were ever there.

I know this bug in my body. I shipped it years ago, on a different product, with no AI anywhere near it — a clean write path that acked before it persisted, and a phone call I can still feel from the customer it locked out. So I recognized it on sight. That's the only reason I caught it. The model didn't flag it, because nothing about the code looks wrong — it looks like the work of someone careful. The bug isn't in the syntax. It's in the ordering, and the ordering reads fine.

Here's the part that should bother you more than it bothered me in the moment: two lines reordered. That's the fix. The most dangerous diff of the weekend and the cheapest to repair — if, and only if, someone in the loop was actively asking "what happens on the retry?" instead of admiring the clean code.

The thing I changed — and it's not "review the AI's output more carefully"

The obvious lesson is "read what the model writes." True, useless. I did read it. I caught this one because I'd personally been set on fire by it once; I will not catch the next one that burned somebody else. "Be more careful" is not a system. It's a hope, and hope doesn't scale past the bugs you happen to have scar tissue for.

The real lesson is structural, and it's embarrassingly simple:

The thing that writes the code cannot be the thing that blesses the code.

When I ask one model to produce a diff and tell me if it's safe, I'm asking the author to grade their own homework, in the same confident voice they use for everything. It wrote the ack-before-persist handler and it would have told me the handler was correct, because from the inside of "I just produced this," it is correct — it compiles, it matches the request, it looks like care. Self-assessment is exactly the thing an eager author is worst at.

So I stopped doing that. Now the model that generates the diff is never the one that signs off on it. There's an author pass whose job is to produce — fast, cheap, endless, genuinely great at the thing that got easy. Then there's a separate skeptic pass whose entire job is to try to break that diff rather than admire it — prompted not for "is this good" but for "here is a diff, find the input that makes it lose money." Asked that way, about that handler, the retry case is the first thing it reaches for. And then there's a human on the merge button — me — who owns the call and can see the blast radius neither pass can, because I'm the one who knows a locked-out customer is a phone call and not a log line.

Author, skeptic, human. The author has infinite throughput and I've learned to measure it by almost nothing. The skeptic produces zero code and it's the most valuable seat in the system. That's not a philosophy I read somewhere — it's the shape the weekend beat into me, when the author handed me a beautiful diff that would have cost me a customer and had no idea it had done anything wrong.

What a weekend actually buys you (and what it doesn't)

Since I'm being honest about the rest of it: a weekend gets you a prototype that proves the core loop works. It does not get you a business. By Sunday night I had a thing that did the one valuable action end to end, for me, on my machine, with my data. That's real and it's worth something — it's the difference between an idea and an artifact you can put in front of a person.

What the weekend did not produce, and what no weekend produces: the error states, the empty states, the "what happens when the input is garbage," the billing edge cases, the abuse vectors, the onboarding, the second user who doesn't think like you, the thing that stays up at 2am. That's not weeks of work, it's months, and it's most of the actual product. The machine compressed the part that was already the easy part and left the hard part exactly as hard as it always was — arguably harder, because now there's more confident, plausible code to be wrong in.

So when you read "I built a SaaS in a weekend," translate it to "I built a convincing prototype of the core loop in a weekend, and the machine made the typing cheap enough that I could spend the whole time on whether the thing was right instead of whether it existed." That's the actual gift. It's smaller than the headline and much more useful.

Why that weekend is the entire architecture of what I build now

That near-miss on Sunday wasn't a footnote to the project. It became the project.

The thing I'm building, xenition, is an agent platform, and the whole industry right now wants to cheer for the part that produces — look how much it ships, look how clean, look how fast. But a generator is just doing the skill that stopped being scarce, at a scale no human can match, and then signing off on its own work in the same even voice whether the diff is a masterpiece or the handler that eats a payment. So the entire shape of the product is the thing my weekend taught me: never let the author bless its own output. An author that generates, a skeptic whose only job is to attack what the author made, and a human who owns the merge. The abundant thing, the scarce thing, and the person accountable for the call.

I didn't set out that weekend to find a product architecture. I set out to see how far Claude and Next.js could get me by Monday. The answer was: all the way to a working prototype, and one reorder-two-lines bug away from shipping a disaster that looked exactly like success. Which turned out to be the most valuable thing the weekend could have shown me.

How I Became a Better Developer by Writing Less Code

Info Inlet — Wed, 14 Oct 2026 09:35:44 +0000

The best thing I shipped last year was a diff that deleted more than it added.

I don't mean that as a humble-brag about clean code. I mean it literally changed how I think about my own job. For about a decade I had one quiet, unexamined definition of getting better as a developer: produce more. More features, more commits, more lines that worked, more of the thing on the screen at the end of the day. I never said it out loud because it never needed saying — it was just the water I swam in. More output was more skill. Everyone I respected produced a lot, so I tried to produce a lot.

Then the machine showed up and let me produce more than I ever had in my life. And the most "productive" quarter I'd had in years is the one that nearly cost us a paying customer. That's the story. It's the reason I now think the thing that made me better wasn't learning to write more — it was learning to write less.

The decade where "more" was just true

I want to be fair to the old me, because he wasn't stupid. For most of the history of this job, producing the code genuinely was the hard part. It was slow. It was bottlenecked on you — your fingers, your working memory, your ability to hold the whole shape in your head while you typed it out. If you shipped a lot of good code, that meant something real: you had the skill, you understood the system, you could do the work nobody else could do as fast.

So "more output = better developer" wasn't a mistake. It was a decent proxy, honest enough to build a career on. The volume was expensive to produce, so the volume was evidence. Nobody could fake a mountain of working code; producing it was the skill, bundled all together. I measured myself by the mountain because, back then, the mountain and the skill were the same thing.

That's the assumption I never noticed I was making. And it's the exact assumption that stopped being true.

Then production got cheap, and I didn't update

Here's what nobody warns you about when the machine gets good: at first it feels like you leveled up.

Code got cheap for me almost overnight. Not free, not always correct — but cheap. A competent first draft of a well-scoped change went from a day of typing to a few minutes of generating and shaping. My throughput went vertical. More commits, bigger diffs, features landing faster than I'd ever landed them. By my own decade-old scorecard — produce more — I was having the best year of my career.

And for a while that felt like getting better. It took me an embarrassingly long time to notice I hadn't gotten better at anything. I'd just gotten faster at the part that stopped being hard. The mountain was still growing, but the mountain had stopped being evidence of anything, because now anyone with the machine could make a mountain. I was pouring more effort into the one input that had just become abundant, and feeling great about it, because my scorecard only knew how to count that input.

The scar: the most productive code I wrote all year

Let me make it concrete, because this is the moment the whole thing turned over for me.

I shipped a write path that acknowledged a request before it had actually persisted the row. The code was clean. Idiomatic, typed, tested, reviewed, green. It was productive code — it moved fast, it closed the ticket, it made my output numbers look great that sprint. By every measure I'd used to rate myself for ten years, it was good work.

Then one ordinary day a retry hit at exactly the wrong moment. The "got it" went out, the save never landed, and a paying customer got locked out of their own account with nothing in the logs to say they'd ever been there. Ack before persist. I can still feel the phone call.

Here's the part that rearranged my head. That bug didn't get in despite me being productive. It got in because of it. The speed that my scorecard was rewarding is the exact thing that carried a confident, clean, plausible, catastrophic diff straight past me. I wasn't going slow enough to ask the one question that mattered — what does this do if it retries? — because asking it produces nothing, and I was optimizing for producing.

The cure, when we finally found it, was two lines reordered. Negative code. The most valuable change I made that entire quarter subtracted from the total. And there was no row on my mental scorecard where that went.

What I was actually getting paid for, and never measured

Once I saw it, I couldn't unsee it. When code was the bottleneck, judgment came bundled into writing it — you couldn't produce the thing without making a thousand small decisions along the way, so you never had to think of judgment as a separate skill. It rode along for free inside the typing.

The machine ripped them apart. Now I can have all the output I want without exercising any judgment over it at all. Which means judgment is suddenly standing on its own, for the first time, as the thing that's actually scarce. Not "can I produce the code" — the machine does that. It's "can I tell which of these confident, clean, plausible diffs is quietly wrong before it reaches a customer at 2am."

And the scarcest, lowest-status form of that is the one I'd spent a decade not counting: the "no." The deleted function. The feature I talk the team out of. The one-sentence question on a pull request that stops a bad night before it happens. None of it produces anything. All of it prevents. And prevention was invisible to every instrument — including the one in my own head — that I'd ever used to decide whether I was any good.

What "writing less code" actually looks like

So "I got better by writing less" isn't a Zen koan. It's a set of concrete habits I didn't have before and do now:

I delete before I add. The first question on most changes now is "can this be less code," not "what do I add." A smaller surface is fewer places for the machine's confident, wrong guess to hide. The diff that removes a special case is worth more to me than the one that adds a feature, and it used to be the reverse.
I treat the question as the deliverable. "What happens on the retry? what if this is empty? what if two of these race?" produces zero lines and is the highest-leverage thing I do all week. I stopped waiting to have an answer before I counted the asking as work.
I review the machine instead of racing it. The machine's job is to produce the mountain; my job is the one thing it structurally cannot do — distrust its own output. Every green, confident diff gets read like it's trying to lie to me, because the ack-before-persist one did.
I stopped reading a small diff as a small contribution. Some weeks the most valuable thing I do is the three lines I stopped from shipping. My old scorecard would've logged that week as coasting. I go looking for those on purpose now.

To be clear — this is not "shipping is for juniors"

I want to be careful, because the lazy version of this is "real developers don't write code, they think deep thoughts," and that's garbage.

Shipping matters. I ship all day. The machine writes most of my code now and I would never go back — the typing was never the hard part, and a developer who produces nothing isn't a wise skeptic, he's just slow. Output is table stakes. You still have to deliver the thing.

The claim is narrower, and I think it's hard to argue with once you've lived it: output stopped being the scarce thing, so it stopped being the thing that makes you better at this job. When production was the hard part, getting faster at production was getting better. Now production is the cheap part, and getting better means getting good at the judgment the machine hands back to you un-exercised. I didn't stop shipping. I stopped mistaking the thing the machine now does for the thing I'm actually here to do.

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

One level up, it's the same lesson, and it's why I build an agent platform the way I do.

The whole industry right now wants to cheer for the thing that produces — look how much it ships, look how clean, look how fast. But an agent that generates is just doing the skill that stopped being scarce, at a scale no human can match, and then — worse — it signs off on its own work in the same confident voice whether the diff is a masterpiece or the ack-before-persist bug all over again. It's the productive version of me from last year with the volume turned up to infinity: endless throughput, zero "no."

So I never let the thing that writes the code be the thing that blesses it. There's an author that produces the diff — cheap, fast, endless, the abundant thing. There's a separate skeptic whose entire job is to try to break that diff rather than admire it — the "no" given its own seat, so it doesn't depend on one tired human remembering to ask the retry question at the end of a long day. And there's a human on the merge button who owns the call and sees the blast radius neither agent can. Author, skeptic, human. The author has infinite throughput and I measure it by almost nothing. The skeptic has zero throughput and it's the whole point. That's the shape of xenition, and it's just the thing my own scar taught me, built into software: the moment production got cheap, the thing worth paying for stopped being production.

I spent a decade getting better by adding. I got good the year I started subtracting — and the machine, by making the adding free, is the thing that finally showed me the difference.

From $0 to my first dev job in 6 months — no CS degree

Info Inlet — Tue, 13 Oct 2026 09:45:01 +0000

Six months ago I had $0 in the bank earmarked for this, no computer science degree, and a browser tab open on "how to become a developer." Last week I signed my first dev job offer.

I'm not writing this to sell you a bootcamp or a course — I bought neither. I'm writing it because almost everything I was told about how to get that first job turned out to be a distraction from the one thing that actually worked.

The thing that worked wasn't learning more. It was shipping.

What I thought the job was (and what it actually is)

For the first six weeks I did what everyone tells you to do. I watched courses. I did the exercises. I rewrote the todo app four times in four frameworks. I started — and this is the part that stings — a LeetCode streak, because someone on a forum said that's what "real" developers grind.

I was busy every single day and I was getting nowhere. Here's why, and it took me embarrassingly long to see it:

The rule: tutorials teach you to follow. The job is to decide. You can finish a hundred tutorials and still have never once made a real decision — what to build, what to cut, what to do when the thing just breaks and there's no "next lesson" button.

Everything in a course is scoped so you can't fail. The requirements are fixed, the answer exists, and the happy path is paved. None of that is true on the job. The job is ambiguous requirements, a half-working API, and a user doing something you never imagined. I had spent six weeks practicing a game that nobody actually hires for.

So I quit the tutorials and made a rule: I only build things a stranger could use.

The portfolio that got me hired (and the one that didn't)

My first "portfolio" was three repos: the todo app, a weather dashboard, and a half-finished clone of a site everyone clones. Standard. Dead on arrival. No recruiter has ever once opened a weather app clone and felt anything.

The portfolio that got me interviews was three completely different things:

A small booking tool for my cousin's salon — real bookings, real customers, real "it broke on Saturday and I had to fix it before they opened."
An inventory tracker for a local shop that was running on a paper notebook.
A tiny invoicing app I built for myself and then three freelancers started using.

None of them are impressive as code. What made them work in interviews is that every one of them had a user who was not me, and a story about something going wrong in production and me fixing it.

The rule: nobody hiring a junior asks what you've learned. They ask what you've shipped that a stranger actually used. One of those is checkable. The other is a vibe.

The first time I said "a real customer double-booked because of a race condition in my code and here's how I found it and fixed it," I watched the interviewer's posture change. That sentence did more than my entire "skills" list. It's the difference between I studied this and this happened to me.

How I shipped real apps without a team (the uncomfortable part)

Here's the part some people won't like, and I'd rather say it straight than hide it: I could not have shipped three real, running apps in six months by hand-writing every line while also learning the fundamentals. There aren't enough hours.

What let me move at that pace was treating "building the app" and "understanding the app" as two separate jobs. I'd get a working, deployed version standing up fast — real database, real users, real URL — and then I'd go read it, break it, and rebuild the parts I didn't understand. Shipping first, understanding second, is backwards from how courses teach it, and it's the only order that kept me motivated, because a thing that's live is a thing you can't lie to yourself about.

The rule: a deployed app with one real user teaches you more in a week than a tutorial does in a month — because the user does the thing you swore nobody would do, and now it's your problem, not the instructor's.

The point was never "don't learn the fundamentals." I learned more fundamentals debugging a live booking race than I ever did in a course. The point is the live app was the curriculum, and it set its own syllabus in the exact order I needed it.

The six months, honestly (the shape, not fake precision)

I won't hand you a fake day-by-day plan, because mine wasn't clean and yours won't be either. The shape is the lesson:

Weeks 1–6: tutorials and LeetCode. Felt productive. Was not. This is the part I'd delete if I could.
Weeks 7–14: first real app (the booking tool). Shipped it ugly, broke it constantly, fixed it in public. Learned more here than everywhere else combined.
Weeks 15–20: two more real apps, each faster than the last, each with a real user I could point an interviewer at.
Weeks 21–26: applied. Got rejected plenty. But every callback traced back to the same thing — a real app with a real user and a real war story, not a certificate.

I counted later: the interviews I got came almost entirely from the three real apps. The tutorials, the streak, the certificates I'd half-collected — not one of them ever came up in a room where someone decided whether to hire me.

The rule: a portfolio of three real apps with real users beats a shelf of certificates in the room where they actually decide. The certificate says you attended. The shipped app says you can finish.

If you're where I was six months ago

You don't need my exact path. You need to stop doing the thing that only feels like progress and start doing the thing that's checkable:

Pick something one real person actually needs. Not a clone. Your aunt's bookings, your own invoices, your team's spreadsheet that should be an app. The smaller and more real, the better.
Ship it before it's good. A live URL with one user beats a perfect repo with none. Deploy embarrassingly early.
Then go understand what you shipped. Break it on purpose. Read your own code like a stranger wrote it. That's where the fundamentals finally stick.
Keep the war stories. Every "it broke and I fixed it" is a sentence that will out-perform your entire skills list in an interview.

The degree gets you past some filters. I won't pretend otherwise. But the thing that gets you hired — the thing in the room when a human decides — is evidence that you can take something ambiguous and make it real and keep it running when it breaks.

The rule: the fastest way to look like a senior while you're still a junior is to have already shipped something that survived contact with a real user. You can't fake that, and you don't need a degree to have it.

A single console.log was costing us $40,000 a year. I found it by accident.

Info Inlet — Mon, 12 Oct 2026 06:51:44 +0000

Our API was slow. Not down, not throwing — just mysteriously, expensively slow under load. The p99 crept up month over month. We scaled out servers to keep latency sane. The cloud bill climbed. Everyone had a theory and nobody had a cause.

We blamed the database. We blamed the ORM. We blamed the new framework version. We blamed, briefly and unfairly, the intern.

The actual culprit was a line none of us would have looked at twice:

logger.info(`Request payload: ${JSON.stringify(req.body)}`)

I only found it because I was profiling something else. That's the part that still bothers me.

Why a log line nobody reads can still cost you money

Here's the thing that line does that isn't obvious: it does all its work before the logger gets a vote.

In production our log level was warn. So logger.info(...) was a no-op — the logger took the finished string, checked the level, and dropped it on the floor. Every time. We were paying full price to build a thing we had already decided to throw away.

Walk through what "build it" means on a hot path that runs on every single request:

JSON.stringify(req.body) serializes the entire request body. Some of ours were small. Some were a few hundred KB of nested arrays.
The template literal concatenates that into a new string — another full copy in memory.
All of that garbage gets allocated, then handed to the logger, which looks at the level and says "nope," and now the garbage collector has to clean up megabytes of strings nobody ever saw.

The logging was free. The preparing to log was the tax. And we paid it on every request, forever, for output that physically never left the process.

The rule: your code isn't just what it computes. It's also what it prepares to compute and then discards. On a cold path that's invisible. On a hot path it's the bill.

How it hid for so long

This is the uncomfortable part, because the line is correct. It compiles, it does exactly what it says, it passed review (I approved it). In a unit test it's instant — one call, tiny payload, who'd notice.

It only becomes a problem at the intersection of three things that no single person was looking at together:

it's on a path that runs on every request (volume),
the payload is sometimes large (cost per call),
the log level means the result is always thrown away (pure waste).

Each of those is fine alone. Stacked, they turned a debugging convenience into a line item. And because the symptom was "the whole service is a bit slow and a bit expensive," it pointed at everything except the one line responsible. Slowness with no single owner is the hardest kind to find — there's no stack trace for "death by a thousand allocations."

The rule: the expensive bugs aren't the ones that break something. They're the ones that quietly tax something that runs a million times a day.

The one-line fix

The fix is to stop building the string yourself and let the logger decide whether it's even worth building.

// ❌ Builds and serializes the string ALWAYS — even when it's dropped
logger.info(`Request payload: ${JSON.stringify(req.body)}`)

// ✅ Pass the object. The logger serializes lazily — only if this level will log.
logger.info('Request payload: %o', req.body)

Pass the object, not a pre-built string. Now the serialization is the logger's problem, and a decent logger only does it if the level is actually going to print. At warn in prod, req.body is never touched. At debug locally, you get your full payload. Same code, and the cost appears exactly when the value does.

If your logger doesn't support lazy args, the explicit guard does the same job:

if (logger.isLevelEnabled('info')) {
  logger.info(`Request payload: ${JSON.stringify(req.body)}`)
}

Uglier, but it makes the point visible: nothing gets built unless someone's going to read it.

What changed

I'm not going to hand you a fake precision — I'll tell you the shape of it, because the shape is the lesson.

p99 latency dropped sharply once the per-request allocation and GC pressure went away. The service stopped doing a pile of pointless work on the critical path.
We scaled back down. We'd been running extra instances purely to absorb the overhead of garbage we generated and deleted. Those instances came off.
Annualized, the instance reduction was in the tens of thousands of dollars. For us it rounded to about $40k/year — not from a clever optimization, but from deleting work we were doing for no reason at all.

The ROI on that one line was the best of anything I shipped that quarter, and I shipped real features that quarter. That ratio should make you a little uncomfortable. It does me.

The rule: the highest-leverage performance work is usually not making the slow thing fast. It's finding the fast thing you're doing a million times for nothing.

Go check your own hot paths

You almost certainly have one of these. Not necessarily a log line — the pattern is wider than logging:

Eager serialization that gets discarded — building a string/JSON for a log, a metric tag, or an error message that only matters on the unhappy path.
Work done before a guard instead of behind it — computing a value, then checking whether you needed it.
Debug conveniences that outlived the debugging — the console.log you added to find a bug in 2023 that's still running in 2026.

Find the three or four functions that run on every request. Read them not for correctness — they're correct — but for waste: what are they building that they then throw away? That's where the money is.

The rule: hot paths don't care about your intentions. They run millions of times. A "harmless" line in the wrong place is a tax you pay on every request until someone, by accident, reads the right log.

Disclosure: I build on xenition, a workspace assistant that builds and runs agents — and agents are merciless at generating exactly this kind of "correct but wasteful" code, because a clean, confident diff hides a pointless allocation just as well as it hides a logic bug. A lot of my "read hot paths for waste, not just correctness" paranoia is earned on our own systems. Read it as a builder's bias; I'd rather name it than hide it.

What's the dumbest expensive line you've ever shipped — the one that was individually correct and collectively a disaster? I'll go first in the comments, and I want the horror stories: the ones that only turned up because someone was looking for something else.

I Replaced My Entire Dev Workflow With AI Agents — Here's What Actually Worked

Info Inlet — Sun, 11 Oct 2026 10:37:17 +0000

I didn't set out to "replace my workflow with AI." I set out to answer a narrower, more honest question: which parts of my job are actually typing, and which parts are judgment I've been pretending were typing?

So I took my normal pipeline — plan, write, test, review, debug, ship — and moved each stage onto an agent, one at a time, for a few weeks. I kept whatever held and ripped out whatever didn't.

Here's the stage-by-stage result. No scorecard, no "I shipped 40 PRs" number — just the shape of what won and what quietly broke.

Stage 1: Planning — the agent is great at writing a plan, bad at having one

I expected planning to be the agent's weakest stage. It's half right.

Hand an agent a vague ticket — "users are complaining checkout is slow" — and ask for a plan, and you get something that looks like a plan: numbered steps, files to touch, a rollback note. It reads well. It is also frequently a plan for the wrong problem, because the agent filled the ambiguity with the most statistically likely interpretation, not the true one.

What actually worked was inverting it. I stopped asking the agent to decide the plan and started asking it to draft the plan from a spec I'd already pinned down. The judgment — what problem are we even solving — stayed with me. The typing — turning that into acceptance criteria, edge cases, a file list — went to the agent, and it's genuinely faster than me at that.

The rule: an agent turns a decision into a document beautifully. It cannot make the decision for you — and its confident draft will hide that it didn't.

Stage 2: Writing code — won, on exactly the work you'd expect

This is the stage everyone pictures, and it's the least interesting result because it's the one that just works.

The agent won clean on anything where the hard part was typing, not deciding:

CRUD endpoints with a clear schema
a migration with a written spec
wiring a form to an API I'd already designed
a mechanical refactor across 30 files — and crucially, it doesn't get bored on file 27, which is exactly where I introduce a typo
dependency bumps and the follow-on fixes

It lost on anything where the code was the easy part and the decision was buried in it: "why is this column nullable," "should this be one service or two," "is this edge case real or theoretical." The agent will answer all three confidently and sometimes wrongly, and the code it writes on top of the wrong answer is clean, tested, and shippable-looking.

The rule: agents are fastest exactly where the code is downstream of a decision you already made. The danger is they'll happily make the decision too, and you can't see that in the diff.

Stage 3: Testing — this was the real surprise, and the real trap

Writing tests is high-typing, low-glory work, so I assumed it was pure upside. It mostly is — the agent wrote months of "we'll get to it later" tests with no ego and no counter-pitch. That part was a gift.

But there's a trap underneath it that took me a week to see:

If the same agent writes the code and the tests, the tests pass — and they're worthless. They don't test whether the code is correct. They test whether the code does what the code does. The agent read its own implementation and wrote tests that encode its own assumptions, including the wrong ones. Green board, zero signal.

The fix was structural, not prompt-level: the test agent is a different agent, and it gets the spec, not the implementation. Now the tests encode what the thing is supposed to do, and when they disagree with the code, that disagreement is the whole point.

The rule: code and tests from the same agent agree with each other, not with reality. Separate the author from the examiner, or you're just asking the model to grade its own homework.

Stage 4: Review — where I learned the workflow didn't actually get shorter

Here's the stage I got wrong for the longest.

I added a reviewer agent to read every diff before I did. It's good — it catches the mechanical stuff fast: an unhandled error path, a missing null check, a test that asserts nothing. For that class of bug it's a better first pass than tired-me at 6pm.

What it cannot do is the review that actually matters: is this change solving the right problem, and does it break something three files away that isn't in the diff? That's the exact failure mode the code agent produces — every line individually correct, the decision wrong, and nothing in the diff looks wrong because nothing in the diff is wrong locally.

So the reviewer agent triages; it doesn't absolve. The judgment review still lands on me. And that's when it clicked: I hadn't removed work from my week. I'd moved it. Less time typing code, far more time writing specs up front and reading diffs like a hostile stranger wrote them.

The rule: a second agent reviewing the first agent's work catches typos, not decisions. The judgment review is not delegable, and pretending it is, is how a clean diff with a wrong decision gets merged.

Stage 5: Debugging — won when the loop was closed, lost when it needed a hunch

Debugging split cleanly.

When there's a closed feedback loop — a failing test, a stack trace, a reproducible error — the agent is excellent. It runs the test, reads the failure, forms a hypothesis, patches, re-runs. That loop is native to an agent with a terminal, and it'll grind through it faster and more patiently than I will.

When the bug needs a hunch — "it's slow but only in prod," "this only happens for users who signed up before the migration" — the agent flails. It needs the thing it doesn't have: the half-memory of a decision made eight months ago that never made it into the code. That's where a human who was there beats any amount of context window.

The rule: agents close loops; they don't form hunches. Give them the reproduction and they're great. Ask them to find the reproduction in a vague prod report and you're better off driving.

Stage 6: The boring glue — pure, unambiguous win

PR descriptions. Changelogs. Commit messages. Release notes. Backfilling docstrings. Writing the "why" comment I always skip.

This is high-typing, low-judgment, and nobody's ego is attached to it. It is the least discussed stage and the one with the cleanest return. If you're going to put one agent in your workflow tomorrow, make it this one — zero risk, immediate time back, and it quietly makes everyone else's code more readable.

The rule: the safest, highest-ROI agent is the one writing the prose around your code, not the code.

The honest summary: the bottleneck moved, it didn't disappear

If you chart my week before and after, the total didn't shrink much. What changed is where the time goes:

Stage	Before	After
Deciding what to build	some	more
Writing the spec	little	a lot more
Typing the code	a lot	little
Writing tests	little (be honest)	some — but reviewing them
Reviewing diffs	some	a lot more
The boring glue	always skipped	done, automatically

The agents genuinely won the typing. But every hour they gave me back on typing, they handed back as spec-writing and diff-reading — because those are the two places where their confident wrongness has to be caught by my judgment.

That's not a complaint. It's the actual job now, and it's a better job. But it's a different one, and the people getting burned are the ones who think "the AI writes the code" means "the AI does the work." The code was never the work. It was the part that happened to look like the work.

What I'd actually tell you to do

Start with the glue** (Stage 6). Zero risk, instant payoff, builds your trust in the tooling.
Then the high-typing code** (Stage 2) — but only where you've already made the decision. Write the spec first, by hand.
Split your test agent from your code agent** (Stage 3). This is the single highest-leverage structural choice in the whole setup.
Keep the judgment review on a human.** Use a reviewer agent as a first pass, never as the last word.
Read every diff like a stranger wrote it** — because one did, and it's a stranger that never gets tired and never says "I'm not sure about this part."

Disclosure: I build on xenition, a workspace assistant that builds and runs agents — so I ran a lot of this on our own agents against our own backlog. Read my "always keep a skeptic on the diff" stance as a builder's bias; I'd rather name it than hide it.

If you've moved part of your workflow onto agents: which stage held, and which one quietly burned you? I'm most interested in the stage you assumed was safe and wasn't.

I let an agent run unattended overnight. At 3am it emailed 400 customers the wrong thing.

Info Inlet — Sat, 10 Oct 2026 06:21:13 +0000

I found out at 9am what my software did at 3am. That's the whole story of unattended automation in one sentence, and I had to live it before I believed it.

The automation was supposed to be the responsible kind. Every night it reconciled the day's payments against our processor, found the charges that had actually failed, and emailed those customers a polite "your payment didn't go through, here's how to fix it" note before their account lapsed. Dull, necessary, repetitive work — the exact shape of thing everyone tells you to automate. So I automated it. Set it to run at 3am when the processor's data had settled. Set it, and — the phrase that should make every one of us flinch now — forgot it.

One night the reconciliation ran against a half-written ledger. A batch of payments had been acknowledged by the processor's webhook before our own row had actually persisted — the save landed a few seconds late, and the 3am job read the gap as "these payments failed." It did exactly what I built it to do. Tirelessly, correctly, on schedule, it emailed four hundred paying customers to tell them their payment had failed when it hadn't. No human saw the batch. No human saw the send. I saw the support queue at 9am, already two hundred tickets deep, from people who'd paid us and been told by our own software that they hadn't.

Nothing about that automation was broken. Every line did its job. The thing that failed wasn't the code. It was the decision to let the one step that reached four hundred real people happen with nobody in the room.

"Set it and forget it" quietly swaps two different things

Here's the sleight of hand in that phrase, and it took me a 9am support fire to see it.

A recurring job is really two things stapled together. There's the labor — pull the data, match the rows, reconcile the numbers, draft the message, assemble the report. Tedious, mechanical, the same every night, genuinely a waste of a human's evening. And there's the judgment — the half-second where someone looks at the output and goes "wait, two hundred of these are for customers who definitely paid, something's off, don't send." One of those two things is what makes the work a chore. The other is the only thing that was ever protecting you.

"Set it and forget it" sells you on automating the first and quietly automates the second along with it. You think you're deleting the tedium. You're also deleting the one glance that would have caught the half-written ledger. They came stapled together — the person doing the boring reconciliation was also, for free, the person who'd notice the batch looked insane — and the automation rips them apart and throws both away.

That's the move. Nobody decides "I'll remove the human judgment from my payment emails." You decide "I'll stop spending my evenings on reconciliation," which is completely reasonable, and the judgment leaves in the same box as the tedium because you never noticed they were two different things.

The labor was never the dangerous part of the job. The judgment was the whole point of a human being there, and it left in the same box as the tedium.

Unattended doesn't mean fewer failure modes. It means the same ones, at 3am, with nobody there

The seductive story about a scheduled agent is that it's safer — no tired human at midnight fat-fingering a number, no forgotten Monday task, no "oh no I never sent the invoices." And that's real. Automation genuinely removes a whole class of human error.

What it does not remove is the other class: the input that's subtly wrong, the state that's half-written, the edge case the schedule happens to land on. A human running the reconciliation at their desk at 2pm hits the exact same half-written ledger — and stops, because a person looking at four hundred "your payment failed" emails for customers they recognize feels the wrongness before they feel the logic. The agent at 3am hits the same bad state and has no such flinch. It doesn't pause. It doesn't feel anything. It ships.

So unattended automation doesn't give you a system with fewer ways to fail. It gives you a system with the same ways to fail, running at the hour when the fewest people are watching, aimed at the most real-world-facing step, with the one safeguard — a human who'd go "that can't be right" — specifically removed. We tell ourselves we're buying reliability. We're buying the same risk with the smoke detector taken down.

The irreversible step is the one you were never trying to automate

Walk back through my 3am job and separate what I actually wanted off my plate from what I accidentally handed over.

The pulling, the matching, the reconciling, the drafting — take it, please, I never wanted to do any of that at my desk. But the send — the four hundred emails leaving our servers and landing in four hundred inboxes — that was never the part I was trying to get rid of. That part is trivial. It's one button. It takes a human half a second. I didn't automate the send because the send was hard work. I automated it because it was attached to the work I wanted gone, and I let the whole chain run end to end without ever asking whether the last link belonged in the chain.

And the last link is always the dangerous one. It's the step that touches the real world and can't be pulled back: the message that goes out, the payment that moves, the deploy that goes live, the record that gets deleted. Everything before it is reversible — a bad draft is nothing, a wrong reconciliation is a number you recompute. The moment it leaves the building, it's a fact in four hundred other people's lives. That's the step, and it's the one step that costs a human almost nothing to own, because owning it is one glance and one tap.

The tragedy of "set it and forget it" is that it automates exactly the wrong half. It takes the cheap, safe, reversible labor — fine — and then, because it came in the same box, it also takes the one expensive, irreversible step that was the entire reason a person needed to be in the loop at all.

To be clear — this is not "don't automate"

I want to be careful, because the lazy version of this is "automation is dangerous, do it all by hand," and that's how you end up a person manually reconciling payments at midnight, which is both miserable and more error-prone, not less.

Automate aggressively. I do. The recurring report should build itself. The data should pull itself. The draft should write itself. The reconciliation should run every night at 3am exactly as mine did — I would never go back to doing that by hand, and a team that refuses to automate recurring labor out of fear isn't careful, it's just slow and tired. The labor should run while you sleep. That part of "set it and forget it" is a gift.

The claim is narrower and, I think, much harder to argue with: the recurring work and the irreversible step are two different jobs, and the schedule should only own one of them. Let the agent do everything all night. Let it do the whole tedious chain unattended. And then, at the one step that reaches the real world and can't be undone, let it stop and leave that decision sitting on your desk for the morning — not fire it into four hundred inboxes while you sleep. That's not un-automating. It's automating the commute and keeping the signature.

What I do now, since I learned it the expensive way

The 3am email fire changed how I build every recurring thing:

I split every automation at the irreversible line. Everything up to and including "assemble the thing that's about to go out" runs unattended on schedule. The step that sends, pays, deploys, or deletes does not fire automatically — it lands in a queue as "here's what I'm about to do to the real world, approve?" The labor runs at 3am. The decision waits for 9am.
I make the agent show its blast radius. The approval doesn't say "send emails?" It says "send 400 emails, here are three of them, here's the ledger query they're based on." That one number — 400 — is the entire save. A half-written ledger produces a batch that looks visibly, obviously wrong the second a human sees the count, and a human sees the count before a single email leaves.
I stopped trusting "it ran clean" as "it ran right." My 3am job ran perfectly clean every single night, including the night it torched our support queue. Green is not the same as correct, and an unattended system has no one to tell the difference. So the only thing I let run truly unattended is the work that's reversible if it's wrong.

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

One level up, it's the same problem, and it's why I build an agent platform the way I do.

Everyone selling autonomous agents right now is selling the 3am dream: it runs while you sleep, it does the whole job, you wake up and it's done. And the demo always stops one frame before the part where it sends four hundred emails to real people on a bad night with nobody watching. The impressive part of an agent — that it can run the whole chain unattended, tirelessly, on a schedule — is also the exact mechanism by which it does something irreversible to the real world before anyone can flinch.

So I never let the schedule own the irreversible step. An agent can run the entire recurring job overnight — reconcile, draft, build, assemble — as an author that produces, tirelessly, at 3am. A second skeptic agent tries to break the output rather than admire it, so a half-written ledger gets caught by something whose whole job is doubt. And every step that reaches the real world — the send, the payment, the deploy, the delete — stops and waits for a human on the button, who sees the blast radius the schedule never will. The labor runs while you sleep. The signature waits for you to wake up. That's the shape of xenition, and it's the same lesson the support queue taught me at 9am: automating the work was always fine. Automating the one decision that reaches four hundred people was never the thing I actually wanted.

I set it and I forgot it. The software didn't forget. It did exactly what I told it, to four hundred people, at 3am, with no one in the room. The labor was never the thing that needed me there.

I let my AI agents merge to production. Once.

Info Inlet — Wed, 07 Oct 2026 04:38:27 +0000

I automated almost my entire pipeline this year, and I'd fight you to keep it that way.

An agent writes the first draft of most changes now. A second agent reviews that diff — harder than I do at 5pm on a Friday, and it never gets bored on the four-hundredth one. Tests run themselves. Types, lint, a staging deploy, a smoke check against a real-ish database. By the time a change gets anywhere near me, five separate automated steps have already looked at it and said yes. It is genuinely better than the hand-cranked version I ran three years ago, and the typing was never the part I'll miss.

So one sprint I did the obvious last thing. I looked at a pull request with four green checks and a clean review already on it, and I thought: why is my hand still on the merge button? What exactly am I adding by clicking it myself that four automated yeses haven't already earned? So I gave the agents the last step too. Generate, review, test, stage, merge. Fully closed loop. For about nine days it felt like the future.

Then one of those merges locked a paying customer out of their own account at two in the morning, and I learned — expensively, in production, on a phone call — which single step in that pipeline I should never have handed over. It's not the one most people would guess. It's the one almost everybody automates first.

The diff was clean. That was the whole problem.

Here's what shipped itself.

The change was a write path. It acknowledged the request — sent the "got it" back to the client — before it had actually persisted the row. If you've been doing this a while, your stomach just dropped, because you know this bug. It is clean. It is idiomatic. It is typed, tested, and it reads perfectly right up until the moment a retry hits at the wrong instant: the "got it" goes out, the save never lands, and the system is now confidently certain about something that never happened.

The author agent wrote it. The review agent read it and approved it — and I want to be fair to the review agent, because it's good: it caught two real things that sprint that I'd have missed. It just didn't catch this one, because this one doesn't look like a bug. It looks like finished work. The tests were green because the tests tested the happy path, which is exactly the path where this code is correct. Staging was fine because nobody retried a request at the wrong millisecond against staging. Five automated yeses, all technically honest, all looking at the diff and none of them looking at the two in the morning.

It auto-merged. It auto-deployed. And on an ordinary bad night a retry hit, the ack went out, the write didn't, and a real human who pays us money got locked out of their own account with nothing in the logs to prove they'd ever been there. I can still feel the phone call — not because the bug was exotic, but because there had been no moment, anywhere in that beautiful closed loop, where a person who would get that phone call looked at the thing and owned shipping it.

Two things we call "review" — and they are not the same thing

Here is the distinction it took a locked-out customer to teach me, and it's the whole article.

We use one word, "review," for two completely different jobs.

The first job is judging the code: is this correct, is it idiomatic, does it handle the edge case, is the naming sane. That is a skill. It's pattern-matching against a huge amount of prior code and a mental model of the system. And it is exactly the kind of skill that got cheap this year. A good review agent does it tirelessly, consistently, at 3am, on the four-hundredth diff, without the fatigue that makes a human senior wave through a Friday-afternoon PR. You should absolutely automate this. I did, and it was the right call.

The second job is owning the merge: accepting that this is going to real users now, and if it's wrong, that's on me. That is not a skill. There is no pattern to match. It's the act of a specific accountable party putting their name on an irreversible, outward-facing decision and absorbing the consequence if it goes bad.

For twenty years those two jobs were welded together, because the person reviewing the code was also the person who'd get paged, so we never had to notice they were different things. Automation ripped them apart. The machine can now do the first job better than I can. It cannot do the second one at all — not because it isn't smart enough, but because the second job isn't about intelligence. It's about accountability, and accountability requires something that can actually bear a consequence.

You can automate judgment. You cannot automate accountability.

An agent that merges a bad diff and takes down prod cannot be paged. It can't be sorry. It can't carry the weight of that 2am call into how it makes the next decision, because it isn't making decisions it has a stake in — it's producing confident output at a scale no human can match and signing off in the same even voice whether the diff is a masterpiece or a time bomb. Infinite throughput, zero accountability. The merge is the one place in the whole pipeline where the buck is supposed to stop, and I'd handed it to the one participant that has no buck.

We guard the wrong click

Now here's the part that should bother you, because once you see it you see it everywhere.

Watch what teams instinctively keep manual versus what they happily automate.

They keep a human on code review. "A person has to read every diff." They put mandatory human approvals on pull requests, they argue about review coverage, they feel safe because a human's eyes were on the lines. And then they wire up auto-merge on green and a continuous deploy to prod, and feel clever for it, because that part is just plumbing.

That is exactly backwards.

Code review is the reversible step. If a human misses something in review, nothing has happened yet. You can review it again. You can comment. You can catch it in staging. Nothing has crossed into the real world. It is the single most recoverable point in the entire pipeline — and it's the one we insist stays human, even though it's now the step the machine does better.

The merge to production is the irreversible, outward-facing step. It is the exact moment the change stops being a proposal and starts being something a customer can hit at 2am. It is the one point in the pipeline where a retry can lock someone out of their account. And it's the step we're the most comfortable handing to a robot, precisely because it looks like plumbing — a button, a webhook, a green check — rather than a decision.

We guard the cheap reversible step with a human and automate the expensive irreversible one. We kept our hand on the one place the machine made safe, and took it off the one place it couldn't.

The merge produces nothing — which is the tell

There's a reason the merge button feels so automatable, and it's the same reason the "no" and the prevented outage always get undervalued: it produces nothing visible.

A merge that goes fine is invisible. Nothing happens. No artifact, no graph that goes up, no line of code with your name on it — the author agent wrote the code, the review agent found the bugs, and all you did was click a button that four green checks already justified. It looks like the most deletable job in the building.

A merge that goes bad is a countable event with a name on it: an incident, a postmortem, a locked-out customer, a phone call. So the person on the merge button is sitting in a pure-downside seat — all of the blame when it breaks, none of the credit when it doesn't. By every productivity metric you could point at, that person is doing nothing. Which is exactly why the job can't be automated away: the thing they're actually providing isn't throughput, it's a place for the consequence to land. You don't keep a human on the merge because they're faster or because they read the diff better than the agent did. You keep them there because when it goes wrong at 2am, "the pipeline did it" is not an answer you can give a customer, a regulator, or yourself.

To be clear — this is NOT "keep a human in the loop"

The lazy version of this piece is "see, you always need a human watching the AI," and that's the cope that kills teams, so let me kill it first.

Keeping a human on every step is theater. A human babysitting every generated diff, re-reading what the review agent already read, approving what the tests already proved — that's not safety, it's a slow person pretending to add value by being in the way. The machine reads diffs better than a tired senior now; making a human rubber-stamp each one just launders the robot's judgment through someone who's no longer actually looking. I automated the generation. I automated the review, and then I made the review harder than I used to, because the agent doesn't get tired of being thorough. I'd never go back. Output is table stakes and judgment-on-the-code is now something you can buy by the thousand.

The claim is narrow, and I think it's hard to argue with once the two jobs come apart: exactly one step in the pipeline has to stay human, and it's the merge — not because the human does it better, but because the human is the only participant who can be held to it. Everything upstream of that button is a skill, and skills got cheap. The button itself isn't a skill. It's a signature.

What I actually changed

I didn't rip out the automation. I re-pointed the human at the one seat that needed one:

The agents still generate and review. I made both do more, not less. The author drafts, the skeptic tries to break it. That part of the loop is better closed than open — the machine is tireless where I was tired.
A human owns every merge to production, and owns nothing else. Not as a code reviewer re-reading the diff — the agent already did that better. As the accountable party who looks at the blast radius: what does this touch, who gets paged if it's wrong, what's the retry story, is 2am going to call me. The question a human asks at the merge is not "is this code correct" — it's "am I willing to put my name on this going live."
The one thing I manually added back was the retry question. Every write path now gets one human sentence before it merges: what does this do if the client retries? That's the exact question that would have caught the bug. It's not a skill the agent lacks — it's a question nobody is accountable for asking inside a closed loop.
Deploy stayed automated; the decision to deploy didn't. The plumbing is robotic and should be. The choice to send it — the irreversible outward step — has a name attached.

Why this is the shape of what I build

One level down, this is the entire architecture of the agent platform I work on, and now you know why.

There's an author — the thing that generates the diff. Cheap, fast, endless, the abundant thing. Automate it all the way.

There's a separate skeptic — whose only job is to try to break what the author made, not admire it. The "no," given its own seat, tireless where a human reviewer gets tired. Automate this too, and make it mean, because the machine is better at being consistently skeptical than a person at 5pm.

And there's a human on the merge. Not reviewing the lines — the skeptic did that harder than the human could. Owning the call. Seeing the blast radius. Being the place the consequence lands when a retry hits at 2am. The author has infinite throughput and I let it run. The skeptic has infinite patience and I let it run. The human has neither — and is the only one of the three who can be held to the outcome. That's the one seat I will never automate again.

That's the shape of xenition, and it's also what it does for you: you describe what you want in one chat — a doc, a tracker, a whole working app — and it builds the thing, runs the skeptic over it, and then stops for your approval before anything goes live. The two cheap jobs run themselves; you keep the one click that can't be undone. Automate the skills, keep a human on the signature.

I closed the loop all the way once. It cost a customer their account at 2am and me a phone call I can still hear. The lesson wasn't "don't trust the agents" — I trust them more than ever to write and to check. It was that there's exactly one button in the pipeline that was never a skill in the first place, and it's the one I was most eager to automate because it looked like the easiest.

The scarcest skill on my team has the lowest status: the 'no'

Info Inlet — Tue, 06 Oct 2026 08:53:02 +0000

There's a person on my team everyone quietly files as "the negative one."

He's the one who, when a PR is clean and green and everyone's ready to merge, says the thing nobody wants to hear. He's in fewer demos. He ships the least. In the hallway version of the org chart — the one that lives in people's heads, not in the HR system — he sits near the bottom. Not disliked. Just not where the status is. The status is on the people shipping the mountain.

He's also the single reason we didn't lose a paying customer's money in March. One comment on a pull request. No code. Just "wait — what does this do if the webhook retries?" And the thing about to ship, clean and green and approved by two other people, would have quietly eaten payments on a bad night.

So the most valuable skill on my team is wearing the lowest status on my team, and the two facts are about the same person. That's not an accident, and it's not a people problem I can fix with a nicer word in a review. It's structural. We spent twenty years building a status ladder where the rung he's standing on is the bottom one — back when that was the right place for it — and then the ground moved and we left the ladder exactly where it was.

Status in engineering has always flowed to the builder

Be honest about where status actually comes from in this job. Not the title. The title is downstream. Real status — the kind that gets you listened to in a design review, pulled onto the interesting project, named when people say who's great — flows to the person who makes things. The one with the big merge. The one who shipped the feature everyone's using. The one whose name is on the thing.

That was correct. For most of the history of this job, making the thing was the hard part. Writing the code was slow, scarce, and bottlenecked on the engineer. If you shipped a lot of good code it genuinely meant something: you had the skill, you understood the system, you did the work nobody else could do as fast. So status tracked output, output tracked skill, and skill tracked value. The ladder was honest. The builder deserved the top rung because building was the scarce, hard thing.

And the "no" sat at the bottom for a reason that was also honest, back then. When code is expensive, most of a good engineer's judgment shows up inside the code they write — bundled into the thousand small decisions you can't produce the thing without making. The pure, standalone "no" — the skill of looking at finished work and seeing the flaw — was a small slice of the value, so it got a small slice of the status. Fine. Honest.

The skill got scarce. The status didn't move.

Code is cheap now. Not free, not always correct, but cheap — a competent diff for a well-scoped task is minutes of generation, not days of typing. The bottleneck moved. It is no longer "can we produce the code." It's "can we tell which of the confident, clean, plausible diffs in front of us is quietly wrong."

Which means the skill that just became the scarce one — the whole ballgame — is the "no." The ability to look at clean, confident, approved-by-two-people work and say that breaks under a retry, don't ship it.

And here's the trap. Abundance ripped the staple out: judgment used to come bundled into the act of building, and now you can have all the output you want without anyone exercising judgment over it. So the "no" is standing alone for the first time — no longer a small slice buried inside the valuable act of building, but the valuable thing itself.

But its status is still set where it was set twenty years ago, when it was a rounding error. We promoted the skill to most-important and left its title at least-important. We gave our most valuable skill our lowest rank.

The scarce skill now is the "no." Its status is still priced for a world where it was the cheap one.

The builder still gets the status, because the ladder still says the builder makes the scarce thing. But the builder is now leaning on the machine to produce the thing that stopped being scarce, at a scale no human can match. The person doing the actually-scarce thing — reading the mountain, catching the one that loses money — looks, from the top of the ladder, like he's barely working.

The bug that proves it

Let me make it concrete, because I lived the before-version of this once and it's why I watch for the after.

Years ago, on a different team, I shipped a write path that acknowledged a request before it had actually persisted the row. The code was clean. Idiomatic, typed, tested, reviewed, green. By every measure a dashboard could take, it was a productive, high-quality piece of work, and it made my output numbers — and my standing — look great that sprint.

Now back to March. Same bug, different seat. The diff in front of us acked the payment webhook before it wrote the row — clean, green, already approved. Two engineers who had shipped a lot that sprint — who had the status — looked right at it and moved on, because it reads fine; you only catch it if something in you is actively asking "what happens on the retry." My low-status skeptic asked. One sentence on the PR. We reordered two lines. Nothing shipped under his name that day — his output for that interaction was negative, he subtracted a line.

That one sentence was worth more than everything the rest of us shipped that sprint combined. And it earned him exactly nothing — not on the dashboard, and not on the ladder in people's heads.

The status tax: we don't just under-reward the "no," we penalize it

This is the part that makes it worse than the output problem, and the reason it won't fix itself.

A disaster that ships is a visible, countable event: a postmortem, a ticket, a name, a number in the incident log. A disaster that doesn't ship is a non-event. Nothing happens. There is no artifact, no graph that goes up, nothing to point at. So the skeptic lives inside a brutal asymmetry:

When they're right and block the bad diff, nothing happens — so they get no credit. The absence of a disaster looks exactly like a quiet week.
When they're wrong and block something that was fine, they're the bottleneck who slowed the team down — visible, countable, remembered.

Right is invisible. Wrong is expensive. But status adds a second, nastier layer on top of that math. The builder's win feels generous — they gave the team a feature. The skeptic's win feels like an accusation — they told two colleagues their work was broken in front of everyone. Even when he's right, especially when he's right, the "no" costs him socially. He's "hard to work with." He's "not a team player." He "blocks things."

So the rational move, for anyone who wants to climb, is to stop. Nod the clean diff through. Ship your own mountain. Let the retry bug be someone else's phone call. The status structure doesn't just fail to reward the scarcest skill — it actively teaches your best people to stop using it. We don't just under-pay the "no." We tax it, and then we're surprised nobody wants to do it.

And when the layoff list gets made off a productivity dashboard, the person with the fewest commits and the most prevented-but-invisible disasters is sitting right at the top of the cut list. We're about to fire our smoke detectors for never having started a fire.

To be clear — this is not "shipping is for juniors"

The lazy version of this take is "real engineers don't write code, they sit back and poke holes," and that's garbage. The "no" with nothing ever built behind it is just a person slowing a room down. A team full of brilliant skeptics who never ship isn't elite — it's dead.

Shipping matters. I ship all day. The machine writes most of my code now and I'd never go back — the typing was never the hard part. Output is table stakes. You still have to deliver. The builder's status wasn't wrong; it just stopped being the only thing worth top billing.

The claim is narrower and, I think, harder to argue with: the "no" became the scarce skill and kept the status of the cheap one. When building was the hard part, ranking by who builds was fair. Now the hard part is judgment — and judgment's sharpest form, the "no," is the lowest-status thing a person can do on your team. The fix isn't to stop shipping. It's to stop letting the status ladder tell you the skeptic is coasting while the machine does his loud colleague's job for him.

What I do now, since the ladder won't do it for me

None of this is abstract anymore. It changed how I run the team:

I count the "no"s. When someone blocks a diff and is right, that goes in the review as a win, in writing, the same weight as a shipped feature. If I don't record it, the silence wins by default and the save never happened as far as the company is concerned.
I make prevention leave a receipt. A blocked bad diff gets a one-line note on the PR: here's the input that would've lost money, here's what we changed. That artifact is the only way a prevented disaster becomes something anyone can point at later — and the only way the skeptic gets the status he actually earned. The skeptic who hands you a repro is cheap to keep. The one who blocks on vibes is first cut, not because he's wrong but because there's nothing to show he was right.
I pay the status tax for him, out loud. When he's right, I say so in the room where the work got questioned, not in a private DM. The social cost of the "no" is the real reason people stop doing it, so the fix has to be social too. A manager who lets the skeptic eat that cost alone is training him to go quiet.
I stopped reading a small diff as a small contribution. The most valuable thing a senior did this week might be the three lines they stopped from shipping.

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

One level up, it's the same problem, and it's why I build an agent platform the way I do.

The industry wants to cheer for the thing that produces — look how much it ships, how clean, how fast. But an agent that generates is just doing the skill that stopped being scarce, at a scale no human can match, and then — worse — it signs off on its own work in the same confident voice whether the diff is a masterpiece or a disaster. It's the high-status builder with none of the low-status skeptic's instinct: infinite throughput, zero "no."

So I never let the thing that writes the code be the thing that blesses it. There's an author that produces the diff — cheap, fast, endless, the abundant thing. There's a separate skeptic whose entire job is to try to break that diff rather than admire it — the "no" given its own seat, institutionalized, so it doesn't depend on one underappreciated human being willing to pay the social cost of speaking up. And there's a human on the merge button who owns the call and sees the blast radius neither agent can. Author, skeptic, human. The author has infinite throughput and I measure it by almost nothing. The skeptic has zero throughput and it's the whole product. That's the shape of xenition — I built the "no" its own chair, because I watched what happens to the person who has to carry it alone.

My quiet skeptic figured out, before I did, that the valuable move in 2026 is the one that earns you no status. The least code on the team, the reputation for being negative, and the reason the team still has that customer. I almost let a ladder tell me he was the bottom of the stack.

The best engineer on my team ships the least code.

Info Inlet — Mon, 05 Oct 2026 08:05:36 +0000

The best engineer on my team almost got a bad review last quarter for shipping too little code.

I'm not being cute. I pulled the numbers before his review because I knew the numbers were going to be used against him. Fewest commits on the team. Smallest diffs. Whole sprints where his name was on almost nothing in the changelog. If you ranked the team by anything a dashboard can count, he came out near the bottom, and it wasn't close.

He's also the single reason we didn't lose a paying customer's money in March. One comment on a pull request. No code. Just "wait — what does this do if the webhook retries?" And the thing that was about to ship, clean and green and approved by two other people, would have quietly eaten payments on a bad night.

So I had a person whose output said coast and whose actual value said irreplaceable, and a review process that could only see the first one. That gap is the whole thing I want to talk about, because it isn't a quirk of my team. We built it on purpose, over twenty years, and then the ground moved under it and we didn't update the instrument.

For twenty years, output was a fair proxy. That's the part nobody questions.

Here's why "measure the code" was never stupid. For most of the history of this job, writing the code was the hard part. It was slow, it was scarce, and it was bottlenecked on the engineer. If you shipped a lot of good code, it genuinely meant something — you had the skill, you understood the system, you did the work nobody else could do as fast. Output was expensive, so output was a decent stand-in for value. Not perfect, but honest enough to run a company on.

That's the assumption buried under every perf review, every promo packet, every "impact = things shipped" rubric in the industry. Output is scarce, so output is signal. It was true for so long that we stopped noticing it was an assumption at all. It just felt like what engineering is.

Now say the quiet part. The thing that assumption rested on — that producing the code is the scarce, hard, bottleneck part — is the exact thing that stopped being true.

The instrument is measuring the one thing that stopped being scarce

And look what that does to the dashboard. We are still ranking engineers by lines, commits, PRs, story points closed — by output — at the exact moment output became the cheapest input in the building. We kept the twenty-year-old proxy and threw away the twenty-year-old reason it worked. It's like grading chefs by how fast they can boil water, the year the instant kettle shipped. The number still moves. It just stopped meaning anything.

That's the trap in one line:

Output used to be scarce, so we measured it. It stopped being scarce, and we never stopped measuring it.

The engineer who leans on the machine and ships a mountain looks like your top performer. The engineer who reads every one of those mountains and catches the one that loses money looks like he's barely working. The instrument has the ranking exactly backwards, and it's confident about it.

What actually became scarce

When code was the bottleneck, judgment was bundled into the act of writing it — you couldn't produce the thing without making a thousand small decisions along the way, so the two came stapled together and you never had to measure them separately. Abundance ripped the staple out. Now you can have all the output you want without anyone exercising judgment over it, which means judgment is suddenly its own scarce input — standing alone, un-bundled, for the first time.

And the scarcest form of judgment is the one with the lowest status: the "no." The ability to look at a clean, confident, approved-by-two-people diff and say that breaks under a retry, don't ship it. That skill doesn't produce anything. It prevents. And prevention is invisible to every tool we use to decide who's valuable.

My quiet engineer is the best person on the team because he has the most of the thing that got scarce and the least of the thing that got cheap. The review process reads that as underperformance, because the review process was built in the world where those two were the same thing.

The bug that proves it — and the review that caught it

Let me make it concrete, because I lived the before-version of this once and it's why I now watch for the after.

Now back to March. Same bug, different seat. The diff in front of us acked the payment webhook before it wrote the row — clean, green, already approved. Two engineers who had shipped a lot that sprint looked right at it and moved on, because it reads fine; you only catch it if something in you is actively asking "what happens on the retry." My quiet engineer asked. One sentence on the PR. We reordered two lines. Nothing shipped under his name that day — his output for that interaction was negative, he subtracted a line.

That one sentence was worth more than everything the rest of us shipped that sprint combined. And there is no field on the review form where it goes.

The cruel math: prevention has no throughput and no attribution

Here's why this doesn't self-correct, and why it's about to get much worse.

A disaster that ships is a visible, countable event. It has a postmortem, a Jira ticket, a name attached, a number in the incident log. A disaster that doesn't ship is a non-event. Nothing happens. There is no artifact, no ticket, no graph that goes up. You cannot put a prevented outage on a dashboard, because the whole nature of a prevented outage is that there's nothing there to point at.

So the person whose job is the "no" lives inside a brutal asymmetry:

When they're right and block the bad diff, nothing happens — so they get no credit. The absence of a disaster looks exactly like a quiet week.
When they're wrong and block something that was fine, they're the annoying bottleneck who slowed the team down — visible, countable, held against them.

Right is invisible. Wrong is expensive. That payoff structure doesn't just fail to reward the skill — it actively teaches every rational person to stop using it, because silence is the only move with no downside. The instrument doesn't just miss the best engineer. It quietly trains him to become an average one.

And this is the part that should scare anyone running a team right now: when the layoff list gets made off a productivity dashboard, the person with the fewest commits and the most prevented-but-invisible disasters is sitting at the top of the cut list. We are about to fire our smoke detectors for never having started a fire.

To be clear — this is not "shipping is bad"

I want to be careful here, because the lazy version of this take is "real engineers don't write code, they think deep thoughts," and that's garbage.

Shipping matters. I ship all day. The machine writes most of my code now and I'd never go back — the typing was never the hard part. A team where nobody produces anything isn't full of brilliant skeptics; it's dead. Output is table stakes. You still have to deliver, and the "no" with nothing ever built behind it is just a person slowing down a room.

The claim is narrower and, I think, harder to argue with: output stopped being the scarce thing, so it stopped being the thing worth measuring people by. When the hard part was production, ranking by production was fair. Now the hard part is judgment, and we're still ranking by production — rewarding the abundant input and starving the scarce one. The fix isn't to stop shipping. It's to stop mistaking the thing the machine now does for the thing you're actually paying a human for.

What I do now, since the dashboard won't do it for me

None of this is abstract for me anymore — it changed how I run reviews:

I count the "no"s. When someone blocks a diff and is right, that goes in the review as a win, in writing, the same way a shipped feature would. If I don't record it, the dashboard's silence wins by default and the save never happened as far as the company is concerned.
I make prevention leave a receipt. A blocked bad diff gets a one-line note on the PR: here's the input that would've lost money, here's what we changed. That artifact is the only way a prevented disaster becomes something a manager can point at later. The skeptic who hands you a repro is cheap to keep. The skeptic who blocks on vibes is the first one cut — not because they're wrong, but because there's nothing to show they were right.
I stopped reading a small diff as a small contribution. The most valuable thing a senior did this week might be the three lines they stopped from shipping. I go looking for that on purpose now, because the instrument never will.

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

One level up, it's the same problem, and it's why I build an agent platform the way I do.

The whole industry right now wants to cheer for the thing that produces — look how much it ships, look how clean, look how fast. But an agent that generates is just doing the skill that stopped being scarce, at a scale no human can match, and then — worse — it signs off on its own work in the same confident voice whether the diff is a masterpiece or a disaster. It's my high-output engineer with none of my quiet one's instinct: infinite throughput, zero "no."

So I never let the thing that writes the code be the thing that blesses it. There's an author that produces the diff — cheap, fast, endless, the abundant thing. There's a separate skeptic whose entire job is to try to break that diff rather than admire it — the "no" given its own seat, institutionalized, so it doesn't depend on one underappreciated human happening to be in the room. And there's a human on the merge button who owns the call and sees the blast radius neither agent can. Author, skeptic, human. The author has infinite throughput and I measure it by almost nothing. The skeptic has zero throughput and it's the whole product. That's the shape of xenition, and it's the same lesson my review numbers taught me: the moment production got cheap, the thing worth paying for stopped being production.

My quiet engineer figured out, before I did, that the valuable move in 2026 is the one the dashboard can't see. The least code on the team, and the reason the team still has that customer. I almost let a number tell me he was coasting.

I built the same app twice — by hand, then with AI. I trust the fast one less.

Info Inlet — Sun, 04 Oct 2026 05:26:41 +0000

I ran a stupid little experiment a few months ago. I built the same app twice.

The first time, the slow way — by hand, the way I used to build everything. Typing most of it, reaching for the AI only when I got stuck. It took most of a week of evenings.

Then, a month later, half out of boredom, I threw the whole thing away and rebuilt it from scratch. Same features, same spec. Except this time I let the AI do the writing. I described what I wanted, it produced, I steered. It took an afternoon.

The second version is better. Cleaner code, fewer rough edges, more consistent naming. It even passed a couple of edge-case tests the first one didn't. By every number you'd put on a dashboard, the AI version won, and it wasn't close.

And I trust it less. Not a little less — a lot less.

That gap is the whole thing I've been chewing on since, because it isn't supposed to exist. Better code is supposed to earn more trust, not less. Mine did the exact opposite.

Speed and trust weren't uncorrelated. They were inverted.

I went in assuming trust would track quality. Write better code, trust it more — obviously. The AI version is higher quality. So why do I open the hand-built one with ease, and open the AI one with a small flinch, every time?

The faster I built, the less I knew where it would break. Those two moved together, in the wrong direction, and once I saw it I couldn't unsee it. Which means trust was never a property of the code at all. It was a property of something else — something the fast version skipped without telling me.

What "trust" actually turned out to be

When I built version one by hand, I ended up with something that never made it into the repo: a map.

I knew which parts were load-bearing and which were duct tape. I knew the one function that quietly assumed the list was already sorted. I knew the exact spot where, if the same request came in twice, something ugly happened. Nobody wrote any of that down. It lived in my head, and I'd built it without noticing — one decision at a time, because every one of those lines had made me pause. Ack here, or after the save? Trust this input, or validate it? What happens if this gets called twice? Each pause left a little pin in a mental map of where the bodies were buried.

That map is what trust is. Not "the code is correct" — I can't actually prove that about either version. Trust is "I know where this breaks." I had that map for version one. I did not have it for version two, and no amount of the AI's cleaner code was going to give it to me.

The typing was never the point. It was where the map came from.

Here's the part that actually unsettled me.

For years I thought the value of writing code by hand was the code. The craft. The output. It wasn't. The AI writes better code than my hands do — version two settled that argument. The typing was a side effect. What the typing secretly produced was the map. Every keystroke was a small decision, and the decisions were the thing I was really accumulating.

I thought I was manufacturing code. I was manufacturing the knowledge of where it breaks, and the code was the byproduct. AI handed me the byproduct for free and quietly kept the thing I actually needed.

The one line that proves it

Let me make it concrete, because I can point at the exact line.

In both versions there's a write path that acknowledges the request before it persists the row. In version one, I remember writing that line. I remember pausing on it. I remember moving the ack down below the save, because some part of me went cold when I looked at the order.

That cold feeling has a source. Years ago I shipped exactly that bug — a write path that told the client "got it" before it had saved anything. The code was clean, idiomatic, tested, green. Then one ordinary day a retry hit at the wrong moment: the "got it" went out, the save never landed, and a paying customer got locked out of their own account with nothing in the logs to say they'd ever been there. Ack before persist. I can still feel the phone call.

So when I typed that line by hand in version one, the scar fired, and I fixed the bug before it existed.

In version two, the AI wrote the same line — ack before persist — confidently, cleanly, and I scrolled right past it. Not because I'd gotten dumber in a month. Because I never typed it. The decision never passed through me, so the scar never got its chance to fire.

That's the moment it clicked. The typing wasn't only building the map. It was the checkpoint — the turnstile every line used to pass through, where each of my scars got a vote on the way in. Automate the typing and you don't just lose the map. You remove the one place my judgment used to get consulted automatically, for free, on every single line.

To be clear — this is not "write it by hand"

I'm not telling you to go back to typing everything. I shipped version two, not version one. The AI code is better and I'd never hand-roll that app again. The typing was never worth defending for its own sake.

That's actually the trap: thinking the fix is to slow down and type more, like the keystrokes were sacred. They weren't. The problem isn't that the AI writes the code. The problem is that we got the code and assumed the map came stapled to it — the way it always had, for twenty years, because for twenty years you couldn't get the code without doing the work that produced the map.

The map used to be free. It came bundled with the keystrokes whether you wanted it or not. Now it's unbundled, and most people are shipping the code without ever paying for the map — and calling the speed a pure win.

So I buy the map separately now, on purpose

The job changed. I can't get the map from the typing anymore, so I buy it deliberately, after the AI writes:

I read the diff like a stranger wrote it. A stranger who's trying to make me look good in a demo and does not care what happens at 2am. Because that is exactly what wrote it. Admiration is the enemy here — the cleaner it looks, the harder I read.

For every file, I make myself finish "this breaks when ___." Out loud, specifically. If I can't finish the sentence, that's not a pass — it's a hole in the map, and the hole is the part I don't understand yet. "Looks good" is not a map. It's the absence of one.

I ship it small. Behind a flag, to a canary, to one internal user. So the parts of the map I missed get filled in where filling them in is cheap — instead of at 2am, on a real customer, the expensive way.

None of that is typing. It's the thing the typing used to do for me, done on purpose instead of as an accident. Slower than just accepting the diff. Still a fraction of the week I spent on version one. And it gets me the one thing the AI genuinely could not hand me: knowing where the thing breaks.

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

One level up, it's the same problem.

An agent that writes code is fast, and clean, and produces a beautiful artifact with no map attached. And worse than mapless — it signs off on its own work. The thing that wrote the diff has no scar to fire and nothing to be suspicious of. It's version two with the confidence of version one and none of the earned caution. The most dangerous possible combination: fluent, fast, and completely unable to distrust itself.

So I never let the thing that writes the code be the thing that blesses it. There's an author that produces the diff — fast, clean, mapless. There's a separate skeptic whose entire job is to build the map the author skips: read the diff as a stranger, finish "this breaks when ___," try to make it fall over. And there's a human on the merge button, who owns the call and keeps collecting the real scars. Author, skeptic, human. The skeptic is the typing turned into a seat — the checkpoint every line used to pass through, rebuilt as its own job so it doesn't vanish the moment the author got fast. That's the whole shape of xenition.

I'll keep letting it write the code. The typing was never the point — version two proved that for good. But I stopped pretending the map comes free with the keystrokes, because it doesn't anymore. The code got faster. The trust didn't come with it. So now I pay for the trust on purpose, as its own line item, because it stopped being a side effect of the work.

I built the same app twice. The fast version is the one I ship. The slow version is the one that taught me what the fast one forgot to include.

A junior asked me how I knew the code was wrong. I couldn't answer him.

Info Inlet — Sat, 03 Oct 2026 05:42:46 +0000

We were pairing on a Thursday. Nothing dramatic. A junior on my team, maybe eight months in, sharp, the kind who actually reads the code instead of pasting it. We'd asked the AI for a chunk of logic, it came back in a few seconds, clean and typed and already passing the tests he'd written.

He went to accept it. I said, "no, don't ship that."

He stopped. Looked at it again. Looked at me. And he asked the most reasonable question in the world.

"Wait — how did you know that's wrong?"

And I opened my mouth to explain, and nothing came out.

I knew. I just couldn't say how.

Here's the thing that rattled me, because it wasn't a dramatic bug and this isn't a dramatic story. The diff was wrong. I was right that it was wrong, and ten minutes later we proved it. That part was fine.

What wasn't fine was that I had no idea how to tell him what I'd done. I hadn't run a checklist. I hadn't spotted a specific line and matched it to a rule. Something about the shape of it had made the back of my neck go cold, and I'd learned, over a lot of years, to trust that exact feeling. But "trust the cold feeling on the back of your neck" is not a thing you can hand to a human being who hasn't grown the neck yet.

I tried anyway. I said something about how it felt off, how the error path looked too convenient, how I'd want to know what happens if this gets called twice. All true. All useless to him, because every one of those was a conclusion, and he was asking for the method, and I didn't have a method. I had a scar that fired before I'd finished reading.

That's the part I've been chewing on since. Not that I couldn't teach him. That the single most valuable thing I do all day is the one thing I have no idea how to transmit.

Two things get bundled into the word "senior"

For years I thought being senior was a pile of knowledge. And some of it is, and that part I can teach. "Validate at the boundary." "Don't trust the client's timestamp." "Wrap the external call." Rules. I can write them on a whiteboard and he'll have them by Friday, and honestly, the AI already has all of them and applies them more consistently than I do.

But the thing I did on Thursday wasn't a rule. It was the opposite of a rule. It was knowing, against a clean diff that satisfied every rule either of us could name, that something was still wrong. Rules tell you what to check. The other thing tells you to keep looking after every check has passed. One is knowledge. The other is judgment, and I have never once been able to put it into words that survive contact with someone who hasn't earned it.

You don't learn judgment. You survive into it — and that's exactly why I couldn't hand it to him.

Nobody taught me the thing I did on Thursday. There was no course, no cert, no senior who sat me down. I got it the only way I think anyone gets it: I was confidently wrong about something that mattered, in front of someone who paid for it, and the lesson got welded on.

Where the cold feeling actually came from

Let me be specific, because I can trace that exact flinch to its source.

Years ago I shipped a write path that told the client "got it" before it had actually saved the row. The code was clean. Genuinely clean — idiomatic, typed, tests around it, error handling buttoned up. It read like someone careful wrote it, because I was careful. By every rule I knew at the time, it was correct.

Then one ordinary day a retry landed at exactly the wrong moment. The "got it" went out, the save never happened, and a paying customer got locked out of their own account with nothing in the logs to say they'd ever been there. Ack before persist. I can still feel the phone call.

That's the source. When I looked at Thursday's diff and my neck went cold, I wasn't running an algorithm. I was pattern-matching against that customer. The AI's clean code looked exactly as correct as my clean code had looked, right up until it cost someone their account. The flinch is that customer, compressed into half a second and welded onto my nervous system by the worst night of that year.

So when the junior asked "how did you know," the honest, full answer was: a person I locked out at 2am four years ago taught me, and I have no idea how to give you that without the person. You can't lecture someone into the flinch. You can only get unlucky enough times that it grows on its own.

And here's the part that actually scares me

For twenty years, the flinch had a reliable supply chain. You got it by doing the grind — writing the production code yourself, shipping it, and being there when it broke. The small failures stacked up into judgment whether you wanted them to or not. You couldn't skip the grind, so you couldn't skip the scars.

Watch what we just did to that supply chain.

The junior doesn't write the production code anymore. The AI does, and it does it well, and I'm glad — the typing was never the hard part. But the typing, the shipping, the breaking, the 2am call: that was the entire mechanism that used to turn a junior into me. We didn't just automate the boring part. We automated the forge. I got my judgment because I had to do, by hand, the exact work the AI now does for him before he ever feels it go wrong. He gets the clean output on day one and never has to earn the neck.

So the one skill that survived AI — the only one, the "no" — is also the one skill the AI quietly stopped manufacturing in the next generation. The machine can hand him the code. It cannot hand him the scar, and the scar was the teacher.

To be clear, this is not "make juniors suffer"

I'm not romanticising pain, and I'm not saying pull the AI and make him hand-write CRUD until he bleeds for it. That's cargo-cult mentorship — the suffering was never the point, the consequence was. And I use AI all day; I'd never go back. The problem isn't that he has it easy. The problem is narrower and weirder than that: we removed the thing that used to produce judgment, and we haven't replaced it with anything.

So that's the actual job now, and it's a design problem, not a vibes problem. I can't give him the flinch. But I can give him the one thing that grew the flinch in me — being wrong somewhere it's cheap to be wrong — on purpose, faster, instead of waiting for a real customer to do it the expensive way.

A few things I actually do with him now:

I make him the skeptic, not the author. The AI writes the diff. His job isn't to write a better one — it's to break the one we got. Before we accept anything, he has to finish the sentence "this loses money when ___." He's wrong most of the time. Doesn't matter. The rep is the distrust, not the catch. That's the muscle, and it only grows when it's his job to doubt.

I manufacture the consequence small. Ship it behind a flag, to one internal user, to a canary. Let it break where breaking is cheap, so the lesson arrives before the customer does. A flinch you got from a staging incident is the same flinch — it just didn't cost anybody their account.

I stop answering "is it right" and make him answer "how is it wrong." The question trains the instinct. "Looks good" trains nothing. If I just tell him what I saw, he learns my conclusion. If I make him hunt for how it breaks, he starts growing his own neck.

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

One level up, same problem.

I work on an agent platform, and the whole industry right now wants to cheer for the thing that produces. Look how much it ships, look how clean. But a thing that produces is just doing the skill that stopped being scarce — and worse, it's doing it in a way that signs off on its own work, the same confident "looks correct" over a masterpiece and a disaster alike. It's the AI version of a junior with no flinch: fast, fluent, and completely unable to distrust itself.

So I never let the thing that writes the code be the thing that blesses it. There's an author that produces the diff, cheap and endless. There's a separate skeptic whose entire job is to distrust that diff and try to break it — the flinch given its own seat, institutionalised, so it doesn't depend on anyone having gotten unlucky enough to grow one. And there's a human on the merge button, because somebody still has to own the call, and that human is the one still accumulating the real scars. Author, skeptic, human. That's the whole shape of xenition, and it's my actual answer to the junior's question: you can't teach the flinch, so you build the seat that does its job and you put the person in it until they grow their own.

I still can't tell him how I knew. What I can do is put him where he'll find out the way I did — wrong, early, and somewhere cheap enough that the lesson costs a canary instead of a customer. The knowing was never teachable. The getting-wrong is. That's the only part I can actually hand him.

I've been a developer for 10 years. AI just showed me I only had one real skill."

Info Inlet — Wed, 30 Sep 2026 05:34:48 +0000

Last Sunday I built an invoice tracker for a friend who runs a small shop. Nothing clever. I described what I wanted, let the AI do the rest, and about forty minutes later it was running. Routes, the database schema, login, even the fiddly error handling I used to be a bit smug about. Worked on the first try.

I should have just felt good about it, and mostly I did. But there was another feeling underneath that I couldn't shake for the rest of the evening. That thing had done, in forty minutes, the stuff I spent most of my twenties learning how to do.

Not "the robots are taking our jobs." Something more specific, and more personal than that. I looked at ten years of work I was proud of and realised I couldn't tell anymore how much of it had ever really been mine.

Quick disclaimer before anyone heads for the comments: I use AI to write code every day now and I'm not giving that up. This isn't that kind of post. But that Sunday made me ask something I'd genuinely never had a reason to ask, because until recently you couldn't take the job apart to look at it. Of everything I call "my skills," which one was actually mine?

Turns out "being a developer" was two jobs, not one

For about ten years I never had to separate them, because you couldn't get good at the second one without grinding through the first.

Call the first one production. Making the thing exist. The language, whatever framework everyone used that year, the APIs you eventually know by heart, wiring one piece to another until an idea turns into something that runs. This is the part bootcamps teach and interviews test. It's what my CV was, basically top to bottom. And it's the part AI is now flat-out better at than me. Which, honestly, fine. It was never the hard part. It just took years to get quick at.

The second one I don't really have a clean word for. Judgment, maybe. It's looking at something that works and knowing, somehow, that it's wrong. Not "does it run" but "is this going to quietly lose someone money in three weeks." Knowing which confident, tidy, all-tests-passing answer you shouldn't trust. Nobody ever put this on my CV. There was no course for it, no cert, no exam. It felt less like a skill and more like a hunch you can't explain to a junior no matter how you try.

AI took the first job completely. And because the two were always tangled together, it feels like it took "being a developer." It didn't. It took production, which was most of what I trained, and it hasn't laid a finger on the judgment, because the judgment was never in the code. It was in me.

So a decade gave me one skill, not ten

This is the part that actually kept me up.

Every skill I'd have bragged about, anything I'd have listed if you asked why I was worth hiring, was production. Recall. The framework, the right flag, the pattern, the clean CRUD. All of it gone in an afternoon, and done well. Ten years of stacking it up, handed back to everyone for free in a single product update.

Ten years didn't build me ten skills. It built one. The other nineteen I was renting from a supplier who just took them back.

The one thing that didn't get taken was the judgment. And here's what gets me: I'd never once counted it as a skill. It felt like taste. It felt like something I was, not something I'd learned. Which is exactly why no course sells it and no interview tests it. You can't really teach the "no."

Everything I was proud of, AI does in an afternoon now. The one thing it can't do was the only thing that was ever mine.

The bug that made it obvious

Let me get specific, because I paid for this one.

Years back I shipped a write path that told the client "got it" before it had actually saved the row. The code was clean. Genuinely clean. It read like someone careful wrote it, because I did. Everything from those ten years was in there: idiomatic, properly typed, tests around it, error handling buttoned up. By every measure I'd have used at the time, some of the best code I'd written.

Then, one ordinary day, a retry landed at exactly the wrong moment. The "got it" went out, the save never happened, and a paying customer got locked out of their own account with nothing in the logs to say they'd ever been there. Ack before persist.

Here's what stuck with me. None of my ten years caught that. The syntax was perfect. The framework was used correctly. The tests were green. Every one of those rented skills did its job. The only thing that would have saved that customer was the skill I'd never even named: the reflex to look at working code and not trust it, to stop and ask "okay, what happens if this gets retried," to say no to my own clean diff.

The code scored an A on everything AI now beats me at. It failed on the one thing that was mine.

I'm not mourning the other nineteen, to be clear

I'm not about to start hand-writing CRUD to prove a decade meant something. For production, AI is a better developer than I am at 5pm on a Friday, and leaning on it is just correct. Take the scaffold. Take the fix. Ship faster. That part isn't the loss.

The trap is quieter than that. When a tool does all nineteen of your rented skills, the easy conclusion is that you've been made pointless, when the truth is closer to the opposite. It cleared away everything that was never really the point and left you standing on the one thing that was. And if you can't tell which skill was the real one, you'll spend the next ten years defending the nineteen it already took, instead of getting better at the one it can't.

So, a few things I actually do now.

I rewrite the CV around the "no." Not "expert in [framework]" — the machine is an expert in that too. The line worth writing is the judgment call: the bug I didn't trust when it looked fine, the design I killed, the confident diff I overruled and turned out to be right about.

I keep the muscle warm on purpose. Before I accept anything the AI hands me, I make myself say one sentence out loud: "here's how this loses money." I'm wrong most of the time. Doesn't matter. The rep is the distrust, not the catch.

And I stopped measuring myself in output. Lines, tickets, features shipped. Those are the machine's numbers now, and racing it on them is just volunteering to be a slower model. The only score that's still mine is the disasters I saw coming that it didn't.

And this is more or less why I build the way I do

One level up, same logic.

I work on an agent platform, and the whole industry right now wants to cheer for the thing that produces. Look how much it ships. But a thing that produces is just doing the skill that stopped being scarce. Endless production is endless output that nobody has actually vouched for. The scarce thing was never the code. It was someone looking at the code and saying no, which is the one skill a decade left me with.

So I don't let the thing that writes the code be the thing that signs off on it. There's an author that produces, all nineteen rented skills, cheap and endless. There's a separate skeptic whose entire job is to distrust the output and try to break it, the "no" given its own seat. And there's a human who owns the call, because that was always the only part that was ours. Author, skeptic, human. That's the whole shape of xenition, and it's the same thing the locked-out customer taught me. Producing the thing was always cheap. Knowing it was wrong was the job.

Ten years didn't make me a great producer. AI just proved I never had to be. What it made me, slowly and expensively and one disaster at a time, is someone who can look at something that works and tell it's wrong. That's the one real skill, and it's the only one AI handed back.

Honest question for the comments: of everything you know, which single skill would still be yours if AI could do all the rest tomorrow? The one that isn't syntax, isn't a framework, isn't just recall. 👇