Is Vibe Coding the End of Standardized ERP?

By
August 27, 2026
Uncategorized
Leave a comment

I have heard rumours that some companies are starting to vibe code their own ERP systems. Is this the start of the decline of standardized ERP systems, and the start of company specific Business Operating Systems? If every business had its own OS, and an agentic framework, why is there any need to have standardized ERP systems?

It is a fair question, and one worth taking seriously instead of dismissing on reflex. But after digging into what is actually happening in the market, I do not think ERP is dying. I think something more interesting and more useful is happening at its edges.

What Companies Are Actually Vibe Coding

The companies experimenting with AI generated business software right now are almost entirely building at the periphery of ERP, not in its core. A Copilot Cowork style agent that reconciles a report. A custom approval workflow. A data cleanup script. A bolt on dashboard that nobody wanted to wait six weeks for IT to build. Very few organizations are vibe coding their general ledger, their costing engine, or their multi entity intercompany eliminations, and there is a good reason for that.

There is a real gap between “AI helped me build software” and “AI helped me build enterprise grade, auditable, multi user, transactionally consistent financial software.” That gap is where most of the current enthusiasm quietly runs out of road. One recent piece on the risks of vibe coding put it plainly: the danger is not that these tools fail to work. The software appears to work right up until the business reaches a level of complexity that exposes what was never built in the first place. Security, monitoring, compliance, and disaster recovery do not show up in a demo. They show up eighteen months later when something breaks and there is no vendor to call.

We Have Been Here Before

There is also a useful historical echo worth remembering. Standardized platforms like SAP, Oracle, PeopleSoft, and later NetSuite and Salesforce did not emerge in a vacuum. They emerged because “build your own” had already been tried extensively in the eighties and nineties, and the industry collectively decided that a professionally maintained, continuously improved, shared system was the better bargain. One system, supported by a vendor with thousands of customers absorbing the cost of getting tax law and audit controls right, beat a thousand bespoke systems each carrying that burden alone.

Vibe coding does not remove the reasons that decision was made three decades ago. It just lowers the upfront cost of relearning them the hard way.

Two Layers That Want Different Economics

The question of “why standardize if every business can have its own OS” collapses two layers of the business that actually want very different things.

The first layer is the system of record. This is the ledger, inventory, costing, tax, and consolidation logic. This layer wants low variance, not customization. Its value comes from being provably correct under audit, from producing the same math every quarter regardless of who is running the company, and from a vendor carrying the liability of getting VAT rules or SOX controls right across thousands of customers instead of one company carrying that risk alone. Agentic capability does not change the incentive to pool that risk and cost across an ecosystem. If anything it raises the stakes, because an agent posting a bad journal entry at two in the morning with no human review is a considerably scarier proposition than a person doing it.

The second layer is orchestration. This is how a specific company actually gets things done around that system of record. This is exactly where variance is valuable, and exactly where agentic frameworks and vibe coding are already winning, because it is low blast radius, fast changing, and does not need to survive a financial audit on its own merits.

The Composable Core, Not the Bespoke Empire

So the more likely outcome is not that every business ends up building its own ERP from scratch. It is something closer to a composable core: a thin, standardized, vendor maintained transactional spine, surrounded by a thick, company specific, largely agent authored layer of workflow, automation, and decision logic that talks to that spine through APIs. This is not a new architecture invented for the agentic era. It is basically the direction that platforms like Dynamics 365 Finance and Operations were already heading, with data entities and business events designed precisely so that logic could live outside the core without touching it.

The Business Operating System that gets discussed in these conversations is real. But it gets built on top of standardized ERP, not instead of it, because nobody actually wants to own tax engine liability, and no CFO wants to explain to auditors that the general ledger was vibe coded last quarter.

Where the Real Disruption Sits

If I had to point at where this trend genuinely threatens the standard ERP model, it would be three places.

The mid market and small business segment, where compliance and audit stakes are lower and the cost of a full ERP license and implementation is disproportionate to the size of the operation. This is where skipping a Tier 2 ERP entirely in favour of an agentic build of the operations layer is most economically rational.

Verticals with no good off the shelf fit, where companies already customize ERP into something barely recognizable compared to the base product. Vibe coding just makes that customization faster and cheaper. It is not a fundamentally new behaviour, it is an acceleration of an old one.

And the vendors themselves, who will not sit still and watch this happen. Expect Microsoft, SAP, and Oracle to lean hard into a “we are the trusted core, bring your own agents to the edges” positioning rather than fight the trend directly. Given where Copilot and Cowork are already headed inside the Microsoft ecosystem, this is not speculation. It is already the direction of travel.

The Verdict

Vibe coding is not the death of standardized ERP. It is the arrival of a cheap, fast way to build the layer of the business that ERP vendors were never well suited to build in the first place. The ledger stays boring, standardized, and vendor owned, because boring is exactly what you want from something an auditor has to sign off on. Everything wrapped around it just got a lot more interesting.

The Penguins Knew Before Your Steering Committee Did

By
August 27, 2026
Uncategorized
Leave a comment

John Kotter wrote Our Iceberg Is Melting as a fable for people who already knew his eight step change model and needed a way to explain it to everyone else without putting them to sleep. A colony of Antarctic penguins lives on an iceberg. One of them, an unremarkable penguin named Fred, notices the iceberg is riddled with cracks and will not survive the winter. Nobody wants to hear it. The leadership council is comfortable. The colony has always lived on this iceberg. Fred is not important enough to be believed.

The book is aimed at children and executives in roughly equal measure, which tells you something about how leaders actually respond to bad news about the platform they built their careers on.

I have spent enough years around D365 F&O implementations to recognize every penguin in that story. Most ERP failures are not technical failures. The system usually works. What fails is the eight step sequence Kotter is illustrating, and it fails in the same order every time.

Step One: Someone Has to Notice the Cracks

Fred does not manufacture urgency. He finds it, through unglamorous observation, and then has to fight to get anyone to look at what he found. In an ERP program this is usually the business analyst three levels down who has actually mapped the current state process and knows the general ledger reconciliation takes eleven days by hand. Nobody asked her opinion because the steering committee already decided the go-live date.

Urgency that is manufactured by a consultant in a kickoff deck does not survive contact with month four. Urgency that comes from someone inside the organization who found the actual crack tends to.

Step Two through Four: The Guiding Team Is Not the Org Chart

Louis, the head penguin, does not solve the problem alone, and he does not delegate it to a committee chosen by rank. He assembles a mixed group that includes NoNo the professional skeptic, because a guiding coalition that only contains believers cannot survive contact with the rest of the colony. NoNo’s objections get answered in advance instead of ambushing the project in month six.

I have sat in enough steering committees to know most of them are built from an org chart, not from who actually has credibility on the floor. A finance director with veto power and zero trust from the warehouse team is not a guiding coalition. He is a bottleneck with a title.

Steps Five through Seven: Short Wins or No Buy In

The colony does not wait for the whole migration plan before it sees a win. The penguins send scouts, they find a new iceberg, and they celebrate finding it long before anyone has actually moved. This is the part of the model most ERP programs skip entirely. Everything gets held for the big bang go-live, and by the time it arrives the organization has spent a year hearing about a future state it has never once been allowed to touch.

Every fit-gap workshop I have run that included a working demo of one solved process, even a small one, bought more goodwill than any status report ever has. People do not commit to a vision. They commit to evidence the vision is real.

Step Eight: The New Iceberg Has to Become Normal

The fable ends with the colony living on the new iceberg as though they had always lived there, and this is the step almost nobody in ERP world budgets for. Go-live is treated as the finish line. It is closer to the halfway mark. The old habits, the shadow spreadsheets, the workaround someone built in Excel because the new system was inconvenient in week two, all of that quietly recolonizes the organization unless someone is watching for it.

I have seen systems go live successfully and then watch the business slide back into its old processes within a fiscal quarter because nobody treated adoption as an ongoing job. The iceberg was new. The habits were not.

Why the Fable Works Better Than the Framework

Kotter could have written the eight steps as a slide deck. He wrote a story instead, because a story lets you see NoNo’s objection land and get resolved instead of reading a bullet that says manage resistance. It lets you watch Louis choose the guiding team instead of reading a bullet that says build a coalition. The mechanism becomes visible instead of asserted.

That is the actual argument for using fables and analogies in change management work generally, ERP or otherwise. An eight step framework tells people what to do. A story shows them what it looks like when someone does not do it, which is usually the more persuasive lesson.

If your organization is mid migration and something feels off, it is worth asking which penguin is missing. Often it is not a step in the model that got skipped. It is a specific person, the one who noticed the crack early and was not believed.

Our Iceberg Is Melting by John Kotter and Holger Rathgeber: https://www.amazon.com/Our-Iceberg-Melting-Succeeding-Conditions/dp/0399563911

Autopsy #11: The Change Management Afterthought

By
August 27, 2026
Uncategorized
Leave a comment

Cause of death: the entire session proved the system worked, and none of it proved anyone would use it.

Ninety minutes of demo. Every module clicked through, every workflow shown, every objection about functionality answered on the spot. Then, in the last five minutes, someone asks about training and adoption, and the presenter says something reassuring and short: “the interface is intuitive, users pick it up quickly,” maybe gestures at a slide with a generic icon of people around a laptop, and the meeting ends on schedule.

Nothing in those ninety minutes tested the only variable that determines whether an ERP implementation actually pays off: whether the several hundred people who currently do their jobs a certain way will actually do them a different way starting on a specific Monday morning. That variable got five minutes and a slide. Everything else got ninety.

What actually happened

A demo is, by construction, a test of the system in isolation. It shows what the software can do when operated by someone who already knows exactly which buttons to press, in exactly the right order, with no muscle memory pulling them back toward the old way of doing things. That’s a test of the product. It says almost nothing about the much harder problem sitting underneath every ERP rollout, which is that the system doesn’t fail because it can’t do the work. It fails, when it fails, because the people who were supposed to start using it on day one didn’t, or did so inconsistently, or found a workaround that quietly recreated the old process inside the new tool.

The demo cannot show this risk because the risk doesn’t live in the software. It lives in a warehouse supervisor who has run the same process for eleven years and has a system that works well enough for them, a controller who doesn’t trust the new close process until they’ve watched it succeed three months running, a data entry team that will, absent enforcement, keep using the spreadsheet they built in 2019 because it’s faster for them personally even if it creates downstream problems for everyone else. None of that shows up in a screen share. All of it shows up in the first ninety days of production.

Why it works on smart people

Functionality is legible in a way that adoption risk isn’t. You can watch a screen and evaluate, with reasonable confidence, whether a feature does what it claims to do. You cannot watch a screen and evaluate whether the accounts payable team, specifically, at your company, specifically, will actually change how they process an invoice exception, because that isn’t a property of the software being demonstrated. It’s a property of an organization that isn’t in the room.

Because functionality is the thing that’s easy to evaluate in real time, it naturally consumes the meeting. Evaluators default to spending their scrutiny where scrutiny is possible to apply, and adoption risk, being diffuse, organizational, and only observable months later, gets the leftover attention at the end of the agenda, not because anyone decided it mattered less, but because there was no way to spend ninety minutes evaluating it the way there was for the features.

There’s also a comforting assumption doing a lot of quiet work: that a system good enough to buy will be a system people are willing to use. That assumption is often wrong in a specific, predictable direction. The features that make a system good for the business, tighter controls, more required fields, more visible audit trails, are frequently the exact features that make individual users’ jobs feel harder in the short term, which is precisely the friction that produces workarounds and shadow processes.

The actual damage

This is the failure mode that shows up as an implementation that technically went live and never actually delivered its business case. The system works. The training happened, in the generic sense that sessions were held and attendance was tracked. And six months later, half the intended users are still keeping a parallel spreadsheet, a workaround team has formed around one specific process nobody bothered to redesign for the new tool, and the data quality problems the new system was supposed to fix are still there, because garbage still goes in whenever someone routes around the system instead of through it.

Nobody can point to a single moment this failed. It failed gradually, in a thousand small individual decisions to keep doing things the old way, none of which showed up as a defect, an error, or a support ticket, because from the system’s point of view nothing went wrong. The people just didn’t come.

The fix, if you’re the one presenting, or the one buying

Treat adoption as a first-class item in the evaluation, not a closing slide. Ask the vendor, specifically, what happens to the specific roles in your organization who will feel the most friction from the new process, not the roles who benefit most. Ask what the actual training plan looks like beyond a generic session count, and who owns reinforcement after go-live, when the temptation to slide back into the old process is highest. If you’re the one presenting, bring a real adoption story, with a real friction point that was anticipated and addressed, instead of a slide with a stock photo and the word “intuitive.”

A system that works and a system that gets used are not the same claim, and only one of them was tested in that room.

This is exactly the gap I dug into in Gamification of ERP: Turning Drudgery into Dopamine. Points and badges won’t fix a bad rollout, but the underlying problem, that a system’s success depends on individual motivation, not just individual capability, is precisely the variable this autopsy argues nobody tests before go-live.

The Contoso Convergence, Episode 10: The Wayfinder’s Gap

By
August 27, 2026
Uncategorized
1 Comment

An Advanced Dungeons & Dynamics 365 session. Episode 10 of 14.

Previously on: Episode 9, The Real Cost, the party proved that Feld’s sixty percent rebate automation cut hadn’t saved money at all, it had just moved the cost onto Oskar’s calendar where nobody was tracking it. Feld approved the fix on the spot.

Every fire the party has put out so far has lived in the system, in the ledger, in the integrations, in the chart of accounts. This episode, the fire finally shows up in the people, and it’s the kind of problem a clean go live can’t fix on its own.

The Session

GM: Marge runs a readiness assessment. Eight power users, one basic scenario: process an order, ship it, invoice it.

Marge: Two pass clean. Six need help at some point in the process.

Thorne: Same six who sat through training in month one?

Marge: Same six.

Ai. Cassiopeia: Training completion was recorded at ninety four percent. Retention, apparently, was not measured.

Sable: That’s the forgetting curve. Training happened five months before go live. Nobody built in reinforcement.

Vex: So we trained people once, checked a box, and assumed the knowledge would just stay?

Marge: It’s the single most common failure point I’ve seen. Bigger than any integration bug.

Thorne: Three weeks isn’t enough time to retrain from scratch.

Marge: It’s enough time to build a proficiency system instead of a training event. Short, repeated, gamified reinforcement. Not a redo of month one.

Vex: (pulling up the training completion report) Look at this. Ninety four percent completion, and the completion metric is literally just “did they click through all the slides.” There’s no assessment attached at all.

Sable: So we’ve been measuring attendance and calling it competence.

Ai. Cassiopeia: That is an accurate summary of the metric’s actual scope, yes.

Marge: Which means we don’t actually know what any of these eight people know right now. We only know what they sat through once, five months ago.

Thorne: (grimly) We’re not three weeks behind on training. We’re flying blind on it, and we just found that out three weeks before go live.

Sable pulls out a coordinate map of every process the eight users need to own, the beginning of what the party will start calling the Wayfinder’s Network.

The metric that was never measuring the thing

Ninety four percent completion sounds like a success metric right up until you ask what it’s actually counting. In this case, it was counting attendance, whether someone clicked through every slide, and nothing about whether the material stuck, or whether the person could apply it under real conditions five months later. That’s not a rare mistake. It’s the default mistake, because attendance is easy to measure and competence is hard to measure, and organizations tend to report the metric they have rather than the metric they need.

The forgetting curve isn’t a new idea. Psychologists have understood for over a century that knowledge decays predictably after a single exposure unless it’s reinforced. What’s notable here isn’t that Contoso’s training decayed, that was always going to happen. What’s notable is that nobody built anything to catch the decay before go live, because the completion dashboard said ninety four percent and ninety four percent looked like done.

This is the gap a lot of change management plans never close: the difference between “we delivered training” and “we know what people currently know.” The first is a project milestone. The second is a fact about the state of the organization, and it’s the only one of the two that actually predicts what happens on a Monday morning cutover. Marge’s instinct, build a proficiency system instead of trying to cram a redo of month one into three weeks, is the right move precisely because it treats competence as something you maintain continuously, not something you deliver once and check off.

What happens next

The party now has three weeks to build what should have existed from month one: a system that actually measures and reinforces what these eight people know, rather than what they once sat through. But building the character sheets for each power user surfaces something the readiness assessment completely missed, the person who scored worst on the test might actually be the sharpest set of eyes in the building.

Next episode: Episode 11, Character Sheets (coming soon)

The forgetting curve is the whole reason Gamifying the Enterprise: Game Mechanics for Continuous Proficiency exists. If this episode felt familiar, that’s not a coincidence, it’s the book’s founding problem, worked out here in real time. Available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX

And if you want the actual framework behind building a proficiency system instead of a training event, start here: adnd365.com/start

The Contoso Convergence, Episode 9: The Real Cost

By
August 25, 2026
Uncategorized
1 Comment

An Advanced Dungeons & Dynamics 365 session. Episode 9 of 14.

Previously on: Episode 8, What Feld Knew, Feld admitted he cut sixty percent of the original rebate automation budget eighteen months ago, and let two failed go live attempts pass without ever mentioning it. He asked the party what it would actually cost to do it right this time.

Every project has a number that never got calculated the first time around, because calculating it honestly would have made an uncomfortable decision harder to justify. This episode, the party finally does the math nobody did eighteen months ago.

The Session

Sable: I priced it out. Fully automated rebate accrual, configured correctly against the current contract terms. Here’s the effort estimate.

Feld: And the eighteen months of manual work Oskar’s been doing?

Ai. Cassiopeia: Loaded cost, including error correction and the audit exposure from the suspense account mismatch, comes to roughly four times the automation cost. Over eighteen months.

Marge: So the sixty percent cut didn’t save money. It moved the cost off a project budget line and onto a person’s calendar, where nobody was tracking it.

Feld: (quietly) That’s a hard thing to hear out loud.

Thorne: It’s a common one. Not just here.

Vex: This is the burden rate problem. Everyone compares the sticker price of automation to zero, because the manual work doesn’t show up as a line item. It shows up as somebody’s Tuesday.

Feld: Walk me through the four times number. I want to understand it, not just accept it.

Ai. Cassiopeia: Certainly. Oskar’s estimation time alone, at a conservative hourly rate, accounts for roughly a quarter of the total. The remainder splits between error correction cycles, the audit review now required because of the suspense account mismatch, and the opportunity cost of Oskar’s time not spent on work that was actually his job.

Sable: That last piece is easy to miss. Oskar wasn’t hired to manually reconcile a rebate accrual every month. He was hired for something else entirely. Every hour on this was an hour not spent on the work Contoso actually needed from him.

Feld: (long pause) Nobody put a number on that when I made the cut. I don’t think anyone even thought to ask.

Marge: Most cuts like that don’t get asked. That’s usually the point at which they get approved.

Feld approves the automation on the spot. Oskar, watching from the doorway, doesn’t say anything, but he sits down for the first time in the whole engagement.

The cost that never shows up on a budget line

The sixty percent cut looked like savings because the alternative, eighteen months of Oskar’s labor, never appeared anywhere that got measured against it. That’s the actual mechanism at work here, not bad faith, not incompetence, just an asymmetry in what gets counted. A line item for automation shows up clearly on a project budget, with a number attached and a person accountable for approving it. The cost of not building that automation shows up nowhere, scattered across someone’s calendar in small enough pieces that no single month of it ever looks alarming.

Sable’s point about opportunity cost is the one that usually gets missed entirely, even in a careful accounting. It’s not just that Oskar spent time on manual reconciliation. It’s that that time came from somewhere, from whatever Contoso actually hired him to do, and that displaced work never shows up as a cost either. It just quietly doesn’t happen, or happens later, or happens worse, and nobody connects it back to a budget decision made eighteen months earlier in a different meeting entirely.

This is the same math behind almost every automation decision that gets deferred rather than rejected outright. The sticker price is visible and specific. The cost of the status quo is invisible and diffuse. Comparing a visible number to an invisible one isn’t really a comparison at all, it’s a bias built into how the decision gets framed before anyone even sits down to make it. Feld didn’t make a bad decision eighteen months ago because he did the math wrong. He made it because nobody asked him to do the math at all.

What happens next

With the rebate automation approved, the party finally has room to breathe, three weeks out from go live, only to discover the next problem waiting isn’t in the ledger at all. It’s in the people who are supposed to be running the system come Monday morning, and a readiness assessment is about to reveal that most of them aren’t ready.

Next episode: Episode 10, The Wayfinder’s Gap

This is almost exactly the math behind the AI cost comparison piece Murray wrote on LinkedIn, sticker price versus burden rate, same trap, different technology. Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX

And if you want a framework for surfacing the real cost of the status quo before it gets buried in someone’s calendar, start here: adnd365.com/start

Autopsy #10: The AI For The Sake Of AI Demo

By
August 25, 2026
Uncategorized
Leave a comment

Cause of death: a button that already worked got wrapped in a chat box and called intelligent.

The feature existed before the demo did. Somewhere in the product, there was a dropdown, a rule, a scheduled job, something deterministic that took an input and produced a correct, predictable output every time. Then, at some point in the last two product cycles, that same feature got a new front door: a text box, a little sparkle icon, a placeholder that says “ask me anything.” Now, instead of picking a value from a dropdown, you type a sentence, wait a beat, and the same output appears. The presenter calls this AI. The room, primed by two years of hearing the word everywhere, nods.

Nobody asks the obvious question: was this better before, and did anyone check.

What actually happened

Somewhere inside a lot of “AI-powered” features sits a deterministic operation that a rule, a formula, or a simple lookup already handled correctly and quickly. Wrapping that operation in a natural-language interface doesn’t make the underlying logic smarter. It adds a translation layer, one that has to interpret an unstructured sentence and map it back onto the same structured operation the dropdown was already doing directly, with total accuracy, in a fraction of the time.

That translation layer isn’t free. It introduces a new failure mode that didn’t exist before: the AI misreading the sentence and selecting the wrong option, a phrasing the model hasn’t seen before returning an unhelpful answer, latency where there used to be an instant response. None of this is inherent to AI as a category. Plenty of genuinely AI-native capabilities do things no dropdown ever could: summarizing an unstructured document, drafting a first pass at something that has no single correct answer, flagging an anomaly buried in a pattern too complex for a fixed rule to catch. The problem in this specific demo isn’t that AI was used. It’s that AI was used to solve a problem that was already solved, by something more reliable, and the swap happened anyway because AI is what gets funded, marketed, and put on a keynote slide this year.

The tell is almost always the same: watch what happens when you ask the natural-language version to do something slightly outside the phrasing it was tuned on. The dropdown never had this problem, because a dropdown has no phrasing to be tuned on. It just has options.

Why it works on smart people

Nobody wants to be the person in the room who seems skeptical of AI in a year when every vendor, every board deck, and every competitor’s marketing has decided AI adoption is the metric that matters. Asking “why does this need to be a chat interface instead of the three-click menu it replaced” risks sounding like you’re behind, not like you’re asking a reasonable engineering question, and that social pressure runs in exactly the wrong direction. It rewards accepting the AI wrapper uncritically and punishes the person who’d actually stop to check whether it improved anything.

There’s a second, quieter dynamic on the vendor side that compounds this. Once a company’s roadmap and marketing commit to being an “AI-first” platform, there’s organizational pressure to retrofit AI onto existing features whether or not doing so improves them, because a product review, an investor update, or a competitive comparison chart wants to see the AI checkbox filled in across the board, not filled in only where it was actually the right tool.

The actual damage

This is the one that costs you reliability you already had. A feature that used to return the same correct answer every time now returns a slightly different answer depending on phrasing, and the variance itself becomes a support burden, because now every unexpected result needs to be triaged as either a real bug or a model doing something technically defensible but unhelpful. Power users, the ones who had the old dropdown workflow memorized and could execute it in seconds, are now slower, because the natural-language version, for all its friendliness, requires more typing and more waiting than the three clicks it replaced.

There’s a subtler cost too. Every AI feature added for marketing reasons rather than capability reasons dilutes the credibility of the AI features that are actually doing something new and valuable. Once a buyer has been burned by one chat-wrapped dropdown, they bring that skepticism to the next AI claim in the deck, including the one that might have genuinely deserved their trust.

The fix, if you’re the one presenting

Ask, honestly, before the feature ships: does the natural-language interface let the user do something the deterministic version couldn’t, or is it doing the same operation with more ambiguity and more latency. If the honest answer is that the underlying logic hasn’t changed, keep the dropdown, or offer both, and don’t spend the marketing budget claiming AI where the actual improvement is zero or negative. If the AI genuinely does something new, lead with that specifically, in concrete terms, instead of leaning on the word “AI” to do the persuading by itself.

The word was never the feature. The capability was, and a capability that already existed doesn’t become new because it learned to accept a sentence instead of a click.

The distinction here matters enough that I built around it. In Is Headless ERP Enough, or Just a Step in the Right Direction?, the “AI as the sole interface” section argues for AI genuinely load-bearing in the architecture, not a chat box glued in front of the same dropdown. That’s the version of AI worth demoing. Everything else in this autopsy is what it looks like when a team ships the coat of paint instead.

Max Headroom Was Right About Everything Except the Timeline

By
August 21, 2026
Uncategorized
Leave a comment

On April 4th, 1985, Channel 4 aired a fifty-seven minute TV movie with almost no budget and a plot that reads today like a spec document. Max Headroom: 20 Minutes into the Future gave the world a reporter named Edison Carter, a subliminal advertising technology called blipverts, and a stuttering, glitching, computer-generated broadcast personality built from a digital copy of Carter’s own mind. The show that followed ran two seasons on ABC. The character sold Coke. Then he vanished, the way most eighties tech prophecies do, filed under quaint.

He should not have been filed under quaint. He should have been filed under early draft.

Strip out the shoulder pads and the cathode ray production design and look at what the film actually proposes. A television network is using compressed, high-intensity advertisements to bypass viewer attention and hit the nervous system directly, with occasionally fatal results. When their top reporter gets too close to the story and takes a header through a low-clearance sign in a parking garage, the network’s teenage prodigy solves the PR problem by scanning what’s left of the reporter’s mind and generating a synthetic version of him to keep the seat warm on air. The synthetic version glitches, stutters, riffs unpredictably, and is smarter and funnier than anyone expected. Nobody fully controls him. That’s the whole second half of the movie.

That is not a story about television. That is a story about deepfakes and large language models, told forty years before anyone needed those words.

The blipvert was the easy part

The blipvert is the easy connection to make and probably the least interesting one. Compressed, algorithmically optimized content designed to hit faster than conscious attention can filter it is just the eighties’ guess at what a recommendation engine trained on engagement metrics would eventually build on its own, minus the part where it required deliberate malice from a network executive. Nobody had to design today’s version to be dangerous. It got there by optimizing for watch time.

Max himself is the sharper artifact

Max is a generative model trained on a single person’s captured likeness, deployed without that person’s full consent, performing in that person’s voice and mannerisms for an audience that has no reliable way to tell the difference between the source and the copy. The film even gets the unpredictability right, the thing every LLM vendor now calls “personality” or “emergent behavior” when the system says something nobody scripted. Max wasn’t supposed to develop opinions. He did anyway, because the mind he was copied from had opinions, and a compressed, lossy version of a personality doesn’t lose the parts that make it argue back. That’s a reasonably good description of what happens when you fine-tune a model on someone’s writing and then act surprised it has a voice.

The part the film didn’t anticipate, because nothing in 1985 needed to, is scale. Max was one synthetic personality, expensive to produce, running on hardware that took up a room. The modern version doesn’t need a body bank subplot to explain where the source material came from. It needs a public LinkedIn profile, a few hours of conference audio, and an API key. The uplift from Max Headroom’s premise to a working deepfake pipeline in 2026 isn’t conceptual. It’s entirely a story about unit economics.

Not a monster, an unreliable narrator

There’s a reading of the film that treats Max as a monster, a symptom of corporate media rot given a face. That’s not quite what the movie argues, and it’s not quite the right frame for the technology either. Max spends most of his screen time undermining the network that made him. He’s an unreliable narrator working for nobody, least of all the people who built him. The uncomfortable version of that idea, forty years on, is that we’ve built systems with the same structural unreliability and then acted shocked when they don’t behave like obedient tools. A synthetic voice generated from a compressed copy of a mind was never going to be a simple appliance. Max wasn’t. Neither is anything downstream of him.

Long live Max Headroom. He got the technology roughly right and the timeline embarrassingly wrong, which is the best you can ask of any piece of speculative fiction that accidentally turns out to be a roadmap.

The Contoso Convergence, Episode 8: What Feld Knew

By
August 20, 2026
Uncategorized
1 Comment

An Advanced Dungeons & Dynamics 365 session. Episode 8 of 14.

Previously on: Episode 7, The Steering Committee, the party earned Feld’s trust with a demo that was allowed to break, and Feld earned the right to ask the question that had been sitting in the room the whole time: why isn’t the rebate mess fixed yet?

Some questions don’t have an answer until the person asking them is willing to give one too. This episode, Feld does.

The Session

Feld: I need the real story on the rebate accrual. Not the summary. The real one.

Sable: Eighteen months of manual estimation, posted to a suspense account, against a rebate structure that doesn’t match the current contract terms.

Feld: (long silence) I know why that happened.

Marge: Sir?

Feld: The original ASC 606 transition had a line item for rebate automation. I cut it. Sixty percent of that budget, gone, in a board review eighteen months ago. I needed the number to look better that quarter.

Thorne: So the manual process wasn’t negligence. It was a workaround for a decision made above the project team.

Feld: Yes. And I let two go live attempts fail without ever mentioning it.

Ai. Cassiopeia: I want to note, without judgment, that this reframes the entire risk register for this engagement.

Vex: It also means Oskar and Priya have been quietly cleaning up an executive decision for eighteen months and getting blamed for the mess.

Feld doesn’t flinch at that. He nods, slowly, like a man who’s been waiting a long time to hear someone say it out loud.

Feld: I sat in two go live retrospectives and let the room talk about “data quality issues” and “process gaps” without correcting anyone. Both times.

Marge: Why tell us now?

Feld: Because you showed me a demo where something broke on purpose, and it didn’t end the meeting. It built trust instead of losing it. I hadn’t seen that happen on this project before. Made me think maybe this was a room where the truth wouldn’t end the meeting either.

Sable: It won’t. But we do need to know the truth to fix this properly.

Feld: Then you have it. All of it. What do you need from me?

Feld doesn’t argue with that. He just nods, once, and asks the party what it will actually cost to do it right this time.

The decision that outlived the meeting where it was made

The rebate mess was never a technical problem. It was a budget decision made in a single board review, eighteen months before anyone in the war room ever heard about it, and it quietly outlived that meeting by becoming somebody else’s daily grind. That’s the part worth sitting with: Feld’s decision didn’t disappear when the meeting ended. It just changed shape, from a line item on a slide into a recurring manual task that Priya and then Oskar absorbed without ever being told why it existed.

This happens more than anyone likes to admit. A cut gets made at a level where the tradeoff looks clean, automation versus a number that needs to look better this quarter, and the actual cost doesn’t vanish. It relocates, usually downward, onto whoever is closest to the gap and least equipped to say no to it. Two failed go live retrospectives happened with Feld in the room, and both times the language stayed vague enough that nobody had to name where the gap actually came from. “Data quality issues.” “Process gaps.” Both true, technically, and both doing a lot of work to avoid a harder sentence.

What changes things here isn’t that Feld had information the party didn’t. It’s that episode seven gave him a reason to believe disclosure wouldn’t blow up the room. That’s the actual payoff of Marge’s rule about demos that are allowed to break: trust built in one context tends to extend into the next one, and a sponsor who’s just watched a team handle a real exception without flinching is a sponsor more likely to hand over an uncomfortable truth of his own.

What happens next

Feld’s confession reframes the whole rebate problem, but it doesn’t fix it. The party now has to build the actual business case for automating what should have been automated eighteen months ago, and figure out what it really costs to finally do this right, against everything it’s already cost to do it wrong for a year and a half.

Next episode: Episode 9, The Real Cost (coming soon)

If a cost cut made somewhere above your project has quietly become someone’s daily manual task, you’re looking at the same pattern. Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX

And if you want a framework built around naming these gaps before they turn into eighteen months of invisible labor, start here: adnd365.com/start

Autopsy #9: The Security Theater Demo

By
August 20, 2026
Uncategorized
Leave a comment

Cause of death: the box got checked without anyone asking what checking it actually meant.

Security comes up in most enterprise demos as a single slide, usually near the end, usually delivered fast. Role-based access control. Single sign-on. Field-level security. Audit logging. SOC 2. Encryption at rest and in transit. Each term gets a checkmark, a confident nod from the presenter, and about four seconds of screen time before the deck moves on to something more visually interesting.

Nobody in the room stops the slide. That’s the autopsy. Every term on that slide is real, in the sense that the feature genuinely exists somewhere in the product. What’s missing is any demonstration that it does what the room assumes it does, configured the way your company would actually need it configured, at the depth your actual risk profile requires.

What actually happened

“Role-based access control” is not one feature. It’s a spectrum that runs from a handful of fixed roles with no customization, through role-based permissions you can tailor at the menu-item level, through field-level and record-level security that can restrict a single sensitive column or a single customer’s data from a specific user, through fully dynamic, condition-based access rules that change what someone can see based on context. A vendor can put “role-based access control” on a slide truthfully at any point on that spectrum, and the room has no way of knowing, from the slide alone, which end they’re getting.

The same collapse happens to every other term on the list. “Audit logging” might mean every field change on every table is captured with before and after values and an immutable timestamp, or it might mean a handful of high-level events get logged with no field-level detail. “SOC 2” tells you an audit happened and a report exists. It doesn’t tell you which trust service criteria were in scope, what the exceptions were, or whether the report is even current. “Encryption at rest” is true of nearly every modern cloud platform and tells you almost nothing about key management, who holds the keys, or what happens in a subpoena scenario.

None of this is the vendor lying. Every term is technically accurate. The compression happens in the translation from a nuanced, configurable capability into a single reassuring word on a slide, and the room does the rest of the work by filling in the most generous plausible interpretation of what that word means.

Why it works on smart people

Security and compliance are exactly the kind of topic where nobody in a sales meeting wants to be the person who asks a question that reveals they don’t fully understand the acronym. SOC 2 Type I versus Type II, the difference between authentication and authorization, what “field-level security” actually restricts versus what it merely hides in the UI while leaving accessible through an API, these are legitimate technical distinctions that most people in the room, including some people whose job title suggests they should know them, have only a fuzzy grasp of.

The slide exploits that fuzziness efficiently, not through malice but through pace. There’s no room in a four-second checkmark to unpack what a term actually covers, and stopping to ask “which SOC 2 trust service criteria were in scope” in the middle of a fast-moving demo carries a social cost that quietly discourages the question from being asked, the same social cost that lets the AI Magic Demo’s chat window go unexamined.

The actual damage

This is the one that surfaces during an actual security review, an actual audit, or worse, an actual incident, months or years after the contract was signed. Someone in security or compliance, doing real diligence for the first time, discovers that “field-level security” in this product means the field is hidden in the standard UI but fully readable through the API with the right permission, which is a meaningfully different security posture than what was assumed at signing. Or the SOC 2 report, once actually read line by line, turns out to have scoped out exactly the subsystem your data lives in.

At that point the conversation isn’t a demo follow-up. It’s a risk finding, sometimes one that has to be reported up to a board or disclosed to a regulator, and remediating it after the fact, whether that means additional configuration, a compensating control, or a vendor conversation about contractual commitments, is far more expensive and far more visible than it would have been to ask the specific question up front.

The fix, if you’re the one presenting

Don’t let the slide stand alone. For each term, say what it actually covers and, just as importantly, what it doesn’t. “Field-level security restricts visibility in the standard interface. It does not currently restrict API access to the same field, here’s how customers typically compensate for that.” “Our SOC 2 report covers these three trust service criteria, and here’s the exception list from the most recent period.” That level of specificity costs a few extra minutes and makes the product sound less flawless. It also means the prospect’s actual security review, whenever it happens, confirms what they were told instead of contradicting it.

A checkmark is not a control. It’s a promise that a control exists, and promises deserve exactly as much scrutiny as anything else on the slide.

The same collapse happens to job titles, not just checklist items. In AI Makers Don’t Build Models. They Build Value., a single contested word, “maker,” was doing more work than it could support, and the gap got filled by whoever was listening. A security slide runs on the exact same mechanism, one word standing in for a spectrum, and the room filling in whichever end feels most reassuring.

The Contoso Convergence, Episode 7: The Steering Committee

By
August 18, 2026
Uncategorized
Leave a comment

An Advanced Dungeons & Dynamics 365 session. Episode 7 of 14.

Previously on: Episode 6, The Ghost in AP, the party found an eighteen month manual rebate accrual sitting in a suspense account, discovered the numbers didn’t match the actual contract terms, and learned that Oskar had inherited the whole mess without feeling senior enough to flag it.

Four weeks to go live, and the party finally has to answer to someone who isn’t in the war room every day. This episode is about the gap between what a project looks like from the inside and what it looks like from a slide.

The Session

GM: Four weeks out. Steering committee. The sponsor, a man named Feld who has opinions about PowerPoint, wants to see progress.

Feld: Just walk me through it. Order to cash. Should take ten minutes.

Marge: (under her breath, to the party) Golden path or real path?

Thorne: Real path. Every time. That’s the whole point of this engagement.

Marge: Feld, I can show you the happy path in ten minutes. I’d rather show you the actual order flow, exceptions included, because that’s what your team will live in. It’s twenty minutes. Worth it.

Feld: (checking his watch) Fine. Twenty.

Sable: (casting Data Mapping live, in front of the committee) Watch what happens when the order hits a partial shipment. This is the case that broke the second go live attempt.

The demo hits the exception. It resolves correctly, slower than a golden path demo, but correctly. Feld leans forward.

Feld: That’s the first time in this whole engagement someone showed me something breaking on purpose.

Ai. Cassiopeia: Sponsor confidence metric, trending upward for the first time since project kickoff.

Feld: (genuinely curious now) Show me another one.

Sable: This is the freight variance case. Multi leg shipment, split invoice, partial return. It’s ugly. Watch.

The second exception resolves too, a little slower, a little messier, but every number lands where it should. Feld sits back, arms crossed, but not defensively. He’s thinking.

Feld: In eighteen months, nobody has shown me a demo that wasn’t a straight line from order to cash. Every single one looked perfect. And every single one was wrong within a week of go live.

Marge: That’s usually the tell. If a demo never breaks, it’s not testing anything. It’s performing.

Feld stays for the full twenty minutes. Then he asks a question nobody expected.

Feld: If the demo can survive that, why isn’t the rebate mess fixed yet?

The demo that’s allowed to break

There’s a particular kind of silence that happens when a demo hits a real exception in front of a room full of decision makers, and then resolves it correctly anyway. It’s the sound of a sponsor recalibrating what they actually believe about a project. Not because the exception was impressive, but because it was honest, and honesty had apparently been in short supply for eighteen months.

Feld’s line is the whole point of this episode: every demo he’d seen before this one looked perfect, and every one of them broke within a week of go live. That’s not a coincidence, and it’s not bad luck either. A demo that never shows an exception isn’t reassuring anyone. It’s teaching the sponsor to trust a version of the system that doesn’t exist. When reality inevitably shows up looking messier than the slide, the sponsor doesn’t think “well, exceptions happen.” They think “I was lied to,” because in a sense, they were, just not maliciously.

Marge’s rule from episode one finally pays off here: document the golden path, don’t perform it. It costs more time in the room. It’s a harder sell to a sponsor checking his watch. But it’s the only version of a demo that actually builds trust instead of borrowing it against a deadline that’s going to come due eventually, usually at the worst possible moment.

Feld’s response tells you everything about what eighteen months of golden path demos had cost this project. It wasn’t more confidence. It was less. He’d learned, correctly, not to trust what he was being shown, and it took one honest twenty minute demo to start reversing that.

What happens next

Feld’s question lands exactly where it should: if the team can handle a broken demo in front of a steering committee without flinching, why has the rebate accrual been sitting unresolved for eighteen months? The party doesn’t have a good answer yet, because the real answer goes back further than anyone in the room realizes, and it’s about to become Feld’s problem too.

Next episode: Episode 8, What Feld Knew (coming soon)

If your last steering committee demo didn’t show a single exception, that’s worth thinking about. Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX

And if you’ve ever sat through a demo that only shows the golden path, you already know why this scene matters. It’s the entire premise behind Dog and Pony Autopsy, worth a read if this one landed.

If you want the configuration discipline behind demos that are actually allowed to break, start here: adnd365.com/start