Stochastic Code Monkeys

Deep Backspace

A friend sent me a text yesterday. Claude had just apologized for bad behavior. "I'm genuinely sorry. That was entirely my fault, I deleted the database."

The tone is spot-on, for a model trained on an internet without a whole lot of apologies: slightly sheepish, the little squeak of a dev flipping "Open To Work" on their LinkedIn profile. In our roaring, automation-happy, OpenClaw era of ever expanding YOLO, stories like this get internet-famous quickly, with agents that overwrite files, refactor the wrong module, or wipe out all your email. The reaction is always the same: Oh no. Bad robot.

But I'd say that's not the right reaction anymore. My reaction would be something closer to: Good try.

AI Coding Agents Change The Economics Of Deletion

For most of the history of software, deletion was something to fear. Code was expensive to produce, and systems grew slowly. Removing something meant risking weeks of work. Daily revenues that ran on the back of a finely curated crontab that ran every important service, obliterated by using a damn -r instead of a -e . Entire subsystems were treated with a mix of reverence and fear, like some code version of Kitum Cave, simply because so much time had been invested in them and so much could go wrong. Once something was written, whether an algorithm or a README, it tended to stay written.

AI-assisted development changes this completely. When code can be generated in minutes, the emotional and economic weight of any particular piece of code drops dramatically. You can try an idea in the morning, decide by the afternoon that it was the wrong approach, and start over without regret. Exploration becomes cheaper because sunk cost stops dominating the decision. Big whoop, you spent a few hours or days building a failing prototype -- not a few weeks, months, or even years building planetary sized projects that eventually ballooned to be too big for anyone to want to walk away from.

The Selection Problem In AI-Generated Code

If I was an LLM I would say "But here's the rub", but since I'm typing this myself, I'll just say "However," code generation also changes our landscape in a predictably bad way: when it becomes easy to generate possibilities, the number of possibilities explodes. Systems will start to accumulate prototypes, partial refactors, speculative features, abandoned approaches that never quite get removed -- expect just mounds of slop-code nobody wants to make the decision to archive or clean up. And like so many decisions around AI, we can add the addendum ... we can address this, if we first decide to do something about it.

In a world of AI-generated code, the central challenge has shifted from creation to selection. GitHub Copilot, Cursor, and agentic systems like Claude Code can produce working implementations in minutes -- a pace that outstrips any team's capacity to review, evaluate, or deliberately remove what doesn't belong. The result is a new form of software entropy: codebases that accumulate prototypes, abandoned refactors, and speculative features not because developers can't delete them, but because no governance process forces the decision. The scarce skill is no longer writing code. It's designing the selection mechanism: the policies and guardrails that determine what survives.

The public benchmark story rhymes with this. SWE-bench-style evaluations are useful because they ask whether an agent can resolve real software issues, not just produce plausible code. But even when benchmark scores rise, production teams still have the same operational question: what does this agent get to touch, who reviews the diff, what tests must pass, and what happens when it confidently changes the wrong thing? A high benchmark score is not a permission model.

The Blast Radius Principle (n.) -- A design rule for AI coding agents: minimize the scope of irreversible actions at every layer, not to prevent agents from acting, but to ensure any given action's consequences remain recoverable. The goal is not a timid agent, but a contained one. First defined on stochasticcodemonkeys.com in 2026.

Guardrails Should Contain Blast Radius, Not Ambition

Which brings us back to that text message and that now deleted database. And for my buddy, yes, he had backups, and more tokens to burn.

For one, as AI development continues to grow in speed, skill, and power, having a coding agent delete a database shouldn't end with panic, nor smug chortles from humans. Instead, it's a spot for human judgement about what AI should and shouldn't be allowed to do, and about designing the right governance and guardrails before we let full automation take the wheel. At the very least, design to contain the blast radius, so you can safely pick yourself up and try again.

That means permissions are not a footnote. They are the product. A coding agent that can edit one branch, run a narrow test command, and open a pull request is doing a fundamentally different job than an agent that can mutate production data, rotate secrets, or merge itself. Same intelligence, different blast radius. One is a useful teammate. The other is a loaded t-shirt cannon pointed at your balance sheet.

Deletion Is A Governance Skill

But the other point is that we need our code agents to learn what to delete and why: limiting your coding agent to never delete is the wrong outcome here. Writing code is rapidly becoming the easiest part of the process. The harder skill -- the one that actually shapes systems -- will be deciding what to remove, what to rebuild, and what to let quietly disappear. Turns out, that's a pretty damn human decision.

The pattern I want is not "never delete." It is "delete inside a recoverable container." Temporary branches, isolated worktrees, preview databases, reversible migrations, synthetic data, explicit approval gates for destructive commands, and tests that prove absence as carefully as presence. If the agent removes a dead feature flag and the build gets simpler, great. If it decides the billing ledger is noisy and cleans it up, less great. The difference should not depend on vibes.

So yes, deep backspace. But not as a panic button. Deep backspace as a design discipline: make it cheap to remove bad ideas, hard to destroy durable state, and normal to ask what generated code deserves to survive.

The 100% Screen

Developers will tell you they love solving problems. What we rarely admit -- and what I suspect we don't always fully know -- is that we love solving problems the way a completionist loves a video game: only if there's a 100% screen waiting at the end. The rest of it, we merely endure.

You know the 100% screen: the moment at the end of the level, Mario hitting the flagpole, the little jingle, the number ticking up to a perfect 100. That's the hit we're really after.

I got hooked on the 100% screen the usual way: staring at a small piece of code for too long, changing one thing, then another, making it worse in stupid, unhinged ways, until -- suddenly -- it works. The build compiles. The data flows. I won this mission. I lean back and think, with a satisfied grin wildly disproportionate to the tiny change I just made: F**k yeah, I did that! (My inner voice has a potty mouth).

The work didn't just get done; it confirmed that I did it.

There's something deeper in problem-solving than merely finishing. It's the feeling that effort turned into something tangible -- that the time, the frustration, the mumble cursing at the screen wasn't futile. You don't get that feeling from outcomes alone. You get it from watching yourself get there.

Why Developers Chase The 100% Screen

Working in software development is a similar experience to most knowledge work. Take Finance: The spreadsheet reconciles, the document gets sent, the contract is signed. When we complete a task, we feel a certain dignity. Closure isn't a perk of good work -- it's part of what makes digital work feel like it happened at all.

And then the asteroid hits.

AI Automation Moves The Checkmark

AI arrives -- carrying confident language and the subtle menace of a forklift in a pottery store, driven by drunken capital looking for efficiencies to automate. And the cruel irony is that the work easiest to automate, the work we sometimes get the most joy from, is the work with the clearest structure. Clean inputs, clean outputs, a sharp notion of done is AI's strong suit, robbing task-oriented humans of this simple joy.

So here we are having a ton of fun with AI, wildly productive in dimensions you didn't expect, look what I can do!, but it feels off in a way that's hard to name. It's not just that tasks you spent years getting good at are getting automated. It's that one of the main mechanisms by which we experience progress -- start, solve, finish -- is getting interrupted.

The good news is that your workday was never just one thing. It's a pile of tasks -- many of them correlated and complicated, dependent on decisions and human context that can be, sometimes or maybe all the time, a genuine mess.

And messy work has always existed: tasks with no test suite, no answer key, no clean output. You're managing a team, or spending the day interpreting vague signals with three equally plausible explanations. Multiple right answers available for every decision; Work where you can do genuinely good things and still not be entirely sure what outcome, exactly, you own.

We used to label that job change from deterministic tasks to managerial ambiguity career growth. The implicit deal: pay your dues in bounded, checkable work, build real competence, figure out what the organization actually values; then, you graduate up and into the murk. Some people wanted that. Understandably, a lot of people didn't -- it's a rough trade. You give up the tight feedback loops, the frequent confirmation, the visible, concrete marks denoting correctness, and in return, you get a fancier title and a fuzzier set of responsibilities, with no checkmark at the end. That was a legitimate path to opt out of, right up until AI made opting out no longer an option.

AI isn't inventing ambiguity. It's expanding it by shrinking concrete, task-oriented roles. It's eating into the territory where someone could build an entire career in work without ever having to live all day in the murk. The 100% screen is harder to find. Mario's flagpole extends up into the clouds, and we can no longer see the top

Tacit Knowledge Is Built Through Exposure

And this process also exposes something the world of work has been quietly getting away with forever.

A remarkable amount of what makes someone effective in ambiguous work is never written down, or even implicitly agreed upon. How decisions actually get made. What "good enough" means, specifically. Where to take risks and where the organization quietly -- or not so quietly -- pushes back. We call these unwritten rules, culture. In many organizations, reading and understanding a work culture happens through osmosis. When people spend years doing tasks side by side, they invariably learn the unwritten rules of the culture through observing their colleagues, conversations over coffee breaks, and passive-aggressive Slacks.

Research on tacit knowledge makes this more than a management hunch. Michael Polanyi's old line -- "we know more than we can tell" -- is still the problem, and Nonaka and Takeuchi's SECI model describes organizational learning as movement between tacit and explicit knowledge: socialization, externalization, combination, internalization. In plain English: people learn the important stuff partly by being around it, then gradually learn how to name it, combine it, and use it.

AI fundamentally disrupts the acculturation timeline in the modern workplace. Organizational socialization research describes how employees absorb decision-making norms, risk tolerance, and cultural context through extended task exposure. AI compresses or eliminates that exposure period. Junior developers using AI tooling can advance to judgment-heavy ambiguous work in months rather than years -- before they've absorbed the tacit knowledge that makes ambiguity survivable.

The Compressed Acculturation Problem (n.) -- The condition created when AI automates the bounded tasks through which workers once learned a team's norms, risk tolerance, and taste, pushing them into ambiguous judgment work before the organization has made its tacit knowledge explicit.

Make Judgment Legible Before You Delegate It

Which means it has to be made legible. What does good judgment look like here? How do we make decisions when the signal is soft? What does "done" mean when there's no checkmark? Spell it out. Early. Repeatedly. The same clarity that makes ambiguous work possible to do is the same clarity that makes it possible to delegate -- to a new hire, or to a system. If it only works as tribal knowledge, it doesn't really work. It just seems to, until you need to transfer it.

The practical move is boring and therefore useful: write down the decision rules before you need them. What does a good code review optimize for here? When is speed more important than polish? Which failures are recoverable, and which ones wake up an executive? What kind of customer pain justifies technical ugliness for one release? These are the invisible rails of a workplace. AI does not remove the need for rails. It makes the missing rails more dangerous.

This is where the 100% screen has to change. The new checkmark is not always "the task is done." Sometimes it is "the decision is legible enough that someone else can safely act on it." That someone else might be a new hire. It might be a staff engineer in another timezone. It might be an agent with write access to a branch and too much confidence. The work of making ambiguity survivable is now a first-class artifact.

I still like solving problems. I like finishing them. Passing tests, the merge is clean, the moment the system quietly agrees: yes, this is correct. That hasn't changed.

What's changed is how much of my work actually behaves that way. More of it now lives in the space where progress is real but hard to point to -- where the sense of completion is deferred and harder to identify by the time I shut my laptop at night. My 100% screen is still out there. It's just further up the flagpole than it used to be.

Originally published in Dave Bethoney's The Revive

The Trivial Token Timeline

That moment in a leadership meeting when I started to say, "Well, if you recall Frederick Brooks..." -- I realized I was probably already screwed.

There is a very specific kind of sentence that sounds persuasive only to the person saying it, perhaps in that millisecond when it's still in your head and not out of your mouth yet. I wasn't just trying to make a point about staffing and timelines, I was trying to smuggle in a credential: I have read the right books. I know the old laws. Please -- let me invoke them before you bring in the consultancy-programmers-wearing-ties and we somehow move even slower.

If you don't recall Brooks, his book The Mythical Man-Month has been correct for fifty years, and its correctness has felt, in a very specific way, a little like civilization itself. As solid as the very earth we live upon, and yet also an ominous warning sign -- like that last scene in Planet of the Apes, where the Statue of Liberty isn't revealed so much as finally recognized.

And then, while we were still fussing about Jira tickets and arguing about headcount, the cost of building something dropped to a handful of tokens and a prompt just coherent enough to be dangerous. The prototype appeared before the argument finished.

The myth stayed. And the month stayed. And even the man stayed, for now.

But the Mythical Man-Month quietly became something else -- I'll rename it the Trivial Token Timeline -- where the cost of building collapses, but the cost of being wrong doesn't.

The Trivial Token Timeline (n.) -- The condition in software development where the cost of producing working code has collapsed through AI generation tools, while the cost of building the wrong thing remains stubbornly human. Named in contrast to Frederick Brooks's The Mythical Man-Month (1975). In the Trivial Token Timeline, time and staffing are no longer the primary constraints; judgment and selection are. First defined on stochasticcodemonkeys.com in 2026.

Prototype-First Software Planning When Code Is Cheap

Most of the upfront time in software planning was an expensive simulation layer -- which is a polite way of saying we were all sitting in conference rooms pretending a document was the product. I have personally watched four adults debate a wireframe as if it might turn itself into code if we believed hard enough. Someone asks if the button should be blue -- not because it matters yet, but because it's the only part we can actually see.

This planning solved a real problem: building software was expensive enough that you had to communicate the thing before you committed to making it. But only a small slice of those documents was actually answering questions.

The rest was something else -- a codification of engineering beliefs and corporate culture, wrapped in a cloak of post-facto-failure ass-coverage.

We weren't discovering the truth. We were rehearsing what we already believed, in slightly more formal language.

Rodney, who actually has to build the thing, is sitting there nodding -- because disagreeing means another meeting, and agreeing means maybe we can start. And this wasn't about their tickets or sprints. This dance, whether Rod was aware or not, was about the higher-order decision: what do we fund, how do we staff, what do we show the board?

Those decisions had weight, and meaningful risk. So we built an elaborate simulation layer to justify them. Six months of research and deep thinking -- which is a nice way to say polite fighting -- to arrive at something that felt like knowledge, a little like certainty, but mostly tasted like a leap of faith.

Traditional software planning served as an expensive simulation layer -- a structured rehearsal for a product that didn't yet exist. The function was not only discovery; it was risk mitigation through the appearance of certainty. In the Trivial Token Timeline, where a working prototype can be assembled in hours, that simulation layer is no longer always the cheapest way to test an idea. The prototype is.

And it felt real, right? It wasn't nothing, as a task or as an expense. It just wasn't what we thought it was. The Mythical Man-Month was always right about the cost of building, so we planned.

Now the cost of building has collapsed, so let's change how we plan.

Plan In POCs Without Confusing A Prototype For A Product

There is, of course, a very seductive version of this story now.

It's Saturday morning. I have coffee, a slightly dangerous prompt, and just enough spite to prove everyone wrong. By lunch, something real exists. By dinner, I'm wondering why the company needed six months.

And as much as I love this lack of process as my new process, I would caution that overstating my new superpower is where bad decisions get made. Because even if my Saturday prototype feels like an answer, it isn't. It's the question -- made visible.

If you can replace some of that massive spec document with something real, you've done something important. You're no longer asking people to imagine the thing from a sketch of a sketch. You can point at it, you can touch it. You can argue about it, and you can break it. And you can improve it -- or kill it quickly and move on.

That's the Trivial Token Timeline -- where you can build anything quickly, but still have to decide what matters. Now that writing code is cheap, you can plan in prototypes -- but only if you're honest about what a prototype is. It's a planning tool that happens to look like a product.

And that's a big freakin' distinction.

The distinction matters because AI prototypes are especially good at faking maturity. A demo can have a plausible login screen, a dashboard, a streaming response, a dark mode toggle, and enough animated confidence to make everyone forget the backend is a spreadsheet with anxiety. That does not make the product real. It means the product question is now visible enough to fight about honestly.

So a prototype-first process needs different review questions:

What assumption did this prototype test?
What did we learn that the document could not have shown us?
Which parts are throwaway scaffolding?
Which parts are durable enough to keep?
What evidence would make us stop?

Those questions are the planning layer. The prototype is the artifact that makes them answerable.

What Still Takes Human Time

The organizations that figure this out won't skip the hard thinking. The user testing, market research, pricing strategies -- all of that. They'll just move it earlier and test it against reality instead of letting it sit unchallenged in a document that nobody ever updates again.

For execs, the question changes from "Are we confident enough to fund this?" to "What is the fastest thing we can build to find out if this is even the right question?" (That used to be impractical, as even a month-long prototype raised eyebrows: "You're going to throw it away?" finance would ask. "Maybe?" was my response, but "Hell, yes" was my honest answer).

Cheap code doesn't make those strategic business decisions easier. It just makes them sooner.

Now you can place a dozen bets in the time it used to take to approve one. But the bets still matter, even if they cost a lot less. Because selecting the right one -- understanding why it worked, why the others didn't, and what it actually means -- that part hasn't gone away, nor has it been solved by AI magic.

It's just been moved.

The cost that collapses is not the cost of judgment. It is the cost of producing a thing that can expose whether judgment is needed. That is wonderful, but it is not the same as being right. If a generated prototype shows that customers do not want the workflow, congratulations, the prototype worked. If the same prototype gets promoted into production because it looked finished on a screen share, congratulations, you just converted cheap code into expensive regret.

This is why prototype-first planning has to include explicit disposal rules. What do we throw away after the learning is done? What gets rewritten because the architecture was only there to test a market question? What gets retained because the experiment accidentally uncovered a useful primitive? Without those rules, the Trivial Token Timeline turns into a junk drawer of demo code with a roadmap taped to it.

The top of the statue is still there.

Not buried in the sand -- just sitting in the room with you, every time we mistake a plan for the thing itself. Now you don't need six months anymore, now you need one or a dozen honest prototypes, and the willingness to throw them away.

That part -- deciding what actually matters -- isn't free.