Experiment Like a Lunatic. Ship Like an Adult.

The single most expensive mistake I see business owners make with AI right now isn't picking the wrong model or the wrong tool.

It's blending two things that should never touch: experimentation and production.

They feel like the same activity. You're sitting in the same chair, typing into the same box, talking to the same model. So your brain treats them as one. That's the trap!

They are equally important and COMPLETELY DIFFERENT, and if you don't draw a hard line between them, you'll either never get started or you'll blow your own foot off in front of your whole team.

Why you have to be experimenting

You cannot lead an organization through this if you haven't felt THE POWER in your own hands.

You have to be the one who learns what your installer's day actually looks like and what the tool can and can't do about it.

You can't delegate that (YET).

At this stage, you or someone right at your hip has to be the engine pushing it forward. Hire all the help you want around the edges, but the taste, the judgment, the "is this even worth doing" … that's you!

So go PLAY. Build the weight-loss calculator. Build the tool that tracks your kid's cello recitals. Build the dumb thing that solves your own annoyance on a Tuesday night. That's not wasted time.

That's how you build the instinct to look at a problem and know whether AI cracks it or whether you're about to spend thirty hours producing something a human could've done a year ago.

Even those of us who live in this stuff waste a ton of time. I've blown millions of tokens in an afternoon chasing something that went nowhere. That's fine — for me…. I have all the context and all the incentive to do it right and eat the cost.

The problem is what happens when you hand that same open-ended access to your entire team!

Why you must not push experiments straight to production

PRODUCTION GRADE is the thing self-taught builders don't feel in their bones…. the way real developers do.

To a developer, OF COURSE you keep a clean codebase, OF COURSE you log your changes, OF COURSE someone reviews before it goes live. But to the rest of us, it's all just a text box, and slowing down feels like the enemy of progress!

But the moment a tool stops being your toy and becomes something your team's job depends on, the rules invert.

Now somebody is going to be genuinely scared when it breaks.

Three things go wrong when you skip this:

You lose trust with your team. If you spin some janky AI tool up over the weekend and quietly make it load-bearing on Monday, and then it breaks in a way nobody can see, you've taught your people that the new way of doing things is unreliable.

You will never get that trust back cheaply. Change management is already the hardest part of this whole transition…don't make it harder by being sloppy.

Silent failure. A form breaks, the AI quietly starts inventing interview questions or skipping records, and nobody notices for a week. When you "hire ten developers" in the form of Claude Code with no IT function, no access controls, and nobody checking, your team stops working the second you close your laptop and you don't even know it. Production needs a person who opens the shop at 6 a.m. with a clipboard and walks the floor… humans checking the critical workflows by hand, on a cadence set by how badly it hurts when they fail.

Blast radius. Your head of maintenance should not be in the terminal with read-write access to your systems of record. Experiments live in a sandbox where the worst case is a wasted afternoon. Production lives behind real guardrails, because the worst case is a withdrawal from your bank account or a corrupted source of truth.

The line is a leadership decision, not a technical one

A real software engineer once told me: it could happen one time, or it could happen an infinite number of times. Before anything graduates to production, you have to actually sit there and consider the impact of it happening at scale, on autopilot, when you're not watching.

The way we run it now is a deliberate cadence:

1. Experiment at the top. Do your spazzy R&D off to the side …you, or you plus one or two people whose whole job is to break things and look stupid. Never with the overworked GM who has thirty crews in the field and a real job.

2. Loop in one forward-looking person close to the actual workflow for an early pilot

3. Find a working-level volunteer who doesn't mind if it breaks, and run the new way in parallel with the old way.

4. Soft-launch it to everyone. Suggest it.

5. Then rip off the bandaid. Mandate it. Lock them out of the old way — because if the old path is sitting right next to the new one, people will sprint back to it the second something feels hard, and you'll never see the gain.

That last step is non-negotiable. The friction of the old way living next to the new way is what kills the return. At some point you have to say: this is how we do it now.

Account for them differently, too

If you take one operational thing from this, make it this: separate your R&D seperate from your production. They're different animals and they need different styles.

R&D is closer to “venture”. You're funding smart people (yourself or a few trusted lieutenants) to chase ideas. The metric is "show me something interesting this week," not "how many widgets did you ship." You give a tinkerer a budget and a long leash and you check in.

Production is the opposite. It's "how many more quotes went out, how much did the constraint move, did we make more money." If you blend the styles, you'll wake up one day having spent forty grand on tokens with no idea whether any of it touched the bottom line — which is the exact same trap as a two-year ERP implementation that nobody can point to a dollar from.

The point

Be a lunatic in the lab and an adult on the floor.

Experiment quickly, precisely because the experiments are walled off from anything that matters. And when something earns its way into production, treat it like you'd treat buying a new truck — with a plan, a reason tied to your actual constraint, and an honest conversation with the people whose jobs are about to change.

Yallah Habibi,

Jon

Good feedback on the pod. Follow on spotify here.