DEV Community: Jack Heath

A Toy Company, AI, and the Human Argument

Jack Heath — Sun, 25 Oct 2026 19:08:17 +0000

If anyone can make it, no one can sell it.

This month, the people who make Dungeons & Dragons and Magic: The Gathering moved to unionize. Most of the coverage is about pay, crunch, and layoffs, and those are real. But buried in the D&D team's letter is the sentence that explains the last three years at Wizards of the Coast:

"As pressure has ramped up from Hasbro to adopt LLMs and Gen AI tools in various aspects of our work, WOTC has resisted these efforts and kept AI out of our games. That's good! We want to preserve this commendable stance through a union contract that ensures our games will always be made by people for people."

Read that again. The workers are not asking the company to adopt a policy. The policy already exists. They are asking to lock it into a contract so the parent company can't take it away.

The Argument Everyone Thinks This Is

From outside, this looks like a fight about artists' rights — whether a machine should be making the art and stories people pay for. That argument is real, but it is not the one being fought inside the building.

Wizards drew its line in December 2023, after AI-assisted art turned up in a D&D book: "We require artists, writers, and creatives contributing to the Magic TCG and the D&D TTRPG to refrain from using AI generative tools to create final Magic or D&D products." A month later, a Magic marketing image made by an outside vendor turned out to have AI in it. The company denied it for three days, then admitted it, and at least one longtime artist announced he was done working for them. Three days of denials bought one admission, and the trust bill came due immediately.

The human argument isn't artists versus AI — it's about what happens when the executives hired to run a company cash out its IP for short-term gain. Is that unethical? Does a decision that pays investors this quarter, at the expense of the company's own future, actually serve the company's interest? And should the employees who build the product have a say in decisions like that? AI matters here only because it makes the short game cheap. It isn't making the product better. It's being used to saturate the market with poor-quality content, pull out every dollar of short-term value in the IP, and cast it aside once there's nothing left to wring out of it.

The Two Faces of Chris Cocks

Hasbro's CEO is Chris Cocks. He is not an outsider who wandered in from the toy aisle. He ran Wizards of the Coast from 2016 to 2022, he plays D&D, and by his own account his home games run on AI-generated images, text, sound, and voice cloning. In September 2024 he told a Goldman Sachs conference that Hasbro was already using AI "significantly and liberally," adding that among the thirty or forty people he plays with, "there's not a single person who doesn't use AI somehow for either campaign development or character development or story ideas. That's a clear signal that we need to be embracing it."

Cocks acknowledged that some audiences and creators simply do not want AI involved, saying that Magic: The Gathering and Dungeons & Dragons were not using it in their product pipelines. The problem is that the softer line does not survive contact with his own building. The union letter, written months later, describes AI pressure that "has ramped up" from the company he runs. The push itself never disappeared. Hasbro launched an AI studio in June, and since September 1, with the Wizards president gone, Cocks has overseen the division directly. The promise and the pressure now come from the same office. One is the public face. The other is the policy.

But the deeper issue is not inconsistency. It is a misunderstanding of what the product actually is.

Listen to how Cocks talks about his own games. He told The Verge that his home computer contains so much AI-generated animation, imagery, text, and voice cloning that the volume of it would "floor" interviewer Nilay Patel. When he looked around his table and saw every player using AI tools, he saw "a clear signal that we need to be embracing it." A market signal.

And even judged purely as business, the signal points the wrong way. Wizards' money has never come from making content. It comes from owning the thing nobody else can make: the official game, the trusted name, the world players agree is real. Generative AI destroys exactly that scarcity. If a model can produce a passable adventure, illustration, or campaign setting, so can every fan, every rival publisher, and every kid with a laptop. The product doesn't get harder to sell. It becomes impossible to sell at all. A company flooding its own market with machine-made content is spending down the only asset that ever made it money. Cocks is steering his most valuable division toward the one future where its catalog is worthless.

Because D&D was never successful because it generated stories efficiently. It was successful because it created community. Matt Mercer has described running games for his friends as an expression of love. He has also spoken about growing up struggling to find his place and how tabletop gaming helped him find his people. That is not incidental to D&D's success. It is D&D's success. For fifty years, the game's real product has been a reason for people to gather around a table, week after week, and build friendships inside a shared world. The story is the excuse. The people are the point.

An AI can write a competent adventure. What it cannot do is be the friend who wrote it for you. It cannot make four exhausted adults show up on a Tuesday night, argue over a locked door, laugh until it hurts, and leave closer than they arrived. Automate the game master and you have not made the experience cheaper or better. You have removed the reason the experience exists and kept the dice.

Maybe that is genuinely difficult to see from the executive suite. Someone who has spent his life comfortable in every room may never have needed a game to help him find belonging. He never needed a character sheet to find his people. Which may be why he can look at a fifty-year-old social ritual and see a content pipeline. It takes a certain confidence to assume that the part you never needed must be the part that does not matter.

New isn't Better, Does AI Hype or Help

And the premise underneath the push, that a beloved game needs new technology poured into it to survive, has already been tested at the largest scale there is. Microsoft bought Minecraft for $2.5 billion in 2014 and spent years trying the new-technology plays: Minecraft shown in augmented reality as a 3D world hovering over a table, a full AR spinoff called Minecraft Earth, and a VR version of the game itself. Earth shut down within two years. The VR version lasted longer, but Mojang dropped support for it in 2025. The headset and the hologram never became how people play Minecraft. The core game, meanwhile, barely changed, and what Microsoft did with the property instead was build different games for different markets: Minecraft Dungeons for action players, Minecraft Legends for strategy players. The original was never replaced, never rebuilt around the technology of the moment, and it is still the best-selling video game in history.

The Player's Contribution

D&D players should sit with the other side of that coin. The game is sold to them as timeless: fifty years of adventures that never expire. If that is true, they do not need to keep buying. A campaign book does not stop working when a newer one ships. The rules on the shelf will run games for the rest of a player's life.

And players are the worst possible customers for generated content because they are already creators. Every dungeon master who has ever run a homebrew campaign has done the thing the AI pitch assumes only a company can do: built a world, written the adventure, and performed it for an audience of friends. Players can cap their games at the content they already own, whether older editions, older adventures, or their own material, and the game loses nothing. That may make them the clearest proof that AI content cannot be profitable in this space. You cannot sell generated stories to the one audience that generates its own for free, because that is the entire point of the hobby.

Neither Side Is Innocent

Rather than turning this into a story about a virtuous studio resisting a predatory parent company, it is worth looking at Wizards' own record. The studio's hands are not clean. The pattern is the same. The incentives are the same. Only the vantage point differs.

In January 2023, a draft of a new Open Game License leaked. For more than twenty years, the original OGL had allowed creators to build games on D&D's rules without paying Wizards or seeking permission. Entire businesses and creative careers grew from that ecosystem. The new draft would have revoked those protections, imposed royalties on successful creators, and granted Wizards broad rights over work made by others. The backlash was immediate. Nearly 90 percent of respondents in Wizards' own survey rejected the proposal, and within weeks the company abandoned it entirely. The original license remained untouched, and the core rules were placed into Creative Commons, beyond the reach of any future executive.

What was the OGL controversy really about? It was an attempt to transform community creativity into a revenue stream. Twenty years of fan and third-party innovation suddenly looked less like a thriving ecosystem and more like untapped intellectual property waiting to be monetized.

Who Captures the Value?

The same logic appears in the layoffs. Throughout 2023 and beyond, Hasbro eliminated thousands of jobs, including creative roles at Wizards, even as Wizards continued delivering strong financial results. Teams were reduced, projects were cut, and community-facing staff disappeared while the company's most profitable division posted record numbers. The people fans actually knew and trusted became line items on a spreadsheet.

Taken together, the lesson is difficult to avoid. Hasbro pressures from above. Wizards protects its interests from below. When the value of human creativity strengthens the brand, it is celebrated. When that same creativity becomes an obstacle to growth targets, it becomes expendable. The honest picture is not a battle between good and bad actors. It is two corporations responding to the same incentives.

Hasbro pushes from above: layoffs, automation pressures, licensing opportunities, and quarterly growth targets. Wizards pushes from below whenever it sees a chance to consolidate control, protect revenue, or expand ownership over community-created value. Sometimes their interests conflict. More often, they align.

The artists and designers caught in the middle are not the authors of these decisions. Neither are the fans whose passion gives the brands their value. Yet both groups are routinely treated as resources rather than stakeholders.

That is the thread connecting the OGL controversy, the layoffs, and the AI debate.

They are not separate stories.

They are different expressions of the same relationship.

The fan community creates value. Creative workers create value. Corporate management captures value.

What to Watch

Forget the next AI art controversy. There will be another one, and it will dominate social media for a week before everyone moves on.

The more important question is who ultimately controls the future of these games: the people who create them, the communities that sustain them, or the executives managing them as assets.

That is the question behind the union effort. It is not really a debate about technology. It is a debate about power.

If "made by people, for people" becomes an enforceable contractual obligation, it survives changes in leadership and quarterly priorities. If it remains a marketing slogan, it lasts only as long as it remains profitable.

And that distinction will do more to determine what Dungeons & Dragons and Magic look like ten years from now than any AI model ever will.

The conflict begins whenever those groups disagree about who should benefit from the value they create.

Thanks to Dungeons & Discourse (@dungeonsanddiscourse) for bringing this discussion to light. If it interests you, go deeper on her YouTube channel: https://www.youtube.com/@dungeonsanddiscourse

You Can't Respin a House

Jack Heath — Fri, 23 Oct 2026 17:42:15 +0000

This article was originally published on Insight Source.

Written by Jack Heath, Information Security Engineer

Most security advice quietly assumes a fantasy world: one where you can start over. Buy the new appliance. Replace the fleet. Respin the board with the right chip this time. Refresh on a three-year cycle and let the problem age out.

Real life does not work that way. Real life is already deployed.

My wife runs short-term rentals. A house is not a lab. It has a guest checking in tonight, a cleaner turning it over tomorrow, and a calendar booked out past that. You don't get to shut it down for a quarter while you re-architect it. Whatever you fix — a lock, the network gear, the way people get in and out — you fix between stays, in a window measured in hours. And it has to work the first time, because the next person through the door isn't a tester. They're paying to sleep there.

That isn't a hospitality problem. It's everyone's problem. And the technology world is finally starting to say it out loud.

This week a chip vendor announced something that sounds small and isn't: TPM 2.0 — secure boot, device identity, protected key storage — delivered in firmware across an entire line of modules already in the field. No discrete chip. No board respin. If the device can take a secure firmware update, it can gain a root of trust it didn't ship with. The vendor talks about product lifespans of seven to fifteen years. That's the honest timescale. The board you shipped five years ago is still in a clinic, a factory, a truck, a building — and it'll still be there five years from now. The question was never how to design a secure new one. The question is what to do with the ones already bolted down.

I've spent a lot of my career on the enterprise version of the same wall. Key estates, certificate estates, server fleets — none of them get respun either. They grow, they get acquired into, they accumulate one-offs nobody wants to delete. You secure them in place, in stages, while production is running. Or you don't secure them at all. The perfect redesign that requires everything to stop is just a polite way of leaving the old thing exposed.

Here's the work that actually holds up, whether the deployed base is a module, a server fleet, or a house people sleep in.

Start with what's actually out there

Not the purchase orders. Not the diagram. The physical reality: what's installed, what firmware it's on, how old it is, and whether the vendor still supports it.

This sounds basic, and it's where most plans quietly die. I've watched teams design an upgrade for a fleet they didn't actually have — wrong versions, forgotten units in a closet, a device swapped during an emergency repair and never recorded. In a house, that's the router a previous owner left behind, still plugged in behind a dresser. In a data center, it's the same router with a bigger budget.

Write it down before you buy anything. An inventory you trust is worth more than a product you don't.

Take the firmware door before the forklift

If something can be made meaningfully more secure by an update — firmware TPM instead of no TPM, current software instead of end-of-life software, automated renewal instead of a certificate tracked on a calendar — take that door first.

It's faster, cheaper, and it reaches the whole deployed base instead of just next quarter's purchases. A refresh-only strategy protects the future and abandons the present, and the present is where attacks happen. Attackers don't wait for your refresh cycle. They inventory your old gear more carefully than you do.

The catch: the update path itself must be trustworthy. Signed updates, a way to prove what a device is after the update, and a way back if the update fails. An insecure update mechanism isn't a door. It's a second front entrance with no lock.

Stage it like somebody lives there — because somebody does

Never start with everything.

Pick one unit, one property, one product line. Upgrade it. Live with it. Watch what breaks that the test plan didn't predict — the guest who can't get in, the client that doesn't trust the new configuration, the workflow that relied on the old behavior for reasons nobody wrote down. Fix it, document it, then move to the next group.

In key-management work, the rule is the same one I use in a house: the original stays working until the replacement is proven. You don't cut over on hope. You run the new thing alongside the old, reconcile the counts, and retire the old only after the new has carried real load. Big-bang cutovers are how security projects become outage stories people tell for years.

Automate the part that repeats, or it will beat you

A deployed base only grows. Every unit you add is another certificate to renew, another update to apply, another key to rotate, another account to close when someone leaves.

At small scale you can carry that in your head. At slightly larger scale you carry it in a spreadsheet and feel fine — right up until the week you don't. Manual tracking doesn't fail loudly. It fails on a Tuesday, in an expired certificate or a missed update, in a system nobody remembered was still running.

The fix isn't working harder. Inventory first, automate the recurring work second, and keep alerts as the safety net instead of the process. That order matters. Automating a mess just makes the mess happen faster.

Replace on evidence, not on a brochure

None of this means never replace anything. Some gear is genuinely done — unsupported, unpatchable, unable to prove what it is or protect what it holds. That gear goes first, ahead of the merely old.

What I'm arguing against is replacement as the default answer. Replace because a device can no longer be secured where it sits, not because a newer model exists. Put the money you save by upgrading in place into the short list of things that truly cannot be saved. That's how a small operator — and, honestly, most large ones — secures all of it instead of beautifully securing the newest tenth.

Regulators are starting to price this in. Europe's Cyber Resilience Act, fully applicable in December 2027, expects products to be secure by default and to receive security updates for years. That's not a refresh-cycle law. It's a deployed-base law — written for things that stay in service long enough to need looking after.

Why I'm sharing this

Because the most useful security shift I've seen in a while isn't a new product category. It's vendors and operators admitting, publicly, that the installed base is the job.

You can't respin a house. You can't respin a factory floor, a medical practice, or a fleet already on the road. You inventory what you have, take the upgrade that reaches it where it sits, stage it so the people using it never have to care, and automate the upkeep so it stays secure after you stop thinking about it.

Start this week with the list. One page, every deployed thing you're responsible for, with its age and update status. If a line on that page surprises you, you've found the work — and it was never going to be fixed by buying replacements for lines that didn't surprise you.