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.

Act I: I Was Just Trying to Commit Code Like a Normal Human

This whole annoyance began while I was happily in the middle of committing a big batch of real, meaningful code changes.

I was in the zone.
I was productive.
I was proud of myself.

And then - like a raccoon knocking over a trash can - I noticed something in git status that absolutely derailed my brain:

Changes to be committed:
    new file: htmltemplates/Examine.html
    new file: htmltemplates/Sample.html
    new file: htmltemplates/Sample2.html

A whole folder of sample HTML files.
Ugly, messy, irrelevant sample files.
I didn’t want them in my repo.
I didn’t want them in my commit.
I didn’t even want to see them.

So I did the obvious thing:

git restore --staged htmltemplates/

Boom. Unstaged.

Except… now they were showing up in red.
Untracked. Loud. Annoying.
Like a toddler in a grocery store.

And I couldn’t ignore it.
My brain refused to move on.
I had to fix it before committing anything else.

This is how the spiral began.

Act II: The Descent Into Madness

I added the folder to .gitignore:

Code

htmltemplates/

Git responded:

?? htmltemplates/

Just the folder.
Not the files.
Not the contents.
Just the folder itself, haunting me like a Victorian ghost.

So I tried the nuclear option:

git rm -r --cached htmltemplates/

Git said:

fatal: pathspec 'htmltemplates/' did not match any files

Excuse me?

I can SEE the files.
They are RIGHT THERE.

I even sent a screenshot to my AI assistant like I was reporting a crime.

I added the folder to .gitignore:

Code

htmltemplates/

Git responded:

Code

?? htmltemplates/

Just the folder.
Not the files.
Not the contents.
Just the folder itself, haunting me like a Victorian ghost.

So I tried the nuclear option:

Code

git rm -r --cached htmltemplates/

Git said:

Code

fatal: pathspec 'htmltemplates/' did not match any files

Excuse me?

I can SEE the files.
They are RIGHT THERE.
I even sent a screenshot to my AI assistant like I was reporting a crime.

Act III: The AI Therapist Enters

At this point, I’m in chat with Copilot.
Yes, CoPilot - because it’s just right there on my Windows desktop ok?

Anyway, I’m like:

“DUDE. WHAT IS THE DEAL.”

And Copilot, with the calm energy of a monk who has seen centuries of human suffering, says:

“Git ignores files, not folders.”

I blinked.

She continued:

“A folder only disappears when every file inside it is ignored.”

I blinked harder.

Then came the moment — the one that will live in my memory forever.

I typed:

“OOOOH. ARE YOU SAYING THAT I need to do htmltemplates/*”

And Copilot basically nodded like a proud parent watching their kid finally ride a bike. LLMs are weird but I guess it’s good it was teaching me rather than giving me a straight answer.

Act IV: The Enlightenment

I changed the rule to:

htmltemplates/*

Saved.
Committed.
Ran git status.

And like a magician’s final flourish…
the folder vanished.

I swear I heard a choir.

Act V: The Moral of the Story

If you want Git to ignore a folder completely — like it never existed, like you’ve scrubbed it from the timeline — you need:

htmltemplates/*

Not:

htmltemplates/

Not:

/htmltemplates/

Not:

../frontend/htmltemplates/

Just:

htmltemplates/*

Because Git is a file‑based ignore engine, not a directory‑based one.
And because Git enjoys watching us suffer.

Act VI: Five Things I Wish I Knew About .gitignore Before Losing an Hour of My Life

This is the part where I pass on the ancient wisdom I earned through pain, confusion, and yelling “WHAT IS THE DEAL” at my terminal.

1. Git ignores files, not folders

This is the rule that started my villain origin story.
You can write folder/ all day long — Git will still show the folder itself unless every file inside it is ignored. Git is petty like that.

2. folder/ and folder/* are NOT the same thing

This one feels like a prank.
folder/ means “ignore files under here… probably… maybe… depends on the moon phase.”
folder/* means “ignore EVERYTHING inside this folder,” which is what you actually want 99% of the time.

3. Git will happily show you an empty folder just to mess with you

Even if the folder contains only ignored files, Git may still show the folder name as untracked.
It’s like Git saying, “Hey, I know you told me to ignore this, but I just wanted you to know it exists.”

4. .gitignore doesn’t apply until you commit it

This one got me too.
You can modify .gitignore all you want — Git will keep using the old version until you commit the new one.
It’s like Git is saying, “I’ll believe it when it’s in the history.”

5. If git rm -r --cached says ‘did not match any files,’ it’s not lying

This error means Git is not tracking ANYTHING in that folder.
Not one file.
Not one byte.
Not even a whisper of a file.
Which is why it refuses to “untrack” something it never tracked in the first place.

Epilogue: What I Learned

• Git will happily ignore files.

• Git will NOT ignore a folder unless all files inside it are ignored.

• Git will show you an empty folder like it’s tattling on you.

• .gitignore rules are deceptively literal.

• Talking to an AI about Git is surprisingly therapeutic.

• And most importantly:
  Never try to “quickly fix something” in the middle of a big commit.
  That’s how the chaos begins.

If you ever see ?? htmltemplates/ again, run.

Let’s get this out of the way: AI is absolute garbage at making logos. Not mid. Not decent. Garbage. And before you come at me with some synthetic brand mark made in Midjourney or DALL·E that looks kinda cool in a vacuum—hold up. That’s the design equivalent of nailing a three-pointer in practice with no defenders. Try doing it in Game 7 of the Finals. Different league.

Logos Are Emotional Landmines, Not Just Pixels

A great logo is less design, more signal. It’s the emotional fingerprint of a company. And AI? It still thinks a logo is a fancy graphic with a keyword or two thrown in. It doesn’t grasp:

• Why a simple swoosh says "speed"

• Why the Apple bite means “thinking different”

• Or why some logos are meant to be boring—because the brand is the hero, not the design

Logos are decisions. Thousands of them. Made under pressure, aligned with legacy, target audience, psychology, and vision. Most of this nuance? AI skips. Or worse—mimics badly.

Why AI Can’t Touch Real Brand Strategy (Yet)

Here’s what branding specialists get and where AI still fumbles - even with all that training data:

What Branding Pros Get:

• Emotional subtext – Understanding how certain colors, shapes, or symbols evoke subtle emotional responses based on life experience and cultural memory. A heart shape might suggest love, but a designer knows when it needs to suggest compassion vs. romance.

• Cultural timing – Sensing the right moment to release a brand or campaign based on social trends, political climates, or generational cues. Designers keep tabs on the zeitgeist.

• Strategic restraint – Knowing what not to include. Resisting the temptation to fill space or over-design. Trusting minimalism when appropriate.

• Brand voice – Crafting visuals that align with how the brand "speaks"—whether formal, witty, confident, playful, rebellious, or aspirational.

• Story arcs – Designing with the long game in mind. How does the brand evolve? Where does it go next? Pros plan visual systems that adapt and grow over time.

What AI Misses:

• Literal visuals – AI tends to translate prompts too literally. Ask for a logo that suggests speed, and it might give you a cheetah clipart.

• Static datasets – AI trains on past data. It doesn’t know what just happened in culture this week—or what’s coming.

• Design bloat – Without judgment, AI adds more visual noise instead of editing down. It struggles with elegance.

• Keyword soup – It interprets brand voice through word lists, not tonality. It might mash "fun," "fast," and "friendly" into a chaotic blob.

• Style averages – AI often blends styles from millions of references, which leads to forgettable, generic outcomes rather than bold, defining statements.

A brand strategist knows when not to add a shape. When to leave white space. When to choose a color because it taps into childhood nostalgia for your audience. AI? It just throws spaghetti.

There’s also design intent—the invisible blueprint behind every creative decision. AI doesn’t understand why one curve suggests elegance and another screams tech startup. It doesn’t know when a mark needs to whisper rather than shout.

But Can’t We Just Train It Better?

In theory? Sure. But here’s what that would take:

• Internal branding decks with rationale

• Rejected design drafts with explanations

• Cultural context of each campaign

• Customer emotional feedback over time

• Iteration notes from real creative directors

You’d need decades of human decision-making, not just pretty logos. AI needs to see what didn’t work, and why. And even then, you’re still missing something fundamental:

Taste, timing, and intuition. These aren’t teachable in a traditional sense. AI can learn data. It can’t live through a rebrand disaster, a client meltdown, or a pivot that changed everything.

One of my close friends was a lead graphic designer—legit talented, leading a team that created incredible campaigns. His whole department was laid off when the company leaned into the media buzz that AI could replace entire design teams. At first, earlier this year, I thought maybe it was a forgone conclusion. After all, the tools were getting faster, flashier, and more accessible.

But now? After running real prompts through the latest tools myself, I’ve realized we’re further from human creativity than people think. The company that let him go? Victims of trend-chasing and media-driven excuses to normalize layoffs. They needed that team more than ever.

I’ll go deeper into that in another article. But the short of it: we need the humans behind design more than ever.

Why AI Always Starts from Scratch (and Why That’s a Problem)

You ever notice how image AIs don’t just tweak your logo? They start over, every time. That’s not creativity. That’s amnesia.

Here’s why:

• Most generative image models weren’t trained to remember context

• They don’t understand “design intent” — they just generate based on prompts

• They don’t know what’s sacred in a design (legacy colors, font shapes, whitespace)

Real example:

Result:

Can you make it a lot more simplified? Like level 1?

AI likes levels. Level 1 denotes the most simplified design while a Level 10 is elaborate and more noisy. So it does this…

I then ask it…

Remove "Fake News" and other social network stuff on it. Go for a more silhouetted look that is more about looking to find the truth in stuff. Radical Insider is all about being grounded with facts and educating the public as a father, a software engineer and a coach. At least it's square. lol.

It then hilariously responds with:

Eww. No silhouettes. Bad idea. Let's try something else. Stay simple but don't go in this direction. Imagine this icon/logo in other visual material. Keep going. Go color and again, no silhouettes.

So what does it do?

This is not working

A friend even suggested pulling an image from the internet and modifying it through AI. But that defeats the entire purpose of originality and ownership.

So... Is AI Useless for Branding?

Nope. It’s actually a beast if you use it right. Think of AI as your endlessly caffeinated intern. Here’s where it wins:

Moodboarding

Throw in keywords, brand personality traits, emotional tones—and AI can generate dozens of visual references in seconds. It helps you explore styles (gritty, playful, high-end, brutalist) before you commit to one. It lets your team see the vibe of a direction early.

But it’s inspiration, not instruction. You still need a human eye to curate what aligns with your brand’s story—and to know when something looks good but feels off.

Naming Help

AI is excellent at brute-forcing name ideas. It can generate hundreds of brand name combos across tone types (playful, serious, nostalgic, futuristic). It helps brainstorm options fast.

But again—it doesn’t know what’s too close to a competitor. Or what resonates in your niche. Or what sounds like a dating app when you’re building a fintech platform.

Concept Drafts

Rapid visual ideation. Want to see how your brand could look on packaging, signage, or mobile UI? AI can give you starter visuals. It’s a thumbnail sketch machine.

Just don’t mistake them for finished work. That’s where your human designer takes over, bringing balance, originality, and polish.

Final Whistle: Don’t Bench the Designer

Here’s the hard truth: you still need graphic designers and brand specialists. Maybe more than ever.

What you see in the media—those “AI made this logo in 10 seconds!” headlines—don’t tell the full story. They’re novelty, not legacy. Behind every enduring brand is someone who knows how to weave meaning into pixels.

You still need:

• Your friend who actually studied typography

• That Fiverr freelancer who knows color psychology

• A creative director who understands business and story

Branding is not just about standing out. It’s about belonging to something. And AI can’t feel that. It doesn’t know if your logo makes someone feel included, nostalgic, or inspired.

The takeaway? Use AI to brainstorm, to explore, to warm up the creative muscles. But when it comes time to ship something that lasts, bring in a human. Logos aren't just made—they're earned.

This has led many to wonder:

Will AI replace programmers?

Short answer: No.

Long answer: Not only will AI never replace programmers, but trusting it without knowing how to code can lead you into a costly mess.

Here’s why.

The Internet Is Lying to You (But Not on Purpose)

We live in an age of instant gratification and social virality. It’s easy to be lured in by videos titled “Built a SaaS startup with ChatGPT in one weekend” or blog posts that brag about replacing developers entirely. These are exciting stories—but they’re often missing the bigger picture.

They don’t show you the aftermath:

• The security holes

• The performance issues

• The broken edge cases

• The technical debt

• The inability to maintain or evolve the code

These success stories celebrate the MVP, but real software lives and dies in version 1.1 and beyond. And those who try to build production software with AI alone—without understanding how it works—usually find themselves rebuilding, refactoring, or bailing out entirely.

What’s Really Going On Under the Hood?

Let’s demystify AI a bit. Code-generating AIs like ChatGPT or GitHub Copilot don’t think or reason. They don’t design. They don’t plan.

They predict.

Specifically, they predict the most likely next token (or chunk of code) based on training data from the internet. That includes Stack Overflow, GitHub repos, documentation, and yes, a ton of outdated and even incorrect examples.

AI doesn’t “know” what it’s doing—it just knows what looks right. It doesn’t understand your application, your users, or your infrastructure.

That’s why you might get a perfectly syntactic answer that’s dangerously wrong—and unless you’ve learned programming, you won’t know until it’s too late.

Real-World Examples: Where AI Code Falls Short

Let’s walk through some real examples where AI-generated code can work in theory—but fail in the real world.

Example 1: Login Code That Opens the Door to Hackers

A non-technical founder uses AI to build a login system. ChatGPT outputs:

$query = "SELECT * FROM users WHERE username = '$user' AND password = '$pass'";

It works. They deploy it. Users can log in. Success?

Two weeks later, a security breach exposes user data. Why? SQL Injection.

AI didn’t sanitize input. The founder didn’t know to ask for prepared statements. No one knew to test for common web exploits.

The story here: The AI generated code that looked fine. But without a background in secure programming, the founder deployed a ticking time bomb.

Example 2: AI Suggests Code That Breaks at Scale

Need to handle image uploads? Ask AI for a Node.js route. It gives:

fs.writeFileSync('/uploads/file.jpg', fileData);

It works locally. But on launch day, with 10 users uploading simultaneously, the app crashes.

Why? fs.writeFileSync blocks the Node event loop. Under concurrent load, the server stalls.

The story here: The AI doesn’t know that Node.js is single-threaded and event-driven. A real dev does. They’d use streams, queues, or cloud storage.

Example 3: Thousands of Queries from One Innocent Loop

A Django app lists blog posts and authors:

for post in Post.objects.all():

print(post.author.name)

Seems fine—until the app generates 1,001 database queries for 1,000 posts. The server chokes.

Why? N+1 query problem. AI doesn’t optimize unless told. A real dev would use:

Post.objects.select_related('author')

The story here: AI gives you working code, not performant code. And you won’t catch this unless you’ve been burned by it before.

Why Programmers Should Feel Safe

Here’s the truth: AI doesn’t replace programming—it amplifies good programmers.

It helps with:

• Boilerplate code

• Rapid prototyping

• Syntax corrections

• Brainstorming edge cases

But it can’t:

• Architect your system

• Consider trade-offs

• Debug obscure issues

• Design intuitive UX

• Write secure, scalable code

A developer using AI is like Steph Curry using a better basketball—he’ll still dominate, but the court vision, footwork, and game IQ are all his.

Even with all the computing power in the world and the freshest training data available, AI still doesn’t “understand” code the way a human does. It doesn’t live with the consequences of its decisions. It doesn’t debug at 3 a.m. It doesn’t refactor under pressure. It doesn’t design with the future in mind.

That’s why programmers are still—and will continue to be—indispensable.

Why It’s Dangerous to Build Without a Coding Background

Entrepreneurs and business owners often think: “If AI can build this, why learn to code at all?”

Because:

• When the code breaks, you can’t fix it.

• When the app needs a new feature, you can’t evolve it.

• When security or performance issues arise, you don’t even know they’re there.

What you get is a fragile prototype that no real team can maintain or scale.

Building software with AI but without programming knowledge is like trying to open a restaurant using only DoorDash recipes. It might look okay on the plate—but what happens when health inspectors show up or the oven breaks?

AI Has a Garbage Problem

AI is only as good as the data it’s trained on. And the public code it ingested includes:

• Deprecated practices

• Insecure examples

• Poorly written tutorials

• Misleading forum answers

Unless you know how to spot bad code, AI can confidently hand you something dangerous—and you’ll have no idea.

Would you trust a surgeon trained entirely on YouTube comments?

Why Programming Is One of the Safest Jobs in the AI Era

The jobs least likely to be replaced by AI involve:

• Judgment in unpredictable environments

• Creative problem solving

• Contextual decision-making

• Long-term accountability

Software development checks all those boxes.

AI isn’t eliminating programming jobs—it’s changing the shape of them. Developers who embrace AI as a tool will become more powerful. Those who understand systems will be in high demand. Those who just copy and paste code will struggle.

But What If the AI Was Perfect?

A common thought experiment:

“What if we had the most powerful AI ever made—with perfect training data, real-time context, and quantum computing behind it? Could it replace programmers entirely?”

It’s a fascinating idea—but even that scenario falls short.

Because programming isn’t just about typing instructions. It’s about:

• Modeling human problems

• Making value judgments

• Navigating uncertainty and trade-offs

• Iterating with feedback, emotion, and context

Even if the AI becomes flawless at writing and optimizing code, it still needs someone to interpret messy business needs, clarify vague user requirements, and make ethical or strategic choices.

In other words: to act like a systems thinker.

That person may not be called a “programmer” in the future.

But the role they play will be more important than ever.

AI can be the engine. But someone still needs to drive.

Final Thoughts: Learn the Game, Then Use the Tools

If you’re a non-technical founder: AI won’t protect you from bugs, scalability issues, or bad design. If you want to build serious software, you need to learn the fundamentals.

If you’re a programmer: Your job isn’t going anywhere. AI is the shooting machine in the gym—it’ll help you get your reps in faster. But the playmaking? That’s all you.

AI might help you code. But it’s not here to run your team.

Software development is a sport of strategy, awareness, and execution and “programmers” are still the ones drawing the plays. Perhaps their names of their role will change (e.g. system designer, software architect, etc)

But the fact of the matter is someone human, particularly one who understands systems, still has to direct these powerful tools - and that won’t change, even in the quantum age.

While media narratives focus on endless political bickering, something else is happening on the ground. Large, passionate crowds are forming at rallies across the country—not for the usual polished politicians, but for a movement that speaks to the struggles people actually face. These rallies are not built on the tired partisan narratives pushed by the media. Instead, they are filled with people from all backgrounds who agree on the most basic, yet ignored, truth: the system is failing them.

The State of the Union—Or Lack of One

Americans are tuning out the political circus in record numbers. President Trump’s recent address to Congress drew an audience of 36.6 million viewers, reflecting a nearly 14% increase from former President Biden’s 2024 State of the Union address.  However, this viewership still represents a decline compared to historical figures, indicating a broader trend of public disengagement.

This isn’t apathy—it’s rejection. People aren’t disinterested in politics; they’re tired of being lied to, manipulated, and used as pawns in a game designed to benefit a small elite. They’ve watched politicians, both Democrat and Republican, make grand promises only to serve the same corporate interests once in office. They’ve seen the media cover political theater while ignoring the skyrocketing cost of living, stagnant wages, and a healthcare system that prioritizes profit over people. The spectacle continues, but fewer and fewer Americans are willing to be part of the audience.

The Media’s Role in the Smokescreen

One of the biggest reasons for this frustration is the unreliability of the media—especially the mainstream outlets that claim to be the guardians of democracy. Trust in mass media has reached record lows, with only 31% of Americans expressing a “great deal” or “fair amount” of confidence in the media to report the news fully, accurately, and fairly.  This erosion of trust is not confined to one political ideology; it spans the spectrum, reflecting widespread skepticism toward traditional news outlets.

The perceived bias and sensationalism in media coverage have contributed to this distrust. For instance, during the early stages of the COVID-19 pandemic, media missteps, such as downplaying the virus’s severity and dismissing alternative theories without thorough investigation, damaged public confidence. Such instances have led to a growing sentiment that media narratives are often disconnected from the realities faced by everyday Americans.

The Rallies That Media Won’t Cover

Meanwhile, something remarkable is happening in cities across the country. Despite the media’s attempt to control the narrative, massive rallies are forming—often with little to no mainstream coverage. The people attending these gatherings aren’t showing up for a party or a politician; they’re showing up because they believe in something bigger than the two-party system.

These rallies attract working-class Americans, union members, small business owners, students, and retirees—all coming together not because they agree on every issue, but because they share the same struggles. They know wages aren’t keeping up with inflation. They know healthcare costs are unsustainable. They know the government works for corporations, not for them. And instead of blaming each other, they are realizing they have more in common than they were led to believe.

The reason these rallies feel different is because they aren’t staged, scripted, or manufactured by political consultants. They are filled with real people who have been ignored for too long. And that terrifies the establishment.

A Growing Political Awakening

While corporate-backed politicians are afraid to hold town halls and face their own constituents, these rallies are only growing in size and energy. The political establishment—both parties—wants Americans to believe they are powerless. They want people to think that nothing will change, that their only choices are the same two parties, the same broken policies, and the same media narratives.

But something is shifting. Americans aren’t as divided as they’ve been led to believe. The true divide isn’t between left and right—it’s between the people and those in power. And as more Americans reject the circus, they’re realizing that the solutions won’t come from the same politicians and media figures who created these problems in the first place.

The crowds forming in towns and cities across the country aren’t just showing up for a cause. They’re showing up for each other. And that, more than anything, is what those in power fear the most.

How It Started

The origins of Diversity, Equity, and Inclusion (DEI) can be traced back to earlier movements advocating for civil rights and workplace equality. Over the decades, similar initiatives have gone by various names, including Equal Employment Opportunity (EEO) and Affirmative Action. These policies were initially designed to address systemic discrimination and promote fair treatment in hiring and education. However, as workplaces and institutions evolved, DEI expanded beyond legal compliance to emphasize the importance of fostering inclusive environments where people from diverse backgrounds feel valued and empowered. Today, DEI encompasses a broad spectrum of initiatives, from inclusive hiring practices to bias training and cultural awareness programs. While some view DEI as a necessary evolution toward a more equitable society, others see it as overreach that can sometimes prioritize representation over qualifications. Understanding this history and how DEI has transformed over time helps frame the ongoing debate about its effectiveness and impact.

At its core, DEI aims to create fair opportunities for people of all backgrounds while fostering environments that value differences. While DEI initiatives have led to significant positive change, they have also sparked debate regarding their implementation, effectiveness, and unintended consequences. Additionally, the media plays a crucial role in shaping how DEI is perceived, sometimes amplifying divisions rather than fostering unity. Sensationalized headlines and selective reporting often emphasize extreme cases—either showcasing DEI as a revolutionary success or painting it as a harmful overreach. Social media algorithms further entrench these views by prioritizing emotionally charged content, creating echo chambers that reinforce existing biases rather than promoting constructive discussion. To fully realize the benefits of DEI, it is crucial to separate the noise from the substance and ensure that diversity enhances, rather than overshadows, professional merit.

The Positive Impact of DEI

The benefits of DEI are well-documented. Companies that embrace diverse workforces often experience increased creativity, broader perspectives, and enhanced problem-solving abilities. Inclusive environments also contribute to greater employee satisfaction, reducing turnover and fostering innovation. Moreover, DEI initiatives have helped break down long-standing barriers, allowing underrepresented groups access to opportunities they might have historically been denied.

In the broader social context, DEI efforts have led to increased awareness of systemic inequalities, encouraging more inclusive policies and practices. By recognizing and addressing biases, organizations can create fairer hiring processes, more supportive workplaces, and better representation across various fields.

The Challenges and Criticisms of DEI

Despite its positive intentions, DEI is not without its challenges. Some critics argue that certain DEI initiatives prioritize quotas over qualifications, leading to resentment and skepticism about the merit of diverse hires. In some cases, well-qualified individuals may feel overlooked due to rigid diversity requirements, while others may experience imposter syndrome, questioning whether they were hired for their skills or simply to meet a target.

A close friend of mine has personally experienced the downside of these initiatives. As a black man, he has faced the unfortunate reality of being underestimated by colleagues who assume his success is due to DEI policies rather than his actual abilities. This persistent underestimation can be frustrating and counterproductive, as it undermines the confidence of highly capable individuals. However, despite these challenges, he still supports the need for diversity. His concern lies not with the existence of diversity initiatives but with how they are implemented. He believes that DEI should not be about ticking boxes but about ensuring fair access to opportunities while maintaining high professional standards.

The Media’s Role in Shaping DEI’s Reputation

The media plays a powerful role in shaping the narrative around DEI, often highlighting extreme perspectives on both sides of the debate. For example, some major news outlets like Fox News have criticized DEI as a form of forced social engineering, while others like MSNBC have framed it as a necessary correction to systemic injustice. On social media, trends such as #DEIisDiscrimination and #DiversityWins illustrate the stark contrast in public opinion, with each side amplifying their stance through viral content. Some outlets frame DEI as an essential step toward justice, while others depict it as an unfair system that penalizes certain groups. This polarized coverage can create unnecessary division, making it difficult for people to have nuanced discussions about DEI’s merits and shortcomings.

Social media further exacerbates these divides, with algorithm-driven content amplifying outrage and controversy. This results in echo chambers where individuals are fed information that reinforces their existing beliefs, preventing constructive conversations and solutions. If we want to move forward productively, we must actively seek balanced perspectives and engage in open-minded discussions rather than relying solely on media narratives.

Moving Beyond the Noise: Making DEI a Professional Asset

The key to making DEI work effectively is to ensure that diversity complements professional merit, enhancing excellence rather than being treated as an afterthought or a primary qualifier. Organizations should strive to create environments where diversity enhances excellence rather than being a substitute for it.

This means:

1. Prioritizing Merit and Inclusion Simultaneously – Ensuring that hiring and promotions are based on qualifications and skills while also providing fair opportunities to candidates from diverse backgrounds.

2. Encouraging Open Conversations – Creating spaces where employees can discuss concerns about DEI policies without fear of backlash, fostering a culture of trust rather than division.

3. Holding the Media Accountable – Promoting media literacy and critical thinking is essential to help individuals discern between genuine DEI efforts and divisive narratives. However, this is challenging when divisive content generates higher engagement and revenue for media outlets and social media platforms. To counteract this, individuals and organizations must actively seek out diverse sources of information, support independent journalism, and advocate for responsible reporting. Encouraging critical thinking through education, corporate training, and public discourse can also help people recognize bias and misinformation. While financial incentives drive media sensationalism, fostering a culture of inquiry and open discussion can help shift focus toward more balanced and constructive narratives.

4. Celebrating Excellence Across All Backgrounds – Acknowledging achievements without attributing them solely to diversity policies, thereby reinforcing the value of competence and hard work. This is particularly important in cases where individuals from underrepresented groups achieve significant milestones through dedication and skill. Recently, another friend received a prestigious award as a top worker in his company. Despite his hard-earned success, some colleagues dismissed his achievement as a byproduct of DEI rather than recognizing his exceptional performance. This illustrates how DEI can sometimes be used as a wedge by those unwilling to acknowledge genuine merit. To combat this, organizations should emphasize transparency in performance evaluations and celebrate accomplishments in ways that highlight individual excellence, ensuring that diversity initiatives are seen as enhancements rather than determinants of success.

DEI remains an important movement, but its success hinges on thoughtful implementation rather than rigid mandates. By cutting through the noise and focusing on a balanced approach where diversity and merit reinforce each other, we can ensure that DEI strengthens our institutions rather than weakening them. With a balanced approach, diversity can be a true asset that complements professional excellence rather than competing with it.

Media consumption shapes how we view the world, but it’s not always as objective as it seems. Recognizing these methods empowers us to consume information more critically, making us less susceptible to manipulation.

1. Loaded Language:
   Emotionally charged words like “disastrous,” “shocking,” or “heroic” are designed to provoke strong reactions rather than provide clear information. They often exaggerate or frame an event to influence how you feel about the subject. Be wary of language that seems more dramatic than the actual topic warrants—it’s a sign the goal may be persuasion, not clarity. Here's one that uses the word "haters" in a new way.
   
   Example: “Snoop Dogg reacts to Trump inauguration haters mad he changed his tune on president”. Yes, that's a real headline.
   

2. One-Sided Perspectives:
   If the content focuses solely on one side of an argument, leaving out dissenting views, it’s a clear indicator of bias. Balanced reporting provides multiple viewpoints, allowing you to form your own opinion. Ask yourself: is there more to this story that hasn’t been covered?
   Example: An article about climate change interviews only fossil fuel executives while ignoring scientists.
   

3. Selective Use of Facts/Data:
   Cherry-picking specific statistics or details while ignoring others is a common tactic to push a narrative. For example, someone might highlight only the benefits of a policy without mentioning the downsides or risks. To spot this, look for whether the information is fully contextualized or designed to lead you to one conclusion.
   
   Example: "According to our poll, 95% of people support this law!" (The poll surveyed 10 people who all work for the organization promoting the law.)
   

4. Omission of Key Details:
   Leaving out important facts can drastically change how a story is perceived. A story that doesn’t explain the full background or skips over relevant details may be framing the narrative intentionally. Be cautious if what’s missing feels just as important as what’s included.
   
   Example: A news report claims, “Local business closes due to union strikes!”—but fails to mention the company had already filed for bankruptcy.
   

5. Overgeneralizations:
   Sweeping statements like “everyone knows” or “nobody cares” often oversimplify complex issues. Such phrases give the impression of universal truth while failing to provide evidence or nuance. Real-life problems usually have multiple factors at play, so generalized claims should always be scrutinized.
   
   Example: A news commentator says, “Americans are tired of high taxes.” Which Americans? Did anyone ask them?
   

6. Sensational and Misleading Headlines:
   Headlines are often written to grab attention, even if they distort or oversell the content. Sometimes, the article itself will contradict the sensationalized headline, so always read beyond the title. A clickbait headline might entertain, but it rarely informs.
   
   Example: “Study Finds Cheese Cures Depression!” (Spoiler: The study was about comfort eating, not medical cures.)
   

7. Ad Hominem Attacks:
   Attacking someone’s character or appearance rather than their ideas is a hallmark of biased or manipulative content. This tactic distracts from the actual issues and stokes emotional reactions. Instead of focusing on the argument, it shifts the discussion to personal jabs.
   
   Example: A political ad says, “You can’t trust Senator Green; he’s been seen wearing Crocs to formal events!”
   

8. Lack of Credible Sources:
   Content that doesn’t provide clear, reliable citations or relies on anonymous or vague sources is less trustworthy. Without strong evidence, claims are just opinions or speculation. Always check if the sources can be verified independently.
   
   Example: “Experts agree that watching TV is better than exercise!” (Who are these “experts,” and where can we find them?)
   

9. Overuse of Opinion:
   News that reads more like a personal rant often blurs the line between opinion and fact. It’s fine for commentators to share their views, but they should clearly label opinion pieces and separate them from objective reporting. Be alert when strong opinions masquerade as factual analysis.
   Example: An article reads, “This policy is the only logical choice; anyone against it clearly doesn’t understand economics.”
   

10. Polarizing Narratives:
    Content that divides issues into “good vs. evil” or “us vs. them” oversimplifies reality and fuels division. Real-world problems are rarely black and white and typically require more nuanced discussions. Be cautious of narratives that vilify or lionize without providing middle-ground perspectives.
    
    Example: “This city’s problems will end if we just elect the right mayor.” If only it were that easy.
    

11. Appealing to Authority:
    Just because someone with a title or influence endorses a claim doesn’t make it true. Authority figures can be biased, mistaken, or working in their own interest. Always look for additional evidence instead of taking their word at face value.
    
    Example: “As the CEO of a billion-dollar company, I can assure you this policy works.” Okay, but where’s the data?
    

12. Lack of Transparency:
    When it’s unclear who funds, writes, or promotes a piece, it’s difficult to assess its motives and credibility. Transparency helps build trust, while hidden agendas create doubt. Ask yourself who benefits from the story and whether that’s been disclosed.
    
    Example: A “scientific” article promoting a new wonder drug is later revealed to be written by the pharmaceutical company that sells it.
    

13. Consistent Partisanship:
    Sources that always side with one political party or ideology, regardless of context, are usually biased. Honest reporting should critique or praise based on the facts, not allegiance. If a source never questions its “team,” it’s likely pushing propaganda.
    Example: A website that only writes glowing reviews about one party, even when scandals emerge, is likely pushing an agenda.

14. Unverified Claims:
    Statements presented as fact without supporting evidence should immediately raise suspicion. These claims often spread quickly, especially on social media, even if they’re later proven false. Always ask: where’s the proof, and can this be independently confirmed?
    
    Example: A viral tweet declares, “Breaking: Alien technology discovered in Nevada!”—but no reputable source covers the story, and the tweet links to a conspiracy website.
    

Recognizing Bias With Family And Friends

Recognizing these methods empowers us to consume information more critically, making us less susceptible to manipulation. For example, if your dad starts a conversation with, “I saw this on TV…” and launches into a talking point, it’s a reminder of how many people—especially seniors—take media at face value. Instead of overwhelming him with a detailed explanation, try using simple, gentle cues to plant a seed of skepticism. A kind response like, “That’s interesting—did they mention the other side of the story?” can subtly encourage curiosity and critical thinking without making him feel called out or defensive.

Start by discussing the reasons behind their preferences without dismissing their views. Understanding their perspective can help you find common ground. Instead of directly challenging their sources, share your own experiences with finding balanced information and how it has helped you form a more comprehensive understanding of the issues at hand.

Kindly teach them to identify loaded language and emotional appeals in news articles or broadcasts. Words with strong connotations can influence perception, portraying certain events or individuals positively or negatively. Encouraging them to look for these cues can make them more aware of subtle attempts to sway their opinions.

Try to set up a safe space for conversation where understanding and empathy are front and center. Use questions like, "Why do you think the questions of [said individual] are framed this way?”.

Suggest simple critical thinking techniques that don't require changing their sources or using fact-checkers. For example, they can look for inconsistencies within their preferred news source, question the motives behind sensational headlines, and consider how different wording might alter their perception of a story. By fostering a mindset of curiosity and skepticism, they may naturally become more open to diverse information.

Share your own journey of discovering media bias. You could say, "I used to watch X all the time, but then I noticed Y, which made me start checking other sources."

By framing it as a shared effort to seek truth, we can help loved ones spot bias and navigate media more thoughtfully.

The Theater of Division: Left vs. Right

At its core, the American media operates as a megaphone for ideological conflict. Headlines scream about “Liberal Snowflakes” or “Conservative Fascists,” creating caricatures of both sides that are easy to digest but devoid of nuance. For example, Fox News might run a headline such as “Woke Culture is Destroying America” while MSNBC counters with “Right-Wing Extremists Pose the Greatest Threat to Democracy.” These narratives are not simply reflective of ideological differences; they are constructed to elicit outrage and deepen divisions.

Sensationalism sells, and in an era of declining attention spans, headlines have become more provocative and less factual. Consider the media’s treatment of issues like police reform. Following the tragic death of George Floyd, outlets on the left pushed headlines like “Defund the Police: The Only Path Forward,” while conservative outlets countered with “Defunding the Police Will Lead to Chaos and Lawlessness.” Neither position reflects the complexities of policing in America, yet the binary framing forces readers to pick a side rather than engage in meaningful discussion.

This dynamic is not accidental. By framing every issue as a battle between opposing forces, the media ensures a steady stream of conflict and controversy that keeps viewers glued to their screens. The result is a society increasingly divided along partisan lines, with little room for compromise or collaboration. But while Americans are busy fighting each other, the real players—corporations, lobbyists, and political elites—continue to pull the strings behind the scenes.

Contradictions and Media Hypocrisy

One of the most striking aspects of the media’s role in perpetuating division is its willingness to contradict itself when it suits the prevailing narrative. Both liberal and conservative outlets are guilty of this, often shifting their positions to align with political expediency or corporate interests.

Take, for example, the issue of free speech. Liberal outlets like The New York Times have historically championed the importance of free expression. Yet, in recent years, some of these same outlets have supported censorship in the name of combating misinformation. Conservative media is no less hypocritical. Fox News, which frequently rails against “cancel culture,” has also called for boycotts of companies that support progressive causes. These contradictions highlight the media’s true priority: maintaining a narrative that serves its own interests, even at the cost of consistency.

Another example can be found in the coverage of government spending. During the Trump administration, conservative outlets largely ignored the ballooning national deficit, focusing instead on the benefits of tax cuts and military spending. However, with a Democrat in the White House, these same outlets suddenly rediscovered their fiscal conservatism, decrying deficit spending as reckless and unsustainable. On the other side, liberal media that criticized Trump’s spending habits have been far more lenient when reporting on similar policies under President Biden.

These contradictions are not mere oversights; they are deliberate strategies designed to reinforce tribal loyalties. By selectively framing issues to align with their audience’s biases, media outlets ensure a steady stream of engagement and revenue. Meanwhile, the underlying issues—government spending, free speech, systemic inequality—remain unaddressed.

Corporate Interests and the Illusion of Choice

At the heart of the media’s manipulation lies the influence of corporate interests. Major media conglomerates like Comcast (owner of NBC), Disney (owner of ABC), and News Corp (owner of Fox) dominate the information landscape, prioritizing profits over public interest. These corporations are not neutral arbiters of truth; they are businesses with shareholders to please and agendas to advance.

Consider the role of advertising in shaping media content. News outlets rely heavily on corporate advertisers for revenue, creating a conflict of interest that undermines journalistic integrity. Stories that challenge corporate power or advocate for systemic change are often downplayed or ignored altogether. For example, coverage of climate change is frequently watered down to avoid alienating fossil fuel advertisers. Similarly, stories about labor rights and unionization struggles receive minimal attention, as they conflict with the interests of corporate sponsors.

This dynamic extends to political coverage as well. Both liberal and conservative media outlets receive funding from political action committees (PACs) and lobbying groups, further blurring the line between journalism and propaganda. The result is a media landscape that prioritizes the interests of the wealthy and powerful while marginalizing the voices of ordinary Americans.

The Real Game: Power and Control

While the media keeps the public distracted with partisan battles, Congress and the presidency continue to operate as two sides of the same coin. Both Democrats and Republicans rely on corporate donations to fund their campaigns, ensuring that their policies align with the interests of their donors rather than their constituents. This dynamic is perhaps most evident in the area of economic policy.

Take, for instance, the issue of tax reform. Both parties claim to champion the interests of working Americans, yet their policies consistently benefit the wealthy. The 2017 Tax Cuts and Jobs Act, passed by a Republican-controlled Congress, disproportionately benefited corporations and high-income earners. Similarly, Democratic proposals for tax reform often include loopholes that allow the ultra-rich to avoid paying their fair share. Despite their rhetoric, both parties are deeply entrenched in a system that prioritizes the interests of the elite.

Healthcare is another area where the bipartisan consensus becomes apparent. While Democrats and Republicans publicly clash over issues like Medicare for All, both parties have consistently failed to address the underlying problem: the profit-driven nature of the American healthcare system. Pharmaceutical companies and insurance providers wield enormous influence over both parties, ensuring that meaningful reform remains out of reach.

The media plays a crucial role in perpetuating this status quo by framing these issues as partisan battles rather than systemic problems. By focusing on the spectacle of political conflict, the media obscures the underlying economic and structural forces that shape American society. This serves the interests of both political elites and corporate sponsors, who benefit from a divided and distracted populace.

Victims of the Game: The American People

The ultimate losers in this game are the American people. By fostering division and perpetuating misinformation, the media undermines the very foundation of democracy. Citizens are left to navigate a sea of conflicting narratives, unable to discern truth from propaganda. This erodes trust in institutions and fosters a sense of cynicism and apathy.

Moreover, the media’s focus on sensationalism and conflict leaves little room for substantive discussion of the issues that matter most to ordinary Americans. Economic inequality, climate change, healthcare, education—these are the challenges that define our era, yet they are consistently overshadowed by the latest scandal or outrage. The result is a society that is ill-equipped to address its most pressing problems.

The media’s manipulation also has profound psychological effects. The constant barrage of negative news and partisan conflict contributes to feelings of anxiety, anger, and hopelessness. This is not an accident; it is a deliberate strategy designed to keep viewers engaged and emotionally invested. By fostering a state of perpetual outrage, the media ensures a steady stream of clicks, views, and ad revenue.

Breaking the Cycle

To break free from this cycle of manipulation, Americans must take a critical and proactive approach to media consumption. This begins with recognizing the biases and agendas that shape media narratives. From YouTube to traditional media, using tools such as Allsides along with seeing how a particular outlet gets funded helps seek out grounded perspectives. By engaging with independent and investigative journalism, citizens can gain a more nuanced understanding of the issues at hand.

Media literacy is also essential. Schools and communities must prioritize education that equips individuals with the tools to critically analyze media content. This includes understanding the techniques used to frame stories, recognizing logical fallacies, and identifying conflicts of interest.

Finally, systemic change is needed to address the root causes of media manipulation. This includes campaign finance reform to reduce the influence of money in politics, as well as antitrust measures to break up media conglomerates and promote competition. By challenging the concentration of power in both the media and political spheres, Americans can reclaim their democracy and ensure that their voices are heard.

Conclusion: The Hate Economy

The media’s role in shaping the divide between the “Left” and “Right” is not just a byproduct of ideological differences—it is a calculated component of what can only be described as a “Hate Economy.” This economy thrives on outrage, division, and sensationalism, generating profit and power for corporations, lobbyists, and political elites. By amplifying conflict and perpetuating contradictions, the media ensures a steady stream of engagement while obscuring the true dynamics of power and control.

The American people, caught in this cycle, are the victims of a game designed to keep them divided and distracted. To resist this manipulation, citizens must recognize the media’s role in perpetuating the Hate Economy and take steps to reclaim their agency. By fostering media literacy, supporting independent journalism, and advocating for systemic reform, Americans can break free from the noise and build a society that prioritizes truth, justice, and the common good. The stakes are high, but the path forward is clear: it is time to dismantle the Hate Economy and focus on the real game at play.