Pulling Weeds on the Moon: Why Documentation Is the Only Thing Keeping My AI Company Alive

In The Little Prince, the boy lives on a tiny asteroid — Asteroid B-612. Every morning, he performs a ritual: he pulls up the baobab seedlings.

Baobabs are harmless as seedlings. Small enough to pluck with two fingers. But if you let them grow, their roots will crack the asteroid apart. The Little Prince is vigilant about this not because the task is hard, but because the consequence of neglect is total. Skip one morning, and by the time you notice, the roots have already split the rock.

I think about this every day. Because I run a company on a very small asteroid — one person, six AI agents, 283,000 lines of code — and the baobabs are documentation rot.

The Problem Nobody Talks About

Here is the dirty secret of AI-assisted development: AI agents have no memory.

Not the kind that matters, anyway. Yes, they can reference conversation history within a session. Yes, you can inject context into prompts. But the moment a session ends, the context evaporates. Tomorrow's AI has no idea what today's AI decided, unless you wrote it down.

When I say "wrote it down," I don't mean a Notion page. I don't mean a Slack message. I mean a structured document, in a specific location, with a defined format, that the AI will reliably read the next time it needs to make a decision in that domain.

My codebase contains 356 markdown files totaling 186,550 lines of documentation. That is not a nice-to-have. That is oxygen. Without it, my AI agents — Morgan, Raven, Nova, Aria, Atlas, Sage — would produce outputs so disconnected from reality that I might as well be reading horoscopes.

What Happens When Documentation Decays

Let me tell you a story about what happens when you skip the morning weeding.

In January 2026, I was deep in the GMCC mortgage video system — building AI-generated marketing videos for Chinese-American loan officers. Intense work. I was shipping features daily, sometimes hourly. I stopped updating the documentation.

Not deliberately. It was the slow drift of "I'll update the docs after this sprint" becoming "I'll update them after this feature" becoming "I'll update them... eventually."

Three weeks later, I asked my AI coding assistant to modify the credit system. The assistant read CREDITS_NORTH_STAR.md — the single source of truth for how credits work — and dutifully followed what it said. The problem: the doc still described the January campaign as upcoming ("campaign ends Jan 28, 2026; all bonus credits expire Jan 30, 2026"). It was now mid-February. The campaign was over. The credits had expired. But the AI didn't know that, because the documentation didn't know that.

The assistant generated code that treated expired credits as still active. Not because it was stupid — because it was perfectly following the information I gave it. The intelligence was working exactly as designed. The information was wrong.

One stale paragraph. Three hours of debugging.

I went back and updated the doc. I added a note: "campaign is now closed." Thirty seconds of writing that would have saved three hours of confusion.

The baobab was small when I should have pulled it.

The Documentation Stack

Here is how I organize the documents that keep 283K lines of code and 6 AI agents coherent:

Layer 1: North Star Documents (Never Wrong)

These are the gravity wells. Everything orbits around them.

| Document | Lines | Controls | |----------|-------|----------| | CREDITS_NORTH_STAR.md | ~250 | How credits work. Types, expiration, model restrictions, pricing. | | WORKFLOW_CASCADE_NORTH_STAR.md | ~200 | How the 6-step video production flow works. Data cascade rules. | | PAYMENTS_NORTH_STAR.md | ~200 | Stripe integration. Subscription tiers. Webhook handling. | | STORAGE_NORTH_STAR.md | ~200 | Where files live. Bucket structure. Upload/download patterns. | | ACCOUNT_MANAGEMENT_NORTH_STAR.md | ~150 | Account deletion. GDPR. Data recovery. | | WORKFLOW_MANAGEMENT_SYSTEM.md | ~2,000 | Company operations. 4 workflows. State machines. Approval gates. |

The rule: If a North Star document says X, and the code says Y, the code is wrong. North Stars are the constitution. They are amended deliberately, not eroded gradually.

When I introduced the AI cofounder system in February, I didn't just build the code. I wrote AI_COMPANY_STRUCTURE.md (461 lines), SOLO_FOUNDER_AI_STRUCTURE.md (611 lines), and CEO_DASHBOARD_DESIGN.md (654 lines) — before shipping any of it. The documentation came first because the documentation is what the AI reads when it needs to understand the system.

Layer 2: System Documents (Load on Demand)

These are the reference manuals. Each one covers a specific subsystem in 150-200 lines: authentication, video generation, gallery, templates, production, permissions, GitHub issues.

They live in a /docs/systems/ folder and are loaded by AI agents only when they need to work on that system. This is deliberate: if you inject all documentation into every prompt, the AI drowns in context and starts producing outputs that reference everything and understand nothing.

The principle is surgical context: give the AI exactly the information it needs for this task, nothing more.

Layer 3: Decision Log (Why We Did That)

DECISIONS.md records every non-obvious architectural choice with the date, the options considered, and the rationale. When an AI agent or a future human asks "why does the credit system work this way?" — the answer is in the log.

Without this, every AI session starts from zero. The assistant sees the code and wonders why it's structured this way. It might "improve" it — undoing a deliberate design decision because the reason for the decision is nowhere in the codebase.

I have watched an AI agent refactor a function that was intentionally written in a non-obvious way to work around a Firebase limitation. The agent didn't know about the limitation because I hadn't documented it. The refactored code was cleaner, more elegant, and completely broken in production.

Decisions without documentation are time bombs.

Layer 4: Invariants (The Laws of Physics)

INVARIANTS.md contains the rules that must never be violated, regardless of what any AI agent or human decides:

Never modify the Stripe API version (currently 2025-12-15.clover)
Never store secrets in code
Never exceed 500 lines per file
Never bypass the approval queue for outbound emails
All prices are in cents, not dollars

These are not guidelines. They are hard constraints. I reference them in CLAUDE.md (the instructions file that every AI coding session loads automatically), so the AI knows these rules before writing a single line of code.

When I don't have invariants documented, the AI makes reasonable decisions that violate unreasonable constraints. It will "helpfully" update the Stripe API version to the latest one — not knowing that this specific version is the one that doesn't break our webhook handlers. It will "clean up" a function that handles prices in cents by converting them to dollars — not knowing that Stripe's API expects cents.

Every invariant I've documented was learned the hard way. Every one was a production bug first.

Layer 5: Bug Patterns (Don't Step There Again)

consistent-bugs-to-avoid.md catalogs 13 recurring bug patterns mined from git history. Each pattern has: the symptom, the root cause, the fix, and the rule to prevent recurrence.

This is the most unusual document in the stack, and the most valuable per line. When an AI agent is about to generate code that touches the credit system, it reads the bug patterns first. Pattern #3 might say: "Never check credits on the client side. Always verify server-side via the API route." The agent adjusts its approach before generating the code.

Without this file, the same bugs recur. Not because the AI is unintelligent, but because it has no institutional memory. The bug patterns document is the institutional memory.

The Daily Ritual

Every morning, before I look at code:

I read Morgan's briefing (CMO) — are there content drafts pending review? Signals detected?
I review the email approval queue — 10-15 minutes of approve/reject
I check if any documentation has drifted

That third step is the baobab pulling. I scan for:

Stale dates: Is any doc referencing a deadline that has passed?
Stale names: Did we rename a feature, and does the doc still use the old name?
Stale architecture: Did a recent code change invalidate a doc's description of how something works?
Missing docs: Did I build something this week that has no documentation?

When I find a seedling, I pull it immediately. Not after this sprint. Not after this feature. Now. Because in three weeks, that seedling is a root system, and the root system is three hours of debugging, and three hours of debugging is a day lost, and a day lost is — for a solo founder with $230K in the bank and a $9K/month burn — not an abstraction.

The AI Context Problem

Here is the deeper issue that documentation solves, and it's one that will define the next generation of AI-native companies: AI agents are only as good as the context they receive.

A large language model with perfect reasoning and wrong context will produce a perfectly reasoned wrong answer. This is not a failure of AI. It is a failure of information architecture.

When Morgan generates a CMO briefing, she receives:

Her personality configuration (creative, data-driven, growth-obsessed)
Real-time data from the email queue and marketing alert system
Up to 20 recent feedback signals from my approve/reject decisions
The brand configuration document (company voice, positioning, key features)

If any of those inputs are stale, Morgan's briefing is stale. If the brand config still describes us as "an AI filmmaking platform" when we've pivoted to also serving loan officers with AgentVideo, Morgan will draft content that ignores our highest-revenue product.

The documentation is not describing the company. The documentation is programming the company. Every markdown file is a configuration file for an AI agent's behavior. Update the doc, update the behavior. Let the doc rot, and the behavior rots with it.

This is why I call it "company as code." Not as a metaphor. The company literally runs on documents that are read by machines and executed as operating instructions.

The Counterintuitive Truth

Every founder I talk to says the same thing: "I know I should document more, but there's no time. I'm building."

I used to say this too. Then I calculated the actual cost.

Cost of writing documentation: 30-60 minutes per major system. Maybe 2 hours per week across the whole company.

Cost of not writing documentation: 3-hour debugging sessions when the AI follows stale instructions. Features built on wrong assumptions. Architectural decisions reversed and re-reversed because nobody remembers why the original decision was made. Context re-explained in every AI session because nothing is written down.

The undocumented company pays a documentation tax on every interaction. Every time you start a new AI session, you spend 15-30 minutes re-explaining context. Every time an AI agent generates code, you spend 10-20 minutes verifying it didn't violate an undocumented constraint. Every time someone new (human or AI) touches a system, they spend an hour understanding what the system does because the system doesn't explain itself.

I spend 2 hours per week maintaining documentation. I estimate this saves me 10-15 hours per week in re-explanation, debugging, and reversal costs.

That's not a time investment. That's a 5-7x return.

The Little Prince Was Right

Saint-Exupery's story is usually read as a fable about love and loss and the loneliness of adulthood. It is all of those things. But it is also, quietly, a story about maintenance.

The Little Prince tends his rose. He pulls his baobabs. He cleans his volcanoes ("one never knows"). These are not heroic acts. They are not dramatic. They are the small, repetitive, unglamorous disciplines that keep a very small world from cracking apart.

Running an AI company as a solo founder is living on Asteroid B-612. The asteroid is small. The systems are powerful. The consequences of neglect are total.

Pull the baobabs every morning.

It's the most important work you'll do.

Q Powers is the founder of Leyline, an AI-native video production platform. Part 1: Learning to Speak Octopus. Part 2: Managing Gods. Follow the build on Twitter/X and LinkedIn.