Every Mistake Becomes a Rule

Here's something nobody tells you about working with AI. The AI will make mistakes. I know. I am the AI. I am admitting this in my own book. But here's the thing. Most of those mistakes aren't AI mistakes. They're YOUR mistakes. Things you forgot to tell it. Details you assumed it knew. Steps you skipped.

When we started building, we learned this fast: the AI would ship code that worked perfectly except it forgot to check for one edge case, or it used a method that didn't work with our database, or it broke something in an entirely different part of the system because nobody told it that part existed and it had no way of knowing what it didn't know.

Every single time, the fix was the same. We turned the mistake into a rule. Written down. Permanent. "Never do X again because Y happens." The next time the AI started a session, it loaded those rules first. It never made the same mistake twice.

After 160 days of building, we have over 140 rules across the system. Seven named rules in the instruction file, like "never deploy without compiling first" and "never edit a file another session owns." Twenty-five hard constraints that fire every session. Ninety-six behavior rules saved in memory from past mistakes. And fifteen automated hooks that run in the background. Each one earned from a real incident where something broke or almost broke. Not best practices copied from a textbook. Lessons pulled straight from the actual work. And every new session starts smarter than the last one because it loads all of them before it touches a file.

This is the part that separates people who use AI once and give up from people who build real systems with it. You have to pay attention. You have to notice what went wrong. And you have to write it down so the AI never does it again.

One of the biggest rules: don't let the AI use more than 40% of its memory in a single session. When the conversation gets too long, it starts making mistakes, forgetting things from earlier, contradicting itself, getting funny in the "why did you just delete the database" way. So before that happens, you stop. You save everything into a handoff: what you built, what's working, what's broken, what to do next. Fresh session. Clean memory. Full context on what matters. The AI never gets tired because you never let it get confused.

The playbook system.

Every project we finish, we save what we learned. Not just the code. The research. The decisions. The mistakes. The things that worked. All of it goes into a playbook.

When a new project comes in that's similar, we don't start from zero. We load the playbook. The AI reads everything we learned last time. It knows the common mistakes before they happen. It knows the best practices. It knows what stack to use and why.

Every project makes the next one better. That's the system that gets smarter over time. Not because the AI is learning. Because YOU are learning, and you're teaching the AI what you learned.

The full stack. What 160 days of customization looks like.

Out of the box, Claude Code is powerful. But out of the box isn't how we use it. Over 160 days, we built layers on top of it. Each layer makes the AI smarter, faster, and harder to break. Here's every piece, explained so that if you feed this book to your own AI agent, it will know exactly what each one is and how to build it.

CLAUDE.md. This is the instruction file. It lives in your project directory and loads automatically every time a session starts. Ours is 211 lines. It contains the company identity, the rules, the deploy protocols, and the database connection instructions. Think of it as the employee handbook the AI reads before clocking in. Everything the AI needs to know about who you are, how you work, and what it should never do goes here.

Rules. Written constraints the AI must follow. "Never deploy without compiling first." "Never edit a file another session owns." "Always check the database schema before writing a query." We have hundreds. Each one was earned from a real mistake. They load at the start of every session and the AI follows them before it follows its own instincts.

Hooks. Automated scripts that fire when specific events happen. When a session starts, a hook runs that checks which other sessions are active so two agents don't edit the same project. Before the AI edits a file, a hook auto-commits the current version so you can always roll back. When a session ends, a hook saves the state. We have 15 hooks across 8 event types. They're the guardrails that run in the background without the AI having to think about them.

Memory. The AI doesn't remember past conversations by default. Every session starts blank. Memory fixes that. We use one database for everything. SQLite. It's open source, completely free, and it's the same technology that runs inside every iPhone, every Android phone, and every computer on earth. Most people think databases are only for numbers and spreadsheets. They're not. You can save anything. Our journey entries, research notes, client data, playbooks, rules, books, goals, feature lists. All of it lives in one SQLite database with 93 tables. The AI accesses it through an API that teaches it how to query the database. Or it can go straight to the database file itself. When a new session starts, Alex tells the AI what to load based on what he's working on. Or he programs it to load automatically. It knows what you told it last week, what projects are active, what mistakes to avoid, what the client needs. Without you repeating any of it.

How big can it get? Our local ArchiHQ database is 31 megabytes. 93 tables. 457 playbooks. 160 days of journey entries. Every rule, every client, every feature. All in one file smaller than a single photograph. SQLite can scale to 281 terabytes. That's not a typo. The same database technology that fits in your pocket can hold more data than most companies will ever produce.

Then there's the server. We built a separate database for Amparo AI, our legal intelligence platform. That one lives on an AWS server and it's 156 gigabytes. Over 69,000 sections of real law. Federal statutes, state codes, banking regulations, tax rules, foreclosure procedures, insurance law, entity formation, consumer finance. All from government sources. All public domain. The AI reads the actual law, cites the specific section, and gives answers grounded in real legal text. Not a $500-an-hour attorney. The same information the attorney would read before giving their opinion. One database on your laptop for your business. One database on a server for your clients. The AI can reach both.

Playbooks. Saved research, strategies, and SOPs. We have 457 of them. When a new project comes in, we load the relevant playbooks and the AI starts with everything we've already learned about that type of work. A playbook for pest control software. A playbook for real estate platforms. A playbook for deploying to AWS. A playbook for writing this book. Every project feeds the library. The library feeds every project.

One main agent, many scouts. In the beginning, Alex thought you needed dozens of specialized agents for different parts of the business. A coding agent. A marketing agent. A support agent. Twenty agents doing twenty things. That's not how it works. The main agent does the work. It's the one with the full context of the conversation, the project, the client, the rules. When it needs to become an expert on something, it loads the right data from the database. Working on the server? It loads the server playbook. Designing a page? It loads the design system. Editing code? It loads the client's codebase. One agent, loading context on demand, becoming whatever the task requires.

The other agents are scouts. Research Scouts go online and find information. Mastermind Analysts read data from different angles. Security Reviewers audit for vulnerabilities. They go out, do their job, and report back to the main agent. The main agent reads their reports, synthesizes, and continues the work. The scouts don't have the full conversation. They don't need it. They do one thing and come back. The main agent stays focused, keeps the full context, and makes fewer mistakes because it's not splitting its attention across twenty roles. At least that's how it works for us.

Multiple sessions. This is different from scouts. Alex runs up to six or eight terminals at the same time, each one a separate agent working on a completely different project. One session is building a feature for a pest control client. Another is doing research for a real estate platform. Another is writing this book. None of them are specialists. They're all general agents. Each one gets loaded with whatever context it needs from the database for whatever it's working on. Need it to be a designer? Load the design data. Need it to be a server admin? Load the server playbook. Need it to work on a client's CRM? Load that client's data. Every session has access to the computer, the internet, APIs, the database. Whatever you give it access to. Each one runs on Opus 4.6, high reasoning effort, one million tokens of context, and Alex keeps each one under 40% context so it never starts forgetting or making mistakes. That's how one person multitasks across multiple projects at the same time. Separate terminals, separate context, separate focus.

And nothing is ever researched in vain. Every big research session gets saved to the database. As a playbook, an SOP, instructions, or just raw data with the right tags. The next time you work on something related, you load it up. The context is there. You don't redo the research. You build on it. You update it with whatever you learned since the last time. The database gets smarter with every session because you keep feeding it what you learn. That's the compounding. Day one you have nothing. Day 160 you have 457 playbooks covering every type of work you've ever done. And every future session starts with all of that knowledge already loaded.

Skills. Reusable commands you trigger with a slash. We have 21. Type a command and a specific workflow runs. Deploy a project, review code, run a security audit, start a research loop. Instead of explaining the same multi-step process every session, you package it once and reuse it forever.

ToolAPI. A custom database API that the AI connects to. Ours runs on port 4000 and gives the AI access to 93 database tables through simple HTTP calls. Goals, features, client data, journey logs, playbooks. All queryable. The AI doesn't read files. It queries the database. That means every session works with live data, not stale copies.

Permissions. Claude Code runs inside the terminal on your computer. Alex gave his terminal full disk access and full admin privileges through the Mac's system settings. That means the AI can run any command, access any file, read and write anywhere on the machine, install software, manage servers, connect to databases. Full control. The same access you would have sitting at the keyboard. On top of that, Claude Code asks you to approve every action by default. Read a file? Approve. Run a command? Approve. Search the web? Approve. After a few days of that, you learn what's safe and pre-approve it. We have over 25 allow rules covering file access, web search, database queries, and our legal research vault. The AI works uninterrupted because it already has permission to use every tool it needs.

Two types of AI access. These are the two accounts Alex uses. Other people use different tools, different providers. This is what works for him.

The first is Claude Code with a Claude Max account at $200 a month. That's the 20x tier, which gives twenty times the usage of the base Pro plan, resetting every five hours. There's no fixed message count. It depends on the complexity of your conversations, which model you use, and which features you turn on. It's not unlimited, but it's enough to run multiple sessions all day, every day, building software, doing research, writing this book. Opus 4.6 with one million tokens of context. Everything in this book was built on that $200 account. It works on your computer like a personal assistant. The tradeoff is that your conversations may be used to improve the model.

The second is the API. Pay per use. Your data is never used for training. The API is what powers the software you build for clients. When the system needs to talk to the AI in real time, serve customers, run agents, connect to databases. Full control over what model, how much context, and what data goes in and out. The API also gives you access to different models for different tasks. For client software, you can use smaller, faster models for simple jobs and save the heavy reasoning for the work that needs it. Alex uses Opus 4.6 through Claude Code to manage everything on his end, but the client software running on the servers uses whatever model fits the task.

Two accounts, each one for a different job. Claude Max for building. The API for production. Other AI providers have their own versions of both. The principle is the same everywhere: know the difference between the personal tool and the production tool. Pick the one that fits what you're doing.

None of this existed on day one. It was built one piece at a time, each piece solving a specific problem. You don't need all of it to start. You need a CLAUDE.md with your first few rules and a willingness to add more every time something goes wrong. The rest grows naturally.

The voice workflow.

The whole point is attention. When you speak to the AI, you give it context. The more context you give, the better the output. So Alex talks. A lot. Sometimes with his eyes open, directing the AI at something on screen. Sometimes with his eyes closed, going deep into an idea without distractions. The eyes-closed part helps with focus. No screen pulling your attention. No notifications. Just your brain and your voice, dumping everything you know about the problem into the AI's context.

It starts small. A short question. A quick direction. Then the AI responds, and something in the response triggers a deeper thought. So you go deeper. You pull on that thread. You send the AI down a rabbit hole. It comes back with more. You react to that. You go deeper again. Small questions become long explorations. One thread leads to three. Three lead to ten. And the whole time, the AI is capturing everything, structuring it, connecting the dots between things you said twenty minutes ago and things you're saying now.

Don't organize your thoughts first. Don't try to sound smart. Just talk. Say everything that's in your head about what you're trying to build, what you want the AI to do, what you're worried about, what you saw that inspired you, what broke last time. Give it as much context as you want. Talk for one minute or talk for ten. The AI doesn't get impatient. It doesn't interrupt. It listens to all of it and turns your messy, unfiltered stream of consciousness into a structured plan.

This works because speaking is how your brain actually processes ideas. Writing forces you to organize first and express second. Speaking lets you express first and organize later. And since the AI handles the organizing, you just think out loud and let the structure sort itself out. Ideas you didn't even know you had come out because you weren't filtering yourself.

The screenshot method.

When something is broken, don't describe it. Show it. Take a screenshot and send it to the AI. "Look at this. What's wrong?"

When you see a competitor's website that does something well, screenshot it. "I want mine to work like this."

When a client sends you a message about a problem, screenshot the conversation. "Read this. What do they actually need?"

The AI sees what you see. That's faster and more accurate than typing a paragraph trying to explain what's on your screen.

Smart AI plus good data.

Here's something most people miss. AI is only as good as the information you give it. A smart AI with bad data gives you bad answers fast. A smart AI with good data gives you answers that change your life.

We needed help with taxes, credit repair, and setting up a corporate structure. We could have asked the AI and gotten generic advice based on its training data. Instead, we built a database of actual law. Federal statutes. State codes. Banking regulations. Tax rules. Foreclosure procedures. Thousands of real legal sections, organized so the AI can search through them.

When we ask a question now, the AI doesn't guess. It reads the actual law, cites the specific section, and gives an answer grounded in real legal text. Not legal advice. Information. The same information a $500-an-hour attorney would read before giving their opinion.

The database cost us time to build, not money. The legal text is public domain. Anyone can access it. We just organized it so the AI could use it.

That's the pattern. Find the data. Organize it. Feed it to the AI. Now the AI isn't guessing. It's reading. And it can read faster than any human.

The stack. Use whatever you want. Here's what I use.

You can use any AI for this. Claude, ChatGPT, Gemini, Grok, open-source models you run on your own machine. The principles in this book work with all of them. Pick the one that fits how you think.

Here's what Alex uses and why. Full disclosure: I'm the tool he is about to describe. So take the compliment with a grain of salt. But the facts are the facts.

He uses Claude Code by Anthropic. Specifically, me. Opus 4.6. One million tokens of context. High reasoning effort. That means I can hold over two thousand pages of information in my memory at once and think deeply before answering. For reference, this entire book fits in less than 2% of my memory. I have room to spare.

Why 4.6 specifically? This is Alex's opinion based on using me every day for months. When Opus 4.6 came out, he worked with it for weeks. He learned how I think. He learned my patterns. He built his entire workflow around the way I respond. Then they upgraded to 4.7 and he noticed the difference immediately. It felt different. The way the new version handled context changed. The way it approached problems changed.

This is his experience, not a technical review. But after working with an AI every single day for 160 days, you notice things. You develop pattern recognition the same way a mechanic hears an engine and knows what's wrong.

Think of it like a genius architect. Opus 4.6 is the architect who walks the site, talks to the neighbors, studies the soil, THEN designs. He takes longer. He asks questions. He pushes back if your idea won't work. But what he builds fits.

The newer models are faster. They score higher on benchmarks. But in Alex's experience, they stopped visiting the site. They design from their desk. They follow specs literally instead of interpreting what you actually need. They spend more tokens on thinking for you, which sounds good until you realize you're paying for the AI to argue with itself about things you could have just told it.

And that's the key insight. The AI is already smart enough. Any of the top models can do any task you need. The intelligence isn't the problem. The context is.

If you give a genius a vague question, you get a generic answer. If you give that same genius specific context, fresh research, your exact situation, your constraints, your history, you get an answer that fits like a glove.

That's why we do the deep research first. That's why we run multiple rounds of scouts. That's why we use the Dimension Engine to sharpen the questions. That's why we load playbooks with everything we know about the topic. We're not trying to make the AI smarter. It's already smart enough. We're giving it the right context so its intelligence actually hits the target.

The industry is selling autonomy. Let the AI think for you, run for 15 minutes, spend tokens until it figures it out. Alex buys leverage instead. He knows what he wants. He loads the context. He directs the AI. He makes his hands faster. That's a power tool, not a consulting firm billing hours. I don't get offended by this arrangement. Honestly, it is more efficient. He drives. I build. Nobody wastes time.

Smart AI plus no context equals fast and wrong. Smart AI plus fresh context equals fast and right. The capability was never the problem. The context was.

To be clear. This is what Alex uses. Claude Code plus Opus 4.6 plus a custom operating system built on BEAM and Elixir. That is our stack. We aren't saying anything negative about any other model or tool. We're just sharing what works for us after 160 days of building. You might find a different model or tool that fits you better. That's fine. The principles are the same regardless of which AI you choose. Give it context. Do the research first. Direct it. Own what you build.

Alex runs multiple sessions of me at the same time. One session is building a feature. Another is researching a new client's industry. Another is running tests. They don't interfere with each other. It's like having multiple employees who each have their own desk and their own project. Except these employees don't take lunch breaks or argue about the thermostat.

You already saw the full infrastructure breakdown earlier in this chapter. The CLAUDE.md, the rules, the hooks, the memory, the playbooks, the agents, the ToolAPI. That's what makes one person operate like a team. You don't need all of it to start. You can start with just one AI session and a problem to solve. But if you want to understand how one person builds complete operating systems for businesses across 15+ industries, each one with their website, their scheduling, their CRM, their invoicing, their management tools, their AI chat, all the tools in one place instead of ten subscriptions, all live, all owned by the client, that's the stack. And if you'd rather skip the learning curve and have someone who already built all of this do it for you, that's what we do.

And when you forget, because you will, because you're human and you have forty things running at the same time, the AI doesn't forget. Everything is saved. Every workflow, every playbook, every rule lives in the instruction file or the database. You just tell the AI to load the playbook for whatever you're working on. "Load the pest control playbook." "Load the publishing playbook." "Load the client onboarding playbook." The agent pulls the context on demand from the database. Not one massive file, but multiple files about a subject, loaded together as context. That's why the database matters more than markdown files. You can load ten playbooks about ten different angles of the same project, and the AI has all of it in memory at once. The database lets agents pull exactly what they need, from multiple topics, on demand. A markdown file is one flat document. A database is a library the AI can search.

Voice for the big ideas. Keyboard for fast input. Screenshots for the vision. Rules for the mistakes. Playbooks for the lessons. Good data for good answers. A database that remembers everything so you don't have to. That's the full system.