In the first article of this series, I described how I went from vibe coding to building a structured system that actually ships. I talked about the five key insights (rules, verification, learning from mistakes, context management, and automated guardrails) that transformed my AI development process from chaos into something that resembles a real engineering organization.
But I glossed over something important: how those pieces connect. Because individually, they're just good ideas. What makes them powerful is the connective tissue, a protocol system that turns isolated practices into a repeatable, auditable development workflow.
This article is about that connective tissue. It's about how structured commands turn AI from something you talk to into something you work with.
The Problem With Talking to AI
Here's how most people use AI coding tools: they open a chat window and start typing. "Build me a login page." "Add a database table for orders." "Fix the bug where the sidebar doesn't collapse."
This works. Kind of. For simple things. But it's the equivalent of managing a team by shouting across the room. Every instruction is ad hoc. Every response is a one-off. There's no process, no repeatability, no way to ensure that the same task gets done the same way twice.
Think about how a well-run company operates. When a new employee starts, you don't just shout instructions at them all day. You give them a procedure manual. You show them the established workflows. You say: "When a customer order comes in, here's the twelve-step process we follow, every time, no exceptions." The employee might be brilliant, but brilliance without process produces inconsistent results.
AI is the same way. It might be the most capable "employee" you've ever worked with, but if you're giving it freeform instructions every time, you're getting freeform results. Sometimes great, sometimes terrible, and you never quite know which you're going to get.
I spent months in this mode before I realized there was a better way.
Structured Commands: The Procedure Manual
The solution was structured commands: predefined sequences that the AI follows when triggered. Think of them as playbooks. Instead of describing what I want done from scratch every time, I invoke a command, and the AI follows a defined protocol. A specific sequence of steps, checks, and decisions that produces a consistent result.
Here's a conceptual example. Say I need to plan a new feature. In the freeform world, I'd type something like: "I need to add a notifications system. Can you plan that out?" The AI would produce something, maybe good, maybe incomplete, maybe brilliant in some areas and blind in others. Every time I asked for a plan, the quality and structure would be different.
With a structured command, I invoke something like a planning protocol. The AI doesn't just brainstorm. It follows a defined sequence: analyze the existing codebase for related features, check the database schema for relevant tables, identify established patterns that apply, produce a structured plan in a specific format, then audit its own plan for gaps. If gaps are found, it loops back and fixes them before presenting the result.
Same AI. Same capability. Radically different output --- because the process is defined, not improvised.
I built these structured commands for every major development activity: planning features, implementing code, writing database migrations, debugging issues, committing changes, auditing quality, and deploying to production. Each one encodes the lessons I've learned about what that activity requires to be done well.
What a Protocol Actually Looks Like
The specific implementations have been productized as Massu AI, where they're available as thirty-one open-source workflow commands you can install and use today. But understanding the anatomy of a protocol matters more than any particular implementation, so let me describe how they work in general terms.
Every protocol has a few key elements:
A defined trigger. The protocol activates when I invoke a specific command. This is important because it means I'm making a conscious decision about which process to follow, not just throwing a request into the void.
A sequence of steps. Not suggestions --- steps. The AI executes them in order. Some steps are analytical (read these files, check this schema). Some are creative (design this component, write this migration). Some are verification (prove this works, confirm this matches the plan). The order matters because each step builds on the outputs of previous steps.
Quality gates. At defined points in the sequence, the protocol requires the AI to stop and verify something before continuing. If the verification fails, the protocol specifies what to do, usually loop back to an earlier step and fix the issue. The AI doesn't get to skip gates or mark them as "probably fine."
Mandatory outputs. Each protocol defines what it must produce. A planning protocol produces a structured plan document. An implementation protocol produces code changes with verification proof. A commit protocol produces a vetted commit with a meaningful message. These aren't optional; the protocol isn't complete until the outputs exist and have been verified.
Failure handling. When something goes wrong (and things always go wrong), the protocol specifies how to respond. Not "figure it out," but specific recovery procedures. If a build fails after code changes, the protocol defines whether to fix and retry, roll back, or escalate.
The critical thing is that none of this is advisory. The AI doesn't read the protocol and then decide which parts to follow. It executes the protocol. Every step, every gate, every output requirement. This distinction, between advisory documentation and mandatory execution instructions, is one of the most important lessons I've learned.
The Golden Path
Once I had individual protocols for different activities, something interesting happened: they started connecting.
The planning protocol produces a structured plan. The implementation protocol consumes that plan as input. The verification protocol checks implementation against the plan. The commit protocol packages verified work. The deployment protocol validates everything end-to-end.
In Massu AI, this chain looks like concrete commands:
/massu-create-plangenerates a structured plan with blast radius analysis and verification requirements/massu-planaudits the plan for gaps, looping until coverage is complete/massu-loopimplements the plan item by item, with verification proof for each deliverable/massu-commitruns pre-commit verification --- pattern scanning, security checks, type safety/massu-pushgates the push with full test suite, regression detection, and security audit/massu-reviewspawns an independent AI agent for 7-dimension code review
I started calling this the "golden path": a complete workflow from idea to production, with quality gates at every transition point. When I invoke the golden path, the AI moves through the entire sequence: plan, implement, verify, commit, deploy. Each phase feeds the next, and quality is enforced at every boundary.
This is where things started feeling genuinely different from "using an AI tool." The golden path isn't me directing the AI step by step. It's me initiating a process, and the process directing the AI through a proven workflow. I'm not managing the work; I'm managing the system that manages the work.
When it works well (and it usually does), I can go from "I need feature X" to "feature X is deployed and verified" with minimal intervention. Not because the AI is magic, but because the process is thorough.
When it doesn't work well, the quality gates catch the problem before it reaches production. That's the whole point.
Format Grammars: Teaching Consistency at the File Level
One of the more subtle protocols I built addresses a problem that drove me crazy for months: inconsistent file formatting.
AI is creative. That's usually a strength, but when you're writing database migrations, creativity is the enemy. A migration needs to follow exact conventions: specific ordering of statements, mandatory security policies, required access grants, specific comment formats. Every time. Without exception.
I tried putting these requirements in my general rules file. It helped, but the AI would still occasionally get creative. It would remember seven of the nine requirements and improvise on the other two.
So I built what I call format grammars: dedicated protocol files that define the exact structure for specific file types. When the AI needs to write a database migration, it loads the migration format grammar, which specifies every element that must be present, in what order, with what syntax. When it needs to write an API route, it loads the API route format grammar.
Think of format grammars as templates with intelligence. They're not just boilerplate to copy-paste; they encode the reasoning behind the format. Why security policies are required. Why grants must follow a specific pattern. Why certain columns need specific data types. The AI understands the why, which means it can adapt the format to new situations while still maintaining compliance.
The result is that every database migration looks like it was written by the same person following the same process. Every API route follows the same structure. Every component file has the same organization. Across hundreds of files and months of development, the codebase has a consistency that would be remarkable for a large team and is frankly astonishing for a solo developer working with AI.
The Compound Effect
Here's what surprised me most about building protocols: the value compounds over time, and it compounds faster than you'd expect.
Each individual protocol makes one activity better. But when protocols build on each other, the improvement is multiplicative.
The planning protocol produces better plans because it follows a rigorous process. Better plans mean the implementation protocol has clearer inputs. Clearer inputs mean fewer implementation errors. Fewer errors mean the verification protocol catches fewer problems. Fewer problems mean faster commits. Faster commits mean more frequent deployments.
And it works in the other direction, too. When the verification protocol catches a problem, that feeds back into the planning protocol: "plans must now explicitly address this category of issue." When the deployment protocol surfaces an environment mismatch, that feeds back into the implementation protocol: "always verify environment configuration before coding."
Over time, the protocols accumulate the lessons from every feature I've built, every bug I've encountered, every deployment that went sideways. The system doesn't just maintain quality --- it gets better at maintaining quality. Every month, the protocols are more thorough than the month before, because they've absorbed more failure modes and more hard-won insights.
This is the compound effect, and it's the reason I'm convinced this approach has a structural advantage over freeform AI development. Freeform doesn't compound. You might get better at prompting over time, but your prompts don't carry forward the lessons from last Tuesday's failed deployment. Protocols do.
Evolution Through Failure
I want to be honest about something: my protocols didn't start out good. They started out terrible.
My first planning protocol was basically "make a plan." My first implementation protocol was "follow the plan." These are not protocols. These are wishes.
What turned wishes into real protocols was failure. Specifically, the incident system I described in Article 1. Every time something goes wrong that the system should have caught, I trace back to the protocol that failed and strengthen it.
A deployment breaks because the plan didn't account for database schema differences between environments? The planning protocol now requires environment schema verification as a mandatory step. A feature ships incomplete because the AI claimed "100% complete" after implementing seven of nine items? The verification protocol now requires item-by-item proof with command outputs for every single deliverable. A commit includes a security vulnerability because the review was superficial? The commit protocol now includes a mandatory security checklist.
Each protocol has been shaped by real failures. Not hypothetical ones --- actual production incidents that cost me time, trust, or both. The protocol for database migrations exists in its current form because I once deployed a migration that was missing security policies, locking real users out of real features. The protocol for code commits exists because I once pushed credentials to a public repository and spent hours rotating secrets.
These aren't abstract best practices borrowed from a textbook. They're scar tissue.
And here's the thing about scar tissue: it's stronger than the original. Every protocol in my system has been tested by the exact failure it was built to prevent. Not theoretically tested. Battle tested. That's why I trust them.
Advisory vs. Mandatory: The Lesson That Changed Everything
Early on, I made a mistake that cost me weeks of frustration. I wrote beautiful, detailed protocols. The AI read them. And then it followed about seventy percent of the steps and skipped the rest.
This was maddening. The protocols were right there. The AI clearly understood them; it could explain what the steps were and why they mattered. But understanding and compliance are not the same thing.
The problem was that I'd written my protocols as documentation. As advice. "Here's how this should be done." The AI treated them the way most people treat advice: as input to its own judgment about what to do.
The fix was changing the framing from advisory to mandatory. Not "here's how to do it" but "do this, in this order, and do not proceed until each step is complete." Not "verification is important" but "run this command, show the output, and stop if it fails."
The difference sounds small. It's enormous. Advisory protocols produce suggestions. Mandatory protocols produce execution. And with AI, execution is the only thing that matters.
I actually logged this as a formal incident after the AI read a planning protocol, understood every word of it, and then executed one pass through a multi-pass audit loop before stopping to report findings. The protocol explicitly said "loop until all gaps are resolved, restarting from step one after each fix." The AI read that instruction. And then it did something else.
After that incident, I restructured every protocol to make the mandatory nature unavoidable. Steps are numbered and must be executed sequentially. Loops have explicit continuation conditions. Gates have explicit pass/fail criteria. The AI cannot exercise "judgment" about whether a step is necessary; the protocol decides that, not the AI.
This lesson became so important that it's now a canonical rule in Massu --- CR-8: "Protocol Commands Are Mandatory Execution Instructions." When a protocol says "loop until X," the system loops until X. When it says "MUST restart from Step 1," it restarts. When it says "FORBIDDEN," it's forbidden. Default AI behavior (report findings, suggest next steps) must yield to explicit protocol instructions.
This one change, from advisory to mandatory, is probably the single biggest improvement I've made to the entire system. If you take nothing else from this article, take this: don't write guidelines for your AI. Write orders.
What This Makes Possible
Let me step back and describe what development actually looks like now, on a good day.
I identify a feature I need. I run /massu-create-plan. The AI analyzes my codebase, checks the database, identifies relevant patterns, and produces a detailed, structured plan. I run /massu-plan to audit for gaps --- it loops until coverage is complete.
I review the plan (this is where my judgment matters most) and approve it with any modifications. Then I run /massu-loop. The AI works through the plan item by item, writing code, verifying each piece, running builds, and checking for regressions. If something fails, the protocol handles it.
When implementation is complete, verification runs automatically. Every claim is backed by proof. Every file existence is confirmed. Every feature is traced from backend to frontend. If gaps exist, the protocol loops back.
Then /massu-commit runs. Pattern compliance is checked. Security is verified. The commit is clean and meaningful. Then /massu-push, with its own verification gates --- full test suite, regression detection, and security scanning before anything reaches the remote repository.
Start to finish, a feature that would have taken me days of manual back-and-forth now completes in hours, with higher quality and better documentation than the manual approach ever produced.
This isn't magic. It's process. But it's process that would be impossibly tedious to follow manually, made practical by the fact that AI is tireless, literal, and fast. The combination of human judgment (deciding what to build, reviewing plans, approving approaches) and AI execution (following protocols, running verifications, maintaining consistency) is genuinely greater than the sum of its parts.
What's Next
In the next article, I'll dive into one of the hardest problems in AI-assisted development: memory. AI models don't remember anything between sessions by default. Every conversation starts from zero. I'll explain how I built a memory system that persists knowledge across sessions --- not just facts, but lessons, decisions, failures, and context --- so the AI genuinely improves over time instead of repeating the same mistakes.
Because the best protocol in the world is useless if the AI forgets it exists.
This is Part 2 of a 10-part series on building enterprise software with AI:
- How I Stopped Vibe Coding and Built a System That Actually Ships
- The Protocol System: How I Turned AI From a Chatbot Into a Development Partner (this article)
- Memory That Persists: How I Made AI Actually Learn From Its Mistakes
- The Verification Mindset: Why "Trust But Verify" Is Wrong When Building With AI
- Automated Enforcement: Building Hooks and Gates That Catch Problems Before You Even See Them
- The Incident Loop: How Every Bug Makes Your AI Development System Permanently Stronger
- Planning Like an Architect: Why AI Needs a Blueprint Before Writing a Single Line of Code
- Context Is the Bottleneck: Managing AI's Most Precious and Most Fragile Resource
- Solo Worker, Enterprise Quality: The New Economics of AI-Assisted Development
- The Knowledge Graph: Teaching AI to Understand Your Codebase as a Living System
I'm the Co-founder and COO of Limn, where we create luxury furniture and fixtures for large-scale architectural and building projects. Alongside the physical work, we design the systems required to manage a complex, global lifecycle --- from development and production to shipping and final delivery. The governance system I built for Limn's software is now Massu AI, an open-source AI engineering governance platform.
Imagined in California. Designed in Milan. Made for you.
Here, I share what I've learned about making AI development actually work in the real world.
Have questions or want to share your own AI development setup? I'd love to hear from you in the comments.