Chad Fowler - BlueYard Capital
Building Systems That Want to Be Changed
He was standing in front of his engineering team during the rebuild of Wunderlist's entire backend, setting a boundary that was physical and absolute. You may write a service in any language or framework you want, as long as it fits inside this space. Smaller than a page. One function, done cleanly.
“It has to be small. Someone wrote it in Haskell and I’m up at night on call and I don’t understand how to do Haskell, I’ll rewrite it in Go and deploy it. Fine, because it’s small enough that I can reason about it.”
Every service built under that constraint was “this sort of like soulless cog in a machine that has a soul, and the machine being the system as a whole.” The launch went out with hundreds of instances running to absorb the load. What the team did afterward was the part that still surprises him to say out loud.
“We deployed it. Then within six months, we had rewritten 66% of the system, I think, as humans. This is 13 years ago or something. That’s pretty crazy to do a big rewrite, launch it, and then literally rewrite all the software.”
Chad Fowler did not have a name for that approach at the time. He does now. And the argument he has built around it is one of the more concrete challenges to conventional software thinking currently being written down anywhere.
The Person Behind the Architecture
Chad Fowler is a General Partner at BlueYard Capital, a venture firm, with capital on the line and a full deal calendar. His CTO title sits alongside that, reflecting a core aspect of his identity: Chad is the only engineer at the firm, which means he also builds the internal tooling, uses it daily, and runs it alone. Most General Partners bring a technical background to their investing. Chad applies his to the firm’s infrastructure as well.
He’s also a musician, describing the experience as “freely improvising cathartic music on a stage playing a saxophone with a group of great musicians that listen well.” The architecture he builds shares that same quality. Small components, each doing one thing, each responsive to the signals around them. No single part dominates. The system as a whole has the identity.
He wrote a piece in 2009 for PragProg.com called “Clone Yourself,” about building repeatable processes to free up attention for harder decisions. Mid-conversation, as he reflected on that article, something clicked.
“[The article] was all about creating repeatable processes to sort of commoditize. This is almost exactly what I’m talking about with AI, but to create systems so that you can go on autopilot and get much more done. And the assertion I made there, and I mention it because I realized it while writing this, is… in my career, I don’t care about money, I don’t care about a lot of things. What I do care about is the freedom to do what I want.”
At BlueYard, the current expression of those ideas is a nameless system designed to make sense of the firm’s incoming signal. “I am building a bunch of kind of crazy AI tooling that ultimately creates a knowledge graph of attributes of people, companies, and timing.” He’s “basically the IT department for a company by myself, as well as being one of the users and partners in the firm.”
The Biggest Change I’ve Ever Seen
Before the architecture arguments, it helps to understand what Chad thinks is at stake right now.
He recently caught up with former colleagues from his time at General Electric in Louisville. Successful people, running successful companies, who have not touched AI. His read on that situation was direct.
“You might as well just throw away your career if you’re not doing it now. I don’t care what your ethical concerns are, don’t care what you’re worried about about change and your job security. You’re screwed if you don’t do this and embrace it hard right now. It is the biggest change that I’ve ever seen in technology.”
That is the temperature of the conversation that follows.
If It’s Hard, Do It Constantly
Recently, Chad has spent time outlining the Phoenix Architecture model in his writing. The intellectual foundation for Phoenix Architecture comes from Kent Beck, the creator of Extreme Programming. Beck’s principle: if something is hard, do it constantly. If code review is hard, do pair programming and eliminate the separate painful step. If testing is hard, test first. Chad extends the logic into territory Beck never mapped. “If change is hard, then make that a built-in guaranteed constant and continuous part of how a system is constructed.”
To explain what that looks like in practice, he references biology:
“You and I are human beings with something that represents a self. We have an identity. And we have constant death occurring within us currently. Cells dying and being replenished constantly. That’s not just a feature that saves us from eventually evaporating, it is actually how this system self-regulates.”
The technical architecture Chad uses to pursue this has two lanes in every system he builds:
1- A synchronous lane for data management.
2- An asynchronous messaging lane where agents can process and enrich data without coupling to the primary flow.
“If you have those two flows in pretty much any system, then you can do almost anything in a way that is easy to maintain and most importantly, easy to evolve and add functionality to.”
In the Phoenix model, what stays constant is not the code. It is the specification. “When we want to change the system, we go back to the specification. What are we building? The durable thing is the actual declaration of the system.” A component that exceeds a cost constraint baked into its spec triggers automatic regeneration in a cheaper runtime. The original framework is irrelevant. “Frameworks don’t matter anymore because frameworks are for humans and this isn’t for humans anymore.”
He also flags what he sees as the current failure mode in AI-assisted development. “Too much of a focus in AI right now is one shot because that’s where the magic tricks are. Work on it for two years and then try and change something in it. It’s not gonna work out so well.”
Deleting the SSH Keys
The moat argument starts with a reframe on a familiar metric. “The only advantage you have is speed. Time to market is crucial. Time to change is really a better way to say it. Because it’s not just like getting the one thing.”
In 2013, Chad made a decision that struck most engineers at the time as impractical. Rather than setting a policy against manually altering production servers, he argued for removing the option entirely. “We should actually literally delete the SSH keys so we cannot access the servers anymore.” This constraint forced every change through configuration management. Painful at first, and then a system with properties that a softer policy would never have produced. Containers eventually arrived and made this the de facto standard, but the principle predates them.
Today, he sees an equivalent choice forming.
"Not only is it not irresponsible for you as a human to let the agent create code and deploy it without looking at it, it is also irresponsible for you to create code yourself."
He does not leave that claim unqualified.
“We can’t go right there right now, but what are the constraints for the process we have to put in place so we can? Because that has to be the goal.”
The Context Nobody Writes Down
Chad describes a scenario that most engineers working on long-running systems will recognize. A production outage, traced after hours of investigation to a single hard-coded number. Changed at 1:12 a.m. on December 3rd, 2014. No record of why. The developer long gone. “You don’t know, and you’ll never know.”
His argument is that this failure is not a documentation problem so much as a human capacity problem. No team sustains the discipline required to capture reasoning at every level, under pressure, over years. An agent, he suggests, changes that equation.
“The agent, because it doesn’t have an ego and it doesn’t get tired, can do things like absolutely refuse to implement your software unless you tell it why. You can have rigor beyond anything you would have ever had, and you can set yourselves up for safe change in a way that otherwise would have been impossible in the past.”
The competitive implication, as Chad frames it, is that this kind of accumulated context is not something a competitor can replicate by adopting the same tooling after the fact. It has to be built from the start.
A Thousand Times Faster, A Thousand Times More Careful
Chad’s forthcoming book, “Regenerative Software,” is due from O’Reilly with early access planned around June 2026. One thread he pulls on in the conversation is the coordination problem forming around programming language defaults. Left unguided, large language models default to Python and TypeScript because of training data volume.
“We end up with the lowest common denominator technologies winning forever because now it’s an endless cycle of more code being put out, training the models, Python becomes even more of a default, and ultimately it’s the only programming language that exists in the world.”
The closing frame he returns to is the one that sits at the center of everything he describes.
“How could we have a thousand times the rigor that we used to have, but also go a thousand times faster? I think they both have to go together.”
That is the design challenge he is working on in his firm’s tooling, in his writing, and in the architecture philosophy he has been developing across his career. What happens next depends on whether engineering teams treat those two demands as a contradiction, or as a starting point.
More from Uncovered Media
 | A guest post by
|