My Nightmare Helped Me Create a Mental Model for Building With AI
I review every line my coding agents write and I still lost the picture of my own system. So I started Holon-Driven Development.
The Nightmare
A few months ago I dreamed I was demoing our product to my co-founder. I clicked through it and it didn't work. So I started debugging, right there in front of him, and then I realized I had no idea what was going on. The thing was way behind where I thought it was. I opened the project folder and it was empty. Nothing in there.
I woke up and it took me a while to calm down, because honestly it wasn't that far from the truth. And it's not that I wasn't looking. I review every single line the agents write. But I work on so many things in parallel that my eyes are on many different places at the same time, and after all that context switching I almost can't remember my own code anymore.
The product I'm building is everything at once: the application, the backend, data ingestion, pipelines, LLM workflows, even the CI/CD. I worked on all of those before the AI era, so I understand every part, and that's why I can take a job where I own everything. But my brain can't hold the code anymore, even after reviewing every line of it. I felt like I wasn't in control anymore.
And I don't think I'm the only one. A lot of engineers building with agents are feeling some version of this. The code ships faster than ever, and the sense of being in control slowly fades. That tells me the problem isn't discipline. Something is missing in how we develop software now that agents write most of the code, and nobody has figured out what it is yet.
A bit about me. I'm a technical founder with a background in full-stack development and data engineering. I run a small team of three on a stealth project, I've been co-founding a relationship platform full-time for the past 5 months as the only engineer, and I consult on software development for VC funds and startups. I've been coding for 14 years, and for the last year I've built almost everything with coding agents.
How it got there
My normal day is like 4 terminals open, each with an agent working on a different part of the system, and Notion open next to them. I write RFCs with Claude, break the ticket I'm working on into sub-tickets, and write ADRs for the important architectural points so the agents can read them and stay in sync with me. Each terminal prints hundreds of lines. Files it read, commands it ran, tests passed, tests failed. Before an agent writes anything I read its plan, I reject the bad proposals, we go back and forth until it's right, and then I approve it. Most of my day is planning with agents.
And I let the agents plan and talk through those plans with me again and again. But all of that still doesn't help me understand the system. The agents drift anyway. They keep coming back with options and suggestions that are outside the architecture, and sometimes things slip in that I just can't control. That's why I started designing a system to guardrail this.
At the end of the day my head is full of terminal output. The architecture is known, planned, and written down, but by the end the generated code doesn't follow it. I run tasks in parallel, and sometimes I let a change through that drifts from the plan without noticing.
As an old-school software engineer, I don't let it vibe. I define the architecture first. I draw the services, write how they talk to each other, and write down the decisions as ADRs before the agents start. For a few weeks the code follows it, and then it drifts when a feature is added. Every session makes its own small choices. Proposals I approved when I was tired pile up. A helper ends up in the wrong place, a convention gets skipped, a boundary gets crossed because it was the fastest way to get a test green.
The code still works, and that's the annoying part. Nothing really breaks, it just slowly stops being what I designed, and I lose the understanding. And no one else is checking, because the only person who could is me, and I'm in 3 other terminals and the Notion where all the architecture and plans live.
The agents don't always push back
One day I found a regex in the codebase that had no reason to be there. I traced it back, and an agent had added it just to make a test pass. The test was green, the feature was wrong, and nobody noticed.
Another time it was my fault. One of my decisions was outdated and it caused a bug in a new feature. The agent didn't come back to me and say "hey, this decision doesn't work anymore". It just bent the code around my decision until the tests passed, and it turned into a much bigger architectural problem than the bug itself. A good engineer would have come to my desk. The agent just did what I said.
Why the old way doesn't fit anymore
So I started researching. I looked back at TDD, DDD, Scrum, Agile, SDD, C4, and other methodologies. They are good and I still use them. But think about who they were designed for. They were made for a team of 5 to 10 engineers who write the code themselves, talk to each other, and review each other's work.
Coding agents have only really been around for about 3 years. Now it's one engineer with a bunch of agents. The people who used to own each module and say "my part works" are not there anymore, and we haven't found a way of working for that.
Writing everything myself works, but I can't ship on time like that, and I'm not going back. Staying where I am doesn't work either. We need a development experience that fits this new world.
What I'm building
My day is not in an editor anymore, and maybe soon not in a terminal with coding agents either. It's defining the system, answering questions, and keeping the architecture, the docs, and the actual code in sync. So for the last few months I've been putting together a mental model for that. I call it Holon-Driven Development. A holon is a part that is also a whole. The product splits into parts, each part splits again, down to the smallest piece of work, and every level is something I can look at and reason about on its own.
I'm not inventing anything new here. It's built on top of things that already work: C4 for the levels of a system, TDD and spec-driven development for the checks, ADRs for the decisions. I just put them together for a world where one person works with a lot of agents.
What I want out of it is pretty simple:
- I can see my whole system as one map and zoom from the product down to a single function, without reading every line.
- Every part is a holon with its own status, so I always know if it's being planned, built or running.
- I can run a coding agent on any holon and spin sessions on its children, so many parts get built in parallel.
- Each holon holds its own context (Tech docs / ADRs) and feeds the agent exactly that, nothing more.
- Agents own the function level, I own the levels above, and my picture of the system stays alive.
- When a change crosses the hierarchy, the architecture makes it easy to detect instead of letting it hide in a diff.
- I don't have to trust an agent to push back. The hierarchy makes the system observable, so I can track what works and what doesn't, see the tests behind each holon, and organize the tickets on the same map.
- I never wake up again not knowing what's in my own folder.
If you're an engineer, a solo founder or a CTO building with agents and any of this sounds familiar, have a look at holondriven.dev. It's still early. Read it, sign it if it makes sense to you, and tell me where it's wrong. I'm building a tool on top of it next, and I'd love to build it with people who have the same problem.