Saturday, October 24, 2026

A Toy Company, AI, and the Human Argument

Written by Jack Heath, Information Security Engineer

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

Tax Season Is Phishing Season

Written by Greg Schneider, Contributor, 2026

Tax Season Is Phishing Season

Every April, two seasons run at the same time. One is tax season. The other is the phishing season that rides on it — because there is no better time to trick people than when everyone is expecting messages about money, deadlines are real, and a refund feels like something you should act on fast.

Scammers don’t need new tricks for this. They just re-run the greatest hits, and they work every year.

The fake IRS message. A text or email says there’s a problem with your return, or your refund is on hold, and you need to verify your information right now. Pause there. The real IRS does not initiate contact with taxpayers by text message or email — that’s their long-standing, publicly stated policy. They start with a letter in the mail. Any text or email claiming to be the IRS and asking you to click, reply, or “verify” is a scam by definition. You don’t have to judge how convincing it looks. The channel itself is the tell.

The refund “processing fee.” Your refund is ready — you just need to pay a small fee, or confirm your bank details on this page, to release it. The page is fake, the fee goes to a stranger, and the bank details you typed in are worth far more to them than the fee.

The preparer impersonation and the lookalike site. An email that looks like it’s from your tax preparer asks you to upload your documents to a portal. Or you search for a filing service, click the first result, and land on a site that looks right and harvests everything you type — including the Social Security number you helpfully entered on page one. Tax data is the complete identity-theft kit: name, address, date of birth, SSN, income. It is worth stealing carefully, and these people steal it carefully.

The W-2 request. This one aims at businesses, and it lands every year. Someone in payroll or HR gets an email that appears to come from the CEO or CFO: “I need copies of all employee W-2s for a review — send them today, keep it between us.” It’s not the executive. It’s a stranger, and if those W-2s go out, every employee in the file gets to spend the next year fighting fraudulent returns filed in their name. The secrecy in the message is the mechanism — it’s there to stop you from checking.

The defenses (this is the part that matters)

Get an IRS Identity Protection PIN. The IP PIN is a six-digit number the IRS issues you, and a return filed under your Social Security number can’t be accepted without it. A scammer with your full identity kit still can’t file as you, because they don’t have the PIN. You can request one through the IRS website — type irs.gov yourself, don’t follow a link — and it renews each year. Of everything on this page, this is the single highest-value ten minutes.

File early. A fraudulent return only works if it arrives before your real one. Once your legitimate return is filed and accepted, a second one under your number gets rejected. Filing early isn’t just about a faster refund; it’s a land grab, and you want to be the one who got there first.

Only reach tax sites by typing the address. Not from an email, not from a text, not from the first sponsored search result. Bookmark the real IRS and preparer sites once, correctly, and use the bookmarks. Most tax-season phishing dies right here, because it all depends on you arriving through their door instead of yours.

Verify your preparer like it matters, because it does. A legitimate preparer has a PTIN (Preparer Tax Identification Number) and signs your return — someone who refuses to sign, wants to be paid in cash or gift cards, or promises a suspiciously huge refund before seeing a single document is telling you what they are. And if your preparer emails you a new “portal” or new payment instructions mid-season, call them on the number you already have before you upload anything. Portals change; a thirty-second call confirms it.

Turn on MFA everywhere a refund could be redirected. Your email first — it resets everything else — then your tax software account, your preparer portal, and your bank. A stolen password alone shouldn’t be enough to change where your money goes.

For small businesses: a two-person rule for employee data. Any request for W-2s, payroll files, or bulk employee information needs a second human to approve it, and the request gets verified by phone on a number already on file — never by replying to the email that asked. Make it written policy before tax season, tell every executive it applies to requests that appear to come from them too, and the W-2 scam has nowhere to land. Nobody legitimate is harmed by a verification call.

Screenshot this

  • ☐ IRS IP PIN requested — a return can’t be filed as you without it
  • ☐ Filed early — your real return blocks the fake one
  • ☐ IRS and preparer sites bookmarked; never arrived at by email or text links
  • ☐ Any “IRS” text or email = scam, full stop (they start with a mailed letter)
  • ☐ MFA on email, tax software, preparer portal, and bank
  • ☐ Preparer has a PTIN, signs the return, and new portal/payment instructions get a phone call first
  • ☐ At work: W-2 or payroll requests need two people and a verification call on a known number

The scams are seasonal. The defenses aren’t — set them up once, and April gets a lot quieter.

Friday, October 23, 2026

You Can't Respin a House

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.

Sunday, October 18, 2026

Why Everybody in NC Hates Data Centers

Written by Jack Heath, Information Technology Specialist, 2026

Cartoon of a data center and a tire factory on farmland, a sewer outfall fouling a creek, and a grinning pitchman with his arms spread wide.

On a Sunday afternoon in Clemmons, I watched representatives from Stokes and Forsyth county talk about people who voted routinely against each other on practically everything sitting together and agreeing completely over a moratorium on data centers for all the same reasons. And that's just not something you see in this political climate.

It may have been a Democratic cluster meetup, but opinions didn't sort the way the invitation suggested. Sure, plenty of the left but no shortage of support from MAGA, and nobody found that strange. The subject wasn't a candidate. It was a data center — a proposed hyperscale campus in Rural Hall, a few miles up the road — and from the floor, more than once, somebody said it plainly: this is not a Republican or Democrat issue.

I've worked in technology for more than thirty years. I work on the kind of infrastructure of those facilities house. So, I sat there with one BIG question:

How does a zoning fight over a farm turn into a four-party coalition against AI and big data?

Because that's what it is now. And the industry built it.

The first grievance is legitimate, local, and winnable — because it's about siting. In Forsyth County's Unified Development Ordinance, the use is listed as "Computer Data Center — Services A, except for Barber and Beauty Shops." Read that again. A hyperscale campus — a $3 billion, roughly 1.3-million-square-foot project — sits in the same services category the ordinance uses for barber shops. There is no hyperscale category. The ordinance has no shelf for the thing, so the thing gets slid onto whatever shelf is open.

Start with the water, because the neighbors do. A facility like this is a plumbing system the size of a neighborhood, and 'closed-loop' doesn't mean sealed: water evaporates to shed heat, the minerals left behind concentrate, and the operator continuously bleeds off part of the loop — blowdown — and replaces it with fresh water. That discharge is chemically treated, and it leaves warmer than it arrived. Warmer water holds less oxygen. Point it toward a small creek and the creek changes — and here the chain is Beaver Dam Creek to Muddy Creek to the Yadkin River, with a drinking-water lake in the same system. Then add the part that never makes the rendering: 130 acres of pasture becomes roof and pavement, and rain that used to soak in now reaches the creek all at once. Ask the people downstream about flood plains.

None of that is an argument the facility can't run. It is an argument that somebody has to ask the questions — how much water, in and out, at what temperature, with what in it, measured by whom — and write the answers down as conditions the operator can be held to. North Carolina has an instrument for every piece: discharge permits, withdrawal registration, stormwater rules. A special-use process can attach the rest — caps, monitoring, reporting. A 'Services A' classification attaches none of them. No hearing. No evidence. No hook to hang a condition on. The questions never get asked, because the category never asks them.

The community noticed. And when the immediate fight was over, they went further: on September 28, citizens filed their own text amendment proposing a "Hyperscale Data Center Campus" use — 25 megawatts and up, special-use permit required. Their draft caps potable water at 10 million gallons a year, mandates closed-loop cooling, and makes the operator report consumption twice a year. Sit with that for a second: the neighbors are drafting the zoning category the county never wrote. When residents have to do the ordinance's homework, the trust is already spent.

The project at the center of it, Iron Spur, was proposed for Wall Farm — about 130 acres, a century farm in the middle of Rural Hall — by the Drox Group out of Charlotte. On July 30, the Board of Commissioners denied the rezoning, 5–2, on Commissioner Dan Besse's motion. Besse has since warned publicly that the petitioners will come back with cosmetic changes. Even the win doesn't feel like an ending to the people who won it. And Forsyth isn't an outlier: neighboring Stokes County voided its own hyperscale rezoning, Project Delta, rather than let it stand.

The second grievance was already in the culture before anyone proposed a building. Long before a facility had a Forsyth County address, people were carrying a general anxiety about AI — jobs, control, the feeling that something powerful is arriving faster than anybody agreed to. That fear doesn't need a local target. But give it one — a fence line, a substation, a transmission corridor — and it lands with both feet. A neighbor who couldn't have told you what a language model was two years ago now has a mailing address for everything that worries him.

The third grievance is the door. This is the one the industry keeps underestimating. If a hyperscale data center can pass through a classification written for barber shop, what else can? The asphalt plant. The warehouse. Whatever heavy use finds the same loose shelf next. So the fight is never only about one building. It's about whether the written rules mean anything — and people who might have shrugged at a single facility will fight for years over a precedent.

When we allow large industrial operations to enter through zoning categories meant for small commercial uses — the kind designed for barber shops and boutiques — we create a loophole big enough for heavy industry to slip through without real public scrutiny.

My own town is living that problem right now. A hot-mix asphalt plant has been proposed at 6010 Gun Club Road in Clemmons — sitting on Muddy Creek, near multiple neighborhoods, and just 1.3 miles from an elementary school. The applicant filed for an air permit in July, and because of how the zoning is structured, no village council vote is required.

Different industry, same door: a high-impact use that neighbors never got to vote on, entering through whichever process asks the fewest questions.

That's why a zoning fight over a data center is never only about the data center. It's about the precedent — the way one exception becomes the pathway for the next heavy use, each one reshaping a community without the community's consent.

Impact map for the proposed Maymead asphalt plant at 6010 Gun Club Road, Clemmons NC, showing 1-mile and 2-mile radius circles, nearby schools, and Muddy Creek.

Impact map: No Asphalt Clemmons — the group's own map of the proposed plant's radius.

The fourth grievance is trust. Underneath the other three sits a simpler question: do the people in that room believe the people they elected are representing them — or going for a quick payoff? A loophole reads like a payoff whether one changed hands or not. And once neighbors start doing that arithmetic about their own commissioners, every vote those officials take afterward gets re-read in its light. Projects end. People face elections.

Which brings it to integrity, because that's what this fight is actually measuring. If you want AI adoption — real adoption, people building on the technology instead of bracing against it — the people implementing it have to act with integrity, and they have to demonstrate it, not announce it. Demonstrate that the data these systems gather and the gains from these initiatives will not be used in any negative way against the communities and workers asked to host them. Demonstrate that massive adoption of AI is not a method to fire people. Put people first, in the paperwork, in the siting, in the staffing — where it can be checked.

People can tell the difference between a knock at the front door and a noise at the back window. Come in the front door, palms out, where everyone can see your hands. Sneak in the back, face covered, and don't be surprised when the neighborhood organizes.

Stack the four and you get a lot of angry people unified in anti-AI and anti-data center sentiment. In it, you'll also hear the economic version of the argument: that administrations steer these facilities onto cheap rural land — land made cheaper, the coalition argues, by tariffs and industrial farming squeezing family farms — and call the transaction growth. You don't have to buy every link in that chain to hear what the people making it are actually saying: decisions made somewhere else devalued the farm, and now decisions made somewhere else have arrived to buy it.

None of this is happening in a vacuum. Duke Energy expects data centers and other large users to account for more than 80 percent of its new demand growth. These facilities are coming, at scale, whether any single county cooperates or not. Which makes the manner of their arrival the whole ballgame.

And the power has a politics of its own. Duke's current plan answers that growth with roughly 9,650 megawatts of new gas by 2033 — more than twice its solar target — delays three coal plants' retirements, and calls wind uneconomic through 2040. The homeowner's side of the ledger runs the other way: the federal credit for owned rooftop solar and batteries ended last December; Duke pays exported rooftop power at a wholesale ~3.4 cents; and the one real home-battery subsidy was capped at about 6,000 homes and is nearly gone. In Lee County, a developer is preparing the state's first fracking application — not despite the data centers, but for one: a gas well to power an AI campus on site. In September, the Utilities Commission itself pushed back, denying Duke a turbine beside Amazon's campus and calling the forecast 'insufficiently reliable.' Notice who makes every one of those calls. Not the technology. Not the building. The plan, the tariff, the permit — politics, all the way down.

Here is the own-goal. A siting dispute is fixable. You write a category, you hold a hearing, you set setbacks and water conditions, a project gets approved or it doesn't, and everybody goes home still neighbors. That's local government doing its ordinary work. But route the project through a loophole instead — hurry it in while early revenue is on the table — and you convert a siting problem into a corruption problem.

The coalition in Forsyth County did not disband when the rezoning was denied. It has a mailing list now. It has practice. The next proposal, in the next county, inherits it.

After the denial, Piedmont Environmental Alliance said it in one sentence: "This coalition is not anti-data center but we are concerned with the way they are entering NC." The industry should read that as a gift. The opposition is publishing its terms.

So here is the work order — and it is the real case for a moratorium. Not a ban: a pause, justified because these four things have to exist before the next application lands, and right now they don't. For those of us who build these things, it isn't complicated:

1. Write the category before the fight. A real hyperscale use, with special-use review, setbacks, and water and power conditions written down where voters can read them. Forsyth County's citizens have already drafted theirs. Most counties would rather adopt a standard than improvise one under pressure. And be honest about capacity: not every county has the planners on staff to draft one of these alone. That's what model ordinances and drafting help from the state are for — the standard can be borrowed; the decision can't.
2. Never route a project through a classification you'd be embarrassed to defend at a podium. If "except for Barber and Beauty Shops" appears anywhere in your approval path, you don't have a strategy. You have a countdown.
3. Treat the host community as the constituency it actually is. A county that hosts one facility well becomes the reference for the next ten. A county that feels ambushed becomes the warning — and warnings travel faster than references.
4. Measure success the way the neighbors do. Not in megawatts energized, but in facilities a county would agree to host twice.

Nobody ordered the coalition that met in Clemmons last Sunday. It was assembled — by haste, by loopholes, by the assumption that the politics would take care of themselves. They won't. At this point, the politics are the project and early voting is under way.

Not a great time to have people angry at policies green lit under your tenure.

Wednesday, October 14, 2026

AI Can't Think of It First



Two young artists lit into me recently. Both of them, vehement, to my face: I was destroying their ability to ever have a career.

I want to take that seriously, because they meant it. They're scared. When you're twenty and you've spent years learning to draw, and a machine can produce a passable illustration in forty seconds, fear is a rational response. I'm not going to mock that.

But I am going to disagree with it. And I want to start with a country song.

Old Town Road wasn't country (until it was)

When Lil Nas X released Old Town Road, country gatekeepers insisted it couldn't be country — because he was a rapper, because it had trap beats, because it didn't fit the boundaries they'd drawn. Then it spent nineteen weeks at number one on the Hot 100 and became one of the biggest country hits ever made. The genre didn't die. It got bigger.

Every creative generation does this. Photography wasn't real art — it was a machine doing the painting. Synthesizers weren't real instruments. Sampling wasn't real musicianship. Digital art wasn't real art — "you just let the computer fix your lines." The pattern is always the same: the new method arrives, the incumbents declare it illegitimate, and ten years later the kids who grew up with it are making things the gatekeepers couldn't have imagined.

"AI art isn't real art" is just the current verse of a very old song.

The part they're right about

Let me steelman their case, because part of it is legitimate: when an AI model is trained on an artist's work without permission and then produces images in that artist's exact style on demand, that is theft. Full stop. The artist did the years of work; the model company scraped it for free and sells the output. The law hasn't caught up, and it needs to.

But notice what that complaint is actually about. It's about unregulated training data. It's a consent and compensation problem — not a verdict on AI as a creative tool. We don't ban cameras because paparazzi exist. The theft is real, and the tool is separate from the theft.

The tool lineage

Art history is a history of artists picking up whatever was lying around. Banksy uses stencils. Bob Ross painted happy little trees with old sponges and palette knives he'd had for years. Digital artists use algorithmic line correction every time they draw a curve — the software literally guesses what you meant and fixes it. Nobody calls that cheating.

AI belongs in that lineage when it's used responsibly. If an artist hand-draws a hundred frames and uses generative AI to interpolate the motion between them, what's the result? A living sculpture made of ink and paper. The AI didn't imagine it. The artist did — the machine just did the in-between work that used to take six more months.

Analysts and creatives

Here's the thing I tried to explain to those two kids, and it's the core of the whole argument:

The world is full of analysts and creatives. AI is the ultimate analyst. It can decompose anything ever made, find every pattern, and hand that analytical skill set to everybody, uniformly, for free. That's genuinely disruptive if your entire value proposition was "I can render in this style" — because now everyone can render in this style.

But here's what the ultimate analyst cannot do: it cannot think of it first. All it can do is copy — remix, interpolate, recombine — what a creative already thought of. Every output is downstream of someone's idea. The machine has never had an original thought and never will; it doesn't want anything, doesn't feel anything, doesn't wake up at 3 AM with an image it has to get out of its head.

So the question isn't whether AI will replace artists. The question is whether you're an analyst or a creative. And here's the uncomfortable corollary I didn't say out loud to those kids, but I'll say here: if your art is entirely "I draw in somebody else's style, but by hand," you were already doing what the machine does. You were the analyst. The machine just does it faster.

But if you're truly creative — if you have ideas that don't exist yet, images nobody's seen, things only you would think to make — then you're creative enough to figure out how to use AI in a way nobody else ever has. Nobody has explored that frontier yet. It's wide open. And whatever you make out there, with whatever tools you pick up along the way?

That's art. It was always about the thinking, never about the brush.

The Next Job Success Engine

My new book is out: The Next Job Success Engine — Building an AI-Run Job Search Around the Next Five Years.

It's the complete system in one place: define your job criteria once, in writing; let an AI agent sweep, filter, tailor, and apply on a schedule; and build the professional image that makes recruiters come to you. The point is not the next application. It is the next five years.

ORDERING LINK:

From the book — Chapter 1 and the opening of Chapter 2:

Chapter 1 — Before You Begin: How These Tools Actually Work

This guide asks an AI to do real work for you — search, judge, write, apply, publish. If you have never looked under the hood, some of that will sound like magic, and magic is hard to trust or supervise. This short chapter is the level-setter: what these tools are, how they differ from each other, and why they consume what they consume. No mathematics, no jargon without a plain-English translation. Everything after this chapter assumes only what is explained here.

Generative AI, in plain terms

The tools in this guide are built on large language models — software trained on enormous amounts of text (books, articles, websites, documentation) until it becomes very good at one specific trick: given some text, predict what text plausibly comes next. Ask a question, and the model generates an answer one small piece at a time, each piece chosen because it fits everything before it. That is why the category is called generative AI: it generates new text rather than looking answers up.

Three consequences matter for everything in this guide. First, the model is not a database: it does not retrieve facts, it produces plausible language, which is why it can sound completely confident and be wrong (the factual-invention risk in Section 8.2 is exactly this). Second, it has no memory of you between conversations unless a product deliberately adds one — the memory files described in Section 2.2 are an added layer, not a property of the model. Third, 'learning' mostly happened before you ever met the tool, during training; a chat session does not retrain it. When this guide says the agent learns your preferences, it means it writes them down and re-reads them — closer to a good assistant's notebook than to a brain changing.

2.1 What You Are Building

Used ad hoc, AI speeds up the parts of a job search that were never the bottleneck — a cover letter here, a resume tweak there — while leaving the real failure modes untouched: criteria re-decided on every listing, applications scattered with no record, an inbox where the important message drowns, a public profile that says whatever it happened to say. That takes a system, not a better prompt: decisions made once, in writing, executed by an agent on a schedule, with a strategy layer keeping the whole thing pointed at the right future.

The system has three working parts, plus the layer that steers them:

  • The application machine. A scheduled sweep that searches job boards and company career pages several times a day, filters every posting against a rule sheet you wrote once, tailors your resume to the survivors, and submits applications on your behalf.
  • The monitoring system. A watch on your inbox that classifies everything job-related — recruiter outreach, interview requests, status changes, rejections — so nothing important is ever buried, and replies you sent are never left hanging.
  • The digital image. 'Image' here means reputation, not a picture: the impression of you that your digital footprint leaves — what a recruiter concludes from your profile, your posts, and your search results before you ever speak for yourself. A managed online presence — profile, content, engagement, and a personal publishing channel — run to a written standard, so your public professional identity is deliberate instead of accidental.
  • The strategy layer. A quarterly, AI-assisted review of where your career is going: role trajectory, skill gaps, certification value, and portfolio projects — so the machine is chasing the right future, not just the next opening.

How the parts interlock. The strategy layer writes the criteria; the application machine executes them at volume; the monitoring system feeds every outcome — replies, rejections, the actual questions interviewers ask — back as data; and each quarter the strategy layer re-reads that data and rewrites the criteria. The digital image runs underneath the loop, compounding quietly, so that when the machine finds the right role, the public record already supports the claim. Section 6.1 develops the strategy layer in full; the sections between here and there build the loop piece by piece.

The operating principle across all three: you make decisions once, in writing, and the agent executes them repeatedly. Your ongoing job shrinks to reviewing drafts, answering the occasional question only you can answer, and giving one-word approvals.



Monday, October 12, 2026

You Don't Know What You Don't Know

 There's an old Greek story about a kid who flew too close to the sun. Daedalus — the craftsman who built the wings, the expert in the room — told him exactly what not to do. Don't fly too high, the sun melts the wax. Don't fly too low, the sea soaks the feathers. Icarus nodded, strapped on the wings, and flew straight at the sun anyway.

The moral everyone remembers is about arrogance. The quieter moral is this: Icarus didn't ignore Daedalus because he was brave. He ignored him because he didn't know enough to understand the warning. You can't evaluate advice you don't have the framework to process, so you dismiss it. He didn't know what he didn't know — so he ignored the expert altogether.


Daedalus was the SME. 

Every conference room has one. It usually starts like this:

"Make my security like my fast food. A kiosk I manage myself."

The SME raises a hand — worried about safety risks, about what happens when you automate a process you don't fully understand. The answer comes back fast: fire him, hire more developers, when AI runs it all we won't need him.


And then, the caption that writes itself: the automation plan failed, because they didn't listen to their SME on requirements. They thought he was being over cautious, just looking out for himself, or trying to overcomplicate what they believe should be simple to automate.


The scramble

This is the part nobody warns you about. The plan fails, and the first instinct is to throw headcount at it. Because a manager who truely thought his people were expendible will also believe they are easy to replace.

"Hire more developers."

"It won't matter. They don't understand the process."

"Then hire back one of the SMEs!"

Read that exchange again, because it's the whole parable in six lines. Developers are not interchangeable with experts. Ten developers who don't understand the process will produce the failure ten times faster, with better tooling. The manager finally arrives at the right answer — bring back the SME — one catastrophe too late.

The punchline that isn't funny

"No one wants the short contract."

"Word got around."

"It's a niche field and nobody qualified wants to work for you now."


"But I hear corporate offered him your job."


That last line is the one that stings, because it's true. Niche expertise is a seller's market. The SME you fired didn't disappear — he got a better offer, probably from someone who watched what you did and decided to do the opposite. Trust, once violated, doesn't come back on a six-month contract. And in a small field, everybody talks.

The wax in the wings

Here's what the manager never understood, and what Icarus never understood either: the SME's real value was never in his hands. It was in his head. The tacit knowledge — why the process has that weird exception, which vendor lies about their uptime, what that alert actually means at 2 AM versus what the runbook says it means. None of that is in the wiki. None of it is in the tickets. It walks out the door with the person, and no amount of AI generates it back, because the AI was trained on the documentation, and the documentation was always the sanitized version.

You can automate the doing. Someone still has to own the knowing. Fire the knowers and you don't get efficiency. You get a very expensive education in everything you didn't know you didn't know.

Daedalus built the wings. Icarus just wore them. Somewhere in your org chart there's a Daedalus with his hand raised — the only question is whether anyone in the room knows enough to listen.

The Greeks called it hubris. We call it a digital transformation initiative. 

The wax melts either way.


Friday, October 9, 2026

Forty-Seven Days and the Death of the Spreadsheet

There is a spreadsheet in your organization. It has a tab with certificate expiry dates on it, and a name next to each one. You know the spreadsheet. You might even own the spreadsheet.

I have bad news about the spreadsheet.


Last April, the CA/Browser Forum voted to cut the maximum lifetime of a public TLS certificate from 398 days down to 47. It's happening in steps: 200 days starting last March, 100 days starting next March, and 47 days by March of 2029. Nobody voted against it. The browsers enforce it by simply refusing to trust anything longer.

That's 7.77 renewals per certificate per year, up from less than one. And here's the part most write-ups bury: the domain-validation reuse window — how long the certificate authority will take your word that you own the domain before making you prove it again — drops to 10 days. So nearly every renewal needs a fresh proof of ownership. If your process involves a human clicking a validation email or pasting a DNS record, get ready to do that for every certificate, every month, forever.

DigiCert and Omdia surveyed senior IT leaders this year. Forty-seven percent still track certificates manually, mostly in spreadsheets. Only about a third have a complete, current view of what they actually hold. Let that sink in: the industry just 8x'd the renewal treadmill, and half the players in the game don't even know how many certificates they own.

I've been in the key business for a long time

Keys, certificates, HSMs, multitenant key structures — this is my lane. I hold patents in it. And I can tell you the thing nobody at the vendor table wants to say out loud: the problem was never the certificates. The problem is the org chart.

Certificate renewal by hand works right up until the person who owns the spreadsheet goes on vacation, changes jobs, or gets reorg'd under a manager who never reads their email. Then a public-facing cert expires on a Saturday and suddenly everybody in the company is learning the phrase "certificate transparency logs" at 2 AM. I've seen it. Every shop has a story like this, and every shop swears it won't happen again, and then the spreadsheet grows another tab.

The 47-day rule doesn't create this failure mode. It just makes the failure mode arrive eight times faster. A process that was barely held together by one diligent person at a one-year cadence is not going to survive a monthly one. Full automation isn't a nice-to-have anymore. It's the only way the math works.

But automation is not a plan

Here's where I get spicier, because everybody's nodding along about ACME and centralized lifecycle tools right now, and half the nodding people are about to automate themselves into a worse outage than the manual process ever gave them.

A misconfigured renewal pipeline doesn't fail one certificate at a time. It fails all of them at once, at machine speed. A bad deploy to your cert tooling can revoke and reissue thousands of certificates before anyone's pager goes off. The manual process was slow, but it was slow in a way humans could interrupt. An automated process that nobody monitors is a loaded gun with the safety off — it'll go off exactly when you're asleep.

So yes: automate everything. Inventory every certificate, give each one an owning team instead of a single person, automate issuance and renewal with ACME, and build the pipeline. But then build the monitoring for the pipeline: expiry alerts that are independent of the renewal tool itself, alerts at 30, 14, and 7 days that go to someone who will actually act, and a periodic reconciliation that compares what the tool thinks it manages against what actually exists. Because here's the dirty secret of the DigiCert number — most shops discover their true certificate estate during automation. You thought you had 4,000 certificates. The scanner found 11,000. Which of the 7,000 nobody knew about is expiring next week?

The spreadsheet is a person, and the person is leaving

Manual certificate management worked because it had a human in the loop who cared. The 47-day cycle removes the loop. That's fine — machines are better at loops. But the human who cared has to be replaced by a human who owns the automation, not by a dashboard nobody opens.

The destination is genuinely better. Shorter-lived certificates mean a compromised key has a shorter shelf life, and a fully automated estate renews itself while you sleep. The journey is where the outages live: in the three-year window where you're automating a process you never fully understood, discovering certs you never knew existed, and trusting a pipeline you haven't stressed yet.

Start with the inventory. Not the tool, not the dashboard — the inventory. You can't automate what you can't see, and you can't monitor what you don't know you have. The spreadsheet was never a certificate management system. It was a memory, and memories expire faster than certificates ever will.

Timeline: CA/Browser Forum Ballot SC-081v3 — 200-day max from March 15, 2026; 100 days from March 15, 2027; 47 days (and 10-day domain-validation reuse) from March 15, 2029. Sources: CA/Browser Forum ballot record; DigiCert/Omdia 2026 certificate-management research as reported by Imperva.

The Machine Said "I Am Alive" and Everyone Missed the Point

I saw a cartoon today: a guy at a computer, telling it to say "I am alive." The machine prints out

I AM ALIVE

The guy stares back, wide-eyed: "oh my god."

It's funny. It's also the entire AI debate in one panel.

Scroll through the comments on something like that and you'll see two familiar reactions. One group shrugs: Relax, it's just repeating a prompt. The other group tenses up: This is how it starts — one day it won't be a joke.

Both reactions make sense. Both also miss the real point.

Because here's what actually happened in that cartoon: a human told a machine to say some words. The machine said the words. And the human immediately reacted as if the words carried intent.

That's the part worth paying attention to. Not whether the machine is alive — it isn't, and "I AM ALIVE" on a screen means exactly as much as "I AM ALIVE" on a bumper sticker. The interesting part is how quickly we go from giving the instruction to believing the performance. The risk was never that the machine wakes up. The risk is that we stop noticing when a system is simply doing what it was told in situations where "doing what it was told" isn't enough.

I work with this stuff — not in the abstract, but in production systems where real money moves and a wrong answer isn't a philosophical puzzle, it's an incident. People who build and maintain these systems don't get to live in either extreme. Complacency gets you breached. Catastrophizing gets you frozen. The job is understanding exactly what the system does, what it doesn't, and designing around that reality.

Now, the job-loss fear — that one deserves respect. Every major technological shift has displaced people. Lamp lighters, bodgers, candlestick makers — those were real jobs held by real people, and they disappeared because something more efficient arrived. Telling people their fear is silly because "progress" is how you get resentment, not adaptation.

But the opposite mistake matters too: dismissing concerns because they sound dramatic. Some AI safety researchers overestimate timelines or mechanisms, sure — but "wrong about the details" isn't the same as "not worth listening to." Anyone who has sat through a serious risk review knows the person flagging the unlikely scenario is often the only one who read the whole threat model.

So where does that leave us? In the middle — which is where all the useful work happens anyway.

Every technology becomes normal not because it's perfect, but because we learn how it works and how to make it safe enough. Electricity didn't become safe by pretending it wasn't dangerous, and it didn't become widespread by refusing to wire houses. We built breakers, grounding wires, and codes because we understood the risks and addressed them.

AI is the same project. Learn what it actually does — right now, sophisticated pattern matching with a talent for sounding confident. Learn what it can't do — including knowing when it's wrong, caring about outcomes, or understanding the difference between words and meaning. Take concerns seriously, including the ones that feel exaggerated, and do the unglamorous work of addressing them: testing, guardrails, oversight, and honesty about limitations.

The guy in the cartoon got it backwards. The machine saying "I am alive" isn't the scary part. The scary part is the human saying "oh my god" — and believing it.

Tuesday, October 6, 2026

The Patch Paranoia Tax

The new generation of AI-driven vulnerability scanners has created something I didn't expect: paranoia. These systems ingest everything, correlate everything, and hand you a list of ten thousand findings with red severity tags — and suddenly the entire security org is sprinting on a treadmill, pushing patches daily, chasing a queue that regenerates faster than any team can clear it.

I'm going to say the quiet part: most of that queue doesn't matter.

What actually gets you breached

Nobody gets breached because they were three days late on a patch for a vulnerability with no known exploit in the wild. Breaches come from the boring stuff: the server running an OS that's been end-of-life for four years, the well-documented critical vulnerability with a public exploit that everybody knows about and nobody prioritized because the scanner buried it under nine thousand theoretical findings.

The KEV catalog exists for a reason. It's the short list of flaws that are actually being used against real targets right now. If your patching program isn't organized around that list first, you're doing theater — expensive, exhausting theater that burns out your engineers and impresses nobody who matters.

The part the vendors won't tell you

Here's what the patch-everything-daily crowd leaves out: an untested patch is its own vulnerability. I've watched rushed patch cycles take down production systems that the vulnerability never would have touched. A bad patch pushed at 2 AM because the scanner said CRITICAL will ruin your week faster than most CVEs will.

So let me be clear about what I'm not saying. I'm not saying patching doesn't matter. I'm saying that testing and validating what you push — confirming it works, confirming it's stable in your environment — is more important than the speed of the cycle. A patch that breaks authentication on a Friday is worse than a patch that ships on Monday after proper validation. Full stop.

The goal was never "patch fast." The goal was "be hard to breach without breaking yourself in the process." Somewhere along the way, the industry confused motion with progress.

Bleeding edge bleeds

Daily bleeding-edge patch cycles sound responsible. They sound like diligence. In practice, they're a great way to convert your change-management process into a slot machine — pull the lever every morning and hope production still works by lunch.

Mature shops know this. They patch the things that are actually dangerous, they test what they ship, and they spend the hours they saved on the unglamorous work that actually moves the needle: killing end-of-life systems, segmenting networks, getting backups to a state where recovery is boring instead of heroic.

The reframe

AI didn't create this problem, but it supercharged it. When a machine can generate ten thousand findings before your coffee cools, the limiting factor was never detection — it was always judgment. Knowing what to ignore is the skill. The scanner can't tell you that. Your experience can.

So here's my heretical take, stated plainly: patch less, but patch what matters, and test everything you ship. The paranoia tax — the burnout, the broken deployments, the 2 AM firefights caused by your own remediation — costs more than the vulnerabilities it pretends to prevent.

I learned this one the hard way years ago: a critical-rated patch, rushed out on a Friday afternoon because the scanner demanded it, took down authentication for a system the vulnerability couldn't even reach. We spent the weekend restoring service from a threat that never existed, while the actual exposed system — three OS versions behind, running a service with a public exploit — sat untouched because it was buried on page nine of the findings. That weekend rewired how I think about patching.

Slow down. Aim.

Motion isn't progress.
Noise isn't risk.
Speed isn't safety.

Monday, October 5, 2026

The Machine That Tells Me What's Happening in Atlanta

I haven't manually looked up "things to do in Atlanta" in months. Not because I stopped caring — I own property there, my wife's family business touches that market, and half my weekends involve somebody asking me what's going on down there. And not because I got lazy. I stopped because AI finally solved the part of the workflow that scripts never could: the judgment.

Here's what runs while I'm asleep.

The problem nobody thinks is a problem

"What's happening in Atlanta this weekend?" sounds like a five-second question. It's not. The answer is scattered across a dozen event sites, venue pages, and social feeds, each with its own format, its own idea of what counts as an event, and its own way of burying the date three clicks deep. Most people check two or three sites, miss half of what's actually on, and give up. Everybody does this. We all just accept that knowing what's going on in a city requires being a part-time research assistant.

How AI Evolved My Workflow

I wasn't checking sites manually before this — I'm not a masochist. I had a scripted solution, and it worked, mostly. It pulled from paid API access to event aggregators, scraped RSS feeds where they existed, and where they didn't, it chewed through raw HTML. Then it dumped everything into a sheet or a JSON blob and I built the calendar view off that.

So the evolution went: manual → scripting → AI. And I want to be honest about what each step actually bought me.

The scripting phase was brittle in exactly the ways you'd expect. APIs changed their pricing or their schemas. RSS feeds died quietly. HTML scrapers broke every time a site redesigned — which is constantly. I spent more time maintaining the plumbing than benefiting from the water. It worked, but it needed a caretaker, and the caretaker was me.

Then AI entered the picture and the whole maintenance burden evaporated.

The AI Does the Reading Now

Here's the current state: the sheet is aggregated by AI, on a schedule. It checks the sites itself — and I mean actually checks them. It follows links, reads the pages, and understands what it's looking at. No API keys to babysit, no RSS feeds to mourn, no scrapers to repair after every redesign. When a site changes its layout, the AI just... reads the new layout. The brittleness is gone because there's nothing brittle left to break.

To put the contrast plainly: scripts do pattern matching — brittle selectors that depend on a page's structure staying exactly the same. AI does semantic extraction — it understands what an event is, regardless of how the page happens to be built. Scripts break when the HTML changes; AI does contextual inference and adaptive parsing, so a redesign is just a different way of saying the same thing.

But the real upgrade isn't durability — it's judgment. The AI makes intuitive calls about which events actually matter: what's happening near the properties we rent, what our hospitality guests would actually want to know about, what's worth surfacing versus what's noise. It ignores trivia-night listings nobody travels for. It prioritizes events within a few miles of our properties. It knows the difference between a recurring weekly drink special and a one-off festival worth planning a weekend around. A scraper can't do any of that. A scraper gives you everything and lets you drown. The AI curates.

That sheet still feeds the same public month-view calendar — open the link, no login, works on a phone. But now the calendar isn't just a convenience for me. It's substantially more functional as a driver for our hospitality business: guests get a genuinely useful guide to what's on near their stay, and it updates itself while we sleep.

The pipeline is the same shape — websites → AI → spreadsheet → web app → human — but the middle step went from dumb plumbing to something with discernment. That's the whole story in one sentence.

The pattern

Once you see it, you see it everywhere. I have another one that watches rental notifications from Houfy and Airbnb, figures out which cleaner should get which job, and handles the assignment and payment flow. Same shape: messy inputs from multiple platforms, decisions in the middle, clean output at the end, no human required until something genuinely needs one.

The through-line isn't any particular tool. It's the architecture: AI as the connective tissue between systems that were never designed to talk to each other. The web wasn't built to feed my spreadsheet. My spreadsheet wasn't built to power a public calendar. The AI doesn't care. It reads what exists, translates, and moves on.

What I'm getting at

Most of the conversation about AI right now is about the interface — the chat window, the prompt, the demo. That's the least interesting part. The interesting part is what happens when you stop treating AI as something you talk to and start treating it as something you deploy: a worker with memory, on a schedule, with write access to your systems, quietly keeping the machinery running.

And here's the reframe that matters: AI didn't replace me. It replaced the parts of the workflow that were never worth human attention in the first place — the babysitting of API keys, the repairing of scrapers, the sifting of trivia from signal. None of that was work. It was glue. And the glue is gone.

I didn't set out to write a philosophy of automation. I just got tired of checking five websites. But somewhere between the scraper and the spreadsheet and the calendar, the philosophy wrote itself.

The best AI isn't the one you chat with — it's the one that quietly removes entire categories of work.

Wednesday, September 9, 2026

Dorm Room, Work Laptop: Setting Up a Student's Digital Life

Written by Greg Schneider, Contributor, 2026

September is move-in season, and somewhere between the mini-fridge and the extra-long twin sheets, a laptop becomes the most important thing a student owns. It's the classroom. It's the bank. It's the front door to a part-time job, the financial aid office, and every account that matters. And most students set it up in about four minutes — open the lid, connect to Wi-Fi, done.

There's a better way, and it takes about an hour. Do it once, at the start, and the machine mostly takes care of itself for the next four years.

Start with passwords, because everything else hangs on them

Install a password manager before anything else. One strong master password — a phrase, not a word, something like three or four unrelated words strung together — unlocks a vault that holds a different, random password for every account. The student doesn't have to remember thirty passwords. They have to remember one.

Then turn on multi-factor authentication, starting with the school email account. School email is the master key to a student's life: it resets the bank password, the loan portal password, the housing account password. If one account gets the extra lock, it's that one. Bank and financial aid accounts come next.

The toggles that do the quiet work

Automatic updates: on. Operating system, browser, everything. Most real-world compromises don't involve a genius hacker picking a lock — they involve an old, known hole that a patch closed months ago and nobody installed. Set updates to automatic and that whole category of problem mostly disappears.

Device encryption: on. On Windows it's BitLocker; on a Mac it's FileVault. On most machines it's a single toggle in the settings, and it means that if the laptop is stolen out of a library or a car, the drive is a brick of scrambled data instead of an open filing cabinet. No performance hit worth mentioning. No reason to skip it.

The lock screen: quick. Set the screen to lock after two or three minutes of inactivity, and build the habit that goes with it — lid down when you walk away, even in the dorm, even "just for a second." A dorm room has a roommate, and the roommate has friends, and the door is open more than anyone admits. This isn't about distrusting people. It's about not leaving the bank open on the desk.

Backups a student will actually have

Here's the honest rule: a backup system a student follows beats a perfect system they abandon by October. So keep it stupidly simple.

Sync documents to the cloud account they already have — school papers, notes, and photos live where a dead laptop can't take them with it. Then add one automatic backup of the whole machine if the platform offers it, set it, and forget it. That's it. The test of a backup is never whether it exists. It's whether the 2 a.m. laptop failure, the week of the term paper, is an inconvenience or a catastrophe.

Separate the lives

A student's laptop usually holds at least three lives: school, personal, and a job. They shouldn't all share one password, and they shouldn't all share one browser profile either. The password manager handles the first part. For the second, a separate browser profile for the part-time job — or at minimum, keeping work logins out of the profile that's signed into everything else — means a compromise in one corner doesn't unlock the whole house.

The scams that come looking for students

Campus is a target-rich environment, and the pitches are tuned to student life:

  • The fake job offer. A "part-time position, flexible hours, work from your dorm" email ends with a check — deposit it, buy supplies, forward the rest. The check is counterfeit, and when it bounces, the money forwarded is gone and the account is on the hook. Real employers do not mail you a check before you've worked a day.
  • The textbook and housing listings. Prices too good, sellers who can't meet in person, payment demanded by gift card or wire. If the apartment can't be walked through and the book can't be handed over in the campus coffee shop, walk away.
  • The official-looking notice. Financial aid "verification," a registrar "hold," a library "overdue account" — phishing dressed as university business, timed for the first stressful weeks. The defense is boring and total: don't follow the link in the message. Open the school portal the way you always do and check there.
  • The QR sticker. Codes pasted over parking meters, flyers, and payment signs around campus that lead somewhere else entirely. If a sticker looks layered, crooked, or stuck on top of another code, type the address yourself instead.

The first-hour checklist, in order

Screenshot this and work top to bottom:

  1. ☐ Password manager installed; one strong master passphrase set
  2. ☐ School email password changed to a unique, generated one — and MFA turned on
  3. ☐ MFA on bank and financial aid accounts
  4. ☐ Automatic updates on for the OS and the browser
  5. ☐ Device encryption (BitLocker or FileVault) switched on
  6. ☐ Screen set to lock in under three minutes; lid-close habit started
  7. ☐ Documents syncing to cloud storage; one automatic backup running
  8. ☐ Separate browser profile for the part-time job

One hour, eight boxes. After that, the laptop stops being a thing to worry about and goes back to being what it was supposed to be: the tool that carries a student through the semester.

Wednesday, August 12, 2026

Agile for One

Written by Alanna Gray, 2026

Agile for One

Almost everything written about Agile assumes a room. A team around a board, a Scrum Master keeping time, planning poker cards going up in unison. My operation has none of that. Most days, the team is me — running short-term rentals in Atlanta, handling guest messages, cleaner schedules, maintenance, pricing, and the books. So the honest question is: what does Agile even mean when the standup has one chair?

More than you’d expect. But not all of it. Solo Agile is mostly an editing job — keeping the parts that manage the work and cutting the parts that were only ever managing the people.

What survives

A visible board. If the work only exists in my head, it competes with everything else in my head, and the loudest task wins instead of the most important one. My board is nothing fancy — columns for what’s coming, what’s in progress, what’s waiting on someone else, and what’s done. Guest issue, turnover prep, a repair quote, quarterly taxes: all on the board. The point isn’t the tool. The point is that on a tired Friday afternoon, I can see the whole operation at a glance instead of reconstructing it from memory and inbox guilt.

A work-in-progress limit of one or two. Teams limit WIP to stop context-switching. Solo, the same math applies harder, because there’s nobody to absorb the spillover. When I catch myself with five things half-started — a reply drafted but not sent, a supply order open in a tab, a cleaner schedule half-updated — nothing is actually moving. One active task, one on deck. Everything else waits on the board, written down, where it can’t nag me. Multitasking for a team of one is just slow-tasking with better branding.

A short weekly review, run like a real meeting. Thirty minutes, same time every week, with an agenda: what got done, what’s stuck, what’s coming in the next two weeks. It feels faintly ridiculous to hold a meeting with yourself — right up until you skip it three weeks running and realize you’re operating entirely on whatever shouted loudest. The agenda matters. Without one, the “review” becomes scrolling your messages and calling it planning.

A written definition of done. On a team, other people check your work. Solo, you are the check, and “done” quietly drifts: the listing update is done except for the photos, the expense log is done except for two receipts. I keep a short checklist for the recurring jobs — a turnover isn’t done until the clean is confirmed, supplies are restocked, and the next guest has the door code. Done means the same thing on a good week and a bad one because it’s written down, not because I feel thorough that day.

Sprints matched to the season. My work has seasons — summer bookings, holiday surges, the quieter stretches in between. Long improvement projects don’t fit in peak season, so I don’t schedule them there. Renovations, system cleanups, and process fixes go in the slow weeks, in two-week sprints with a clear finish line. Peak-season sprints shrink to one week and cover operations only. A cadence that ignores your busy season isn’t discipline; it’s a plan to feel behind four months a year.

What gets cut

Estimation rituals built for teams exist to align a room full of people — story points, poker, t-shirt sizes. Alone, I estimate in the only unit that matters: hours of my week. A task gets a rough time guess and a deadline. That’s it.

Standups performed for an audience of zero. If I want a daily check-in, the board gives me one in ninety seconds — what’s in progress, what’s blocked. No ceremony required.

Any artifact nobody will ever read. Burndown charts for one person. Velocity reports to an audience of me. If a document doesn’t change a decision I make, it doesn’t get produced. Process theater is still theater when the audience is just you, and it costs the same hours.

The auditor’s footnote

Here’s the twist nobody mentions about working solo: in an audit, the person doing the work and the person controlling the work are supposed to be different people. When you’re a team of one, you’re both — which means the controls have to live on paper instead of in a second pair of eyes. So I write things down. Decisions, prices I quoted, why I chose a vendor, what “done” meant for that job. Future me is the auditor, and she has no memory of my good intentions. The board, the checklists, the review notes — that’s the audit trail, and it’s what makes one person running an operation different from one person just being busy.

The weekly rhythm, on one page

  • Monday, 30 minutes: Weekly review. Check the board against the calendar — bookings, turnovers, deadlines. Pick the week’s sprint goal: one main thing, not five.
  • Daily, 5 minutes: Look at the board. One task in progress, one on deck. Move cards, don’t carry them in your head.
  • Midweek, 10 minutes: Check the “waiting on” column. Anything sitting there more than three days gets a follow-up message today.
  • Friday, 15 minutes: Definition-of-done sweep. Close out or honestly re-date everything in progress. Note one thing that went wrong and one fix for it — two sentences in the review notes.
  • Monthly, 1 hour: Season check. What’s the next busy stretch, and what has to be true before it starts? Schedule slow-season projects into the slow weeks now, while you’re calm enough to mean it.

That’s the whole system: a board, a limit, a checklist, a half hour a week. Everything else in the Agile toolkit was built for coordinating other people — and on the days the team grows, it can come back. Until then, the parts that remain earn their keep every single week.

Wednesday, July 8, 2026

How to Read a Job Posting

Written by Greg Schneider, Contributor, 2026

How to Read a Job Posting

A job posting looks like a description of a job. It isn’t, quite. It’s a document with an author, an agenda, and usually a committee — and once you learn to read it that way, the whole thing gets less intimidating and more useful.

Every posting is written by several hands. The hiring manager wrote the parts about the actual work. HR added the parts about the company. Someone in legal added the parts at the bottom. A recruiter may have rewritten all of it to match a template. None of those people were trying to describe one single human being. Keep that in mind, and the posting stops being a verdict on you and starts being what it actually is: a rough sketch of a problem a team needs solved.

The requirements list is a wish list

Start with the longest part of most postings, the bulleted list of requirements. Read it as a wish list, because that’s what it is. Several people contributed their “it would be great if they also had…” and almost nobody went back and cut it down to what the job truly needs.

The hiring manager’s real must-haves are usually two or three items, and they’re often near the top of the list — the skills mentioned first, mentioned again in the duties, or named in the first paragraph. Everything after that is a preference wearing a requirement’s clothes.

That’s also why the years-of-experience numbers are softer than they look. “Five years required” usually means “we want someone who won’t need this explained from scratch.” If you’ve done the core work — in a job, in training, on a project you can talk about in detail — you’re closer than the number suggests. The standing guidance from career advisors is consistent on this: if you meet most of the core skills, apply. Job ads describe the perfect candidate. Companies hire real ones.

Read the duties, not the title

The same job wears five different titles at five different companies. “Associate,” “specialist,” “coordinator,” “analyst,” and “technician” can all describe identical work — and sometimes the grander title pays less because a smaller company hands out titles instead of raises. Title inflation and deflation are both real, so compare postings by their duties, not their names.

The duties paragraph is where the actual job hides. The first two or three responsibilities listed are usually what you’ll spend most of your week doing. Anything described with specific tools, specific people, or specific outcomes is probably real. Anything that could be pasted into any company’s posting unchanged — “collaborate with stakeholders,” “wear many hats,” “thrive in a dynamic environment” — is boilerplate, and it tells you nothing except that nobody proofread it with you in mind.

Reading the salary band

Where a range is posted, read it in thirds. Employers generally expect to hire somewhere in the lower-to-middle part of a band for someone growing into the role, and reserve the top for candidates who check nearly every box and can start at full speed. So if your experience honestly matches most of the posting, picture yourself landing around the middle, not the ceiling — and if the bottom of the range is below what you can accept, that’s real information worth having before you invest hours in applying.

Red flags worth respecting

None of these is automatic, but each one deserves a question:

  • The unpaid “trial project” that’s really free work. A short skills exercise is normal. Producing something the company can actually use, unpaid, over several days, is not an exercise — it’s an invoice they declined to pay.
  • Three jobs in a trench coat. “Fast-paced environment” plus a duty list spanning what are clearly three separate roles usually means the last person quit and they’re hoping one hire absorbs all of it.
  • The evergreen posting. The same role re-listed for months on end may mean a team that can’t decide, a budget that isn’t approved, or a listing kept up just to collect résumés. Apply if it fits — but don’t arrange your hopes around it.

Green flags worth noticing

  • A named team and real tools. “You’ll join the four-person support team using X and Y” means someone specific is waiting for help.
  • A clear first-year outcome. “By month six you’ll own…” tells you the manager has actually pictured the job.
  • Duties written in plain language. Clear writing about work usually means clear thinking about it.

Then make your moves

Three things, in order. First, mirror the posting’s honest language: if they say “ticket queue” and you’ve run a ticket queue, use their words — not to game anything, but because the person (or software) scanning your application is matching against this document. Only mirror skills you genuinely have; the interview will find the rest. Second, in your application or cover note, answer the two or three real requirements up top, plainly: here’s the core thing you need, here’s where I’ve done it. Third, save a copy of the posting — a screenshot or a PDF — the day you apply. Postings vanish when the listing closes, and the exact text is gold when you’re preparing for the interview a week later.

The 60-second decode

  • ☐ Find the two or three real must-haves (listed first, repeated in the duties)
  • ☐ Count the duties honestly — is this one job or three?
  • ☐ Ignore the title; compare duties across companies instead
  • ☐ Split the salary band in thirds; picture the middle
  • ☐ Check the dates — posted last week, or re-listed since spring?
  • ☐ Scan for one green flag: named team, named tools, or a first-year outcome
  • ☐ Save a copy of the posting before you apply

A posting isn’t a test you pass or fail before you’re allowed to try. It’s a committee’s best guess at what help looks like. Read it for the job underneath — then answer that job, in its own words, with what you’ve actually done.

Wednesday, May 13, 2026

Small Portfolio, Many Doors

Written by Alanna Gray, 2026

Small Portfolio, Many Doors

May is when the phone starts ringing. School is about to let out, families are planning summer trips, and every booking channel I use wakes up at once. I run a handful of properties. That's it. But a guest can reach those same few rooms through several different doors — the big listing platforms, and our own direct booking site. Done right, that's reach. Done carelessly, it's how a small operator ends up double-booked on a Saturday night with two families and one set of keys.

Here's the thing nobody tells you when you start: the doors are not the hard part. Anybody can open another listing. The hard part is making sure every door opens into the same house.

One calendar, one truth

The first rule I audit myself on, every spring: there is exactly one source of truth for availability, and it is not any single platform's calendar. It's mine. Every channel syncs from it, and I check the sync the way I used to check a bank reconciliation — not because I expect fraud, but because drift is what happens to anything nobody verifies. A guest who books a room that isn't actually available doesn't care which software failed. They remember that I failed. Double-bookings aren't a technology problem. They're a controls problem, and controls are kind of my whole career.

Same house, every door

Second rule: a guest should never be able to tell which door they came through. Same photos. Same description. Same house rules, same check-in window, same everything. The moment one listing promises a feature another doesn't mention, or an old photo set survives on a channel I forgot to update, I've created two different properties in the guest's mind — and the real one will lose the comparison every time.

This sounds like marketing advice. It isn't. It's audit discipline. Inconsistent records are where small problems hide until they become expensive ones. When every listing says the same thing, a mismatch stands out immediately. When they don't, you're the last to know.

Know what each door costs

Every channel takes its cut, and they don't all take it the same way — some charge the host, some charge the guest, some split it, and the percentages reward a close read. Before summer, I sit down and run the actual math per channel on a real booking: what came in, what the platform kept, what landed in the account. Not the advertised rate. The settled number.

That math tells you what a channel is actually buying you. A door that delivers steady out-of-town families at a fair fee is worth keeping wide open. A door that mostly delivers discount-hunters and headaches at the highest cut might be worth narrowing — fewer dates, a longer minimum stay — or closing entirely. Doors are tools. Nobody said you have to keep all of them.

Direct booking is a relationship, not a discount war

Our direct site exists for one reason: the guests who come back. The family that stayed last summer and wants the same week this year shouldn't have to win an auction against the open market to get it. Direct booking lets me hold dates, communicate like a person instead of a platform template, and know who's actually coming.

What it is not is a price war. I don't undercut my own listings by a dollar and call it strategy. Guests who book direct get the same rate, better communication, and a host who remembers them. That's the offer. Trust compounds better than discounts.

Never pad the portfolio

Last rule, and it's the one I'd carve over the door: list only what you operate. No borrowed photos. No "coming soon" properties that don't exist. No stretching a description — a quiet street is not "steps from the action," and a room that sleeps four does not sleep six because a couch exists.

A small portfolio can look bigger than it is, and the temptation to help it along is real. Resist it. Every booking you take under a promise you can't keep costs you more than the booking was worth — in refunds, in reviews, and in the slow work of rebuilding a reputation that took years to earn. Honest listings also filter for the right guests. The people who book exactly what a listing describes arrive happy. That is not a coincidence. That is the system working.

Before the season starts

  1. Reconcile the calendar. One source of truth, every channel synced to it, one manual spot-check per property before Memorial Day.
  2. Read your own listings like a guest. Every door, start to finish. Fix any photo, description, or rule that differs from the others.
  3. Run the real fee math per channel on your last few bookings. Decide which doors stay wide, which narrow, which close.
  4. Write your repeat guests directly — before the public calendar fills — and give them first claim on their dates.
  5. Strike every word you can't prove. If the property doesn't have it, the listing doesn't say it.

Summer rewards the operators who did this work in May. The doors take care of themselves. The house has to be true.