The Organism

A business isn't a person with tools. It's an organism — a system of processes that take inputs, transform them, and produce outputs. Software companies figured out decades ago that computers can automate many of those processes. LLMs extend that to processes that previously required human judgment. Not replacing the judgment, augmenting it. There's a line often attributed to old IBM training manuals that captures this well:

Decisions should be driven by humans. We can't absolve ourselves of responsibility for the systems we manage. But we can design systems where the human focuses on the decisions that matter while agents handle the volume.

The Shape of an Agentic Company

During the Acorn build, I kept noticing how many traditional team roles have agentic equivalents. Not replacements, but a different way of performing the same function:

What's left for the human? The hardest part: strategy (what to build and why), domain expertise (GPS methodology, genealogy data models), information architecture (the specs and DAGs), and judgment (when the approach isn't working, what to change).

This is about what one person can do when agents handle the commodity labor: translating specs into code. The human work is real and hard. It's just different work.

What I've Found Working Like This

The tools that make agents effective make me more effective:

• Clear specifications of what is to be done
• Documentation for how a system should work
• Well-defined interfaces between components

These are things we've always known matter. We just rarely prioritize them because the cost of not doing them isn't felt immediately — there's always more to build. But in an agentic workflow, these aren't "nice to haves." They're the input. If the spec is vague, the output is vague. If the interfaces are clean, the output is clean.

The same information architecture discipline that makes agents productive makes teams productive. The difference is that agents make the payoff immediate and obvious.

Where's the App?

So why haven't I released the app I've spent four posts talking about?

Building something is only part of the experiment. I've demonstrated that it's possible to generate a large software project quickly using agentic tooling. What I have not demonstrated is that the result can be operated safely or sustainably.

On safety: I need to confirm that user data is managed securely — and that continued development on the system preserves that property. Building with a novel process means I don't yet have the guardrails that prevent a future agent session from introducing a vulnerability. That needs to be designed, not assumed.

On operations: building something alone is relatively easy compared to adapting it quickly to users' changing needs. As Eric Ries says in The Lean Startup:

The only way to win is to learn faster than anyone else.

I need tooling to diagnose issues, understand how users interact with the system, and surface patterns that inform what to build next. A simple "Claude, please fix" won't identify a specific gap in an onboarding flow that improves retention — that requires careful processes that surface information and drive analysis.

Beyond Code Generation

The build story — what this series has covered — proves that agents can reliably produce code at scale when given good specifications. But code generation is the easy part of running a software business. The next frontier isn't writing more code faster. It's agents helping operate the business:

• Analyzing Honeycomb traces to surface performance anomalies
• Reviewing PostHog funnels to identify UX drop-off points
• Scanning codebases for security vulnerabilities
• Triaging incidents by correlating signals across services
• Drafting responses to user feedback

Observability and product analytics platforms already provide agent-friendly interfaces for much of this. The question is designing a process that lets me leverage agents to identify which problems to solve — not just to solve the ones I've already found.

This is uncharted territory, and the same discipline applies. You can't just hand an agent access to production logs and hope for the best. You need specs for what the agent monitors, contracts for what actions it can take, and review gates for anything that touches live systems. The same information architecture that made the build story work needs to extend to operations — with higher stakes, because production mistakes affect real users.

The Competitive Moat Question

If everyone has access to the same AI models — and they do — where's the advantage?

It's not in the code. The code is generated. It's in the information architecture: the interface specs, the dependency DAGs, the domain expertise encoded in system prompts, the tooling that makes the process reliable. That's a different kind of moat than "we have the best engineers." It's closer to "we understand our problem domain deeply enough to specify it precisely, and we've built the infrastructure to make that specification actionable."

Going Slow on Purpose

The speed of building doesn't mean you rush the release. I spent a long time thinking carefully about how to build this system. The same decomposition discipline that produced 866 commits in two weeks needs to apply to the rollout: what are the specs for "ready to ship"? What are the quality gates for production? What does the monitoring contract look like?

Nobody's done this publicly. Others may be doing it privately, but they aren't sharing. I'm sharing, warts and all — because I think the conversation needs real data from real attempts, not just hot takes and demo videos.

Here's what I know so far. I'll keep sharing as I learn more.