# Phoenix Architecture: Regenerative Software Strategy

**Podcast:** The AI Native Dev - from Copilot today to AI Native Software Development tomorrow
**Published:** 2026-03-24

## Transcript

The code that we have is a liability and the system is the asset that we're building.
Phoenix architecture takes the same exact idea, but it says ideally what you should have is some sort of a specification for the system.
And then the code you should think about is just an implementation detail or a build artifact.
And the reason it's called Phoenix architecture is like the metaphor of the Phoenix that's destroyed and rebuilt and rises from the ashes.
But the entire architecture is about constantly replacing every piece of the system, but not replacing the system as a whole.
The goal here is to be able to deploy code in production that was generated by AI of some sort that humans never reviewed.
We know that's what's going to happen because we know human behavior and it's way too easy to do that now.
So people are always going to do the easy things.
So let's figure out systems that make the easy thing okay to do.
You have a statement that said evaluations are the real code base.
How do you think about durability?
What is it that as I build IP or as I build up anything?
persists across?
That's a good question.
Back in November, we hosted the first ever in-person AI Native DevCon in New York.
This June 1st and 2nd, we're bringing it to London.
It's two days built for AI Native developers and engineering teams.
One day full of hands-on workshops and one day full of practical talks on agent skills, context engineering, agent orchestration and enablement platforms, and how teams are actually shipping AI in production.
Join us at the brewery in London near the Barbican for all of that, plus networking, parties, giveaways, and a room full of people building the future of AI native development.
You can also join us from anywhere in the world via the live stream.
As you're listening to this podcast, you get 30% off your ticket with code POD30.
Just head to AInativeDevCon.io and we'll see you in London.
Hello, everyone.
Thanks for tuning back into the AI Native Dev.
Today, we are going to go, I don't know if it's far into the future, but definitely looking into the future or the concepts of it with Chad Fowler, who is a VC today, but don't hold it against him.
He's today at Blue Yard Capital, but he really has this rich technical background on it.
Some of you might know him as the person leading Ruby Central at the time when Ruby was all the rage, what feels like.
feels like a while ago.
Very innovative.
I think you were a CTO at Wunderkinder.
I'm not sure how to call that, which you sold to Microsoft.
And you were CTO for a variety of departments and sort of areas for Microsoft then.
And generally, I think a fairly well-known thought leader in the space.
And specifically, for this podcast, what...
pulled you in is that you've been writing some really interesting blog posts and like little storylines and perspectives on the future of software development and where that is headed in the Phoenix Architecture blog, which is inconveniently posted on aicoding.liflet.pub.
Every time I have to like find that, but it really, really good blog, really, really good ideas, which we will talk about today.
So Chad, thanks for coming onto the show here and sharing some perspectives.
Yeah, thanks for having me.
It's a totally exciting time to be talking about software development.
So I want to do as much of it as I can.
Yeah, I fully agree with it.
Unsettling, interesting, cerebral, fast-moving, a lot of this excitement, and never boring, super interesting.
So I guess before we, so we're going to talk a lot about the Phoenix architecture and I want to maybe like dedicate some specific focus on, on what you mean by this.
But maybe for starters, I know there was a bit of like a origin for all of these things thinking and you were, you were sort of thinking about code is disposable and these types of views for a while now.
So can I, for starters, just have you tell us a little bit the origin story of how did you come to this line of thinking and how that came about?
Yeah, I guess, you know, it started with, um, in the, the early 2000s, somehow I ended up in this line of consulting and full-time jobs where my, my job was to euthanize an existing software system.
So come find some system that's like doing good work, but can't keep up with the demands, like the technical demands or the business demands, um, uh, posed to it.
And so I'd come along and kill the systems.
And I started getting really tired of that because I was thinking about like, what about my own systems that I create?
Like think about how much time and effort and emotion I put into my work.
How can we build systems that can outlive us?
Like why are we building all these systems that are dying within like five years?
It's insane.
And so I started thinking a lot about legacy and what that word means and also just like biological metaphors for software development because...
I thought, well, I don't take very great care of myself as a human, but I'm still here.
How is that possible?
We spend all this money on software systems and they still sort of get corrupted and die and fail under their own weight.
And so...
A couple of sort of key insights came to me, one of which I didn't really act on much over the years.
The first one is just about infrastructure.
And I started thinking about, you know, how we in the like 90s, we would be excited about uptime for a given server.
You know, we install these massive big sun servers or whatever.
And I remember one that had been up for like two years without being rebooted.
terrifying but back then we were we were proud of it yeah and i realized that like if you want to be able to change things you need to do it all the time and so you know this sort of behavior whether it be an infrastructure or software would lead to situations where you just couldn't progress the system because you're not practicing change so the first insight that i had in this sort of legacy thing is let's just kill things over and over and over so that we can be used to killing and i started with infrastructure And now it's just like old hat, the idea of immutable infrastructure, but like never, ever modify a server, always replace it, which of course you couldn't do with physical hardware, but you can do with containers and, you know, EC2 instances is what we were doing back then.
Right.
But not just even for the purpose of, uh, of.
kind of learning and the agility, but also to, to know that you can do it, to really truly know that you're able to recover from a saver failure is to do it all the time intentionally.
Right.
Right.
And why is that?
Why, like, why is that the rule?
It's because if you cannot change the system, it means you don't actually understand the system.
So, you know, if you're changing it constantly, you understand what the requirements are.
Just, you have to, right?
So the same should be true in software, but.
It was much more expensive, you know, 15 years ago or so to just throw away code all the time.
But I was thinking a lot about like, what would it mean to have disposable software, immutable code?
So as soon as you write like one unit of work, whatever that is, you'd never modify it again.
You just throw it away because the unit of code itself is small enough.
and bounded enough that you can understand what it's supposed to do trivially, and therefore you can safely replace it.
So this is the sort of backstory that when you pit it against where we are in terms of LLM-generated code, it starts to click, and you say, oh, okay.
And we can go into that in more detail later, but that's sort of the origin story of this thinking.
I love that, and I love the analogy to immutable infrastructure because I think so many DevOps analogies are helpful, at least.
to me or to people that have kind of been through the DevOps change to be able to kind of apply those to AI and try and forecast where it's headed.
You know, the fact that servers are statistical creatures, right?
And they don't always behave the way we want them.
And so we need to deal with a world in which it's not deterministic and to move those.
So I love the immutable software to, or rather immutable infrastructure.
concept and applying that to immutable software and think, okay, what have we learned about immutable infrastructure that we need to now kind of represent here?
Right.
Yeah, there's also, like, as you were talking, I was thinking, there's also this thing back in the day, like, when I talked about how proud I was of my two-year uptime on a server, I also knew that server's name, and I knew its IP address, and I, like, set it up myself physically.
I cared about it.
You know what I mean?
Yeah.
So I was, like, attached to this thing.
And when you get to immutable infrastructure, you can never be attached to like one running instance of your software stack.
I think the same sort of lesson applies to code too, that we have all developed, especially developers, this almost fetish-like worship of our code, forgetting that the code is not actually the thing we're trying to build.
It's just the implementation of the thing we're trying to build.
Yeah, yeah, no, I love that.
That's, you know, in DevOps is the whole ethos of cattle versus pets, right?
You have the ones that are nurturing as pets, which is what you're describing.
And it is a really interesting thought to say, how do you think of code as cattle?
And, you know, you just have plenty of it and you keep swapping it, which was just not feasible before.
Just like immutable infrastructure was not really feasible or practical, I guess, except for very unique circumstances before the cloud enabled it.
Yeah.
So, I mean, how would you make it feasible?
Even back then, you know, as I said, I was like starting to think about this.
The first rule when I was working on Wunderlist was you can do code in any language you want as long as it's no more than this big.
And so, you know, I would literally say this.
So it just means...
Just trying for a small amount.
Yeah.
Roughly like it fits on a page of your editor.
So if you have really good eyes, you can have more code because the font can be smaller.
But we actually did this, and we did this sort of radical microservices architecture.
And there were at least a couple of cases where code was disposable because of this.
We had consistent calling conventions, and we had a way of dealing with mutations offline.
We had a way of dealing with REST and CRUD sort of stuff through the system.
And it was all consistent.
And all the code was tiny, which meant we were able to replace things.
So the two versions of this, one, I had written a service in Haskell, and I was one of only two people who would tolerate even looking at Haskell.
I loved it.
The write-only code.
Yeah, well, yeah.
In fact, in this case, that was the problem.
So we had to change this code so infrequently that the build system became stale underneath it.
And after we were acquired, we could not recompile the code anymore.
It still worked.
It was great.
But the tool chain had broken underneath us.
We didn't have that rigor of constantly changing it.
So there was a problem with it at one point.
And someone just said, well, we're just going to rewrite this in Go or something.
So they rewrote it in an afternoon and deployed it.
It was fine.
And the other thing was we had deployed a major release of Wunderlist, which was like the crown achievement of what we did technically.
literally hundreds of server instances running these heavy Ruby on Rails servers because that's what we knew was like the consistent choice.
But then afterward, over the course of like three months, we replaced something like 70% of the code base with Clojure, Go, Rust, et cetera, and made it feel like, I don't know, I think it costs like 25% of what it did at launch to run because we were able to replace all these systems that were running Ruby.
because they were all just tiny little things with consistent calling conventions and easy to plug in.
That was our first attempts at doing this sort of disposable code thing.
I love that.
And I think some of the kind of clear modularity goes all the way back to sort of Java design partner design patterns, you know, just thinking about, you know, abstract, you know, factories of factories and kind of a creation of those that at least from a dynamism of the software and the ability to hot load different components will come in.
And I guess we still think of the code itself oftentimes as the thing that is precious, even if we modularized it within the system.
And I guess, you know, this is AI land or AI era now.
And so clearly that is now changing.
So maybe tell us a little bit about the Phoenix architecture.
I love in general, a lot of the storytelling you have on the blog, but some of these.
visual analogies are helpful and fun.
So you talk about Phoenix architecture, you talk about regenerative software.
So what's the, I mean, you've already alluded to some of it, but tell us a bit about what's the philosophy behind that.
Sure.
Yeah.
So, you know, if you think about what I was just saying about consistent calling conventions and generally conventions for like what the interfaces would be, you know, how you think about.
CRUD operations on data.
And this doesn't just apply, of course, to CRUD-based REST apps, but these are all ways of constraining a system so that you understand how the components interact with each other so that the components could then be potentially implemented in any language or framework or whatever.
You still have the idea of how the system works.
And one thing I used to always say to the team at Wunderlist is, The code that we have is a liability, and the system is the asset that we're building.
And the Phoenix architecture takes this and sort of codifies it.
And I also have a not-yet-released but eventually open-source project called Phoenix, which is like the actual implementation of all this stuff I'm talking about.
But it codifies it, and it says...
any software in the system you should think about like it's a build artifact so you know imagine you have a make file or and file or or whatever the dependency oriented build system thing as you know there's always some um sort of top level asset that you start with Usually it's code in a high-level language, and you run a thing, and it understands the path, and it can compile all the way through.
It can invalidate any object code that's changed, if you're talking about a truly compiled system or a VM-type system like JVM.
And it can replace just the paths that need to be changed.
But the top-level asset that you're building in that case is the Java code or the C code or the Rust code.
With Phoenix architecture, takes the same exact idea, but it says ideally what you should have is some sort of a specification for the system.
And then the code you should think about as just an implementation detail or a build artifact.
And the reason it's called Phoenix architecture is that, you know, these, like the metaphor of the Phoenix that's destroyed and rebuilt and, you know, rises from the ashes.
But the entire architecture is about constantly replacing every piece of the system, but not replacing the system as a whole.
because you need that sort of consistent shape and calling convention for interacting with the system generatively.
And so, yeah, that's sort of the key thing of if we want to be able to change systems safely and rapidly, and we want that to be how we interact with our systems, they're just like very change friendly, then...
I take a lesson actually from extreme programming, Kent Beck, all those people in the early agile days.
If something's hard, just do it all the time.
So if testing is hard, then do it all the time.
If code review is hard or expensive, then just do it all the time by doing pair programming.
The idea here is if change is hard, then just build it into the system so you have no choice but to constantly change.
And you can also never actually look at the code.
And I guess I should sort of back up and say the goal here is to be able to deploy code in production that was generated by AI of some sort that humans never reviewed.
And this would have sounded more crazy six months ago.
Now a lot of people are doing this.
But at scale in big enterprise systems or very complex older systems, of course, you can't do this yet.
So if that is the goal, and why would that be the goal?
Because that's what's going to happen.
We know that's what's going to happen.
Not because like we're looking at the future and we're looking at technology trends, but because we know human behavior and it's way too easy to do that now.
So people are always going to do the easy things.
So let's figure out systems that make the easy thing.
Okay to do.
Yeah.
I think it's also the opportunity.
It's not just that it will happen.
It's also, uh, uh, the, uh, the means of staying competitive is to be able to tap into that and to take the human out of the equation.
But I, you know, so as someone has been saying, you know, code is.
going to become disposable a couple of years ago and, you know, kind of was dismissed as heresy not that long ago, you know, like sort of two years ago.
Today doesn't feel as far-fetched.
But let me ask about a few challenges kind of within that world.
So I think the most blatant one is what is sufficient detail in the spec and at what point does that sufficient detail just become a different piece of code?
uh that that you've written and all you've done now is like create some sort of template that's at the top how would you define the the right level of specificity uh in the spec and and which parts you're happy to delegate to the to the implementer uh that is the agent that's a good question and the answer changes weekly kind of you know like i mean since you've been talking about this for at least two years It means probably four years ago you were messing around with code generation and the frustration loop constantly.
Like, oh my God, it's magic, and then it's not magic anymore.
Fails, you know.
And I think the last time I felt that way was like September or October with the tools available, and now I don't feel that way anymore.
I know it doesn't sound like I'm answering the question, but the reason I'm saying this is there's a whole lot more you can one-shot with very little detail these days.
However, Like forgetting about the fact that it just keeps getting smarter and smarter.
I think the answer for me is that I want to iterate until I see the thing change.
So I'm working on a new IRC network, for example, a reboot of IRC right now.
I didn't one-shot it.
I've got all sorts of interesting technical things in it.
It's called Freak, by the way.
And when I worked on it, I didn't create a spec that had a great level of specificity.
But I iterated until I had a spec that was enough.
And I knew it was enough because I see the evidence in the software.
So it's kind of like you go back to the early 2000s.
We had this thing called naked objects in Java where you just generate Java objects and it creates the UI for you on the fly.
And the whole idea was a new agile way of working with customers and software where you just pop things open and show that to them and iterate like that.
sitting with the customer instead of like going on these long project things right interact with the data model yeah yeah and i think it's the same sort of thing now where you can iterate and iterate the problem this creates though is if you want a system that can survive change over time you can't just regenerate the entire thing constantly yeah yeah so you need to be able to iterate but you need to have some way of being very clear about which things are changing so like there are two issues one um If a user knows how to use an application and it changes every day because you've changed the spec and regenerated it and reimagined an entire UI, that's not okay.
Even if the UI is great, even if it's better tomorrow than it was today, users have to actually understand how to use this.
And the other is you just don't want things that are core to the technical foundation of your system to change constantly because they might be wrong.
And that's where...
this level of specificity matters a lot where one intuition like so an example of this is i'm building this irc network so i've got irc server that implements the protocol and then i've got protocol layers on top and another layer and then i've got clients you know and client sdks at the very bottom level i want to get that right quickly and just set it in stone and probably never change it unless there's a mistake or we want to upgrade the irc protocol right And so the best way to do that would be if there were some set of specifications that we iterate on that we can literally tie through some like build graph back or to the code that gets generated.
And it never has to change unless the dependency tree changes before it.
So we can change the protocol all we want in the beginning.
And then we sort of lock it because we never change even the like vague specs we created that happened to create a thing that was good enough.
This sounds pretty scary, I know.
And then you just, you know, you work in the layer that makes sense to do a lot of change.
There's a term, I remember the person's name who coined it, a term called pace layers that sort of codifies this idea of different speeds of change, layers of a software architecture.
Yeah.
I think so.
So I've done a fair bit of thinking of this and in the TESOL framework that we've since kind of parked as we focus on TESOL and context management, and we can get a little bit into the delta there.
We had a lot of the settlements and we talked precisely about that in that you will create a spec and the spec can be at whatever level of resolution you reach.
software that you bless by using it and looking at it and sort of deciding that it is good enough.
And then from here, you have the question of stable, what you want to achieve is stable regeneration.
So, you know, when you regenerate it, you want stability, you might have a button, you might not care what color it is, and you're happy to delegate that to the...
to the agent but you don't want to change in colors uh every every version and so you want some stability over there uh and so you want that and the the challenge of course is figuring out what are the aspects that you want to um stabilize because because increasingly like those those change like maybe you want the button to be the same color unless it has a good reason to change because you've just changed all of the themes colors and so the button should also change in that process and we actually introduced use the word lock you know we we had in the system tests for uh for the different uh parts of the spec and we you could lock a test to imply it and so so it is very interesting And I think probably a bit of an unsolved and an interesting interaction model as well of if you were to create these different things, let's say your information architecture allowed that, what is the user interaction that you would have with these assets?
And maybe I'll throw one more, which is I think there's also an element of who made the decision that is more important.
If I said something, me, the human in control, who is paying the bills and whose neck is on the line, That should be, you know, more holy than if the agent has made a decision and that decision should be more easily overwritten because it was just making it at the time.
So there's a lot to sort of figure out.
I don't know if you're, are you, would you anticipate like new programming?
This is like a frequent question, you know, that I get as well.
It's like, would you anticipate these things?
manifesting in new programming language paradigms or are these just patterns that will eventually be applied by the agents?
They will manifest in programming languages, but I think that's also a step along the way to where it goes.
Because I think what we're going to find is like any programming language we create is going to be trying to solve problems that LLMs can't currently solve with plain language.
and then they'll become obsolete.
My first assumption when I started doing stuff with ChatGPT, early ChatGPT days was, oh, we should be using Haskell or OWL and RSS, like ontologies.
I had all these ideas about static typing being better and blah, blah, blah.
It just all doesn't matter, actually.
But I think what we need instead is different programming paradigms and patterns that aren't languages.
So, you know, my work right now on my implementation of this Phoenix architecture is focused on going from raw human specs to refined clauses in my system where you can like canonicalized actual intents out and then you can do hash-based tracking of these intents all the way through, like cryptographic hashes.
which gives you that build system thing, but it also gives the ability to add provenance because I absolutely agree, like capturing intents of the system and capturing who made them and like when and why are really critical, both in like knowing what to regenerate and also in just like figuring out how you would remove things from a system.
To me, that's the biggest problem because we're generating things at such speed.
You're going to end up creating absolute masses of garbage.
And if the agents did it and not the person, you know it's probably okay to delete.
There's a lot of other factors you have to check.
But on my IRC system, Freak, I actually have two parallel web apps by accident.
I have a really nice one that I've been iterating with and then one that the agents just decided they were going to make.
And it's linked some places, so I have to remove it.
But at least I know in this case that I made this decision.
But I think what's really interesting is the combination of what we were just talking about with specs, et cetera, and then capturing the human interaction with the LLM as the code is being built.
There's a bunch of work going on here of doing this.
And to me, that's the important thing is how do we figure out how to map from intent all the way through to object of code, whatever that means, implementation unit, in as clear and replaceable a unit as possible, then we have the ability to do this regenerative software thing.
For real.
I think super interesting.
And I guess my thesis also would be that there are actually sort of three layers of human condoning, you know, or like blessing.
There's the explicit instruction that came from the human developer.
There's the explicit review.
I actually read this and said, yes, which is a bit tricky because did you really read it?
I don't know.
You know, like you technically it says, is this OK?
Should I go?
And you said yes.
And then there's the, you know, no human interaction.
The agents just decided those.
Uh, and, uh, yeah, we had a lot of those.
We, by the way, refer to them as shadow specs.
Um, there's the spec in the shadow spec, uh, which, uh, show the decisions you never made, but have been made for you.
Uh, yeah, that's a good term.
I like it.
And I like, I must admit most of the work that I do, I've got mostly shadow specs with like really high level, stupid instructions these days.
And I go YOLO, you know, so my review, my explicit review, I did not read it.
I scanned through it.
Like, yeah, that sounds right.
Yeah.
And there's, again, There's kind of these two levels.
I don't know how to sort of name them.
There's sort of levels of shadow, like, you know, the shadow and the dark spec.
I don't know.
But, you know, the ones that you, in theory, reviewed and the decisions that were never presented to you, they were just made.
And you could have proactively gone and reviewed, but you didn't bless.
Like asking about programming languages reminds me of a conversation I had earlier this week with a real language innovator.
I won't say who it is because I didn't ask if I could, but we were talking about.
Specifically, as I take all these stupid ideas I have and I try to make them into real code, then I can create projects with.
One of the first things that I ran into was, you know, I keep saying like consistent calling conventions and ways of dealing with mutations in the system asynchronously.
There's some sort of message bus thing.
Like there's sort of these things I have in my head for what you need for a Phoenix type architecture to work.
And the immediate thing that I run up against when I started generating this is, oh, I actually have to choose like what language and framework.
Let's say I'm going to build a web app.
Like what MVC framework is it going to be in?
What programming language?
What runtime?
And I reached the conclusion that I should just decide this for the entire system for any code that's generated.
So like we can start with web apps.
I'll just decide, like, okay, what's the best framework for generating, for generated code for a web app and AI today?
I think there are two answers to it.
One is whatever the LLM knows.
So probably like two years old Next.js or something, you know, React.
Not things I like.
It makes me sort of ill to say this.
Yeah, but it's whatever it is that has this sort of the sweetheart of the weights at the moment.
Exactly.
Which tends to sort of persist historical popularity.
Yes.
Well, now it's really going to lock in forever because we're going to keep regenerating.
Everything is getting duplicated and it feeds itself.
But what really matters now is, you know, like I was all into Ruby and Rails and evangelism and all this stuff back in the day, you know, as you mentioned, I would not do that today.
I would not tie myself to such a thing because what matters is the code has to be able to be correct.
It has to be as cheap as possible to run.
It has to perform as well as it can.
It does not have to be human friendly.
It doesn't have to be trendy.
It doesn't even have to have unit tests.
You don't have to do TDD.
Yeah.
So what I realized is this Phoenix architecture, I don't think you will decide when you use it what the framework is or the language that it generates.
You shouldn't.
That should also be a thing that's completely open to change.
So what we'll be compiling to is more system architectures, a shape of the system that allows us to have pluggable, replaceable components because of the shape of the system, because of the calling conventions and the consistency and probably some sort of like type system.
There will be these sort of properties, but they won't be about the programming language.
They'll be about how this thing runs and how the components interact.
Yeah.
I think so.
So that's that's a good kind of tee up for a challenge that I have in my mind.
So clearly, I've been on this of the spec centric software bandwagon for a while, like literally have been sort of devoting kind of my time in TESOL to pursuing this vision.
And like probably the most significant way in which I feel like my thinking has.
I want to say evolved or at least changed, you know, maybe it's regressed over time, is the move from more of thinking about a spec and some data format definition in which you properly capture your intent and the definition to wanting to get the agent to just make good decisions.
And I feel like when you work with humans and with people on your team, the best developers that you have on the team, or even yourself and your future self on it, it's not so much that you expect them to truly represent these definitions of your software, right?
Or sort of, you know, the historical decisions that you've made and that need to bless and all that, but rather that you expect them to combine intelligence and information, you know, to combine, you know, just like smart decision-making and kind of conclusion drawing with the right context, you know, using a term that I think is good for humans and agents.
to put the emphasis in the right spots.
They should know how much you care about finance and budgets versus how much you care about speed and latency, how much you care about functional programming versus how much you care about Ruby, how much you care about security versus just sort of all of these different preferences.
And even your you know, your kind of business surroundings.
So it's sort of an understanding of your constraint.
And sometimes those constraints may include it has to be written in this language, right?
Maybe if you are building within Microsoft and, you know, someone condoneses, well, this has to run on Windows.
That's a constraint and that limits some of your options.
So I don't know, like I really love and still expect a representation.
of these things to to manifest but i wonder where is it that we even if we're thinking ahead we're not thinking sufficiently ahead and we still like the idea of a data model that can represent robustness right or some some semblance of determinism when really it's more about making good decisions yeah i mean i guess like just um a random thought from what you were talking about is I think instead of specs, we need to be thinking about building knowledge graphs.
That sounds like a little bit probably too inflated, but knowledge graphs of all of these things, whether it be the values and variance and intents of the person.
The beautiful thing with L&Ms is they can actually get, they can mine this stuff from you very easily.
I feel like you're missing this, which is sort of how I did it with the tests I've been doing with Phoenix architecture so far.
invariants are part of the system and like metrics of success are part of the system and you're right that there's like a you know I don't know deploy target or build target or whatever like clearly there's still a Windows app sometimes and there's still a Mac app sometimes the way I'm thinking about it is there's probably just like a set of patterns that I'll say I create for myself with this Phoenix thing but there's you know everyone's gonna have their own probably center of gravity of ways of doing this that they adhere to but for mine it would be a set of patterns that apply to uh native mac os apps native ios apps for now web apps you know um tui apps for consoles or whatever server-based things uh and and even you know like distributed systems so that i have an architecture that i compile into which can include things like platform You know, most of the cases, for me, I'll be pretty agnostic about platform and language, but then you could have different constraints that you add to the system.
Yeah, very hand-wavy abstract stuff because we're not there yet, you know.
I mean, the other thing was like we're talking about apps that manifest, but maybe there's just a data substrate and apps manifest on the fly, you know.
It could be visual or it could be LLMs, whatever, conversation.
yeah there's probably still an efficiency element there so i really like like i did i also like i don't want to challenge i feel either way we need these data structures uh for it and and there's you know i think another lesson learned a little bit is that you can't be too far you know too far out into the future you have to think a little bit about it and so i think the phoenix architecture is is already fairly dramatically innovative and a bit of a mental switch to embrace, you know, for anybody in the current software development world.
So even if there is, even if it is a stepping stone, you know, as you think ahead, it is very likely to be a kind of necessary stepping stone.
I also really like how it enables something else that I think about, which is personalized software.
And the idea that, because I find increasingly, I don't know if you feel the same, which is I use a bunch of tools that I really like.
And I don't really have a problem with them.
I don't want to vibe code an alternative.
Even if I could, it's good.
It's good.
I don't mind paying them a little bit, you know, is what I do.
But what I increasingly get frustrated is that I can't customize them.
Like I want to add, they're not doing, they don't have this feature and I'm annoyed.
And it's almost to the level that I was like, you know what?
I'm going to write one of my own just because I want that feature.
And I guess I'm imagining a world in which you, the author.
can produce a piece of software that has some of these definitions of what is what you can muck about with and what you cannot you know what is the essence of this piece of software and it has to be embedded and what is it that you know chad if you want to sort of add a different ui a different web app you know for this maybe this is one that we do know we can do because apis and all that but you can modify it um and like have you thought about like the phoenix the phoenix architecture or whatever the I don't know how to kind of call the whole thing, but like that type of platform being an actual distributable, that this is the software that you're sending off to users?
Yeah, I think so.
Although my, it's not that I disagree, but the way I've been thinking about this is more from the data model up.
And it comes from like the local first community specifically.
Well, I think IncanSwitch wrote a good thing called malleable software about some of this.
But, you know, like in the local first community, it's all about your data is local.
It's on your device.
People write applications that interact with that data.
And then, you know, you have CRDTs, et cetera, for synchronizing this stuff.
So why wouldn't you have like a shared data model across?
And I'm sort of not answering a question you didn't ask, but imagine you had a shared data model of all the sort of common things you need to do.
And anyone could write.
software that allows you to interact with your shared data models or it could be your productivity stuff like meetings and tasks and emails and stuff.
If it's not in a cloud and it's not on some private server that you have to deploy to, but rather it's a software that you run locally, then manifesting new interfaces to these things is sort of just like an assumption because third parties, you know, maybe one company writes software that you start using, let's say linear, which is actually local first software.
Someone else could then come along very easily and write the second interface to that same stuff.
And linear can't stop you.
They wouldn't want to.
That's part of the point of doing local first software.
And maybe I'm just like an old stupid software developer that's still chasing this idea of reusability and the semantic web and everything.
But what if we could now think industry-wide or at least in pockets of consortia about doing local first as a default?
and having shared data models by default, you know, schemas, JSON schema, whatever it is, schema.org, that is, so that new vibe-coded apps just talk to this stuff, and there's an assumption that it's there.
I think this is really interesting.
The other idea of, like, constraining which parts are malleable is interesting, although I don't see why there should be a limit to which.
pieces of the software you should be able to change uh though maybe you know from an it department perspective i i do see it because you know someone calls and says my software doesn't work because i changed it that's a bad thing But part of it is not so much the constraint about what you're allowed and not allowed to change.
Like at least a portion of it is just, you know, like if you invested in Wunderlist and you created, you've spent this deep thinking about, you know, choosing the right functionality or visuals or like means of it or the things that will drive the correct kind of to-do list handling.
And so I don't want to lose that.
I just want to add this feature.
So it's more like de-risk me when I add my sort of experts to my own social network button.
didn't exist on it because you know, I wanted to extend it.
Can you, can you help me preserve, you know, Chad's brain, you know, when you, when you, when I got the software from you and just modified, I mean, like big software does this, right?
Like CRMs and all of those, you would customize your organization.
I just find it interesting to think about.
Yeah.
It is a great idea because, you know, one of the things that we all, when you start talking about regenerative software, the immediate like pushback is you can't just regenerate the whole thing.
The users won't know how to use it.
So it's true that if you could like define even paste layers within the UI, maybe like this panel and this panel or these types of panels are things that are always extensible.
It makes sense.
And you're right.
It's like a lesson from the 90s or 80s or, you know, like this has been a thing in enterprise software forever.
Usually not because they want to preserve the experience because the experience is usually not very good, but everyone needs to customize them.
Yeah.
And I love the idea of pace layers.
And to be clear, I'm a huge fan of reusability.
I think even if you get to the point in which LLMs can create and agents can create everything from scratch with very high.
reliability that is so massively inefficient, right?
I want to create a to-do app and it needs to build a kernel.
I mean, why?
Why would it do that?
And, you know, familiarity between different systems, consistency within enterprise systems, just mutual learnings, right?
When there's a bug, I don't want everybody to kind of shave and, you know, have all of these problems.
So.
Yeah.
The efficiency thing is a really interesting one.
I was talking a couple of weeks ago with, one of the founders of radical which is this open open distributed github sort of replacement um he is now working on something called radiant computer and it's like a ground-up operating system that he's building and he's thinking obviously a lot about llms and he wrote a piece uh about how you can sort of like reduce the surface area of how you interact with something let's say an operating system uh to the benefit of efficiency of llm use because part of what he's doing is like everything is private by default and you can run local models etc of course you're dealing with like local power constraints and the fact that the models aren't quite as good as the frontier models and it's it's an obvious thing to reach but somehow there's this beauty in in the the insight that if you like you start with an open playing field and then you create this constrained language that actually expresses what the system's supposed to do.
And I think this is like a version of what you're talking about.
Then it becomes a very easy thing for the LLMs to interact with it.
And you can do this over time with every system where it starts with this open field and then it becomes, you know, it congeals.
Maybe this is like what programming languages are in the future.
You asked about new programming languages.
I don't know.
There's another guy, Guy Steele, who is, I'm sure you know of him.
He's a well-known programming language researcher.
He did an amazing talk at OOPSLA in like 98, I think, called Growing a Language.
Like every generation, I reintroduce it to people because it's always relevant somehow.
But the talk starts with him defining a subset of English from scratch that he can use for the talk.
And it's all this big lesson on building up vocabulary and building up foundations.
You can then be expressive.
And maybe that's what we end up evolving toward.
Because in this agent, this like rapid change, rapid software creation environment, we should be able to create tons of reusable vocabulary like this.
And we should be able to easily differentiate between what's reusable for me, what's reusable for my organization, and what's reusable for the world.
And the ideal state is that we like figure out markets for this or ways of sharing this stuff.
Yeah, no, absolutely.
And we've gone through all of that type of thinking as well at TESL in the early days.
It's like, he created an HTML to markdown converter for me.
Sounds like a simple spec.
Which HTML do you mean?
Yeah.
Which markdown do you mean?
To be loaded in a browser.
Which browser?
And these things rot over time, right?
Like whatever, you know, if you interpreted today's...
you know, LLMs will interpret the thing from two years ago.
Well, I guess actually maybe it stays the same because it's persisting itself.
But in overtime, the definition, you know, in five years.
Hey, everyone, hope you're enjoying the episode so far.
Our team is working really hard behind the scenes to bring you the best guests so we can have the most informative conversations about agentic development, whether that's talking about the latest tools, the most efficient workflows or defining best practices.
But for whatever reason, many of you have yet to subscribe to the channel.
If you're enjoying the podcast and want us to continue to bring you the very best content, please do us a favor and hit that subscribe button.
It really does make a difference and lets us continue to improve the quality of our guests and build an even better product for you.
All right, back to the episode.
So I want to ask you, though, about another set of posts that you have there.
There's more about evaluations and durability.
And so if everything is regenerated and as we've been talking here, there's some...
That's not always ideal and there's some accumulation of learnings and preferences and distributions.
You have a statement that said evaluations are the real code base.
They are in one of these posts.
How do you think about durability?
What is it that as I build IP or as I build up anything persists across?
Yeah, so I do say this thing about evaluations, and it might be an overloaded word where it sounds like I'm talking about some modern definition of evaluations in the context of LLMs or ML, and I'm not, although I also am.
I'm really talking about invariance, metrics, constraints, all these things that we were just talking about.
Like to take a stupid example, just because it'll be easy to talk about, let's say you have...
I don't know, an order record in a database and you're just talking about like the CRUD operations for orders in an e-commerce system.
You know, there would be like correctness requirements.
Obviously, there might be side effects that you expect when an order is placed that should also happen so that you can like measure the fact that that happens.
There might be speed constraints.
There might be memory constraints or I.O.
or, you know, all these sort of like system level things.
And to me, like this set of stuff, this is kind of why I was talking about knowledge graph earlier versus specs, because I think you have to create this knowledge graph, which may be pretty inscrutable, that we probably need tools for dealing with this too.
But it captures all this intent.
It's both business intent and technical intent.
In my old naive way of doing things, which is still the way I would do it for now, I would always talk to my teams about focusing on meantime to resolution of problems versus meantime between failure, which was another way of saying, don't worry so much about testing everything up front, but let's just make sure everything is really well instrumented and we can easily roll back.
And so my way of changing software is YOLO and production.
you know, just to sort of overstate the point.
Yeah.
And then immediately respond to the live metrics and the real state of the system via intense observability at all layers, including business and technical.
I think there's probably some aspect of that still, at least for now, in a system that's going to be changing rapidly like this.
The other thing is you can create tests and you can do it both before and after the fact.
You can do it.
really rapidly with AI now.
So I think there's a thing where, and you were talking about like locked tests, I think, in your way of thinking.
Yeah, because you test, otherwise you don't know what to trust, right?
You take some spec, you create code, you create tests, they disagree.
Who's right?
Exactly, yeah.
My way of thinking about it right now is there's like at least a layer of tests that like everything is locked.
There isn't differentiation between locked and not locked.
Of course, I'm not writing tests anymore.
I'm not writing any other code.
So I'm explicitly talking to the agents about the purpose of the tests.
And the purpose of the tests is based on our current understanding of the system, like in my IRC system, for example.
I will go through runs where I have it just look for all of the possible edge cases we might not have thought of for a certain class of bugs.
And I get multiple models multiple times to do this.
And then I review it, and I have it create tests that discover bugs.
And then I have it work until the tests run all the time, and I keep this layer locked all the time.
So that's sort of like the second way I'm thinking about evaluations now.
I think probably it goes further and further when we can collectively spend more time on specs to canonicalized requirements to invariance and this sort of chain because that gives you something different to reason about in a more automated way.
But right now, I think just this sort of metrics plus tests is the way to go.
I'm a big believer in evaluations.
I think in the, like...
first year if you will of tesle i was thinking a lot about tests as the things that persist and you'll have tests you will lock tests this is the behavior of the functionality increasingly in my current world view i i think more about making good decisions and and so the tests that i want are more the tests of my agent's behavior as opposed to the test of the system that has been built uh and those are I don't know if you call it anything classic these days, right?
But those are AI evaluations of saying, hey, is the agent behaving as I am?
And I guess I perceive that to be a higher leverage point because you're making the developer that you want versus making the system that you want.
And the developer that you want is actually much more powerful than a system because they can create the system that you want at a fairly high fidelity.
And what's interesting is the same concept that you said right now is true, though.
Like there's still a element of you have to capture and aggregate what are the evaluations that are that represent what you want.
And you probably have to accumulate them.
And over time, you need to curate them, which is still like, you know, we don't know how we don't know how to deal with that yet.
You know, we have to.
But at least evaluations speak in slightly higher level terms of like when when this happens, that, you know, like the behavior.
uh the developer behaves like this but still a volume challenge uh of how many of those do you do you assess um but then once you once you get that the instructions the specs actually are malleable uh themselves because they are um they also change with the models right like the way that you would instruct haiku is different effectively is different than the way you would instruct opus um and we see already that you know opus is very creative but it's a bit of a smart ass and it doesn't follow instructions and you know codex is less creative but it is more obedient you know in that sense and you know gemini has its own traits and just each of these things is different uh and so when you when you think about these uh like again if you really continue down the same rabbit hole and you continue you you you move from programming languages to program programmer language, right?
It's the language with which you instruct the agent versus the language with which you define the system.
That's really an interesting approach.
And I feel this, like I switched from Opus to another model trying to arbitrage credits a week ago.
And I had a very frustrating day until I woke up the next morning and realized, oh, I changed the model.
That's why it feels like...
you know 2025 again uh i blamed the model i probably should blame myself and the way i interact with the model however um that actually sort of makes a point like when you said try and make the best programmer i think this is a really cool approach and it's absolutely the opposite of the way i think about it i just assume the programmers are both idiots now and going to be geniuses later and they're going to progress at different paces depending on the model and so i'm i lean toward trying to create a system of code generation maybe that's the programmer i don't know but it's not an intelligence you know but a system that allows me to plug in the most idiotic llm here and the genius here and still have some results that i feel i can i can trust but also decouples me from thinking about the models underneath they're just going to keep changing and getting better of course eventually all this stuff that we're talking about is going to be irrelevant to an obsolete because the models are just there's a different point in the future which is uh you know having kind of a a more intelligent conversation by a couple of ai models uh than what we're sort of having here but yeah and i think for its worth i think you need both because i think amidst the team you need some form of definition of the output of that you know intelligent programmer that captures the definition of your system and makes it easier for the programmer to be less intelligent or even just to capture the alignment on what the system does and making that increasingly LLM friendly so it's easy for them to understand and kind of apply and represent instructions.
And then you separately need the instructions of the developer.
And I think to me, context engineering is about that, right?
And I think we started writing and we'll probably talk more about the context development lifecycle.
And I think I think the agents will handle the software development lifecycle.
And we need developers to sit in the context development lifecycle as we develop context.
And the context really is the operator's manual.
It is about how should the agents behave and what are your intents.
It would be interesting to see the interplay there.
A friend of mine, Jess Martin, is working on something called Context Library, which is a way of automating, building up context of all of these.
these decisions that you make with the goal being kind of like what you're saying, run agents all night while you're asleep and they make decisions based on probably what you would have said because they have enough context of the system built up in a way that's usable by them.
I see a lot of that.
And then I do wonder the reason I say context development, I think it's a different view on it.
Although time will tell which one is right, which is there's this spontaneous, you know.
observe me and understand what I do.
But then what I do today is not the same as I would have done a year ago, and let alone 10 years ago.
And so like the alternate approach is context is a thing you develop.
It is not a point in time.
And we all know like at one point during the LLM kind of iterations, all the rage was learn my code base.
And then we learn like...
There's a bunch of stuff in my code base that I do not want replicated.
In fact, most of the stuff in my code base I do not want replicated because it's been accumulating garbage and garbage in, garbage out.
And so it's not that it's not useful, but you want to develop your sort of practice.
So it's interesting.
I guess maybe it's a good point to sort of try and conclude the conversation in the point of timeline.
So what is your thesis?
Like your building, put aside.
So the guide to the programmer even side.
The switch from current day software to immutable, regenerative, you know, Phoenix architecture style software.
Like, what do you think is a practical or what is your anticipation in terms of the path of adoption for software actually changing to be working like this in the industry?
I think it will be both really quick and incredibly slow.
And the slow part is the realization we need to all make that we have systems that have been in development for decades and no one understands them.
And most of us nerds out on the frontier are not thinking about them so much yet.
I think some of us are starting to.
So I think if I were to go start a company now, I would be doing the company this way today.
So, you know, Greenfield code base right now, now is the answer.
And I know some people who are doing this to varying degrees.
But I also know of development shops in, you know, fairly forward leaning companies that are barely touching AI at all.
And they're resistant.
And there's a huge portion of the developer population that's afraid or just not paying attention.
You know, just like.
when java happened they didn't want to do java they didn't want to do ruby and python you know uh and uh you know they just want to have fun and and go to work as little as they can that is the truth about most people in their jobs which is fine that's you know humans are humans but organizations are backward organizations are slow most people don't know how to deal with this and they're going to be looking at like large consulting companies to try and figure it out so i think it's a long long time before There's a mass adoption of AI-generated software up and down the stack through the largest enterprises.
But there's a lot of interesting work that should be happening probably in the coming year or two because so many of us and companies I'm talking to, from my perspective as a VC, are having these same conversations about like, trying to capture intent and what is the spec versus intent and where can intent come from.
You could mine it from corporate email systems for the last several decades.
You've got all that stuff captured.
You could mine it from source control system, project management.
So work being done to figure out the legacy intent of a legacy system so that you can then start automating maybe like strangler fig pattern, breaking pieces of an application off.
But yeah, I think it's going to be like insanely fast on one side and surprisingly slow on the other side.
Yeah, I think that's a good, it's almost always like the right answer to like any diffusion of technology.
I do, one of the things that I do feel, and maybe this is in sort of TESOL on the company building ethos side, is that one of the reasons that we've kind of focused on, on this sort of, you know, train the developer versus, you know, define the system.
in the offering, you know, there's a whole bunch of reasons.
Some of this stuff needs to, you know, be open source, needs to sort of be part of the agents.
You know, there's a variety of reasons.
But part of it is that if you train the programmer, then you're sort of simulating the human behaviors, right?
Like in these ancient systems that are so fragile, there are still humans, they're operating in there and they're making decisions.
And those decisions are, you know, by and large, these companies are still alive, right?
Like they are, they are growing, they're modifying it.
And so there's some logic.
by which they are making this work.
And so it felt like it's even though conceptually, as we talk about the it's a higher layer and it's maybe a further future to think about training the programmer versus training the there's actually in some aspects of it a more short term applicability of it because that better programmer can help you do better on the systems, even if it doesn't fix the fragility or it doesn't make those systems, you know, be able to rise up from the ashes.
Yeah, I agree.
I mean, I think, you know, it's like what I said about everything's going to be obsolete that we're talking about at some point.
I think there are waves where we will solve these problems in the way we're talking about today.
And it's totally valid and it will be useful for a long time.
But the industry is just going to go so fast.
We'll think, oh, God, what we're talking about now is silly, but it's still useful.
But it's maybe not the future anymore.
You know, the beautiful thing about today is we can go so fast.
We can deal with all these different phases.
And we can have roadmaps for our companies where we just say, OK, we'll get to that when it's a problem.
OK, now it's a problem.
Boom.
Next week, we've got a whole new release.
It's like a miraculous time to be a software developer as well as a terrifying one.
But yeah, I think we get to be steering through this crazy time.
It's really exciting.
Yeah, yeah.
Definitely sort of fasten your seat belt.
But it is an exhilarating ride.
Chad, this has been super, super fun, fascinating, future-looking, deep on it, and I think right in many ways.
So I'm really looking forward to the open source version of it and to hear more about this development.
I don't know if you want to say if people are keen to find you, to invest in their invention of the future of software development, where can they find you?
Probably Blue Sky is the best place.
I'm chadfowler.com on Blue Sky.
Sounds good.
So thanks again for coming on to the show.
Thank you.
Very fun.
Thanks everyone for tuning in and I hope you join us for the next one.