Demo, Don't Announce
22 Jul 2026There’s a move I’d make to get an engineering team to take AI seriously, and it’s the opposite of what most orgs reach for. Don’t announce the tool. Show it, live, on the code the team shipped this week.
Picture it. You stand up in an engineering standup and run a real bug from the backlog through a full agent pipeline. Investigate, fix, review, open the MR, in front of the team. No slides. A real ticket, fixed live.
I’ve come to think this is the only convincing way to move an engineering org on AI, and I want to make the case for why.
How adoption usually gets sold
The default move is the announcement. A rollout email, a mandate from leadership, a lunch-and-learn with a vendor deck and a slide that says “10x productivity.” Maybe a demo, but a canned one: a toy app built from an empty prompt, the kind of thing that proves the tool works on a problem nobody in the room actually has.
Everyone in that meeting has seen “AI writes code” by now. It doesn’t land as news. It lands as a claim, and a claim from someone with something to sell. The announcement asks the team to believe a thing they can’t check, about work that isn’t theirs, on the word of the person at the front of the room.
That’s the setup that manufactures skeptics. You’ve told people the future is here and handed them nothing they can test against their own experience. The only move left to them is to decide whether they believe you.
What a demo asks that an announcement doesn’t
Run a real bug from the backlog live, and the person who filed it is watching a machine reason about their code. The team doesn’t have to take your word for anything. The work is right there. Either the fix is good or it isn’t, and every engineer in the room is qualified to judge, because it’s their codebase.
An announcement produces a verdict: you believe it or you don’t. A demo produces questions. How did it know to look there? What model was that? Could it do the flaky test I’ve been avoiding? Those questions are not resistance. They’re the first thing that happens when someone starts imagining the tool inside their own work. Adoption starts there, in the questions, not in the nodding along that follows an email.
What the team watches
A real ticket, pulled from the backlog in front of the team. The first agent investigates: it reads through the codebase, forms a theory about the bug, and explains its reasoning. A second agent takes that diagnosis and writes the fix. A third reviews the change. Then it opens the merge request, the same way any of us would.
What I’d most want them to see isn’t that AI can produce a diff. It’s how the work gets split up. Different agents running on different models, each with its own context and its own job. One agent reasons about the bug on a heavy model, where the thinking is expensive and worth it. Another does the implementation on a lighter, cheaper one. A third reviews.
For many of the engineers in the room, watching it run this way changes the picture. They walk in picturing autocomplete, a slightly smarter version of the suggestion box in their editor. What they watch looks less like autocomplete and more like a small team with a division of labor: a senior engineer who reasons, a mid-level who implements, a reviewer who checks. Seeing the labor divided that way is what moves the idea from “the tool writes code” to “the tool works the way we work.”
The reason it works is that it can fail
When you demo instead of announce, you’re not asking anyone to trust you. You’re removing yourself from the equation. The work makes the argument, and it makes it in public, where it can go wrong. If the agent misreads the bug, or the fix is sloppy, or the review misses something obvious, the whole room sees it happen. Live and unedited.
That exposure is the feature, not the risk. An announcement can’t fail in front of you; it just sits there asking to be believed. A demo is falsifiable on the spot, and a thing that can visibly fail and doesn’t is worth more than any number of slides. The willingness to run it live, on a problem the team recognizes, with no chance to quietly retry if it breaks, is itself the signal. It says, “I’m not selling you anything. Watch for yourself.”
And on the day it does flop, that reads as honesty too. The room saw the tool struggle, and no one was told to pretend otherwise. That is what earns the benefit of the doubt the next time you stand up and say “watch this.”
Reach is the wrong measure
The obvious knock on this is that it doesn’t scale. A demo reaches one team in one standup. An announcement reaches the whole org in a single email, in an afternoon. If the goal is to move an engineering organization, a live demo to eight people looks impossibly slow next to a message that lands in three hundred inboxes at once.
But the reach of an announcement is mostly counterfeit. It arrives in three hundred inboxes and changes almost nothing, because an email doesn’t create adoption. It creates awareness, which is a different thing that feels like progress. Nobody starts using a tool differently because they read that they should.
What actually spreads is the questions, and the questions only come from people who watched it work on something they recognize. One team that walks out of a standup asking how to point this at their own flaky tests will move further in a month than an entire org that got the memo and archived it. Adoption propagates person to person, from someone who saw it to someone they tell. The demo doesn’t have to reach everyone. It has to reach the few people who then can’t stop talking about it.
What the resistance is really about
Resistance to a new tool is rarely about the tool. It’s about the person handing it over, and whether they’ve earned any credibility yet.
Stop trying to win the argument from the front of the room. An announcement spends whatever credibility you already have. A demo earns you more, one recognized problem at a time, by putting the work where it can fall apart in front of the exact people who’d notice. Don’t tell your team the tool is worth their time. Put it in front of them, on a bug they know, and let them catch it working.