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.