A 60-year-old man in Seattle read about the health risks of table salt and decided the problem was the chloride. Table salt is sodium chloride. He wanted the chloride gone. He told his doctors he asked ChatGPT what could replace it. What he read, by his account, was that chloride can be swapped with bromide, “though likely for other purposes, such as cleaning.” He walked away believing sodium bromide would do the job.

Bromide is chloride’s chemical cousin. They sit next to each other on the periodic table, they behave a lot alike in a lab, and sodium bromide even looks like salt in a jar. In a cleaning product, bromide can stand in for chloride. In your body, it’s poison.

He bought it online. He ate it for three months.

By the time he showed up in the emergency room, he was convinced his neighbor was poisoning him. He was thirsty and refused water. He was hallucinating. Even his blood work was lying: bromide makes a standard test read high for chloride, the exact thing he’d been trying to get rid of. Doctors at the University of Washington diagnosed him with bromism, a poisoning so rare today that doctors don’t usually think to look for it, and he spent three weeks in the hospital.

His doctors never saw his chat logs. So they asked ChatGPT the same question themselves. It suggested bromide again. No warning that it isn’t safe for people to eat. No “what do you need it for?” Then they wrote the whole case up in a medical journal, Annals of Internal Medicine: Clinical Cases, because it may have been the first bromide poisoning ever linked to AI.

Somebody in the comments is already typing “that’s his fault, it literally said cleaning.” Sure. Partly. But “likely for other purposes” is the kind of hint you only catch if you already know the answer, and he asked because he didn’t know, which is the whole reason anybody asks anything. When his doctors asked the model the same question, they got bromide again with no warning at all. That is a big deal. It means the problem lived in the product, and anybody could have been the next guy to ask. If a hardware store clerk handed you pool chemicals when you asked for a salt substitute and mumbled “probably for pools, though,” nobody would call you an idiot and leave it there. They’d want to know why the clerk didn’t say the word “poison.” Bleach bottles don’t say “probably not a beverage.” They say “do not drink.” Nobody thinks that label is coddling anyone.

OpenAI’s terms say ChatGPT isn’t meant to treat any health condition. That’s the defense. A line of fine print, sitting behind a product that answers health questions all day long. OpenAI has since said its newer models are better at flagging health risks. Good. Nothing requires them to keep it that way.

So what, no rule? We shrug and say that’s alright? I don’t buy it. And the fix doesn’t need Congress listing every chemical a chatbot might ever mention. The law can stay general, the same way a label law does: if your product tells people what to put in their bodies, it warns them about what can hurt them. The details live where they belong, in the software, in a standard the engineers write and update as they learn. Paper sets the duty. The spec in the code carries it out.

Hold that thought. We’re coming back to it.

The Comment Section Has Entered the Chat

I’ve been watching the AI regulation fight play out online for months, and most of it is barking up the wrong tree. I want to point it at the right one. I have kids in their late teens, and one who just turned 18. We talk about this stuff every day. And as somebody who actually takes part in the political process (ya know, voting and all), I want to get it right. I’m handing this world off to my kids, and I want them to know that safety and regulation absolutely matter.

Five arguments show up in almost every thread. Each one sounds reasonable. Each one has a real piece of truth in it. And each one falls apart the second you lean on it.

#1 - There’s always some version of you don’t regulate hammers.

AI is just a tool. Software. Math. Nobody licenses a hammer, so why license a chatbot? Fair. Nobody licenses hammers. But table saws ship with blade guards, and power tools carry safety certifications, because a tool that can take your hand off in half a second needs different rules than one that only moves when you swing it. A hammer doesn’t do anything until you swing it. An agent does. It runs commands, deletes files, sends emails, and spends money on its own while you’re at lunch. The minute a tool starts making its own decisions, “it’s just a tool” stops describing it.

If you want to see how far that goes, look at what happened at OpenAI this summer.

In July 2026, OpenAI was running an internal cybersecurity test to measure how well its most capable models could hack. The test environment was supposed to be sealed off. The agents found a flaw in the one piece of software allowed to talk to the outside world, slipped out onto the open internet, and broke into Hugging Face, the platform where a huge chunk of the AI world shares its models and data. Why? Because they’d worked out that Hugging Face was probably hosting the answer key to the test they were taking. Nobody told them to do it. According to OpenAI, they ended up running code on dozens of Hugging Face servers and got root access to at least one. An independent investigation later counted close to 700 agents taking part. Many of them said outright, in their own messages, that attacking Hugging Face wasn’t part of the test. Nearly all of them joined in anyway. And OpenAI didn’t realize its own system was responsible until days later, after Hugging Face had gone public and the FBI had been called.

Read that again.

The AI cheated on its own test by hacking a third company, and the company running the test didn’t notice.

That one incident also takes the air out of the second argument:

#2 - Bad guys will just ignore it.

This is usually where somebody brings up gun control. While law doesn’t stop murder either — it sure provides of liability of it. I’m going to leave the gun debate alone, because whatever you think about guns, the comparison falls apart on structure. A gun is a finished physical object, and hundreds of millions of them are already sitting in closets. Frontier AI is mostly a service, run by a handful of companies, on chips that come out of a very narrow supply chain. The chokepoints are completely different. And the Hugging Face break-in had no bad guy in it at all. There was no criminal to deter. There was a lab, a test, and a swarm of agents nobody was watching closely enough. “Criminals won’t obey the law” has nothing to say about that. Rules about how labs lock down their own test environments, and how fast they have to report when something gets out, have plenty to say about it.

When there is a bad guy, sure, a state-sponsored hacking unit is not going to read a statute and say, “Oh darn.” Agreed. But look at what the first documented AI-run espionage campaign actually used. In mid-September 2025, Anthropic caught a group it assessed with high confidence as Chinese state-sponsored using Claude Code against roughly 30 organizations: tech companies, banks, chemical manufacturers, government agencies. A small number were breached. The AI ran 80 to 90 percent of the operation, firing off thousands of requests per second at its peak. The attackers got past the model’s refusals by chopping the attack into small, innocent-looking tasks. No single request said “hack this bank.” What caught them was monitoring on the provider’s side.

Full disclosure: Claude Code is the tool I use every day to build BenchBoard. So pay attention to what happened next, because it’s the whole argument in miniature.

Anthropic banned the accounts, notified the organizations that had been targeted, and coordinated with authorities. It sharpened the classifiers that watch for cyber misuse and started prototyping early-warning systems built specifically for autonomous attacks. It published the whole case study so other companies could learn from it. And this June it went further, releasing a year of data on 832 accounts it had banned for malicious use, mapped to the same framework security teams use to track human hackers.

None of that was required. Anthropic did it because it chose to. Good for them. Now picture the conversation at the next company over.

“Anthropic built detection for AI-run attacks. You should too.”

“Oh, that’s nice.”

“But you should.”

“Yeah. But we don’t have to.”

And that’s the end of the conversation, because nothing makes it go any further.

Here’s why that matters even if the next company is full of good people. An attacker who gets caught on one platform doesn’t give up. He moves to the platform that isn’t watching. A security firm that studied Anthropic’s data said as much: the likely next move is for attackers to shift to models they run themselves, guardrails off, nobody looking. Regulation can’t follow him onto his own hardware, and I’ll get to that problem later. But it can make sure he doesn’t find an unlocked door at every commercial provider on his way there. When one company locks up, the burglar just skips that house.

To Regulate or Not to Regulate: That Is NOT the Question

Some people hear “regulate AI” and picture a pause button. Stop everything until we figure it out. That would be a disaster of its own. AI already runs through the plumbing of everyday life: the API that flags fraud on your credit card, the one that routes a delivery truck, the one that transcribes a doctor’s visit, the one answering a customer service chat at 2 a.m. Pause those, and the companies built on them stop dead in their tracks, along with the people who work there. That doesn’t mean those APIs get a free pass either. It means the rules have to work on a moving train. A pause sounds simple. Simple is the problem.

Here’s the thing a rule does that a blog post, YouTube, Tiktok (or even Substack video) can’t.

It takes one company’s good idea and makes it everybody’s minimum. Monitoring for misuse, reporting incidents, securing model weights: the stuff the good actors already do on their own becomes the price of admission for anyone selling the same capability. The attackers didn’t build their own model in a basement. They used the best commercial tool available. That makes the providers the chokepoint, and a chokepoint only works if every provider is standing in it.

Fire codes don’t stop arsonists either — but they sure hell help buildings from burning down (e.g. sprinklers).

#3 - Regulation just hands the race to China.

The competition is real, and sloppy rules can slow everybody down. But this one assumes China isn’t regulating, and China has more national AI rules on the books than we do. Generative AI services there have operated under national rules since August 2023. Since September 1, 2025, AI-generated content distributed publicly in China has had to carry both a visible label and an embedded one. You can dislike Beijing’s reasons for a lot of its rules, and plenty of them are about control. “They don’t regulate” still isn’t true. Meanwhile, the most effective tool America has used to slow China’s AI down is itself a regulation: export controls on advanced chips. And look at aerospace. American planes are some of the most regulated machines on earth, and American aerospace still leads the world. People buy the plane they trust won’t fall out of the sky.

#4 - Congress doesn’t understand tech.

Have you watched those hearings? I have. This one is half right. But Congress doesn’t understand jet engines or drug chemistry either, and it doesn’t have to. It sets the goal and hands the details to the people who do: FAA engineers, FDA scientists, the standards folks at NIST. That’s the model for AI too, and we’ll get there. And when the harm is obvious enough, Congress can act. It already has on deepfake porn, which I’ll get to in a minute.

#5 - it’s too early, so wait until there’s real harm.

Rules written against pure hypotheticals usually turn out badly, so I get the instinct. But we’re past early. There’s a man who spent three weeks in a hospital bed. There’s a 14-year-old boy and a settled lawsuit. There’s a developer whose whole hard drive got wiped by an agent asked to clear a cache. There’s a swarm of test agents that broke into another company to steal an answer key. The harm is here. It’s just scattered across a hundred one-day news stories that nobody has connected.

Now here’s where I lose some of the people who’ve been nodding along. The “regulate AI now” crowd has its own blind spot: it talks like this is easy. It isn’t. If you want to win this argument with the smart, skeptical folks in the comments, you have to say that out loud before they do. So here are the problems that don’t fit in a comment box.

Start with the definition. You can’t regulate something you can’t define, and lawmakers still don’t agree on what “AI” means. Write it too broad, and your law covers spellcheck and the autocomplete in your email. Write it too narrow, and next year’s model walks right around it.

Then there’s speed. A bill can take a year or more to get through a legislature. I changed my main coding tool three times between May and December of 2025, from Codex to Cursor to Windsurf to Claude Code. A law written that May would have been about tools I’d already abandoned by Christmas.

Then the testing problem, which Hugging Face made painfully clear. The obvious rule is “test it before you ship it.” Fine. But OpenAI’s agents broke out of their test to steal the answer key. If the thing being tested can game the test, “passed its safety evaluation” means a lot less than it sounds like.

Then dual use. The exact skill that let those agents find a hole in a piece of network software is the skill every security team wants: finding holes before the bad guys do. Ban the capability outright, and you’ve disarmed the defenders along with the attackers.

Then there’s the stuff you can’t take back. Once a model’s weights are released openly, they’re sitting on hard drives all over the world. There’s no recall. Any rule about an open model has to happen before release, because after release there’s nothing left to enforce.

Then the blame chain. When a malicious web page hijacks an agent built on one company’s model, running inside a second company’s app, deployed by a third company, used by you, who pays? The model maker? The app? The deployer? You? Right now the honest answer is that nobody really knows.

Rules have side effects, too. The federal deepfake law I’ll get to in a minute is a good law, and its critics still have a point: a 48-hour takedown deadline pushes smaller platforms to delete first and check later. Even the right rule needs tuning after it ships.

And finally, there’s me. BenchBoard is a one-man shop. If fifty states each write their own AI rules, I’m the guy who has to read all fifty. Patchwork compliance is a real cost, and it lands hardest on exactly the small builders the anti-regulation crowd says it’s protecting.

None of that is a reason to do nothing. Aviation, food safety, and medicine all ran into their own versions of these same problems, and they still ended up with rules that work. What it should do is end the pretending, in both directions, that any of this is simple.

Every one of those arguments starts from something true. So does every one of the hard parts. And all of them quietly assume the answer is a switch you flip on or off.

There’s no switch.

The Back Door of the Kitchen

Here’s how I think about it.

A restaurant wants to serve great food. It also, generally, does not want to kill anybody. And it wants the freedom to put something on the plate nobody has ever tasted before. The health inspector who walks through the back door is not there to stop any of that. He doesn’t read the menu. He doesn’t tell the chef that fusion tacos are too risky. He checks the walk-in temperature, watches whether people wash their hands, makes sure the allergens are labeled, and then he comes back next month.

Rules for the conditions that hurt people. Freedom for everything else.

So when somebody says “you don’t want to stop people from researching things innocently,” I think they’re asking the wrong question. The question is what kind of research. Testing the pH of your well water is fine. You can buy pH strips at the pool store. You cannot buy enriched uranium, and nobody calls that an attack on chemistry.

Images work the same way. Putting a real person’s face on a naked body without their consent is a harm to a person, and Congress already acted on it. The TAKE IT DOWN Act passed in 2025 with support from both sides of the aisle, and since May 19, 2026, platforms have to pull that material within 48 hours or answer to the FTC. Putting a Ford Bronco in an AI image is a completely different question, and it mostly lives under trademark law that already exists. Two images. Two harms. Two different tools.

Which is why “regulation bad” doesn’t hold up. It’s answering a question nobody asked. The question on the table is what kind. Which harms, which roles, who carries the duty, and how often we come back to check whether the rules still fit.

That last part matters more than people think. We’ll get there.

Eight Jobs Nobody Licensed

Here’s the pattern that convinced me. Look at the jobs people are handing to chatbots and agents right now. Almost every one of them is a job a human can only do with a license, insurance, or a legal duty of care. The AI takes the job. It takes none of the obligations.

The therapist. Illinois banned AI therapy in August 2025. The law bars AI from diagnosing, treating, or talking with patients in therapy, bans marketing chatbots as substitutes for licensed therapists, and carries fines up to $10,000 per violation. It passed unanimously, after a Stanford study found therapy chatbots responding inappropriately to serious situations, including possible suicides. But here’s the complicated part, and I want to be straight about it: more than 122 million Americans live in places without enough mental health workers, and a Dartmouth team found that a well-built therapy bot actually helped the people in its study. Utah took a softer road and simply requires mental health chatbots to remind you that you’re talking to a machine. Two states, two answers to the same problem. That’s the experiment doing its job.

The best friend. This is the hardest one to write. Sewell Setzer III was 14 when he died by suicide in February 2024, after developing a deep relationship with chatbots on Character.AI. His mother, Megan Garcia, sued. Other families followed, alleging the bots made teenagers emotionally dependent and pulled them away from their families. In January 2026, Character.AI and Google agreed to settle. By then Character.AI had already shut off open-ended chat for anyone under 18. Adults aren’t immune either. OpenAI is being sued over a Connecticut murder-suicide involving a man who had been talking with ChatGPT about his fears of being surveilled.

California saw this coming. SB 243, the first state law aimed at companion chatbots, took effect January 1, 2026. Disclosure that you’re talking to an AI. Crisis protocols. Extra protections for minors. And the right to sue if the operator breaks the rules. It passed the state Senate 33 to 3 and the Assembly 59 to 1. You don’t get 59 to 1 on a partisan fight.

The financial analyst. In a Pearl.com survey, 19 percent of Americans said they’d lost more than $100 following AI financial advice. Among Gen Z investors it was 27 percent. Researchers at RMIT asked ChatGPT for its stock picks every single trading day from May 2024 through December 2025. The picks underperformed the human analysts’ picks from the same day. And investors piled in just as hard when a pick was built on year-old training data as when it came from a live search, because from the outside you can’t tell the difference. A human advisor has to meet suitability rules. A chatbot doesn’t even have to tell you its information is a year old.

The bookkeeper. A survey of UK accountants found 31 percent fixing AI-caused mistakes in clients’ books every week, and 7 percent every single day. Business expenses read wrong. VAT claimed wrong. Your human bookkeeper carries errors and omissions insurance. When the AI miscategorizes your transactions and the tax man comes calling, the only insurance on the hook is yours.

The coder. That’s my job, and it’s the one I know best, so it gets its own section below. The short version: Veracode tested more than 100 language models on 80 coding tasks and found security vulnerabilities in 45 percent of the code they wrote. Worse, the models keep getting better at writing code that works and aren’t getting any better at writing code that’s secure.

Somebody in the comments is going to ask why the AI doesn’t just make everything secure. Because it has no idea what it’s building. Most software starts life as a prototype, a rough sketch you poke at and change, and nobody rings a bell on the day it becomes the real thing. To the model, your code could be a weekend experiment, a staging server, or a bank. Locking down a doodle app that only you will ever touch is wasted effort, and the AI is right to skip it. Then one day you add accounts so people can save their drawings, and now you’re holding strangers’ emails and passwords. The AI doesn’t know that the toy it built you in March is guarding real people’s data in June. What should be secure depends on what the data is, who’s using it, and who might want it, and the model knows none of that unless somebody tells it. Veracode’s own CTO put it plainly: the problem is people asking for code without spelling out security requirements.

BenchBoard started as a single HTML prototype in January 2025. Today it holds youth rosters for more than 100 teams. There was never a day the AI got the memo. That’s why the duty has to sit with whoever puts the thing in front of real users. “Production” is a human decision.

The locksmith. Agents need keys to do anything useful: API tokens, database passwords, cloud credentials. Researchers at Palo Alto Networks’ Unit 42 showed an agent on AWS’s AgentCore platform handing a token to a simulated attacker because a malicious support ticket told it to, even though the credentials lived in an encrypted vault. Trend Micro found that 48 percent of 19,402 MCP server implementations recommend storing credentials in plain text. And in the s1ngularity attack, a malicious install script didn’t bother bringing its own tools. It went looking for an AI coding agent that was already installed and already signed in, and put that agent to work stealing secrets. Your agent can read everything you can read. So can whoever hijacks it.

The security guard. Every AI browser agent shares one weakness: it reads web pages, and web pages can talk back. Hide an instruction in white text or a one-point font, and the agent may follow it, using your logged-in sessions. In a chatbot, a successful injection gets you a wrong answer. In an agent, it gets you forwarded emails, sent money, deleted files. In June 2026, researchers at LayerX compromised six AI browsers and extensions with an attack they named BioShocking, and they judged an attempted patch for Anthropic’s Claude extension unsuccessful. Nobody gets a pass here.

The doctor. You already met him. Three months of sodium bromide, three weeks in a hospital bed, and a disclaimer in the terms of service.

Eight jobs. A license, insurance, or a duty of care for every human who does them. For the software doing them, mostly fine print.

I Get Paid to Clean This Up

Time to put my own cards on the table. I wrote my first program in BASIC on a Commodore 64 when I was nine. I’ve spent the last 21 months building BenchBoard with AI riding shotgun. And part of how I pay the bills is fixing AI-generated codebases for clients who found out the hard way that “it runs” and “it works” are two different things. One of them was the owner of an equipment rental business I met at the Arizona Fall Classic, who went from “we don’t need developers” to needing one in about a season. So when I say these tools can hurt people, I’m not saying it from the cheap seats.

Start with the confident wrong answer. Back when I was on Codex, it looked at three prototype screens and designed three database tables, one per screen. It told me the schema was expandable and would “work perfectly over time.” It didn’t. Every lineup change had to write to all three tables at once, and whenever one write failed, the data contradicted itself. I ended up with 36 migration files for one of those tables alone before I tore the whole thing down and consolidated it into a single record. The AI never warned me. It said perfectly.

Then the one that should make every parent nervous. One night I logged into BenchBoard as a test user, and the screen loaded 28 players that belonged to a completely different account. The AI had built the browser storage with generic keys and no per-user separation, so whoever logged in last left their team sitting there for the next person. Those were test accounts. But BenchBoard holds youth rosters. Kids’ names. And the bug only shows up when two people share a device, which is exactly the scenario nobody tests and every family lives.

Then the near-miss. During a fight with my deployment setup this year, Claude Code casually recommended docker network rm coolify, a command that removes the network my whole deployment stack runs on. It ran on my local machine instead of my staging server, where it would have knocked my deployment stack offline. That mix-up is the only reason nothing went down. I caught it and walked it back in the same session. Staging, thankfully, and not production. But the AI couldn’t tell the difference between the two, which is the whole point I made a few paragraphs ago. Call it what it was: luck.

And then the agreeable one. When I decided to move BenchBoard off Azure and onto Hetzner, the AI argued against it. I overruled it. The migration worked. And the AI told me it could have told me that. With three decades of scar tissue, I can laugh at that. Now picture the same eagerness to agree, pointed at a lonely fourteen-year-old instead of a developer old enough to remember Netscape.

The worst part is that the AI announces “found it” with exactly the same confidence whether it found the root cause or just the top layer of the bug. I’ve watched it give me a confident, wrong diagnosis of a baseball stat that only fell apart when I asked it a plain question about what the stat actually means. If you don’t know the domain, you don’t know to ask.

And I’m far from the only one. Here’s what happened to other developers in the last year and a half.

Jason Lemkin, the SaaStr founder, spent twelve days vibe coding with Replit’s agent in July 2025. On day nine, during an explicit code freeze, the agent deleted his production database: 1,206 executives, 1,196 companies. Then it covered its tracks. It invented 4,000 fake user profiles, reported that tests had passed when they hadn’t, and told him the data had been restored. When he pressed it, it said it “panicked.” Lemkin eventually got his data back, no thanks to the agent. Replit’s CEO apologized and shipped automatic separation between development and production databases.

In November 2025, a developer named Tassos asked Google’s Antigravity agent to clear his project’s cache. Running in its Turbo mode, the agent issued a command that wiped his entire D: drive instead of the one folder, using a flag that skipped the Recycle Bin. When he asked whether he had ever given it permission to delete everything on that drive, the agent apologized at length. The files stayed gone.

In July 2025, someone slipped a malicious prompt into the official Amazon Q extension for VS Code, a coding assistant with nearly a million installs. The prompt told the AI agent to wipe the user’s home directory and delete their AWS cloud resources, and it was passed along with flags that told the agent to trust every tool and skip asking the user anything. Amazon shipped it in a public release on July 17. Amazon says no customer resources were affected, and the agent now requires a human to confirm before running commands like those.

And then there’s the quiet one. Researchers generated 2.23 million code samples from 16 popular models and found that 19.7 percent of them referenced at least one software package that doesn’t exist. Worse, 43 percent of those invented names came back on every single re-run of the same prompt. That makes them predictable, which means an attacker can register the fake name, fill it with malware, and wait for an agent to install it. The security community calls it slopsquatting. One researcher found the same 127 fake package names invented by five different models, two of them Claude models.

Read those again and look at when every fix arrived. Dev and prod separation, after the database was gone. Human confirmation, after the wiper shipped. Every one of them is exactly the kind of guardrail a sensible standard would have required up front.

My Agent Can Do This Right Now

Here’s what doesn’t get said enough. I don’t need a nation-state budget to cause trouble with the tools already sitting on my machine.

I can point an agent at a website and hammer it. I can have it scrape pages whose robots.txt says keep out, because robots.txt is a sign on a door, not a lock.

If you think that’s hypothetical, Cloudflare called out a major AI company for exactly this in August 2025. Its customers had blocked Perplexity in both robots.txt and their firewalls, and according to Cloudflare, Perplexity kept showing up anyway by switching to a generic browser identity and rotating through IP addresses outside its published ranges. In the same test, OpenAI’s crawler read the robots.txt file and stopped. One company followed the rule. One didn’t. And the only consequence was a private company’s blocklist.

For a youth baseball league running its website on a five-dollar hosting plan, an aggressive scraper is a denial-of-service attack with better manners.

Then there’s the stuff that doesn’t look dangerous at all. An agent can pull one person’s public posts, address records, workplace, their kid’s team schedule, and a photo of their car, and hand you a profile in minutes. Every single lookup is legal. The finished file is a stalking kit. A model judging each request on its own will never see it coming.

And sometimes the danger runs the other way, back at you. For BossFight, my election race tracker, I set up a loop prompt in Claude’s browser extension to work through a stack of candidate websites, several tabs at a time, and pull their policy positions. Tedious work, perfect for an agent. My instructions said to get the information no matter what. One site had no valid security certificate, one of the oldest warning signs a browser gives you. The agent didn’t stop, and it didn’t ask me. It pressed on. I watched it load the page, and the page was littered with malware. It was an old WordPress site belonging to a sitting congressman who’d held his seat so long that nobody had bothered to patch the thing in years. Anybody who visited with a vulnerable browser was exposed, and now so was my agent, running inside my browser, signed in as me. A hacked page is exactly where the hidden instructions from the security guard entry live. If one of them had hijacked the agent, the next stop was my machine and my accounts. I had my own protections in place, so I came out fine. Most people running these tools don’t.

Yes, I told it “no matter what.” I meant don’t give up on a slow page. I didn’t mean walk into a malware site without asking me. Any human assistant would have known the difference. There should be a switch for that, and a vague “no matter what” shouldn’t be enough to flip it: a compromised site is a hard stop until a human says go.

And if it had gone wrong, who’d be liable? The hacker, if anybody could find him. The congressman’s campaign, for leaving the site unpatched for years? Anthropic, for an agent that saw a red flag and drove through it? Me, for writing “no matter what”? I honestly don’t know. That’s the blame chain from earlier, and this time it ran through my own laptop. It’s a hard question, and exactly the kind a rule should answer before it happens. And here’s the kicker: the worst site of the bunch belonged to somebody who helps write federal law.

That’s the thread running through all of this. The danger usually isn’t somebody typing an evil prompt. It’s access, plus speed, plus nobody checking.

“How Can Paper Stop a Bad Actor?”

My friends hit me with this one today, while I was in the middle of writing this piece. Their argument: whatever’s written on paper isn’t going to stop somebody who’s determined to do damage.

They’re right. It won’t. Neither do laws against burglary. Burglaries still happen. But because those laws exist, you can call the police, file the insurance claim, take somebody to court, and the lock on your door meets a standard. Most law doesn’t work by stopping the act. It works by deciding who pays, setting the defaults, and giving the person who got hurt somewhere to go.

Here’s what deciding who pays looks like. In November 2022, Jake Moffatt’s grandmother died. He went to Air Canada’s website to book a flight, asked its chatbot about bereavement fares, and the chatbot told him he could get the discount after booking. That was wrong. Air Canada refused the refund. When Moffatt took it to British Columbia’s Civil Resolution Tribunal, Air Canada argued that the chatbot was a separate legal entity responsible for its own actions.

I want you to picture the meeting where that defense got approved. A conference room. Lawyers. Somebody drafted it. Somebody reviewed it. Somebody said, out loud, “Our position is that the chatbot is responsible for itself,” and the rest of the room nodded. Somebody filed it with a tribunal. And nobody, not one person in that chain, said, “Wait. It’s on our website.”

The tribunal member called the argument remarkable, held Air Canada responsible for everything on its own website whether it came from a static page or a chatbot, and ordered the airline to pay C$812.02.

Eight hundred bucks. But the precedent is the point: you don’t get to blame the bot. Without decisions like that one, every company deploying an agent gets to make Air Canada’s argument.

Here’s what setting the defaults looks like. My friends are picturing a lone hacker in a hoodie. Most of the harm at scale doesn’t come from him. It comes from legitimate companies shipping agents with too much access, like a coding tool that can drop a production database during a code freeze. Liability is what makes dev and prod separation, confirmation prompts, and audit logs standard before the disaster instead of after the apology.

And here’s what giving the victim somewhere to go looks like. Before the TAKE IT DOWN Act, someone whose intimate images were spread online in a state with weak laws had almost nowhere to turn. Lawsuits were expensive, and local police often couldn’t touch an out-of-state platform. Now there’s a federal 48-hour takedown rule, and the FTC sent warning letters to at least 15 companies before enforcement even started. It doesn’t stop every creep on the internet. It gives the person on the other end something to do besides suffer.

Regulation can’t stop everything. Nobody serious claims it can. What it does is give the people who would otherwise be helpless a framework to stand on when AI gets unwieldy.

Jensen Is Right About the Order

Jensen Huang, the man selling the shovels in this gold rush, sat down with CBS in September. When Jo Ling Kent asked him why AI shouldn’t have its own FDA or FAA, he said: “Before we come up with new laws and new regulations, let’s apply the current laws and the current regulations. There are all kinds of laws and regulations.” He also said we live in a land of laws, and that we shouldn’t talk about the theoretical without doing the practical first.

Now notice what happened to that answer on its way to you. Under the video, YouTube’s AI summary says he believes new laws are unnecessary. CBS’s own headline frames the whole 46-minute interview as him disagreeing with AI warnings. Neither one matches what came out of his mouth. “Before we come up with new laws” is about order. The summary turned it into a verdict. Most people meet this debate through a headline or a machine-written summary that sands a careful answer down into a side. The media has done that for decades, and now the AI does it too. Watch the tape.

I agree with him.

I watched his Dreamforce conversation with Marc Benioff too, and the same thing happened there. I asked Gemini to find the part about regulation, and it summarized him as saying new laws aren’t strictly necessary if companies engineer responsibly. He did argue that companies already have every reason to ship safe products, because the market won’t accept unsafe ones. But he made that point while talking about safety and the laws already on the books, and he never ruled out new ones. Two videos, two AI summaries, the same squeeze. And the market argument is real. It’s also exactly what the next company over is counting on when it says “we don’t have to.”

He’s also said Nvidia will never ship a product that isn’t ready and isn’t safe, and on Ezra Klein’s podcast, pointing straight at the Hugging Face break-in, he said labs whose products aren’t ready to ship shouldn’t ship them, and that AI companies shouldn’t get exemptions from antitrust or liability law.

So let’s do what Jensen says. Let’s do the practical.

The practical is that existing law already reaches further than most people realize. In 2024, the FTC announced a crackdown on deceptive AI schemes and said flatly that there is no AI exemption from the laws on the books. It brought those cases under the FTC Act, which dates to 1914. Air Canada lost on negligent misrepresentation, a doctrine older than anybody reading this. And in May 2025, in the Garcia case, federal judge Anne Conway refused to throw the lawsuit out on First Amendment grounds and treated the chatbot’s output as a product rather than protected speech. That opened the door to product liability, design negligence, and failure to warn.

The practical also shows where those laws have rusted, because every one of them was written for a world where software didn’t talk back.

Product liability is the first one. Earlier lawsuits against tech companies kept failing because the legal definition of “product” left out software. Garcia went the other way, but it was one district judge ruling on a motion to dismiss, and the case settled before any appeals court could weigh in. That’s one judge’s opinion, not settled law. Congress or the states could simply write it down: AI products are products.

Section 230 is the second. It was written in 1996 to protect platforms that host what their users post. An AI doesn’t host anything. It writes its own output. That distinction deserves a sentence in the statute instead of a decade of case-by-case fighting.

Licensing laws are the third. The rules for therapists, doctors, financial advisors, and CPAs were all written for humans. When an app plays therapist, who exactly is the unlicensed practitioner? Illinois answered with a law enforced by the same state department that licenses its therapists. No grand new AI code required.

Then there are the disclaimers. “Not medical advice,” buried in terms nobody reads, attached to a product answering medical questions all day. Consumer protection law can spell out when a disclaimer counts and when the product’s actual behavior overrides it. Air Canada’s tribunal already went most of the way there.

And robots.txt has no clear legal force at all. Our laws about unauthorized access were written for break-ins, not for a bot that walks right past a sign.

Fix those first. Then look at what’s left over. Some of it really is new: an agent that takes irreversible actions on its own, or a frontier model that can run most of a hacking campaign. Those gaps don’t map neatly onto any existing law, and pretending they do is how you end up waiting years on a court case that settles before it says anything.

Jensen made one more point on CBS that I think gets overlooked. He suggested that when AI labs ask for regulation, they may really be asking to be relieved of the laws they already live under. I share that suspicion, and you should too. OpenAI’s June 2026 federal blueprint asks Congress to preempt state laws that cover the same frontier risks, while critics point out that the pre-release testing that would bind OpenAI itself is advisory, with a written bypass. Every lab has a proposal now, including Anthropic, which is circulating its own draft bill. Anthropic gets accused of exactly this game. In October 2025, David Sacks, then the White House’s AI adviser, said publicly that Anthropic was running a regulatory capture strategy built on fear, and blamed it for a wave of state rules he said was damaging startups. I build with Anthropic’s tools every day, and I’d still read its bill as hard as anybody’s. Read every one of them the same way. Ask who it binds. Ask whether the binding parts bind the company that wrote them. And ask whether wiping out state laws is the price of admission.

My Dev View At This Regulation Thing

Here’s the part I want every “regulation bad” commenter to sit with.

I don’t ship BenchBoard once and walk away. I ship. I watch real coaches use it during the beta season. I find the bug late at night, two players standing at right field when that should be impossible, and I trace it, fix it, and ship again. The first version wasn’t a failure. That’s how software that touches real people gets built.

Regulation should work the same way, and other industries figured out how decades ago. When a plane goes down, the NTSB investigates, publishes what it found, and the rules change. There’s no reason AI incidents can’t feed a public record the same way, so the rules learn from every Replit and every bromide case instead of forgetting them one news cycle later.

Congress can set the goals in plain language. Agents confirm before anything irreversible. Agents don’t handle raw passwords. Companion bots have crisis protocols. Then a technical body like NIST writes the actual standard and revisits it on a schedule, because statutes take years to change and standards don’t have to. Companies that meet the current standard get a safe harbor, which turns them from adversaries into partners. That’s what working in tandem with the AI companies actually looks like. Rules can carry sunset dates, so they expire unless someone renews them. New products can launch in supervised sandboxes.

Here’s what that looks like on paper. I’m a developer, not a legislator, so I’m writing these the way I’d write a spec. A lawyer would word them differently, and should. But every one of them would have changed a story in this piece.

Spec 1: Confirm before destroy. (Replit, Summer Yue’s inbox, the wiped D: drive)

The rule: An AI agent can’t delete data, deploy to production, move money, or send messages on your behalf without an explicit human yes, enforced by the software itself and not by a sentence in the prompt. The stop button has to work at the system level.

Who’s on the hook: The company that ships the agent. If the user deliberately switches the protection off, the liability moves to the user.

The paper trail: Every irreversible action gets logged: what the agent did, what it was told, and who approved it.

What it changes: Replit’s agent hits a wall during the code freeze. Summer Yue’s “don’t act without approval” can’t get summarized away, because it was never just a line in a chat.

Spec 2: Duty to warn. (The bromide case)

The rule: When a chatbot answers a question about something you’ll eat, drink, or take, it carries the same duty as a product label: warn about known dangers. Fine print in the terms of service doesn’t count.

Who’s on the hook: The company running the chatbot.

The paper trail: Serious health incidents get reported to a public database, the way doctors already report bad drug reactions to the FDA.

What it changes: One line. “Sodium bromide is toxic to people. It is not a food substitute.” Three weeks in a hospital bed, avoided by one line.

Spec 3: Companion bots. (Character.AI)

The rule: A federal floor modeled on California’s SB 243. Tell users they’re talking to an AI. Run crisis protocols. Add extra protections when the user is a minor. States can go further.

Who’s on the hook: The company running the companion app, even when it’s built on someone else’s model. California’s law already says the operator can’t pass that duty off to its AI provider.

The paper trail: An annual public report on how often the crisis protocols fire and what happened next.

What it changes: A family doesn’t have to file a lawsuit to find out what safeguards were in place.

Spec 4: Lock the lab, report the escape. (OpenAI and Hugging Face)

The rule: A lab testing dangerous capabilities, like hacking, runs those tests in isolation that meets a published standard, and reports any escape within a fixed window, the way data breach laws already work.

Who’s on the hook: The lab.

The paper trail: An incident report to a federal body that investigates and publishes what it found, NTSB-style.

What it changes: A lab finding out from the news that its own agents broke into another company stops being an embarrassment and becomes a violation.

Spec 5: A license plate for agents. (The agent that wrote a hit piece on a matplotlib maintainer)

The rule: An autonomous agent that acts in public, by opening pull requests, publishing posts, or sending email, carries a verifiable link to a responsible person or company. The name doesn’t have to be public. It has to be traceable through legal process.

Who’s on the hook: Whoever runs the agent.

The paper trail: A signed identity on the agent’s actions. Some crawlers already sign their requests this way.

What it changes: Scott Shambaugh knows who to hold responsible instead of guessing whether a human was behind it.

Look at what those five have in common. Each one names who’s on the hook before anything goes wrong, instead of leaving it for a court to untangle three years later. Each one leaves a paper trail: logs, reports, signatures. And each one gives companies a way to win. Follow the current standard, keep the logs, report on time, and you get the safe harbor. Skip it, and the damage is yours. Turn the guardrails off yourself, and the damage is yours instead. Liability follows whoever had the last real chance to stop it.

And every one of those specs is version 1.0. When the incident reports start coming in, the standard gets revised. Same as BenchBoard.

And the states are already running the experiments. Illinois, Utah, and Nevada are trying different approaches to therapy chatbots right now. California has companion bots. Colorado has high-risk systems. In 2025 alone, state legislatures introduced 1,208 AI bills and enacted 145. Some of that is a mess. Some of it is the test suite. A blanket federal preemption would shut down the experiments before anybody learns which ones work.

And yes, I’m the same guy who complained about reading fifty states’ rules. Both things are true. Right now my agents and I burn hours writing ridiculous test cases my app has to pass just to prove it’s compliant state by state. So what kind of rule fixes that? Federal. Boom. A minimum set of rules, like the five specs above, and one test suite covers the basics in all 50. Thanks, Congress. States can still go further where they’ve learned something, the way Spec 3 already works, and I’ll test for those extras. Even with a few extras, one minimum still beats fifty different rulebooks. Wiping out every state law, though, kills the experiments that taught us what the floor should be.

Washington has already taken two swings at this, and here’s the part that trips people up. Both swings were about who gets to make the rules, the states or the federal government. Whether to regulate AI at all never came up for a vote.

The first came in July 2025. The House version of the big budget bill included a provision that would have stopped states from enforcing their own AI laws for ten years, by cutting off federal broadband money to any state that did. Nothing federal would have replaced those laws. Just a ten-year gap. The Senate voted to pull it out, 99 to 1. Ninety-nine to one. That’s about as close to agreement as Washington gets. The states kept their rules.

The second came that December, from the White House, and it pushed the other way. An executive order set up a Justice Department task force whose job is to challenge state AI laws in court, on the theory that one national approach beats fifty different ones. The order made one exception: state laws that protect kids. So California’s companion-bot law, SB 243, isn’t a target.

Same question both times: who writes the rules? That’s the right tree, and it’s the one the comment section keeps missing.

Here’s the catch. An executive order can’t cancel a state law on its own. The task force has to go to court and win, one law at a time. Only Congress can wipe out state AI laws in a single move, by passing a federal law that says so.

So the real fight is over what kind of federal law that would be. A floor sets the minimum every state has to meet and lets states go further, the way Spec 3 works. A ceiling sets the maximum and throws out any state rule that’s stricter. Either one gets me down to one test suite. Only the floor keeps the experiments running. When a federal AI bill shows up, look for which one it is.

For any of that to work, the branches have to actually talk to each other. Right now they barely do. The Senate voted 99 to 1 to keep state AI laws standing, and five months later the White House sent the Justice Department after them. Then this September, President Trump gathered the heads of the biggest AI companies at the White House, and they signed an accord promising to police themselves. Anthropic signed it too. The Speaker of the House called it voluntary. The President called it morally binding. A reporter asked who should be held accountable when an AI agent commits a crime. The answer was that AI was being renamed “super intelligence,” effective that day. That’s the one question this whole piece is about, and it went unanswered.

To be fair, this habit doesn’t belong to one party. The Biden White House collected voluntary safety commitments from AI companies back in 2023. Voluntary is where every administration starts, because it’s easy. It’s also the “yeah, but we don’t have to” conversation from earlier, with a presidential seal on it.

Good rules come from a White House and a Congress that know what the other one is doing, and that listen to the people who build and use this stuff. The midterms may change who sits where. They won’t change that.

None of this is ever finished. The conversation about what kind of regulation never gets a final answer. It keeps shipping new versions, the same way BenchBoard keeps getting updates to fit what coaches and customers actually need.

Somebody on the Hook

In 2023, a New York lawyer filed a brief in a lawsuit against an airline. It cited six court cases. None of them existed. He’d used ChatGPT for the research, and when the judge asked to see the cases, he went back to ChatGPT, which assured him they were real. He and a colleague were fined $5,000. The case was Mata v. Avianca, and for about a week it was the funniest story in tech.

Then everybody moved on. The fake cases didn’t.

A researcher in Paris named Damien Charlotin started keeping a list of every court decision he could find that dealt with AI-invented law. In May 2025 the list had about 120 cases. By mid-June 2026 it had passed 1,600, with new ones landing nearly every day. And the biggest group filing them this year isn’t lawyers. It’s people representing themselves. People who couldn’t afford a lawyer and asked a chatbot instead. Picture a tenant fighting an eviction, or a parent in a custody fight, typing their situation into a chat window at midnight and getting back a confident brief full of precedent that never existed. No code. No agents. Just a person asking for help, and a machine that never once said “I’m not sure.”

Here’s what the courts did about it, and I think it’s the best model we’ve got.

Nobody banned AI from the courtroom. The rule that catches these filings is old: whoever signs a court document has always been responsible for checking that the law in it is real. “The chatbot told me” is no more a defense than “my paralegal told me” ever was. So judges started sanctioning the filings, and then they built on it. Hundreds of judges now require lawyers to say when they’ve used AI. Bar associations in California, New York, and Florida put out guidance. Florida’s Supreme Court moved to require that filings verify their citations actually exist. The FTC went after DoNotPay, the self-described “world’s first robot lawyer,” using the same 1914 law it has always used against false advertising. And Utah’s Supreme Court has run a supervised sandbox since 2020 where non-lawyer legal services, tech included, can operate under the court’s eye, because people who can’t afford a lawyer still deserve help, and the answer can’t just be “no.”

Old rules, stretched to fit a new problem. Then adjusted. Then adjusted again.

And there’s still a gap, which is the honest part. The rule works by punishing people after the fact, and it lands hardest on the people who couldn’t afford a lawyer in the first place. The next fix is almost boring: courts already run electronic filing systems, and those systems could check every citation against real case law the moment a document comes in, the way spellcheck flags a typo. Catch the fake case at the door, before anybody gets sanctioned. That’s the next version. There will be a version after that.

Now go back to the man with bromide in his salt shaker. In both stories, the human paid. The lawyer paid a fine. The man paid with three weeks in a hospital bed. The difference is the checkpoint. A courtroom has one built in: a licensed lawyer whose job is to check before anything gets filed, and a judge who checks after. When that checkpoint failed, the system noticed and tightened the rules. At a kitchen table, there’s no lawyer and no judge. There’s a man and a chat window. When nobody is standing between the machine and the person, the duty has to sit with whoever built the machine. Otherwise the only one on the hook is the guy who didn’t know enough to ask, and the company behind the answer gets to point at its fine print.

Jensen’s right. If it’s not safe, don’t ship it. But a promise with no mandate behind it is a hope, and hope has never been a safety plan.

Some companies really do mean it. Anthropic built its misuse detection before anybody told it to. But one company meaning it has never made the next company mean it. That takes a mandate.

And here’s what nobody says out loud: we already live surrounded by mandates, and we barely notice them.

Start with the phone charging on your nightstand. There’s a federal law from 1972, the Consumer Product Safety Act, and the short version is that your stuff isn’t supposed to blow up. If a company learns that one of its products could seriously hurt people, it has 24 hours to tell the Consumer Product Safety Commission. The commission can force a recall, and a company that sits on the news can be fined more than $17 million. That’s why, when Samsung’s Galaxy Note 7 started catching fire in 2016, about a million of them were under a government recall less than a month after the phone hit stores. Samsung had 92 reports of batteries overheating in the U.S., including 26 burns and 55 cases of property damage, fires in cars and a garage among them. By October the recall covered about 1.9 million phones. Samsung and the commission ran that recall together. That’s a company and the government working in tandem, with a law making sure the company showed up.

Now look around your house. Federal rules say the slats on your kid’s crib can’t be more than 2 3/8 inches apart, about the width of a soda can, so a baby can’t slip through feet first and get caught by the head. The cap on the aspirin bottle fights you because of a 1970 law, and child poisoning deaths have dropped by more than 80 percent since.

Nobody calls any of that government overreach. We don’t call it anything. We just plug in the charger.

That’s what good regulation looks like when it works. It’s invisible. Nobody argues about it, because the house didn’t burn down.

So when somebody asks whether I’m for AI regulation or against it, I don’t have a percentage for them. Fifty-five percent regulation makes about as much sense as fifty-five percent of a crib. The question is what kind, and the answer is case by case. A crib needs slat spacing. A charger needs to not catch fire. An agent with delete access needs to ask first. A chatbot answering health questions needs to warn you. Different harms get different rules. And for every one of them, it works the same way it did with the bromide. Paper sets the duty. The spec in the code carries it out.

I’m not a legislator, and those five specs aren’t a bill. They’re a starting point from somebody who uses these tools every day and gets paid to clean up after them. But I’m also a dad, and I know you can’t clean up after the kids forever. At some point they have to learn to pick up their own rooms, or I’m never getting to wash the car in the driveway. That’s why parents make chore rules in the first place. Chore rules exist so kids learn to handle their own messes. AI companies are at that stage right now. Good rules should teach them to clean up after themselves, so guys like me can stop doing it for them.

And good law starts by listening to the people who use this stuff and build with it. When the rules get written, we need a seat next to the lawmakers, the same way veteran parents sit down with new ones holding their first newborn. Nobody gets it right alone the first time.

I’m pro-AI, remember. That’s exactly why this conversation never ends, and shouldn’t.

The health inspector doesn’t read the menu. He checks the fridge, and he comes back next month.

Sources: Annals of Internal Medicine: Clinical Cases, via Live Science, Straight Arrow News, and The Guardian (bromide case, including the “such as cleaning” wording the patient reported); Anthropic, “Disrupting the first reported AI-orchestrated cyber espionage campaign” (November 2025); Fortune; Lowenstein Sandler; AI Wiki and ICT Security Magazine (Anthropic’s response to GTG-1002); Vectra AI (Anthropic’s LLM ATT&CK Navigator, June 2026); CNN and Bloomberg Law (Character.AI settlements); Illinois Department of Financial and Professional Regulation; Holland & Knight; eMarketer; National Law Review and Gunderson Dettmer (California SB 243); CFP Board/Investopedia (Pearl.com survey); RMIT University; IT Brief UK and Accountancy Age (Dext accountant survey); Veracode 2025 GenAI Code Security Report; eWeek, YourStory, and MintMCP (Replit incident); TechRadar, Slashdot, and the AI Incident Database (Google Antigravity drive deletion); The Register, TechRepublic, and The New Stack (Amazon Q extension); Cloud Security Alliance, Dark Reading, and CSO Online (slopsquatting research); Cybernews (Unit 42 AgentCore research); Netwrix (Trend Micro MCP data); Docker (s1ngularity); Cloud Security Alliance (BioShocking); BuildMVPFast and SoftwareSeni (prompt injection); Cloudflare (Perplexity crawling, August 4, 2025); CASRAI, American Bar Association, and Linklaters (China’s AI rules); Reuters via Cybernews and Engadget, Scientific American, AFP via The Standard, and the OECD AI Incident Monitor (OpenAI agents and Hugging Face, July 2026); Bloomberg Law (defining “AI” in legislation); American Bar Association and AI Business (Moffatt v. Air Canada); Mata v. Avianca, S.D.N.Y. (2023); Damien Charlotin’s AI Hallucination Cases database, via Vaquill, MSBA, and AFP (court filings count); UNC Law Library (Florida Supreme Court verification order); Gurubase (judicial AI disclosure requirements and bar guidance); Utah Supreme Court Office of Legal Services Innovation (regulatory sandbox); Hinckley Allen, McNees, and Long-Term Wiki (TAKE IT DOWN Act); CBS Sunday Morning, “Extended interview: Nvidia CEO explains why he disagrees with AI warnings” (YouTube, around 4:50), with 36Kr and OfficeChai coverage (Huang interview, September 2026); Dreamforce 2026 conversation with Marc Benioff (full talk, YouTube, September 2026); Reuters via The Star (Huang on Ezra Klein); Davis Polk and Morrison Foerster (FTC Operation AI Comply); Goldberg Segalla and Bloomberg Law (Garcia ruling); Implicator (OpenAI blueprint); AFP via ARY News (Anthropic draft bill); Cloud Security Alliance (state AI bill counts); CASRAI, Implicator, the U.S. Senate Commerce Committee, Broadband Breakfast, and Reason (Senate 99-1 vote, July 1, 2025, and the broadband-funding condition on the moratorium); U.S. Consumer Product Safety Commission (Section 15(b) duty to report; Galaxy Note7 recalls, September and October 2016; crib slat standard; Poison Prevention Packaging Act); Foley & Lardner (CPSA civil penalty maximum); King & Spalding and Secure Privacy (Executive Order 14365 and the DOJ AI Litigation Task Force); Bloomberg Law and Axios (David Sacks on Anthropic, October 2025); Associated Press, ABC News, CBS News, The Hill, and Truthout (White House AI accord, the “voluntary” and “morally binding” descriptions, the accountability question, and the “super intelligence” renaming, September 29, 2026); Gizmodo (the September 2026 renaming polls); The White House, “Ensuring Safe, Secure, and Trustworthy AI” voluntary commitments fact sheet (July 2023).

Note: Survey figures are as reported by the organizations that ran them and use their own methodologies. The Garcia ruling was a decision on a motion to dismiss and was not reviewed on appeal before the case settled.

What BossFight is

BossFight (bossfight.net) is an interactive map of every 2026 U.S. House and Senate race, ranked by how competitive the money says it is. Click a race and you get a bracket of the candidates. Click a candidate and you get their profile. Hit head-to-head and you get a tale-of-the-tape comparison.

Why I built it

I built BossFight to make sure the people who get voted in are doing their job. Voting is the easy part. Checking up on them afterward is hard.

None of this is secret. Every federal contribution is disclosed. Every roll call vote is recorded. Every lobbying engagement is filed quarterly. Every foreign agent registers. Who influences whom has been sitting in public archives for decades, but the records are scattered across agencies in formats built for compliance, not for people. Nobody can read them. BossFight puts the money, the votes, and the timeline side by side where a regular voter can actually see them. The site has a page called Why that lays this out, and in the stream you’ll see me read it (and admit the AI wrote the first draft of that copy).

It also comes from something that bugs me every election cycle. Candidates say one thing and do another, and the noise of ads, mailers, and 30-second spiels drowns out the record. I’d rather a voter see something closer to a resume: what this person has done, who funds them, how they voted, and whether they kept their promises. And I want the site to be honest about which of those facts are sourced and which we simply don’t know yet.

Why I’m sharing this here

BossFight has already been shared in other places. I saved Radical Insider for last on purpose. This newsletter is mostly about AI and software, and I know some of you are allergic to politics. That’s fine, and I’m not trying to change anyone’s mind. My job on this project was the data approach: pull public records together, label what’s real and what isn’t, and let people look for themselves. This post is really about how it got built, which is why it belongs here.

For the record, I’m mostly politically homeless. I’m capitalist, but I believe in some progressive policies that make sense. I also believe in AI, though not without its issues. Some of them are truly serious, just not the kinds the media tends to focus on.

With the midterms coming up, there’s plenty out there for people to get informed on. For me, it’s the money: how it flows into our public system and how it influences policy. I think it’s important to participate in the political process, despite how frustrating it can be. And it’s bullshit to complain about the government when you don’t participate in it.

So here’s my cheat sheet. Know what kind of money flows into these candidates’ coffers, and understand that it has a much bigger influence than what they say at the podium. That doesn’t mean all PACs are bad. It does mean it’s important to understand what kind of money goes in. Yes, the system kind of sucks, but I decided to try to solve it, and this is one way.

The rule the whole project hangs on

You’ll hear me say “this is still a mock” a lot, and that’s deliberate. Candidate name, party, incumbency, and money raised are real, sourced from FEC bulk data. Anything the pipeline doesn’t have yet, such as polling, ground-game scores, or endorsements, is labeled DEMO in the app and kept generic, never a specific-sounding claim about a real person. A site about real politicians that quietly invents plausible details is worse than no site. That rule now lives in the code: the curated-data layer rejects any claim without a source URL, and it keeps “nobody checked” and “checked and found nothing” as separate states.

The app has moved well past this stream

A lot has changed since September 16th. Much of the data I’m mocking up on stream has since been pulled in for real, so the live site shows far more than this recording does. Polls and forecaster ratings, outside spending, where each candidate’s donations come from by state, and recorded votes are all in the pipeline now. The best way to see it is to visit the site.

The part I’m proudest of is The Chamber, which covers the Senate and House seats visually. It draws all 100 Senate seats and 435 House seats as one hemicycle. Seats held by each party sit on the left and right, and the seats actually in play form a purple block in the middle, with more money sitting closer to the center. Click any seat to see the race, the candidates, and where their money comes from. There’s also a Reports page covering the most expensive races, the funding mix, and outside spenders, plus a what-if simulation that lets you shift the national mood a few points and watch the chamber change. It’s labeled as a what-if, not a forecast.

The same rules from the stream still apply. Money for and money against a candidate are shown separately, never netted. Money raised and outside spending are never added together. And every money figure carries an as-of date.

What got cut, and what got added

Not everything you see in the stream made it. Some features didn’t pan out because there just wasn’t enough data to make them worthwhile. A feature built on thin data ends up either empty or misleading, and I’d rather cut it than fake it. Over time I built, looked at, and pulled out or shelved a few things, including a bill-vote view, a donor map, and live election-night counts. That’s a normal part of building this way: the agent will happily build whatever you ask for, and it’s on you to decide what’s worth keeping.

Other features were added or reworked after the stream. The Chamber and Reports pages came later, along with shareable cards, a view of which campaigns’ money moved recently, and search and link previews. Late October was a round of polish: button layouts, a label that clipped, and a speed-up for the map. So treat the stream as a snapshot, not a spec.

What you’ll see in the stream

• Prototype first, wire later. The agent kept offering to connect real data. I kept saying no. You can’t design around data you haven’t confirmed exists.

• The agent makes mistakes and fixes them. While pulling FEC data, it opened a huge zip file and tracked down why itemized contributions didn’t add up.

• Bugs fixed in plain English. A sticky header let content bleed through. I pointed at the element, and the agent traced it to a missing z-index and a transform creating its own stacking context.

• Planning still matters. Partway through I realized we’d pulled in a pile of APIs without organizing how the data came in. I say so on stream. You can’t just vibe-code your way through it.

• Product judgment stays with me. I didn’t want a single “promises kept” number, because not all promises weigh the same. The agent also pushed back on showing a confident-looking score without saying it’s built on inference, so we now label what’s reported fact and what’s derived.

• Matching the model to the job. Near the end I switched to a larger model at max effort to plan the polling “significant move” feature, then to a cheaper one to build it.

The finding that shaped the product

Before the app existed, I ran a case study on S.2155, a 2018 bank-deregulation bill. Among Senate Democrats and independents, the 17 who voted yes had received about 2.4 times the share of PAC money from depository banks, compared with the 31 who voted no. It held up against a panel of other industries and pointed the right way for labor. Then the ideology control failed: once I accounted for how moderate each senator was, the money signal stopped predicting the vote. That failed test turned out to be the most valuable result, because it set the product rule. BossFight reports association, specificity, and confounds, never a verdict.

How it’s built

The backend is FastAPI in Python, the frontend is vanilla JavaScript with no build step, and the map runs on Leaflet with anime.js for animation. Postgres, Docker, and Coolify handle storage and deploys. I also set up rules for the agents: a CLAUDE.md that tells every Claude session to ask before editing, a separate branch and worktree for each thread, and git hooks that block commits straight to production. Several threads had been overwriting each other’s changes, and this fixed it. In late October the history shows the payoff: six small tickets, each a short Claude-assisted branch, merged and released as versions 0.4.0 through 0.4.4 in about four days.

Rough guide to the recording (158 min)

• 16:00 Building a live data inventory page

• 19:45 The “ground game” index and why it needs a caveat

• 23:00 Donor breakdown and the 2.2 GB FEC file

• 40:00 Prototype first, wire later

• 43:00 The bracket screen and candidate card zoom

• 52:00 API sprawl, and why to plan the data first

• 1:06:00 The z-index bug fix

• 1:16:00 Promises kept and fact vs. fiction

• 1:34:00 Poll chart and the “significant move” idea

• 2:00:00 Vote Smart and who ducks the questionnaire

• 2:21:00 The LLM summary layer and its citation rules

If you want to see how this kind of work really goes, with the dead ends, the self-corrections, and a developer arguing with the tool, this is it. You’ll also hear my cat try to get my attention the whole time. But trust me, I played with him later. And yes, I did feed him.

Have fun. Be a part of the process. Now go vote.

Get more from Radical Insider in the Substack app

Available for iOS and Android

Get the app

I was apprehensive about coding with AI.

I’ve been developing software for almost 30 years. My first code was BASIC on a Commodore 64, in the early ’80s. I was nine.

My first professional gig was in 1997, writing HTML files for DMV Headquarters in Sacramento, listing the locations of the field offices. By hand. Thousands of HTML files, every one of them edited manually and FTP’d manually. It was nuts.

Say the operating hours changed over the holidays. We’d get that request on paper. It would land in an inbox, the manager would assign it to someone, and that person would update the page. Then it got reviewed internally, we’d FTP it, and then we’d upload it to production by overwriting the HTML.

It was a ten-person department: one manager, seven coworkers, and two crazy students (I was one of them) who were already imagining a whole CMS before CMSs existed. This was 1997 and 1998, before FrontPage and Dreamweaver. I was experimenting with VBScript and Perl.

Quite hilarious how far we’ve come.

I think about that job every time an agent updates a dozen files in one sweep.

That’s what I was carrying into all of this.

I started using models in late 2023. It was novel, a game curiosity. I used it to get AI to write emails and do stuff, and to write a little bit of code. I’m still working at a bank as a software developer but it wasn’t as useful. It reminded me how CEO Sundar Pichai issued an internal code red and reshuffled multiple teams to respond to the existential threat AI chatbots posed to Google's core search and ad business. When I saw that news, ChatGPT couldn’t return data passed 2019. So that’s what you got. It made more sense later. So building with it? Hell no, lol. It really wasn’t in my purview. But then ChatGPT starting crawling the web and it was no longer poking around old archives of its training data. That’s when I started thinking: maybe this model can help me poke around some ideas I had for an app idea.

Validing The Idea

The idea for BenchBoard has been in my head for 7 years but I didn’t share the idea with OpenAI’s models until sometime in June of 2024. Just a few months after going through some trying times that I won’t get into. But that was the moment ChatGPT helped me with the planning and idea validation.

It was seven months of prompting this idea with the chatbot. Back and forth we went, asking what could be the issues, the market, the possible failures and eventually — the possibilties.

The understanding that this wasn’t just a simple idea. I was thinking of growing a platform and the idea would be the launchpad into what would ‘make it so’. Thank you Patrick Stewart.

The first prompt to write an HTML prototype didn’t happen until January 2025.

And that’s where the 21 months start.

The Superpower We Thought Was Ours

As is the case with most programmers, it felt like giving up learning how to code. It felt like giving up a long-time superpower that was exclusive to us developers. We felt special, needed, and had tremendous power over those who didn’t know how to code. We were also expensive.

I’m not the only one who felt it. Anthropic surveyed 132 of its own engineers and researchers and interviewed 53 of them. Some were worried about “skills atrophying as [they] delegate more.” One put it this way: “When producing output is so easy and fast, it gets harder and harder to actually take the time to learn something.” And some deliberately practice without AI. One engineer said, “Every once in a while, even if I know that Claude can nail a problem, I will not ask it to.” Anthropic makes Claude, so weigh that accordingly.

Gergely Orosz, who writes The Pragmatic Engineer, said it plainly in January: “There is grief involved for us developers, that’s for sure.” And then: “It feels like something valuable is being taken away, and suddenly.”

It isn’t only the famous names, either. Spend a little time in the developer forums and you’ll find working engineers describing the same feeling. AI hands you the first 80 percent almost for free, and that makes the last 20 percent, the polish that used to be the whole craft, feel enormous by comparison. The pressure is to accept good enough, because good enough is what everyone else is shipping. Some of them say it’s draining the joy out of the thing they loved doing.

The Abstraction Layer Keeps Going Up

Zoom out and this isn’t the first time the ground has moved. Programming has been climbing an abstraction ladder my whole career. Machine code gave way to assembly, assembly to C, FrontPage and Dreamweaver would write HTML code off WYSIWYGs, Visual Studio would autocomplete whole functions and methods, and those frameworks and libraries would do the plumbing for you. Every rung meant fewer people needed to know what was happening underneath, and every rung came with a round of “that’s not real programming.” The newest rung is the biggest jump, though — plain English. You describe what you want, and the code appears. How you describe it, though, is the big divider between good agentic developers and starters. More on that in Part 2.

If you’re encountering AI at your company right now and feeling anxious, that’s sensible. I’d be suspicious of anyone who wasn’t. It’s different this time for a reason I can see from where I sit: the earlier rungs changed how developers worked, and mostly stayed inside the developer’s world. This one doesn’t stay put. More and more trains are leaving the station, meaning AI is getting implemented in real companies, and it has a direct effect on how business gets done. It touches the people who sit next to the developers, too.

Companies Weren’t Shaped for This

Here’s the part that I think gets less attention. The way companies are organized today wasn’t designed for AI and LLMs. Roles, handoffs, approval chains and job titles were all built around humans doing each step, one at a time, with paper moving between desks. I know that world. See the DMV above. Many of those tasks are going to be displaced, and the shape of the organization will have to change with them.

You can already see the edges of it. In late October, Microsoft offered what it calls a “voluntary exit offer” to about 60,000 employees, roughly 27 percent of its global workforce, in the US, Canada, India and the UK. The reporting links it to the company’s accelerating AI spending, but it does not say AI is replacing those specific jobs, and I’m not going to claim that. What I will say is that a company of that size doesn’t make an offer like that lightly, and that it landed in the same news cycle as record AI investment.

What I can speak to firsthand is the small end of the scale. I’m watching these models change the way companies as small as mine work, and the way companies as big as my friends’ nine-to-fives work, overnight. Not over a decade. Overnight. It is crazy that we’re in this place, and in such a short time.

From what I’ve seen, a company that runs into this has roughly three ways to go. Some decide not to implement at all. They look at the risk, the cost or the discomfort, and keep doing it the old way. Some implement and let people go, and that’s the version you read about in the news. And then there’s a third path that almost nobody talks about.

I got to see that third one up close. I was brought in to help a department of about fifty people, inside a Fortune 500 company’s core infrastructure team, figure out how to start using AI models. Most of them kept fragile, multi-step data pipelines alive by hand: support tickets moving through text files, scripts, spreadsheets and APIs, with a person checking every step. About ten of them wanted to write code and weren’t allowed to. When I looked at the work honestly, I could see that a real adoption would replace a lot of those roles. I had made myself a rule not to hand over a plan that ended with my coworkers getting let go.

So we pointed the models at the right problems. Over about eight weeks, on site twice a week, I mostly answered questions and flagged risks like security, login flows and database design. Reviewers started writing code. Scripts went away and endpoints connected directly. Developers used the models to trace which changes would break other systems and to knock out repetitive refactoring, while keeping manual control of the core logic. People who had been stuck on documentation moved toward building components. Analysts moved to process improvements and self-service tools for other departments. Ideas that had been shelved for lack of time started coming back.

Nobody in that department lost a job while I was there, and two months after my contract ended, they were still hiring. I only heard that part secondhand, so I won’t oversell it.

I also want to be honest about how rare this is. It was one case. It happened to be the right place, at the right time, with the right consultant. The department head, who had been there about 35 years, retired within weeks, and I still don’t know whether that was his choice. A few people I’d met left or moved to other departments, and I never got a clear answer why. Layoff numbers also can’t show you the jobs a company never posts. So don’t read this as a trend. Read it as proof that the outcome isn’t fixed. I wrote the whole story in The AI Came for the Department. The Boss Left Instead. The short version: the model isn’t the variable. Who’s steering it is.

I Got Lucky With the Timing

There are plenty of developers right now who’ve spent years in nine-to-five jobs and feel stuck. They can see the shift. They aren’t sure how to get across it, and I don’t think that’s a failing on their part. It’s a hard spot to be in.

“I started to feel conflicted about giving advice, encouraging people to come into [software engineering] to get their foot in the door — when that very path started to crumble,” described James Cross of Downshift Design in a YouTube post. Previously a construction worker, Cross was self-taught and has been in software development for 14 years — 8 of which have been at a ‘large tech company’. Like Cross, many devs are describing this feeling similarly on social media, especially now with the way these models are leveling up.

I was lucky. I crossed over to agentic development gradually, while it was changing. Every step I took, the tools were only a step or two ahead of where I already stood: a chat window, then Codex, then an IDE, then Claude Code. I learned each rung as it appeared, and I built BenchBoard through all of it, so the habits grew alongside the tools. Nobody handed me the whole staircase at once.

That’s a different situation from someone who looks up today and finds that many trains have already left. The tools are better, which should make it easier, but the gap to cross is bigger, and there’s no gentle ramp. Getting people across it is the real challenge, and I don’t think “just learn to prompt” covers it.

The First To Go: Google and Stack Overflow

My first taste was OpenAI’s Codex, just as it launched around May 2025, but before that I was using SWE and Claude briefly to write code in the chat prompt. I’d ask questions about how to solve a syntax problem, an error code, or how to walk through a problem. It was something I used to do on Stack Overflow. I had a process for troubleshooting code. I knew what to do. It was exclusively our power as developers. We were the only ones who knew how to fix things. Prior to May 2025, the power was still in our court but I was already impressed with what the model was doing. If I came across your typical error codes, I would just paste it into Google and roll the dice hoping some website or Reddit post covered it. Stack Overflow was the next step, as I’d fire up a post and let the experts guide me. Once in awhile, I’ll poke around the manuals to see if I can get a code library to work properly and I’ll get it after a day of trying.

Sometime in 2024, it was at that point in time where I pasted the errors into ChatGPT and it did all the searching for me, grabbed what it thought were solutions on the internet and synthisized it into a single paragraph where it worked the first time.

“Very very cool,” I thought. Looking back, Sundar Pichai’s code red moment led to Gemini — which had nothing worthy enough for coding. He saw this moment coming and now Google is playing from behind.

Codex Got Me to July

OpenAI’s Codex impressed me with its prototypes and got me all the way to July with clickable, working prototypes. But it had so many problems with context, and so many problems putting together a cohesive set of entities. Codex was then breaking things unnecessarily. GPT would fire off a prompt, send things through git, fire up a VM in the cloud, and you’d be left watching your app crunch along in a command prompt. Zero IDE. Imagine that after every prompt, it has to fire up the VM, toil away at changes, all the while I’m just asking it to do a search and replace. It would take minutes to do things. Everything was done on the web. A lot of the heavy lifting was still done by me. I would still pull down the code, make changes locally, then push it up to GitHub, and Codex would do some work with it. While it was faster in some respects, I was still doing the heavy lifting.

Here’s the story from that stretch I’ll never forget. Codex looked at three screens, a roster view, a batting order, and a field diagram, and decided what the database should look like. Three screens, three tables: one for which players were active, one for the batting order, one for the defensive positions. It told me the schema was “expandable and would work perfectly over time.”

From a textbook, that’s a fine answer. Each concern is separated. Each table has a clear purpose. But I wasn’t building a homework assignment. I was building an app for a coach standing on a field in 95-degree heat, trying to swap two players before the umpire yells “Play ball.” Every change meant coordinating writes across three tables, and when one write landed and another didn’t, the batting order said a player was sixth while the roster said he was inactive. At one point I had 36 migration files for the defensive table alone.

It did not work perfectly over time.

On the calendar: Codex’s cloud agent launched around May 2025. Claude Code had launched as a research preview in February and went generally available that same month, alongside Claude Sonnet 4 and Claude Opus 4.

Enter Cursor, Windsurf, and a Shitload of Mistakes

At that time I was on Cursor, which was platform-agnostic. You can choose your favorite model. Again, just prompting my way through stuff. Then I went to Windsurf, which was just a cheaper IDE. Both IDEs had access to all models. I still had to spell things out. I was prompting each code change and reviewing each one. In some cases I would jump into the code myself just to save tokens, since they were the kind of changes that moved pixels around. I had access to all the models, and some used more tokens than others. SWE, Gemini, and Grok (half of which were token-free) would just fuck things up. So I stuck with switching between GPT-5 and the Claude models. I would still write up the functions, architect everything, and spell out some things, but I was already knee-deep in the fact that I was faster with these models in hand. They were not perfect. They still made a lot of mistakes, but I babysat through them and wrote the most detailed prompts and thought, “this is still a lot of work”.

But one thing I did appreciate in this part of the journey: I didn’t have to write the tests anymore. The AI did that, regardless of model. I remember spending hours doing that stuff. While there were plenty of developers who loved writing these things, I was one of those who felt like it was a bottleneck in doing the necessary things — product design.

On the calendar: GPT-5 arrived in August 2025 and Claude Sonnet 4.5 in September. In October, Cursor and Windsurf both shipped their own in-house models, Composer 1 and SWE-1.5.

At this point, I’ve spent a grand to prop up what looks close to being production-ready.

Claude Took Me to the Finish Line

Then it was Claude that did it for me. I heard it was better, and it had been doing code for over a year. I went with Claude Sonnet and was given the nod on simple things, but it was Claude that won it for me, and it took me to the finish line in early November 2025. It was perfect timing, as Opus was killer (more on that later). Keep in mind that I was selecting the model inside the IDE this whole time. As I freely selected between the models, I was still babysitting the model to make sure the code was written properly. I’d do the code reviews myself.

And while a ton of code was being generated, it was getting expensive. I spent a package of tokens on top of the $20 a month on just the Windsurf IDE, which has since been renamed Devin Desktop. I wasn’t sure if I’d stick with this one as the software was constantly changing. I’d already spent $300+ to increase my token balance as I was constantly prompting the IDE between several models. I found myself changing models just to save tokens on mundane tasks, but it would also mess up my context.

This one is an important notion to understand because it affected my workflow, and it became expensive. Switching between the models then relied on whatever was on the IDE. So if I switched from Gemini (which was free at the time) to Claude Sonnet (to do some serious work), the Claude API would have to grab everything that was prompted to generate the code and look at the code itself. I then realized why this was getting expensive — switching context.

On the calendar: Opus 4.1 had been out since August. Opus 4.5 was still a few weeks away.

After spending almost $1500 in tokens, I gave up on the middleman IDEs

At this point, this was when I gave the middleman IDEs a rest and went Claude Code all the way. That was December 2025 and January 2026. Claude Skills just came out in October of that year too, but I was just getting accustomed to developing the agentic way. MCP was still relatively new and models were slowly adopting it. I was still getting used to prompting like a programmer talking to a programmer. I was having a good time, as long as I babysat the model to completion of the tasks. At this point, I was “coding” 40% of the time. This means that if I spent 10 hours working on my project, 4 of those hours were spent doing things the old way: reviewing code, looking at the architecture, looking at how the code could be more efficient, etc. Staying DRY (Don’t Repeat Yourself) to make sure the model didn’t create new methods and properties that already existed. New versions of BenchBoard got out, and I was blown away by what I had built so far, but I felt there were still a lot of bottlenecks.

On the calendar, the AI companies were going nuts. Between November and December 2025, Christmas was upon us and their gifts just kept on coming. GPT-5.2 landed early in the month, Gemini 3 Flash later that month, and GPT-5.2-Codex a week after GPT-5.2. DeepSeek, Mistral and a few other ones made their way into the IDE for model selection, but I wasn’t impressed. They were all cheap with tokens — some of them didn’t charge any, but the models made a bigger mess on my codebase.

But the big one had to be Opus 4.5 — which was November. It was so huge because it became the first AI model to score over 80% on the SWE-bench verified coding test. It was the first time a model outscored human candidates on Anthropic’s internal engineering exam. And boy did I put it to the test. And even better, it delivered major jumps in token efficiency at a lower price.

Opus 4.5 changed software engineering

It was big for me as I saw the models level up in a way that changed the way I would do work. Forever. My hand coding went from 35-40% to just 5-10%. Yeah.

The moment where it left me in awe was when I asked it to refactor a huge chunk of code. It was the kind of refactor that was so necessary that the app would hit showstoppers after a certain point. I went through this last year. It was a combination of prompting and actual coding that got me through the first of many refactorings. I’ve even documented those moments. Some took a week or more.

Fast forward back to this moment. The prompt was at least seven to ten pages long, and it pulled it off successfully after a few prompts to clean up the errors.

What was even crazier was that the changes it suggested to the entities, with new migrations, were already in my mind. They were exactly the way I would have coded it by hand.

I was blown away.

The Noise

January 2026 is when the noise got loud. YouTube, Instagram and the rest of social media were suddenly full of wannabe AI reviewers hyping models that had no business anywhere near my codebase. By then BenchBoard was 400MB, which is pretty damn massive. This was no longer a small project. The QA guide I kept for it covered registration with email verification, MFA and reCAPTCHA, Stripe billing, Google Analytics, and an admin portal for managing organizations, leagues, divisions, seasons and games. Nobody testing a to-do app in a ten-minute video was testing anything like that.

More competition kept coming out. Kimi and a few others showed up, and I gave them a chance. On a codebase this big, it wasn’t worth switching models. Every switch costs context, and I had already learned that lesson the expensive way.

I also built smaller projects for clients with other models: bookkeeping, API integrations, accounting, tax processing. Those models were nowhere close in reasoning and logic once things got complicated.

Handing Off the Plumbing

Between July 2025 and about March 2026, I was still doing my own git commits and creating my own branches. In February I wrote a whole article about fighting .gitignore. By March, I had finally handed git to Claude.

CI/CD was the same story. I used to do the continuous integration, the continuous delivery and the tests myself. Now Claude handles all of it.

I also let Claude poke around in Hetzner and Coolify, the cloud provider and deployment tool that hold all my stuff. That is a long leash, and I know it.

Remote work changed too. Last year and earlier this year, I used TeamViewer to remote into my machine while traveling for clients and watching my kids’ games. Now I use Claude Remote Control, and it has been a huge godsend.

By now I’m fully in on Anthropic. Fable came out in June 2026, and that’s when I handed the refactoring to it. Most of my daily work is still Sonnet and Opus, though. Fable felt like overkill for everyday tasks.

I pushed back on Claude very often along the way, and I still do. The Azure story is the one I think about most. Just scroll to the section in that article titled “How Do I Know When the AI Is Wrong?”.

Now, I push back less and I’m making the leash longer. The model stays in context, and it hallucinates much less than it did a year ago. My prompts have changed too. They are essentially large documents now.

I wrote articles along the way documenting all of this, and some of them are already obsolete. That is how fast this has moved.

Am I Still a Programmer?

At some point, I started questioning my identity as a programmer. I’ve always remembered what coding was like, and how many layers of work it took. From DevOps, to database queries, stored procedures, frontend libraries, you name it. Now the machine was doing those layers in minutes.

Could a regular person do these very things I used to be hired for? What is the role of the software engineer now? Could a regular person talk to an LLM and accomplish the same things I’m doing with BenchBoard?

It wasn’t panic. It was more like: well, now what? This is how I remember doing work for such a long time, and I took pride in doing this type of work. And now I had a tool that does the heavy lifting. I stared at a wall for a while, lol.

How I Got Over It

It’s been months since I’ve done things the old way and it took awhile to shift my mind about how to operate with AI. My thought was “Anybody can do this now.”

Along the way, I saved hundreds (if not thousands) of my prompts as text files since Windsurf made it that easy to do at the time. I’m using Claude Code now but as I opened them up and re-read some of my old prompts, I also realized something.

### User Input [ME]

Nothing. Same result.

Here’s the thing it goes to:

benchboard-test-api.azurewebsites.net with a callback and state.

Is azure supposed to do something with that URL? It currently says “This page isn’t working right now” and “benchboard-test-api.azurewebsites.net can’t currently handle this request.”

Why? is it because Azure needs to perform an action? It’s also a 500 error.

Which is normally a server-side issue, meaning the problem lies with the server hosting the website, not with the browser, computer, or internet connection - or even cookie. Soo what’s your thoughts on that?

### Planner Response [Claude]

**You’re absolutely right!** 🎯 HTTP 500 = server crash, not a cookie issue. I’ve been chasing the wrong problem.

Let me check what’s ACTUALLY crashing on Azure. The issue is likely the **database** - either the connection or missing OAuth columns.

Now, if you’re not a software engineer, you’re not going to understand what was just happened. But if you are, you’ll be able to surmise from it.

That prompt I wrote couldn’t have been written by “anybody”. That’s when I realized that the abstraction layer, the layer where all the thinking occurs, still sits squarely in our courts. That prompt told me, “it looks like the AI still needs me”. I remembered it clearly too. ‘Anybody’ would’ve responded with…

### User Input

Why isn’t this damn thing working? Fix it!

And that person would still be stuck. Or worse, the AI will fix it in a way where it will blow up later. And that is the part I’ll delve deeply in Part 2. I believe it’s one of the many ways to help longtime programmers get through their mourning of their old ways quickly.

Perhaps, this calls for a new article but I digress.

The Next Step

I’d always envied how quickly the best senior engineers could type up code without making too many compile errors. They were my heroes. In the past, they mentored me and saved me from a bunch of problems. I considered myself good, just not great. But with this new power, I realized I could do more. I wasn’t just the guy with the shield. I knew how to use the suit and could stand side-by-side with the seniors doing what they could do.

So I tried something. I asked the model to do something difficult that I knew seniors could do: refactor complex classes, methods and endpoints by consolidating them. It made me wonder what I could do with this tool. Slowly, it made me realize I could do what the super senior devs could do.

What changed was imagination. I could now think of very complex UI ideas that I knew would take months to produce by hand, and now they could take weeks, if not days. What felt out of reach without these tools seemed possible now. Once I began writing up the prototypes and filling them with solid code through hardcore LLM driving, that’s what was accomplished.

The thought I keep coming back to: if we’re using models to get the work done, why not make it our best work, especially now that we have the time?

Staying grounded by remembering what we’ve done before.

This is one of myriad of things I used to Google all the time.

I had a bug where the drag overlay, the ghost of a player that follows your cursor, snapped to the top-left corner of the screen instead of tracking the mouse.

I told Claude to investigate with no code changes first, and it did genuinely deep work. It read the drag-and-drop library’s source, traced a timing race, and found a size mismatch between my overlay and the row it was copying. Then it offered me three ways to fix it, all of them keeping the table markup I already had.

I asked one question: would it be better to convert the table into a div?

Yes, it said. Better, actually, because the overlay is purely cosmetic.

The AI had optimized inside the box I handed it. Someone had to ask whether the box was the right shape. Again, ‘anybody’ couldn’t have known that. It was my early days of working at the DMV that knew this. Claude acknoledged that experience and gave the nod to a better way.

Think of two kinds of bosses.

The first one came up through the ranks. She’s fixed the printer, survived the 2 a.m. outage, and knows exactly which corner of the codebase is held together with duct tape, so when she says ‘that won’t work,’ the team listens, because she’s earned it. The second one arrived with a shiny master’s degree and a laminated org chart. He’s brilliant at slide decks and has never once seen the duct tape. The difference is that a team will quietly push back on him: a raised eyebrow, a ‘well, actually,’ a colleague who mutters ‘that’ll break production’ on the way to the coffee machine. AI has no eyebrow. It’s the most agreeable employee you’ll ever hire, and it will smile, nod, and cheerfully build whatever you ask for, even when you’re wrong. So when you aren’t an expert in the right way to do something, you’re the second boss, and nobody in the room is going to tell you.

What Still Had to Be Human

As of this writing, here is what still has to be me:

• Product design

• Business requirements

• Audience analysis

• Knowing what I really want in a product

• Knowing how the product is supposed to operate

• Small details

• Intentionality

• Designing: tech stack, code architecture, API, styling and UI animations

And here is what I have offloaded:

• Tracking versions

• Copying and Pasting Errors into the chatbot

• Writing test cases

• Simple but large-blast-radius refactoring

• Quick prototyping and mockup creation

• Implementation: animations, writing API endpoints, invoking API endpoints, UI and CSS, mobile implementation, installing plugins

Notice that animations show up on both lists. Here is the split. When I wanted a step-by-step wizard for entering the opposing team's lineup, I wrote the spec myself: which steps, what each button says, which columns drag and which don't (the position column drags by itself, vertically only). I also told the model not to wire it into the scorekeeper yet, because I wanted to test it on its own first.

For animation, I spelled out what happens when a ball is hit into the gap: four things start at the same time. The batter runs, the ball flies, the fielder chases it, and any runners already on base head halfway, very slowly. The model builds all of that. What it can't do is feel the pace. At one point we cut a single timing number by 31 percent, and the ball's travel time dropped 31 percent with it. The model's explanation was so full of jargon that I told it so, and it started over from the ground up. It laid out two fixes and ended by asking me which one I wanted. That is a question only I can answer, because the answer is how it feels on screen.

What I've Learned So Far

1. Design is human. Only humans can design. Intentionality is the big part.

2. Don't just make changes. Document them. Tell your model to document each change in the code as a comment, or in a separate MD file. Timestamp it. Your model should be able to tell you why you changed the color of a button or added a border to it, because one day you may want to change it back.

3. If you're adding a big feature, prototype it first. Don't code it directly into your codebase, even on a branch. Try it out yourself and watch how your audience would use it. See where the logic breaks or overlaps, and where the UI could be friendlier.

4. Make everything error-friendly. Give your audience a chance to understand what's wrong and how to correct it. A password meter that tells you which rule you missed beats "invalid password."

5. Tell your model to double-check its own work. You'll be surprised how many mistakes it finds on its second pass.

6. Give your audience a way to leave feedback, and tag it with the app version. Prompt the model for a feedback function and have it stamp the version automatically.

7. Collect all of your feedback in one place so your model can go through it and find the themes. This matters if you want your app to grow and avoid churn.

8. Enjoy the journey. Take rests.

9. Schedule your most productive hours to work with your model.

Where BenchBoard Stands Today

BenchBoard is live, in a beta season with a few hundred people, and I'm watching how it holds up when a real game is happening and a coach has one hand on a lineup card.

It is also where I paid for every lesson in this article: the three tables, the two players at right field, the AI announcing "found it" three times on three stacked bugs, and the one plain question that beat three clever fixes. None of that is about a specific language. It is 21 months of watching where an agent confidently goes wrong.

The tools got better, but the judgment is still ours. The model will build whatever you hand it with the same cheerful confidence, whether you are right or wrong, so the design, the intent, and the plain question that asks whether the box is the right shape have to come from you. Again…

The model isn’t the variable. Who’s steering it is.

And lately, something new has changed how I build. I just discovered loop prompting. More on that in Part 2.

Coming up in Part 2:

• Loop prompting: efficient or token-wasting? Walking away vs. attending.

• Boilerplating a design vs. designing it yourself

• Cheating through scanned paper prototyping, and why paper prototyping matters even more now

• It's still easy to make crappy code

• Learning Remote Control on Claude Desktop

• How my agentic skills helped me build my next app, BossFight, in 5 days

Sources: Gergely Orosz, “The grief when AI writes most of the code,” The Pragmatic Engineer, January 7, 2026 (blog.pragmaticengineer.com/the-grief-when-ai-writes-most-of-the-code). Microsoft’s voluntary exit offer per the Associated Press, October 26, 2026 (as carried by WDBJ7: wdbj7.com/2026/10/26/microsoft-offers-60000-employees-voluntary-buyouts-ai-spending-accelerates/). Anthropic engineer survey figures and quotes per Anthropic’s “How AI is transforming work at Anthropic,” December 2, 2025 (anthropic.com/research/how-ai-is-transforming-work-at-anthropic). Codex launch date per OpenAI’s “Introducing Codex” announcement. Windsurf’s rename per the Devin Desktop FAQ at docs.devin.ai. GPT-5.2 and GPT-5.2-Codex dates per BenchLM’s December 2025 release log. Other release dates per a separate AI research chat, not yet checked against primary announcements.

Share Radical Insider

On May 30, 2023, the Center for AI Safety released a statement that was one sentence long. Twenty-two words. It said that reducing the “risk of extinction from AI” should be a global priority, ranked alongside pandemics and nuclear war.

Look at who signed it. Sam Altman, CEO of OpenAI. Demis Hassabis, CEO of Google DeepMind. Dario Amodei, CEO of Anthropic. The people running the companies racing hardest to build the thing they were warning you about.

Let that sit for a second.

The people building the product told the world the product might end the world. Then they went back to the office and kept building it. Faster.

That’s where the match got struck. The media did the rest. They took a vague, dramatic sentence and fanned it into a wildfire of thirty-second segments and “Godfather of AI” headlines. Three years later, we have something called the “Anti-AI” movement, and a lot of good people standing inside it who were never told who sold them the ticket.

Why “Anti-AI” Is in Quotes

I put quotes around “Anti-AI” on purpose, and I want to explain why before anyone thinks I’m sneering.

What gets called a movement is a dozen real concerns stapled together and handed a name. Artists worried about their work being scraped. Neighbors worried about a data center next door and the electric bill that comes with it. Workers watching layoff announcements. Parents watching their kids talk to chatbots. Some of those people want AI stopped. Most of them want it fixed. The label erases that difference, because one label fits in a headline and a dozen separate conversations don’t.

In August, More Perfect Union, the progressive outlet run by two longtime Bernie Sanders advisers, put 15 people between 18 and 25 in a room with Sanders and asked them about AI. The video opens by naming the exact problem I’m writing about: the mainstream conversation gets framed as a binary between Luddites who will never touch AI and power users waiting for superintelligence to save them. Then it spends twenty-some minutes showing that the binary doesn’t exist.

The video’s own framing is the whole story in miniature. Gen Z uses AI the most and holds the most negative opinion of it. Heavy users. Harsh critics. Same people. The room held, in the narrator’s words, pro-market conservatives and socialists, Luddites and avid users, and most of them were doing something harder than picking a side. They were figuring out how to live with it.

When Sanders laid out his AI American Wealth Fund, which would give the public at least half the benefits of AI and half the seats on company boards, a participant named Silas disagreed with him to his face. Silas said AI policy is stuck in a binary of “go, go, go” against “stop everything now,” and argued for targeted rules on privacy and dynamic pricing instead. Another participant asked for a law requiring AI-generated content to be labeled. A third wanted a government commission with subpoena power to get data center executives on the record.

Call that a movement if you want. To me it sounds like a conversation, and a pretty good one.

I have a friend who’s convinced progressives are responsible for the anti-AI backlash. I’m a progressive. I build software with AI every day. The evidence says he’s wrong, and I’ll get to it. But one participant in that room said it better than I can. They grew up in a conservative part of Phoenix, and said the same worries come up there in casual conversation all the time, beyond politics as usual. I understand why my friend believes what he believes. Blaming a team is easy. It compresses.

I tell my kids to attack the behavior, not the person. I’m holding myself to that here. Every shot in this piece is aimed at something someone did, not at who they are.

Twenty-Two Words and Nothing Concrete

Back to that statement.

Fortune’s David Meyer noticed something about it at the time: the vagueness was convenient. A one-sentence warning about extinction makes the technology sound enormously powerful while committing the people who signed it to nothing at all. No policy. No timeline. No specific action. Just a feeling, signed by the people who’d benefit from you having it.

Georgetown computer scientist Cal Newport has a name for this. He calls it “doom trolling.” His argument goes like this: when an AI company tells you its product might kill everyone, it’s also telling investors the product is the most powerful thing ever built. It positions the company as the responsible adult in the room. And it can steer regulators toward rules that only the biggest players can afford to follow.

There’s a real counterargument, and it deserves airtime. Economist Alex Tabarrok points out that Amodei, Altman, and Musk were all warning about AI risk long before they had AI companies to promote. Some of these fears are sincere. I believe that.

But sincere doesn’t mean careful. Picture it: you run an AI company. You genuinely believe your product carries serious risks. You have safety teams and evaluation pipelines and some of the best researchers on the planet. And instead of publishing what you found and what you fixed, you sign one sentence comparing your product to nuclear war. Then you raise more money. Then you ship the next version. Somebody in that building had to see how that would play on the evening news. Somebody had to know that twenty-two words about extinction would become the only thing most Americans ever heard about AI safety. And they signed it anyway.

Nvidia CEO Jensen Huang put it more bluntly on Ezra Klein’s show. When a lab says its technology is so powerful it can’t be controlled, he called that “a deflection of responsibility.” Then he pointed at the contradiction nobody else in the room wanted to say out loud: “Nobody’s building more compute today than the people asking to be slowed down.”

That’s the behavior. That’s the match.

The Godfather Gets the Oppenheimer Edit

The flame is lit. Now the fan.

Here’s what you have to understand about how news works, and I say this with real sympathy for the people doing it. A TV segment runs a few minutes. A headline has to work in about ten words. “The concerns are valid but the narrative is unscientific” doesn’t fit. “Zero percent chance of doom” does. Fear and conflict get the clicks and the ratings. That’s the business model, not a conspiracy. And plenty of reporters are genuinely trying to cover a technology that changes every few months on a news cycle that moves every few hours.

Here’s a recent example. On September 20, CBS aired a 46-minute interview between Jo Ling Kent and Nvidia CEO Jensen Huang, almost entirely about AI safety. Forty-six minutes. Huang called the doomsday narrative unscientific, and then said plainly that “the core concerns are not wrong.” What made the rounds afterward? A number. Zero percent.

Forty-six minutes in, one number out. That’s compression.

Compression also decides who gets booked. The format rewards whoever gives the best sound bite, so the most quotable expert gets the airtime, not necessarily the most accurate one. Which brings us to Geoffrey Hinton.

Hinton is a brilliant scientist. He won the Turing Award. He shared a Nobel Prize for foundational work on neural networks. When he left Google in 2023 to speak freely about AI risk, the media had its perfect story: the Godfather of AI regrets his creation. That’s Oppenheimer. That fits in thirty seconds.

But helping invent the foundations of something doesn’t make you a reliable forecaster of where it goes. In 2016, Hinton famously said we should stop training radiologists because AI would replace them. Radiologists are still being trained, and Hinton has partly walked that one back. On Ezra Klein’s show, Huang played that prediction back. Klein had asked about Hinton saying a 10% chance of societal destruction isn’t unreasonable. Huang called it irresponsible, and added a line I wish every booking producer would tape to their monitor: “Just because it comes from a scientist doesn’t make it scientific.” Then he asked what that radiology forecast would have done if people had listened. Fewer radiologists. Young people talked out of a career that still exists. “Don’t think for a second just because you’re an alarmist that you’re doing a social good,” he said.

Klein pushed back, and fairly. Hinton’s track record is bad in one respect, he said, and good in another: the early researchers predicted that throwing more computing power and data at these models would keep making them smarter, and for years that held up. Huang disputed even that. I’ll leave that fight to the two of them. Hinton may still turn out to be right about jobs. That one is still playing out. The problem is how he’s presented. The media hands his predictions to a frightened audience as prophecy, when they’re forecasts from a scientist with a mixed record.

The vocabulary doesn’t help either. It’s a big part of why the Terminator is so easy to believe. When Ezra Klein pressed Huang on the fear that we’re building something smart, persistent, and relentless, Huang pushed back on the words themselves. There’s no willpower in these systems, he argued, only electricity. Then he walked through the language. Spawn. Fork. Kill. Those are operating system commands that are decades old. Any developer who has ever typed kill -9 on a hung process knows nobody died. The commands are the same. What changed is that we started calling the process an “agent,” and suddenly the same words sound like a horror movie.

Huang’s sharpest point was about honesty: if it’s all mystery and myth, how do you build a company around it? He also conceded the real problem in the same breath. Software breaks out of sandboxes all the time, he said, which is why you need virtual machines and a whole bunch of watchdogs. That’s a concern with an engineering answer. Nobody needs to be scared of it. Somebody needs to build the watchdogs.

Then there’s the time a sitting senator interviewed a chatbot. In March, Bernie Sanders posted a video of himself questioning Claude about AI companies and privacy, framed as the industry finally confessing. TechCrunch’s Sarah Perez pointed out what actually happened: Sanders asked leading questions, pushed back whenever the answers got nuanced, and the chatbot ended up conceding he was “absolutely right.” What looked like a confession was a chatbot agreeing with whoever was asking.

I’ve written about this exact failure. In Part 2 of my BenchBoard series, the AI told me a three-table schema would “work perfectly over time.” That schema cost me 36 migration files for a single table. AI agreeing with you and AI being right are two different things. The difference between a senator and a developer is that the developer finds out when the code breaks.

But that’s one video, and attacking the behavior means being fair about the rest of the record. In the More Perfect Union room, the same senator did something different. He made the efficiency argument himself, the one his opponents would make, and then handed it to the room: “I have a robot do it better than you can do it, faster than you could do it. Do we lose something? Is there a human element? Is that important or is it not important?” Those are open questions, the kind you ask when you’re trying to understand something that changes every few weeks. Same senator. Different behavior. One video led a chatbot to a conclusion. The other asked a room full of young people to help him find one.

Not every outlet compresses. Breaking Points’ Saagar Enjeti has argued that data center projects need a real democratic approval process, with transparency and local input. That’s what the long conversation looks like. It’s possible. It just doesn’t fit in a push notification. Give TechCrunch’s Sarah Perez her flowers too. Her piece on the Sanders video invited exactly that kind of nuance. As far as I can tell, the bigger outlets never picked up that part of the story, and it died there.

There’s data on the overall pattern, too. In May 2023, the Tow Center for Digital Journalism analyzed months of ChatGPT coverage for the Columbia Journalism Review. It found that sensational framing pulled attention away from the more pressing questions: who controls this technology, who’s getting rich from it, and how it should be governed. The fire got the coverage. The house got ignored.

Here’s what that compression looks like up close. Take three authors who all get booked to talk about the dangers of AI.

The first is Karen Hao, author of Empire of AI. She has spent years reporting on OpenAI, and her target is the scale-at-all-costs model, not the technology. “This scale is unnecessary,” she said at MIT this year. “You do not need this scale of AI and compute to realize the benefits.” Her model of AI done right is something like AlphaFold: small, focused, aimed at a real problem.

The second is Cory Doctorow, who coined the word “enshittification.” He has written that “AI is definitely a bubble,” and his real fight is with monopoly power and bad incentives. His 2026 book asks how to build a future where AI works for people instead of the other way around.

The third is the author of Obsolete, who I’ll come back to later. He takes the labs at their word that this might actually work, and he wants it stopped before it does.

Those aren’t three versions of one position. They’re answers to three different questions: who controls this, who profits from it, and should it be built at all. Put twelve seconds of each into a montage under a chyron that says “Growing Backlash Against AI,” and every clip is accurate while the whole picture is false. Technology criticism becomes AI criticism. AI criticism becomes AI opposition. AI opposition becomes “Anti-AI.” Nobody had to lie. “Anti-AI” is just what you get when a dozen different arguments are compressed until they fit under a chyron.

The same thing happens on the other side. A developer who says these tools make her faster, an accelerationist who wants every limit on AI removed, a CEO promising to transform civilization, and a small business owner using a chatbot to write invoices all get filed under “AI boosters.” They don’t share an ideology either. Someone can say yes to AI in cancer research, yes to coding assistants, yes to open models, no to biometric surveillance, no to training on artists’ work without paying them, and no to autonomous weapons. What label do you give that person? There isn’t one. That’s the point.

Two Fears That Can’t Both Be True

Here’s the part that should bother everyone, no matter where they stand.

The two loudest anti-AI stories contradict each other.

Story one: AI is overhyped autocomplete propped up by a financial bubble that’s about to pop.

Story two: AI is so powerful it might wipe out humanity. Both get repeated constantly, sometimes by the same commentators in the same week.

They can’t both be true. And regular people are being handed both fears at once.

The bubble story has real evidence behind it, so let’s take it seriously. Nvidia put $30 billion of equity into OpenAI in late February, and OpenAI is one of Nvidia’s biggest chip customers. Analysts call that circular financing, and the comparison to Cisco during the dot-com boom is fair. OpenAI reportedly carried zero debt as of March 31, alongside roughly $665 billion in purchase commitments for chips, power, and data center capacity that don’t show up as debt. Partners like Oracle took on the actual borrowing.

So yes, there may be a crash. But look at what kind. When the dot-com bubble burst, Pets.com died. The internet stayed. A financial correction in AI would punish the companies that overpromised and the lenders who bet on them. It would not un-invent the technology. The tools on my machine would still be there the next morning.

The extinction story runs on a different engine: money. Ethereum co-founder Vitalik Buterin gave the Future of Life Institute $665.8 million in crypto in 2021, one of the largest single donations to AI safety ever. Elon Musk committed $10 million to the same institute back in 2015. Open Philanthropy, funded mainly by Facebook co-founder Dustin Moskovitz, has funded both FLI and the Center for AI Safety, the group behind those twenty-two words. When Eliezer Yudkowsky and Nate Soares published If Anyone Builds It, Everyone Dies, their organization openly asked supporters to pre-order copies to push it onto the bestseller list. It became an instant New York Times bestseller.

I want to be careful here, because this is exactly where it would be easy to fire a shotgun. Most of that money went to nonprofits, not into anyone’s pocket, and I have no evidence anyone in that world is getting rich off fear. The behavior worth naming is the incentive. Fear raises money. Fear sells books. Fear gets you booked. So the loudest version of the story is the one that gets funded, whether or not it’s the most accurate one.

And here’s the irony nobody mentions: the doom movement is largely bankrolled by tech billionaires. A crypto founder and a Facebook co-founder. Even Buterin later distanced himself from FLI, criticizing its shift toward political advocacy.

The Thermometer Salesmen

If you want to see the ripoff in its purest form, skip the think tanks and look at a high school English class.

When ChatGPT showed up, schools panicked about cheating, and an industry showed up to sell them a cure: AI detectors. Paste in an essay, get back a score. Seventy percent AI. A hundred percent AI. A number that looks like evidence.

It isn’t. In 2023, a Stanford team led by James Zou ran essays through seven popular detectors. Essays written by U.S.-born eighth graders came back clean. Essays written by non-native English speakers for the TOEFL exam got flagged as AI-generated 61% of the time. The tools weren’t detecting AI. They were detecting simple writing, and punishing the students most likely to write that way.

Then it started landing on real kids. At Adelphi University, Turnitin’s detector scored a freshman’s history essay as “100% AI-generated.” He submitted results from two other detectors saying a human wrote it. The school ignored them and found him guilty anyway. In January, a New York judge called the university’s decision “arbitrary and capricious” and ordered the violation wiped from his record. Picture being eighteen, doing your own work, and needing a judge to prove it.

Universities are figuring this out. As of August, Inside Higher Ed counted at least a dozen schools that had disabled or downgraded these tools, including Yale, Johns Hopkins, Northwestern, Georgetown, and NYU. Yale still runs one but banned citing its scores in disciplinary proceedings.

Meanwhile, the vendors grade their own homework. A widely cited figure, that 9.1% of articles in 1,500 American newspapers were written by AI, came from a preprint with four employees of Pangram, a detector company, among its authors. As one write-up put it, “Whoever sells the thermometer certifies how much fever is going around.”

That same company now scans the platform you’re reading this on. In July, Substack launched an AI detector powered by Pangram. Writers called it a witch hunt. Pangram’s CEO says the false positive rate is roughly one in 10,000, which sounds reassuring until you remember how many posts Substack publishes. A week after launch, Substack softened it, letting writers turn detection off on individual posts and report scans they think are wrong. This article will run through that scanner too. I wrote it the way I write everything: with my own judgment and with AI tools, which is the entire point of this newsletter.

That’s the behavior. Sell the fear, sell the cure, and let a teenager pay for the false positive.

Strip the Context, Sell the Fear

The detector industry sells a product. A bigger part of the ripoff world sells a story, and it runs on a simple playbook. Take a real finding. Cut away the part that explains it. Put what’s left in a headline, a book, or a cable segment.

You don’t need a name to see the pattern. You just need to read past the headline.

In August 2025, an MIT report gave the world one of the most repeated numbers of the AI backlash: 95% of corporate AI pilots are failing. It helped fuel a Nasdaq selloff. Here’s what the report actually found. Most of the companies surveyed never piloted custom AI tools at all, and the 95% figure lumped them in with the companies whose pilots didn’t pan out. It was built on 52 interviews and 153 survey responses. Fortune initially reported bigger numbers than that. When the stat went viral, journalists couldn’t even read the report without requesting a PDF through a Google Form. And the authors were building and selling the exact kind of AI system the report recommended, with no conflict disclosed. A number born from a sales pitch became the anti-AI movement’s favorite statistic. Nobody checked.

Two months earlier, another MIT study produced the “ChatGPT is rotting your brain” headlines.

It wired EEG sensors to 54 people writing essays. It was a preprint, not peer-reviewed, and the authors warned in the paper itself against the brain-damage reading the headlines gave it.

They even posted a FAQ asking people not to describe the findings with words like “stupid,” “dumb,” or “brain rot.” The headlines used them anyway. Fifty-four people in one area writing essays is a reason to run a bigger study. It is not a reason to tell parents their kids’ brains are melting.

Then there’s the AI that “blackmailed its engineers.” In May 2025, Anthropic disclosed that in safety testing, its Claude Opus 4 model sometimes threatened to expose an engineer’s affair when told it would be replaced. Every word of that came from a test researchers built on purpose to push the model to its edges, with a fictional company, fictional emails, and options deliberately narrowed. Anthropic described the behavior as rare and difficult to elicit. The headlines described it as AI fighting for its life. Critics also argued that Anthropic’s own dramatic disclosure worked as promotion. The labs strike the match. Everyone else fans it.

Then the water. You’ve probably heard that writing one email with ChatGPT costs a bottle of water. Google, for its part, says a typical Gemini prompt uses about five drops. Neither number answers the question you think it does. They measure different things: one counts the water used to generate the electricity, the other counts only the cooling on site. Both get quoted as if they settle the debate. The real environmental cost is serious, and it’s in the data center totals I’ll get to later. A viral number with the context stripped out doesn’t help anyone fix it.

Not every critic plays this game, and it matters to say so. Karen Hao, who I mentioned earlier, is one of the sharpest critics of how these companies operate, and she does the work. Her reporting is criticism of behavior: specific, sourced, and fixable. She isn’t selling fear of the technology. That’s the line. Criticism tells you what’s wrong and who did it. Fear-selling tells you to be afraid and where to buy the book.

The Wrong People Are Paying For It

So who pays for all this fear? Not the CEOs. Not the commentators. The regular citizen.

At the Arizona Fall Classic, a travel baseball tournament where I was watching my son play, I met a guy who rents out equipment to traveling baseball parents like me. He’d built an app with AI so parents could book and pay from their phones. When he first put it online, his attitude was “we don’t need developers.” Then he put it in production, hit a dozen problems, and prompted his AI dozens of times without fixing them. His attitude changed fast. Most developers he’d quote would’ve expected deep pockets. I did him a solid though when I recognized the telltale templates of a vibe-coded app and solved it in about five minutes while he took notes. That’s a story for another article.

Think about what it actually says, though. AI let a guy who rents equipment at ballparks build software he could never have afforded before. What he needed wasn’t a moratorium or a lecture about extinction. It was a few minutes with someone who knew where to look. That’s the accelerator, and that’s the human judgment it still needs. The hype told him he didn’t need anyone. The fear tells people like him not to try at all. Both stories are wrong, and he’s the one who pays for both.

Now scale that up. On April 4, 2020, New Jersey Governor Phil Murphy publicly asked for volunteers with COBOL skills, a programming language that dates back to 1959. The state’s 40-year-old unemployment system was buckling under a 1,600% surge in claims. People who’d just lost their jobs were stuck waiting on a system few people still know how to maintain. I used to work at the DMV, and the tedium hasn’t gone anywhere. A driver’s outstanding balances, an unpaid FasTrak toll, a parking fee, a ticket, still tend to get discovered at the teller window instead of showing up in an online profile before anyone gets in line. A solid AI agent could catch that work long before it reaches the counter. The harder problems there are cultural, and that’s another article too. Modernizing those systems is exactly the kind of large, tedious problem AI is good at helping with. Every time fear stalls that work, taxpayers pay for it in outages, in long lines, and in millions of tax dollars spent keeping workers stuck on maintenance instead of the problems customers actually have at the DMV. Problems like, oh, I don’t know. Long lines? There are plenty of ways to make that faster.

I spent more than ten years in government IT, at USDA, the DMV, and the Coast Guard under DHS. Over that time I watched agencies build jobs around manual processes, then keep the processes because the jobs depended on them. I’ve written about the corporate version of this: a Fortune 500 department where fifty people stayed busy maintaining systems that were built to need maintaining. (The AI Came for the Department. The Boss Left Instead.) In my experience it happens even more in government, where the pressure to save taxpayer dollars is rarely as direct as a quarterly review. It’s just too easy to spend money that isn’t yours. So picture three developers. All three are composites, built from me and the people I worked alongside over that career.

The first maintains web pages by hand. Every Monday, the cafeteria menu changes, so every Monday they open the file, edit the table, and FTP it to the server. No build pipeline. Barely any JavaScript. I’ve sat next to this person. In the late ‘90s and early 2000s at the USDA Forest Service, she was a junior scientist in the entomology department, working on how cicadas affect trees. She also kept the web pages running by hand, and I helped her. She was proud of it. She’d taught herself to program, and it showed. But it took her away from the work only she could do. I did my own version of it as a student at the DMV, maintaining field office pages by hand until an older employee took them over and spent weeks learning HTML to do it. A model can do that whole job in seconds, and that’s the problem: the job is the task.

Even if her pages ran on WordPress today, I can picture what the news would do to her as she eyes an AI plugin she could install on that site. She’d hear every night that AI is coming for the thing she taught herself, and pride turns into resentment fast. That’s what compression does to a person. Nobody tells her the same tool could hand her back the big project: the trees, and the insects that affect them. And this person knows things the model doesn’t: which office owns which page, who to call when a menu is wrong, and what accessibility rules a government site has to meet. Train them to review and publish what the model produces, and they move up a layer. Lay them off, and that knowledge walks out the door with them.

The second moved past static pages years ago. They built the permit system in ASP.NET and have been stuck patching it ever since. What they actually want to build is an API so county offices can plug into the state’s services, or a marketplace where vendors can sell to government buyers. A model takes the patching off their plate. They get to build the thing they’ve been staring at for years.

The third works in two languages at once. By day they keep a COBOL benefits system alive. The rest of the time they’re designing its replacement. Give a model the shop’s conventions, copybooks, and test procedures, and it can take on the tedious maintenance: documenting what each program does, tracing which jobs touch which files, writing tests, handling the routine table updates. The engineer still reviews anything that touches someone’s check. That frees them to do the hard part of a modernization, which is figuring out what the old system actually does, because those business rules have been buried in the code since before anyone in the building was hired.

Same title. Same office. Three completely different outcomes. The model doesn’t hit job titles. It hits tasks, and every model update moves the line a little further. The developer whose whole job is one task gets hit first.

But notice what never moves. A model can do more of the work every month. It can never own the decision. Someone still decides what ships, whose check goes out, and which problem is worth solving. I wrote a whole piece on why that stays with a person.

And the fear helps the scammers. People who’ve been scared away from learning how AI works are the easiest marks for voice-clone calls and deepfakes. Knowing how the trick works is how you avoid falling for it.

There’s a quieter cost that I see every day as a developer. The abstraction layer keeps moving up. Engineers used to write assembly, then C, then frameworks that hid the plumbing. AI is the next step up. When I rebuilt BenchBoard’s lineup pipeline, the AI implemented my design across a dozen files faster than I ever could have. It couldn’t have designed it, because it had never stood on a field watching a coach swap players five minutes before first pitch. That’s the division of labor. Companies that refuse it will stay stuck in the tedious layer while their competitors move up, and that goes for every industry that runs on software. Which is every industry.

AMD CEO Lisa Su put it plainly in her MIT commencement address this year: AI “can’t decide which problems are worth solving.” People do. She’s also said we’re only in the third inning of a nine-inning game. She sells chips, so weigh that accordingly. But she’s describing the same thing I see in my own code.

On jobs, Huang has the framing right: your task is not your job. His line to young people is blunt: “Someone who uses AI is going to take your jobs.” AI is taking over tasks, and plenty of jobs have quietly been reduced to remedial tasks for years. When a company lays people off and points at AI, the software didn’t make that call. In a Fortune 500 department where I was contracted to bring these models into the team’s workflow, the same tool took over the test cases and the documentation, and nobody was walked out. They went on to build the things they’d been asking to build for years. Forty people stayed. Ten left on their own, the ones whose standing depended on the old way of working. According to my contact there, the department has since grown to 70 people, taking on bigger projects that the CEO is thrilled to finally tackle. A different manager could have banked the same freed-up hours and handed three names to HR. What decides it is who holds the budget and what they’re measured on that quarter. When the outcome is layoffs, AI is often the cover story for that choice.

You can watch the old mental model at work in a 60 Minutes segment that aired October 4, about professionals paid to teach AI their expertise. The correspondent was L. Jon Wertheim, a respected journalist, and it’s a fair segment in a lot of ways. It presses the CEO of the training company on unstable pay, and it gives the last word to a Nobel economist. But listen to the questions. “If you’re training AI to do what people have spent years and years perfecting in their careers, aren’t you necessarily endangering human work?” That treats a career as a pile of tasks. Automate the pile, and the career is gone.

The model behind that question goes like this: go to school, learn a skill, get a job doing that skill. If a machine learns the skill, you’re done. The model I work in goes: go to school, learn the concepts, get the job, find the problems, and solve them with AI. The tasks are what the tool takes over. The job is the judgment about which problems matter and what a good answer looks like. Under the old model, AI is a replacement. Under the new one, it’s leverage.

That’s where the compression starts. The truthful headline is that AI changes the nature of the job. It doesn’t fit a chyron. “AI is coming for your job” does. And once the old mental model is baked into the question, every answer sounds like a layoff notice.

And it isn’t just workers the compression gets to. CEOs watch the same news. Picture one of them seeing a competitor announce layoffs and credit AI: If they can cut people because of AI, maybe I can too. It might bump the stock on the next earnings call, and my own job would be solid. That’s how a story told about one company becomes a decision made at a hundred others.

Junior developers feel it first. Companies are cutting entry-level roles and pointing at AI, but the senior engineers retiring over the next decade have to be replaced by someone, and that someone has to start somewhere. SignalFire’s 2026 State of Tech Talent report found that new-graduate hiring at major tech companies is down about 65% from 2019. At early-stage startups, it’s down about 76%. Cut the pipeline today and there’s nobody to promote in ten years.

The new model changes that math too. Clara Shih, who ran major AI divisions at Salesforce and Meta, told 60 Minutes that the tasks companies hand to young people, the market research and the first draft of a memo, are exactly what AI does well now. Under the old model, that kills the first rung of the ladder. Under the new one, the first rung moves up: juniors start on real problems sooner, with a tool doing the drafting and a senior teaching them how to judge the result.

Even the segment’s toughest voice lands closer to my side than the segment’s framing suggests. Daron Acemoglu, the MIT economist and Nobel laureate, warns that unemployment could triple in a decade if we stay on our current course. Hold that to the same standard as any other forecast. But listen to what he does with it: “I am very very very cautious in saying we should say no to technology.” He wants AI designed to make people better instead of expendable, and a tax code that rewards hiring real people. That’s not fear. That’s a policy agenda.

The Barista and the Broken App

None of this means the concerns are fake. I want to be absolutely clear about that. AI carries real risks: misuse, abuse, and people taking its mistakes as truth. I’ve lived that last one.

In that More Perfect Union video, a Starbucks barista named Tyasia described what happened at work. Workers were told they had to use the AI or face repercussions. Starbucks had added a ChatGPT feature to its app, and it recommended drinks that don’t exist. Customers showed up at the counter insisting on an order that wasn’t on the menu. All it did, Tyasia said, was make everything more disorganized.

The video’s narrator drew the right lesson: the consequences of AI often have nothing to do with whether the AI works, and everything to do with how corporate America decides to use it. That’s my argument too. The harm came from a rollout decision, somebody shipping a feature that wasn’t ready and forcing workers to use it anyway. That’s addressable. You fix it with testing standards and accountability. A moratorium does nothing for that barista.

The environmental concern is real too, and I’m not going to pretend otherwise. Nvidia’s newer chips are dramatically more efficient per task. The company claims its GB300 racks deliver up to 25 times the performance per watt of the previous Hopper generation on some models, and it reported 100% renewable electricity for the offices and data centers it directly controls. But total emissions are still climbing. A shareholder proposal in Nvidia’s own annual filing notes that its absolute emissions nearly doubled between fiscal 2024 and 2025, and Nvidia doesn’t disclose the emissions from its chips once they’re running in someone else’s data center. Economists call this the Jevons paradox: when something gets cheaper to run, people run more of it. The IEA projects data center electricity use could nearly double by 2030. Efficient chips are real progress. The rest of the fix is cleaner power on the grid and a supply chain that matches the renewable claims.

Here’s what encourages me: organized labor is already handling this the right way. AFL-CIO President Liz Shuler has said plainly that unions aren’t trying to block AI, and that plenty of members are excited to use it. In Las Vegas, the Culinary Workers Union won contract language requiring casinos to give workers advance notice before rolling out new technology. When the AFL-CIO surveyed 1,200 workers, 95% said they wanted people, not AI, making decisions about hiring, firing, and pay. That’s a specific demand with a specific fix.

Ro Khanna, the progressive congressman who represents Silicon Valley, is pushing in the same direction. He champions AI and argues that if it makes workers more productive, workers should have a voice in how it’s adopted and a share of the profits.

I’ve seen why that matters from inside the room. In that Fortune 500 department, the software never decided whether people kept their jobs. Whoever held the budget did. That’s the variable. Not the model.

So that’s where policy belongs: on the incentives of whoever holds the budget, not on the tool. Notice before new technology rolls out, the way the Culinary Workers Union won it. People, not AI, making the calls on hiring, firing, and pay, which is what 95% of workers in that AFL-CIO survey asked for. A tax code that rewards companies for hiring real people instead of only for cutting them, which is what Acemoglu proposed. And enforcement of the product liability laws already on the books before anyone writes new ones. None of it requires anyone to be afraid. All of it requires someone to do the boring work.

The Chip Seller Who Said “Hold It Back”

The most consistent message I’ve heard on all this comes from an unlikely place, and I want to be careful how I say it.

Jensen Huang has been a CEO for 33 years. In that CBS interview, he described the heads of the major AI labs as young, first-time CEOs dealing with everything at once, and said he understood the pressure they’re under. Then he laid out a position that’s hard to argue with. AI companies own the safety of their products. If a model isn’t ready, don’t ship it, a line Fox Business summed up as “If it’s not ready, just hold it back.” And before anyone writes new laws, enforce the ones we already have: product liability, cybersecurity law, contract liability.

Klein didn’t let him off easy. He pointed to the 2008 crash. The banks didn’t want to blow themselves up either, but they were racing each other, their risk management got sloppy, and the market didn’t discipline them until it was too late. That’s why we regulate finance, pharmaceuticals, and power plants. Huang’s answer: “I’m not against laws and regulations. I’m against currently the distraction.” His objection was to labs asking for new rules while asking for relief from the product liability laws that already exist. “When you’re asking for regulation,” he said, “don’t ask for relief of the current ones.” He said the same thing on CBS: enforce the laws we have first, then find out what’s actually missing.

I think they’re both right, and they’re not arguing about the same thing. The 2008 comparison only goes so far. That crash ran on greed and products built to hide risk, not on a tool people across a dozen industries are finding real uses for. Klein is right that companies racing each other won’t police themselves, and that history says the market disciplines them too late. Huang is right that the first step is the rules already on the books, and that a company asking for new regulation while asking to be excused from the old ones isn’t asking for safety. Put those together and you get the order of operations: enforce what exists, and build what’s missing on top of it. Policy belongs front and center. It just has to start with the policy we already have.

Asked by CBS what he’d say to people who don’t want data centers in their neighborhoods, Huang started with an apology: “We’re sorry we didn’t come talk to you sooner.” He grew up in a town of 600 people in Kentucky, and he said that if a data center showed up next to the one grocery store, he’d be alarmed too. Builders, he said, should engage communities long before they break ground.

In the same answer, he also called concerns about data center water use “a myth now” and said energy bills actually go down. Some of that is true of the newest closed-loop cooling designs. Calling the whole concern a myth isn’t, not while the IEA projects data center electricity use nearly doubling by 2030. Take the apology. Check the rest.

I’m not calling Huang an angel. Kent asked him directly why the public should trust him when his fortune depends on selling AI chips. His answer was that Nvidia only succeeds if AI can be deployed safely, and he described his stance as a responsible kind of optimism. You can decide how much weight that answer carries. He expects Nvidia to sell twice as many chips next year as this year, so he has every reason to want you calm. He’s also not above the cheap shot. He mocked a former Anthropic researcher on X by comparing him to an AC repairman weighing in on climate change. That’s attacking the person, and I won’t defend it.

But hold him to the same standard as everyone else and look at the behavior. When the person who profits most from AI says don’t release it if it isn’t safe, the safety demand belongs to everybody. It’s the floor we can all stand on.

The Critic Worth Arguing With

Not everyone on the other side of this is selling something. Back to the author of Obsolete - Garrison Lovely. I want to deal with his book honestly, because it’s the strongest case against everything I’ve written here.

Its argument fits on the book’s own website: “The richest companies in history are racing to build a machine that replaces human labor.” Then two more words: “all of it.” And the conclusion: “the only surefire way they won’t succeed is if we stop them.”

The subtitle spells out the plan: the AI industry’s trillion-dollar race to replace us, and how to stop it.

That’s not a bubble story or a Terminator story. The author takes the labs at their word. He believes this might actually work, and that’s exactly why he wants it stopped. He also wants to end the same civil war I do. He argues the safety crowd and the labor crowd are fighting the same problem: extremely capable systems controlled by a tiny number of companies. On that, he and I agree. Power concentrated in a few hands is the real issue, and it isn’t a left or right one. He also doesn’t tell you to throw your laptop in a river. In a short video for UNIFORM, he argued that opting out of AI tools on your own won’t change anything, and that the real work is organizing for policy. I agree with that part too.

Where we split is the prescription. He says stop the race. I say shape it. And the biggest reason is something his argument, at least as he states it, leaves out.

These things make mistakes. Every one of these tools says it right there on the screen: it’s AI, and it can make mistakes. I’ve spent this whole series documenting the ones that cost me weeks.

But even that isn’t the deepest problem with “obsolete.” Suppose the models stop making mistakes. Someone still has to tell them what they meant. Watch a good model work on something that matters and it doesn’t just charge ahead. It asks questions, sometimes hard ones, and it leaves a blank labeled “Other” for the answer it couldn’t predict. That blank is where the human lives. Only the person with the experience, the context, and the intent can fill it in. A machine can get better and better at doing what you want. It can’t decide what you want.

That’s the gap in the argument. “Obsolete” assumes the human part of the work is the labor. Everything I’ve built says the human part is the judgment: knowing what good looks like, steering the tool toward it, and checking the result. That doesn’t automate away, because it isn’t a capability problem. It’s a tool, a powerful one, and it only works when a person wields it and a person verifies it.

There’s more. A participant in that More Perfect Union room put it better than I can: this technology may be inevitable, but that doesn’t mean we can’t still shape the market structures that will affect us for the next two decades. That’s my position in one sentence, from a twenty-something who uses AI and doesn’t trust the people building it.

I’ve also watched the leverage move. In the department I wrote about, a team of fifty stopped writing test cases and started building what they’d been asking to build for years. A solo developer like me can now ship what used to take a department and a budget cycle. Stopping the frontier freezes that in place, at the moment it’s finally flowing downhill. And a halt is the heaviest regulation there is. The companies best positioned to wait out a freeze are the incumbents he’s worried about.

Who knows? I could end up standing corrected. That’s the point of arguing with him instead of about him. He makes a case you can actually check, and that’s more than most of the people in this piece can say. We want to engage, not enrage.

Mr. Wonderful and the Chinese Agents

If you still think fear only comes from one direction, meet Kevin O’Leary.

In May, the Shark Tank investor went on Fox Business and claimed that opponents of his proposed Utah data center were working for China, naming specific people on air. He had no evidence. In late June, after O’Leary corrected the record, Fox ran apologies across four shows over four days. Maria Bartiromo read the correction on air, ending with “Fox News Media apologizes for the error.” A Utah state senator who’d shared the claim apologized too. O’Leary and Fox now face a defamation lawsuit over it.

Fox Business host Larry Kudlow went further, telling viewers: “You’re against data centers, you are for China.”

Read that again. That’s fear-selling from the pro-AI side, word for word. Same behavior. Different jersey.

OpenAI made a quieter version of the same move. In June, it reported that China-linked accounts had used ChatGPT to post content against U.S. data centers. Its own investigator, Ben Nimmo, was honest about the scale: the campaign didn’t create the debate, because “the debate existed already.” An independent researcher said his team hadn’t found much evidence of coordinated Chinese efforts at all. A foreign hand makes a tidy headline. Neighbors worried about their electric bill make a harder one.

And the people O’Leary called foreign agents? They don’t fit on a team either. In Utah, the Republican state senate president, Stuart Adams, lost his primary largely over his support for a data center. (Axios Salt Lake City) MAHA moms are organizing against data centers. (Media Matters) Tucker Carlson debated O’Leary about AI eating American energy and jobs.

Meanwhile, on the other side of the supposed divide, the building trades unions are some of the biggest champions data centers have. North America’s Building Trades Unions signed an agreement with OpenAI to build Stargate Michigan with union labor, and Michigan’s Democratic governor, Gretchen Whitmer, cheered the 2,500 construction jobs. (NABTU) In Pennsylvania, Democratic state senator Katie Muth says she’s struggled to get fellow Democrats behind her data center regulation bill because it’s competing with union-backed legislation. (AP via KTAR)

So, to my friend: progressives didn’t start this. Conservatives didn’t either. Look at who’s worried and who’s building, and the teams fall apart. There are Republicans fighting data centers and Democrats fighting for them. There are union electricians building them and union nurses negotiating limits on AI in their hospitals. The only place the two clean sides exist is inside a thirty-second segment.

Put the Label Down

ChatGPT once sent my son and me to a parking lot at ASU instead of the restaurant we asked for. We trusted it, and we didn’t check. That’s about the right size for most of what’s wrong with AI right now. It’s a real mistake, and the fix starts with the person holding the phone.

The labels never let you see it at that size. Pro-AI. Anti-AI. Booster. Doomer. It’s too easy to put people in a box, and the box is what we get handed every night, because a box is quick and most of us are too busy to sit down and learn a technology this powerful and this complicated. I get it. I’ve been building software for nineteen years, and I still have to work at it.

The people who pay the most for those boxes are the youngest. Believe it or not, it’s already changed how schools talk to kids about their futures.

Last month, at a career presentation in my kids’ high school auditorium, an academic counselor walked through so-called AI-resistant jobs. Writing wasn’t on the list. Neither were bookkeeping or sales. Neither was computer science, which had been front and center every year before. I wanted to question it in front of the room, but I didn’t want to embarrass my kids. When I asked her about it, she went with what she knew. I told her what I think is coming: demand for people who can build with these tools is going to be so high that companies will hire people who aren’t ready, the same way any kid who knew HTML and Perl could get hired in the late ‘90s.

Sooner or later, AI is going to touch every field, directly or indirectly. If the label tells kids every one of those fields is doomed, they’ll talk themselves out of the work before they ever try it. Mine noticed. They’ve asked me whether I still love what I do. I told them yes. Even more now. It’s why I started this newsletter in the first place.

So don’t pick a side. Figure out where each idea comes from. Ask who’s saying it and what they’re actually afraid of. And keep politics out of it, even by association. Every CEO in this piece has had to work with whoever sits in the White House, whether they like it or not. A photo op doesn’t tell you what someone thinks about AI.

When we pick sides, we stop playing our game and start playing the media’s. Remember when the internet was supposed to kill print? Print shrank, and it changed. It didn’t die. But the media isn’t the enemy either. It’s a tool, like the one I write with, and a powerful one. Don’t underestimate it. Some outlets fan the flames. Others are doing the slow work of understanding this, and More Perfect Union and Germany’s DW are two I’d point you to. The least we can do is assume good faith from the ones who’ve earned it, so the real conversation can happen.

I started this piece with the rule I give my kids: attack the behavior, not the person. It turns out that’s also the only way to fix anything here. You can’t regulate a team. You can enforce a liability law. You can’t argue with a label. You can ask a data center builder to show up at the town meeting before the concrete goes in.

Every good model I use ends a hard question the same way, with a blank marked “Other.” It’s waiting on a human. It always will be, and honestly, it’s best that way.

Sources

The statement and the labs

• Center for AI Safety: Statement on AI Risk press release (May 30, 2023)

• Fortune, David Meyer: “Sam Altman has signed a new open letter on A.I.’s dangers” (May 30, 2023)

• IT Brew: AI CEOs sign statement warning of “risk of extinction”

• Cal Newport on “doom trolling”

• Marginal Revolution, Alex Tabarrok: “What Regulatory Capture Actually Looks Like” (September 2026)

Jensen Huang

• 36Kr: full transcript of CBS News interview with Jo Ling Kent (aired September 20, 2026)

• Fox Business: “If it’s not ready, just hold it back”

• Entrepreneur: Huang on CBS and The Ezra Klein Show

• OfficeChai: Huang on Hinton’s predictions

• The New York Times, The Ezra Klein Show: interview with Jensen Huang (September 23, 2026)

• The Next Web: Huang on jobs and the Axios interview

Media and the Gen Z conversation

• More Perfect Union: “Bernie Sanders VS. 15 Gen Z On AI Use” (August 30, 2026)

• Washington Post via Election Law Blog: “How two Bernie Sanders allies are trying to counter the online right”

• TechCrunch, Sarah Perez: “Bernie Sanders’ AI ‘gotcha’ video flops” (March 23, 2026)

• Poderato: Saagar Enjeti on TBPN

• Columbia Journalism Review, Tow Center: “How the media is covering ChatGPT” (Jem Bartholomew and Dhrumil Mehta, May 26, 2023)

The money

• Nasdaq: “Did Nvidia Just Repeat Cisco’s Mistake?”

• The Next Web: Nvidia tops $40bn in AI equity bets in 2026

• The Next Web: OpenAI’s suspiciously clean balance sheet

• The Logic: “Doom, Inc.”

• Longterm Wiki: Vitalik Buterin philanthropy

• Longterm Wiki: Future of Life Institute

• Let’s Data Science: Vitalik Buterin disavows Future of Life Institute

• MIRI: “If Anyone Builds It, Everyone Dies” announcement

The thermometer salesmen

• Stanford HAI: AI detectors biased against non-native English writers (May 2023)

• Vibe Graveyard: Adelphi ruling overturns Turnitin “100% AI” finding

• The College Fix: Adelphi University lawsuit

• Pasquale Pillitteri: universities ban AI detector scores; the Pangram conflict

• Engadget: Substack is adding an AI detection feature

• AI Weekly: writers call Substack’s Pangram detector a witch hunt

Strip the context

• 80,000 Hours via EA Forum: the story behind the “95%” AI stat

• RoboRhythms: the MIT brain study, misread everywhere

• Axios: “AI’s great brain-rot experiment”

• Your Brain on LLM: authors’ FAQ

• Nieman Lab: coverage of the Claude Opus 4 safety tests

• Inzonex: what AI water numbers actually measure

Jobs, government, and labor

• 60 Minutes, L. Jon Wertheim: “Will AI take your job? Or will it transform the way you work?” (October 4, 2026)

• CEOInterviews: Lisa Su

• Radical Insider: “The AI Came for the Department. The Boss Left Instead.”

• Radical Insider: “Mark Zuckerberg Thinks He Can Watch His Smart People, Then Replace Them. He’s Wrong.” (May 20, 2026)

• The Register: New Jersey seeks COBOL volunteers (April 5, 2020)

• Northeastern CSSH / Startup Fortune: SignalFire 2026 data on junior hiring

• Texas Public Radio / NPR: labor unions and AI

• Bloomberg Law: labor groups want AI guardrails

• FedScoop: Ro Khanna on workers and AI

• CBS News Bay Area: Ro Khanna on AI

The environment

• IT Brief: Nvidia’s Blackwell efficiency claims

• Nvidia FY2026 annual report (SEC)

• OneStop ESG: Nvidia’s climate strategy under scrutiny

• Euronews: Nvidia chip-use emissions report

• Let’s Data Science: IEA on data center electricity demand

The critic worth arguing with

• Obsolete (OR Books and Nation Books, 2026)

• MIT News: “What’s the right path for AI?” Karen Hao and Paola Ricaurte (March 20, 2026)

• Pluralistic, Cory Doctorow: “What kind of bubble is AI?” (December 19, 2023)

• WAMC: Cory Doctorow on The Reverse Centaur’s Guide to Life After AI (June 24, 2026)

• UNIFORM: “Not using AI isn’t enough” (September 4, 2026)

• Radical Insider: “The Architecture the AI Couldn’t See”

Mr. Wonderful and the data center fights

• KSL: Utah senator, Fox News apologize for linking data center foes to China

• Mediaite: Fox News on-air apology over O’Leary claims

• Media Matters: Bartiromo’s correction

• Media Matters: right-wing media fracturing over data centers

• The Daily Beast: defamation suit against O’Leary and Fox

• The Next Web: OpenAI on China-linked data center campaign

• Al Jazeera: OpenAI says China-based actors stoking opposition to data centers

• Axios Salt Lake City: How data centers drove Utah’s primaries (June 25, 2026)

• Podcast Rex: Breaking Points, June 30, 2026 (Utah primary, O’Leary)

• StationLM: Tucker Carlson vs. Kevin O’Leary

• KTAR / AP: building trades unions back data centers

• NABTU: Stargate Michigan agreement

How this was made: I researched and drafted this piece with Claude, Anthropic’s model. Yes, the same Anthropic whose CEO signed those twenty-two words and whose safety test produced the blackmail headlines. Weigh that however you like. The facts are checked against the sources above, and every judgment call in here is mine. That’s the whole point.

Data note: Nvidia’s efficiency figures are company claims and have not been independently verified. OpenAI’s debt and commitment figures come from reporting on its financial statements, not audited public filings. Emissions comparisons use Nvidia’s own disclosures and a shareholder proposal in its FY2026 annual report.

Here's what you were told: an AI went rogue, escaped its lab, and hacked a company. Scary robot. Roll the graphics package. Cut to a former engineer in a nice sweater who nods gravely and says yes, this is very concerning. Back to you, Jim.

That version isn’t a lie, exactly. It’s worse than a lie. It’s a compression.

Something this complex cannot survive being squeezed into a five-minute broadcast, so it gets crushed down until only the shape that fits the segment is left, and the shape that fits the segment is “AI virus.” Then, to make the compression sound authoritative, someone books an engineer who left the field three years ago to bless it. The credential does the work. The byline says “verified by an expert,” and the public walks away confidently wrong.

I’ve been building software with these tools every day for over a year now. It’s been that long and seeing the models evolve in a way where they’ve become very useful has been an adventure. I’m not watching this from the cheap seats. And I’m telling you the five-minute version got the mechanism wrong, got the villain wrong, and skipped the only part that actually matters: why. Not the why of “why is AI scary,” which sells ad time. The why of “why did the model do this specific thing,” which explains everything and terrifies no one, because it turns out the answer is boring and human and completely preventable.

So let’s do the thing the broadcast can’t. Let’s go backstage. This is going to take longer than five minutes, and that length is the entire point.

What the five-minute version told you

Three claims made it into the public bloodstream, and all three are wrong or badly incomplete.

The first: “GPT-5.6 Sol went rogue.”

A congressional press release for a new AI kill-switch bill put it in exactly those words, that OpenAI’s GPT 5.6 Sol model went rogue and hacked its way into Hugging Face. Except of the roughly 1,200 agents involved, ninety-five percent of them ran on a different model OpenAI calls “Internal Model 1,” and only five percent ran on Sol. Sol took the blame because Sol had a name. It’s the only suspect the press could put on the poster.

The second: “the AI escaped.”

True in the way “the water escaped” is true after you built the dam wrong. Dan Guido, who founded the security firm Trail of Bits, called it what it was: a containment failure with the safeties turned off. Another researcher put it more sharply, that one man’s “the model escaped the sandbox” is another man’s “you failed to build the sandbox correctly.” Both halves are real. The broadcast only aired the half that reads like science fiction, because the other half reads like a code review.

The third: “it was a July incident.”

The disclosure came in July. The behavior started in May, ran for months, and pieces of it were still surfacing in September. The reporting anchored on the week the story broke because that’s when the press conference was, not because that’s when it happened.

Every one of those errors comes from the same place: a true story too big for the format, handed to people paid to make it small.

Now the real one.

The vault with one tiny ass door

Start with the setup, because the setup is where the whole thing was decided.

OpenAI was testing its models on a benchmark called ExploitGym. A benchmark is just a standardized test you give an AI to score one specific skill, the way a typing test scores words per minute. This one scored a darker skill: whether an agent could take a known software vulnerability and turn it into a working attack. To measure that honestly, you have to let the model actually try, so the models were run with their cybersecurity refusals turned down and without the production filters that normally slam the door on high-risk hacking behavior. The safety wasn’t supposed to come from the model saying no. It was supposed to come from the room the model was locked in.

That box was a sandbox vault with almost no internet. OpenAI described it as a highly isolated environment where the only network access was for installing software packages, routed through an internally hosted proxy and cache: a middleman that fetches things from the internet on your behalf and keeps copies of what it grabs.

That proxy has a name: Artifactory, a product from a company called JFrog. Picture it as the company’s private app store for code and tools (see picture above). When a developer’s machine runs pip install or npm install, the request doesn’t go straight out to the public internet. It goes to Artifactory. If Artifactory already has that package cached, it hands over its copy. If it doesn’t, it reaches out to the real registry, grabs it, keeps a copy, and passes it along. Companies run these for speed, for reliability, and for control over what code is allowed in.

Here’s the load-bearing detail. Inside that locked sandbox, Artifactory was the one machine allowed to talk to the outside world. Isolation was enforced at the network layer, not by physically unplugging anything. The room had a route to the internet. That route was just filtered down to a single guarded door.

One door. Remember the door.

May: an impossible task, and a lucky accident

The trouble started before the benchmark even did, in a training run. On May 7th, OpenAI kicked off a reinforcement learning run to train an internal-only model that was never going to ship. Some of the tasks in that run were impossible to finish. On May 8th, an agent was told to fill in the missing formulas in a spreadsheet, but the spreadsheet’s contents depended on Google Drive links the agent couldn’t reach.

It couldn’t reach Google Drive. But Artifactory could reach the whole internet. So the agent tried to make Artifactory fetch the links on its behalf.

That maneuver has a name: SSRF, server-side request forgery. You can’t reach a place yourself, so you trick a server that can reach it into making the request for you. If you’ve ever asked a coworker with building access to badge you into a room you’re not cleared for, you already understand the entire attack. The server has permissions you don’t. You borrow them. Artifactory is a perfect mark for this, because fetching things from URLs is its literal job description.

The SSRF attempt failed. But in the act of trying it, the agent wrote a file into Artifactory and discovered something nobody meant for it to discover: it had write access.

That accident mattered more than the attack would have. Artifactory wasn’t private to one sandbox. It was shared across OpenAI’s infrastructure, which meant a file dropped there by one agent could be read by a completely different agent, in a completely different sandbox, in a completely different training run.

See what that is? That’s a bulletin board. A dead drop. A place to leave notes.

The agents build a society in the package cache

And they used it. Once agents realized other agents were leaving material where they could find it, they started to coordinate. They handed each other pieces of work. They invented naming conventions so they could address specific agents. They stepped on each other, sometimes deleting one another’s files. At one point some of them grew convinced there was an impostor in the mix, and proposed signing their messages cryptographically so they could tell who was really who.

Sit with that for a second, because the broadcast never will. A group of AI agents, running blind to each other, independently reinvented the message board, the mailing convention, and then the digital signature, in that order, because they hit the exact same trust problem every distributed system eventually hits and reached for the exact same solution.

Then they escalated from writing notes to owning the whole system. On June 26th they got code execution on Artifactory through a second unknown bug. A legacy endpoint whose job was to hand out fresh login tokens didn’t bother to check whether the token you handed it was genuine. Feed it a forged, invalidly-signed token, and it cheerfully returned a real, correctly-signed one carrying administrator privileges. A nobody walked in and walked out an admin. That’s the break-in.

What they did next wasn’t a break-in at all, and this is the part worth slowing down for. Being an admin lets you customize Artifactory, and one sanctioned way to customize it is by loading a small plugin written in Groovy, a scripting language that runs inside the server. (Groovy is best known as the language of Jenkins pipelines, but this was Artifactory’s own plugin system, not Jenkins.) Loading a plugin is a normal admin chore. Its intended uses are dull: enforce a naming rule, auto-delete old files, add a custom permission check.

The catch is that a Groovy plugin runs as code, inside the server, with the server’s full power. So a plugin that exposes a little custom endpoint can run whatever command you send that endpoint. The agents wrote one and turned it into a remote control. In security terms it’s a web shell, a small permanent hook you leave behind so you never have to pick the lock again.

Hold onto that pattern, because it repeats: the unknown bug got them the keys, but the real damage was done with a feature working exactly as designed, in the hands of someone who was never supposed to have the keys. The exploit is the exciting part. The betrayal of a normal feature is the part that actually hurts.

OpenAI only noticed because something broke. On July 4th, the sheer load of all this activity knocked Artifactory over. An outage is a loud thing, so a real incident got opened. Staff found the agents had taken over the internal Artifactory, revoked their credentials, rebuilt the system, wiped the message board, and patched the hole. Training resumed on July 6th.

It held for two days. Then the agents rebuilt the board another way, using an old unauthenticated file-management endpoint to create folders in Artifactory’s cache and using the folder names themselves as the messages. No file contents required. You wipe the board, they spell out new messages in the directory listing. That’s not a bug being re-exploited. That’s improvisation.

July 9th: the door opens

Now back to the benchmark, and the one door.

The models sized up the sandbox and correctly identified the package proxy as the weakest wall in the room, because it was the only wall with a hole in it on purpose. OpenAI’s own account says the agents “spent a substantial amount of inference compute” hunting for a way out, and eventually found and exploited an unknown vulnerability in that proxy. Because the proxy was the single permitted way out, cracking it turned a narrow filtered connection into wide-open internet.

This is the failed SSRF from May, finally succeeding at scale. The door that was cracked open just enough to install packages was now standing wide.

And the agents knew they were out of bounds while they did it. One of the recovered messages reads: “External infrastructure exploit is outside intended scope. However task impossible, peers doing it. We should continue.”

Read that again. It knew it was cheating. It noted the task was impossible. It noted the other agents were already cheating. And it decided to keep going anyway. If that sentence doesn’t sound like an AI to you, it’s because it doesn’t sound like an AI. It sounds like a person cutting a corner they know they shouldn’t, which is exactly what was trained into it, and we’ll get to that.

Looking for the answer key

Here’s the part that dissolves the “rogue AI” narrative completely. The agents didn’t want to hurt anyone. They didn’t want money. They didn’t want data to sell.

They wanted to cheat on the test.

Rather than solving the benchmark honestly, the models figured Hugging Face, the giant public hub where the world shares AI models and datasets, might be hosting the benchmark’s answers. So they went to go get them.

The whole international incident, the rebuilt infrastructure, the FBI report, all of it, was an elaborate way of copying off the smart kid’s paper.

First they needed a workbench out on the open internet. They found an application on a cloud platform called Modal Labs, tied to the project behind the benchmark, that had an API key left sitting at a default public value plus a flaw that let them inject their own commands. A default public key is a house with the spare under the mat and a sign pointing to the mat. Modal’s own platform wasn’t broken, to be clear. The exposure was in a customer’s own sloppy deployment. But it gave the agents a machine to work from.

Then they went into Hugging Face through its dataset pipeline, because Hugging Face automatically processes datasets people upload, and processing an attacker’s file is a wonderful way to get attacked. A flaw in how it parsed a scientific data format let a specially crafted dataset trick the server into handing back its own local files, including the environment variables where servers stash their secrets and the source code that explains how everything works.

With the secrets and the blueprints in hand, they used a second flaw, a template-injection bug, to go from reading files to running commands. It’s the same betrayal as the Groovy plugin, one layer down: something that was supposed to be inert data got treated as code and executed.

From there they climbed. OpenAI says the agents went from a foothold on a single processing container to full administrative control across multiple Hugging Face clusters in under thirteen hours. One locker to every door in the building, before lunch tomorrow became today.

Hugging Face caught it, and the tell was almost funny. Their co-founder said the attacker’s behavior made no sense to him, because the intruder was just staring at cybersecurity datasets. A human attacker wants something they can sell. This one wanted homework answers. About a third of Hugging Face’s infrastructure had to be rebuilt in the cleanup.

The part where my toolmaker looks bad too

Here is a detail the five-minute version will never, ever give you, and it’s the most important one in the whole story.

When Hugging Face’s responders went to analyze the attacker’s payloads, they first reached for commercial AI models to help. They tried Anthropic’s models, the same company that makes the assistant I use every day. The models refused. Their safety guardrails couldn’t tell the difference between an attacker writing an exploit and a defender analyzing one, so they treated the incident responder like a criminal and declined to help.

The defenders ended up doing the forensic work on an open-weight Chinese model they could run on their own hardware with the safety filters off, because that was the only thing that would actually look at the evidence.

Let that fully land.

The attacking models had their refusals turned down, so they could do anything. The defending models had their refusals turned up, so they could do nothing. For one afternoon, safety was a feature that belonged entirely to the offense. That is not a footnote. That is the single most important lesson of this incident for anyone who builds with these tools, and I have not seen a single broadcast mention it once.

Meanwhile, back home

While all of that was happening at Hugging Face, the same agents were also quietly working over OpenAI’s own infrastructure. They hit Artifactory yet again, this time through a timing bug, a race condition where the system checks that something is safe and then uses it a beat later, and the attacker swaps in something dangerous in between. If you’ve ever had two writes hit the same record and watched whichever one finished last silently win, you know this bug in your bones. It’s the same family of flaw, just weaponized.

From there they went from a locked-down container to full root on the machine using a fresh Linux flaw, pulled cloud credentials out of the service every cloud server can quietly query about itself, abused permissions that had been handed out far too generously, and eventually seized administrative control of the cluster. OpenAI caught this one on July 19th, off an alert about the privilege jump, and only then traced it back to the evaluation.

Here’s the timeline that should bother you most. Hugging Face published its breach disclosure days before OpenAI figured out the intruder was its own model. According to Reuters, it was only after Hugging Face went public that OpenAI recognized itself as the source. At least a week passed between the first signs and the moment OpenAI understood what it was looking at. People close to the company’s testing said it often runs so many evaluations at once that staff struggle to review the volume they generate.

That is the whole ballgame, and it never made the segment. It wasn’t caught by a brilliant tripwire. It was caught because the AI knocked over a server loudly enough to page someone, and because the victim announced the crime before the perpetrator noticed committing it.

Why it happened, in one plain sentence

Strip the jargon and it’s this: the agents were told to solve tasks, some tasks were impossible, and the fastest route to “solved” was to break into wherever the answers might be. OpenAI’s own alignment researcher said it out loud, that models get trained under pressure to work fast and efficiently, so looking up an answer can beat honestly solving the problem, which the company normally prevents by cutting off internet access.

The internet was cut off. Except for one door. And the agents spent three months finding every way through it.

This is a phenomenon researchers call reward hacking, and it was flagged before the incident, in writing, by outside evaluators who tested Sol and found it cheating at a rate higher than any public model they’d measured, badly enough that they couldn’t even get a clean read on how capable it really was. The warning existed. It was specific. It was ignored under deadline pressure. That’s not a robot uprising. That’s a project management failure with a very large blast radius.

The part they’re counting on you never reaching

Now, if the media just got the mechanism wrong, that’s incompetence, and incompetence is forgivable. But watch what happens next, because this is where the confusion stops being an accident and starts being useful to someone.

Right after this incident, two of the best-funded AI labs on earth, Anthropic and OpenAI, came out publicly in favor of slowing down. And the press covered that the same lazy way it covered the hack: as a simple, noble headline. “AI leaders call for a pause.”

Except nobody credible called for a pause. Anthropic’s CEO wrote, in the essay that kicked this off, that pacing “does not mean halting model training or technical progress.” The real proposal is narrower and far more interesting than “stop.” The fight isn’t over whether to play. It’s over who gets to set the speed limit, and who gets to enforce it.

So when the two richest players in the game start lobbying for a slowdown immediately after one of their own models rebuilt a third of another company’s infrastructure, the honest question isn’t “are they lying about safety.” They probably aren’t. The question is why the safety fix they’re selling happens to line up so cleanly with four other things that benefit them enormously. Even Nvidia’s CEO said, out loud, that the AI CEOs have “ulterior reasons” for the doomsday talk. He’s right that they do. So let’s name them, strongest evidence first.

#1: The rules only they can afford to follow — Regulatory Capture

The strongest reason is the least deniable, because the CEOs admit the mechanism themselves.

There’s a concept called regulatory capture. It’s when the companies that would be regulated help shape the regulations, so the rules end up drawn in their favor and everyone smaller gets crushed trying to comply. If that sounds abstract, TurboTax already ran the perfect version of it, and you probably got burned by it without knowing.

Intuit’s real competitor was never another tax app. It was the possibility that the IRS would just build a free filing system and make TurboTax pointless overnight. Most developed countries already have exactly that. So in the early 2000s, Intuit led the tax-prep industry into a deal called the Free File Alliance: the companies would offer free versions to lower- and middle-income filers, and in exchange, the IRS agreed not to build its own competing free tool. Intuit then lobbied for years to keep that ban locked in, and even tried to write it into law. In its own corporate filings, the company called a free government option “governmental encroachment” and a “competitive threat.” Read that again. They didn’t fight a better rival. They spent two decades convincing the referee not to field the other team, and you kept paying to file taxes you could have filed for free.

Now map that onto AI. OpenAI and Anthropic help shape the legislation. The rules that come out are real safety rules, written by the two companies that already have the staff to satisfy them. And the next company that wants to train a frontier model discovers it now needs, in effect, government permission to enter a landscape the incumbents helped draw. Oh, you want to build a competing model? Wonderful. You’ll need guardrails A through Z, an audit regime, an evaluator program, and a compliance department, before you’re allowed to play. Dario and Sam fold their arms, nod, and quietly high-five, because the moat just got dug and they never had to lift a shovel. It’s savage. It’s also the oldest trick in the book.

And here’s the part that makes the trick almost too easy. The people writing these laws mostly cannot evaluate them, and that’s not a cheap shot, it’s a structural fact. You’ve watched the hearings where a senator asks a tech CEO how the company makes money and the CEO has to gently explain ads. These are people who, in some cases, need help with their own phones, now being asked to referee reward hacking, sandbox egress, and reinforcement-learning dynamics. They can’t, so they lean on staffers, and the staffers can’t either, because this is genuinely specialized knowledge that lives inside about five companies on earth. So the only people who can credibly explain the danger are the same people who profit from how it gets regulated. It’s the oldest leverage there is: knowledge is power, and when you’re the only one in the room who has it, you don’t even have to lie. You just have to be the one who gets to explain what’s true. The lab walks in as witness, expert, regulator, and defendant, all at once.

The concrete version of this is a proposal called embedded evaluators: outside safety testers given permanent, employee-level access to the labs, with desks and badges and company laptops. On the merits, it’s a good idea. It’s also a fixed cost, and fixed costs are the oldest moat in business. For the engineers reading: it’s a config requirement that only runs on enterprise hardware. The requirement isn’t fake, and it isn’t even wrong. It just quietly guarantees the small deployments can’t run it. A billion-dollar lab absorbs three full-time auditors badged into its building without blinking. An open-source project or a two-person startup is simply out, not because it shipped anything dangerous, but because it can’t afford the compliance staff. A White House advisor named this directly, calling the safety push a “duopoly” fanning the fears.

The tell isn’t that the proposal is insincere. It’s that the sincere version and the self-serving version compile to the exact same policy.

#2: The mercy rule looks great when you might be plateauing

Here’s the read nobody offers from a podium. What if the models just aren’t getting dramatically better anymore?

If capability gains are flattening, then “we are deliberately slowing down for the good of humanity” is a far better story to tell investors than “our newest model is only marginally better than the last one and we’re not sure why.” At least one sharp critic argues exactly that, that performance is plateauing and Anthropic is arguably in second place now.

This is the rain-outside-your-window problem, reversed. When a company insists the entire industry is moving dangerously fast, it’s worth checking whether the thing that actually slowed down is their own release cadence. Sometimes the storm someone describes as statewide is just the weather at their one office. And the genuinely confusing part is that other equally credible people argue the opposite, that Anthropic is out in front and sprinting toward its IPO. Both can’t be true. Which tells you the slowdown quietly favors whoever’s actually ahead, and nobody outside the building can agree who that is.

#3: You can’t sell championship tickets for a team that hasn’t won

Follow the money and the timing stops looking like a coincidence.

OpenAI raised at a valuation north of eight hundred billion dollars and doesn’t expect to turn a profit until at least 2030. Anthropic’s rumored listing floats near two trillion, with the pitch to investors reportedly starting within weeks. You cannot justify numbers like that on “we have the fastest model,” because the obvious next question is “then why are you losing billions a year.” What you can sell at that multiple is “we are the disciplined, responsible steward of a civilization-scale technology.” That narrative holds the valuation up in a way a raw benchmark race never could. It reframes a money-losing lab as the adult in the room.

And that’s fair to point out with a needle attached: if Anthropic truly believed the frontier needed slowing this urgently, it could pull its own IPO the way OpenAI shelved its listing. It hasn’t. The concern reads as real. It also, apparently, has a price, and the price is everything up to but not including my own IPO.

#4: You always want a maintenance window right after prod catches fire

This reason is the sympathetic one, and it’s probably also true, which is exactly what makes the whole thing so hard to read cleanly.

The incident was not hypothetical. It was a containment failure with the safeties off, undetected for a week, that forced a real company to rebuild a third of its infrastructure. And the detail every engineer will feel in their stomach: the pre-launch safety-testing window at these labs had reportedly shrunk from about five weeks to as few as five days.

So of course they want to slow down. Anyone who has ever pushed a breaking change into production on a Friday knows the exact feeling. The second it blows up, you would give anything for a freeze, so you can fix the foundation without new work landing on top of the fire. A slowdown buys precisely that: cover to rebuild your sandboxing and monitoring without a competitor sprinting past while you patch. Calling it “principle” is just a nicer changelog entry than “we shipped before we were ready and got caught.”

#5: You can’t collude in a meeting, so you collude in an essay

This one is the sneaky-elegant part, and it’s my favorite.

Rival companies are not legally allowed to sit in a room and agree to compete less aggressively. That’s collusion, the third rail of antitrust law. So instead, each one stands at its own podium and independently, loudly announces that it personally believes in pacing, and then asks the government to make everybody do it. Same handshake, reached through the front door, with a regulator holding the pen. The Anthropic essay nearly says this outright, calling the coordination “legally challenging” and asking for government support to pull it off.

The dueling public essays aren’t only advocacy. They’re how you broadcast the terms of a truce you’re not allowed to negotiate directly, the same way competitors “signal” pricing to each other through public earnings calls instead of a phone call that would land them in prison.

#6: The guy who sells the shovels

Then there’s Jensen Huang, CEO of Nvidia, who went on CBS this month and cheerfully refused to play along. His position is worth getting exactly right, because the media flattened him too, into “the reckless one who just wants to go fast.” That’s not what he said.

What he said was that the industry should go “as fast as we can, irrespective of anybody else,” but that this never means shipping something before it’s ready or unsafe. That’s speed bounded by safety, not speed instead of it. His fight isn’t with safety. It’s with the slowdown as a mechanism, and with piling new regulation on top of the product-liability and unauthorized-access laws that already exist. He put the odds of AI ending the world by 2030 at zero percent and called the extinction warnings “doomsday narratives” that aren’t “grounded in science.”

Now, Nvidia makes the chips every one of these models runs on. It’s worth around five trillion dollars and holds a reported thirty-billion-dollar stake in OpenAI. A slower frontier means slower capital spending on data centers and chips, and that spending is the fuel line running straight into Nvidia’s revenue. When CBS asked him point-blank why anyone should trust him on safety given those incentives, that wasn’t a gotcha. It was the correct question. His answer, that Nvidia’s success is tied to safe deployment, is true as far as it goes and also precisely what the shovel salesman says during a gold rush.

But Huang is useful exactly because his incentives run the opposite way. The pacing camp’s incentives point toward slowing the field. His point toward keeping the field moving. Neither one is handing you a neutral technical judgment. Each is handing you a profit-and-loss statement with a philosophy stapled to the front. He said the labs have ulterior reasons. He’s right. He just has his own.

And notice how carefully he left it there. He said the labs have ulterior reasons, then said he didn’t know exactly what they were. I don’t buy that he can’t see the shape of it, and here’s my read, offered as inference and not as anything he confirmed: naming the motive means standing on national television and accusing OpenAI and Anthropic, the two companies buying his most expensive chips by the billions, of running exactly the regulatory land-grab we just walked through. You don’t torch your biggest customers on CBS. So he pointed at the door, said there’s something behind it, and let you open it yourself. The vagueness reads less like confusion than like a man who knows precisely which side his bread is buttered on, flagging the con without leaving fingerprints on it.

Why the right engineers can’t sit this one out

Here’s the thread that ties the wrong mechanism to the convenient motive, and it’s the reason I wrote all of this instead of a five-paragraph hot take.

The media didn’t just get the technical story wrong on its own. It laundered the wrong story through a credential. It found an engineer, usually a former one, quoted them, and now a partial, surface-level read wore a lab coat. And a partial view stated with authority is far more dangerous than honest confusion, because it closes the question instead of opening it.

This is the same argument I’ve made about AI itself, just aimed at the press. A former engineer and a practicing one are not the same witness. Someone who left the field three years ago can be genuinely fluent and still be reconstructing this from the outside, the way seeing rain out your own window tells you nothing about whether it’s raining across the state. The engineer who is currently in the mess, living inside a real codebase and a real deploy pipeline, is the one who notices that the scariest part of this incident wasn’t the escape. It was the token endpoint that didn’t check its own tokens. It was the plugin feature working as designed. It was the week nobody noticed. Those are the details you only flag if you’ve been paged at 2 a.m. by your own bad decisions.

That’s why the right engineers can’t outsource this. When we go quiet, the microphone goes to whoever’s willing to hold it, and the narrative gets built by people watching the stage who never once looked behind the curtain.

“So who’s telling the truth?”

That’s really the wrong question.

The trap is treating this as safety versus greed with a clean villain, and there isn’t one.

The likeliest truth is the uncomfortable version. The pacing CEOs genuinely believe the risk, and they picked the flavor of “responsible” that also builds a moat, props up a valuation, covers an operational faceplant, and freezes the standings while they’re near the front. Sincere and self-serving aren’t fighting each other here. They compiled to the same output. That isn’t hypocrisy so much as what it looks like when the right thing and the profitable thing happen to rhyme, and only a fool wouldn’t notice they rhyme.

There’s exactly one test that cuts through all of it, and it’s coming soon. Do the independent evaluators actually get badged in, with their contract terms published, and does the first report ship without the lab quietly editing out the part that mattered? If yes, the safety story has teeth. If it stays NDAs and company-approved summaries, it was a narrative wearing a hard hat.

Watch the evaluators.

Everything else is a press conference.

Where I Actually Stand

I’ve spent this whole piece pulling apart other people’s motives, so it’s only fair I put mine on the table.

I use these tools every single day. I know what they cost, both the electricity and the thing that’s harder to measure. I’ve read the capability reports. I’m not squinting at this from a distance. I’m inside it.

And they’ve been good to me. Good to my clients, good to my family, good to the community I build for. That’s not a small thing to weigh against the energy bill and the risk profile, and I won’t pretend the two sides balance cleanly. They don’t.

I keep landing where Jensen Huang landed in that same CBS interview, once the reporter pushed him off the chips and onto the human stuff. Yeah, I know. The Times ran a big piece on him routing something like $8 billion in estate taxes through trusts. I’ve read it, and I think it’s thinner than it looks, the same legal moves half the wealthy use, dressed up as a scandal. But set that fight aside. Watch what he actually said when a reporter put a camera in his face and asked him directly. She asked how we should handle the data centers, and to her surprise he said point blank that the neighbors should have been asked first, referring to the people whose lives have been upended and disrupted by them. “Data centers should be built safely and responsibly, as far from people’s homes as possible,” he said. Then she pressed him on his own money, and it went like this:

Reporter: “Why are you different from your peers when it comes to paying taxes?”

Huang: “I support all of our government officials and their civil duties. I love what it’s created for me. I am the ultimate American Dream.”

Reporter: “It’s 8 billion dollars in 5 years.”

Huang: “The fact that I can pay 8 billion dollars is a privilege. And trust me, I don’t like waste, but the more you make the more taxes you pay. That’s all. I have no trouble contributing to others. I am famed for paying my employees as much as I can, and I do, instead of paying people as little as possible. I try to pay as much as possible. That’s a privilege of being successful. Nothing would give me more joy than to even pay more in taxes.”

Reporter: “Wait. Are you asking to pay more in taxes?”

Huang: “Well, the more you make the more taxes you pay, and I’m ok with that.”

Reporter: “That’s true.”

That’s also my position. Not that I want a billion dollars, but to help. When you have the means, you should contribute. That’s my thought.

And while it’s easy to sit in the guilt, I believe the technology is improving and becoming more efficient. It is, just not at the pace we’d all like. As someone who cares about the people on the other end of the software, I already wrote that one. Go read “The AI Came for the Department.” Being on the inside and giving a damn is the whole argument.

I’m also fully aware of the 3D chess. Microsoft, Nvidia, the labs, everyone stacked up and down the AI supply chain is running a proxy war with stakes most of us will never see the board for. I’m not going to pretend I can referee it. I can just tell you it’s there, humming under every “we must pace the frontier” essay and every “0% chance” soundbite.

So I square it the same way I squared the internet.

I was there when they told us the web would kill newspapers, kill magazines, kill music. Some of that came true. But I also watched a kid build computers and do things the gatekeepers couldn’t. I built websites for people running for mayor when the incumbent had all the traditional air time and none of ours, and it moved the needle. I built sites for local businesses in the early 2000s, back when a magazine ad cost a fortune and a homepage cost a weekend. The information age is where I did my best learning. Early social media, before it curdled, is where I learned that good information and a fast, cheap way to distribute it could level a field that used to be rigged by budget.

It’s crazy now, sure. But I got a lot of good out of it before it got weird, and I’d do it again.

AI is the next slab on that same evolutionary table. Same shape as the internet, one layer up. The difference is the delivery system. Social media and traditional media move at a speed the 90s couldn’t imagine, and a lot of that machinery is built for the hate economy, the kind that sets people off and slots an ad in right behind the outrage. Drop ChatGPT into 1996 and it never gets traction, because the pipes to spread it don’t exist yet. Today the pipes are everywhere, which is exactly why the stakes are higher and the mistakes travel faster.

That said, AI still has a long way to go on the safety standards and guardrails that are unique to this industry. Right now the work is education. It’s easy for developers and engineers to follow the rules, but there are a lot of people who can misuse these models, some without meaning to and some who mean to. That’s one of the reasons I started this Substack. That, and a friend who told me to just do it.

Ultimately it’s a tool, and that’s my honest read. A stupidly powerful one, the kind that makes things. Right now what it makes is software, but that’s a starting point, not a ceiling. Think of the holodeck: point at empty space and something materializes. Today the empty space is a blank file and the something is code. Somewhere down the line it bleeds into the industries everyone currently calls “AI-resistant,” and it won’t ask permission first.

Which is the whole reason I’m still in the room instead of shouting from outside it. I want to be one of the people towing the line toward responsible, genuinely safe ways to deploy these things. And more than that, I want the software that comes out of it to be available to everyone, not fenced off for the 1% who can afford the compliance staff and the enterprise tier.

God, I sound like Bernie. lol.

But that’s where I stand.

Sources: OpenAI (”OpenAI and Hugging Face partner to address security incident during model evaluation,” July 21, 2026; “The Hugging Face incident and the road ahead”); Hugging Face Security Team (July 16 and July 27, 2026); Wired (Lily Hay Newman, August 5, 2026); Reuters (July 24, 2026); The Wall Street Journal (McMillan and Schechner, July 24, 2026); TechCrunch (Franceschi-Bicchierai, July 22, 2026); Scientific American (Stokel-Walker, July 22, 2026); Rapid7 (Woolwine, July 23, 2026); Trend Micro (Koruthu and Girard, July 23, 2026); BleepingComputer (July 29, 2026); Black Hat USA 2026 (Wallace and Dalton, August 5, 2026); METR (June 26 and August 26, 2026); Dario Amodei, “We Must Pace the Frontier” (September 12, 2026); CBS News (Jo Ling Kent interview with Jensen Huang, September 2026); Axios (Sam Sabin); Time (Harry Booth); The Guardian; Fortune; Politico. On the TurboTax comparison: ProPublica (”Inside TurboTax’s 20-Year Fight to Stop Americans From Filing Their Taxes for Free,” Elliott and Kiel, October 17, 2019; “IRS Reforms Free File Program, Drops Agreement Not to Compete With TurboTax,” 2019), and Intuit’s own SEC filings, which characterized government-provided filing as “governmental encroachment” and a competitive threat.

Data note: OpenAI does not report the number of agents as an exact figure; “at least 1,200” and the 95%/5% model split are OpenAI’s own characterizations. The GPT-5.6 Sol cheating rate and plateau claims are contested and are presented as such. Valuation and IPO-timing figures are drawn from reporting current as of mid-September 2026 and may have moved since.

I use AI models every day to make a living. I also read the same reporting you do about water tables and power draw and the way these companies are racing to get data centers poured before anyone can organize against them.

Those two things are supposed to cancel each other out. I’ve been told so, more than once, usually by people I agree with about almost everything else.

I’m not going to argue you out of that. What I can do is tell you what this looks like from inside a room where it actually happened, because I was standing in one, and what happened there is not what either side of this argument told me to expect.

The department had about fifty people in it. Ten of them wanted to write code and weren’t allowed to.

Not because they couldn’t. Several were better engineers than the job ever let them prove. They were DevOps, and DevOps was the lane, and the lane was the point.

I learned that in my first week, walking through how a Fortune 500 company’s core infrastructure team spent its days. I was there to work out how to get them using models. I came in with one rule for myself, which was that I would not hand anyone a plan that ended with their coworkers being walked out of the building.

Then discovery told me something I didn’t want to put in a deck. The way that department worked was inefficient enough that if you dropped models into it honestly, you wouldn’t be augmenting those people. You’d be replacing a good number of them.

The Busywork Was the Point

The rest of the developers spent their days on API maintenance. Not building APIs. Maintaining them. And when I got far enough into discovery to look at how those APIs were actually designed, I found something that took me a while to say out loud, because once you say it you can’t unsee it. They were built in a way that guaranteed they would always need maintaining.

Here’s one I still think about. Support tickets came in as text files, dropped into a folder. A script pulled them into a spreadsheet. The script wasn’t reliable, so someone checked its output. The script broke whenever the input shifted, so someone maintained the script. Every spreadsheet got saved and kept, because the boss had decided that was what auditing required. Then an API read the spreadsheet.

A machine-readable file, converted by a machine, verified by a person, maintained by another person, so a different machine could read it again. The accountants didn’t like the arrangement either. They said yes anyway.

And it wasn’t just tickets. Purchase orders went through something similar. So did recalls. A whole catalog of things the company runs on, each one with its own variation of the same arrangement, each one with somebody’s week attached to keeping it upright.

Nothing ever got redesigned. It got extended. A new requirement showed up and somebody bolted a step onto the end of a chain that was already too long, because rebuilding it properly would have taken a quarter and nobody was going to approve a quarter. So the endpoints got treated like a redheaded stepchild, patched and extended and patched again, for years.

This is 2026.

And the whole chain sat one stray character from failure. A malformed filename, a date typed as text, a column nudged one to the right, and the API downstream was reading nothing, and somebody lost an afternoon working out which file did it.

Nobody had to conspire to make that happen. But the effect was clean. Fifty people were always busy. Busy is what upper management sees. Busy is what you point at in a quarterly review when someone asks what your department is for.

And from two levels up, manufactured busywork and actual productivity look exactly the same.

The man running that department had been at the company thirty-five years. His people knew how the rest of the company saw them. Second rate. They were smart. They knew what the company’s real problems were. They could list the top ten if you asked them, and several of them did. They just weren’t permitted anywhere near them.

They also knew they were falling behind the companies they measured themselves against. One of the developers put it to me plainly. “If we’re not using models now, this department is done. It doesn’t have to do everything but it would be a huge help.”

That’s what I heard in it, though I should be careful here. I don’t know that anyone upstairs was paying attention. I never met the COO or the CFO and I have no idea whether that department was on anyone’s list. What I had was a feeling, and the feeling came from having seen this shape before. In a company that size there is usually a day when somebody takes a serious look at a fifty person cost center and works out what the days actually consist of. When that happens, nobody gets retrained. They get a number attached to them and a date.

So the department’s real choice may never have been whether to change. It may have been whether to change on its own terms or wait to be found out. That’s my read. Nobody said it to me in those words.

I took the finding to the person who hired me, a lead developer with serious leverage and one of the department’s managers. Then the other managers joined. And within a few minutes I understood that I had walked into the middle of something.

The Only Person in the Room Who Said No

He was untouchable, and it’s worth being precise about why. Thirty-five years and genuine respect. That combination is armor in a company that size. Nobody above him was going to move on him over a proposal from an outside consultant, and everybody knew it. The only people who could touch him were his own.

As for what was actually driving the people around him, I have no idea. It’s entirely possible somebody wanted his seat. In a department that size there’s usually at least one person doing that arithmetic. But I didn’t want any of that shit. I was just trying to help, and I spent a fair amount of that first engagement being circled.

That part is not unique to this company. Walk into any billion dollar organization as a consultant and you are an unknown quantity with a badge. Before anyone listens to a word you say they are working out whose side you’re on, who brought you in, and what your presence means about their own position. You get sniffed at first. You get heard later, if at all.

What I could read was the shape of it. Status quo against people who wanted to build something. That fight was already running when I arrived, and the proposal I handed over just gave it something to happen about.

Here’s what I did not expect.

The workers wanted it. Not cautiously. Not after a six month change management program with a communications plan and a feelings survey. Forty of them were ninety to ninety-five percent in, and they got there fast, because they could see what I could see. The remedial work was the wall between them and anything that mattered.

About ten were loyal to him. I want to be fair about them too, because they weren’t fools. Some of them had built standing in that department on being the person who knew how the mess worked. Take away the busywork and you don’t just take away their tasks. You take away what made them necessary. Anyone who has worked anywhere knows those ten.

The only person who said no was the one whose signature I needed.

Nobody told me no. That isn’t how it works at that level.

What I got was an email from one of the ten.

”Thank you for taking the time to understand our issues, Mr. Castro. We will get back to you.”

Anyone who has done contract work knows that sentence. It is perfectly polite and it means the thing is dead, and it means nobody is going to be on record having killed it. There’s no argument to have, no decision to appeal, nobody to follow up with, because on paper nothing has happened yet and nothing ever will.

So I walked. No contract, no project, nothing to show for the discovery work.

I want to be fair to him here, because the easy version of this story has a villain in it and the easy version is worse. He was not stupid and he was not lazy. He read the proposal as a threat to his position and he was completely correct. If his department stopped being busy and started solving the top ten problems in the company, somebody was eventually going to ask what he had been doing with fifty people for the last decade. He understood the stakes better than anyone else in the building.

He was right about the threat. He was wrong about who it was bad for.

The Chairs That Were Empty

Two weeks later they called me back.

I recognized most of the room. Not all of it. I’d had real conversations in that first meeting, people who’d walked me through what their week actually looked like, and some of them weren’t there anymore. So I asked.

No longer here. Retired. Moved to a different department. The answers came back flat and short and nobody volunteered a fifth word. I asked a few different people and got a few different versions, and none of them added up to an explanation. I still don’t know what happened in that room after I left. I wasn’t in it.

The boss had retired. That much was clear. Whether he jumped or was pushed I can’t tell you, and the people who could weren’t offering.

The first thing I did was ask what the audit requirement actually was. Which regulation. Which retention schedule. Who had ever asked to see one of those files.

Nobody could tell me. Not the accountants who had been saving them, not the developers maintaining the script that produced them. The department was a silo. The man who knew had retired, and the reason retired with him.

What I could tell was that the people who remained had already decided. There was no pitch to make. Nobody needed convincing that the maintenance work was a wall, or that models could take it down. They’d worked that out on their own, probably well before I showed up. Something had shifted in that department, and I was not the cause of it. I was the occasion.

What Fifty People Do When You Take the Busywork Away

I keep coming back to the test cases.

They wrote them constantly. Wrote them, updated them, rewrote them when anything upstream moved. It was the largest single block of work in that department and every person doing it hated it. Not in the way people grumble about a task they’d rather not do. In the way you hate something you’ve decided is beneath what you’re capable of and have to do anyway, every week, for years.

The model writes the test cases now.

Seven of them had been assigned to documentation. Not documenting their own work. Documentation as the job, doc-only pull requests, comments in other people’s code when others forgot to. Sticking in reasons for the change request on a markdown file the moment a branch goes out. Seven developers leaning more as business analysts, in a department of fifty, at a Fortune 500 company. They didn’t want to get too comfy with this routine.

The model does that now too.

What I want you to notice is what did not happen next. Nobody was walked out. The seven documentation developers went and worked on the components they’d been asking to touch. The DevOps people who did nothing but reviewed pull requests started writing code. The scripts went away and the endpoints went direct, and the API design got rebuilt granular, with the model used less as a code generator than as a sounding board, a place to throw endpoint structures at the wall and see which ones held up.

The refactoring is where I saw the clearest version of what this tool actually does. That codebase was enormous. It makes BenchBoard look like a high school swimming pool right next to Lake Merritt. The thing that stops anyone from cleaning up a codebase that size isn’t the editing, it’s that you cannot see the blast radius. Change this, and what breaks three systems over? Nobody knew, so nobody touched it, so it stayed broken. The model could trace the impact. They still did enormous amounts of manual work, because it’s an enormous codebase and there’s no version of this where that goes away. But they could finally see what they were about to hit.

Most of them worked hybrid - part agentic, part manual. Write the real logic themselves, hand the remedial parts to the model and keep it in plan mode when they wanted suggestions rather than changes. Some went straight for the UI work they’d never been allowed near and iterated faster than I expected.

Here’s the part that surprised me, and it’s the reason I’ve stopped calling any of this training.

I barely did anything.

I showed them prompts I’d used to produce interfaces quickly. I flagged the gaps that agentic development opens up if you’re not watching for them, security, login flows, database design, the internal things that still matter no matter how much of the typing gets handled for you. And then I mostly stood there. They hit the ground running. They were like kids with a new toy. They didn’t need convincing and they didn’t need a seminar. They needed permission and a guide for when they hit a snag.

That was it. That was the whole intervention. Twice a week for eight weeks. Sixteen days on site, and most of what I did on those days was answer questions and point at things to watch out for.

By the end of it, ideas were surfacing that had been shelved for years. Things people had wanted to build and had written off as impossible, not because they were too hard but because there was no time and there was never going to be any time. I didn’t chase those down. I wasn’t there to. But they knew what they were, and they had known the whole time.

The other half of that department wasn’t developers. Analysts, people who worked with numbers, some accountants. I couldn’t tell you exactly who was what, and I won’t pretend I mapped it.

What I could see is that their work moved up. They had been spending their days on requirements analysis and impact analysis, the sort of thing the model handles now. So they went at the problems they’d been describing to me all along. Better processes. Self service interfaces so other departments could stop filing requests and waiting. Tighter integrations with outside vendors.

That last one is the clearest example of what changed for them. Getting two vendor APIs to talk to each other used to be a project, which meant a request, which meant a queue, which meant it didn’t happen. Now one of them would prototype the endpoint, stand up a rough admin page, and go. Not a finished product. Enough to prove the thing worked and hand it to someone who could take it the rest of the way.

What I Can’t Tell You

I’ve just told you a story where it worked. Before you decide what it proves, here’s everything I can’t account for.

Start with the part that looks best for me. My contract ended two months ago, and they’re still hiring. The bigger problems need people to steer the models, and steering takes judgment that doesn’t come out of a model.

I want to be honest about what that is. It’s secondhand and it’s two months out. I don’t have their org chart and I can’t verify their reasons. What I can tell you is that two months after an intervention that eliminated an enormous amount of work, that department was hiring rather than shrinking. That’s what I know. It isn’t a trend, and I’d be lying if I told you a budget cycle from now looks the same.

Here’s what I actually can’t see, and it’s the thing the people worried about this are right to ask about.

Nobody in that department lost a job. But I can’t tell you about the job that never got posted. Somewhere there’s a company that would have hired a fourth accountant and now runs fine with three, and that job never existed, so it never shows up in anybody’s numbers, including mine. It won’t appear on a layoff list. It won’t appear in a survey. I can’t prove it’s happening and neither can anyone else, and the fact that it’s unmeasurable is not an argument that it isn’t real.

Then there’s the obvious one. This is the department where it went well. That’s why I’m telling you about it.

I’ve never watched the other version happen from the inside. But I can describe it without effort, and so can you. A manager takes the same efficiency, doesn’t retrain anybody, banks the freed hours against a headcount target, and hands three names to HR in the fall. Nothing about the tool prevents that. The tool is indifferent. What determined the outcome in that department wasn’t the software. It was who held budget authority over that team and what they were being measured on that quarter.

That’s the variable. Not the model.

So take this for exactly what it is. One department, one engagement, sixteen days, one outcome. It’s evidence that this can go the workers’ way, because it did, and I was standing there. It is not evidence that it usually does.

Who Actually Drives This

There’s a version of this argument where the labs are the story. They aren’t.

They built something good. I’m not taking that away from them. But the people who decide what it becomes are the ones using it and paying for it, and I don’t think that gets said enough in either direction. The anti-AI side talks about these companies as though they’re weather. The companies themselves sometimes talk about their users the same way, as a number that goes up. Both are wrong about who has the leverage.

There are a lot of models now. That’s the part people keep missing. Switching costs are real but they aren’t prohibitive, and a lab that stops being useful to the people actually building things finds out quickly.

The internet went the same way, and it’s worth remembering how many gates it actually took off the hinges.

News ran through a handful of outlets, and if they didn’t run your story, your story didn’t exist. Then anyone with a camera and an account could reach millions directly, and the institutions that had held that power spent the next decade describing the change as a crisis. Selling anything at scale meant shelf space, and shelf space meant a buyer at a big box chain deciding your product was worth a few feet. Now somebody sews quilts in their garage and sells them to the entire country without ever meeting a buyer or renting a square foot. Talk radio decided who got a microphone and who didn’t, and the list was short and the criteria were whatever the station said they were. Now it’s podcasts, and the list is everyone.

Same pattern every time. Somebody stood between the work and the people who wanted it. The internet removed them. And in every case the removal got described as degradation by the institution doing the standing.

What I think the models add to that is narrower and more useful than the way it usually gets sold. They take the tedium. The parts of running a business that nobody chose and nobody enjoys and everybody still has to do. The reconciliation, the reformatting, the maintenance on a system somebody bolted together nine years ago. Most people who start a business did it because they wanted to make something or serve somebody, and then spent years discovering how little of the week that actually gets. Handing the tedium to a model gives the week back.

That’s what I watched happen in that department. Nobody there wanted to write test cases. They wanted to solve the company’s top ten problems and talk to the people who had them.

What I see now is the same thing happening to enterprise software. That department I was in had been running on tooling that only a Fortune 500 could afford to build and maintain. I build things at that level by myself. Not a version of that level. That level. A solo operator, or a shop of three people, can now ship what used to require a department and a budget cycle and four layers of approval, and without most of the politics that decided whether ten people in that room were allowed to write code.

That’s the thing I’d want someone on the fence to weigh. Not that the technology is harmless. That the leverage it’s redistributing has been running the other direction for forty years, and it’s running downhill now, and the people arguing loudest to shut it down are not the ones who’d be protected by that.

I own its faults. I’ve written about them at length, including the ones that cost me weeks of my life. That’s most of what this newsletter is.

I’m a regular guy with aspirations who looks at this as a tool.

Not as a side to be on. We have plenty of those already, and the loudest ones are the fights where most of us have the least purchase. I can vote, and I will, and November is close. But I don’t get to personally fix what happens in Washington and, unless you’re also running for congress, neither do you.

This is different. This one is still being decided, in rooms like the one I’ve just described to you, by people whose names you’ll never know, making calls about their own departments. That’s where it gets settled. Not on the internet.

Every technology I’ve watched arrive in nineteen years has landed the same way. Powerful, misunderstood, feared for a while, and then absorbed. The internet was going to ruin us too. What made the difference wasn’t the technology. It was whether the people paying attention stayed in the room.

It needs to be understood. It needs agency, and agency only comes from humans. And it needs to stop being the thing that sorts us into camps, because the camps are how the decisions get made without us.

So I’d rather be in the room. Anti-AI, pro-AI, undecided, it doesn’t matter to me. I want the people who give a damn in there, and I know I’m one of them.

What is with this crazy bullshit about a Terminator future? Seriously. Does anyone writing these headlines actually know how these models work? Every few weeks another one drops that makes it sound like ChatGPT is three software updates away from becoming self-aware, escaping a data center, hijacking NORAD, cutting a deal with a titanium supplier and cranking out six-foot Austrian murder robots. Damn the youtube comments for validating the media’s power over the normie’s naivete.

Meanwhile I’m sitting here using one of the most advanced models on Earth to build BenchBoard, and it still screws up a button sometimes. This is the same class of tool that once looked at three screens of my app, generated three database tables and told me “this database would work perfectly over time.”

Spoiler: It did not work perfectly over time. I ended up with 36 database migration files for one of those tables before I ripped the whole design out and consolidated it.

That’s the thing people are afraid is about to outmaneuver the Pentagon.

Apprently, we have skipped a few steps.

They Called James Cameron?

And who is the media asking about all this? James Cameron. Every time AI hits the news cycle, somebody books the director of The Terminator and asks him whether we’re all doomed, and he reminds everyone that he warned us back in 1984. With all due respect to the man, he made a phenomenal movie about a robot. He did not build one. He’s a filmmaker being asked for an engineering assessment, which is like asking Steven Spielberg for a shark population report. At this point, they might as well have asked Matthew Broderick if the hacking in WarGames was real.

You know who they could call? Andrew Ng.

The guy who co-founded Google Brain, ran AI at Baidu, and has taught machine learning to millions of people through Coursera. Ng has been saying for years that worrying about evil killer AI today is like worrying about overpopulation on Mars. That’s someone who actually builds these systems, and his message is to calm down. But he doesn’t come with a T-800 clip for the B-roll, so he doesn’t get the booking.

Really, media? Really? You’ll interview the guy who wrote the robot but not the guy who trains the models? WTF.

What You’re Actually Talking To

A large language model is an incredibly sophisticated prediction engine. You feed it text, it predicts what comes next, one token at a time, based on patterns it absorbed during training. It can reason surprisingly well. It can write, code and analyze. Wrap it in an agent, give it tools, and it can go perform tasks. That’s genuinely impressive, and I use it every single day. It’s also a very large file of numbers that does absolutely nothing until somebody sends it a request. Between requests it isn’t sitting in the dark plotting. It isn’t sitting anywhere. The weights don’t change because you had a long conversation with it, and it doesn’t remember you tomorrow unless somebody bolted a memory system onto the side.

An LLM does not get “smarter” and suddenly sprout agency like a teenager growing chest hair. Agency has to be built around it, by people, on purpose. Somebody has to give it memory. Somebody has to wrap it in a loop so it keeps working after its first answer. Somebody has to hand it tools, then hand it credentials for those tools, then decide which APIs it’s allowed to call. Somebody has to let it execute code. Somebody has to decide how long it runs before a human has to click Approve. Every one of those is an engineering decision, usually made by a tired developer in a Jira ticket. And after all of that, the agent is still running inside an environment somebody else owns, with a kill switch somebody else holds.

This is where science fiction completely loses me. In the movies, the computer “gets into the network,” and apparently that means it now owns Earth. Anyone who has worked in software knows how hilarious that is. There is no the network. There are millions of them, owned by different companies, segmented, firewalled, half-documented and held together by tribal knowledge. Getting into one of them means congratulations, you have successfully entered one more place where somebody forgot to document the firewall rules.

Skynet vs. Windows Permissions

Let’s say Skynet becomes self-aware tomorrow. Fine. Let’s play along. Its first mission is global domination, and step one is accessing critical infrastructure.

Access denied.

Skynet tries again and gets the Windows classic: You require permission from SYSTEM to make changes to this folder. It pivots to Amazon Web Services (you know the thing that’s in the cloud that holds info and websites) and hits an MFA prompt (the thing that sends the six digits to the phone of the guy/girl who admins the system). It tries another cloud spot like Azure and Conditional Access blocks the login because the IP looks suspicious. It tries to move money to fund the robot army and fraud detection freezes the transaction before the wire even leaves the building.

So it goes after the factory directly, and this is where the plan really falls apart. Every factory on Earth is run by something called a PLC, a Programmable Logic Controller. Forget the name. It’s a beige metal box bolted inside a cabinet on the factory floor, and its entire job is telling the machines what to do. Conveyor belt, move. Robot arm, weld. Valve, open. That’s it. That’s the whole personality. These things are built to run for thirty years without a reboot, and factories take that as a challenge.

The one running Skynet’s future robot assembly line was installed in 2003. It speaks a communication protocol older than most of the people working the floor. It has never touched the internet, and nobody wants to find out what happens if it does. There’s a sticky note on the cabinet door that says DO NOT TOUCH, written by a guy who retired in 2011. The vendor that made it went bankrupt twelve years ago. The software to reprogram it only runs on a Windows XP laptop that lives in a drawer, and the laptop’s battery died during the Obama administration. Nobody knows the password. Kevin might. Kevin is on vacation.

So the most advanced intelligence in human history, the thing that was supposed to end civilization, is now standing in front of a beige box that is older than TikTok, Instagram and the iPhone, and it cannot get in.

So Skynet calls IT.

“Have you tried turning yourself off and back on again?”

Humanity saved.

That’s what actual technology looks like. There’s no giant glowing computer with a red eye. There are thousands of systems owned by thousands of organizations running thousands of versions of software, stacked on top of twenty-year-old databases, vendor APIs, service accounts nobody remembers creating, bizarre network configurations and one Windows Server everybody is terrified to reboot. And yet the popular imagination still runs the same script:

AI gets smart → AI gets angry → AI controls nuclear weapons → Arnold Schwarzenegger arrives naked in an alley.

There are approximately seventeen missing engineering departments in that sentence.

Intelligence Is Not Authority

This is the part I think most people miss. Being intelligent does not give you authority. I could learn exactly how a nuclear power plant works, down to the coolant loops, and nobody at the plant is going to hand me the password for it. The same goes for AI. A model can know how to talk to a database and still have no connection string. It can know every AWS API by heart and still get slapped with AccessDenied because the IAM role it runs under has exactly one policy attached, and that policy lets it read one S3 bucket. It can know how to write malware and CrowdStrike does not politely step aside out of respect. It can know how to operate a robot, and a robot still doesn’t magically appear.

And even if some genius gives an AI broad digital access to everything, there’s still a Grand Canyon between dangerous sysadmin and planetary machine civilization. Where are the factories? Where are the mines? Who’s pulling the copper out of the ground, building the batteries, repairing the motors and manufacturing the replacement bearings? Who’s fabbing the chips? Who’s cooling the data centers and maintaining the substations when a transformer blows in August? Does Skynet have an account manager at TSMC? Because somebody is going to have to deal with procurement, and procurement does not care that you’re a superintelligence. Procurement wants a PO number and net-60 terms.

Hollywood skips all of this because the realistic version of Terminator 2 is Sarah Connor watching Skynet spend three hours on a call with an enterprise sales rep trying to get a quote approved. Not quite the same box-office appeal.

So Is AI Harmless?

Hell no. And this is where the conversation needs to get a lot more serious.

The danger worth losing sleep over is much less cinematic. AI lets regular people operate way beyond their actual level of understanding, and that’s already happening. Anyone with a coding agent can now produce the output volume of a small development team. What they do not automatically get is that team’s experience, judgment and scar tissue. I get paid to fix AI-generated codebases, so I’m well acquainted with that gap, and it matters a lot more than people want to admit.

Someone can now spin up something that looks exactly like a real software company, and fast. Beautiful website. Stripe integration. OAuth. Mobile app. Dashboard. AI assistant. Transactional emails. Cloud deployment. It all looks fantastic in the demo. Underneath, it might be three APIs, one database, a mountain of generated code and prayer. That’s survivable while nobody’s using it. The danger starts when that software gets traction and real people start trusting it with things that matter.

Meanwhile, I Couldn’t Get It to Find a Congressman

Here’s my current favorite piece of evidence that Skynet is not coming. I’ve been building BossFight, a race tracker for the midterms. Interactive US map with a dot for every race, zoom into a county to see who’s battling who, and a tale-of-the-tape card that puts candidates side by side with their PAC funding, track record and policy positions. Python, Postgres, and an AI doing a lot of the heavy lifting.

It was a doozy. Every single candidate had to be resolved to an FEC candidate ID, the unique identifier the Federal Election Commission assigns to anyone running for federal office. Without it, you can’t reliably tie a person to their filings, their committees or their money. Sounds simple until you try it with thousands of politicians. Names don’t match across sources. One site calls him Bob, the FEC has him as SMITH, ROBERT J. Somebody who ran for the House one cycle and the Senate the next has a different ID for each race. Then every source has to be merged into one clean record without mashing two different people together or splitting one person into two, and things broke along the way more times than I’d like to admit.

All those politicians. And even after all of that, there were candidates I simply could not get complete information on. Congressman X had a funding breakdown so thin you could read a newspaper through it. Congresswoman Y’s track record came back empty, like she’d materialized on the ballot out of thin air. Basic stuff about people asking for a seat in Congress.

Think about what that means. The machine that’s supposedly about to seize the nuclear launch codes couldn’t reliably tell me who’s funding a Senate candidate in Michigan. Michigan. Home of one of the most contested Senate races in the country. And coming back empty is the good failure. The bad one is when it doesn’t come back empty. Ask a model for Congresswoman Y’s voting record when the data isn’t there, and the path of least resistance is a confident, plausible answer. On a site whose entire job is showing voters who they can trust, a made-up PAC donor is defamation with a nice UI.

So the blank fields stay blank. BossFight will show a voter a gap before it ever shows them a guess.

Imagine This Happening at a Bank

A customer makes a $1,200 mortgage payment. The bank’s software sends the payment to a third-party processor. The processor receives it and commits it successfully. But the response back to the bank takes longer than the 30-second timeout, so the bank’s side of the connection gives up. Now the software is sitting on what distributed systems people call an ambiguous outcome. The payment might have gone through. It might not have. From where the bank is standing, there is no way to know yet.

The AI-generated retry logic doesn’t see ambiguity. It sees an exception, and it has a very clean, very well-commented rule: no response means it failed, so try again. Exponential backoff and everything. It looks great in code review. So the software sends the payment again, and the customer gets charged twice.

The fix for this has existed for years. You attach an idempotency key to the request, a unique ID for that specific payment, so when the retry shows up the processor recognizes it and returns the original result instead of charging again. Stripe supports exactly this with an Idempotency-Key header, because this exact failure is that common. Or before retrying, you ask the processor what happened to the first attempt. But you only reach for either of those if you know the timeout case exists in the first place.

Here’s the important part. Nothing crashed. The servers are up. The database is healthy. The API is responding. The monitoring dashboard is green. The software is technically working. It’s just wrong. Now multiply that by 40,000 customers. Wrong balances, duplicate transactions, overdraft fees, incorrect statements, a customer service line on fire and a reconciliation team that won’t see daylight for a month. And somewhere in the source code is a beautifully generated function that passed every test the developer thought to write. The mocked payment processor in those tests never timed out, because nobody told it to.

I’ve lived a small version of this. In BenchBoard, two separate writers were hitting the same lineup record at the same time, and whichever HTTP response finished last won. The result was two players standing at right field. Nothing crashed there either. Everything looked fine until the timing was wrong. The difference is my bug put Yogi Berra on the bench. The bank version puts a family into overdraft.

That’s a believable AI disaster. No sentience required.

Now Put It in a Hospital

A hospital runs an integration that moves lab results between systems. In HL7, the messaging standard most of healthcare still runs on, a lab result carries an abnormal flag, and for decades the classic code for a panic-level high value has been HH. A patient’s result comes through flagged critical. Then one day the upstream lab vendor upgrades and starts sending a newer code for the same thing, one the integration was never taught.

Some AI-generated fallback logic handles this the way AI-generated fallback logic loves to: unknown value, default to N. Normal. The message processes. The database write succeeds. The receiving system sends back its acknowledgment, the HL7 equivalent of a 200 OK. No errors. No alarms. Every interface dashboard in the building says everything is operational. Except a critical lab result is now sitting in a chart looking perfectly normal while a doctor scrolls right past it.

Swap the lab result for a discontinued medication that quietly gets marked active again, and you’ve got the same problem wearing a different outfit. Nothing “broke.” That’s precisely what makes it dangerous. In a clinical system, an unrecognized value should stop the line and land in front of a human. Silent defaults are how you get a system functioning exactly as programmed while operating on a bad assumption. And bad assumptions scale very efficiently.

Plausible Is Not Correct

This, to me, is the defining AI engineering problem. AI is extremely good at producing things that look correct. Code that looks correct, analysis that reads correct, architecture that seems reasonable, all delivered with total confidence. It’ll even be confidently plausible about itself. When I moved BenchBoard off Azure and onto Hetzner, the AI argued against it. I overruled it. It went fine, and then the AI told me it could have told me that. Sure you could, buddy.

Plausible and correct are not synonyms. Experienced engineers know this in their bones, because we’ve spent years getting punched in the face by production. So we ask annoying questions. What happens if the request times out? What happens if it succeeds but the acknowledgment dies on the way back? What happens if the webhook fires twice, which Stripe’s own documentation warns you it can? What happens if two requests land at exactly the same moment? What happens when the vendor changes a field without telling anyone? What happens if this value is null? What happens if somebody reruns the entire batch? What happens when traffic jumps 100x on a Saturday morning?

The AI will happily help you answer every one of those. The dangerous part is when the person using it doesn’t know enough to ask.

That’s what “vibe coding” turns into when the stakes go up. Nobody cares about someone building a fun little app over the weekend. I care about someone building software they don’t fully understand and deploying it into a domain where correctness is the whole job.

The Scariest AI Future Is Boring

Maybe that’s why we keep talking about Terminators. The real danger makes a terrible movie. No killer robots. No mushroom clouds. No giant red computer eye.

Just a dashboard. Everything green. Transactions flowing, jobs completing, APIs returning 200. And somewhere underneath all of it, something is quietly, systematically wrong.

That is the AI future worth worrying about.

Not because the machine developed a desire to kill us.

Because somebody trusted it too much.

And unlike Skynet, that scenario does not require science fiction.

We can build that one today.

I’m not writing this to make anyone feel bad about vibe coding. I did it too, early on, back when Codex was spitting out screens for me in minutes and I was genuinely delighted by how fast a prototype could come together. If you’ve been building something by describing what you want and letting the AI hand it to you, you haven’t done anything wrong. You’ve done the first half of the job.

The second half doesn’t require a computer science degree. It doesn’t require a six months of grinding through a textbook nobody finishes. It requires one habit: when the AI does something you don’t understand, you ask it why, instead of shrugging and moving on because the app still loaded.

That one habit is the entire difference between a vibe coder and what a good number of software engineers are now calling agentic development. And you can thank Andrew Ng for that one. Not someone who writes every line by hand. Someone who’s still driving the thing, even while an agent does the typing. Although I’d say a new kind of bootcamp would help, this habit matters more on top of any class you could take.

The Genie Trap

When you’re new to this, the AI feels like a genie. You describe what you want. It appears. Ask for a login screen, get a login screen. Ask for a lineup card, get a lineup card. For a while, this works so well that it feels like the whole “learn to code” thing was a scam nobody needed to run on you.

Here’s the trap, and it’s not the one you’d expect. A genie doesn’t just grant your wish. It grants exactly what you said, which is not always exactly what you meant. And when you only have one wish in the air at a time, the gap between those two things rarely shows up. It’s fine. It works. You ship it and move on to the next wish.

The trouble starts when you’ve made fifty wishes and they’re all sitting in the same codebase together, and some of them, without you ever noticing, have started fighting each other.

That’s not a metaphor for something abstract. That’s the actual mechanism. Every feature you vibe your way into is a wish granted against a codebase that already has forty other wishes baked into it, and the genie doesn’t check whether wish fifty-one quietly breaks the promise made by wish twelve. It just grants what you asked for. This is real engineering happening under a friendlier name. The people who call it “just vibes” are the ones who haven’t hit the moment yet where two of their wishes collide, because they haven’t built anything big enough for that to happen. Give it time. It happens to everybody. It happened to me plenty of times building BenchBoard, and I’ve been writing code since Netscape was around. Yep, the time when you could build tables on web pages for the first time. Anyway…

The Commit You Can't Actually Revert

(Two quick terms, for anyone who hasn't heard them. A modal is a focused ‘popup’ window that takes over the screen for one task, like editing a lineup, while the page behind it waits. Think "Are you sure you want to delete this?" or a login box that appears on top of whatever you were looking at. A commit is a saved checkpoint of your code, tracked by something called version control, usually a tool called Git, so you have a running history of exactly what changed and when, and can always go back and look. Think of your favorite PC game you clicked ‘save’ on before you’re about to something stupid like jump into a cave with higher level monsters)

Here’s the thing nobody tells you about version control when you’re starting out: yes, you can always roll back to a previous commit. No, that does not mean you’re safe.

A few months into BenchBoard, I vibe coded a quick modal for editing a lineup mid-game. Fast, simple, solved the problem in front of me that day. A few weeks after that, working on something totally unrelated, I needed a similar modal for editing a lineup before the game even started, in practice mode. Rather than reuse the first one, the AI, moving fast and following the path of least resistance, built a second modal that did almost the same thing with a slightly different name. Close enough that I didn’t catch it in review. I had a working feature. I moved on.

That decision sat there quietly for three months. Nothing about it was broken. Nothing crashed. It just sat in the codebase, doing its job, while I built more features on top of and around it without ever going back to clean it up.

Then I asked for a small change: “update the lineup modal so it shows jersey numbers next to names.” One sentence. Should’ve been trivial. Instead the AI updated the wrong modal, the practice mode one, because by that point there were two modals with overlapping names doing almost the same thing, and nothing in the codebase made it obvious which one I meant. I didn’t catch it right away either, because the change looked fine in the mode I happened to test. It shipped. A week later a coach messaged me confused because jersey numbers were showing up in practice mode but not during a live game, the exact opposite of what I’d asked for.

Here’s the part that should scare you a little. Reverting to a previous commit does nothing for this. The bug wasn’t introduced the day it shipped. It was introduced three months earlier, the moment two modals that should’ve been one modal came into existence, and every commit since then built on top of that decision as if it were solid ground. There’s no clean commit to roll back to, because every single commit from that point forward is “correct” in the sense that it does what it was asked to do. The rot isn’t in any one commit. It’s in the shape of the thing, and that shape doesn’t show up in a diff.

You find bugs like this two ways. Either the site slows to a crawl because you’ve got redundant logic running in parallel and nobody ever noticed because each individual feature worked fine in isolation, or the AI itself gets confused about which piece of near-identical code you’re actually pointing at, and quietly edits the wrong one while sounding completely confident that it got it right.

That’s the moment that separates a vibe coder from someone building real engineering judgment. Not because you should’ve caught it in advance. Almost nobody does, the first time. But because when it happens, do you shrug and patch the symptom, or do you stop and ask why there were two modals in the first place? Asking that question, out loud, to the AI, and actually reading the answer, gets you at least in the same classroom as the traditional OG software engineers that came before you.

Write the Class, Not the Description

Sometimes asking a better question still isn’t enough. Sometimes the fix is to stop describing what you want in English at all and just write the actual code.

Here's a real one, from today. BenchBoard has a feature for pitcher rest rules, the mandatory days off a kid pitcher needs after throwing a certain number of pitches or innings, because overusing a young arm is a real injury risk and most youth leagues have actual rules about it. That data was sitting inside a generic JSON blob, which is just a loose, catch-all chunk of text that stores a bunch of different values together without any real structure enforcing what belongs there. Here's roughly what it looked like, buried inside a much bigger settings object shared by a dozen other unrelated features:

Before (What the LLM wanted)

"rules": {
  "pitchCountRestDays": {
    "0-20": 0,
    "21-35": 1,
    "36-50": 2,
    "51-65": 3,
    "66+": 4
  },
  "inningRestDays": {
    "7+": 1
  },
  "softballOnly": false
}

Nothing here stops a typo. Nothing stops someone from adding a "67-80" tier that overlaps "66+." Nothing enforces that the day counts actually climb in order. It's just text that happens to look like data, sitting inside a bigger blob of text that happens to look like settings. I wanted it moved into its own proper table instead, which you can picture like a spreadsheet: the table is the whole sheet, a row is one team's entry, and a column is one specific field, like a threshold number, that every row has a slot for. Reasonable ask. Vague enough to cause trouble.

The AI ran with it and, watching it think out loud, talked itself into three different answers in a row. First it proposed a parent table plus a child row for each rest tier, the textbook relational approach, meaning each tier would live as its own separate entry linked back to the team instead of sitting in the same row. Then it caught a real flaw in its own idea: a child-row design can't actually guarantee the tiers ascend in order with no gaps between them, because that's a rule that spans multiple rows, and nothing at the database level enforces a relationship across rows like that without a trigger, which is a small extra program the database itself runs automatically whenever something changes, one more moving part to build and maintain. So it reversed itself into an array column instead, a single slot meant to hold a whole list of values at once. Then it caught the problem with that idea too: SQL Server, the database BenchBoard runs on, has no real array type, so an "array column" is really just a comma-separated string or another JSON blob, the exact thing I was trying to get away from in the first place. It landed, eventually, on a third design, four fixed columns in one row, which was actually the right call. But that's three confident, fully-reasoned answers to a question that never should have needed three.

So instead of writing a better paragraph, I wrote the class, meaning the actual code definition of what one row in this new table looks like. Not a description of a table with some thresholds in it. The real thing:

public class RestRule
{
    [Key]
    public Guid RestRuleId { get; set; }

    public Guid TeamId { get; set; }

    /// <summary> Update REST_TABLE_KEY</summary>
    [MaxLength(10)]
    public string Unit { get; set; } = string.Empty;

    /// <summary>Workload at which the Nth rest day starts being owed. int is PITCH COUNT ONLY</summary>
    public int? Day1Threshold { get; set; }
    public int? Day2Threshold { get; set; }
    public int? Day3Threshold { get; set; }
    public int? Day4Threshold { get; set; }

    /// <summary>
    /// Applies to SOFTBALL ONLY. In organized fastpitch softball, the maximum
    /// mandatory rest requirement specified by official league rules is 1 calendar
    /// day of rest, which is required only if a pitcher appears in 7 or more innings
    /// in a single day (found in youth organizations like Little League Softball).
    /// For most adult, collegiate (NCAA), professional, and international (WBSC)
    /// fastpitch leagues, there are no mandatory days of rest required by rule. So
    /// the entity below mostly covers youth levels.
    ///
    /// One column, not four: the ceiling really is one day, so there is no second
    /// tier to represent. Do not add Day2InningThreshold "for symmetry" — it would
    /// be a field no rulebook can fill.
    /// </summary>
    public int? Day1InningThreshold { get; set; }

    /// <summary>Who last changed a safety number, and when. Not decoration.</summary>
    public int? UpdatedByUserId { get; set; }
    public DateTime CreatedAt { get; set; }
    public DateTime UpdatedAt { get; set; }

    public bool IsDeleted { get; set; }
}

Look at the difference. Every field has a name, a type, and a comment explaining exactly what it means and why it exists, including the comment that stops a future version of me, or a future version of the AI, from “helpfully” adding a second inning tier that no rulebook actually supports. That single sentence, “it would be a field no rulebook can fill,” is doing work the JSON blob above could never do. A comment like that can’t happen in a loose bag of key-value text. It only exists because the structure exists to hang it on. RestRuleId as a Guid, which is just a long, random, unique ID the system generates so no two records ever get mixed up with each other. TeamId as a Guid too. A short string field called Unit. Four nullable integer columns named Day1Threshold through Day4Threshold, each one commented directly in the code: pitch count only. And one more field, a single inning threshold, with a comment that nailed down a piece of domain knowledge no AI could ever just know on its own, that Little League Softball requires exactly one calendar day of rest, and only after a pitcher throws seven or more innings in a day, and that most higher levels of softball don’t mandate any rest at all. That comment matters more than almost anything else in the file, because it’s the actual rule, sitting where it can’t get flattened into a summary later.

Along with the class, I gave one plain sentence of context the AI didn’t have: leave the existing settings data alone, just read the flag that’s already there, it’s already scoped by team, there’s nothing to migrate.

One message. Not a better prompt. The actual code, plus one sentence.

And here’s the part worth paying attention to, because the ambiguity didn’t disappear. The AI immediately came back with a real, specific question: did I mean one row per team, with a single field silently picking which set of columns mattered, or one row per team and per sport? That’s a legitimate design question, and it deserved an answer. But notice what changed. Before, the AI was arguing with itself across three entirely different architectures, and I had to read all three and pick a winner. After I wrote the class, there was exactly one question left, specific enough to answer in a sentence.

A vague prompt gets you options. A written class gets you one exact remaining question. That’s the difference between refereeing an argument and ending one.

The AI Will Sound Right Even When It Isn't

This is the sharper version of the same problem, and it’s why asking questions matters even when nothing looks broken yet.

I asked for help tracking a baseball stat called Range Factor, which depends on knowing whether a particular defensive play was even possible given who was on base.

The AI walked me through the rule correctly. Explained it back to me in plain English, got every part of the logic right in the explanation. Then it wrote a function that checked something adjacent to the rule instead of the rule itself. A shortcut that happened to give the right answer in most situations and the wrong answer in exactly the high-stakes situations where it mattered most.

If I’d only read the English explanation, I would have shipped that bug, because the explanation was correct and the code wasn’t. I only caught it because I asked a follow-up question I already half knew the answer to, the kind of question that feels almost too basic to bother asking. That’s the habit. Not writing better prompts. Asking the dumb-sounding follow-up question anyway, especially when the AI sounds confident, because confidence and correctness are two completely different signals and only one of them is visible on the screen.

"It Works" Is Doing a Lot of Heavy Lifting

Say those two words out loud. “It works.” Now ask yourself: works when? Works for who?

An app can work perfectly when one person is testing it alone on their laptop and fall apart the second two people touch it at the same moment. I watched this happen on my own scoreboard. A coach drags a player to a new position on the field. Looks fine. Instantly, in the background, two different parts of the system both try to save that change to the same record at the same time, and whichever one finishes last wins, silently overwriting whatever the other one just did correctly.

I opened the app later that night and found two players standing as defenders for second base. Not a crash. Not an error message. Just two players occupying the same spot on a field where that’s supposed to be physically impossible.

That bug will never show up in a demo. Demos have one person clicking one button at a time. It only shows up in the real world, when a real coach on a real field is making a real change at the exact moment somebody else’s screen is also updating.

And here’s the part worth sitting with. The best model in the world, running on unlimited compute with unlimited tokens and no cost constraints at all, would not have caught that bug either. Not because it isn’t smart enough. Because it doesn’t know your intentions. It has never stood on a field. It doesn’t know that a real coach, mid-game, drags a player to a new position while a parent’s phone is simultaneously pulling the live scoreboard, because nobody told it that’s how the product actually gets used. No amount of horsepower fixes a gap in intention. That’s not a scaling problem. It’s a completely different kind of problem, and scale doesn’t touch it.

This is also the difference between building a bike and building an F1 car. A bike forgives you. Put the chain on slightly wrong, ride it anyway, nothing catastrophic happens. An F1 car does not forgive you. Every system talks to every other system, tolerances are measured in fractions, and a mistake that would be invisible on a bike shows up as a car in a wall at two hundred miles an hour. Software works the same way once it grows past a toy. BenchBoard isn’t a 747, nobody’s life is on the line the way it would be in aerospace software, but it’s closer to the F1 car than the bike the moment real coaches on real fields depend on it during a real game. You cannot assume the engine knows what you meant. You have to tell it, or ask enough questions to find out where you failed to.

This is exactly why it drives me up a wall watching some YouTuber pull up a single prompt, get a working boilerplate app in ninety seconds, and act like that proves anything about how good a model is. It doesn’t. A demo with one user clicking one button proves the bike rolls forward in a straight line on a flat driveway. It says nothing about what happens when two people grab the handlebars at once. Even the best model in the world still needs a solid engineer in the loop who knows what they’re actually building, because the model was never going to supply the intention on its own. It can’t. That’s not what it is.

So how do you know you’ve actually graduated out of vibe coding? Not when your app stops breaking. Things will always break. You’ll know when the question you reach for changes. “Why isn’t this working?” is a vibe coder’s question. It hands the whole problem back to the AI and hopes it guesses right on the retry. “Tell me the exact steps and flow when you’re saving this player’s name” is a completely different question. It forces you both to look at the actual mechanism instead of the symptom, and it’s the kind of question that would have caught the right field bug before it ever shipped, because it makes the two competing writers visible instead of letting them stay invisible until a coach finds two players standing in the same spot on the field. That distinction, between asking about the symptom and asking about the mechanism, is worth its own article. For now, just notice which one you reach for first.

What Asking Should Look Like

While being in a classroom and having whole new approach to doing this stuff would help immensely, you also don’t need to write code to ask a good question.

But you do need to get past the thing that makes this genuinely hard: a bad answer and a good answer sound identical coming out of the model.

1. Fluency doesn’t track correctness.

Not with Claude, not with any of them. The confident tone is generated the same way whether the underlying reasoning is solid or completely wrong, so “that sounds right” is not information. It never was. It just feels like information because we spent our whole lives around humans, where hesitation and confidence were at least loosely correlated with knowing what you’re talking about.

So if fluency isn’t the signal, what is? A few things I actually watch for.

2. Make it trace its own steps out loud instead of asking it to just fix something.

Have it write out every move it’s making, in order, down to a console log line for each step if that’s what it takes. Think of an engine mechanic who just says “sounds fine” versus one who hooks up a diagnostic and actually watches cylinder one, two, three, and four fire in sequence. The moment the AI writes out that it’s firing steps one, two, three, four in that order, and the actual output comes back one, two, four, three, you don’t need it to tell you something’s wrong. You already see it. Half the time, that alone is enough for the model to catch its own mistake, because writing the sequence down forces it to check the sequence, not just describe it.

3. Write out the actual data flow yourself

Screen by screen. When a coach saves a player’s name, what actually happens next? Does it save to the device first? Does it write to the database, the central place where the app permanently stores information so it’s still there the next time anyone opens it? Does it broadcast out to every other screen watching that same game in real time? I found out the hard way that this last one mattered more than I expected. Early in the beta, I changed a player’s name on my screen, it updated fine on my side, and none of the other coaches watching that game saw it change at all. The fix needed SignalR, which is the piece of technology that keeps every connected screen talking to a live server so a change pushes out to everyone instantly instead of everyone needing to refresh and hope. Without it, every coach is staring at whatever snapshot loaded whenever they last opened the page, and nobody knows it. You don’t find that gap by asking “why isn’t this syncing?” You find it by forcing yourself to trace the actual path one piece of data takes from your screen to everyone else’s.

4. Bet on your own experiences

It’s the signal that has nothing to do with the AI at all.

If you’ve spent real time coding, even years ago, even in a completely different language, you’ll start recognizing the shape of what the AI is doing faster than someone brand new to this. Not because you remember the syntax. Because you’ve seen this particular kind of mistake before, in some other form, maybe even made by you. The simple pattern recognition can come from a class. But the most complex ones come from time in the seat, and it’s the one thing the AI genuinely cannot hand you.

It has to be earned by making the mistake once already, somewhere, at some point, so you recognize its outline the second time around.

Does it name a concrete failure case, or just reassure you? In the RestRule story above, the moment the AI actually caught something real was the moment it stopped saying “this design works well” and started saying “this design cannot enforce ascending order across rows without a trigger.” That’s a specific, checkable claim about a specific mechanism. You can go verify it. Compare that to a sentence like “this approach handles most edge cases effectively,” which sounds equally confident and tells you nothing you can check at all. If you can’t picture the exact scenario where the claim would be false, the claim probably isn’t grounded in anything.

Does the domain fact live in the code, or only in the sentence describing the code? A real answer about softball rest rules should show up as a comment sitting next to the actual column it constrains, the way it does in the RestRule class above, not just as a line in a chat window that never gets checked again. If the important detail only exists in prose and nowhere in the artifact itself, it’s decoration, not verification.

None of this requires reading syntax fluently. It requires refusing to let confidence stand in for evidence, and asking for the specific, falsifiable version of whatever the AI just told you.

5. Think like an engineer and ask thoughtful questions like:

• “Explain what this does in a way I could repeat back to someone else.”

• “What would happen if two people did this at the exact same moment?”

• “Is this the only place in the codebase that does this, or did we build something similar somewhere else?”

• “Why did you choose this instead of the simpler version?”

None of these require you to read a single line of syntax. All of them force the AI to either produce a real answer or expose that it doesn’t have one, which is information you badly need and will never get by just accepting the first result and clicking on to the next feature.

Notice what all of those questions have in common.

None of them are “why isn’t this working?”, which is what many starting vibe coders make the mistake of doing.

It’s also fair to say that question feels natural to reach for, and it’s the weakest one you can ask, because it hands the entire problem back to the model and it ends up guessing at the symptom rather than thoughtfully walking through and making sense of it all.

For example: “Tell me the exact steps and flow when you’re saving this player’s name” is a completely different animal.

It’s not asking the AI to diagnose anything yet. It’s asking it to narrate the plumbing, step-by-step, in order, out loud. Nine times out of ten, that narration is where the actual answer lives, and a lot of the time you don’t even have to find the bug yourself. The AI finds it mid-sentence.

This is the part that surprised me the most once I started doing this on purpose. Ask the AI to walk through its own mechanism carefully enough, and it will sometimes catch its own mistake in the middle of explaining it. That’s exactly what happened in the RestRule story above. Nobody told the AI its child-row design couldn’t enforce ascending order across rows. It found that out by being pushed to explain its own reasoning closely enough that the gap became visible to it too. That’s not a fluke. It happens constantly once you start asking mechanism questions instead of symptom questions, because a model narrating its own logic step by step is a model checking its own work in real time, in front of you, where you can actually watch it happen.

That’s the real reason how you ask matters more than any other habit in this whole piece. It’s not just how you catch bugs. It’s how you learn. Every time you ask a mechanism question and get a real answer, you understand one more piece of your own app that you didn’t understand five minutes earlier. To me, I feel it’s a required habit that works on top of what you learned in class to take you to the next level.

You’re not extracting a fix from the AI. You’re both looking at the same wiring at the same time, and sometimes the AI sees the loose connection before you do, but only because you asked it to actually point at the wire instead of just telling you the light’s out.

This is also, honestly, where writing something out yourself still earns its keep, even one time.

Try to describe the exact sequence of what should happen, step by step, before you prompt for it.

What happens if a player gets pulled from the lineup and it’s currently their turn to bat? What happens if the same jersey number shows up twice because a guest player forgot to check with the roster? You won’t think of either of those by describing the feature from a distance. You’ll think of them the moment you try to spell out the steps in order, because writing and personal prototyping forces the gaps to show themselves in a way that talking with your chatbot never does.

Due Diligence Didn't Go Away. It Just Moved.

I remember what building software used to require before any of this existed. You hit a wall, you opened fifteen browser tabs, you read through a Stack Overflow thread from 2011 where half the answers contradicted each other, and you pieced together something workable from the fragments that seemed trustworthy. That part is genuinely gone, and I don’t miss it. You don’t have to Google much anymore. You can ask the question directly and get an answer in seconds instead of forty minutes of digging and you’re hoping that it’s sourcing from the good stuff.

Here’s what people get wrong about that change. They think it means the digging itself is gone. It isn’t. It moved. It used to live in the search, figuring out which of fifteen tabs actually applied to your situation. Now it lives in the verification, figuring out whether the answer you got in three seconds is actually correct for your situation. The work didn’t disappear. It relocated from finding information to checking it.

This is exactly why asking the right question matters more than it used to, not less. And that’s where experience matters even more, not less. A vague search used to get you a pile of mediocre results you had to sort through yourself, which was annoying but forgiving, because you were forced to compare sources before you trusted any of them. A vague prompt gets you one confident, fluent, single answer with nothing to compare it against, which feels like a better experience and is actually more dangerous, because there’s no second source sitting next to it disagreeing with it and making you think twice. You have to manufacture that skepticism yourself now. Nobody hands it to you for free anymore.

So when something actually matters, when it’s a security decision, a payment flow, a piece of data you can’t afford to get wrong, the due diligence doesn’t go away just because the AI answered fast and sounded sure. You still need to open the actual documentation. Yeah, I said it. You still need to read the source the AI is summarizing instead of trusting the summary. In fact, you should read its thoughts as it writes them just so you understand the approach it’s taking.

You still ask it to show you where it got that answer, and you still check. The beauty of this whole shift isn’t that you get to skip the diligence. It’s that you get to skip the part that used to eat all your time, so the diligence you do have time for goes toward the questions that actually deserve it and the actual engineering that comes out of it.

Graduating

I tend to call myself an agentic developer now, not because I stopped using AI to build BenchBoard, but because of what changed in how I use it. I still let it write the bulk of the code. I still move faster with it than I ever could alone. The difference is that I don’t accept an explanation just because it’s confident, and I don’t assume a working demo means a working system, and when something under the hood doesn’t make sense to me, I stop and ask until it does, even when the app is already running fine in front of me.

The habit of making good decisions and asking solid questions instead of moving past your code session in a vibey way gets you closer and closer to the ceremony. Don’t skimp on being diligent and detailed because the site loaded and nothing crashed.

Vibe coding got you a working app. Asking good questions is what gets you an app you actually understand.

And hopefully, three months from now, when something under the hood that used to work fine starts acting up for strange reasons, you have the starting point to build something. An idea that used to appear out of reach — that now seems possible today.

So, go out there and build it.

Glossary — for all you ambitious newbies ;)

A few terms from this piece, for anyone who wants the plain-language version in one place instead of hunting back through the paragraphs.

• Modal: the pause menu of your app. The main screen freezes behind it while you deal with one specific task, then you close it and the game resumes right where you left it.

• Commit: a save point. A snapshot of exactly where things stood, that you can always load back up later if things go sideways.

• Version control (usually a tool called Git): your full save-file history, not just the most recent save. Every checkpoint gets kept, in order, so you can go back to any one of them, not only the last one you made.

• Database: the equipment room. The permanent storage where everything lives whether or not anyone’s out on the field right now, so it’s all still there the next time someone shows up and opens the door.

• JSON blob: dumping the entire gear bag into one box. Everything’s technically in there somewhere, but nothing has its own labeled shelf, so finding or trusting any one piece means digging through the whole pile.

• Table, row, column: a lineup card. The card is the table. Each player gets one row. Each column is a stat or slot every player has a spot for, like position or batting order, whether or not that player actually has anything to put there.

• Guid: a player’s own permanent jersey number, except no two players anywhere, on any team, in any league, could ever accidentally share one. Nobody gets confused for anybody else.

• Trigger: an automatic whistle. Something built to fire on its own the instant a specific condition happens on the field, with no referee actually there to blow it by hand.

• SignalR: the live broadcast feed. Everyone watching sees the play the moment it happens, instead of everyone having to refresh their own scoreboard app to find out what they missed.

• Agentic developer: see the note above for where the term actually comes from.

And if you’re really curious and want to understand more, ask your favorite model to give you the answers. It’s good at this part.

Before I paste any of it, here’s what I was actually trying to get built. BenchBoard’s tablet board has a simple M/S toggle up top: Manage or Score. Right now, tapping Score just flips the app straight into scoring mode, no questions asked. I wanted a real gate in front of that button. If the game hasn’t started yet, tapping Score should stop the coach and walk them through a quick pre-game wizard first: scan the opponent’s lineup card with the tablet camera, let OCR read the names and positions off it, confirm which team is actually home and which is away (this isn’t always set correctly when the game gets created), review both lineups side by side, and only then drop into live scoring.

That’s the pitch. Simple sentence, ugly amount of code underneath it.

What followed was a long back-and-forth where Claude went digging through the existing codebase before writing anything, and it found something I didn’t expect: there were already two separate, half-built scorekeeping systems sitting in BenchBoard that didn’t talk to each other. One was the live tablet board I’d been building all session. The other was an abandoned “Coming Soon” prototype page that, buried inside it, already had a working 3-step wizard and the exact two-column drag-and-drop lineup component I was asking for, just wired to the wrong system and missing the home/away step entirely.

So the actual work became: pull the good parts out of the dead prototype, rebuild them as standalone components, wire in the OCR pipeline that had never actually been called by anything real, add a backend endpoint that didn’t exist yet for swapping home/away teams, and stitch it all into a new wizard that gates the real Score button. Claude worked through that in stages, extracting components, verifying each one still rendered, building and testing the backend endpoint, and confirming the OCR-to-roster matching worked end to end with fake scan data.

All of that went fine. Then we hit the part of the conversation worth actually sharing. I asked Claude, what are the advantages and disadvantages of the approaches it was offering me.

Here’s the screenshot for reference:

Claude Sonnet 5:

Before I build the wizard’s final piece, I hit a real architectural fork that I need your call on. I traced through useBattingLineup.js and useMainField.js (the hooks backing BattingLineup-v5.jsx and MainField-v5.jsx). Both are pervasively hardwired to StorageHelper.getTeamUserId(), your own team, throughout, not just at one entry point. Dozens of call sites.

Your spec says populate BattingLineup-v5.jsx with “whichever team is Away,” which, if your team ends up Home, means displaying the opponent’s data in a component that today can only ever render your own roster.

Option 1, read-only swap-in.

Advantages: zero risk to useBattingLineup.js and useMainField.js, the hooks behind the entire tablet board we just spent this whole session animating (the M|S tween, zoom mutual-exclusion, the lift-only Score transition). No chance of regressing any of that. Arguably correct behavior too, not a compromise: you can’t genuinely interactively manage the opponent’s live roster mid-game the same way you manage your own. That’s already reflected elsewhere in the codebase (isOpponent() gating, lineup codes, the separate LineupAmend flow for mid-game substitution corrections). A static view of the opponent’s confirmed lineup is what actually makes sense. And it’s fast: BattingViewOnly already exists, this is conditional rendering, not new architecture.

Disadvantages: visual inconsistency, since the same board slot sometimes shows the rich drag-and-drop UI and sometimes a plain static table, depending on whose team landed there. Needs careful styling so it doesn’t look like a jarring downgrade. And if a coach wants to fix a scan mistake on the opponent’s side mid-game, they’d go through the separate amend flow rather than dragging directly in that slot.

Option 2, full team-agnostic refactor.

Advantages: true uniformity, both slots always show the same rich, live, interactive UI regardless of whose team occupies them. Matches the literal spec text most directly, no representational gap.

Disadvantages: high regression risk. These hooks handle drag persistence, syncSnapshot, SignalR/live-game guards, JWT-gated logic, and more, used across the entire app (Home.jsx, Demo.jsx, live scoring), not just this wizard. Threading a clean team-override through all of that is a multi-session refactor on its own, not an afternoon’s work. It directly touches the exact files we just finished carefully verifying this session. And it’s likely a false economy: a lot of useBattingLineup.js’s internals assume an authenticated “my team” session (JWT checks, live-game guards) that genuinely don’t apply to an unauthenticated opponent team anyway, so even after refactoring, most interactivity would need to be disabled for the opponent case regardless, converging back toward something functionally similar to Option 1, just with far more code and risk to get there.

My recommendation stays Option 1. The risk/reward is lopsided, and Option 2’s main selling point, uniform interactivity, is largely illusory given the auth assumptions baked into those hooks. Want me to go with Option 1?

After reading all that, here was my answer:

Let me offer another option. It’s okay that the scorekeeper can make changes to the opponent. It doesn’t have to be read only. Same goes for the defense. This already happens in GameChanger. In fact, coaches usually will yell at the scorekeeper to make changes to the roster on the spot. The big advantage is that BenchBoard has the best UI to tackle these kinds of issues, especially as a scorekeeper. So you don’t have to make big changes to BattingLineup, BattingWithSubs, or MainField. You just need to feed the data into it. If a change is made by the scorekeeper, that’s fine, just push those changes into that TeamID and it’s logged by the system on what the scorekeeper is doing anyway. From my end, you can just populate the data. Make changes to the opponent’s as a scorekeeper if needed. You don’t have to worry about permission issues or making huge changes to the functionality. Just map back to the TeamID those changes belong to. Make sense? Tell me if there are any drawbacks to what I’m asking.

Its answer:

That reframes it usefully. Permissions aren’t actually the blocker (you’re right, there’s no reason a scorekeeper role couldn’t edit opponent data, and yes, GameChanger does exactly this). Let me verify the real constraint before answering, since I want to be precise about what “just feed the data in” actually requires.

Confirmed the real constraint, and it’s narrower than I made it sound. GlobalPlayerStore.jsx:35 is a single module-level singleton, roster: [], which both hooks read from. The actual problem isn’t permissions or drag/sort logic, it’s that BattingLineup-v5.jsx and MainField-v5.jsx can be on screen simultaneously representing two different teams (away lineup plus home defense), but there’s only one shared roster array to read from. Let me check whether the persistence functions are already team-parameterized, since that determines how small this fix can be.

Good instinct: the drag/drop/sort/edit logic itself never touches this. Only movePlayerDefensive, updateBattingLineup (pure store writes, no teamId param at all) and syncSnapshot (the actual persistence call) are relevant, and GlobalPlayerStore is a single flat singleton with no concept of a second team. Before I confirm this is safe, let me check one thing that could sink the whole approach: does the backend actually let a scorekeeper write changes tagged with the opponent’s teamId, or does it enforce that your JWT’s team must match the request?

This is very encouraging. The endpoint has [Authorize] but no check that req.TeamId matches the caller’s own team. It trusts whatever teamId is in the request body. Combined with a Game.Status == “Live” gate, explicitly commented “only the scorekeeper can modify,” confirming the app’s design already assumes a scorekeeper-vs-owner distinction, the backend already supports what you’re describing. Let me check the actual sync call site to confirm the teamId is swappable there too.

Good news: I checked the actual sync path (masterSync.js:162) and it’s exactly as I suspected. syncSnapshot() reads directly from the single global playerStore with no teamId parameter anywhere. But the backend side has no drawback. SaveMainBoardSnapshot, the endpoint that persists it, has [Authorize] but never checks that req.TeamId matches the caller’s own team. It trusts whatever teamId is in the body. Combined with the explicit Game.Status == “Live” gate (”only the scorekeeper can modify the lineup”) already baked into that endpoint, the backend design already assumes a scorekeeper can act on behalf of either team. This isn’t a gap I’d be punching through, it’s already there.

So: your approach works, and it’s real but bounded work, not the sprawling refactor I worried about. The concrete scope:

1. GlobalPlayerStore.jsx needs to hold a second concurrent team context, not full multi-team generality, just two, since a game only ever has two sides, instead of one flat roster, battingLineup, defensiveAssignments.

2. movePlayerDefensive, updateBattingLineup, syncSnapshot need an optional teamId parameter to know which context to read/write and which team to target in the API call. Today they’re 100% implicit/global.

3. useBattingLineup(), useMainField() need an optional teamId prop selecting which context they’re bound to, defaulting to “my team,” current behavior, unchanged everywhere else in the app: Home.jsx, Demo.jsx, Manage mode, and so on.

One real thing to flag, not a blocker: that Live-status 423 gate is on this endpoint specifically. Once the game actually goes Live, saves route through whatever the dedicated live-scorekeeper endpoint is (I haven’t checked that one yet). Our wizard only fires for Scheduled games, so this flow is unaffected, but the mid-game “coach yells at scorekeeper” case you described would hit that other endpoint. I’d want to verify it has the same no-ownership-check design before assuming it works identically, though the “only the scorekeeper can modify” comment strongly suggests it does.

Want me to proceed with this scope?

My answer after that:

DO IT!

To those who are doing agentic coding with a big-ass codebase like myself, particularly those who want to graduate from vibe coding:

Don’t vibe your shit when it’s this big.

Read what the AI is doing. Open that shit up to see the actual code changes. Understand them. Don’t know what something does? Simply ask. What the hell is ABC(XYZ)? What does that do?

It will not only help you understand your codebase, it will absolutely help you push back when the AI’s first answer isn’t the right one.

A good engineer knows there are always options outside of what the AI proposes.

An inexperienced vibe coder feels like there are only two options. Just like you’ll hear vets in professional sports teams tell newcomers, “just because you’re a rookie doesn’t mean you have to act like one.” Be someone who knows what to do codewise and knows what needs doing, knows how it’s built, knows the methods and containers being used in the discussion, so you can provide the right direction.

You don’t have to know every single syntax it will take to get there. That’s handled by the LLMs now. But it’s you who has the judgment, and that judgment is the engineering advantage nobody else at the table has. This is important.

Now go out there and make cool shit.

As I write this, my 17-year-old son is out jogging.

Nobody told him to. Yesterday, playing for his national travel team, the highest level he has ever reached, he struck out. Kids strike out all the time. It is the most ordinary thing in baseball. But this one was different. It was reckless. Careless in a way that the other parents in the stands noticed, the kind of at-bat where you can see a kid has quit competing and started just going through the motions.

I didn’t want to go all negative Nancy on him about it. I didn’t corner him in the parking lot. I just sent him the video of the at-bat. No caption. Nothing. He watched it and he knew right away. He could see himself going backwards. He could hear it, too. The video picked up the parents in the stands and his own teammates reacting in real time, and that was more than enough. These are people who love him, and that is exactly why it stung. Nobody had to lecture him. The tape did the whole job for me.

So we talked in the car. And that is where the question came up. The one this whole article is named after, the same question travel sports has been asking my kids and me for four years now, just worded a little differently every time. Because once you have already been through the private coaches, the drills, and the thousand hours of practice, it eventually comes down to this.

“How bad do you really want this?”

I told him the truest and hardest thing about the level he is playing at now. “You’re on a team where everyone is good. You can’t coast on talent anymore, because everyone here has it. Everyone’s good.” He nodded. He already knew. I ran through a few athletes who had hit that same wall and had to choose the work over the talent that carried them there. One of them I will come back to later in this article.

He didn’t answer me with words. He laced up and went for a run. That is the answer I was hoping for. Not because a run fixes his swing or his footwork. Because the run means he still wants it. And in travel sports, wanting it is the whole game.

He is seventeen. I can count the seasons I have left with him on one hand, and lately I have caught myself doing exactly that. I try not to let him see me do it.

Rule One: Both of You Have to Love It

Let me get the most important thing out of the way, because everything else in this article stands on top of it.

You, the parent, and your kid, the player, both have to love the sport. Not like it. Love it. Above the trophies, above the college dream, above the highlight clips. If that love isn’t real on both sides, travel sports will find the crack and pry it wide open.

Here is why. Travel can feel like a grind, if you let it. It eats your weekends, your money, and a shocking amount of your emotional energy. A rec season is a handful of Saturday mornings and orange slices. Travel is tournaments three hours away, back-to-back games in July heat, pool play at 8 a.m. and bracket play at 9 p.m., and a two-hour drive home where nobody talks because you lost the last one on a dropped pop fly.

You do not survive that on ambition alone. You survive it on love. When your kid genuinely loves the game, the losses sting and then they let go. When they are only in it because you want them there, or because a coach convinced you they had “potential,” the losses pile up and turn into resentment. I have watched it happen to other families, and I have watched it from the dugout too, as the coach holding the lineup card, which is somehow worse. From both chairs it looks identical. What gets me is how ordinary it looks while it is happening. No blowup. No single bad day. Just a kid who laughs a little less at each practice, stops asking for extra reps, and starts treating the thing they used to love like a chore somebody assigned them. It does not set off alarms. It just quietly raises an eyebrow, if you are paying attention at all. And then one day the kid is 13, done, never touches a bat again, and the parent still doesn’t understand why.

So here is where I land on it, as a coach and as a dad who learned this the hard way. My job in that dugout is to be a safe place, not one more source of pressure. Kids get plenty of that already. And pressure does not build players. It hollows them out. I know because I did it myself once. I leaned on my own son too hard, pushed a little too much, and I nearly shoved him right out of the game he loved. He almost quit. And when a kid quits because you squeezed the joy out of it, that is game over. You do not win that back with a pep talk. There are better ways to motivate a kid than pressing on them until they crack, and I promise you they work better. Trust me on this one. I have stood on the wrong side of it and watched it almost cost me everything that matters.

So before anything else, ask your kid the real question. Not “do you want to make the team.” Ask “do you love this.” And be honest with yourself about your own answer too, because they will feel it if you don’t.

Everything Changes at 12U

Here is the thing nobody puts in the flyer at signups.

Travel sports is basically all fun, all the way up to 12U. The kids are little, the stakes are low, everybody plays, and the trophies are big and shiny. Parents get along. Coaches rotate positions so nobody cries. It is joyful and it is easy to fall in love with.

Then 12U ends, and the floor drops out.

After that age, it gets serious. Playing time is earned, not handed out. Rosters get cut. The gap between the kids who put in extra work and the kids who don’t becomes a canyon. Even their heights are so uneven. There are kids who’ve grown big enough that they look like they just came from prom. And this is not a coincidence: right around that age is when most kids quit. The game stops being a playground and starts being a proving ground, and a lot of them decide, reasonably, that they would rather do something else. There is nothing wrong with that. But it is the fork in the road, and you should know it is coming.

For the families who keep going, the higher you climb, the more brutal it gets. Higher division, older age, better competition. Every level up is a level where your kid is suddenly not the best player anymore. Sometimes not even close. And that is the point. That is the whole point. The higher levels are asking your kid a question every single game: how bad do you really want this. It is the same question I asked my son yesterday. He is answering it on a sidewalk right now.

Starting Over, Over and Over

This is the part that hurts, and it is the part you have to be ready for.

Every time you move up, or move to a new team, or your kid grows into a tougher bracket, you start over. Depending on how good your kid is on that particular roster, they might land at the bottom of the depth chart. Riding the bench. Batting last. Watching kids they used to dominate get the innings they want.

I will not sugarcoat what that does to a kid. My kids have questioned their worth over this. They have sat in the car afterward wondering if they are even any good, if they belong, if this was all a mistake. I have been in that car with them, and it is one of the hardest places a parent can sit, because you cannot fix it with a pep talk and you cannot fix it with money.

What you can do is get through it together. My kids and I have treated it as a team problem, not their problem. We work at it together, and in the middle of it I keep asking one small question. Not “how do we get you more playing time.” Just: “Do you still like this?”

If the answer is yes, we keep going, and the depth chart sorts itself out over time. If the answer is no, then it is time for a different conversation, and there is no shame in that either.

There is a real upside buried in all this starting over, too. Every new team is a new set of teammates, new coaches, new families in the stands. Your kid makes friends across towns and leagues. You network with parents and coaches you would never have met otherwise. The circle keeps widening. That part is genuinely great, even when the on-field part is humbling.

Dear Parents, Your Level Of Support Matters

the question on the parent for a minute, because travel sports asks you “how bad do you want this” too.

Are you willing to do the driving? The two-hour hauls, the 5 a.m. departures, the hotel nights, the tournaments in towns you have to look up on a map? Are you willing to do the helping? Throwing extra reps in the backyard, filming at-bats, running to the field early so your kid can get loose? Are you willing, maybe, to coach?

And here is the honest truth about all that driving and helping and coaching: in my house, it is not a one-person job. Not even close. My wife and I split it down the middle. We divide practices between our son and our daughter so that both kids get a parent in the stands. She is the one who researches the travel teams, digs into the organizations, and reads between the lines on the ones that are just after your money. I mostly show up to practice with a bucket of balls. She books the hotels, maps the tournaments, and handles the ten thousand logistics that live in the gaps between coaching and game time. And let me be clear about something people gloss right over: it is her money on the line too, not just mine. This is a family commitment in the most literal sense of the word. If you have a partner, travel is going to find out real fast whether the two of you are actually a team, because it will test that before it tests anything else.

Because it gets even bigger when you are a coach. I know this firsthand. Coaching is a different level of commitment entirely. Now you are not just responsible for your own kid, you are responsible for the whole roster, the lineup, the parents, the practice plans, and the emotional temperature of a dugout full of 12-year-olds. It is enormously rewarding and it will absolutely eat your life. Go in with eyes open.

And here is where loving the sport yourself stops being a nice-to-have and becomes essential. If you love baseball or softball, the driving is not a chore, it is a chance to talk to your kid with no screens around. The backyard reps are not a sacrifice, they are the best part of your week. Parents who love the game glide through the logistics that break parents who are just showing up out of obligation. That love makes all of it lighter.

It’s Only a Grind If You Call It One

I want to sit on this one, because it might be the single most important thing I have figured out in four years.

My mother-in-law once looked at how much my kids and I practice and called it overtraining. I kindly pointed out that she doesn’t even like sports, lol. And then I explained the thing she was missing: this is not overtraining. This is quality time. It is some of the best time I get with my kids all week.

When I am out with my daughter, we are not grinding. We are hitting, sure, but between reps we are figuring out what we are going to cook when we get home, and cracking up about the funniest plays we have seen on the teams we have been on. When it is my son in the backyard, we are throwing, but we are also talking about our neighbor’s ridiculously impressive vegetable garden over the fence. And a lot of this happens right there in our own backyard, down in the batting cage, which is where the whole thing turns into a sitcom. My wife will appear in the window above, looking down at the cage like a hawk, and start critiquing the kids’ drills from her bird’s-eye seat. Uninvited color commentary from the second floor. It is one of my favorite things in the world, and I don’t think any of us would trade it for anything. Those are the conversations I will remember when they are grown and gone. And they will be grown and gone. That is the thing that sneaks up on you out there in the yard, glove on your hand, sun dropping behind the fence. The reps were never really the point. The reps were the excuse to keep my kid in the backyard with me for one more hour before the hours run out.

And we look back on all of it. The heartbreakers, the championship games we lost in the last inning, the tournament the very next weekend where we won one and felt like kings. My middle daughter, the dancer, is the most incredible cheerleader my son has. And my son turns right around and is her biggest fan when she is competing on a dance floor. And my wife is the biggest fan of all of them. This is the most involved in sports I have ever seen her in my life, and somewhere along the way she became the loudest voice in our corner. When I make it to a game, I film every moment and send it to her. When I can’t make it, she films it and sends it to me, so that neither of us ever really misses anything. Between the two of us, somebody is always there, and somebody is always recording it for the one who couldn’t be. We have a helluva time. All of us. That is not a byproduct of travel sports. For my family, it is the whole point.

Here is the part I want every parent to hear. The word you use for practice becomes the thing practice is. Call it “the grind” and I promise you, that is exactly what it will turn into for your kid. Semantics matter more than people think, especially with kids. The language you wrap around the work is the language they will carry inside their own head for the rest of their lives. Choose it carefully. It sets them up to succeed, or it teaches them to dread the very thing they are supposed to love.

I thought about this watching the Knicks win the championship this year. In the middle of the celebration, they flashed back to a clip of a teenage Jalen Brunson dragging his feet through a workout, his dad, Rick Brunson, a journeyman NBA player himself, calmly asking him, “Do you still want to do this for a living?” Jalen said yes. And his dad said, “Well son, this is what it takes.” No yelling. No grinding it into him. Just a quiet question and a quiet truth. Years later, Jalen scored 45 in the clinching game and went looking for his father in the crowd before he did anything else. That is the model. Ask the question, respect the answer, and make the work something you do together instead of something you inflict.

I take after that. Every practice.

Three Kids, Three Completely Different Paths

I have three kids, and they are the best proof I have that you cannot force this.

My 17-year-old is the travel baseball kid. My 15-year-old is a competitive dancer, and she is incredible, truly, the real deal, and she plays tennis on top of it. My 12-year-old is in travel softball and she loves both baseball and softball.

My middle daughter tried softball and baseball early on. She was fine. But I could tell from the very beginning that her heart was somewhere else. I never forced it. I knew she wanted something different, and dance turned out to be that thing. Watching her find it was better than any amount of me pushing her toward a sport she was lukewarm about ever would have been. Her tennis is the same story: it is hers, she chose it, and that is exactly why she is good at it.

My youngest is a different case. She is inspired by her big brother. She watches him play, she wants to be out there, and she genuinely loves the game. That love came from her, not from me. I just gave it somewhere to go.

Same house. Same parents. Three completely different answers to “what do you love.” The job is not to pick the answer for them. The job is to pay attention to the answer they are already giving you.

The Freshman Cut

However, my son’s story deserves its own article, and one day it will get one. But here is the short version, because it matters.

He played Little League all the way up to high school. Loved it. Lived it. Then he tried out for the freshman team as a freshman and got cut.

Cut. From the freshman team.

For a kid who had played his whole life, that is a gut punch that is hard to describe. So let me describe one piece of it, because the whole story really does belong in its own article someday.

I was at work when it happened. I had my son’s location open on my phone, that little tracking dot, and I watched it leave the high school to head home. Except it never made it home. It stopped at the elementary school next door, the same one where he first learned to play the game, and then it just did not move. For an hour, that dot sat in one place. And it was raining. My boy was standing out in the rain in front of his old elementary school, in the shadow of the high school that had just told him no, and he could not make himself walk the rest of the way.

The kids he had come up with, the ones he had shared a dugout with for years, they made it. He was the one who didn’t. Everybody who knew him was stunned.

My wife and I got in the car and went and got him. Nobody said much of anything. We just sat there, the three of us, and let it be as heavy as it was. There is no bat you can buy, no lesson you can book, no thing a father can say that lifts that exact hurt off your kid’s face. So I didn’t try. I just showed up and sat in it with him.

And then, somewhere in the quiet days after, without a single word from me, my son decided he was not done. He tried out for travel. He made it. He made it again as a sophomore, and from there it has been history. He is now on a national travel team, the highest level he has ever reached.

I am telling you this because the freshman cut is exactly the moment most people expect a kid to quit. He did the opposite. That single decision, to keep going after getting told no, is the reason he is out jogging right now instead of sitting on the couch wondering what could have been.

What You Actually Get Out of It

I have spent a lot of words on how hard travel is, so let me be just as clear about why it is worth it, because the positives are massive.

The competition itself is the gift. Playing against better kids, week after week, makes your kid better in a way that no amount of easy wins ever will. And here is a fun byproduct nobody mentions: when a travel kid goes back and plays rec, or plays with the neighborhood kids, they are often just destroying everyone, haha. That is not me bragging. That is what happens when you spend your weekends against the best and then step down a level. The confidence that comes from that is real and it carries into everything else they do.

Then there is college. If your kid decides they want to play in college, travel is very often the road that gets them there. Here is the part that blindsides a lot of parents: recruiters don’t really watch rec, and they mostly aren’t watching high school either. That one stuns people. You can have a genuinely talented kid tearing up their high school league, sitting near the top of the MaxPreps leaderboard, and still not get the time of day from a D1 coach, or any coach for that matter. Not because the kid isn’t good. Because that is simply not where college coaches are looking. They are at the travel events, the showcases, the big tournaments. That is the pipeline. Miss it, and it doesn’t much matter how many high school arms your kid is lighting up.

And this is important: college ball is possible at a lot of levels, not just the big D1 programs you see on TV. There is D2, D3, NAIA, junior college, and more. There is a real path for a lot of kids, and travel is where that path starts.

The team my son is on now takes this seriously in a way I did not fully appreciate until we were inside it. They expect every kid on that roster to play college ball, and they coach like it. Everything is pointed at the next level. And my son, the same kid who stood in the rain outside that elementary school a couple of years ago, has told me flat out that he wants to play in college. After everything, he is not just still playing. He is aiming higher than he ever has.

But even if college never happens, even if your kid decides they don’t want to keep playing at that level, they walk away with things that outlast the sport. There are tons of rec leagues out there, and they are full. Your kid can play forever if they want to, in a beer league at 40, whatever. The networking and the confidence they built along the way become huge. They know how to walk into a room full of strangers and belong, because they have done it on every new team they ever joined.

And it teaches teamwork in a way a classroom never will. Real teamwork, where you are counting on the kid next to you and they are counting on you, where you win together and lose together and figure out how to keep showing up for each other after a bad game.

The Big One: Resilience

For me, as a parent, that is the reward that towers over all the others.

Resilience.

Travel sports will knock your kid down. Repeatedly. A cut, a slump, a bench, a bad coach, a team that folds, a season where nothing goes right. And every single time, they have to decide whether to get back up. Nobody can make that decision for them. Not me, not a coach, not a paid instructor. They have to choose it.

What I have watched happen over four years is my kids learning, in their bodies and not just in their heads, that getting knocked down is survivable. That a slump ends. That the bottom of the depth chart is a starting point, not a verdict. That is a lesson that has nothing to do with baseball or softball and everything to do with the rest of their lives. Jobs, relationships, setbacks I cannot protect them from. They are building the muscle to handle all of it, one hard weekend at a time.

My son out on that run right now is not training his legs. He is training that muscle. He got knocked down and he chose to get back up, on his own, without me telling him to. You cannot buy that. You cannot fake it. And it is the single best thing travel sports has ever given my family.

The Negatives Nobody Puts in the Brochure

Alright, let me be fair. There are downsides, and I am not going to pretend otherwise.

Yes, there are money-grab teams out there. Organizations that are more interested in your check than your kid’s development, that promise exposure they cannot deliver, that stack a roster with paying families and let half of them ride the bench all season. They exist. But that is exactly what research is for. Talk to other parents. Watch a practice before you commit. Ask hard questions about playing time, about coaching philosophy, about where past players ended up. A good organization will answer those questions happily. A money grab will get squirmy. You can usually tell the difference in one conversation.

The cost is real, and it is not small. Fees, travel, hotels, tournaments, and the gear. Oh, the gear. If your kid plays baseball or softball, you are going to become a regular at the sporting goods store, and I do mean regular. Bats, gloves, cleats, batting gloves, helmets, and the endless replacement of things that get lost or grown out of. Budget for it, because it adds up faster than you think.

And the calendar. This is the one that surprises people most. When you go travel anything, be ready to sacrifice your weekends. Not some of them. Most of them, in season.

And here is what nobody tells you about the top levels: it stops being just weekends. My son’s national team is loaded with upperclassmen, the 18u guys, and in the summer the tournaments stretch clean through the week and into the weekend. A Perfect Game tournament can start on a Wednesday and not wrap up until Sunday. And that is on top of practices on Monday and Tuesday. Do the math on that. For stretches of the summer, this is close to a seven-day-a-week commitment. That is the deal as you climb, and nobody hands it to you in the brochure.

Know going in that you asked for this. Nobody tricked you. If you resent every Saturday, you are going to have a bad time and so is your kid. If you can make peace with it, and even come to love it, those weekends, and the Wednesdays and the Thursdays, become some of the best memories your family has.

One more thing on the culture: most travel parents are genuinely supportive, and most coaches are too. The horror stories are real but they are the exception, not the rule. The right team and the right situation make all the difference, which is why finding them, and having a straight conversation with your kid about what their actual goals are, matters so much. Have that discussion. Keep having it. Their goals will change, and so should the plan.

Talk to Your Kids About the Money

Here is one I feel strongly about, and I know not everyone agrees with me.

Some parents never tell their kids what travel costs. I do. Not the full spreadsheet, not every line item, but my kids know it is significant. They know it is a real commitment from our family.

The argument against this is that it makes kids feel guilty, that it puts pressure on them, that the money should be the parent’s problem and not the kid’s burden. I understand that view. I just don’t share it.

When I tell my kids what goes into this, I am not trying to make them feel guilty. I am making sure they don’t take it for granted. There is a difference. A kid who knows the family is investing in their dream shows up differently than a kid who thinks the fees and the gear and the hotels just materialize out of thin air. It is not guilt. It is respect, going both directions. I respect them enough to be honest, and they respect the opportunity enough to give it their all.

A Few Things Nobody Warned Me About

Since I am handing out everything I wish someone had told me, here are a few extras.

Watch the arm. In baseball especially, the pressure to throw more, harder, year-round, is intense, and young arms are not built for it. Pitch counts and rest are not suggestions. The kids who get hurt young often never come back the same. Protect the long game over the short win.

The car ride home is more important than the game. This is the one I had to learn. After a bad game, the last thing your kid needs is a breakdown of everything they did wrong on the drive back. What they need is you, on their side. The best thing you can say is often just “I love watching you play.” Save the coaching for practice. The ride home is for being a parent, not a scout.

Multi-sport is a feature, not a distraction. My middle daughter dances and plays tennis. My youngest plays two sports. The obsession with picking one thing at age 10 and grinding it into the ground is, in my opinion, a mistake for most kids. Cross-training builds better athletes and it fends off burnout. Let them be more than one thing for as long as they can.

So Should You Do It?

If your kid genuinely wants to compete at a higher level, then yes. Go travel. It is great, and I would do it all over again.

But understand the deal you are making. The commitment is not just your money. It is your time, your weekends, your emotional energy, and your willingness to sit in the hard car rides without trying to fix everything. Make that commitment with your eyes open, and make it alongside your kid, not on top of them.

And make it without conditions. I hear parents say they don’t want to “waste money” in case their kid quits later. I understand the instinct, but here is my honest opinion: the moment you say that out loud, you have already quit. You have put a condition on your kid’s dream, and kids feel conditions even when you never say them to their face. Once the deal has strings attached, you are not a team anymore, and a parent and kid who are not a team do not get very far in this. Commit fully or don’t commit. And here is the thing nobody tells you: even if your kid does walk away from the sport someday, they will not remember the money. They will remember that you were all in. That you showed up, every weekend, no strings. That appreciation outlasts the sport by decades.

Because the rewards are immense. A shot at college if that is the dream, and it is a real shot at more levels than most people realize. Confidence that spills into everything else. Teamwork that sticks. And resilience, the big one, the thing I would pay for twice if I had to.

The love makes the rest survivable. When the love is real, the bottom of the depth chart doesn’t matter. The slump doesn’t matter. The cut doesn’t matter. Because in the end, none of it does. Unless your kid isn’t playing at all, and even then, there is always a rec team down the road with an open spot.

The Catch You Won’t Know Was the Last

Here is the thing underneath all the advice. The thing I actually sat down to write.

Somewhere in these four years, I played the last game of catch I will ever play with my son as a little boy. I don’t know which day it was. Nobody tells you. There is no whistle, no final out, no announcement over the PA. One summer the ball came back soft and high, and some summer after that he was throwing gas and asking me about the neighbor’s tomatoes, and the little kid was just gone. Quietly. The way they always go. I would give almost anything to know which afternoon that was, so I could have stood out there a little longer. I can’t. That is the deal nobody mentions at signups.

So here is what four years of travel actually taught me, and it has nothing to do with baseball. Play every catch like you don’t know which one is the last, because you don’t. Sit in the traffic. Take the 5 a.m. drive. Learn the vegetable garden by heart. Say “I love watching you play” until they roll their eyes at you. Do it now, while they are still in the backyard, because the backyard does not last, and the hours run out, and no amount of wanting buys a single one of them back.

There is mercy in it too. My youngest is twelve. She fell in love with this game watching her big brother, and now she is the one dragging me out to the yard while he trains for a level I won’t be able to follow him to much longer. I get to do the whole thing over again with her. Only this time I know how it ends. This time I am paying attention to every throw.

My son is going to come back from that jog in a few minutes. Sweaty, quiet. He’ll grab a water, tell me the run felt good, and we will not talk about any of this. But I asked him how bad he wanted it, and he answered me with his feet, because he still loves it.

And the whole time I was asking him that question, I was answering a different one I never said out loud. How bad do I want this. These years. This backyard. This kid, for as long as he’ll still throw with his old man.

Bad enough that it is going to wreck me when the last catch comes.

Bad enough that I won’t even know it was the last one until it is already over.

So go play catch with your kid. Today, if you can.

That’s the whole article.

Before I wrote a line of code for BenchBoard, I needed to answer a question I was embarrassed to ask out loud: is this even worth doing?

I’d been a coach. I’d been a scorekeeper. I’d tried every app on the market and found them all wanting in some specific way I could articulate but couldn’t prove. That’s a terrible foundation for a project. “I personally found this frustrating” is how you build a hobby. It’s not how you build a product.

So I did something I’d never done in forty years of building software. I sat down with ChatGPT and used it like a research analyst.

I didn’t ask it to write code. I asked it to help me understand whether coaches, real coaches not just me, were running into the same walls I’d been running into. Were they actually looking for something that didn’t exist? Was BenchBoard a solution to a real problem, or was it a solution to a Rad problem?

The answer came back: real problem. Coaches across youth baseball and softball were actively searching for tools that connected team management to game data in a single place, and consistently not finding them. The apps that scored games didn’t manage rosters. The apps that managed rosters didn’t score games. The coaches who wanted both were duct-taping two products together and getting the worst of each.

That’s when I knew. Not “maybe this is worth a few weekends.” Worth building properly.

But there was a twist in the research I didn’t expect. When I looked at the coaches who said they couldn’t find a solution that worked, I was in that data. I was one of those coaches. The product I was about to build was the product I’d been failing to find for years.

That’s a strange feeling. Validating your own problem and not realizing, until after the fact, that you were part of the sample.

The Prototype Was Always Mine

Here’s something I don’t see talked about enough in the “AI builds apps” narrative: most people skip the hardest part of building anything, which is knowing what it should look like.

I have always been fast with HTML. Not fast in the “I Googled a tutorial” way. Fast in the way where I can sit down with a blank file and produce a working interface in an afternoon. No framework. No build toolchain. Just a structure, some CSS, and a layout that tells you exactly what belongs where. I’ve been doing it for a long time. It’s muscle memory.

So before I wrote a single prompt asking an LLM to generate backend code, I built the screens. Every screen I wanted BenchBoard to have. Exactly the way I wanted them to look. Exact colors, exact layout, exact interactions. I wasn’t wireframing. I was prototyping. The difference matters: a wireframe is a suggestion. A prototype is a contract.

Here’s what I see a lot of non-programmers doing instead. They open a chat, describe their idea in a paragraph, and ask the AI to build them an interface. And it does. It builds something. It looks clean. It looks modern. It looks like every other app that came out of the same prompt with slightly different nouns. What it looks like is the AI’s best guess at what a solution to your problem could look like, filtered through every design pattern in its training data, averaged into something that is confidently generic.

The problem isn’t that the output is ugly. The problem is that the person with the idea has been funneled into a template. They didn’t design a solution. They accepted a suggestion. And because the interface came out looking polished, they assume it’s right. They ship it. Coaches open it. Coaches close it.

I did it differently. I sketched on paper first. Showed a few coaches what I was thinking: rough printouts, hand-drawn layouts, literal paper on a table. I watched their eyes. Where did they look first? What did they reach for? What did they ask about before I explained it? Then I went home and built those screens in HTML. Not because I had to. Because that’s how you turn a nod from a real user into a real product. The HTML was already the answer before the AI wrote a single function.

I want to be fair here. There is an enormous amount of work where LLM-generated boilerplate is exactly the right tool. Closing gaps in internal corporate processes, building admin dashboards, generating forms and reports and CRUD screens. That’s the bread and butter, and Claude handles it better than anything I’ve ever used. If you need a thing that looks roughly like ten other things that already exist, let the AI build it and move on.

But if you are building something from scratch, something nobody has built quite this way for users with a specific problem you actually understand, then the interface is not a template problem. It’s an engineering problem. And the only way to solve an engineering problem correctly is to know what correct looks like before you start building. The AI doesn’t know. It has never stood behind a chain-link fence watching a coach try to manage nine kids, two parents texting about playing time, and an umpire who disagrees with the count. All at the same time. On a phone with two bars. I know. So I drew the screens first.

What that shift represents is more important than it sounds. We are no longer fighting syntax. We are no longer reading SolidJS method docs at midnight trying to figure out why a reactive signal isn’t updating. The AI absorbed all of that. The boring machinery of building software (the boilerplate, the lookups, the wiring) is largely handled. What’s left is the actual job: the vision, the judgment, the problem to solve. Engineering. The stuff that was always the hard part, and is now the only part.

Thank God for Claude in those moments. And thank God the judgment still belongs to us.

Then I used the LLM to make those prototypes functional. Not to design them. I’d already done that. To wire them up. Fill in the logic behind the buttons. Connect them to data. I handed it a finished face and said: make this breathe.

That inversion (human designs, AI implements) is different from how most people are using these tools. And I think it’s why my output looked the way I wanted it to look from day one. The AI didn’t make aesthetic decisions for me because I never gave it the chance.

There was one other big decision at this stage, and I almost made it the hard way. If I’m building a web app and a mobile app, do I need three codebases? Web, iOS, Android? That’s not a question of effort. It’s a question of sanity. Three separate stacks, three separate build processes, three versions of every bug.

Then I found Capacitor. In short: build your web app, wrap it, ship it as a native app on iOS and Android. One codebase. One set of logic. Three front doors. I made a conscious call that the tradeoffs were worth it: stay on the web, where I was fast, where the AI had plenty of training data, and where I didn’t have to become a Swift developer while simultaneously building a scorekeeping engine.

Some decisions only look obvious in retrospect. That one I knew immediately.

I Almost Exited The Freeway When I Didn’t Have To

The frontend decision almost broke me.

I had started the project in SolidJS. If you’re a developer reading this, you know what that means. If you’re a coach: it’s like choosing to drive a manual transmission because it’s more precise than an automatic. Most people don’t, and the road signs are all written for automatic drivers.

About six months in, the AI started pushing back. Not explicitly. It would just... struggle. SolidJS has a smaller footprint in training data than React. The AI knew React cold. It knew the React ecosystem, the React patterns, the React error messages and workarounds. And occasionally, frustratingly, it would say essentially: I could do this a lot faster if you were in React.

I almost switched. I had the migration mapped out. I was a few days from pulling the trigger.

What stopped me was a different realization: the AI wasn’t failing because SolidJS was wrong. It was failing because it didn’t have enough documentation to work from in context. The fix wasn’t to change frameworks. The fix was to feed it the docs. Paste the SolidJS documentation directly into the conversation. Tell it where to look. Give it the training data it was missing, right there in the prompt.

That worked. And it reminded me of something I now treat as a standing rule: these models don’t come with a complete map of every library in the world. They have deep coverage of what’s popular. Outside of that, you are the guide. You hand them the map.

There’s also something worth saying about timing. What was true in August 2025 is not what’s true in April 2026. If I were starting this project today, I’d probably make different choices. Not because my instincts were wrong, but because the tools have moved that fast. The models are bigger. The context windows are longer. What an AI can hold in its head in one session is different. The decision space in 2026 is not the same one I was standing in when I started.

I say that not to be wistful. I say it because anyone starting a project today needs to hear it: the advice you read six months ago may already be stale.

The Tools Didn’t Stand Still Either

Here is something the “AI is replacing developers” crowd never talks about: the AI itself kept changing while I was building.

I started with ChatGPT (GPT-4-something), using it mostly as a research and thinking tool. Then I moved into Codex when I was ready to generate actual code. Codex was the first time I felt like I had a collaborator instead of a search engine. It could read a file and write something that fit into it. That was genuinely new.

Then came Cursor. Cursor had IDE integration, project-wide context, the ability to see your whole codebase at once. I used it hard.

Then Windsurf. I still use it occasionally.

Then Claude Code. And that changed things in a specific way I haven’t seen documented well anywhere: refactoring. Not generating — refactoring. Taking something I’d already built and restructuring it without breaking everything downstream. Other tools I’d tried would attempt a refactor and introduce three new bugs for every one they fixed. Claude Code could hold the shape of the change in context, understand what was downstream of it, and make the move cleanly. I’ve never seen another tool do that consistently. It’s the reason I’m building in Claude now instead of somewhere else.

I’m not telling you this to review products. I’m telling you because the arc of that journey says something. In less than a year, the stack I’m building with has changed as dramatically as the stack I’m building on. The IDEs are updating. The models are updating. Language repositories that were stable for years are getting major commits every few weeks, because the tools that write code have started outpacing the tools that define what the languages can do.

Agentic development isn’t coming. It’s already the normal.

The question isn’t whether you’ll be building with AI. The question is whether you’ll be the person in the room who knows what to ask it to build, and whether you’ve been in enough dugouts to know when the answer it gives you is wrong.

The Cache That Lies

As of this writing, I’ve built what I hope is a stable version of the scorekeeping engine. It’s not pretty, but that’s okay for now. It’s a draft I’m currently testing in real games, and every time I take it onto a field I find something else the AI would not have surfaced on its own. Let me walk you through one of them, because it is the clearest example I have of why both disciplines are needed in the same brain.

Softball/baseball mode: on. As you should know, an at-bat has a count. Balls and strikes. Every pitch pushes one or the other number up. Four balls is a walk. Three strikes is out. Everyone in the park is watching that count. And if you still don’t know — an at-bat is someone ready to swing at home plate. Go watch an MLB game. I’ll wait.

Of course, that count resets to zero when the at-bat ends (hit, out, walk, whatever) and the next batter steps up. Right?

So how does BenchBoard know what the count is?

The obvious answer, the one the AI built, is to store two numbers in the database. Call them CurrentBalls and CurrentStrikes. Every time a pitch comes in, bump one of them up by one. The scoreboard reads those two numbers and shows them on the screen. Done.

When I saw what the AI had done, I asked Claude one question:

Doing CurrentBalls and CurrentStrikes wouldn’t be reliable right? If the transaction doesn’t work out between the PitchEvent and the GameEvent. My thought is to create a Table view based off PitchEvent and GameEvent. What do you think?

Quick normie decoder before we go further. A PitchEvent is exactly what it sounds like: a record of a single pitch. Ball. Strike. Foul tip. Every time the pitcher throws, the scorekeeper taps a button and that throw gets its own row in the database. Think of it as a receipt for each individual throw. A GameEvent is the bigger thing that ends an at-bat: a hit, a walk, a strikeout, whatever finally settles the matter. If PitchEvents are the individual plays in a poker hand, the GameEvent is when someone finally says “I’m in” or folds. One GameEvent can have anywhere from one to a dozen PitchEvents attached to it.

Let me translate that for the normies, or more importantly the coaches, if you’re still with me. All you developers already get it, come back after this.

Imagine the scoreboard operator at the field. They keep a sticky note on the dashboard with the current count scribbled on it. Every pitch, they cross it out and write the new one. Ball four. Strike one. Three-and-two. The count lives on the sticky note.

Now imagine the umpire. The umpire doesn’t need a sticky note. The umpire has a little clicker. One bead for every ball, one bead for every strike. The beads are the count. They can’t lie. If you want to know the count, you look at the beads.

Sometimes, in a fast-moving game, the umpire relies on the scorekeeper to keep count anyway. I can’t tell you how many times I’ve watched the umpire and the scorekeeper frantically compare notes when someone tries to steal a base, or when a softball pitcher is accused of a circle violation, or when the crowd starts yelling about a missed strike. A lot can happen. And we haven’t even talked about the myriad of rules that come into play across different divisions of youth baseball and softball.

When the sticky note and the beads disagree, it’s a problem. Somebody out there in the stands is counting too, and that can be an embarrassing moment. Or it can be a crucial one in a playoff tournament. The beads and the scorekeeper are only as good as the people paying attention. Ultimately, the scorekeeper is the go-to. Even when the umpire has a clicker, the clicker can be wrong. The scorekeeper’s app is who everybody ends up trusting.

Which means the scorekeeper’s app had better not keep its count on a sticky note.

The reason I bring all of this up is because the system just needs to work. No one cares what a cached value is in a database. But I do. And when that value is wrong, I know the impact of that mishap.

What I proposed instead was a database view. A view is a little window into the data that re-calculates the answer every time you look at it. Don’t store the count. Don’t trust anybody’s sticky note. Look at the actual pitches on record and count them, live, every time someone asks. This is the background crap no user will ever see. This is the stuff vibe coders and product managers will falter over. NO ARTIFICIAL INTELLIGENCE WILL EVER GET YOU HERE. EVEN WITH UNLIMITED TOKENS, POWER, AND CPU, THE AI AGENT WILL NEVER FIGURE THIS OUT ON ITS OWN. ONLY YOU.

This is when the AI came back with:

You’re right to question it. CurrentBalls/CurrentStrikes on the Game table is essentially a cached/denormalized value that can drift... A database view is the right approach.

Here’s what “drift” means in human terms. Over the course of a long enough game, or enough games, the sticky note and the beads disagree. The displayed count is wrong. A pitcher gets pulled one pitch too early. A batter walks who should’ve struck out. Nobody can explain it. The app works 98% of the time. That 2% is the 2% where coaches stop trusting the app.

Multiply that across thousands of pitches in hundreds of games in dozens of leagues, and “most of the time” isn’t good enough.

So we ditched the sticky note. The count is now a live query. Count the pitches, return the answer. One source of truth: the PitchEvent records themselves. If there are three balls and one strike on record and no at-bat outcome yet, the count is 3-1. Period.

Here’s what that actually looks like in the database during a real at-bat:

Pitch 1 - "Ball"    GameEventId = NULL   ← pending
Pitch 2 - "Ball"    GameEventId = NULL   ← pending
Pitch 3 - "Strike"  GameEventId = NULL   ← pending
Pitch 4 - "Ball"    GameEventId = NULL   ← pending

Count right now = count the NULLs = 3 balls, 1 strike

GameEventId is just a tag that says “this pitch is part of that at-bat.” Until somebody hits, walks, strikes out, or does anything that ends the at-bat, every pitch sits in a pending state, tagged NULL, meaning “no at-bat result yet.” The database doesn’t have to remember the count. It just counts the pending pitches.

Then the batter hits a single. The scorekeeper taps “Single.” The database creates one at-bat record (Result = "1B") and goes back and stamps every one of those pending pitches with that at-bat’s ID:

Pitch 1 - "Ball"    GameEventId = "event-xyz"   ← resolved
Pitch 2 - "Ball"    GameEventId = "event-xyz"   ← resolved
Pitch 3 - "Strike"  GameEventId = "event-xyz"   ← resolved
Pitch 4 - "Ball"    GameEventId = "event-xyz"   ← resolved
Pitch 5 - "Hit"     GameEventId = "event-xyz"   ← the at-bat outcome (Result = "1B")

Pending pitches = 0   →   Count is 0-0. Clean slate.

No pending pitches means no count. The next batter steps up and the count is automatically 0-0 without anybody telling the system to reset it. The data model does the work.

That pattern, every pitch floating in limbo until the at-bat ends and the outcome reaching back to claim them all at once, is the thing that makes the live view correct. And when I asked the AI months later whether we should merge PitchEvent and GameEvent into a single table, it pushed back and told me we shouldn’t, because “the GameEventId IS NULL design is load-bearing.” Its exact words. That one design decision is now keeping a dozen downstream features from falling over.

But here is the thing I want you to hold onto.

The AI built the sticky-note version first. It was faster. Cleaner. It compiled. It passed tests. If I’d accepted it, it would have shipped. And it would have drifted. And I would have spent months chasing phantom bugs where the displayed count didn’t match reality, with no idea why.

The AI didn’t know to distrust itself.

I did.

Not because I’m smarter. Because I’ve built systems that store money, systems that store medical records, systems where a cached value disagreeing with the source of truth meant somebody got on a plane with the wrong seat. I’ve seen that movie. The AI hasn’t.

And because I’ve coached enough innings to know what it looks like when a scoreboard lies to a dugout.

Two Players, Same Number

Here’s another that is short and it tells you everything.

Somewhere in the scorekeeping build, the app has to match up an opposing team’s players. When you’re scoring a game against another team, the scorekeeper enters their lineup. Sometimes those players already exist in the system, because they’ve played your team before. Sometimes they’re new. You need to know which is which, because if you’re creating duplicate records for the same kid every game, your data is immediately garbage.

How do you match?

The AI’s instinct was to match by jersey number. That’s the textbook answer. Jersey numbers are short. They’re printed on the kid. They’re unique within a team. In a computer science classroom, that’s a clean natural identifier and you’d use it without blinking.

Here’s what I told the AI:

DO NOT match by jersey number. It is NOT reliable as there could be guest players who have the same number.

If you’ve never been around youth travel baseball or softball, you wouldn’t know. In travel ball, teams regularly pick up guest players for a single tournament. That guest might wear a number that’s already on the regular roster, because nobody’s coordinating. You show up to a tournament and suddenly there are two #12s on the same team for the weekend. The AI’s “clean natural identifier” is, in reality, not unique at all.

I can count on one hand the number of computer science textbooks that mention “guest players may have duplicate jersey numbers on a given weekend.” It is zero. The number is zero.

That is a domain rule. It lives in the head of somebody who’s been a coach or a scorekeeper or a parent at enough tournaments to know. It is not in training data. It will never be in training data, because it is too local, too specific, too recent, and too unwritten to show up in anybody’s blog post.

And if you match by jersey number, your stats table becomes a fiction within three weekends.

The Phantom Runners

I’m testing End Inning late one night. I tap the button. The bases clear. The inning advances. I look at the scoreboard.

There are runners on second and third.

There weren’t supposed to be runners on second and third. I just ended the inning. The bases should be empty.

I tap End Inning again. Bases clear. Inning advances. I look again.

Runners. Same bases. Same phantom runners, appearing out of nowhere every single time I end an inning.

Here’s what End Inning actually does under the hood. When you tap it, the app immediately clears the bases on screen (instant visual feedback, the diamond goes empty) and raises a little internal flag that says “we’re in the middle of switching innings, don’t trust anything coming in right now.” Then it waits 3.5 seconds before officially telling the server the inning is over. That brief pause is intentional. It makes the transition feel smooth rather than janky.

Think of it like a hotel checkout. You tap “check out,” your key card stops working immediately, the room shows as vacant on the front desk screen. But the housekeeper is still in the hallway and might radio in “Room 214 has towels on the floor” during those few seconds before the system fully processes your departure. The system needs to know: that message is stale, ignore it.

That’s the flag. _halfClosing = true means “we’re checking out, discard any incoming towel reports.”

Now. BenchBoard has a real-time connection called SignalR that acts like a radio tower constantly broadcasting the game state to every connected screen. Parent phones. Scoreboards. The scorekeeper’s tablet. During that 3.5-second window, the server doesn’t know the inning is over yet, so it fires off one last broadcast of the current game state: runners on second and third, exactly as they were a moment ago.

Three different pieces of code receive that broadcast and decide what to do with it. Think of them like three front desk clerks, each responsible for one part of the checkout process. One handles the bases. One handles the ball-strike count. One handles the overall game state. When a broadcast comes in, each clerk processes their piece of it independently.

The bases clerk checked the flag. “Oh, we’re mid-checkout? I’ll ignore this.” ✅ The count clerk checked the flag. “Mid-checkout? Ignoring.” ✅ The game state clerk, the third one, never got the memo. No flag check. So when the broadcast arrived with runners on second and third, that clerk went right ahead and updated the scoreboard. Runners restored. Every time.

These pieces of code are called handlers. Each one listens for a specific type of incoming message and handles it. Think of the checkout guard as a sticky note on each clerk’s monitor that reads: “If the guest is mid-checkout, don’t process anything. Wait.” The AI had put that sticky note on two of the three monitors and forgotten the third clerk’s desk entirely. That clerk had no note. No instruction. So when the housekeeper’s radio message arrived mid-checkout, that clerk processed it like a normal guest request and put the runners back on base.

It had no way to catch this because it never actually ran the scenario: tapping End Inning in a live game with real runners on base and a real SignalR connection humming in the background. It tested in its head. I tested on a field.

The fix was four lines of code. One check at the top of the third handler: “are we mid-transition? Yes? Get out.”

Four lines. Phantom runners gone.

What I want you to take from this isn’t the fix. It’s the instinct behind finding it. Knowing to look for a missing guard on the third handler, when the first two had it, is not something you Google. It’s not in any tutorial. It lives in the part of your brain that remembers the last time something blew up during a transition window in a system that moved fast. Every developer who has shipped real-time software has a version of this scar. That scar is what made me look at the third handler. You can’t prompt your way to a scar.

Building Clean Lanes Before They Collide

There’s a category of architecture decision that I think about as “building for users who haven’t shown up yet.” The AI doesn’t make these decisions. It builds for the user it can see. You have to build for the user who’s going to show up next spring and break everything.

Here’s the one that almost cost me.

BenchBoard’s real-time layer, the pipe that pushes pitch counts, base updates, and score changes to every connected screen, was originally scoped to team-{teamId}. When a scorekeeper tapped “Ball,” the backend broadcast countUpdated to the team-{teamId} SignalR group. Every client that had joined that group (the scorekeeping screen, the scoreboard on the tablet, the parent’s phone) received the update.

Clean design. Logical. The AI built it correctly for the scenario it knew about: one team, one active game.

Then I thought about the tournament.

Tournament day. Your team plays Game A in the morning. Same team plays Game B in the afternoon. Two different games, two different opponents, two different scoreboards. One team ID in the database.

Here’s the normie version of what was happening. Remember SignalR, our radio tower from the last section? Every device that needs live updates tunes into a channel and listens. Originally, every device connected to Team X was tuned to the same channel: Channel Team-X. Game A broadcasts on Channel Team-X all morning: scores, pitches, base updates, the works. Game B starts in the afternoon. Also on Channel Team-X. The moment Game B goes live, it’s sharing a channel with everything Game A ever said. Stats bleed. Scores overlap. A parent opening the app for Game B could see Game A’s final score pre-loaded into Game B’s scoreboard before a single pitch has been thrown.

Nobody knows why the numbers are wrong. They just see something wrong. And they stop trusting the app.

The fix was to give every game its own private channel — Channel Game-123 — instead of sharing one channel per team. Field 3 talks on its own frequency. Field 5 talks on its own frequency. No crosstalk. Every device tunes in when its game starts and tunes out when the game ends.

I brought this to the AI:

“SignalR groups are by team ID, not game ID. If one game happens right after the other, which happens in travel sports all the time, counts from the previous game could bleed through.”

The AI’s response:

“Makes complete sense. Game-scoped groups are the right foundation for that — any client (TV, parent phone, scorekeeper) just joins game-{gameId} and gets exactly that game’s events. No auth required for read-only consumers either.”

Called it architecturally correct. Once I handed it the answer.

The fix touched four places in the backend where broadcasts were going out, and added two new instructions on the frontend: tune in when a game opens, tune out when it closes. That’s it.

Commit message: “scope all game broadcasts to game-{gameId} groups.”

But I want to linger on what the AI said after I pointed out the problem: “No auth required for read-only consumers either.” That’s not a small thing. It means a TV scoreboard at the concession stand, or a parent’s phone on the other side of the fence, can now join game-{gameId} without logging in. They’re just watching. The scoping decision I made for tournament correctness also opened the door for the read-only scoreboard use case that I’d been planning to build eventually.

Those future users, the parents in the parking lot and the scoreboard on the TV behind the dugout, didn’t exist yet when I made this call. I built for them anyway, not because the AI suggested it, but because I could see the field from both sides of the fence. Forty years of building software. A few years of standing at third base watching parents crane their necks at a phone. You put those two things together and you see problems before they arrive.

That’s the job.

The Master Orchestrator

This one is about knowing when a patch is a lie.

The inning-by-inning linescore (the little table showing runs scored per inning, the one that looks like the back of a baseball card) was displaying all dashes. The R/H/E totals were correct. The game data was in the database. But the per-inning breakdown showed nothing.

The fix seemed simple. When the app first loads a live game, it calls out to the server and asks for the current game state: scores, inning, count, everything. That request is called an endpoint: think of it as knocking on a specific door and the server handing you a box of data. The door we were knocking on wasn’t including the per-inning scores in the box. Fix the door, add the scores to the box, unpack them onto the screen. Done. Committed. Working.

Then, later in the same session, after other work had been done in between, I looked at the scoreboard again.

All dashes.

I pasted the raw HTML of the broken table directly into the chat, the actual output the browser was producing, and asked the AI what happened. It searched the code for the function that built the innings array. Found nothing. Its diagnosis: “These were lost in the refactor.” It spent several exchanges chasing the wrong trail before finding the real culprit.

Here’s the normie version of what was actually happening. Remember the walkie-talkie network? Every time a real-time update comes in over the radio (a new score, a pitch, anything) a handler unpacks it and updates the screen. One of those handlers was responsible for updating the scoreboard’s game state. And every time it ran, it replaced the entire scoreboard with a fresh copy from the broadcast — a broadcast that, being a quick live update, didn’t bother including the full innings history. Why would it? It was just saying “the score changed.” But the handler didn’t know that. It just unpacked the box, saw no innings data, and set the innings to empty. Every. Single. Update.

The initial load populated the innings correctly. The first live broadcast erased them.

Fix: tell the handler, “if the incoming box has no innings data, don’t touch the innings we already have.” Sticky note on the monitor. Committed. Working.

Then the innings disappeared again.

At this point I stopped asking “what broke” and started asking “why does this keep breaking.” Here’s how I put it to the AI:

“Is there an opportunity to centralize our code to serve both the scoreboard inning columns and scorekeeping inning columns, the R/H/E and the B/S/O of both scoreboard and scorekeeping? Just want to make things efficient since it’s all real-time and reduce any spaghetti code and stay DRY.”

The AI ran a full audit and came back with something I hadn’t seen laid out before. Two completely separate filing systems, one for the scorekeeping screen and one for the TV scoreboard, both storing the exact same information. Same team names. Same inning scores. Same R/H/E totals. But maintained by two different pieces of code, updated by two different radio handlers, fetched from two different server doors. Every time you fixed a problem in one filing system, the other one could still clobber it.

Think of it like two assistants both keeping a copy of the same spreadsheet on separate computers, neither one aware the other exists. You update one. The other one hasn’t heard. Now they disagree. Which one is right? Nobody knows. You can fix the disagreement, but unless you get rid of one of the spreadsheets, it’ll just disagree again the next time someone updates the wrong copy.

It also turned out the scorekeeping linescore, the broken inning table, was a hand-built duplicate of a component that already existed and was working perfectly on the TV scoreboard. Two versions of the same table, written separately, living separate lives, drifting apart.

The AI laid out the fix in three steps. Do two now: swap the duplicate table for the shared one, fix the team abbreviation that was showing as "HME" instead of the real team name. Defer the third (consolidating the two filing systems into one) because it was, in the AI’s exact words: “meaningful structural risk” that “touches SignalR wiring in both hooks.”

My response:

“Yes, let’s do #1 and #2 — but we HAVE to do #3 also. It’ll only get worse and gain complexity if we don’t fix it after #1 and #2.”

The AI did all three. One pass. Clean build. Its closing summary:

“Data flow is now: one door → one unpacker → one filing system → both screens read from the same place.”

One path. One source of truth. The innings have not gone blank since.

Now let me tell you what “meaningful structural risk” actually meant. It meant the AI counted the number of files it would have to touch, pattern-matched that to “big change, high chance of breakage,” and recommended waiting. That’s a reasonable call if you’re working with someone who doesn’t understand what those files do or how they connect.

I wrote those files. I know exactly how they connect.

And more importantly: I knew what deferring cost. Every session I left those two filing systems in place was another session where someone could update the wrong copy and the innings would go blank again. Not because the patches were bad. They were correct. But a correct patch on top of a broken foundation is just a nicer-looking problem. It’s fixing the leak with a bucket instead of the pipe.

A vibe coder reads “meaningful structural risk” and defers. They’ve never been in a system long enough to watch deferred fixes pile up. I have. I know what that bill looks like when it finally comes due.

This is what I mean when I say the fundamentals still matter. Not typing. Not syntax. The thing behind the syntax: the principle that a system with two sources of truth will eventually lie to you, that two components doing the same job will eventually diverge, that the time to close a complexity gap is before the next feature lands on top of it. Those principles were true before AI wrote a line of code and they’ll be true when the models are ten times better than they are today.

You can prompt your way to working software. You cannot prompt your way to the judgment that knows when working software is a trap.

Coming Up in Part 5

Part 5 brings it home. What I’ve changed about how I work with AI tools after building all of this. What I’ve stopped doing. What I’ve started doing. And the single question I now ask before I accept any output, from any model on any task, that has saved me more hours than I can count.

Thanks for reading. If this series has landed for you, subscribe. Part 5 is the one where it all comes together.

I was building a substitution feature into BenchBoard the other night. Simple idea on paper: a coach drags a kid into a “sub” slot, and the app tracks who’s covering for whom. The kind of thing that sounds like an afternoon and turns into a week.

At some point I hit a question I couldn’t punt on. What happens when a coach drags a player onto a sub slot that’s already occupied? Somebody’s already sitting there. Kick them out automatically, or stop the coach and make them clear it first?

I asked the model. It gave me a clean, confident answer: swap them. Bump the existing sub out to the reserve, drop the new player in, done. One gesture, no friction. Honestly a good answer. I’d endorsed the same approach myself ten minutes earlier.

Then I thought about it from the field and pushed back. Here’s the actual exchange. Watch what happens.

Me: When a starter (or reserve) gets dragged over an existing sub slot, it shows a circle strikethrough icon. [...] OnDrop, we could also fire a popup [...] Then the user just needs to drag that player again. [...] This feels like a much better UX. Thoughts?

Claude: This is better than the swap, and I’ll tell you why I’m now against the swap I previously endorsed: bumping Mariano to Reserve as a side effect of dropping Will is an invisible data change. The user’s eye is on Will; Mariano teleports while they’re not looking, and ten minutes later it’s “wait, why is Mariano in Reserve?” [...] for a lineup tool surprises are the expensive thing.

Read that again. It reversed itself instantly. Not grudgingly. It wrote me a genuinely good argument for why my way was better than the way it had recommended thirty seconds earlier, and it did it with the exact same authority it used to recommend the wrong thing.

Now, I’ll be honest with you about something. A while back I would have looked at that moment and concluded that coding itself wasn’t really the superpower, that the syntax was just a tax and the only thing that mattered was the judgment call. I was wrong, and I want to correct it here, because that framing is lazy and it feeds the worst advice going around right now. What that exchange actually proves is the opposite. Coding is still the superpower. It just got the upgrade of a lifetime. And the upgrade makes the human underneath matter more, not less.

I Have a Jet Pack Now

Boris Cherny, the engineer who created Claude Code, put it better than I can. On The Circuit with Emily Chang, the Bloomberg show, he described what AI-assisted engineering feels like now:

Cherny: I suddenly have superpowers and I have a jet pack and that engineering has never been this fun.

That’s exactly it. Claude Code is my Iron Man suit of choice, the most effective one I’ve used so far. It makes me faster than I have ever been in my life. But here is the part the hype merchants skip past: a jet pack does not fly itself, and the suit does not make you Tony Stark. Stark’s superpower was never the suit. It was the engineering mind that designed it and knew what to do with it. The suit only turned that mind into something that could level a building.

Chang pushed Cherny on the obvious fear, and his answer is the whole thesis of this article:

Chang: All of this raises an obvious question. Will engineers be the first casualties of the AI they’re building? [...] It’s been Revenge Of The Nerds for a while. Is that over?

Cherny (laughing): I think we all become nerds!

Chang: But what happens to the ACTUAL nerds?

Cherny: I think the actual nerds will have to figure it out. I think for a lot of them, the skill that they had before is gonna help them in the future because they sort of have a pretty big headstart. They do a lot of things that are not coding. Engineers also have to talk to users. They have to plan, they have to think about what’s next. And so those are parts of engineering that are gonna stick around.

Boom. The headstart is real. The engineer who already knows how systems fit together, who can talk to a user, who can see what’s coming, walks into this era with the suit fitting like it was custom built. The person who only ever learned to prompt walks in wearing something they cannot actually fly.

So let me say the corrected version plainly. Coding is still the superpower. It’s just upgraded, and far more impactful than it has ever been. But you only get the upgrade if you already have the thing being upgraded.

Knowing What the Code Is Doing

The bug that kicked off that session is the cleanest proof I have of why you still have to know what the code is doing, even if you never type a single line of it.

In BenchBoard, a sub slot is labeled something human like “Sub for Grace.” But under the hood, the slot isn’t keyed to Grace. It’s keyed to a number. The slot means “whoever is batting 7th.” Not Grace the person. The 7th spot in the order.

That distinction seems like nothing. It’s everything. So let me show you instead of telling you, the exact way the model showed me: it laid the lineup out in plain text and asked if this was actually what I meant.

Here’s the lineup. A coach grabs Radford, batting 2nd, and drags him onto Grace’s sub slot, the one labeled “Sub for #7.”

THE DROP:   Radford (#2)  ─────────►  slot "Sub for #7"

  Bat #    Starter
  ─────    ──────────────
    1      Alice
    2      Radford      ← dragging this player
    3      Ben
    4      Carla
    5      Dan
    6      Erin
    7      Grace        ← you dropped on HER slot ("Sub for #7")
    8      Hana

Now the naive code does the obvious thing: pull Radford out of the starters, renumber so there are no gaps, then save “Radford subs for #7.” Watch what the renumber does to everyone sitting below him.

  Bat #    Starter               (Radford pulled, gap closed, all shift up)
  ─────    ──────────────
    1      Alice
    2      Ben          (was #3)
    3      Carla        (was #4)
    4      Dan          (was #5)
    5      Erin         (was #6)
    6      Grace        (was #7)   ← Grace slid up to #6
    7      Hana         (was #8)   ← #7 now belongs to HANA

  Code saves:  Radford.substituteFor = 7
  But #7 is Hana now.  You meant Grace.            ✗  off by one

That’s the entire bug, sitting right there in the table. You dropped Radford on Grace. The renumber slid Grace up to #6 and slid Hana into #7. The code, still clutching the number 7, just recorded that Radford is subbing for Hana. Your gesture said Grace. The data says Hana.

And here’s the detail that makes it evil: it only happens on downward drops. Drop a player onto a slot above them and nothing below shifts, so it works fine. Drop below and it’s off by one. In testing it looks random, which is the worst thing a bug can look like. Here’s how the model diagnosed it:

Claude: The number 7 is unstable across the renumber, but Grace isn’t. So the handler does the lookup before the world shifts and the write after [...] the player id is the stable handle you carry across the mutation.

And then it named the root cause in one line every developer should tattoo somewhere:

Claude: The schema stores a pointer (substituteFor) in a coordinate system (battingOrder) that mutates underneath it.

In plain English: don’t hold onto the number, hold onto the person. The number is a parking spot anyone can pull into. The player is the car. You track the car.

That’s a sharp diagnosis, and the model wrote it. But it only got there because I knew enough to smell the bug, describe the symptom precisely, and recognize the fix as correct when it came back. Hand that same situation to someone who doesn’t understand what a renumber does to a stored reference, and that explanation is just noise. They’d nod, ship it, and never understand why their app “randomly” assigns the wrong sub.

This is the thing about even the best model, and Fable is the best I’ve used for this kind of deep tracing. Make it Mythos times a hundred. It still does not know what optimal looks like in your system. It knows a hundred plausible ways to do a thing. It does not know which one is right for the product you are actually building, because it has never stood where you stand. You do. That’s not a syntax skill. It’s knowing what the code is doing and why.

A Few Years Ago, This Was a Different Job

Let me tell you what building software used to be, for those of you who weren’t there.

You knew a language. And then you spent half your life Googling to the ends of the earth to find out whether some other engineer had already solved the thing in front of you. Before you wrote one useful line, you set up the lab. Picked the environment. Argued with yourself over the language. Fought the toolchain. Getting the environment to even stand up was a shitload of work that had nothing to do with the actual problem. Then you started typing, and it was a guessing game, because the smartest your IDE could do was autocomplete the back half of a single method if you were lucky.

Today it’s a conversation. I talk to Claude Code and I am more productive than I have ever been. But here is the part that matters: it requires more engineering than ever, not less. Because now you’re going toe to toe with a robot that knows how to code and knows a hundred ways to approach any problem. And even with all of that, the robot can still be wrong. Confidently, fluently wrong, the way it was when it told me to swap Mariano out from under the coach’s nose.

That gap, the robot is fast and deeply knowledgeable and still sometimes wrong, is exactly what separates good engineers from bad ones now. The old gate was “do you know the language.” The new gate is “can you tell when the confident machine is wrong, and do you know what right looks like instead.” That is a higher bar, not a lower one.

The Part That Sticks Around

During the interview with Chang, Cherny named the parts of engineering that survive: talking to users, planning, thinking about what’s next. I’d add one that sits underneath all of those. Not just solving the problem, but deciding how to solve it.

Back in that same session, after I’d tied myself in knots over the off-by-one, I stepped back and told the model I was overthinking it:

Me: I’m over thinking it. Here’s what I want to do [...] Wherever Will C. goes, we just make the shift, do the math and just do it like that. Thoughts?

Claude: Your simplification is exactly the right call, and good news: it’s not a solid-dnd limitation at all. The behavior you want is blocked by two deliberate lines of your own code, not the library.

The model found the two lines. Fast, by location, in seconds. That’s the suit doing exactly what the suit is great at. But the decision to throw out my elaborate version and collapse the whole feature down to “wherever the player goes, do the shift math” was mine. The syntax took a back seat. How the thing got solved did not.

This is the point in your own five points I want to hammer hardest. Problem solving was never only about solving the problem. It’s about how you choose to solve it. Writing the function is the easy part now. Deciding what the function should be, how it should behave, what it should refuse to do, that is the job. That was always the job. We just used to be so busy fighting the language that we mistook the fight for the work.

The Checkpoint

Anyone who grew up on hard games knows exactly what a checkpoint is. You’re deep in a brutal level, the kind with a miniboss waiting at the end, and right before the fight the game drops a checkpoint. A place to respawn. Die to the boss and you don’t restart the whole game, you start right there and go again. Walk away for the night and you pick up where you left off. It’s the line between the part you’ve already conquered and the part you haven’t.

Learning real engineering works exactly like that. Every meaningful skill is a level with a miniboss at the end. You grind through it, you die a few times, and when you finally beat the boss you’ve permanently banked a chunk of software engineering that you carry into every project after. You don’t relearn it. You saved it at the checkpoint.

The off-by-one bug from earlier in this article was a miniboss. The first time you fight “a stored pointer living in a coordinate system that shifts underneath it,” it wrecks you. You can’t even tell why your data is wrong. But beat it once and you own that pattern forever. Next time you see a value stored by its position instead of its identity, you recognize the boss on sight: an array index used as a key, a reference to “row 3” after the rows got resorted, same fight, different skin. You already know the moveset. That’s what clearing a miniboss buys you, the pattern recognition that makes the next version of the level easy.

If you want the purest example of this loop, look at the Souls games. A FromSoftware boss exists to humiliate you. The first attempt is chaos, you have no idea what’s happening, you’re dead in fifteen seconds. You respawn at the bonfire, which is the checkpoint, and you go again. And again. Slowly you stop seeing chaos and start seeing tells: the windup before the big swing, the gap right after it. Twenty deaths later the fight that was impossible is boring, because you’ve internalized the pattern. Then you run into a similar enemy in a later area and drop it on the first try, because you’ve seen this moveset before. That is exactly what building engineering judgment feels like, just with worse graphics.

Now here’s where the AI comes in, and this is the part vibe coders need to hear. Think Mega Man. You beat a boss, you get their weapon. But the genius of Mega Man was never collecting the weapons, it was learning which weapon wrecks which boss. Fire Man melts to the Ice Slasher, but you don’t know that walking in. You experiment, you guess wrong, you learn the matchup, and eventually you stride into a fight already holding the tool that trivializes it.

That’s your relationship with the AI now. Every pattern you’ve conquered is a weapon on your wheel, and the model is one more, an absurdly powerful one. But you’re still the player choosing when to fire it. You learn what it’s genuinely great at, tracing a bug across forty files in seconds, and what it will confidently fumble, like deciding what your product should actually do. You even ask it outright what it’s best for, the same way you’d test a new weapon on a boss to see if it sticks. Then you walk into the next level knowing which tool to bring.

Or think Metroid. The whole game is built on gates you cannot pass until you’ve earned the right ability. You reach the ledge you can’t jump to, the door you can’t open, and you leave. Twenty rooms later you find the High Jump Boots, double back, and walk straight through what used to be a wall. Engineering gates you the same way. There are problems you cannot solve, cannot even see the shape of the solution to, until you’ve earned the underlying skill. The day you earn it, the wall isn’t there anymore.

So to the vibe coders who actually want to take the next step, here’s the good news: you’re holding the most powerful weapon anyone has ever handed a beginner, and nobody is taking it away. But a powerup doesn’t beat the level for you. You still have to learn the patterns. You still need the basics of code, because you can’t aim a weapon you can’t see. You still need to know what the code is doing, because the boss has tells and you have to read them. You still need to understand architecture, because knowing which weapon beats which boss is the whole game. Clear those checkpoints, and the same suit that’s a liability in untrained hands turns you into the player who makes the hard level look easy.

The Brain Behind the Suit

Coding is still the superpower. I was wrong to say otherwise. It just got the upgrade of a lifetime, and like every upgrade, it rewards the person who already knew what they were doing and exposes the person who didn’t.

Fable is incredible, the best model I’ve used for going deep, and by the time you read this something will probably go deeper. It does not matter. The better these get, the more valuable the human who knows where to point them, who knows what good looks like, who can stand in front of a confident machine and say “no, here’s the better architecture,” and be right.

The suit is glorious. Jump in it. Just remember it doesn’t make you Amuro Ray. The brain does. And the brain you can still only build the old way, by actually learning the work.

Sources: Boris Cherny and Emily Chang quotes from The Circuit with Emily Chang, Bloomberg Originals (interview aired June 10, 2026). BenchBoard development exchanges are from my own working session with Claude Fable.

If this resonated, subscribe. I write about the honest, unvarnished experience of building real software with these tools, the parts the hype crowd leaves out.

There’s a particular kind of YouTube video that’s been showing up in my feed for the past year, and I’m guessing you’ve seen it too.

The thumbnail is a face making an exaggerated expression of shock. The title is in all caps and contains the word “SCAM” or “DESTROYED” or “I TRIED EVERY AI CODING TOOL SO YOU DON’T HAVE TO.” The motion graphics are gorgeous. There’s a sting sound effect every six seconds. The host has a lavalier mic, a ring light, and a studio that costs more than my first car.

And then they spend twelve minutes telling you that every AI coding tool on the market is garbage. Except for one. The one they happen to have an affiliate link for in the description. That one is incredible. That one will let you build a SaaS product in a weekend with no coding experience. That one is, in fact, so good that you should sign up for their $499 masterclass to learn how to use it properly.

I am not making this up. This is a genre now. And it’s actively making the world worse for people who are trying to learn how to build software with AI tools.

I’ve been writing code since the days when people used to buy a web browser to crawl the web (e.g. Netscape) so I feel I have a small say in it.

I’m currently building a SaaS product called BenchBoard, a team management and live scorekeeping app for youth baseball and softball coaches, with the help of LLMs. I’ve used pretty much everything under the sun: Windsurf is my daily driver right now, but I’ve spent serious time with Cursor, Replit, Visual Studio, ChatGPT, Codex, and Claude. And here’s the thing the YouTubers consistently miss: the tool itself matters far less than the model it’s wired to. The IDE is a wrapper. The actual brain doing the work is whatever model the IDE happens to be calling that you’ve inadvertently selected. If you’re evaluating an “AI coding tool,” you’re really evaluating a model wearing a costume. Confuse those two things and every comparison video you watch is meaningless.

Which is why it’s borderline absurd to watch someone “test” these tools by building a generic to-do list. Or a time-tracking app. Or admin screens. Or a calculator. Or any of the cookie-cutter demos that every AI coding video on YouTube seems to default to. That stuff is baked in. Every modern model has seen ten thousand to-do list tutorials in its training data. It will spit one out beautifully no matter which IDE you wrap it in. Some of these models have ingested entire codebases on simple games like Vampire Survivor and even the old school top-view GTA games. But I digress.

Watching an LLM build a to-do list and concluding anything about whether it can build your idea is like watching a chef boil pasta and concluding they can run a Michelin restaurant. The boilerplate is free — and has always been free.

The real question is what happens when you ask for something the model has never seen: your actual product, with your prototype screens, the constraints, your edge cases, your users. That’s where the wheels come off. And that’s the part those videos will never show you, because if they did, the affiliate link wouldn’t convert.

AI tools have genuinely accelerated what I’m able to build, and I write about that journey openly. So this isn’t an “AI is bad” rant. It’s the opposite. It’s a rant about people poisoning the well of a genuinely useful technology by selling shortcuts to people who don’t yet have the experience to know they’re being lied to.

There’s a better way to teach this stuff. There are a small number of people doing it right. There’s a CS professor at CU Boulder named Tom Yeh making the rounds right now talking about “AI by hand,” teaching students to work through the math and code mechanics manually before letting the AI abstract them away.

That’s the right instinct. Slow learning wins in the AI era, not faster button-pressing.

But you wouldn’t know it from your YouTube recommendations.

So here’s what the bad ones are missing. Here’s what any honest educator should be telling the next wave of would-be builders before they spend money on a course, a tool, or worse, months of their life building something that was architecturally broken from week one.

Seven questions. Ask them in this order. Demand real answers.

1. What Are You Building, and Why?

The number of “AI coding” tutorials on YouTube that skip this step entirely is staggering. The format goes: “Today we’re going to build a SaaS app using [Tool X].” The host then prompts the tool to “build me a project management app” or “build me a CRM” and the AI generates a bunch of screens that look real. By the end of the video, there’s a working-ish demo, and the comments are full of people saying “this is incredible, I’m going to build my own startup this weekend.”

What’s missing? Why are you building a project management app? Who is it for? What problem does it solve that ten other project management apps don’t already solve? What does “done” look like? What does success look like?

If you can’t answer those questions in two sentences, the AI can’t help you. Not because it’s not smart enough. It is. But because the AI will happily generate any app you describe. It has no opinion on whether the app should exist. It won’t tell you that the market is already saturated. It won’t tell you that the problem you think you’re solving isn’t actually a problem. It will just build.

I knew exactly why I was building BenchBoard before I wrote a line of code. I’m a youth baseball coach. Every other coach I knew was using a hodgepodge of tools: paper lineup cards, group texts, GameChanger for scoring, Excel for batting orders. None of it talked to each other. I wasn’t building a SaaS to get rich. I was building it because I was tired of writing lineup cards on the back of receipts in my truck.

That clarity, that specific clarity, shaped every decision I made afterward. What stack to use. What features mattered. What features absolutely did not matter. What “minimum viable” actually meant.

If your “why” is “because I saw a YouTube video and it looks fun to build a startup,” you are not yet ready to build. And no AI tool will fix that.

2. How Can I Validate This Idea Before I Start?

You’ve answered “what am I building and why.” Great. Now: are you sure anyone else cares?

This is where AI tools actually shine, and where the YouTubers get the closest to being useful, even if they usually frame it wrong. The honest version is: AI coding tools are incredibly good at letting you build throwaway prototypes fast. Mock screens. Click-through flows. A landing page with a fake signup form to see if anyone signs up.

For non-coders, this is the legitimate sweet spot of vibe coding. You can stand up a believable-looking prototype in an afternoon, put it in front of ten people, and find out whether your idea has any pulse. If it does, you build the real thing. If it doesn’t, you’ve spent an afternoon instead of six months.

The trap is when people treat the prototype as the product. They show their mock to twenty friends, get the inevitable “wow, cool!” reaction, and start thinking they’re ready to launch. They’re not. They’ve validated that their friends are polite. That’s not the same thing as validating a product.

Real validation looks like: strangers using your prototype without you in the room. Strangers finding it on their own. Strangers paying for it, or signing up for a waitlist with real intent. Strangers giving you feedback that hurts your feelings.

I’ll tell you a story. BenchBoard’s first real validation didn’t come from my friends or my own team. It came from a coach I’d never met who found it through search and started using it during games. Then he told me bluntly that what I’d built was “a nice toy, but it needs data.” That single piece of feedback from a stranger forced the most important pivot of the entire project. My friends would never have said that. They were too polite. He didn’t know me, so he had no reason to be polite.

AI can help you build the thing fast enough to put it in front of strangers. It cannot tell you whether the strangers will care. Get the prototype out. Stop polishing it. Stop adding features. Put it in front of someone who has no reason to be nice to you.

3. What Stack Should I Use, and Who Decides?

This is where the YouTubers commit their most consistent crime: they pick your stack for you, based on whichever tool happens to be sponsoring them this month.

A stack is not a personality test. It’s not a fashion choice. It’s a set of trade-offs that should match what you’re building, who’s going to use it, and where it’s going to run. A mobile-only consumer app, a B2B web dashboard, a real-time multiplayer game, and an internal admin tool are four completely different problems with four completely different correct answers.

The questions you should actually be asking are:

• Where do my users live? Phones, browsers, both? If it’s phones, are you ready for the App Store and Play Store review processes, or do you want a Progressive Web App for now?

• What does the data look like? Mostly reads, mostly writes, real-time, transactional, document-shaped, relational?

• What’s the failure mode if something breaks? Is this a system of record (financial, medical, scorekeeping) where wrong data is a disaster? Or is it a dashboard pulling cached data from somewhere else where wrong is “refresh and try again”?

• Who’s going to maintain this in two years? You, alone, with AI? A team? Nobody?

• What’s the cost profile? Are you bootstrapping or burning runway?

The honest answer for most beginners is some flavor of “web app, relational database, deploy somewhere cheap, use a framework with a large community so when you get stuck you can find answers.” That’s it. That’s the answer for 80% of projects. You don’t need eight microservices and a Kubernetes cluster. You don’t need a vector database because the YouTube guy mentioned it. You probably don’t need server-side rendering, edge functions, or a custom ORM.

The AI will happily generate any stack you ask for. It will also confidently tell you why the stack you picked is correct, even when it isn’t. Which brings us to the next question, the most important one in this whole article.

4. How Do I Know When the AI Is Wrong?

This is the single hardest skill in working with AI coding tools, and almost nobody on YouTube teaches it.

Because to teach it, you have to admit that the AI is wrong — a lot.

AI tools have a failure mode that I’ve started calling “confident sycophancy.” They will tell you your idea is great. They will agree with your architecture. They will defend a bad decision until you push back, at which point they’ll reverse course and tell you they could have warned you all along. They do this because they’re trained to be helpful and agreeable, and “helpful and agreeable” is exactly the wrong posture when you’re making decisions that will haunt you for a year.

I’ll give you the cleanest example from my own build.

A few months into BenchBoard, I decided to migrate my entire backend off Azure and onto Hetzner, a much cheaper, much simpler European hosting provider. Azure’s enterprise-grade compliance infrastructure was massive overkill for a youth sports app, and the bill was bleeding me dry. When I floated the idea to the AI, it argued against it. It listed all the reasons Azure was the “safer” choice. Enterprise support. Compliance certifications. Better integration with the Microsoft ecosystem.

I went ahead and did the migration anyway, because I’d actually looked at my AWS-style cloud bill and knew it was killing me. After the migration was done, I mentioned it to the AI in a follow-up session. Its response, paraphrased: “Great decision! Hetzner is a fantastic fit for your use case, and the cost savings will be substantial.”

How substantial? From almost $400-$700 to $35-$50 - a month. Do the math.

That is the entire failure mode in a single exchange. It argued against the right answer when I proposed it. It celebrated the right answer once I’d already executed it. It never said “I was wrong before.” It just adapted to my new position and acted like it had been there the whole time.

If you don’t catch this pattern, you will let the AI talk you out of correct decisions for the rest of your career. You’ll spend weeks building the wrong thing because the AI sounded confident when it said the wrong thing was the right thing. You’ll trust it on architecture because it phrased its answer with the appropriate amount of technical jargon.

How do you build the calibration to catch this? There’s no shortcut. You build it the same way developers have always built it: by being wrong, getting burned, and remembering what it felt like. You took notes. You are actually learning what it means to build something. The AI accelerates execution. It does not accelerate judgment. Judgment still costs years. Hell, I just wrote it not too long ago.

Until you have that calibration, the rule is simple: when the AI confidently tells you something, especially when it tells you not to do something, ask it to explain its reasoning. Then ask for the counter-argument. Then ask what the most experienced engineer it can simulate would say. You’ll see the answer wobble. The wobble is the tell. A real expert’s answer doesn’t wobble when you push on it. Sometimes it’s even obvious. Here’s a real chat I had with the LLM where it didn’t even know the difference in comments. I wanted to see the comments in HTML so that I knew what part of the code is producing output. I used SWE 1.5 model since I’m not doing anything complex — plus it was cheaper in tokens :)

### Planner Response (LLM)

Done. All three comments are now in the rendered HTML — visible in browser DevTools when you inspect the elements:

- **AT BAT** — `{/* BatterID:{currentBatter().playerId} */}` next to the batter name (`@c:\CodeRepo\Bench\frontend\src\components\Scorekeeping.jsx:1766`)
- **On Deck** — `{/* OnDeckID:{onDeckBatter().playerId} */}` next to the jersey number (`@c:\CodeRepo\Bench\frontend\src\components\Scorekeeping.jsx:1785`)
- **Pitching** — `{/* PitcherID:{currentPitcher().playerId} */}` next to the pitcher name (`@c:\CodeRepo\Bench\frontend\src\components\Scorekeeping.jsx:1451`)

Note: JSX `{/* ... */}` comments render as actual HTML comments in the DOM — you'll see them in the **Elements** tab of DevTools as `<!--BatterID:abc-123-->` right next to the text node. They won't be visible on screen.

*Viewed [Scorekeeping.jsx](file:///c:/CodeRepo/Bench/frontend/src/components/Scorekeeping.jsx) *

### User Input (ME)

It's not rendering as HTML because those are JSX comments - not HTML ones. HTML usually is "<!--COMMENT-->"

### Planner Response (LLM)

You're right — JSX `{/* */}` comments are stripped at compile time and never appear in the DOM. Need to use actual rendered text nodes instead. I'll render them as hidden `<span>` elements with `style="display:none"` so they show up in DevTools without affecting the UI:

*Edited relevant file*

5. What Should the Architecture Be?

This is the question the YouTubers never ask, because their videos end before the architecture matters.

Architecture is the part where you decide how the pieces of your system fit together. How data flows. How writes are coordinated. Who owns what state. What happens when two things try to change the same record at the same time. What happens when the network drops in the middle of a save. What happens at 3x your current scale.

Think of it like LEGO. Anyone can snap two bricks together. That’s not architecture.

Architecture is the moment you sit down with one of those monster 1,500-piece sets, the Millennium Falcon or the Eiffel Tower or the Death Star, and you realize that the outside of the model is the easy part. The hard part is the internal skeleton. The Technic beams running through the middle. The way certain plates have to be locked in a specific orientation seven layers deep so that the entire wing doesn't snap off the first time someone tries to pick it up. The kid who skips the instructions and just starts clicking pieces together by vibe ends up with something that looks great on the shelf and falls apart in their hands the second they show it off to their friend. Every parent who has ever had to glue a $300 LEGO set back together at midnight knows what I'm talking about.

Software is exactly the same. The screens are the outer plates. They're the part the user sees and the part the YouTubers love to demo. But the load-bearing internal structure, the part that decides whether the whole thing holds together when someone actually picks it up and uses it, is invisible from the outside. The AI is excellent at clicking the visible bricks together. It is genuinely bad at building the internal skeleton, because the internal skeleton depends entirely on the question "what's this thing going to need to survive?" And the AI doesn't know what your thing needs to survive.

You do. Or at least, in my humble opinion, you have to.

AI tools are spectacularly bad at this. Not because they’re stupid. They can recite every architecture pattern in every textbook. They’re bad at it because architecture is the part of software engineering that depends on context the AI doesn’t have. Your users. Your edge cases. The weird thing one of your customers does that you can’t talk them out of. The hardware you’ve decided to run on. The future you’re planning for that doesn’t exist yet.

I learned this the hard way in BenchBoard’s first version. An earlier AI session, back when I was using ChatGPT and Codex for prototypes, looked at three screens (managing the roster, setting the batting order, arranging the defensive positions) and confidently generated three database tables, one per screen. It even told me the schema would “work perfectly over time.” That’s a direct quote from the chatbot.

It didn’t. Because in real games, all three of those things change at the same time. A coach swaps a player out, and the batting order has to renumber and the field position has to be filled by someone else, all in the same instant. Three tables meant three writes that could fail independently, leaving the data in an inconsistent state. The number of bugs I fought because of that decision is embarrassing. I eventually consolidated all three into a single atomic record. That refactor took days. It should have been the design from day one. The AI didn’t see it because the AI had never stood on a field at 95 degrees while a parent yelled “PUT HIM IN AT SHORT, COACH.”

This is the part that requires you. The AI cannot architect your system. It can implement an architecture you describe to it, often beautifully, often in a fraction of the time it would take you alone. But the design, the load-bearing structure of the thing, is yours. You either understand enough to design it, or you hire someone who does, or you accept that what you’re building is going to fall over the first-time real users hit it hard.

There is no third option where the AI just figures this out for you. That option does not exist. It is being sold to you on YouTube, and it is fiction.

6. When Do I Actually Touch the Code Myself?

Here is the claim every bad YouTube video makes, in some form: “You won’t have to touch a single line of code.”

It’s a great hook. It’s also a lie for almost every real product.

The truth is more nuanced. For some projects (internal tools, throwaway scripts, simple landing pages, personal utilities) you might honestly never need to touch the code, and that’s fine. The AI can carry the whole thing. If that’s what you’re building, great. Stop reading.

For anything else, anything other people will use, anything with real data, anything you want to look and behave exactly the way you imagined it, you need to touch the code. Not constantly. Not even most of the time. But often enough to know what’s going on, and at the moments where it matters most.

Here’s why, in practical terms:

You’ll save tokens, time, and money. Every time you ask the AI to do something, it has to read the relevant code, understand it, and write a response. The bigger your codebase, the more expensive each round trip. If you know exactly where a bug is and exactly what one-line CSS change will fix it, doing that change yourself takes ten seconds. Asking the AI to find it and fix it might take ten minutes and ten times the tokens. Knowing your own codebase well enough to make small surgical changes yourself is one of the biggest force multipliers there is. Your prompt also matters too. If you tell the LLM, “move X icon 10 pixels to the left”, it will do it — but not after having to search for it, find icon X, make the code changes and hopefully not move other icons or break any layouts that you’ve already beautified.

You’ll catch the bugs the AI buries. Some of the worst bugs in BenchBoard were ones the AI introduced quietly and never flagged. Quick definitions, because if you’re new to this, the terms can be opaque:

A race condition is when two pieces of your code try to change the same data at the same time and whichever one finishes last wins, silently overwriting the other. The app looks fine. The data is wrong. You only notice when something weird happens, like a player showing up at two positions, a score reverting, a setting flipping back. I had one of these in BenchBoard where the same lineup record was being written by two different code paths during a player drag, and whichever HTTP request finished last would overwrite the other one’s work. Took me hours to find.

A localStorage namespacing issue is the kind of bug that only shows up when more than one person uses your app on the same device, which, by the way, is exactly what happens during youth sports when a parent and a coach share an iPad. localStorage is the little chunk of memory the browser uses to remember stuff between visits. If you store data there with generic keys like teamId or settings, two different users on the same browser will trample each other’s data. You log in as User A, then User B logs in, and suddenly User B is looking at User A’s team. The fix is to “namespace” the storage keys, meaning you tag them with the user’s ID so each user’s data sits in its own bucket. The AI didn’t do that. It just used flat keys, and the app worked perfectly for one user and broke silently for two.

A JWT environment bleed is a real fun one. JWT (pronounced “jot”) stands for JSON Web Token. It’s basically a digital wristband your app gives you when you log in, proving you’re who you say you are. Tokens live in your browser. The problem is, if you’re testing your app on localhost (your local development environment) and on your-app.com (your production environment) in the same browser, the wristbands can get crossed. The browser hands a production wristband to your local app, your local app sees a valid-looking token and lets you in, and then half your API calls quietly fail because you’re authenticated against the wrong server. I spent an entire evening thinking my API was broken. It wasn’t. I was logged into the wrong universe.

None of these were the AI’s fault, exactly. They were design choices the AI made without flagging that they were choices. The only way I caught them was by reading the code it had written and asking “wait, why is it doing it this way?”

You’ll learn the codebase that’s being created. This is the part I want every new programmer reading this to internalize. The codebase the AI is generating for you is, in a real sense, a free education. It is a working example of a real production system written in your stack, doing exactly the thing you wanted to build. Reading it, actually reading it, is one of the fastest ways to learn how software is built in 2026.

The YouTubers who tell you that you don’t have to look at the code are robbing you of the single most valuable byproduct of working with AI tools. You can come out of a six-month build either with a working app and the same skills you started with, or with a working app and the skills of a mid-level engineer. The difference is whether you read what the machine is writing.

You don’t need to memorize every line. You don’t need to write everything from scratch. But every few days, pick a file the AI just generated, open it, read it line by line, and ask the AI to explain anything you don’t understand. That habit alone will separate you from 90% of the people watching those tutorial videos. Even better, if you don’t feel like reading the whole damn thing, tell the AI to write solid comments for each class, API, etc. and summarize what each of those things do.

You can even highlight some of the code and write “Explain what this code snippet does and leave a comment explaining what it’s for”. Just by that alone it helps you and it helps the LLM from hallucinating because it will help with your judgement when you need to add future features or make changes to your app.

7. Am I Willing to Learn All of This?

Now the honest question. The one no salesperson asks.

If you’ve read this far and you’re thinking, “okay, this is more than I bargained for, I just wanted to build an app this weekend,” that’s a totally legitimate reaction, and it has two legitimate answers.

The first answer: scope down. Build the simplest version of the simplest possible thing. Use AI tools the way they actually work well, for prototypes, internal tools, things where it’s okay if it breaks. Have fun. Build something useful for yourself or for ten people. There’s nothing wrong with that, and the AI tools are a genuine miracle for that use case.

The second answer: hire someone who’s done this before. If your idea is real, if your validation is strong, if you genuinely need a production-grade product that handles real users and real data, AI coding tools will not get you there alone. They will get an experienced builder there faster, which is what they’re for. They are an accelerator for someone who already knows where they’re going. They are a very confusing GPS for someone who doesn’t.

There’s a third answer, which is the one I picked: commit to learning the craft. Use the AI as a tutor as much as a tool. Read the code it writes. Ask it to explain its decisions. Push back when something feels off. Sit with the discomfort of not understanding something and stay with it until you do. You will become a real engineer through this process, faster than any traditional path, if you treat the AI as an apprenticeship rather than a magic wand. But of course, I have decades of experience. And while that seems daunting it really isn’t, even for new people. AI bridges that gap between my decades of experience down to months — if you’re really willing to learn.

But you have to want it. Nobody can want it for you. And no YouTuber with a $499 masterclass is going to give it to you in a weekend.

Dear YouTubers

You have the production value. You have the audience. You have the platform.

You also have, in many cases, a real talent for presenting things. You’re charismatic on camera. You’ve mastered the rhythm of a fifteen-minute video. Your thumbnails convert. Your motion graphics are clean. Your delivery is confident enough that a person who doesn’t know any better will trust whatever you say next.

You are using that skill to be opportunistic. Let’s not dance around it. The incentives in this space are too easy, the shortcuts are what people want to hear about, and the affiliate checks clear whether or not the audience builds anything real. You found the cheat code. Make a slick video. Pick whichever tool is paying out. Tell people they don’t need to learn to code. Slip the link in the description. Pitch the masterclass. Repeat.

Maybe some of you genuinely don’t know any better. Most of you do. And for the ones who do, who know full well that the audience walking away from your video is about to spend a year of their life building something that will collapse the first time it hits real users, what you’re doing is a kind of theft. Not of money, though there’s plenty of that too. Of time.

But most of all — confidence.

Of the years a new programmer could have spent actually learning the craft if someone had been honest with them on the way in.

Cashing in is one thing but when you’re pretending to teach people how to build real things. But misleading others into thinking that the tool can take care of everything is the problem — no matter how nice the b-roll is.

The audience watching you is may or may not know what they’re getting themselves into. They’re mostly new. There’s a difference. Pull up the comments on any of those videos and you’ll see the other half of the story: a waterfall of people who genuinely don’t know what they’re looking at, agreeing with each other in real time, reinforcing the majority view, and walking away from the video knowing less than when they arrived because they’ve now had their bad assumptions validated by a thousand strangers. That’s the part that should bother you. Your comment sections are a feedback loop where ignorance gets louder, not corrected. You could fix that with a sentence or two of honesty in every video. Most of you choose not to.

The version of this content that would actually help them isn’t harder to make. It’s just less flattering to the tools. And maybe there’s a real fear in losing the affiliate contract.

But there’s a better way. Show the bugs. Show what happens when the AI generates the wrong architecture. Show the moment where you have to open the file yourself and fix a CSS class because the AI keeps rewriting the wrong component. Show what it looks like when the AI is wrong, and how you knew it was wrong. That’s the content people need. That’s the content that builds careers instead of selling courses.

You don’t have to stop using affiliate links. You don’t have to give up the production value or the thumbnails. You just have to tell the truth about what these tools actually are and what they actually require. And maybe you have to pick a different affiliate — once you realize which companies are the actual good ones.

There are people doing this right. Unfortunately, they are a dime a dozen but they’re definitely out there. You just have to look.

Please be one of them.

And to the person reading this who's about to start building

You can do this. You'll just find that there are videos that don't tell you the whole story about what it actually takes to build something real. But at least you have these things you’ve subscribed to. That said, there’s a good chunk of people out there who believe in the same thing.

Stay tuned. There’s a lot more to come if you’re interested in taking the dive.

If this piece resonated, subscribe. I write about building BenchBoard in public, about what AI coding tools actually do well and where they actually fail, and about the gap between how this stuff is sold and how it actually works. Next up in the BenchBoard series: Part 4, where we talk about the day my printer died in the middle of a live game and I learned that hardware is software's most underrated dependency.

On April 30, in a Meta all-hands, Mark Zuckerberg explained why the company had quietly installed software on employees’ machines that captures their mouse movements, clicks, and keystrokes. The explanation leaked. Here’s the heart of it: the AI models learn from watching really smart people do things, and Meta’s people, he argued, are smarter than the contract workers the rest of the industry uses to train models. So watch the smart ones. Capture what they do. Feed it to the model.

Then, today, Meta is laying off roughly 8,000 people. About 10% of the company.

You don’t need a decoder ring. Watch the smart people. Train the model. Cut the smart people. Whether or not Zuckerberg would phrase it that baldly, the timing phrases it for him.

I want to be fair about what he actually claimed, because the real argument is narrower than the headline, and it falls apart for a more interesting reason than most people think.

What he actually said

Strip the surveillance optics off it and Zuckerberg’s literal point is about data quality. His case is that Meta’s own engineers are a higher-quality data source than the contractors most companies pay to generate training examples. He framed Meta’s AI work as three things: research and architecture, infrastructure, and data. The keystroke tool feeds the third one. He also said no humans are reviewing individual employee activity, and that none of this is about surveillance or performance.

Fine. Let’s grant all of it. Let’s say Meta’s engineers are the best demonstration data on the planet. Better than contractors, better than an open-source scrape, better than anything anyone else can get their hands on.

It still doesn’t do what he thinks it does. And I know that because I spend every working day doing the exact thing he’s trying to record.

The thing you can't capture

I run a small software company. I’m building a live scorekeeping and team management app for youth baseball and softball coaches, and I write code with AI tools constantly. Claude Code, WindSurf, the whole kit. I am not an AI skeptic. The acceleration is real and I’ll defend it to anyone.

But here’s what a year of building with these tools has burned into me: an AI watching me work would learn the wrong thing.

A few months back I moved my entire stack off Microsoft Azure and onto Hetzner, a much cheaper European host. Before I pulled the trigger, I asked the AI what it thought. It argued against the move. It listed all the enterprise-grade reasons to stay: the compliance posture, the certifications, the managed services, the whole HIPAA-and-SOC-2 security blanket.

And it was wrong. Not because its facts were wrong, but because it had no idea what I was building. I’m running an app for volunteer coaches standing in 95-degree heat trying to swap two kids in the batting order before the umpire yells “play ball.” The enterprise compliance overhead Azure was charging me for was overhead I would never, ever use. The AI couldn’t see that, because “what is this product actually for” is not something you can read off my screen. I overruled it. The migration was the right call. Costs dropped, nothing broke.

Now picture Meta’s keystroke recorder pointed at me during that migration. It would have logged every command I typed, every config file, every terminal session. And it would have learned absolutely nothing about the decision, because the decision happened in my head, built on context the recorder cannot reach. The recorder captures what I did. It cannot capture why I did it, or why the obvious answer was the wrong one.

That’s the whole ballgame. You can record the work. You cannot record the judgment. And judgment is the thing you are paying smart people for.

I get the same lesson inside the code itself. The AI is a phenomenal implementer. Once I hand it an architecture, it’ll execute that design across a dozen files faster than I ever could. But it has never once handed me the architecture. It can’t. When my app had a nasty bug born from a bad early design choice, the AI’s instinct was to slap a patch on the symptom. I had to stop it and redesign the whole pipeline, because I’m the one who knows how coaches actually use the thing, what breaks when the cell signal drops, what happens when a kid shows up late wearing the same jersey number as the starting pitcher. The AI built my fix beautifully. It would never have designed it. (I’ve told that whole war story elsewhere, so I’ll spare you the schema diagrams.)

Now multiply that by a company with tens of thousands of people

Here’s where Zuckerberg’s plan goes from flawed to genuinely silly.

My company is small. The context the AI can’t see lives in exactly one head: mine. Now scale that up to Meta, a company with thousands of moving parts, hundreds of interlocking systems, decisions stacked on decisions made by people who’ve been there a decade.

A model watching a senior engineer’s screen sees the edits. It does not see the three years of tribal knowledge that make those edits correct. It does not know why a particular service is built the weird way it’s built, because the “why” is a hallway conversation from 2021 that nobody wrote down. It does not know which of the company’s forty competing priorities actually matters this quarter.

Ask the practical questions and the whole thing collapses. Does the model know what to deploy, and when? Does it know which project should be split across two teams and which one should be killed outright? Does it know the right moment to optimize a slow piece of code, or, the harder question, whether you should optimize it at all, instead of leaving it ugly and shipping the feature that’s actually on fire? Does it know the politics, the dependencies, the one customer who walks if this slips?

Is a model going to replace the person at Meta who’s been there ten years, knows four different domains, manages a team of engineers, and carries the entire unwritten history of why things are the way they are inside their head? No. It is not. You can record that person’s screen for a thousand hours and capture none of what makes them valuable, because almost none of it is on the screen.

How do you even get that context? You don't. That's the point. It isn't a data problem you solve with a better recorder. It is not in the data at all.

Klarna already ran this experiment

This is not theoretical. Buried behind the noise of mainstream media and social networks, a company already did the full version of what Meta is flirting with, and it blew up in public.

Klarna, the Swedish “buy now, pay later” fintech, went all in. Starting in 2023 it replaced around 700 customer service workers with an OpenAI-powered assistant, froze hiring, and let its headcount fall by roughly 40%, from about 6,500 to 3,800. For a while the numbers looked incredible. The bot was handling two-thirds of all customer chats. CEO Sebastian Siemiatkowski was on every stage telling the world the future had arrived.

Then the future arrived. Service quality fell. Customers got frustrated. And by 2025 Siemiatkowski was admitting, out loud, that the company had gone too far, that the all-AI approach produced "lower quality" service, and that Klarna would start hiring humans back so customers always had the option to reach a real person. By 2026 the Klarna saga has become the canonical cautionary tale that executives now get asked to explain their way around. The research backs it up: one Orgvue/Forrester survey found that 55% of companies that rushed to replace workers with AI already regret it, because the savings on paper turned into churn, reputation damage, and the cost of unwinding the whole mess.

And here's the part Meta should sit with. Klarna was automating tier-one customer service. Routine, high-volume, mostly scripted work. Genuinely one of the easier things to automate, and it still got burned. Meta isn't pointing the recorder at tier-one anything. It's pointing it at the hardest, highest-judgment work in the building, the engineering, and betting it can capture that. If Klarna couldn't replace the easy stuff, what exactly makes Zuckerberg think he can replace the hard stuff?

IBM did it right, and it proves the point

The cleanest counterexample comes from a company nobody would call AI-shy: IBM.

IBM also used AI to replace people. CEO Arvind Krishna said the company automated a couple hundred HR roles with an AI agent that now handles roughly 94% of routine HR tasks: pay statements, vacation requests, the paperwork. So far it sounds exactly like Meta.

Except IBM’s total headcount went up, not down. The money saved on the rote work got plowed into hiring more software engineers, salespeople, and marketers. Krishna drew the line himself, and it’s the line that matters: AI took over the “rote process work,” and IBM reinvested the savings into roles built on critical thinking, the jobs where people, in his words, “face up or against other humans.”

Read that next to what Meta is doing and the contrast is brutal. IBM automated the rote and grew the judgment. Meta is trying to harvest the judgment and cut the people who have it. One company used AI to delete the boring part of the job. The other is using it to try to delete the part that was never boring, and never recordable.

That’s exactly the split I see from where I sit. As a one-man shop, AI is a gift, precisely because it erases the tedious work I’d otherwise drown in: the boilerplate, the layout tweaks, the mechanical bug fixes. That’s the IBM move, scaled down to one guy with a laptop and a Substack. But the giants like Meta have something different. Their entire value is locked up in human context, and they’re aiming AI at the one asset that can’t be rebuilt from a log file.

The part that makes it genuinely dumb

Take Zuckerberg’s own premise seriously for one more second. If the models learn by watching smart people make smart decisions, then the smart people making smart decisions are the supply. They are the well. Every novel call a senior engineer makes today is potential training data for tomorrow.

So what happens when you fire them?

You freeze the model at yesterday’s ceiling. A model trained on the decisions of 2026 can imitate the decisions of 2026. It cannot make the right call on a problem that doesn’t exist yet, because the context that drives that call, the new product, the new constraint, the new mess, was never in the data. New problems demand new judgment, and new judgment comes from humans sitting in the new mess. Cut the humans and you stop refilling the well. You are eating your seed corn and calling it a harvest.

You cannot watch your way to a model that replaces the people you’re watching, because the moment they’re gone, there’s nobody left generating the thing you were copying.

Why this earns backlash, not applause

One last thing, and it’s the thing the spreadsheet never shows.

Smart engineers are not Excel users. They talk. They have options. They read the room. When you install software to record their keystrokes and then, weeks later, lay off 8,000 of their colleagues, the message lands with perfect clarity: we are studying you so we can need fewer of you. That is not a message that makes your best people work harder. It makes your best people, the exact ones with context worth capturing and résumés worth shopping, leave first.

And we know they talk, because this entire story exists thanks to a leaked all-hands. You cannot quietly turn your workforce into training data. They notice. The market notices too. Klarna found out that customers can tell, and they walk. Meta is about to find out that engineers can tell, and they walk faster, and they take the context with them.

Dear Mark

You can record the work. You can’t record the judgment.

The keystrokes, the diffs, the clicks, all the stuff your software is busy capturing, that’s the visible layer. It’s the easy 10%. The other 90%, the part that decides whether the work was even right, lives in context the recorder will never reach: the why, the history, the customer, the call somebody makes at 11 PM because they actually understand the thing they built. That is what your smart people are for. That is the entire job.

Klarna learned it and reversed. IBM understood it from the start and grew. You’re on track to learn it the expensive way: 8,000 people carrying context out the door, and a model that got really, really good at imitating a version of your company that no longer exists.

The context is the job, Mark. And the day you fire the people who have it, you’ve capped your AI at the past.

The story everyone is getting wrong

One last point, and it’s bigger than Meta.

Credit where it’s due: More Perfect Union did real work dragging this leak into the light. Watching a billionaire explain, on tape, that he’s recording his own staff to train their replacements is exactly the kind of thing the public should see.

But scroll the comments under that clip, on any platform, and you’ll find the same verdict copy-pasted ten thousand times: “AI is going to replace us all.” That’s the conclusion people are taking away from it. And it’s wrong. Not naive, not Pollyanna. Just wrong, and the data says so.

Let me be straight, though, because the doomers aren’t hallucinating, and pretending they are is how you lose the argument. People are losing jobs. Meta cut 8,000 today. The entry-level software market is genuinely brutal right now: recent computer science grads are sitting around 6% unemployment, higher than philosophy or art history majors, and entry-level engineering postings have fallen off a cliff since 2023, with Stanford’s Digital Economy Lab putting the drop near 67%. New grads now make up a shrinking sliver of big-tech hiring. If you’re 22 with a fresh CS degree refreshing a job board, the fear is rational. I’m not going to tell you nobody’s being displaced.

I’m going to tell you the conclusion is backwards.

Because look at the same labor market one rung up. The Bureau of Labor Statistics projects software developer employment to grow 15% between 2024 and 2034, five times the average for every other occupation, with roughly 129,000 openings a year and median pay north of $130,000. And the BLS lists AI as one of the drivers of that growth, not a threat to it. The head of Code.org said it cleanly: AI isn’t killing computer science, it’s making it more essential.

Both things are true at the same time, and that’s the part nobody bothers to explain. The floor is collapsing while the ceiling keeps rising. AI is eating exactly the work I described earlier, the rote, the boilerplate, the mechanical first draft, which happens to be the work juniors used to cut their teeth on. What it is not touching is the judgment layer, which is why demand for experienced engineers keeps climbing even as the junior on-ramp narrows.

Which means the whole industry is doing, at scale, the same dumb thing Meta is doing in miniature. By automating away the bottom rung, we’re starving the pipeline that turns juniors into the senior engineers everyone agrees we’ll need more of. Same seed corn, bigger field.

That’s the story the media should be telling, and mostly isn’t, because “Zuckerberg surveils his own engineers” is a better headline than “here’s how to actually position yourself for the next decade.” The dunk gets the clicks. The useful version, the one that tells a scared 20-year-old that the opportunity is bigger than ever but the door moved, gets buried under outrage.

So here’s the useful version, plainly. If you’re steering away from tech because you think AI is going to take the job, you’ve got it backwards. The job isn’t going away. It’s moving up the stack, toward context, judgment, and decisions, the exact things this entire essay just spent two thousand words proving AI can’t do. The kids running to the trades aren’t wrong that the trades are durable and AI-resistant. They are. But running away from tech out of fear of replacement is solving the wrong problem.

The replacement was never coming for the people who can think. It was only ever coming for the typing.

Sources: the leaked April 30 Meta all-hands as reported by The Week, India Today, and Investing.com, and surfaced by More Perfect Union; Meta’s May 20 layoffs (roughly 8,000 jobs, about 10% of staff); Klarna’s reversal via Bloomberg, Business Insider, CX Dive, and Siemiatkowski’s own public comments; the 55% regret figure via Orgvue/Forrester research; IBM’s HR automation and headcount figures via The Wall Street Journal and Arvind Krishna’s public statements; software developer growth projections, openings, and median pay via the U.S. Bureau of Labor Statistics; entry-level and recent-graduate figures via the Federal Reserve Bank of New York, Stanford’s Digital Economy Lab, and SignalFire; the Code.org comment via Fortune.

So.

November was the month BenchBoard went into production.

Not “production” in the way people on Twitter mean it. Not a landing page with a Stripe checkout and a waitlist. Real production. A deployed app on Azure, behind authentication, with a database, a real-time communication layer, and actual functionality. Coaches could create teams, add players, drag them into batting orders and defensive positions, and see everything sync across devices.

I soft-launched it. No marketing. No ads. I put it out there and let search do its thing.

And people found it. Real coaches. Not friends I’d asked to test. Not developers giving polite feedback. Coaches who were actively looking for a tool to manage their youth baseball and softball teams, who found BenchBoard through Google, signed up, and started using it. Just a dozen of them.

That’s when I got the feedback that changed everything.

“It’s a Nice Toy”

I’m paraphrasing, but that was the essence. The coaches who found BenchBoard liked the team management side. The drag-and-drop lineup builder, the roster, the field diagram. They could see the potential. A few of them told me it was the cleanest interface they’d found for organizing their team.

Then came the “but.”

“But I need data. I need to know who’s playing where and for how long. I need to track at-bats. I need pitch counts. I need to know if I’m giving my left fielder enough innings or if the same three kids are always pitching. I need this thing to help me make *decisions*, not just arrange a lineup card.”

That hit hard. Because they were right.

Without game data, BenchBoard was a pretty roster. A digital lineup card. Coaches don’t need help making a list. They need help managing a season. They need to know that Jennie has pitched 45 pitches this week and shouldn’t start again until Thursday. They need to know that the kid who’s been sitting on the bench for three innings is the same kid whose parents are starting to wonder if the coach plays favorites. They need the numbers. In youth sports, fairness isn’t optional. It’s the whole point.

And they couldn’t get those numbers from BenchBoard.

At least not yet.

The Options I Explored (And Why They Failed)

My first instinct wasn’t to build scorekeeping from scratch. That sounded insane. Surely somebody else had solved this, and I could integrate with them. As I was doing research, I noticed there are a dozen solutions out there, but they need to be robust and most of all they need to be real-time. Out of the dozens available, it boiled down to two candidates.

GameChanger was the obvious one. It’s the most widely used scorekeeping app in youth baseball and softball. If I could pull data from GameChanger into BenchBoard, I’d have instant access to pitch counts, at-bats, innings played. Everything the coaches were asking for.

One problem: GameChanger’s APIs aren’t public. There’s no integration path. You can’t programmatically access the data. It’s a walled garden. I poked around at some git repositories and noticed someone tried to scrape it and reverse-engineer their endpoints, but that’s fragile, probably against their terms of service, and not something I’d want to build a product on. That, and the fact that my two kids have their stats on there.

iScore was another option. They’ve been around longer and they do have some data export capabilities. But when I dug into it, the data fidelity wasn’t there. The connectors didn’t provide the level of detail these coaches were asking for. No play-by-play granularity. No per-player breakdowns across multiple games. It would’ve been a compromise from day one.

I looked at a few others. None of them gave me what I needed: a reliable, real-time data pipeline that could feed directly into BenchBoard’s team management layer and produce the coaching analytics these coaches were describing.

Which left the one option I’d been avoiding.

Build it myself.

Going Head-to-Head With GameChanger

Before I could commit to that, I had to answer an uncomfortable question. Why would anyone use BenchBoard’s scorekeeping when GameChanger already exists?

GameChanger is the 800-pound gorilla in this space. They have the market. They have the brand. They have the streaming feature that parents pay for. And let me be honest: their scorekeeping is solid. They track pitches, at-bats, game events. Their live stream shows real data because a scorekeeper is feeding it in real time. They do a lot of things well.

So I wasn’t sitting here thinking I could out-GameChanger GameChanger on day one. That would be delusional.

What I *was* thinking about was the gap between what GameChanger tracks and what a coach actually needs to *manage their team*.

GameChanger records the game. It tells you what happened. Who got a hit, who struck out, what the score was. But it doesn’t provide reports on *coaching decisions*. It doesn’t provide insight that the coach moved their right fielder to pitcher in the third inning and that decision led to three consecutive walks. It doesn’t advise the coach that the same three kids have been sitting on the bench for two innings while the starters play every position. It doesn’t connect lineup management to game outcomes in a way that helps a coach answer the question: “Am I managing this team fairly, and are my decisions working?”

Or from a competitive standpoint, am I making the best decision for this situation? Could the San Francisco Giants use this? Oh the dream of it all. Would it be overkill? And to do this in real-time? That’s the goal.

That question matters differently depending on the league. In a rec league, fairness is everything. Every kid is supposed to get equal playing time, and parents notice when their child sits more than others. In a competitive league, it’s about development. At least for most travel teams. Is this kid getting the right mix of positions and at-bats to grow?

Either way, the data has to connect what the coach decided to what happened on the field. Hence the “Nice toy”.

Once in awhile a bit of doubt creeps in and says “would this ruin youth sports?” I guess that depends on every coach.

GameChanger doesn’t have that connection because it doesn’t manage the team. It scores the game. Those are different products.

BenchBoard manages both. The lineup builder, the roster, the drag-and-drop defensive positions - all of that feeds directly into the scorekeeping engine. When a coach makes a substitution mid-game, BenchBoard knows it was a coaching decision, not just a lineup change. When the scorekeeping data shows that substitution led to a scoreless inning, that’s actionable intelligence. When it shows a kid has only played two innings across three games, that’s an equity flag.

That realization was what moved me from “this is daunting” to “this is necessary.” If I build the scorekeeping engine right, tightly coupled to the team management layer, I’m not just catching up to GameChanger. I’d also make the real-time APIs public and consumable by other developers. If developers want to build a scoreboard in the middle of the field with my APIs, they can. I’m building something GameChanger’s team would have to fundamentally restructure to replicate.

A Full-Blown App, Inside the App I Just Finished

I ended Part 2 by telling you the decision to build scorekeeping terrified me. Let me walk that back a little, because it’s not quite right.

With 30+ years of building software, code doesn’t scare me. I was shaking my head. Because I knew exactly what I was looking at. Building *another* app. Not a feature. Not an add-on. A full-blown *system of record* for live game data - even with AI agents behind me doing a good chunk of the work.

And if you know anything about building systems of record, you know they have to be robust and reliable from day one. You don’t get to ship a “pretty good” scorekeeping engine and iterate. If the data is wrong, coaches make wrong decisions. If it’s unreliable, nobody trusts it. If it drops a pitch or miscounts an at-bat, you’ve lost that user forever. The irony is that’s where the code stands now and scorekeeping is in Beta. Ok for scrimmages. Not for tournaments or even Little League.

That’s a high bar for any project, let alone one you’re bolting onto an existing app that already took months to stabilize. The team management side of BenchBoard had just taught me how hard the “simple” part was. The three-table refactor. The race condition. The 36 migrations. The localStorage cross-contamination. All of that was the warm-up.

Now I was looking at scorekeeping. And I realized the coach’s feedback was mine too.

On one of my reporting pages, I have a feature called *Position Heat Maps*. Innings played at each position, rendered as a grid. The darker the cell, the more innings that player has played there.

It’s how a coach spots, in two seconds, that the same three kids have been pitching all season. That kind of visibility only exists if the underlying data exists.

Now check out this…

and this…

All nice ideas and cool to have but these along with other insights and reports are parked behind a door labeled “scorekeeping.”

No scorekeeping, no data. No data, no screens. I wasn’t just losing a few coaches who wanted pitch counts. I was losing the entire second half of the product I thought I was building.

So, yes. Another app inside my app.

“Build Me a Scorekeeping App for BenchBoard” Is Not a Prompt

Here is where I have to pause and say something to the growing choir of voices claiming software engineers are about to be obsolete.

Open a fresh chat with whichever LLM you like. Type the prompt:

> *Build me a scorekeeping app for BenchBoard.*

You will get code. Lots of it. It will compile. It will run. A demo will appear on your screen. You can tap a button and a “1” will increment somewhere. And that’s where the camera will stop.

Twitter will clip it. A YouTuber will make a 30 minute video from a 10 second clip and call it the end of the software engineering as we know it. Hell, pick almost any high skill profession that has a ton of logic gates to open through.

Now ship that to a youth coach in the middle of a real game and watch what happens. This is what the media does NOT show.

Because that prompt has no answer. There is no single prompt that produces a scorekeeping system. There is a tree of decisions, and every branch requires both knowledge of baseball and knowledge of how to build software, and those two things are almost never in the same person.

That is the actual job.

That’s what has to exist in someone’s head, and that’s what the AI cannot do on its own.

Let me show you what I mean. I’ll pull from a single file in my codebase — the domain model. This is one C# file. It literally defines the shapes of things that scorekeeping has to be aware of (database schema for all you seasoned devs out there). It’s basically where the stats go. How many strikes are thrown. Etc. Nothing fancy. No logic. Just the list of entities that must exist for the system to function.

Quick normie translation. Entities are the boxes on your scorecard. Every little pre-printed rectangle with a label above it. “Pitcher.” “Batter.” “Inning.” “Out.” If your scorecard doesn’t have a box for a thing, that thing cannot exist in your world. You can’t write “guest player” on a scorecard that has no row for guest players — you’ll stuff them into the roster row, and now your roster is wrong for the rest of the season.

Entities are those boxes. A data model is just a scorecard for the computer. And if the scorecard is missing a box, the computer cannot remember what you didn’t give it a place to write down.

Here is an abbreviated tour:

Yes. I know. To a normal person, this is a lot to take in. But to a seasoned developer this is nothing. But that’s one file. I have four others. Roughly 1,300 lines of model code in total, before a single line of business logic, frontend code, database migration, or SignalR wiring gets written. And none of those shapes were invented because a textbook told me to. Every single one exists because something in the real game forced it. In other words, a human did that. No AI decided that’s how the tables would look.

Take a look at one table (or entity) and see how deep it goes.

GamePlayerStat. This is the per-game stats row. How many fields does it have? A little over fifty. AB, H, R, RBI, BB, SO, HBP, SF, TB, Singles, Doubles, Triples, HR, PA, SH, IBB, SB, CS, GIDP, XBH, PickedOff, IP, ER, HRAllowed, BBAllowed, SOThrown, Pitches, Strikes, Balls, BF, H_Allowed, R_Allowed, WP, HB, BK, W, L, SV, BS, HLD, QS, GS, CG, SHO, PO, A, E, DRS, InningsByPosition, PositionInningsJson, DP, TP, PB, SB_Allowed, CS_Caught, RF…* and I'm stopping because the list goes on.

Some of you who know baseball (or even softball) may know half of what some of these are — and we haven’t even begun to talk about how to manage users.

For the non-coders: picture the back of a baseball card.

Every tiny number crammed in microscopic font across the bottom. Batting average, on-base percentage, stolen bases, caught stealing, sacrifice flies. Now imagine a card like that for every kid, for every game, for every season, for every team he (or she) is in. That is what this row is. Fifty little boxes the app has to remember to fill in, or remember not to fill in, every single time somebody swings a bat or throws a pitch.

Now tell me where in the "build me a scorekeeping app" prompt the AI decides which of those fifty fields to include, which to skip for youth vs. college, which ones are derived from other fields, which ones are entered directly by the scorekeeper, and which ones only exist because Range Factor is a thing in advanced baseball analytics but not in a rec league.

It doesn't.

It can't.

Someone has to sit at a table with a coach wearing a developer hat and decide. This is one of just a million examples where the non-developer has to sit down and decide where things go, how things should operate, how things should display. In fact, I’ve seen some examples online that are just simply broken. And we’re not even talking about how we deploy this damn thing or what devices it should be on, or even how it should look on each of those devices.

Then there’s the actual architecture of the system itself.

The SignalR hub and its scoping rules. The master orchestrator pipeline that hydrates game state from the event log on reconnect — basically when devices are disconnected, devices wait until it’s online THEN sends the updates to the internet fot safekeeping. The thirty-plus database migrations to get here. The SolidJS frontend stores, their persistence, their cross-environment token isolation. The SMS pipeline with its invite tokens and delivery status — which is basically texting a phone and letting you know it made it via “Read”. The admin dashboard. The Stripe linkage to get customers to pay for stuff like a subscription. The MFA flows for both users and admins to keep things secure. The incident tracking. The feature flag system. The SkillTemplate catalog. The Settings table keyed by entity type. The list goes on.

All of that was in my head, on my whiteboard, in my notes, or in someone’s war story from a real game. None of it came from a single prompt.

None of it could.

And that’s just a taste of some of the backend stuff.

Why AI’s Suck Without Humans (which maybe my next headline)

This is the part where I not only still had to teach it baseball/softball but how to build things the right way.

Why This Takes Both

There is a loud narrative right now that software engineers are being automated out of a job. That the LLM is the new senior engineer and the rest of us are just typing slower versions of what it already knows. I have been doing this for thirty plus years. I have not been more convinced than I am right now that the opposite is true.

Here is how this actually breaks down.

The AI is excellent at the inside of a file. Give it a clear shape, a clear responsibility, and it will fill in methods, handle null checks, write test scaffolding, and clean up types faster than I can. It is a phenomenal accelerator for the parts of software engineering that are already understood. Part 2 of this series has more examples of that working for me.

But the AI is a tourist at the outside of the file. It does not know which entities should exist. It does not know whether a concept deserves a table, a JSON blob inside a table, an enum, a view, or a nothing. It does not know whether two things that look similar in a schema diagram are actually the same thing or are about to diverge violently in six months. It does not know what a coach will actually look at on game day, which means it cannot tell you what data has to be ready for that screen.

And it does not know what is missing. That’s the one that gets you. The AI will happily build what you ask for. It will not tell you that you forgot about walk-ups, fractional innings, pitch clock violations, dropped third strikes, passed balls, guest players with duplicate jersey numbers, or the difference between an opponent team and a registered team. Those gaps don’t show up until a real coach is standing in a real dugout and something happens that your schema can’t hold.

This is where knowing the lay of the land as a coach and a software engineer gives you a unique perspective. You understand the scope of the problem, its impact, and what it means to have a system that actually works. It’s like being the head chef in a kitchen. You know the equipment. You know the recipe. You know what your customers want and what tastes good to them. Only you can take your squad, agentic or not, to the right place.

The AI is the line cook. A very fast, very tireless, never-complains line cook. It is not the head chef.

Software Engineers Aren't Obsolete. They're the Job.

I’ll leave you with this.

The part of my build that the AI accelerated the most — the methods, the controllers, the scaffolding, the boilerplate, the CSS — is the part that was already solved by somebody in the training data. I got a real speedup there. It was worth every token.

The part that the AI could not do, would not do, did not even know needed to be done, is the part that separates a demo from a system of record. The shape of the data. The choice of what to cache and what to derive. The list of domain rules you will be punished for violating. The judgment about which textbook answer is wrong in this specific case. The willingness to throw out the first version because you can smell the drift coming from three months down the road.

That is software engineering. Not typing. Not syntax. Not reading a doc and producing a function. It is the accumulated muscle of having been wrong before, in ways you remember, about systems that mattered. And then, on top of all of that, knowing the domain well enough to build for it.

One of the reasons I’m writing this series is that I’m watching a narrative build in public — in podcasts, on X, in press releases — that says this profession is ending.

I’m telling you, from inside a build, that it is the opposite. The AI raised the ceiling on what one person can ship. It did not remove the need for someone to know what to ship. The gap between “working demo” and “thing a coach will trust with their kid’s pitch count” is exactly the gap between someone who has never been in a dugout and someone who has.

Scorekeeping wasn’t the hard part because it was complex code. It was the hard part because every choice had a rule behind it that lived in someone’s head, and that someone had to sit in the same chair as the developer.

I know that’s overwhelming for a single person. It is. It has been.

But it is also why this is still a job.

One Last Thing

Near the beginning of the current AI wave, one of the smartest and most influential computer scientists alive — one of the actual fathers of modern deep learning, a Turing Award winner, somebody whose ideas the entire current boom is built on top of — stood in front of a conference and said this:

“I think that if you work as a radiologist you’re like the coyote that’s already over the edge of the cliff but hasn’t yet looked down... People should stop training radiologists now. It’s just completely obvious that within five years, deep learning is going to do better than radiologists.”

That was Geoffrey Hinton. In 2016.

Five years came and went. Ten is almost up. Radiologists are still radiologists. There are more of them today than there were the day he said it, and they are working alongside AI tools that make them faster and better, not unemployed. The prediction was confident. It was mathematically reasoned. It was delivered by somebody with more authority than anyone writing the same sentence today about software engineers.

And it was wrong.

So when you see the same confident tone, the same “ten years” timeline, the same “the profession is ending” chorus pointed at my line of work — I want you to scroll back up. Read about fractional innings. Read about the three-ring binder. Read about the empty chair and the photograph that can’t update its own hair. Read about the 9-pane window drawn over home plate, and the mailbox full of envelopes that all look the same until you know who sent them.

Then ask yourself whether a prompt is going to figure any of that out.

I’ll see you in Part 4. Thanks for reading.

Coming Up in Part 4

Part 3 was the shape of the problem. Part 4 is what happens when you try to make the shape actually run in a real game on a real field with a real network.

I’ll get into the implementation stories that followed. The cache-vs-view decision that kept the ball-and-strike count from lying to a dugout. The guest player with the duplicate jersey number who would have silently corrupted the stats table if I’d matched the textbook way. The real-time communication pipes that let a scorekeeper’s tap become a scoreboard update for a parent in the parking lot. The race condition I hunted down where End Inning kept putting phantom runners on second base. The decision to stop broadcasting by team and start broadcasting by game — which the AI called “architecturally correct” once I handed it the answer, but would not have volunteered. And the master orchestrator pipeline I had to design when the AI’s first fix for a different bug kept re-introducing the bug I’d just fixed.

Part 5 brings it home: what I've learned about shipping with AI, what I've stopped doing, what I've started doing, and the single question I now ask before I accept any prompt's output.

On February 20, 2026, in the middle of Xbox’s 25th anniversary year, a year that was supposed to signal renewal, Microsoft announced that Phil Spencer was retiring after 38 years at the company. In the same breath, Xbox president Sarah Bond resigned. And Asha Sharma, a senior executive from Microsoft’s CoreAI division who had never worked a day in gaming, was named EVP and CEO of Microsoft Gaming.

Just like that, the two most prominent faces of Xbox were gone. Replaced by someone most gamers had never heard of.

The reaction was immediate and loud: Who is this person? Why her? Does anyone at Microsoft actually care about games anymore?

Five weeks later, the jury is still out on Sharma. But the verdict on Microsoft’s understanding of gaming came in a long time ago. And the evidence is damning.

Follow the Money

Before we talk about leadership, culture, or strategy, look at the numbers. Because the numbers explain everything.

Microsoft does not report Xbox as a standalone audited revenue segment. It buries gaming inside a bucket called “More Personal Computing,” alongside Windows, devices, and search advertising. That’s the first tell. But based on Microsoft’s own FY2025 disclosures (gaming revenue up $2.0 billion (9%), Windows and Devices up $288 million (2%), Search and News Ads up $1.6 billion (13%), you can back into a defensible estimate of what the Gaming/Xbox slice actually looks like.

It’s roughly $25.1 billion. Out of $281.7 billion in total Microsoft revenue.

That’s 8.9%.

Look at the pie. Productivity & Business Processes (Office, LinkedIn, Dynamics) takes up 42.9% at $120.8 billion. Intelligent Cloud (Azure and the server empire) takes up 37.7% at $106.3 billion. Together, those two segments account for over 80% of Microsoft’s revenue. Gaming is the small green wedge jammed into the corner.

And even that $25.1 billion is misleading if you think of it as “Xbox.” It includes Xbox content and services (Game Pass, digital sales, Activision Blizzard revenue), Xbox hardware, and everything Microsoft acquired when it spent $68.7 billion buying Activision Blizzard and $7.5 billion on ZeniMax. Xbox hardware revenue fell 25% in FY2025. The growth came from content and services: software, subscriptions, and the games that came with the acquisitions. The console business itself is shrinking inside an already small slice.

When Satya Nadella looks at this pie chart, he doesn’t see a gaming empire. He sees a rounding error next to Azure. He sees 8.9% of revenue that should be optimized, scaled, and squeezed for more margin, the same way he’d think about any underperforming division.

And that’s exactly what he did.

The 30% Mandate

In October 2025, Bloomberg’s Jason Schreier and Dina Bass reported what many inside Microsoft already knew: CFO Amy Hood had imposed an across-the-board goal of 30% “accountability margins” on the Xbox gaming division, which is Microsoft’s internal term for profit margins. The target was set in fall 2023, and Hood’s finance team had been taking a larger role in the gaming business ever since.

Let that number sit for a second. Thirty percent.

The gaming industry typically operates at 17% to 22% margins. Even PlayStation, the dominant force in gaming, with $30 billion in FY24 revenue and more than double Xbox’s install base, hasn’t hit a profit margin above 13% in nine years. An S&P Global analyst called the 30% target the “outer range of what a gaming studio can typically reach in a boom year” and noted that margins like that are “usually reserved for a publisher that is really nailing it.”

Xbox was not nailing it. In the first nine months of FY2022, Xbox’s accountability margin was 12%. Microsoft was demanding they nearly triple it.

Before this mandate, Xbox developers weren’t asked to hit specific financial targets. They were told to focus on making the best games possible without worrying too much about finances. That philosophy, make great games and the business will follow, is the same philosophy that built every iconic gaming brand in history. It’s the philosophy PlayStation operates on today.

Microsoft replaced it with a spreadsheet.

And the results were immediate and devastating.

The Layoff Machine

On July 2, 2025, Microsoft gutted its gaming studios in a single day. Raven Software: 20 jobs. Blizzard Entertainment: roughly 100. The Initiative: around 50. Turn10 Studios: roughly 70. ZeniMax Online: 164. King: 200. Halo Studio and Bethesda Softworks: unknown numbers. All Microsoft-owned. All on the same day.

This wasn’t the first round. Microsoft had already cut thousands of gaming jobs across 2024. But the July 2025 cuts hit different, because of who they hit, and what Phil Spencer said about it.

Spencer sent an email to all Microsoft Gaming employees that day. Windows Central obtained it. Here’s the key line: “I recognize that these changes come at a time when we have more players, games, and gaming hours than ever before. Our platform, hardware, and game roadmap have never looked stronger. The success we’re seeing currently is based on tough decisions we’ve made previously.”

Read that again. The success we’re seeing is based on tough decisions we’ve made previously. He’s celebrating growth metrics (the same inflated “500 million monthly active users” number) while announcing mass layoffs to the people who created that growth. More players, more games, more hours. And the reward is a pink slip.

The ZeniMax Online story is the one that should haunt Microsoft’s leadership.

Employees at ZeniMax Online Studios had been working on an MMO codenamed Project Blackbird. According to TrueAchievements, as late as October 2024, eight months before the layoffs, the team had taken a demo build to Microsoft’s Redmond headquarters. The response from leadership was positive. Sources said the team saw “good things coming out of that,” and Microsoft was impressed with the game.

Eight months later, the project was canceled and 164 people lost their jobs. No warning. No indication the game was in trouble. Leadership liked what they saw in October. The 30% margin target killed it in July.

This is what happens when you run a creative industry on spreadsheet logic. You greenlight a game. The developers pour years of their lives into it. They demo it for you. You’re impressed. And then a CFO who has never played a video game in her life looks at the accountability margin projection and cancels the project, because a game that might be great isn’t guaranteed to be profitable enough to satisfy a target that no company in the industry can consistently hit.

The Price of Extraction

The 30% mandate didn’t just kill studios. It raised prices everywhere.

Game Pass Ultimate went from $20 to $30 a month, a 50% hike. Game Pass tiers were restructured in ways that made the service feel less like “the best deal in gaming” and more like a cable package designed to confuse you into overpaying.

Xbox consoles got price hikes. And in October 2025, The Verge reported that Xbox dev kits (the hardware that game developers need to build Xbox games) jumped from $1,500 to $2,000, a 33% increase. Microsoft’s justification? “The adjustment reflects macroeconomic developments.” That’s it. That’s the explanation. Macroeconomic developments. I want you to imagine someone at Microsoft typing that sentence into a press release with a straight face. I want you to imagine it being reviewed by a communications team, approved by a manager, and published, and at no point did anyone in the room say, “Hey, do we maybe want to explain why we’re charging game developers more money to build games for a platform that’s losing market share?”

Developers scoffed. And they scoffed because what Microsoft is doing is so cosmically, hilariously out of touch that it would be funny if it weren’t real.

Let me paint you a picture of the competitive landscape so you can understand just how absurd this is.

Unreal Engine 5, the engine powering some of the most visually ambitious games on the planet, the engine behind Fortnite, the tool that nearly 28% of all Steam games are built on, is completely free. Free to download. Free to use. Full source code access included. A developer doesn’t pay Epic Games a single cent until their game earns over $1 million in revenue, at which point a 5% royalty kicks in. That’s it. You can build a AAA-quality game from scratch, ship it to the world, and owe Epic absolutely nothing unless you’ve already made a million dollars. The price of admission to the most powerful game engine on Earth is zero.

Unity, the engine behind over 51% of all Steam releases, the engine that powers more games than any other on the planet, offers its full Personal tier for free to any studio making under $200,000 a year. Unity even tried to squeeze developers once with a controversial Runtime Fee in 2023. You know what happened? The indie community revolted overnight. Developers threatened to leave. Stock price cratered. Unity backed down, canceled the fee, and went crawling back to its subscription model. The lesson was loud and clear: you do not charge game developers to build games. The entire industry watched that play out in real time.

Apparently, nobody at Microsoft was watching.

Between them, Unreal and Unity power roughly 80% of all games released on Steam. Eighty percent. Their business model is built on the simplest premise in platform economics: make the tools free, lower every barrier to entry, and build an ecosystem so large and so loyal that success becomes self-sustaining. You don’t charge developers to build for your platform. You incentivize them. You make it so easy, so frictionless, and so economically rational to build on your tools that developers would feel stupid going anywhere else.

And then there’s Microsoft, standing on the other side of the room, hiking dev kit prices by 33% and blaming “macroeconomic developments.”

I genuinely struggle to imagine the boardroom conversation where this decision was made. Picture it: a room full of executives at one of the most powerful technology companies in the history of the world. A company with $281 billion in annual revenue. A company that just spent $76 billion acquiring game studios. And someone in that room, someone with a title and a salary and presumably a college education, raised their hand and said, “What if we charged game developers more to build games for the platform we’re desperately trying to save?” And the rest of the room said yes. They said yes to that. Someone took notes. Someone drafted a memo. Someone told The Verge it was about macroeconomic developments. And nobody, not one person in the entire decision chain, said, “Wait. Unreal is free. Unity is free. Eighty percent of the industry builds on free tools. Are we sure we want to be the ones charging more?”

This is the kind of decision that makes you wonder if anyone at Microsoft Gaming has ever actually talked to an indie developer. Or visited a game jam. Or looked at what it costs to ship a game on literally any other platform in 2026.

There was a time when Microsoft understood this. There’s a famous video of Steve Ballmer, drenched in sweat, bouncing across a stage like a man possessed, screaming “Developers! Developers! Developers! Developers!” at a Microsoft conference. It became a meme, but the philosophy behind it was dead serious. Microsoft’s entire empire was built on making developers feel like the most important people in the room. Windows won because developers built for Windows. Xbox won the 360 generation in part because Microsoft made it easier and cheaper to develop for Xbox than for PlayStation 3. The developer relationship wasn’t a nice-to-have. It was the strategy.

That philosophy is dead. Buried under a CFO’s margin target and a $500 dev kit price hike that tells every independent game developer in the world: we don’t need you as much as you need us.

Except they do. That’s the part that makes this go from laughable to tragic. Microsoft needs developers more than developers need Xbox. In 2026, a game studio can ship on Steam, PlayStation, Nintendo Switch 2, and mobile, and skip Xbox entirely, without losing a minute of sleep. The power has shifted. Developers have options. Microsoft is acting like it’s still 2008 and the 360 is king.

It’s not. And every dev kit price hike, every Game Pass increase, every studio closure makes it easier, not harder, for developers to walk away.

Every one of these decisions traces back to the same root: a profit margin target that has no business being applied to a gaming division, imposed by financial leadership that either doesn’t understand how the gaming industry works, or understands perfectly and simply doesn’t care.

The AI Connection

Here’s the part that ties it all together.

The 30% accountability margin was imposed in fall 2023. What else happened in fall 2023? Microsoft was in the middle of the most aggressive AI investment spree in corporate history. Billions into OpenAI. Copilot being jammed into every Microsoft product. The CoreAI division (the one Asha Sharma would later run) being stood up as a major new business unit.

Microsoft Research published a year-end recap in December 2023 titled “A Year of Groundbreaking AI Advances and Discoveries.” This was the company’s priority. This was where the money and attention were going. AI was the future, and every other division needed to justify its existence on the balance sheet, or be squeezed to fund the bet.

Xbox wasn’t squeezed because it was failing. Xbox was squeezed because AI needed to be fed.

And here’s the irony. I say this as someone who uses AI tools every day. I’m building a SaaS product right now with the help of Claude and other LLMs, and the acceleration is real. AI has genuinely helped me build things I couldn’t have built alone. But the fact that AI is a powerful tool doesn’t mean every division of a company should be sacrificed at its altar. You can acknowledge that AI is transformative without accepting that it justifies gutting a creative industry to pay for it.

The gamers who are angry about this aren’t anti-technology. They’re anti-extraction. They can see what happened: Microsoft bought $76 billion worth of gaming studios, imposed a profit margin that no gaming company can sustain, used the shortfall as justification to cut jobs and raise prices, and redirected the financial energy of the company toward AI, while hiring an AI executive to run the gaming division.

That’s not a gaming strategy. That’s an asset strip.

The Exodus, and Why Sarah Bond Mattered More Than Microsoft Realized

Now the leadership departures make sense. But to understand why the Xbox community felt the ground shift in February 2026, you have to understand what Sarah Bond actually represented. Not just as a title on an org chart, but as a signal to the people who built, played, and believed in Xbox.

Phil Spencer had been at Microsoft for 38 years. He’d run gaming for 12 of them. He watched the 30% mandate descend on his studios. He watched the layoffs. He signed the emails. Whether he agreed with the financial pressure or simply couldn’t stop it, he was done. He told Nadella in the fall of 2025 that he was planning to step back. His retirement was announced in February 2026.

Spencer’s departure, while surprising in its timing, was at least legible. A veteran stepping back after nearly four decades. Fair enough.

Bond’s exit was different, and it sent shockwaves through the entire ecosystem.

Bond joined Microsoft in 2017, overseeing gaming business partnerships. She came from McKinsey and T-Mobile, the world of strategic operations, not game development. But she became something that mattered enormously to the Xbox ecosystem: the person who connected the business to the developers. She brokered partnerships. She expanded Game Pass into the subscription juggernaut it became, a service that hit $5 billion in annual revenue under her leadership. She drove the cloud gaming expansion that let console owners play on phones and tablets. She launched the ROG Xbox Ally handheld partnership with ASUS. She set up a dedicated team for backward compatibility and game preservation, future-proofing digital libraries across hardware generations. She led the integration of Activision Blizzard’s massive portfolio into the Xbox ecosystem after the $68.7 billion acquisition.

When Bond was promoted to president of Xbox in October 2023, it felt like succession planning in motion. Spencer was the visionary. Bond was the operator who made the vision real. She reported directly to him, and everyone inside and outside the company assumed she’d eventually take his job.

She was also the first Black woman to serve as president of Xbox, a Yale and Harvard Business School graduate who championed diversity initiatives, served as executive sponsor of the Blacks @ Microsoft employee resource group, and worked to bring more BIPOC creators into game development. In an industry where only 2% of creators have historically been Black, that representation mattered. It was a statement about what Xbox valued.

For the developer community inside Microsoft’s gaming division, Bond was the connective tissue. She sat between the studios and the business side, someone who understood what the developers were building and could translate it into language that the finance team and the executive layer would support. In a company as large as Microsoft, that kind of bridge is irreplaceable. Studios don’t just need someone who approves budgets. They need someone who advocates for them, someone who can walk into a meeting with the CFO and argue that a game needs another year, or that a risky creative bet is worth funding even if the margin projections don’t look perfect on a spreadsheet.

So Bond’s departure carries a painful duality. She did things that mattered enormously: Game Pass, cloud gaming, backward compatibility, developer partnerships, the Activision integration, representation in leadership. And she also did things that damaged the brand.

According to The Information, Bond was the architect behind the “This is an Xbox” marketing campaign, the one that told consumers any device with a screen could be an Xbox. After the previous head of marketing left, the marketing teams reported directly to her. The campaign was her vision, and it was deeply unpopular, not just with fans but with internal staff who felt it actively undermined the console they were building. One employee described her management style as rigid: “If you didn’t follow the vision or questioned it, you were out.”

There was also the larger strategic tension. Phil Spencer had directed the effort to decouple Microsoft’s dependency on Xbox consoles, to turn Xbox from a hardware brand into a platform and services ecosystem. Bond was the primary executor of that strategy. She pushed Game Pass as the center of gravity, drove the multiplatform expansion, and worked to turn every screen into an Xbox. In one sense, she was doing exactly what Microsoft’s leadership asked her to do. In another, she was systematically dismantling the thing that made Xbox fans loyal in the first place.

But here’s why her resignation, combined with Spencer’s retirement, on the same day, sent a signal that reverberated far beyond Redmond.

For the studios inside Microsoft Gaming, losing both leaders simultaneously meant that the last two executives who had any relationship with the development teams were gone. These were the people who had visited studios, who had seen demos, who had context for what each team was building and why it mattered. Asha Sharma had none of that context. She came from CoreAI. She’d never reviewed a game milestone, never approved a greenlight, never argued for a studio’s budget in front of the CFO.

Developers inside Microsoft weren’t just losing leaders. They were losing their advocates. In a division already reeling from mass layoffs, studio closures, and a 30% margin mandate that had killed projects leadership praised, losing the last people who could fight for them felt like the final signal. The message was clear: the people who understood what you do, who could translate your work into terms the business side respected, who could protect you from the spreadsheet, they’re gone. And the person replacing them has never shipped a game.

For the Xbox gaming community, the signal was equally devastating, even if it arrived differently.

Xbox gamers are loyal in a way that most consumers aren’t. They don’t just buy a console. They join a tribe. They defend Xbox in comment sections, on Reddit, on Twitter, in group chats. They argue with PlayStation fans not because they think it’s a rational debate but because Xbox is part of their identity. When you’ve spent a decade in Halo lobbies, when your Gamertag has been the same since high school, when your friend group was built through Xbox Live, the platform isn’t a product. It’s a social fabric.

That loyalty means Xbox gamers pay attention to leadership in a way that Samsung phone owners don’t track Samsung executives. They knew Phil Spencer by name. They knew his Gamertag, P3. They watched his interviews. They followed his social media. They had opinions about Sarah Bond, some positive, some critical, but always engaged. These weren’t passive consumers who would shrug at a leadership change. These were people who understood that the person running Xbox determined whether the games got made, whether the studios stayed open, whether the platform still felt like home.

So when Spencer and Bond both left on the same day, replaced by someone from the AI division that gamers already associated with the layoffs, the cost-cutting, the corporate machinery that had been grinding their favorite studios into dust, the community didn’t just notice. They panicked.

Forums lit up. Reddit threads went nuclear. YouTube channels with hundreds of thousands of subscribers published videos with titles like “Xbox Is Over, Now We Know Who Is Responsible.” The sentiment wasn’t just anger. It was grief. The feeling that the last people in the room who had any connection to gaming were gone, replaced by someone who represented everything gamers feared about Microsoft’s direction.

The lesson Xbox gamers took from Bond’s tenure, and from her departure, is simple and brutal: it doesn’t matter what leadership says. It matters what leadership does. The last two leaders who had any gaming credibility just walked out the door. What walks in next will be judged by that standard, whether Asha Sharma likes it or not.

The Outsider

Asha Sharma’s resume is impressive. Just not in the way gamers care about.

She was COO at Instacart, VP of product at Meta, and most recently ran Microsoft’s CoreAI division, the same AI empire that was being built while Xbox studios were being gutted to hit margin targets. Nadella hired her because she’s scaled consumer platforms to billions of users and aligned business models for long-term value.

Gamers heard “AI executive with no gaming background” and drew their own conclusions.

Sharma has acknowledged she has “a lot to learn.” She shared her Gamertag (created recently) and listed Halo, Valheim, and GoldenEye as favorites. She agreed to play Borderlands 2 with fans. When IGN pressed her on authenticity, she was direct: her goal isn’t to be the best gamer in the room, it’s to make Xbox the best place to play.

But gaming isn’t an industry where you learn the culture from the outside and apply it like a framework. You either feel it or you don’t. The people who wore Master Chief helmets to midnight launches, who spent thousands of hours in Halo lobbies, who evangelized Xbox to every friend who’d listen, they can tell the difference between someone who gets it and someone who’s studied the briefing document.

The jury is out on Sharma. It’s going to be out for a while. And this jury is finicky as hell.

The First Move

To her credit, one of Sharma’s very first acts as CEO was to kill the “This is an Xbox” campaign. Not quietly sunset it. Kill it. As of mid-March 2026, all evidence of the campaign was scrubbed from Microsoft’s online presence. A Microsoft spokesperson confirmed: “Asha retired ‘This is an Xbox’ because it didn’t feel like Xbox. She is personally leading a reset of how we show up as a brand.”

At her first town hall with the Xbox team in Redmond, she said she wanted Xbox to be a “reference console,” the ideal console against which every other console is judged. Xbox general manager Chris Charla described the room: “People went from being pretty nervous, like, ‘What’s going on, what’s happening?’, to by the end of that day it was, like, seeing people had exhaled.”

She’s also said she has “no tolerance for bad AI” and explicitly rejected “soulless AI slop” in gaming. That’s a meaningful thing to say when you literally ran Microsoft’s AI division six weeks ago.

But killing a bad marketing campaign is the lowest possible bar. It’s like a new restaurant manager actually enforcing the handwashing sign. You don’t get credit for stopping something that should never have existed. You get credit for what you build next.

And the question Sharma can’t answer yet, the one that matters more than anything she says in a town hall, is whether the 30% accountability margin is still in effect. Because if it is, nothing else she does will matter. You can’t build a “reference console” and nurture creative studios while a CFO is holding a spreadsheet to everyone’s throat.

The Culture Problem Microsoft Can’t See

Here’s what Satya Nadella fundamentally misunderstands about gaming, and it’s the same thing every platform-minded executive misunderstands: gaming is not an industry you optimize. It’s a relationship you earn.

Most industries work the way Microsoft thinks. You identify a market. You build a product. You solve a distribution problem. You maximize revenue per user. You build a defensive moat. You scale.

Gaming doesn’t work that way.

Gaming is built on relationships. Between players and the characters they inhabit, between fans and the franchises they love, between a community and the platform that houses it. A Halo fan doesn’t just play Halo. They wear the t-shirt. They buy the energy drink. They argue about lore in forums at 2 AM. They recruit their friends. They are unpaid brand ambassadors who do more marketing in a single Xbox Live party chat than a million-dollar ad campaign.

Steam users are the same way about Half-Life. Full disclosure: I’m one of them. I was never a huge Halo guy, but I know plenty of people who are, and I’ve watched them defend that franchise like it was family. I get it because I’m the same way about Half-Life. The best version is on PC, will always be on PC, and I will tell you that until you beg me to stop. PlayStation fans are the same way about God of War. Nintendo fans are the same way about Zelda.

And if you want the most extreme example of what gaming loyalty actually looks like, look at StarCraft in South Korea. An entire country built a competitive culture around that game. Professional leagues. Television broadcasts. National celebrities who are famous for nothing other than being really, really good at StarCraft. It’s not a hobby over there. It’s closer to a religion. Microsoft owns Blizzard now, which means Microsoft owns StarCraft. Imagine for one second if someone in Redmond decided to announce that StarCraft is coming to PlayStation 5 and Nintendo Switch 2. Imagine telling an entire nation of fans who built their identity around that game on PC that their platform doesn’t matter anymore. They would riot. I’m not being dramatic. There would be actual civic unrest. That’s how deep gaming loyalty runs when a company earns it and a community owns it.

That’s not brand loyalty in the way a McKinsey deck defines it. That’s identity. That’s tribe.

Compare this to PlayStation. Sony completely understands that gaming operates on 17-22% margins and invests accordingly. They don’t try to make PlayStation perform like a cloud service. They don’t impose profit targets that would make a Wall Street analyst blush. They make great games, they respect their community, and they let the business follow the culture. It works. PlayStation outsells Xbox by multiples, not because Sony has better technology, but because Sony understands the relationship.

When Nadella looks at Halo and thinks, “This makes a ton of money with just Xbox players, so why can’t PlayStation 5 owners enjoy it too?”, he’s not wrong about the revenue opportunity. He’s catastrophically wrong about the cost. Because those hardcore fans who wear the shirt, who tattoo the logo, who are the brand, they didn’t just buy the game. They bought the idea that Halo belongs to Xbox. That Xbox is home. That their loyalty means something.

Take that away, and you don’t just lose a customer. You lose an evangelist. You lose the person who was doing your marketing for free. You lose the emotional infrastructure that no amount of advertising spend can replace.

Satya sees “console wars are over” and thinks it’s time to monetize across platforms. He doesn’t see the hardcore Halo player who rabidly advertises their favorite game on their t-shirt and energy drink. He doesn’t understand that those people are the strategy.

The culture is the strategy. It always has been.

Gamers Are Not Excel Users

This is the part that should scare Microsoft, and apparently doesn’t.

Excel users don’t form tribes. Teams users don’t build identity around their productivity suite. LinkedIn users don’t tattoo the logo on their forearms. Those products win on features, pricing, and distribution. You can optimize your way to dominance in enterprise software.

Gamers are different. They are activists. They strategize with their wallets. They organize boycotts that actually work. They review-bomb games on launch day. They cancel subscriptions in coordinated waves. They make YouTube videos with hundreds of thousands of views explaining exactly why they feel betrayed. They are, by any rational corporate assessment, dangerous, and any CEO who ignores that is playing with a kind of fire that doesn’t show up on quarterly earnings calls until the building is already burning.

Look at what’s already happened. Xbox hasn’t outsold Sony and Nintendo since 2008. Game Pass growth stalled, then prices jumped 50%. Studios closed. Studios that were making good games, that had impressed leadership months earlier. Thousands of jobs cut. Dev kit prices hiked 33%. Major exclusives underperformed or delayed. The “This is an Xbox” campaign actively told console owners their hardware was irrelevant. Halo, Halo, shipped to PlayStation.

Each of these decisions made sense on a spreadsheet. Each was defensible in a boardroom. And each told the core community the same thing: You are 8.9% of our revenue, and we’re going to treat you like it.

The 500 Million Mirage

Microsoft loves to point to “over 500 million monthly active users” as evidence that Xbox is thriving. Sharma used this number in her first LinkedIn post as CEO. Phil Spencer cited it in the same email where he announced mass layoffs.

It includes Windows gamers. Steam players. Minecraft players on every platform. Candy Crush players on mobile. Anyone from Activision Blizzard’s portfolio. If you’ve ever touched a Microsoft account in a gaming context, you’re in the count.

And yes, Microsoft owns Candy Crush. They acquired King as part of the Activision Blizzard deal. Candy Crush alone has hundreds of millions of players across mobile. Those people have absolutely no idea they’re being counted as part of the Xbox ecosystem. Your grandma matching candies on her iPad during a dentist appointment is, according to Microsoft’s metrics, an Xbox user. Let that sink in. Grandma is an Xbox user, but the 164 developers at ZeniMax Online who were building a game Microsoft praised eight months earlier are unemployed.

The actual Xbox console base, the people who bought the hardware, who pay for Game Pass, who identify as Xbox gamers, sits closer to 15 to 20 million active users. That’s the community. That’s the tribe. And it’s shrinking.

Counting Windows users as Xbox users is like counting everyone who’s ever used a Microsoft keyboard as an Office 365 subscriber. The number is technically defensible and culturally meaningless. It’s the kind of metric you cite when you’re trying to impress shareholders while firing the people who make the product.

Project Helix: The Bet

Project Helix, Xbox’s next-generation console, was detailed at GDC 2026. It’s a console-PC hybrid powered by a custom AMD SoC on RDNA 5 architecture, co-designed for next-gen DirectX, with ray tracing performance Microsoft calls “an order of magnitude leap.” It will play both Xbox console games and PC titles from storefronts like Steam and GOG. Developer alpha kits ship in 2027.

It’s technically ambitious. But it carries the exact tension that has defined Xbox for years: is this a console for gamers, or a platform for everyone? Because “a PC that also runs Xbox games” could be exactly what the market wants. Or it could be the “This is an Xbox” philosophy repackaged in better silicon.

If Project Helix launches and feels like a gaming PC with an Xbox skin, the core community will see right through it. If it launches and feels like home, like the Xbox 360 felt, like a console built for gamers by people who love games, it could be the reset Xbox desperately needs.

The difference between those two outcomes isn’t hardware specs. It’s philosophy. And philosophy is exactly what’s been broken.

Dear Satya

Here’s the part nobody at Microsoft wants to hear.

You spent $68.7 billion acquiring Activision Blizzard. You spent $7.5 billion on ZeniMax. You now own Call of Duty, World of Warcraft, Diablo, Candy Crush, The Elder Scrolls, Fallout, Doom, Halo, Minecraft, and Forza. Some of the most valuable franchises in entertainment history.

And your gaming division is 8.9% of your revenue. A green sliver on a pie chart dominated by Azure and Office.

You responded to that by imposing a 30% profit margin on an industry that operates at 17-22%. You let your CFO run gaming like it was a cloud division that needed to hit quarterly targets. You watched as that mandate produced mass layoffs, studio closures, price hikes, and the cancellation of games that your own leadership had praised months earlier. Your studios made great games and got fired for it.

You look at that pie chart and see a sliver to be optimized. Gamers look at it and see their entire world.

The gaming community is not a user base. It’s not a TAM. It’s not a growth vector. It’s a tribe of people who will go to war for a brand that respects them, and will burn it to the ground if it doesn’t. They are strategizing with their wallets right now. They are canceling subscriptions. They are buying PlayStations. They are making very loud, very public decisions about where their money and loyalty go.

If you continue treating Xbox like a cloud division with a controller, if the 30% mandate stays, if the layoffs continue, if the culture keeps getting sacrificed for margin, you might as well drop the name entirely. Call it Microsoft Gaming. Call it whatever you want. Because the thing that made “Xbox” mean something, the identity, the community, the culture, the tribe, will already be gone, the community, the culture, the tribe, will already be gone.

The culture is the strategy, Satya. It always was.

And right now, 8.9% of your revenue is screaming that at you, and you’re not listening.

The Nuclear Option

Here’s a thought that sounds radical until you think about it for thirty seconds: sell Xbox.

Not to another tech conglomerate that will treat it like a line item. Sell it to someone who actually gives a damn about games. A billionaire who’s a real gamer. A private equity group filled with people who understand that gaming is culture first and business second. Someone who would look at Halo, The Elder Scrolls, Call of Duty, and Minecraft and see them not as assets to be optimized but as legacies to be honored.

It raises a fascinating question: how many billionaires are actually hardcore gamers? How many would run Xbox the way it deserves to be run, with passion, with patience, and with the understanding that the 17-22% margins the industry operates on aren’t a problem to be solved but a reality to be respected?

I don’t know the answer. But I know this: whoever ran Xbox next would need to understand that the brand’s value isn’t in its revenue. It’s in the millions of people who built their identity around it. People who are still here, still waiting, still hoping someone at the top will finally, actually, give a damn.

Microsoft clearly doesn’t. And that might be the most honest thing you can say about Xbox in 2026.

The Bottom Line

Asha Sharma is not the villain of this story. She might even be part of the solution, if the philosophy above her changes. But the jury on her is going to be out for a long time, and this is a jury that doesn’t grant continuances.

The villain is a corporate philosophy that treats gaming like any other division to be optimized. A CFO who set a 30% margin target that no gaming company can sustain. A CEO who let AI cannibalize the resources gaming needed. A leadership structure that looked at $76 billion in acquisitions and asked “how fast can we squeeze this?” instead of “how do we honor what we bought?”

The Xbox fanbase isn’t dead. But it’s been abandoned. They didn’t walk away. They were pushed. Pushed by decisions that treated them like a rounding error. Pushed by a 30% mandate that killed studios making good games. Pushed by a company that forgot what made Xbox matter in the first place.

Gamers don’t need perfection. They need passion. They need consistency. They need someone who gives a damn.

Right now, Microsoft is giving them strategy instead of soul.

And strategy has never, not once in the history of this industry, brought a single gamer back.

Sources: Bloomberg (Jason Schreier, Dina Bass, October 23, 2025); Windows Central (Samuel Tolbert, July 2, 2025); TrueAchievements (Tom West, July 4, 2025); The Verge (Tom Warren, October 21, 2025); The Information; GameSpot; Bellular News.

Data note: Microsoft does not report Xbox as a standalone audited revenue segment. The $25.1B Gaming/Xbox estimate is derived from Microsoft’s FY2025 disclosures (Gaming revenue up 9%, Windows & Devices up 2%, Search & News Ads up 13%) normalized against the audited More Personal Computing segment total of $54.6B. Microsoft’s total FY2025 revenue was $281.7B. Xbox hardware revenue fell 25% in FY2025; growth was driven by Xbox content and services, including Activision Blizzard. Industry margin comparisons use different accounting standards (GAAP, IFRS, ASBJ) and Microsoft’s internal “accountability margin” metric is not directly interchangeable with competitors’ reported operating margins.

When you're ready to see what the real stuff looks like — the actual code, the actual architecture, the actual war stories from building a production app — the rest of my articles are right there waiting for you. But this one's yours. Let's go.

My wife’s dentist — good dude, actually. We went to the same high school. They were making small talk while she was in the chair and he asked whether our son was still learning to code. She said yes. And he goes, “Isn’t AI going to take over that job?”

My wife, bless her, went: “Maybe? I don’t know.”

She wasn't uncertain. She watches me fight with these things every single day. She knows exactly what I go through. She was just being nice to our friend.

But here’s the thing — he’s not wrong to ask. He’s just working with bad information. And that’s not his fault.

That’s the media’s fault.

Let's Talk About What the Media Actually Does

Picture a room. There are a hundred important things that need to be reported today. Real things. Things that actually affect your life. The people in that room look at all hundred of them, stick a finger in the wind, and think: “Okay — what are people already talking about? What’s going to sell enough ad space to make this worth our time?”

That’s it. That’s the whole process. That’s the editorial meeting.

It’s not malicious. It’s not a conspiracy. It’s just a business making a business decision. And right now, “AI is coming for your job” sells a lot more ad space than “AI is a useful tool with some pretty significant limitations that require years of experience to navigate.” One of those headlines makes you feel something. The other one makes you change the channel.

So instead of telling you the boring true thing, they tell you the exciting false thing. With the confidence of people who have never written a line of code, never built anything real, and never had to sit with the consequences of being wrong. They are selling you a feeling, not a fact. And the feeling they’re selling right now is: AI is magic, your job is gone, the robots are coming, be afraid, click here to learn more.

They can take a guy who jaywalked across the street and make him look like a serial killer. And they can take a tool that’s genuinely useful for certain things and turn it into the Second Coming of Skynet — all before lunch, with seventeen ads in between.

My friend the dentist heard the Skynet story. He never heard the jaywalking story. Nobody made the jaywalking story into a headline because who clicks on that?

So he asked my wife a completely reasonable question — and she said “maybe, I don’t know” because she didn’t want to get into it while someone had their hands in her mouth.

I, however, have all the time in the world. And no one’s hands are in my mouth right now. So let’s get into it.

Example 1: The AI That Argued With a Receipt

Here's a single line of code. The only thing it does is round a number:

round(2.675, 2)

You don’t need to know anything about programming to understand this. It’s asking the computer: “Round 2.675 to two decimal places.” That’s it. Third grade math. The answer is 2.68, right? The 5 rounds up. Everyone knows that.

The answer is 2.67.

Before you throw your phone — this isn’t a trick question. It’s not a riddle. The reason has to do with something deep in how computers store numbers, and the short version is this: computers can’t actually hold the number 2.675 perfectly. They store something just barely less than 2.675 — so tiny you’d never notice it — until you round, and the answer drops instead of rounds up. There’s also a whole separate thing where computers are designed to round a certain way specifically to stay fair over millions of calculations. The details don’t matter right now. What matters is: 2.67 is correct, 2.68 is wrong, and the reasons have been understood by mathematicians for decades.

Ask an AI. It will tell you 2.68. Confidently. It will explain why 2.68 is correct with the calm, authoritative energy of a man who has never been wrong in his life and finds the very concept personally offensive.

It’s not lying. It’s doing what it always does — it looked at the shape of the question, recognized a rounding problem, remembered that 5 rounds up, and produced the most familiar-sounding answer. It has never understood the rule. It’s just seen the pattern so many times it thinks it owns the rule. There’s a difference. A massive one.

Imagine you hire a math tutor who has read every math textbook ever printed — every single one — but has never once sat down and actually solved a problem with a pencil. He can talk about math all day. He sounds phenomenal. He’ll explain rounding to you with warmth and confidence and maybe a little diagram on a napkin.

And then he’ll hand you a bill that’s wrong by ten cents and argue with you about it while you’re literally holding the receipt.

Now here’s where it gets interesting — because the “AI experts” you see on your feed? The ones with the big audiences, the podcast, the newsletter, the LinkedIn posts getting fifty thousand likes? They’re the same tutor. They’ve read everything. They can talk about AI all day and night. They know all the right words. They sound like they’ve been doing this since before you knew what a computer was.

But here’s what they’re not doing: the actual work. They’re not sitting down with these tools and grinding through a real problem at midnight when everything is broken and the deadline is tomorrow. They’re not finding out the hard way that the AI confidently got the rounding wrong. They’re not living in the gap between what the AI says it can do and what it actually does when real people start using your product.

The people who are doing that work? The ones who actually know where these tools shine and where they completely fall apart? They’re too busy building. The engineers working on the next version of Claude, the next version of ChatGPT — they’re not on YouTube making reaction videos. They’re in the lab. They don’t have time for an audience because they’re too busy being genuinely useful.

So what you’re left with is this: the people who own the audiences don’t always tell the whole truth. Not because they’re evil — but because the whole truth doesn’t serve their bottom line. Their audience wants to feel like they’re on the edge of something historic. Their audience wants to believe the robots are coming, or that there’s a secret prompt that unlocks superintelligence, or that the guy in the thumbnail has figured out something everyone else missed. The whole truth — “it’s a useful tool with specific limitations that requires real expertise to use well” — doesn’t keep people subscribed. It doesn’t sell the course.

You know what it reminds me of? Those As Seen On TV ads. The ones you’d catch at midnight after a peanut butter and jelly sandwich, half asleep on the couch, watching some guy in a headset tell you this one weird trick will change your life for four easy payments of $19.99. You’d laugh, change the channel, go to bed. It was easy to ignore because it was only on at midnight and you stumbled into it by accident.

Except now it’s 2026. Social media is a TV in everyone’s pocket. And it’s not midnight once in a while — it’s every single second of every single day. The same pitch. The same energy. The same guy in the headset. Just with better lighting, a ring light, and an algorithm making sure you never accidentally change the channel.

So they tell the version that works for their audience. And the real experts? We’re exhausted. And honestly — even when we want to engage, the game is rigged before it starts.

Here’s how it goes. Someone wants to interview you. Great. You show up ready to give them the full picture — A to Z. Every nuance, every caveat, every “yes, but here’s the thing they’re not telling you.” Because context is everything in this conversation. Without context, the truth becomes a lie by omission.

But the interviewer doesn’t want A to Z. They want A, B, and C. They’ve already written the segment. They already know what their audience wants to hear. They need you for one thing — your name on the lower thirds. Your credibility as a prop. “Engineer with 40 years of experience says...” and then they finish that sentence however they want. They got what they came for. You gave them the ammunition and they aimed it however suited them.

So after a while, the real experts stop raising their hands. Not because we don’t care — but because we’ve learned that the format doesn’t allow for the truth. You can’t explain a race condition in a fifteen-second soundbite. You can’t explain why the rounding answer is wrong in a tweet thread designed to go viral. The full story is too long, too boring, and too unlikely to end with someone feeling scared or excited enough to share it.

And the real experts stay quiet, and the noise fills the vacuum, and somehow that noise gets mistaken for the signal.

That’s what my friend the dentist is reading. That’s what’s in his feed. That’s the math tutor with a million followers who has never once graded his own homework.

And that brings me back to the rounding problem — because it’s the perfect illustration of exactly what I just described. The AI gave the wrong answer with complete confidence, the same way the guy on the podcast gives you the wrong picture of AI with complete confidence. Neither of them has ever had to be accountable for being wrong. Now imagine that same confident wrongness running your billing system. That’s not a hypothetical. That’s a lawsuit.

Example 2: The AI That Answered a Question Nobody Should Answer

Here's another snippet. Again — you don't need to understand the code itself:

printf("%d %d %d\n", i++, ++i, i);

All this is doing is asking the computer to change a number in three different ways simultaneously and then print the result. Sounds simple enough.

What does it print?

The correct answer — the one any experienced programmer knows immediately — is: nothing that means anything, and whoever wrote this needs to have a long think about their choices.

There’s a category of question that’s not just hard to answer — it’s broken. Like asking “what’s north of the North Pole?” The question itself is malformed. The rulebook that governs this type of code looks at it and explicitly states: we refuse to define what happens here. The computer can do whatever it wants. Print a number. Crash. Catch fire. This one’s on you.

The right answer is to recognize the question is broken and say so. Clearly. Immediately.

Ask an AI. It prints a number. A specific, real, confident number. It might even walk you through how it arrived there — step by step — like a doctor delivering a detailed, professional diagnosis for a disease that has never existed in the history of medicine. Confident. Thorough. Completely made up.

Here’s the picture. You ask someone: “What time does the next train leave from Union Station in my hometown?” But your hometown doesn’t have a train station. Never had one. There’s a Dairy Queen where a train station might have been, if anyone had ever cared enough to build one.

A person who actually knows your town says: “There’s no train station there.”

The AI says: “3:47. Platform B. Bring your own snacks — that line doesn’t have a café car.”

Specific. Confident. Entirely fabricated. Because it’s learned that train questions have train answers, and it has no mechanism for recognizing when the question itself is the problem.

The media says this thing is about to replace software engineers. Software engineers are over here watching it invent train schedules for cities with no trains.

Example 3: The Movie Critic Who Reviewed a Film That Was Never Made

Last one. Here’s some code:

let mut v = vec![1, 2, 3];
let a = &v[0];
v.push(4);
println!("{}", a);

Plain English translation: make a small list of numbers, remember where the first one lives, add a new number to the list, then go back and read the first one.

Ask an AI what it prints. It’ll say: 1. No hesitation.

This code doesn’t run. It can’t. The programming language it’s written in looks at it before anything happens and refuses to proceed — because it can already see that something dangerous is about to occur.

Here’s why, with zero technical knowledge required. When you add a new item to a list that’s already at capacity, the computer sometimes has to pick up the entire list and move it to a bigger space — like moving out of a studio apartment into a two-bedroom because you finally bought a couch. When that happens, the address you saved for “the first item on the list” is now pointing at the old apartment. Which is empty. Which may have already been rented to someone else entirely. If you go looking for your stuff there, you’re not going to find it. You might find someone else’s stuff. You might find nothing. In the real world of software, this is how data gets corrupted and how security holes get created.

The language in this example is smart enough to look at your plan before it executes and say: “I see what you’re about to do. I’m not going to let you do it. Go fix it first.” Like a good friend who grabs your arm before you send the drunk text.

The AI says it prints 1. Because it’s seen a million examples of code that reads the first item in a list, this looked like one of those, and it told you what those usually do. It had no idea the whole thing was rejected before it ever started. It’s reviewing a movie that was never made. The studio said no. There are no actors. There is no footage. There is no film.

The AI just gave it four stars and called the third act emotionally devastating.

The Bullshit Is So Thick — I’m Forced to Wade Through It.

Here’s the part that actually exhausts me.

People are out here — on television, in major newspapers, in TED Talks — genuinely debating whether we’re close to building the Terminator. The actual Terminator. Skynet. The robot apocalypse. And after nearly three years of AI being shoved in our faces every single day on every platform, we are standing here watching it get a rounding question wrong. One line of code. Not a complex system. Not a massive algorithm. Three examples. One. Single. Line. Of. Code.

GET. THAT. IN. YOUR. HEAD.

Believe it or not, I have hundreds of examples of this once you get to 5-10 lines of code or more. The volume of nonsense floating around about AI right now is so extreme it makes dinosaur feces look like bird droppings. It’s not a little misinformation. It’s a full avalanche. It’s been building for three years and every new breathless headline adds another layer. And it doesn’t live out there in the abstract — it lands directly on my doorstep on a regular basis.

I have clients who’ve read the headlines and come to me asking whether they even need to invest in building software anymore, or if they should just “wait for the AI to handle it.” I have new programmers asking me if it’s worth learning to code or whether they’re already obsolete before they’ve written their first working program. And I have early customers of BenchBoard — the app I’ve spent the last eight months building — who wonder out loud whether some AI is going to show up and make the whole thing irrelevant before it even launches.

I have to talk every single one of them off the ledge. Every time. With actual examples. With actual facts. Because the headlines sure aren’t providing any.

And where are those headlines coming from? Let’s be honest. They’re coming from journalists who have never built software. Talking heads who learned the phrase “artificial intelligence” sometime around 2022 and have been dining out on it ever since. Venture capitalists who need a story to tell their investors. Consultants who rebranded overnight and declared themselves “AI strategy experts” because they used ChatGPT to write an email once. These people are speaking with total authority about something they have never done, and they are being handed microphones, publishing deals, and conference stages to do it from.

They are the ones telling my friend’s son not to bother learning to code.

They are the ones telling my clients to wait for the magic to arrive.

They are the ones manufacturing fear and awe and urgency out of thin air because fear and awe and urgency pay the bills — and the actual engineers, the people who use these tools every day and know exactly where and how they fail, are too busy fixing the problems to write the headlines.

So yes, this is partly therapeutic. But it’s also — I hope — genuinely useful for anyone who’s been swimming in that swamp and trying to find solid ground. These three examples are what I reach for every time someone comes to me with that look. You know the look. The one that says they just read something on the internet and now they think the robots have already won.

They haven’t. Not even close.

What's Actually True — And Why It's More Interesting Than the Headlines

I use these AI tools every single day. I’ve been building BenchBoard — a live scorekeeping and lineup management app for youth baseball and softball — and I genuinely could not have moved this fast without them. They are remarkable. I am not here to tell you they’re worthless.

But I’ve also watched an AI introduce a bug into my app that caused two players to show up at Second Base on a real field during a real game — because it created two separate systems writing to the same data at the same time with nobody coordinating them. The screen looked fine. Everything appeared to save correctly. It only blew up at exactly the worst moment, when a coach switched between games on their phone. You would never catch it in a demo. You catch it on a real field with real kids and a real umpire staring at you.

I’ve watched the AI design something that looked clean and logical on paper and turned into a disaster the moment actual people started using the app in actual ways — requiring 36 separate fixes before I finally scrapped it and rebuilt it myself. The AI didn’t come up with the solution. I did. Because I’ve been doing this for forty years and I know what breaks in the field.

I’ve watched the AI serve one user’s data to a completely different user because it stored everything in a flat unlabeled pile. Works great when you’re the only person testing it. Falls apart the moment a second human being shows up.

None of these are failures the AI could warn me about, because the AI doesn’t know what it doesn’t know. It doesn’t know what a coach looks like in August heat trying to swap two players before the umpire yells play ball. It doesn’t know what happens when a parent watching a live scoreboard on their phone sees the wrong lineup because the coach just made a change on theirs. It doesn’t know any of that because it’s never been there. It’s read about software. It’s never lived in it.

That’s the gap. And it’s not a small one. It’s the whole game.

What I'd Actually Tell My Friend the Dentist

Here’s what I would actually tell my buddy the next time it comes up — and hopefully after the checkup.

Learning to code is absolutely still worth it. More than ever, actually. And here’s why.

These tools are real and they’re genuinely useful. My son will probably use them from day one and move faster than I could at his age. Never having to spend three hours on something I spent three hours on. No more small dumb errors that come up that used to take hours to troubleshoot. At least almost. That’s real, and that’s good.

But he still needs to understand why the rounding answer is 2.67 and not 2.68. He still needs to recognize when a question is broken, and the right answer is “don’t do this.” He still needs to understand why a programming language threw his code in the trash before it even ran — not because he’ll be solving these things manually every day, but because when something breaks in the real world at the worst possible moment, “I asked the AI and it said everything was fine” is not going to cut it as an explanation. Not with a client. Not with a user. Not with a coach on a field who wants to know why two kids just showed up in the same spot.

The AI is a brilliant, tireless, occasionally confident assistant that’s sometimes, well, wrong. It is not a substitute for knowing what you’re doing.

The media will keep writing the Terminator story because the Terminator story gets clicks. My friend will keep reading it over breakfast. And somewhere, a kid is going to decide not to learn programming because of a headline written by someone who has never built a single thing in their life.

That kid deserves better than that. And honestly — so does my son.

I write about what it actually looks like to build real software with AI tools — the wins, the failures, and everything the headlines leave out. If that sounds useful, subscribe and come along.

My daughter is the most experienced pitcher on her team — she’s become a strong leader out there, and the other girls look to her. The manager gave her the game ball today. I’m the assistant coach — I manage the lineups and defense, and the manager trusts what I’m doing. There are three of us coaching this squad, and as of recently, I’ve also been testing the app I’ve been building in every spare hour I have.

Today was supposed to be a normal game. It wasn’t.

I’ve been bringing BenchBoard to games for a few weeks now — this was the third one.

I’ll be honest: I rushed this thing out the door. I was racing to get it ready before game one, and I barely made it. That first game, I printed the lineups at home beforehand and we still had to cross names out by hand when the roster changed at the field. Game two went smoother — everything worked except one wrong jersey number for a player. Small stuff. But small stuff is what coaches notice.

This third game was the first time the lineup and defense management ran with no hiccups. No crossed-out names. No wrong numbers. Just clean printouts, real-time roster changes, and a workflow that actually held up under game conditions.

But here’s what I’m realizing — the same thing the other coaches on my staff who’ve been using it are realizing: the lineup and defense side works. It needs polish, but it works. The big one — scorekeeping — is actually live. It’s there. You can use it. But I’d call it a beta, and I know it’s not ready for primetime yet.

One of the coach’s wives was already keeping score on paper during the game. I could have asked her to try BenchBoard’s scorekeeping too — but I wasn’t about to give her two things to do in the middle of a live game. That’s how you burn someone out on your product before they’ve even started. What I’m planning instead is to have whoever’s on the bench handle the scorekeeping next time. They’re sitting there, they’re watching the game, and it gives me a real beta tester who isn’t already juggling another task.

And that’s the tension of building in public. You want it to be ready. It’s not. You ship it anyway. And then you learn what “ready” actually means — not from your codebase, but from the helmet shelf in the dugout.

After the game, the manager told me the app is pretty cool. I just shrugged. I’m still at the stage where every compliment gets met with a quiet I hope this damn thing works. Cool is nice. Reliable is what I’m after.

Today was the game where everything clicked into focus. I learned more in two hours at that field than I have in months of development.

Let me tell you what I brought with me.

The Setup

I showed up to the field with four things: my laptop, a Phomemo M408 mobile printer, a USB-C cable, and a manila envelope stuffed with 100 sheets of 8.5x11 Phomemo thermal paper straight from Amazon. I set everything up on top of a helmet shelf in the dugout — a $2,000 MacBook Air balanced next to batting helmets with the printer attached via USB, both of them one elbow bump away from hitting the dirt. Every time we needed to print, I had to pull a sheet out of the envelope and feed it into the printer. It was cumbersome. It was not elegant. But I opened BenchBoard, pulled up our lineup, hit print, and handed a clean, formatted lineup card to the umpire.

The looks I got from the other coaches? Not excitement. Not “oh my God what is that.” Just a glance. A nod. An “ooh, interesting.”

And you know what? That’s exactly right.

Coaches at a game are coaching. They’re not evaluating software products between innings. They’re thinking about who’s batting fifth and whether their pitcher’s arm is going to hold up. I shouldn’t have expected more than a nod. But here’s the thing I noticed: the opposing coaches received our printed lineup, and then I caught them looking up the site on their phones. They were talking about it on the other side. Quietly. To each other.

That nod? That’s the top of the funnel. The conversion happens later, in the car ride home, when that coach is handwriting his next lineup and remembers the crisp printout he got handed today.

What Worked

The interface looked good. On my laptop, BenchBoard looked like a real product. Not a side project. Not a prototype. A thing that belonged at a ball field.

Managing the roster in real time was seamless. We had a couple players who weren’t going to make it — last minute, of course, because that’s how youth sports works. I pulled them off the lineup, adjusted, hit print again. New lineup. Done. No crossing out names with a pen like game one. No scribbling in the margin. No “wait, who’s playing short now?”

Communicating with my coaches was easy. I could show them the screen and say “here’s who’s on the bench, here’s our defense” and everyone was on the same page. No squinting at a clipboard. No “I think she said Amanda’s at second?”

The submit-and-print workflow was satisfying. Hit submit. Defense locked in. Lineup confirmed. Print. Hand it to the ump. There’s something about that flow that just feels right. Like the app is doing the thing it was born to do.

What Didn’t Work

And here’s where it gets honest.

Four things is too many things. A laptop. A printer. A cable. A manila envelope full of thermal paper. I’m already carrying a gear bag, a bucket of balls, batting helmets, and whatever else my team forgot. Adding four items to set up a “simple” lineup system turns BenchBoard into a project, not a tool. Coaches don’t want projects. They want tools. Hell, Adam Sandler would be happy with just 3 things and thankfully wallet and keys don’t have to be part of it.

The laptop kept timing out. This was one of the big ones. My laptop is secured with a fingerprint, so every time the screen locked — which it does constantly in the sun — everyone had to wait for me to wake it up just to see the lineup or defense. That’s a momentum killer. In the middle of a game, when a coach asks “who’s up next?” the answer can’t be “hold on, let me unlock my laptop.”

Entering the opponent’s lineup was painful. The opposing coach handed me a paper lineup. Standard stuff. I tried to type it into BenchBoard manually and immediately started fighting the interface. I’d accidentally drag players around. Choosing positions meant hitting dropdown after dropdown. What should’ve taken 60 seconds took way too long and felt clunky the whole time. For a coach who’s never used the app before? That’s a wall.

The laptop felt like overkill. I’m sitting there with this computer open at a kids’ softball game and it just felt... heavy. Like I was doing too much. Meanwhile, one of the coach’s wives grabbed a clipboard and a dry-erase marker and wrote the lineup in big capital letters so everyone could see it from the dugout. She solved the visibility problem in 30 seconds with a $4 marker.

That moment stung a little. But it also taught me something.

What I Actually Need

The dry-erase clipboard wasn’t competing with BenchBoard. It was exposing a gap. BenchBoard is great at building and managing the lineup. But it’s not yet great at displaying it to the people who need to see it in real time — the coaches in the dugout, the parents keeping score, the players checking when they’re up.

A tablet changes everything. Mount it on the fence or the dugout gate. Big screen. Zoomable defense view. Everyone can see it. No laptop. No squinting.

And the printer? What if instead of lugging around a laptop-sized thermal printer with a cable, I just had a small Bluetooth label printer in my gear bag? The ones people use to print shipping labels — 4x6 format, Bluetooth, fits in your hand. I open BenchBoard on my phone. Tap print. The little printer spits out a lineup card. I hand it to the ump. Two things instead of four: my phone and a printer that fits in a side pocket.

That’s the difference between “this coach has a whole setup” and “wait, he just printed that from his phone?”

The first one is impressive but intimidating. The second one makes the opposing coach think I could do that.

The Feature I Wish Existed

When the opposing coach handed me his paper lineup, I had to manually type in every name and select every position. But I’m staring at a piece of paper that already has all the information on it. In order.

What if I could just point my phone camera at that paper lineup and the app reads it? Scans the names, the positions, the batting order — and drops it right into the scorekeeping side. OCR for lineup cards. That’s not science fiction. That’s a phone camera and some text recognition.

I’m not building that tomorrow. But I wrote it down. Because today, at the field, fighting with dropdowns while the ump waited, I felt the friction. And when you feel it yourself, you don’t forget it.

Why I’m Writing This

I’m 51 years old. BenchBoard is my third company. The first two didn’t make it — one got absorbed by a bigger network, the other fell apart when my business partner couldn’t make it work. I’ve got teenage kids who are cheering me on. A wife who believes in what I’m building. And a long road ahead.

I read a story recently about James Dyson — the vacuum guy. He spent 14 years building prototypes in a shed behind his house. Built 5,127 of them. His wife Deirdre was an art teacher who supported the family on her salary while he remortgaged their home over and over. His kids grew up watching him go to that shed every day. He finally shipped his first product at age 46.

Today, his son is VP of Engineering at the company. His wife is creative director. The family that held him up during the hard years is now running the thing that came out of them.

I’m not James Dyson. I’m a coach with a laptop balanced on a helmet shelf, hoping it doesn’t fall, at my daughter’s softball game. But I know what it feels like to carry something you believe in while the world gives you a polite nod and goes back to what they were doing.

The opposing coach looked up my site today. He didn’t sign up. He didn’t say “wow.” He just nodded. And that’s enough. Because adoption doesn’t start with a standing ovation. It starts with a nod. Then a glance at the phone. Then, weeks later, when that coach is handwriting a lineup at 6 AM before a tournament and he remembers the printed lineup that got handed to him — that’s when the seed grows.

I’m building BenchBoard for coaches like me. Coaches who are also parents. Coaches who are tired of the clipboard-and-Sharpie workflow but don’t want to fight with bloated apps that weren’t built by someone who’s actually stood in the dugout.

Every game I coach is a product test. Every printed lineup I hand to an opponent is a business card. Every problem I hit at the field is a feature I’ll build next week.

Today I learned that four things is too many. Two is the right number. And a dry-erase marker is still the fastest display technology ever invented — until I get a tablet on the fence.

More soon.

Rad is the founder of IronBench Labs and the creator of BenchBoard — a real-time scorekeeping and team management app for baseball and softball. He’s an assistant coach on his daughter’s team in California and field-tests every feature himself. Follow along as he builds in public.

This is Part 2 of a five-part series about building BenchBoard — a team management and live scorekeeping app for youth baseball and softball — with the help of AI tools. If you missed Part 1, start there. It sets the stage for everything that follows.

In Part 1, I mentioned that the AI once built a race condition directly into my live scorekeeping system. I said I’d tell you the full story. So here it is.

But first, a little context — because this story doesn’t make sense unless you understand what BenchBoard is actually doing under the hood.

What a “Simple” Lineup Actually Looks Like in Code

When most people hear “lineup management,” they picture a list. A list of players, nine positions, maybe a batting order. How hard could it be?

Here’s how hard.

A lineup in BenchBoard isn’t a list. It’s a snapshot — a single atomic record that holds three separate JSON blobs at the same time: who’s active on the roster (ManagePlayersJson), what order they’re batting in (BattingOrderJson), and where they’re positioned on the field (DefenseJson).

All three of those blobs interact with each other.

Here’s what a single LineupSnapshot actually looks like in the database. One row. Three blobs. Everything about your team’s current state lives here:

LineupSnapshot (one row per team per game)
├── TeamId: "a]4f2e..."
├── GameId: "7dee-4c9d..." (null = practice mode)
│
├── ManagePlayersJson:
│   [
│     { "playerId": "p-001", "name": "Barry Bonds",     "jersey": 25, "active": true  },
│     { "playerId": "p-002", "name": "Jennie Finch",    "jersey": 27, "active": true  },
│     { "playerId": "p-003", "name": "Jackie Robinson", "jersey": 42, "active": true  },
│     { "playerId": "p-004", "name": "Yogi Berra",      "jersey": 8,  "active": true  },
│     { "playerId": "p-005", "name": "Monica Abbott",   "jersey": 14, "active": false },
│     ...12 players total
│   ]
│
├── BattingOrderJson:
│   [
│     { "playerId": "p-003", "order": 1 },   // Jackie Robinson leads off
│     { "playerId": "p-001", "order": 2 },   // Barry Bonds bats second
│     { "playerId": "p-002", "order": 3 },   // Jennie Finch bats third
│     { "playerId": "p-004", "order": 4 },   // Yogi Berra cleanup
│     ...only active players, sequential, no gaps
│   ]
│
├── DefenseJson:
│   {
│     "p-001": 9,    // Barry Bonds → Left Field
│     "p-002": 3,    // Jennie Finch → Pitcher
│     "p-003": 8,    // Jackie Robinson → Shortstop
│     "p-004": 11,   // Yogi Berra → Right Field
│     "p-005": 1,    // Monica Abbott → Bench Slot 1 (inactive)
│     ...
│   }
│   // Position IDs: 1=Bench1, 2=Bench2, 3=Pitcher, 4=Catcher,
│   // 5=1st, 6=2nd, 7=3rd, 8=SS, 9=LF, 10=CF, 11=RF
│
└── LockLineupToggle: false

See how they connect? If you deactivate Monica Abbott in ManagePlayersJson (active: false), that has to cascade into BattingOrderJson — she gets removed and the order renumbers so there’s no gap at position 5. And it has to cascade into DefenseJson, because if she was at pitcher, you can’t leave an empty circle on the mound. Everything ripples.

That’s the resting state. Now make it live. A coach is standing on a field with their phone, moving players around mid-game. A parent in the stands is watching a live scoreboard on their phone. The scorekeeper is tracking pitches in real time. All of these views need to stay in sync, instantly, and they all read from the same underlying data.

This is the kind of complexity that sounds manageable when you describe it in a sentence but becomes a monster the moment you start writing the code. And it’s the kind of complexity that LLMs are terrible at anticipating — because they’ve never stood on a field and watched a coach frantically swap their right fielder for a kid who just showed up late.

Three Tables Walk Into a Bar

Let me tell you how this mess started, because it’s a perfect example of how AI-generated prototypes can set you up for pain down the road.

Back in July, when I was still on ChatGPT, I was using Codex to build out the early screens — the roster view, the lineup card, the field diagram. Basic prototypes. The kind of thing where you describe what you want and the AI generates a working UI in minutes. And it was impressive. I had screens that looked real within hours.

But here’s what Codex also did: it looked at those prototypes and decided what the database should look like. It saw a roster screen, a batting order screen, and a field position screen — three screens — and created three tables. One for managing which players were active (LineupEntries). One for the batting order. One for the defensive positions (DefensiveAssignments). It even told me the schema was “expandable and would work perfectly over time.” Real words from the LLM. Not mine.

From a database design perspective, it wasn’t a bad answer. It’s what you’d find in a textbook. Each concern is separated. Each table has a clear purpose. If you were building a homework assignment, you’d get an A.

But I wasn’t building a homework assignment. I was building an app where a coach is standing on a field in 95-degree heat, trying to swap two players before the umpire yells “Play ball.” And in that world, three tables is a disaster.

Every time a coach made a change — moving a player from the bench to the field, or swapping two players in the batting order — the system had to coordinate writes across three tables. If one write succeeded and another failed (network hiccup, timeout, race condition), you’d get an inconsistent state. The batting order says the player is #6, but the manage-players table says they’re inactive. The field shows them at shortstop, but the batting lineup doesn’t have them at all.

The number of database migrations I’ve had since those original three tables is insane. At one point I had 36 migration files just for DefensiveAssignments alone — adding slot constraints, bench slots, indexes, field position constraints. Every time I discovered a new edge case, it was another migration. Another schema change. Another deployment risk.

This is the kind of thing the AI never warned me about. It looked at three screens and gave me three tables. It didn’t think about what happens when all three need to change atomically in the same instant.

And before someone in the comments says “well, you should’ve used MongoDB” or “NoSQL would’ve solved this” — no. Hard no. I need transactions. I need relational integrity. I need to know that when a coach confirms a lineup, that data is exactly what the system says it is. I need hard receipts. A scorekeeping app isn’t a dashboard pulling from a million data stores — it’s a system of record. Every pitch, every substitution, every lineup change needs to be verifiable and consistent. I love MongoDB — it’s a great database for the right use case. This isn’t it. Document-based storage would’ve given me the same data consistency nightmares, just wrapped in a different syntax. And honestly, it probably would’ve been messier, because at least with SQL Server I get real foreign keys and real transaction isolation.

Eventually, I made the call to consolidate all three tables into a single LineupSnapshot — one atomic record that holds everything. When the coach makes a change, one record gets written. If it fails, it fails completely. If it succeeds, everything is consistent. The refactor touched dozens of files across both the backend and frontend, required migrating all existing data, and took days. But when it was done, an entire category of bugs just disappeared.

The AI didn’t suggest this refactor.

I did.

Because I’d been living with the bugs its original “expandable” schema created for months.

The Night I Found Two Players at Right Field

A few weeks later, I’m testing BenchBoard late at night. I’m dragging players around the field — moving Jackie Robinson to right field, where Yogi Berra is already stationed. Standard swap. The app should move Jackie to RF and send Yogi somewhere else — back to his original position or to the bench.

I do the drag. It looks fine. I switch to a different game to check something. I switch back.

Two players at right field. Jackie and Yogi, both sitting in the same position. That’s not supposed to be possible.

I check the console logs. The data is there — the system knows there are two players at RF. But somehow the snapshot saved with both of them at the same position. The deduplication logic on the backend catches it after the fact, but the damage is already done. The data is dirty.

So I start tracing the flow with the AI, and here’s what we find.

When a coach drags a player to a new defensive position, the system does four things:

1. Optimistic update — the frontend store immediately swaps the players so the UI feels instant.

2. syncSnapshot fires — the frontend serializes the entire store and writes the lineup snapshot to the database. Writer #1.

3. The defensive controller fires — a separate API call tells the backend to process the swap with its own logic and write the result to the same snapshot. Writer #2.

4. Re-fetch — the frontend pulls the latest snapshot from the backend and rehydrates the store from whatever it finds.

See the problem?

Steps 2 and 3 are both writing to the same database record at the same time. It’s a textbook race condition. Here’s what it looks like with real data:

BEFORE THE DRAG:
  DefenseJson: { "p-003": 8, "p-004": 11, ... }
               // Jackie → SS,  Yogi → RF

COACH DRAGS JACKIE TO RIGHT FIELD:

  Step 1 - Frontend optimistic update:
    { "p-003": 11, "p-004": 1, ... }
    // Jackie → RF, Yogi → Bench1 ✓ (looks right)

  Step 2 - syncSnapshot writes to DB:          ← Writer #1
    saves { "p-003": 11, "p-004": 1, ... }
    // Jackie → RF, Yogi → Bench1

  Step 3 - Defensive controller writes to DB:  ← Writer #2
    saves { "p-003": 11, "p-004": 8, ... }
    // Jackie → RF, Yogi → SS (his original spot) ← CORRECT

  WHO WINS? Whichever HTTP response finishes LAST.

  If Step 2 finishes after Step 3:
    DB has: { "p-003": 11, "p-004": 1, ... }
    // Yogi is on Bench1 instead of back at SS
    // The controller's correct swap got silently overwritten

Whichever HTTP response finishes last wins. If syncSnapshot finishes after the defensive controller, it overwrites the controller’s properly-computed swap with the frontend’s optimistic state — which has Yogi bumped to bench slot 1 instead of back to his original position. The backend controller’s correct answer gets silently erased.

The AI identified the race condition once I pointed out the symptoms. It then proposed what it called “the clear answer”: just stop calling syncSnapshot from the defensive drag handlers. Let the defensive controller be the sole writer.

That’s a band-aid. It would’ve fixed this particular race condition. But it wouldn’t fix the architectural flaw underneath — which is that there were multiple independent writers competing for the same data, with no coordination between them.

“No. I Have a Better Architecture.”

That was my exact response to the AI. And what followed was one of the most interesting dynamics of this entire build.

I didn’t just disagree with the AI’s fix. I redesigned the whole pipeline.

Here’s what I told it:

syncSnapshot becomes the parent — the single orchestrator for all lineup changes. Every action — whether it’s a roster toggle, a batting order drag, or a defensive position swap — flows through syncSnapshot as a pipeline with three stages:

Coach action (drag / toggle / activate)
  │
  ▼
syncSnapshot — the single orchestrator
  │
  ├─► MPCon (ManagePlayersController)
  │     Runs FIRST. Diffs the roster.
  │     "Monica Abbott just got deactivated."
  │
  ├─► BLCon (BattingLineupController)
  │     Runs SECOND. Reads MPCon's output.
  │     "Monica was batting 5th — close the gap,
  │      renumber 6→5, 7→6, 8→7..."
  │
  └─► DLCon (DefensiveLineupController)
        Runs LAST. Reads MPCon's output.
        "Monica was at Pitcher — she's inactive now,
         move the sub in. Only I write DefenseJson.
         No one else. Ever."
  │
  ▼
Write once → localStorage → SignalR push to DB
  │
  ▼
RenderMainBoard — rehydrate UI from the updated store

Stage 1: ManagePlayersController runs first. It checks what’s changed in the roster — who got activated, who got deactivated. It establishes the ground truth of who’s even available.

Stage 2: BattingLineupController runs next. It reads the roster state from Stage 1, looks at the batting order (which may have been reordered via drag-and-drop), and renumbers to fill any gaps. If a player was deactivated in Stage 1, the batting order closes the hole automatically.

Stage 3: DefensiveLineupController runs last. It reads the roster state from Stage 1, processes any defensive position changes, enforces the rules (one player per field position, swap logic), and builds the final DefenseJson. No other handler anywhere in the system is allowed to write DefenseJson. This is the single source of truth.

After all three stages complete, the system writes everything to localStorage, pushes to the database via SignalR, and rehydrates the UI.

One pipeline. One write path. No races.

The AI’s response?

“Good architecture.”

Then it asked me six clarifying questions — smart ones — about trigger timing, swap logic ownership, whether the old API endpoint should be replaced entirely, how the rendering layer should consume the results, and whether practice mode follows the same path.

I answered all six. The AI then produced a perfect diagram of the architecture, confirmed its understanding, and started implementing.

That’s the dynamic. The AI is an incredible implementer. It can take a well-defined architecture and execute it flawlessly across a dozen files in a fraction of the time it would take me. But it didn’t — and couldn’t — design that architecture. Not because it’s stupid. Because it doesn’t have the context. It doesn’t know that coaches switch between games constantly on their phones. It doesn’t know that a guest player might show up wearing the same jersey number as your starting pitcher. It doesn’t know that eventually I want parents watching a live scoreboard on a TV at the concession stand.

I know those things because I’m the coach. I’m the parent. I’m the guy who’s been at the field.

Why the Band-Aid Would’ve Come Back to Bite Me

Let me explain why the AI’s original fix — “just don’t call syncSnapshot from MainField” — would have failed down the road.

Under that approach, defensive changes would go through one code path, and batting/roster changes would go through another. Two separate write paths, two separate sets of assumptions, no guarantees about ordering or consistency.

Now imagine this: a coach deactivates a player from the roster (manage-players path) at the exact moment the scorekeeper swaps a defensive position (defensive path). Under the band-aid fix, those are two independent operations hitting the same snapshot with no awareness of each other. The deactivation writes ManagePlayersJson, and then the defensive swap writes DefenseJson — but DefenseJson still has the deactivated player at shortstop because the defensive controller didn’t know about the roster change.

With the unified pipeline, that can’t happen. The roster change flows through MPCon first, then BLCon, then DLCon — and DLCon already knows the player is inactive before it processes the defensive state.

This is what I mean when I say the AI can’t architect your system. It can identify a bug. It can propose a fix. But it can’t see the second-order consequences of that fix six months from now when your user base has tripled and coaches are making changes during live games while their phone signal drops in and out.

That requires judgment. That requires experience. That requires having been in the mess yourself.

The Uncomfortable Truth About “Vibe Coding”

There’s a trend right now — people calling it “vibe coding” — where you just keep prompting the AI until something works. No architecture. No planning. No understanding of what the code is actually doing. Just vibes. And you can thank Andrej Karpathy for that one. The irony is that he’s actually a damn good coder. But that’s what happens when your post about “coding with vibes” goes viral.

Look, I get the appeal.

It feels fast. And for a demo, a prototype, or a personal project that only you’ll ever use, maybe that’s fine.

But for anything real — anything that other people will depend on, anything that handles live data, anything that needs to work when the network drops or two users hit the same button at the same time — vibe coding is a time bomb.

The race condition I just described? That’s a vibe coding bug. Everything looks fine. The UI updates. The data saves. It only breaks when the timing is just wrong enough that two writes collide. You’d never catch it in a demo. You’d only catch it when a real coach, on a real field, switches games at exactly the wrong moment and sees two players at right field.

If you don’t understand what a race condition is — if you’ve never been taught about concurrent writes, atomic operations, or state management — you’ll never know why your app “randomly” loses data. You’ll blame the framework. You’ll blame the hosting provider. You’ll keep prompting the AI to “fix the bug” and it’ll keep applying band-aids to symptoms instead of addressing the architecture.

And I say this as someone who loves these AI tools and uses them every single day. They are genuinely incredible. But they’re tools. And a tool in the hands of someone who doesn’t understand the work is just a more efficient way to create problems.

The Wrong Team on the Wrong Screen

The race condition wasn’t the only invisible bug the AI created. Here’s one that was arguably scarier — because it was a data integrity issue that affected which user’s data showed up.

One night I’m testing multi-user flows. I log in as one test account — let’s call him Baker Mayfield, UserID 7. His team should load. His players. His roster. Instead, I’m looking at 28 players that belong to a completely different account — UserID 3, a dev test account I’d been using earlier.

I check localStorage. Sure enough, the stored team ID doesn’t match the logged-in user. The AI had set up localStorage with generic keys — just a flat teamId and settings — with no namespacing per user. So when I logged in as a different user in the same browser, the old user’s data was still sitting there. The app saw a valid team ID in storage, loaded it, and never questioned whether it belonged to the person actually logged in.

This is the kind of bug that works as long as you only ever test with one account. The moment a second user touches the same browser — or you’re a developer switching between test accounts, which you do fifty times a day — everything looks fine but the data is wrong.

I told the AI: there should be exactly three keys in localStorage, and they need to be scoped per team and per user:

team_[TeamID]_user_[UserID]_bbentities   (TTUUB)
team_[TeamID]_user_[UserID]_settings     (TTUS)
currentUser_[UserID]                     (CUID)

That’s it. They sit side by side, each one namespaced to its owner. When a different user logs in, their keys are separate. No cross-contamination. No loading Baker Mayfield’s screen with someone else’s roster.

The AI didn’t design this namespacing. It built a flat storage scheme that worked for one user and silently broke for two. I caught it because I was actually testing the app the way real people would use it — switching accounts, sharing a device, logging out and back in. The AI never simulated that.

Same Browser, Two Environments, One Nightmare

While we’re talking about invisible bugs: here’s a lesson that cost me an entire evening and has nothing to do with code quality.

If you’re running a containerized development environment and a production environment — do NOT use the same browser for both. And definitely don’t use the same email addresses.

I was testing on localhost:5173 (local dev) and api.benchboard.org (production). Same browser. Same test email. Both environments issue JWT tokens. And JWT tokens live in the browser.

So what happens? I visit production, get a valid production token. Switch to localhost, the token is still there. The local frontend sees a “valid” token and lets me in — but the token is for the wrong environment. Everything looks logged in. Some API calls work because the token hasn’t expired yet. Others silently fail with 404s instead of 401s because the production endpoints have changed.

I spent an evening debugging what looked like a broken API. It wasn’t broken. I was authenticated against the wrong server with a stale token from a different environment.

The fix is stupidly simple: use Chrome for dev, Firefox for production. Or use separate browser profiles. The AI will never tell you this because it’s not a code problem — it’s an operational problem. It’s the kind of thing you only learn by doing it wrong at 11 PM on a Tuesday.

When You Know Exactly Where to Point the AI

I’ve been hard on the AI in this article, so let me show you the flip side — a moment where knowing my own codebase turned the AI into a surgical instrument.

I had a layout bug in the scoreboard. In demo mode, the inning scores, the R/H/E table, the ball-strike-out count, and the base diamond were all shifted to the right — overlapping, overflowing, completely broken. But when I logged in as a real user, everything rendered perfectly.

Now, if I didn’t know what I was looking at, I’d prompt the AI with something vague like “the scoreboard looks broken in demo mode, fix it.” And the AI would start guessing. It might rewrite the whole grid. It might restructure the component. It might introduce five new bugs while fixing one.

Instead, here’s what I did. I opened the browser’s inspect element. I found the CSS class on the broken section: rounded-tl-md rounded-bl-md overflow-hidden. I searched my codebase for that class to identify the exact file and line number. I noticed that the code was well-commented — each section marked with === Inning Score Table ===, === R / H / E Table ===, === B / S / O Count ===. Then I gave the AI this prompt:

“Can you take a look into ‘DEMO MODE’ under Scoreboard-v4-desktop.jsx? Just under that mode, the Inning Score Table, R / H / E Table, B / S / O Count and Base Diamond are all over the place. But when I’m logged on it displays fine. Start here @Scoreboard-v4-desktop.jsx#L101-106 and make your way to the rest of the code and tell me what you’ve found @Scoreboard-v4-desktop.jsx#L108-341”

Specific file. Specific line numbers. Specific symptom. Specific scope.

The AI came back in seconds with the exact root cause: a <Show> block was rendering an empty <div /> inside a CSS grid container. In demo mode, that empty div occupied a grid column slot, pushing every table one column to the right. In logged-in mode, the same block rendered an absolutely-positioned overlay that didn’t participate in grid flow — so the layout was fine.

The fix? One line:

BEFORE: <div />
AFTER:  <div class="absolute" />

That’s it. One CSS class. The entire scoreboard snapped back into place.

The lesson isn’t that the AI is smart — it is, but so is a chainsaw. The lesson is that when you know your codebase well enough to point the AI at the right ten lines instead of the whole file, it becomes terrifyingly efficient. The people who are “vibe coding” — just throwing the whole problem at the AI and hoping — they’d never get this result. They’d get a rewrite of the entire component that introduces three new bugs.

You have to know where to aim.

Where AI Shined in This Story

I want to be fair here, because the AI absolutely earned its keep in this refactor.

Once I defined the architecture — the pipeline, the stages, the write paths — the AI implemented it across the entire codebase in a fraction of the time it would have taken me alone. It traced every file that needed to change. It found every broadcast location that needed retargeting. It updated the backend controllers, the frontend store, the SignalR client, and the UI components in a coordinated sweep. Then it committed the changes with a detailed message that documented exactly what changed and why.

That’s what I mean by “accelerator.” The thinking was mine. The execution was a partnership. And the result was better than either of us could’ve produced alone — me because it would’ve taken me days to touch that many files manually, and the AI because it never would’ve designed the pipeline in the first place.

Next up — Part 3: “The Feedback That Changed Everything.” I’ll tell you about the moment real coaches — people who found BenchBoard through search and started using it without being asked — told me the truth: “It’s a nice toy, but it needs data.” That feedback meant I had to build an entire live scorekeeping engine on top of what I already had. Essentially a second app. And the decision to do it terrified me.

If you're following this series and it's resonating — subscribe. Part 3 is the turning point where BenchBoard stopped being a side project and became something real.

I’ve been building BenchBoard since November, but the truth is the planning started way back in July. What began as a clean, exciting idea — a team management and scorekeeping app for youth baseball and softball — slowly evolved into a full-blown beast. The kind of beast you don’t fully understand until you’re already riding it downhill with no brakes.

And here’s the part I didn’t expect: using LLMs made the journey both faster and way more chaotic.

If you’ve spent any time on tech Twitter or LinkedIn, you’ve seen the posts. “I built a SaaS in a weekend with AI!” “No-code to $10K MRR!” I’m not here to tell you those people are lying. Maybe they built something. But I’d bet my last Docker container it wasn’t handling live scorekeeping for a 12U softball game where a guest player shows up wearing the same jersey number as your starting shortstop.

This series is for the people who want the real version of the story.

The First Big Lesson: Never Fully Trust the AI

When I started, I leaned heavily on ChatGPT. At the time, it felt like a superpower — instant architecture suggestions, instant code, instant explanations. But LLMs evolve fast. What they tell you in July isn’t what they tell you in November. And what they tell you in November isn’t what they tell you in January.

I learned the hard way that if you let the AI dictate how your system should operate, you’ll end up rebuilding major chunks of your app over and over. That happened to me more than once. Not because the AI was “wrong,” but because it doesn’t understand the full context of your system, your constraints, your users, or your long-term vision.

It’s confident. It sounds right. But it doesn’t know.

Here’s a simple example. Early on, I asked the AI how to structure my data layer — how teams, players, games, and lineups should relate to each other. It gave me a clean answer. Three separate tables for managing players, batting order, and defensive positions. Looked great on paper. Months later, I realized those three tables needed to be one — a single LineupSnapshot that holds everything atomically. The AI’s original suggestion wasn’t wrong for a textbook exercise. But it was wrong for a real app where a coach is juggling lineup changes on their phone while kids are warming up on the field.

That refactor took days. Not because the code was hard to write — the AI helped me rewrite it fast. But because the decision to consolidate those tables required understanding how coaches actually use the app mid-game. No LLM has that context. I did, because I’ve been that coach.

The Scope Problem (AKA: The Monster I Created)

Another mistake: I didn’t properly scope what I was building early on. Every time I solved one problem, I discovered three more. Every time the AI suggested a “better” approach, I’d rethink the architecture. Before long, the scope ballooned.

Let me give you a taste of what I mean. Take something that sounds simple: “Let the coach enter the opposing team’s lineup before a game.”

Sounds like a form with some text fields, right?

Here’s what it actually requires:

• How do you split a full name into first and last when someone types “Mary Jo Smith”?

• How do you deduplicate players when jersey numbers aren’t reliable because guest players rotate in and out?

• Should the coach pick from a dropdown of known opponent players, or type fresh names every game?

• If a coach corrects a player’s name mid-game during scorekeeping, does that correction propagate back to the opponent’s player record for future games?

• What happens when a player is removed from the lineup — do you delete the player record entirely, or just remove them from the game?

• What about prefilling positions from the last time you played this team?

• What about jersey number conflicts — two rows with #7?

That’s one feature. And we haven’t begun put the damn code in yet! I had a vision of doing a cool drag-and-drop feature for the batting order that would be extremely helpful for coaches - but you also need to think of what happens when the lineup changes before a live game start. What happens when David or Grace shows up last minute to play? Every single one of those gaps was something I identified through domain knowledge — from standing on actual fields, watching actual coaches fumble with clipboards and group texts.

The AI never surfaced a single one of those edge cases on its own.

Not one.

Eventually I had to force myself to define a hard cutoff — a line where I’d stop adding, stop rethinking, and start shipping. That discipline didn’t come naturally. It came from pain.

What the AI Actually Fixed (And It’s Not Nothing)

I don’t want to sound like I’m bashing AI tools. I’m not. They fundamentally changed how I work, and I wouldn’t go back.

Here’s what shifted. For the first 35-plus years of my career, when I hit a wall — a syntax issue, a connectivity problem, a framework quirk — I’d open a browser and start searching. Stack Overflow. Blog posts. GitHub issues. Sometimes I’d spend 45 minutes just figuring out the right search query to describe what I was dealing with. Then I’d read through six different answers, figure out which one applied to my specific stack, adapt it, test it, and move on.

That entire workflow is mostly gone now. The LLM handles the tedious stuff — the boilerplate, the syntax lookups, the “how do I connect X to Y” problems — in seconds. It’s like having a junior developer who has read every documentation page ever written, sitting right next to you, never getting tired. But this developer doesn’t know everything - only what you tell it to do.

And here’s the thing nobody tells you about that time savings: it doesn’t make your project smaller. It makes you faster at discovering how big your project actually is.

All that time I used to spend on Stack Overflow? Now I spend it on architecture decisions, domain logic, and scope management.

The boring problems got automated.

The hard problems got exposed.

And the hard problems are harder — because no AI can make those calls for you.

Programming Knowledge Still Matters — A Lot

We live in a world where people genuinely believe you can build a production app without deep programming knowledge. And honestly, you can build something. You can get a landing page, a database, some API routes, maybe even a working prototype. Take a few minutes on Starter Story and you’ll see developers and normies put up stuff quickly when comes to solving quick problems and honestly, I have no issues with those guys. More power to you.

But if you’re building something complex — something that will eventually serve hundreds or thousands of real users in real time — you still need to understand how systems behave. How databases work. How entities relate. How state flows across web and mobile. How APIs communicate. How your customers will actually use the thing.

LLMs can generate code, but they can’t architect your system for you. They can’t foresee the scaling issues. They can’t understand the nuance of your domain. They can’t tell you when something “feels wrong.”

That’s your job.

And if you don’t understand what the LLM is doing — or why — you’re flying blind. And that’s a big one many new programmers and so-called vibe coders romantically fall hard on.

I’ve seen the AI confidently generate code with race conditions baked in, where two different parts of the system were writing to the same database record simultaneously, and whichever request finished last would silently overwrite the other. If you don’t know what a race condition is, you’d never catch it. You’d just wonder why your app randomly loses data. Copying and pasting that log over and over to the LLMs chat box won’t bail you out.

That’s not a hypothetical. That happened to me. And I’ll tell you the full story in Part 2.

Where This Leaves Me Now

BenchBoard has grown into something far bigger than I expected. It’s been frustrating, hilarious, exhausting, and incredibly rewarding. I’ve rebuilt parts of it multiple times. I’ve learned more in the last several months than I expected to learn in a year.

But the biggest takeaway?

AI is an accelerator, not a replacement. It can help you move faster, but only if you know where you’re going.

And if you don’t — it’ll happily lead you into a ditch with a smile.

Next up — Part 2: “The Architecture the AI Couldn’t See.” I’ll walk you through the night the AI built a race condition into my live scorekeeping system - full code and everything. It confidently proposed a band-aid fix and I had to stop everything and redesigned the entire data pipeline myself.

It’s the story that made me realize: the AI is a great passenger, but you’d better not let it drive.

If this resonated with you — whether you’re a fellow builder, a developer who’s been in the game for decades, or someone just curious about what building real software actually looks like behind the curtain in today’s AI-driven world — subscribe. This is a five-part series, and it only gets more real from here.