I was the hypocrite in my own AI policy

This week, I was in a meeting about splitting IT from product development, real "professionalizing the company" stuff, when we got to the team's use of AI app builders.

I heard myself say two things within minutes:

"Put the Lovable down. Your job is sales, not building dashboards."

“I spend half my day inside Claude Code, MCPs, and agent workflows.”

One of our leaders could have reasonably asked, "So which is it, Jon?"

I didn't have a crisp answer handy. My instinct said these were different. And "it's fine when I do it" isn't a policy!

The line is separating USING AI….. from BUILDING with it.

USING AI leaves no artifact behind. You do some stuff with your data, draft the email, summarize the calls, or run your workflow 10x faster. When you close the laptop, nothing exists except the work product. Nothing to maintain. Nothing to break silently in six months. My team should be SNORTING this AI.

BUT

BUILDING creates software, a thing with “state”, users, and a ongoing maintenance bill (mostly in human hours).

AI has made building so fun and fast that ambitious people will do it instead of their jobs. I watched seven people at my company independently vibe-code presentation tools, all of which were 70% good.

Every one was janky and over time…. orphaned. The people building them spent hours away from revenue/fulfillment/whatever work to produce things my (or your) dev team could have built properly in an afternoon (if they'd known the problem!)

The rule at Sagan now fits in one sentence:

Use AI as much as you possibly can. Build production software never!

If you run a business and are rolling out AI, I'd bet money you have this exact confusion brewing: enthusiastic people, magical tools, and no line between useful AI and shadow IT.

Draw the line before you have seven presentation tools like us.

Below is the draft memo I’m working of for the team. Steal it, if you agree!

What do you think? How have you solved this?

Yallah Habibi,

Jon

Memo

To: All Sagan Team

From: Jon

Re: AI at Sagan, use vs. build

The rule in one line:

Use AI as much as you possibly can. Build software never.

Some of you have noticed that I spend half my day using AI tools… while we've also started telling people to PUT DOWN THE LOVABLE.

That looks contradictory!

The difference is using vs. building.

Using means putting AI to work inside systems and workflows we've already got: asking questions of our data, drafting, summarizing, researching, and getting through your work faster.

When you close the laptop, nothing is left. Nothing needs a password reset in six months. Nothing breaks silently while a teammate depends on it!

I want everyone doing this aggressively!! Every day!

Every tool we're rolling out, including read-only data access, the MCP (s), and our agent tooling, harnesses, exists to help you work this way.

BUILDING means creating software: an app, a dashboard, a tool with a login, or anything wired to real data. It doesn't matter that AI made it fast, that it works, or that it's clever. The moment it stores data, connects to a live system, or has a second user, it is PRODUCTION SOFTWARE. The product team has to own, secure, and maintain it, or someone will fall into the trap later.

We have already lived this.

At one point, seven people at Sagan were separately building presentation tools. They were all janky, built during hours that should have gone to serving customers.

If you're a recruiter or customer facing person, a week spent wrestling a vibe-coded dashboard into existence is a week not spent on making Sagan better. (our devs could build it properly in an afternoon if you gave them the problem and the context…they on the other hand, can’t close a hiring request)

When you have a good idea:

1. Do it manually first. Use a spreadsheet, a checklist, WHATEVER. Prove this problem is worth solving.

2. Show us! Make a throwaway mockup with fake data and no connections/backend. MS Paint is honestly fine. Or a vibe coded front end with ipsum lorem (NO BACKEND OR USERS)

(everything in 3 and 4 is soon to be rolled out - but is a work in progress)

3. Give the request through your team's rep with real context: problem, what happens now, and what it costs you (time). Rich context is the most valuable thing you can hand the product team (FAR more valuable than a half-built app)

4. Product/in house developers build the official version so everyone gets it, supported.

This asks for better-aimed ambition.

The enthusiasm is the best thing we've got.

Aim it at the step where it has a chance to stick around instead of the step where it is a dumpster fire.

Jon