The weekend I went from AI user to AI builder at work

I’d just finished an AI Strategy program at Cornell — the certificate was three days old and burning a hole in my pocket. The capstone was about derisking AI portfolios, which sounds abstract until you reduce it to its actual questions: What do you test first? How cheaply can you learn the thing that kills the idea? What does a real experiment look like when the stakes are a roadmap?

I was catching up with a colleague and mentioned the program, and somewhere in there I said the sentence that started everything: rapid prototyping in the age of AI redefines “low fidelity.”

She didn’t nod politely. She made me an offer. Her team owned some of the biggest initiatives on our transformation roadmap — would I want to look at a few and think out loud about how to derisk them?

Let me be clear about what this wasn’t. It wasn’t my job. It wasn’t adjacent to my job. It wasn’t anything anyone would ever ask me to do. It was a colleague being generous with her roadmap and me having a fresh certificate and a free hour.

The ideas were north stars — nothing buildable today, but you could feel which direction the whole industry was leaning. One of them I couldn’t put down. It was the one I most wished were true. So I asked for two weeks to come back with a sequence of prototypes and experiments.

I did not need two weeks.

The meeting ended early Friday afternoon and my calendar was empty, which is its own kind of dangerous. I started doing the certificate-trained thing: decompose the idea, find the riskiest assumption, design the smallest possible test.

And mid-decomposition, a thought wandered in from a completely different part of my life: I already have AI software on my personal laptop for prototyping. For my animatronics hobby, of all things. I’d used it enough to know my way around, and I had a suspicion — a strong one — that the first prototype was going to be embarrassingly easy.

So, to prove the point properly, I set the stopwatch on my phone.

Two hours and eleven minutes.

That’s how long it took to go from “north star on a transformation roadmap” to “working prototype on my kitchen table.” Not a mockup. Not a clickable PDF pretending to be software. A thing that did the thing.

Saturday morning I kept pulling the thread: vibe-coded a single-page HTML interface, learned how APIs actually work (Saturday was a big day for me and APIs), opened a Cloudflare account so the app had somewhere to live and the API key had somewhere to hide. By lunch, the prototype had a URL. Anyone with a browser could try it.

Total elapsed time from “interesting idea” to “could send your CEO a link” = one day, minus sleep and errands.

The prototype did what prototypes are supposed to do — it confirmed the experience would have user value. But it also taught me something I hadn’t designed the experiment to test.

If I could build this — no coding background and hobby software — then a real developer could build the real thing almost as fast. Anywhere. Including at a competitor. Including this weekend, while I was building mine.

That’s the part that should keep strategy people up at night. The old derisking playbook — scope it, write an SOW, engage an agency, wait weeks for a prototype, then decide — isn’t just slow anymore. It’s slower than the threat. A competitor can ship the feature in the time it takes a large company to approve the press release announcing the intention to explore it.

The cost of learning has collapsed. Which means the cost of not learning — of letting an idea sit in process — went up by exactly the same amount. Nobody sent a memo about that.

Then came the twist.

It turned out some of our own developers had already been circling the same idea. One of them had a version sitting on her desk as a side project — the thing she tinkered with when a free afternoon appeared. The capability existed inside our walls the entire time.

What the side project didn’t have was a why. No business context. No connection to the roadmap or the competitive clock I’d just heard ticking. So it sat there, technically alive, strategically invisible.

The moment that context arrived — the moment someone could say “this matters, and here’s what it unlocks” — everything changed. It got prioritized. An idea that had been idling as a side project for who-knows-how-long went from desk drawer to ready for validation and the unlock wasn’t engineering. It was translation.

There are lessons here for other people, and I’ll give them their own posts eventually. The short versions:

If you’re non-technical and you have an idea — build the bad version yourself first. A rough thing that works changes the entire conversation. You stop pitching a concept and start demoing a fact.

And if you run a big, matrixed company watching AI-native competitors move faster than seems fair: they don’t have better ideas than you. They have fewer layers between an idea and a person with the context to act on it. Your developers’ desk drawers are full. The question is who in your company can see into them.

But the lesson that actually rearranged something was mine, and it was quieter than either of those.

I will never build anything customer-facing. Shouldn’t, can’t, won’t — that’s what engineers and compliance reviews and entire departments are for. That was never the point.

The point is that somewhere between starting that stopwatch and watching the prototype work, a category I’d always put other people in opened up and let me in. I could be a builder at work. Not as a title. As a way of standing in front of a problem.

Before that weekend, my reflex when I saw a gap was someone should build that. Now it’s let me see how far I can get by Saturday. Most of the time the answer is “not very,” and that’s fine — even a failed prototype tells you which assumption to attack next, and the certificate taught me that’s the whole game.

But the gap between someone should and let me see turned out to be two hours and eleven minutes wide. I know because I timed it. And once you’ve crossed it, you can’t un-know how narrow it always was.