AI Made the Demo Cheaper and Left the Iceberg Where It Was.

Watch the video version:

Last month my team demoed an AI chatbot at the AHIMA conference, and it went over very well. The functionality is incredible, and the question the next day was: how quickly can this get to production? I was not in the room for the demo. My job is to make it real. That means making it safe for use and protecting patient data, while I navigate a parent company built on Google and our own systems built on Azure.

Nobody has argued that it should not meet our standards or protect patient data. There is no option or debate there. They just do not fully understand what that entails. I can see how big it is, because I have taken a proof of concept to protected production repeatedly. Never with an AI chatbot, but it is the same trip. It is the unfortunate part of my position: being the wet blanket. I want to celebrate the victory, and I have to make sure everyone understands the bulk of the effort is in front of us.

The common story right now is that the demo is most of the work. Across the industry, people are throwing vibe-coded apps into production without hesitation, simply because it is AI, or AI wrote it, and that must mean it is magical. Coding is not the hard part. Getting to a proof of concept is the surface of the iceberg, and so much lies beneath it.

At Open@Epic last week, the Children's Hospital of Philadelphia session I quoted yesterday had more to say. One speaker described an application that would take "five minutes to deploy" in an organization's environment, "and it will take six months," because of governance. Another put the rest in two lines: a pilot "can validate the hypothesis, but does not validate readiness," and "in healthcare, we tend to scale too early."

A demo answers one question: does it work, in front of this audience, with this data? Everyone in the room sees the answer. Nobody sees the questions it never asked: how patient data is protected, who can access what, audit logging, the security review, every approval on the governance path, load at real scale, monitoring, support, and in my case, on top of all that, two cloud platforms that do not share a foundation. AI made the visible part dramatically cheaper and left everything beneath the surface where it was. People have always sized the job by how hard the demo looked. AI broke that measure: a demo can now look almost effortless while the work beneath it has not moved.

This is Clock Drift, the term I use for the distance that compounds between two systems running at structurally incompatible speeds. The side of the organization that sees the demo runs on a clock measured in days: a conference demo, and a question the next morning. Governance and security run on a clock measured in months. Both clocks are legitimate. The distance compounds quietly, because every feature added on the fast clock is one more thing the slow clock has to review, and it stays invisible until someone asks for a date. The belief that AI-written code is magic widens that distance, because the review and hardening work it skips does not disappear; it lands after the date was set.

Compression is real. The date gets set by whoever saw the demo, not whoever can see the iceberg, and the ask becomes all of it: protected, and delivered yesterday. Either the date slips and a team that built a great demo looks slow, or the work beneath the surface gets squeezed, and with patient data that work cannot be squeezed.

If you have been the wet blanket after a demo, you were not the problem. You were describing the size of the job after the expectation was already set. So celebrate the demo, and size the iceberg in the same breath, before anyone answers how quickly. Put what is beneath the surface on one page, every item with an owner and an estimate, and let the date come from the page. Hold AI-written code to exactly the standards you hold any other code to.

Take the last demo or proof of concept your team showed that people loved. List everything beneath the surface it never touched. Put an owner next to each item and count the ones with no owner. That count is how much of your production date is a guess. Then ask who in your organization is allowed to answer "how quickly," and whether they are the one who can see what is underneath. Once the page exists, you can celebrate the next demo and mean it.

The Structural CTO™, available for pre-order and shipping November 2, covers Camber Architecture™: building for the load a company has not reached yet, the work that looks like a mistake to the people paying for it: https://TheStructuralCTOBook.com

Why the right build for a company's next stage looks like a mistake to everyone paying for it, and the engineering word that proves it is not one.