My company ran out of money. That is the short version of a long story. The dream did not end with it. The payroll did.

I decided the fastest way to learn AI was to rebuild the entire platform from scratch, alone, reusing nothing. Every aspect of it: the property analysis engine, the consumer game, the outreach system, the data pipeline, the deployment. The first version took a team several years and hundreds of thousands of dollars. The rebuild took eight months, one person, about $200 a month in AI subscriptions, and under $100 a month for hosting, the database and the other tools. It is better than the original.

Last month that project put roughly seventy million tokens through Claude Code without me writing a single prompt to the coding sessions.

I spend hours talking to a separate strategy session about what we are building, what is broken, what should happen next, and what tradeoffs I am willing to make. That session acts a lot like my project manager and technical architect. When we agree on the next piece of work, it writes the instructions for the coding session. I carry them over. Claude Code builds it. I carry the results back. We review what actually happened, make the next decisions, and repeat.

I have joked that coding has been reduced to courier work. That is obviously an exaggeration, but there is something important underneath it.

Earlier in my career, software development had two big pieces: first, figure out exactly what the system was supposed to do; second, write the code to make it do that. I worked in consulting at Ernst & Young, where requirements were serious work. You agreed on processes, data, behavior and exceptions before development started. I also knew how to program, although I was never going to be anybody's star developer.

AI has radically changed the second half of that equation. It has not changed the first. If anything, it has made it more important.

An AI coding agent will build almost anything I ask for, and it will build it frighteningly fast. That is wonderful when the instructions are good. It is also a very efficient way to build the wrong system.

A human developer who does not understand a requirement may stop and ask a question. An AI may make a perfectly reasonable assumption, implement it across twenty files, write tests around the assumption, and continue confidently. Speed multiplies clarity. It multiplies ambiguity too.

So a much larger percentage of my time now goes into deciding things before code is written: what the source of truth is, what happens in edge cases, which system owns a piece of data, what a user is allowed to do, and how we will know the feature actually works. Our platform has requirements documents, technical specifications, build plans, decision ledgers and explicit rules for which document wins when two pieces of history disagree.

That sounds like paperwork. It is. And I have become a huge fan of paperwork.

It solves a problem specific to AI development. A strategy session can know an enormous amount about a project, and modern tools preserve useful memory between sessions. But I do not want the important history of the company to exist only inside an AI's working context. Context is working memory. The repository has to become institutional memory. The logs make the point bluntly: in August, for every token the AI wrote, it read about 350. What you let it read is the work. Decisions get written down. Bugs get logged. When a rule changes, the old rule does not simply disappear; we record what replaced it. Build sessions receive a specific work order and acceptance criteria rather than being expected to reconstruct months of history.

Where one month of tokens went, from Claude Code's own session logs. At API list rates the month would have cost about $5,400.

That is also why I am comfortable being the courier. I am not copying random prompts between two chat windows. I am controlling the handoff, and I remain the person deciding what the business should actually do. The we in this article is me and the AI sessions. That is the whole team, and it's enough.

One of our systems uses two AI roles called Lennie and George. Lennie researches. George drafts outreach. They can reason about messy information far better than a traditional rules engine. That is exactly why we use AI.

But being good at reasoning does not mean an AI should have unlimited authority. George does not need unrestricted access to my production database just because George needs information from it. Instead, consequential actions move through an orchestration layer. The AI asks for something in a structured form. A trusted workflow validates the request, retrieves or changes only what that workflow is allowed to touch, and returns what is necessary. Humans approve outbound communication.

The two loops. Top: the strategy session writes the work order, Dean carries it, Claude Code builds. Bottom: agents reason without credentials, workflows execute, a human approves anything sent.

That distinction matters because AI is probabilistic. It can misunderstand something. A customer can paste hostile instructions into an input. A model can follow the wrong piece of context. A future model update can change behavior. I do not want my security model to depend on an AI being smart enough never to make a mistake. I want the architecture to remain safe when it does.

The simplest rule I have found is this: let AI reason. Let controlled systems execute.

We designed the architecture around that rule, and an audit still found credentials hardcoded where they should not have been. That was embarrassing. It was also useful. We removed them, changed how credentials are supplied, and added the problem to the permanent list of things the system looks for. Security is not something you finish.

The harder lesson was learning not to trust evidence just because it looked official. My project ledger eventually gained a rule I call the proxy law: never check a stand-in for the thing itself when you can check the thing itself.

I learned it repeatedly.

Our platform has an AI character named JET, a homing pigeon who analyzes housing data and publishes opinions about what homes are worth. We built a feature around JET. The tests passed. Weeks later a real batch job tried to use it and rejected every property.

JET did not exist.

More precisely, no production database record had ever created JET as the system player the feature expected. The tests were green because each test builds a throwaway copy of the database, and the tests planted JET in that copy before checking whether JET was there. The real database never had him. A test that plants the evidence it is looking for proves nothing.

Another time, a nightly maintenance process produced a beautiful report. Tens of thousands of records reviewed. Remaining work counted. Clean completion. It had done nothing. A math error told the process there was no work left, so it did nothing. Then it wrote its report from a results file an earlier run had left on disk. The report described the earlier run. At the bottom it confidently recommended running the process again. Which would have done nothing again.

Then there were our automated safety checks. The checks run on my machine every time, and they passed, so for three weeks I took that as proof. The official checks run on a separate service after every change. Nobody had opened that page. When we did, we asked it a simple question: show us the successful runs. There were none. All 119 runs in the project's history had failed before the tests even started. Everything looked healthy on our development machines, so we had mistaken local success for actual success.

None of these systems were lying. They were measuring the wrong thing. That is a particularly dangerous failure mode with AI, because the explanation can sound so convincing.

It is also why production AI needs two kinds of tests. Traditional software asks whether the system executed correctly. AI adds a second question: was the result actually good? An API can return 200 OK while the AI gives a terrible answer. So we test the machinery, and we evaluate the output. The demo is almost always the happy path. Production is every path the demo skipped.

Whenever we discover a category of failure, I try not to write a new rule saying, "Remember not to do that again." We build a tripwire.

One of my favorite bugs involved three invisible formatting bytes. Nobody could see them in the file, but they broke a production installation. We documented the problem. The documentation itself accidentally reintroduced the same invisible characters. Twice. There is no amount of careful reading that solves an invisible-character problem. A permanent automated check does.

The same thinking now applies to secrets, schema changes, terminology, performance limits and deployment gates. It applies to retries, too. Production workflows fail. Networks time out. Jobs restart. Engineers call the fix idempotency, a word I learned this year: running a job twice should have the same effect as running it once. If retrying a process sends two messages, creates two customers, awards something twice or corrupts state, the system was never really reliable. "Run it again" should usually be boring. Boring is underrated.

I brought this from an earlier career in securities. As a FINRA principal, we maintained written procedures, backup facilities and scheduled reviews not because we believed something was currently broken, but because scheduled distrust is how you discover whether things are actually right. I recently ran an AI audit session whose entire assignment was to distrust our own project documentation. It found a rulebook that had gone stale while newer sessions were pointed elsewhere, and a bug report where a guess had quietly been recorded as a fact. Both took minutes to correct. Neither had yet become code. That is the economics of auditing: catch a bad idea while it is still a sentence instead of after it becomes a system.

None of this is an argument against vibe coding. I love it. If I am testing an idea or building something I may throw away tomorrow, adding enterprise process would be ridiculous. The line is not project size. The line is stakes. Once real customers, private information, money or important business processes enter the system, the job changes.

I started this era thinking AI would make me dramatically faster at writing software. It did something stranger. It made writing software a smaller part of my job.

I still spend my day building. But increasingly, building means deciding what should exist, breaking it into pieces, managing what the AI needs to remember, deciding what it is allowed to touch, verifying what it claims to have done, and turning every painful lesson into a control that remains after the session ends.

The code became abundant. Clarity did not. Judgment did not. Accountability certainly did not.

AI did not remove engineering judgment. It made it the whole job.

The AI Collective is built by volunteers across 180+ chapters in 40 countries.

Thank you to the thousands of volunteers around the world who make this work possible. We truly could not do this without you.