← Journal

May 24, 2026 · 1 min read

On defining before building.

Most AI projects fail at the spec, not the code. A short note on why we refuse to write code until we can write the test that proves it worked.

Most AI engagements start in the wrong place.

A team has a problem. A vendor has a demo. Someone in the meeting says the word agent. By Friday the company has bought tokens, picked a vector database, and committed to a Q3 launch — and no one in the room has written down what the system is for.

We've watched this story play out enough times to refuse to participate in it. Define AI starts every engagement with a single, unglamorous week: discovery, decisions, kill list. Eleven prototypes become two. The two get sharp briefs.

What "define" actually means

A definition is not a roadmap. A roadmap is a list of things you'll do. A definition is a constraint — a sentence so specific that, six months from now, you can hold the working system up against it and say yes or no.

For an inspection rig: "84 milliseconds, end-to-end, on rejected parts."

For a legal-research tool: "Zero fabricated citations in the held-out audit set."

For an agent platform: "47% of L1 tickets resolved without a human, no clinical regressions."

You can write code against those. You cannot write code against "leverage AI to delight customers."

The cost of skipping it

Every team that skips this step pays for it later — in models that demo well and ship badly, in retrains that improve one metric and regress another, in dashboards that say green while users say it isn't working.

The expensive part of AI work is not the model. The expensive part is agreeing on what the model should do. We do that part first, and only that part first.

Most teams ask, "how should we use AI?" The better question is — what should we define AI to do that nothing else can?

That's the conversation we're here for.