This Was Supposed to Be a Simple Project

Before any code was written, I asked Claude to create a PRD (Product Requirements Document).

You start a project by defining what you're building. The request was simple enough that I could have skipped that step and gone straight to implementation.

I didn't.

Then I did something that probably needs explaining.

I asked the Architect and Product Security Engineer to review it.

I wasn't trying to create a process. I simply wanted another set of eyes on the plan before each project moved into execution.

Looking back, that decision turned out to be more important than I realized.

Reviews Changed the Design

The project was a simple one: I had 820 Apple Notes spread across roughly 50 folders, with 638 of them sitting in a single folder called "Notes." The goal was to export them, classify them, and move them into something better organized.

The review immediately surfaced things the original PRD had missed.

The Architect focused on operational concerns: dry-run support, batch processing, rollback requirements, separating cleanup from the main workflow.

The Product Security Engineer looked at it differently: credential detection, export handling, output protection, preservation of the existing folder structure.

One recommendation stood out.

The PRD contained a precautionary instruction to disable iCloud Notes synchronization before executing the move phase. On paper, it sounded reasonable. During testing, I followed that recommendation and was immediately presented with a dialog on my iPhone warning that all iCloud notes would be removed from the device.

I hit Cancel.

Nothing was deleted. But it was a useful lesson.

The recommendation was intended to reduce risk. It introduced a different risk entirely. Further testing showed the instruction wasn't necessary at all. AppleScript operations on the Mac propagated through iCloud normally without touching synchronization settings.

What mattered wasn't that the review was perfect.

What mattered was that the review changed the design before implementation began.

That felt familiar.

The project was already behaving less like a prompt and more like an engineering process.

What Kept Reappearing

Once I started looking, the pattern was everywhere.

Every project eventually started with a specification instead of code. The ones that did required fewer revision cycles than the ones that didn't.

Every project eventually developed a canonical record of what was requested, what was built, what changed, and what was pending. Without it, project memory degraded quickly. With it, handoffs became easier and scope became visible.

Approval gates appeared without being asked for. The Apple Notes pipeline generated a classification report before executing any moves. Hundreds of notes would be moved, but not until a human reviewed the plan first.

Rollback appeared the same way.

One comment from an Architect review stayed with me:

"A log you can't act on is history, not a rollback."

At the time, it felt like a small implementation detail. Looking back, it was a statement about risk. The rollback wasn't valuable because it was used. It was valuable because it existed. Its presence changed how decisions were made long before it was ever needed.

I was no longer looking at a single project.

I was looking at recurring behavior.

The Token Audit

The moment that changed how I thought about all of this didn't come from a review.

It came from a resource problem, one I'd already seen once before.

In an earlier project, I realized we were consuming tokens faster than the value justified. That forced a question I hadn't thought to ask at the start:

"Where are we spending tokens?"

The answer led to a deliberate strategy. Reasoning-intensive work stayed with Claude. Pattern-oriented work moved to local Ollama models. Early-stage exploration happened in ChatGPT.

Then, mid-way through the Apple Notes project, credits ran out.

It wasn't a plan. It was a forced pivot. But the lesson was already there. This time it confirmed it.

The goal was never to eliminate any particular tool. The goal was to reserve expensive resources for problems that actually required them.

Over time, that evolved into a tiered build process. Before implementation begins, work gets assigned to a model the same way work in an organization gets assigned to a person. Some tasks require a specialist. Others don't. Some justify the cost. Others don't.

The interesting part wasn't the savings.

The interesting part was what happened to my thinking.

I had stopped asking whether the models could do the work.

I had started asking which model should be doing the work.

That was a management problem.

That realization became a practice. Before any project starts, I ask the Content Director to estimate token usage. After it completes, I ask for the actual. The delta tells me whether I allocated correctly, and where I'll do better next time.

What I Got Wrong

For a long time, I thought the interesting part of these projects was the AI.

I thought the breakthrough was creating specialized roles.

Architect. Product Security Engineer. Content Director.

Looking back, I don't think that was the breakthrough at all.

An Architect can identify problems, but if the project continues unchanged, the review didn't really matter. A Product Security Engineer can raise concerns, but if there is no mechanism for those concerns to influence the outcome, then the role is little more than another opinion.

The value wasn't in the existence of the roles.

The value came from the structure around them.

The PRD had to be updated. Findings had to be addressed. Reviews occurred before implementation. Human approval happened before irreversible actions. Rollback existed before execution. Lessons learned were captured and reused.

The roles surfaced the issues. The governance made those issues count.

The governance didn't appear from nothing. I had an Architect asking operational questions and a Product Security Engineer looking for risks. The roles shaped the outcome. What surprised me was recognizing what they had built.

Why This Felt Familiar

Once I noticed the pattern, I couldn't unsee it.

I've spent years working in product security for connected medical devices. In regulated environments, governance isn't optional. Requirements exist before implementation. Reviews happen before release. Traceability exists because decisions need to be understood later. Human approval gates exist because some actions carry consequences that are difficult to reverse.

Nobody looks at those controls and says: "That's the product."

They're not the product. They're the framework that allows the product to be built safely and repeatedly.

What surprised me was seeing the same structures emerge in a project that had nothing to do with medical devices.

Different goals. Different technology. The same patterns.

The technology changed. The problems didn't.

Closing

If I'm being honest, this project was probably over-engineered.

Most people don't create a PRD to reorganize their notes. They don't run architecture and security reviews before writing a script that moves files. They don't build rollback procedures, maintain feature ledgers, or write post-mortems for a home lab experiment.

They're probably right.

But the notes were never really the point.

The project became a low-risk environment to experiment with an AI-assisted workflow and observe what happened as complexity increased. What I found wasn't that the tools were capable. I already knew that.

What I found was that the same structures kept appearing.

Requirements. Reviews. Feature tracking. Institutional memory. Approval gates. Rollback. Resource allocation.

At some point I stopped studying the models and started studying the system around the models.

That's when the lesson became clear.

I thought I was learning how to manage AI models.

What I eventually realized was that I was rediscovering governance.

And once I saw it, I couldn't stop seeing it.