Cameron Barre: why specs alone aren't enough

00:00Oren Toledano, Swimm CEO

Hi Cameron.

00:02Cameron Barre

Hey Oren, how's it going?

00:03Oren Toledano, Swimm CEO

Welcome to the Swimm Podcast, Cameron Barry. nice to meet you and nice to have you here. we're going to talk about all kind of aspects related to AI for development. but I want to know first your background story. I will ask you through, you know, what brought us here. And in our prep discussion you told me a lot about information systems. You've been thinking about them for a while and why why the decay? Long before AI coding was a thing, right? And so my question is what kept you, you know, back to that problem? What is the the origin story of Cameron?

00:47Cameron Barre

Yeah, thanks for having me. And as far as ori origin story goes, you know, I'm just a working engineer. been working in the industry since around 2013 and I have to work to survive, it turns out. And when you have to work, you got to work at different companies. And as you work at different companies, you find out that every company you go to has a different way of doing things. And depending on how they choose to go about that, it really has an influence on how successful their projects are or how likely they are to fail.

And as someone who wants to stand out professionally, I've always been well, I developed this mindset of like how can I mitigate execution risk on projects that I'm responsible for? And I think if you follow that thread long enough in software, you realize that the design of systems really does have an outsized influence on how much execution risk there is in any given initiative. And so that's just the thread that I always come back to is how can I make sure that I'm successful or my team is successful or whoever is responsible for getting this thing done that also has to live for many, many years, right?

how can we be How can we make sure this is a success and we don't have to rewrite it in 5 years and you know, we can always understand how it works and things like that.

02:05Oren Toledano, Swimm CEO

Makes a lot of sense. So, back to the AI story, right? When AI coding tools started becoming a thing, becoming real, what did you see happening that most people you think were missing?

02:20Cameron Barre

Well, so I've been I've kind of been messing around with this sort of modern of AI since around like GPT-2, like before ChatGPT was even a thing. You had to go into the playground and mess with it there. and I was kind of building prototypes and stuff and just over the years it became very clear to me that the way that they work is has a lot to do with all of the code that they've seen in their training data and they've been trained on all of the code on the internet and all of that code is very reflective of how coding works in industry and there's a lot of variance in that.

And so, I just noticed, I think the classic thing that everyone's noticing right now is like, oh, I can put I can get something stood up really fast, but after a couple weeks I can't really progress any further with it cuz there's so much variance day-to-day in how the coding agent chooses to actually build what you're asking that eventually it all kind of falls apart and that's where we arrive at this kind of slop designation and I just realized that because of the thread I've been following in my career, the answer is like uniformity.

So, if we can get these things to behave in a uniform way, then there's no reason we shouldn't be able to keep keep on the paved road and keep moving fast and I think that currently a lot of people are missing that just because they're catching up on how to even think about the technology.

03:44Oren Toledano, Swimm CEO

Okay, we'll get there to the uniformity aspect. I think that's the most interesting part of the discussion. before you you just explained how, you know, models were trained on a lot of existing code and you told me in in the call we had previously that AI accelerates bad habits, right? If you're the foundation is wrong. can you give me a concrete example of what that actually looks like, you know, when the model does something that is, you know, fund fundamentally wrong?

04:16Cameron Barre

Yeah, so it doesn't seem like this is going to change anytime soon. These things are really good at pattern matching. And they pattern match on the environment that they're in. And so if you build code bases that use lots of complicated object-oriented design patterns or you use code bases that have hundreds and hundreds of relational database tables and every time you make a change you have to do dangerous schema migrations and maybe you have a system that's been around for a long time and has certain hotspots in the code that have really bad patterns, but everyone's moved to like new better ones over here, but even that changes over time.

It really gives a pattern matching tool nothing to latch onto and everything to sort of like have to average in between and kind of it it waters down the effectiveness of how these tools work because there's no uniform and coherent way to do things.

And so what that looks like is really just an if if you have a problem, like you don't like something about your legacy code base, just imagine that problem times 10 as you're trying to move fast and do the work of multiple people and do a lot of work in one day that you could, you know, weeks' worth of work, but you're piling up these pull requests that everyone has to look at that's full of code that you have to inspect not because you want to make sure that the product and whatnot works right, but you're trying to figure out like is it applying like the right architecture here? I don't like the way it's doing that.

Just so just concretely, it just tends to magnify and replicate existing bad habits. and that that's what I'm trying to avoid basically.

06:03Oren Toledano, Swimm CEO

Sure. so I think like over time and definitely in the past, I would say 6 months, there is a lot of discussion about structuring the work, right? And making it like not only a vibe coding experience, but something you can bring to production. And there there is a lot of discussion around spec you know, you know, driven development and most engineers now thinks the better specs, the more detailed instructions, better prompts will solve that. So but I understand from you that you don't fully buy that direction. Can you explain why?

06:39Cameron Barre

Yeah. I think spec driven development is great. Better prompting is great. All of these things are great because they're one side of a two-sided coin. Unfortunately, they're not the side of the coin it's the side of the coin that you can live without. and the reason is I think it's it's pretty easy to sum up in we've heard stories about people's production databases getting dropped by some coding agent.

And I have no doubt that they gave that coding agent instructions not to do anything destructive against the production database, but instructions aren't enough to actually structurally limit software like these agents that that make decisions based on probabilities and statistical outcomes. And so without something to really constrain them, they'll do anything, even if you've given them good instructions or good specs. And it gets worse over time because there's variance over time.

And so if you have a system that lives for 5, 10 years, the way even if your spec is good and coherent, the way that things actually play out in the code is going to keep changing. And that's why specs and spectrum development aren't enough to solve this problem. They're they're part of the solution to a bigger problem, but they're not enough to give uniformity to the underlying architecture of long-time horizon projects.

08:07Oren Toledano, Swimm CEO

Okay, so we're we're going to get to what you build and and how it it you know, you think it solves the the part of the problem or most of the problem and but and we when we talk to talked about that you need a bottom for decision-making space and you know, can you tell more about that and what does a drift look like without it? You know, we've talked about giving specs, how the code evolves with the specs, but eventually this drift happens. so can you give more color why it's happening and

08:45Cameron Barre

Yeah, so when I use the term bottom or floor, it's to imply something that you can't go beneath the floor easily, right? It's it's difficult if you're standing unless you have a shovel or a jackhammer or something or an excavator like you're the floor is the floor. So, what you have there is what you have. And how that relates to decision-making space is kind of like I've already mentioned how human teams of programmers at different companies have so much variance in how they choose what good looks like for software architecture, it's the same kind of thing for AI because it's been trained on all of that.

And so, it has no it has no way to keep itself on a consistent path because it has no taste of its own. It has no life experience of it its own. It does not solve problems in the way that we solve problems and learn from them. So, you really have to give it just a constrained kind of grammar to work with. and when you do that, that prevents all of that kind of architectural drift. It doesn't prevent product and domain level drift. That's actually where the specs come back into play. Now, if you've prevented drift at your architectural level, you have more leeway to work with specs to prevent drift at your product and domain level.

10:06Oren Toledano, Swimm CEO

So, in a way the floor is ensuring the code quality when the spec is ensuring the product quality. Anyway.

10:17Cameron Barre

In a way, it's a it's a little higher level than that in the sense that the floor creates a space that limits the blast radius of code quality in the small, like individual function bodies and things like that. It constrains the sort of connective tissue of how the entire application is put together. And then that way some of the code quality issues are someone else's problem for another day they cuz they exist kind of in the small and they don't build up big enough to cause real problems in a system like this.

10:49Oren Toledano, Swimm CEO

Okay, now coming to something that you've built called Grain to address this. So, for our audience, what is it in the simplest possible terms? Because I know you're very smart person and what we're trying to address here is a complex problem. And many people are trying to address it at different levels. so, please give us the the elevator pitch.

11:14Cameron Barre

Okay. so, Grain is essentially a domain-specific language for building event-sourced information systems. It's a DSL. It's a DSL that you hand to any competent coding harness plus model combination. And it can work with that DSL as a tool, and because the DSL's grammar is constrained, the only valid approach for building information systems with it is the tool you've given it. And because it's at the code level, it actually operates as a constrained bottom of floor to the decision-making space.

So, it allows you to produce correct information systems, and correct is subjective, like I've said, so this is our ideological approach to how information systems can be structured. Grain is a system of ideas that if anyone was curious about, they could go and look at, and they could decide, "How do I How do I do this for myself to make sure my company can build software that we're confident in."

12:14Oren Toledano, Swimm CEO

So, if I understand correctly, it's a set of primitives and, you know, to to constrain the code, right? To like organize it, uniform it. how did you get to select this, you know, specific primitives, and what did you have to cut? take us to this, you know, you know, process, and what guided you to to make what decisions?

12:43Cameron Barre

Sure. ultimately, I'm a pragmatist, so one of the cool things about Grain is that I really haven't invented possibly any of the ideas that are in it. I believe that all of the ideas that are required to make AI software production reliable have already existed for possibly more than 20 years. The industry has just been catching up for a while. And since about 2021, through co-founding some other startups that no longer exist and working at some other companies, we I found a very smart person by the name of Adam Demetrius, who came up with this product design methodology called event modeling.

And event modeling has a constrained set of primitives that you can express any of information system with. And it's really a tool designed to bring engineers and non-technical people to the table so we can all speak one language. it's kind of an alternative to domain driven design where no one's ever going to read like a thousand page book on domain driven design, but you can teach someone event modeling in an afternoon and then it serves as a blueprint for your information system that you can return to as you do change management and whatnot. So there's a select set of primitives. and I just made Grain the executable version of that.

So I'm kind of standing on the shoulders of event modeling because I've seen it turn around companies' abilities to actually understand when projects were going to be done and velocity and all sorts of things and I said, I'm just going to make an executable version of that. So therefore Grain's grammar is the same set of primitives as event modeling. It can express any information system. And that's how it works basically. That's how I arrived at the primitives. And so that gives me the confidence that I'm standing on the shoulders of someone very intelligent in their methodology.

And then I see it work in how Grain systems are built and architected. And then you also get the added benefit of any Grain system can be visualized as an event model, any event model can be turned into a Grain system. It's just really interesting. And I was already on this track before AI. It just happened to be like, oh this makes sense. Like this actually makes sense. I can use this. I can work with this in my client work and stuff like that.

14:50Oren Toledano, Swimm CEO

Yeah. Okay, so taking that from the theory that you just explained to the execution, right? You're you're actually delivering services and and work. you told me you were working now. I was building an a $10 million company completely on Grain, right? You're using Grain. So what what does it mean? What does it look like day-to-day, right? Work with Grain versus how it was before?

15:17Cameron Barre

Yeah. so how it was before is a classic tale of there was a development team that built this enterprise application for a company that has a pretty complex finance domain with a lot of like essential problem complexity that has to be managed. Those people are no longer around. they have a developer who's newer in the ecosystem and it's difficult like AI is useful to make changes in an application, but it's difficult to do a lot of work cuz it's difficult to understand the implications of those changes.

And it's built on a mutable database paradigm, so it's easy to you could run into situations where you accidentally corrupt your production data and stuff when you're working with AI. Our build process, however, is myself and this developer. We sit together for 3 hours a day cuz I'm also mentoring her on systems engineering principles and how to work with grain. And we do the work of a team of probably three to five people every day and we do multiple days worth of work and weeks worth of work per day.

This project, I think, would have taken a whole team of people at least a year in the past and it probably would have failed cuz like rebuilds are one of the riskiest and most expensive things that you can really engage in as a company, especially a small company. And so what we're doing is we're building a system that is tolerant to change over time because it's an immutable database paradigm. AI slots into it perfectly because the code base, as it matures, becomes more and more self-descriptive and declarative, so it like really hones the AI harnesses in on the correct way to do things.

And then it also leads to automated debugging and verification cycles and the ability to figure out any state that your user got into, how they got into that state. And that's just a benefit of event sourcing. But it's essentially preparing them with a system that is cohesive and coherent and simple in the if anyone hasn't seen Simple Made Easy by Rich Hickey, simple means that you you go into a problem space and you take it apart and then you put all the pieces back together in a way that you choose so that you're fighting the incidental complexity so that you can have more leverage to manage your problem complexity.

And so the system has the quality of being simple, which makes it easier for any competent harness and model to work with at any stage of the process now and in the future after it goes live.

17:39Oren Toledano, Swimm CEO

Yeah, so that's that's something interesting I wanted to like double click on cuz a lot of engineering managers now are struggling on you know complex code bases, you know, send the AI to work with and come back a bit sad about the results. So when you pawn point AI at the code base built this way with grain, what's different about what comes back? So how would you describe that?

18:06Cameron Barre

Yeah, so grain as a tool is very self-descriptive and declarative. That makes applications built with grain very self-descriptive and declarative. And because all of the primitives each have one job and they do it well and it creates these isolated boundaries that cause the code to compose together rather than being like complected together like braided together. And so when you point an AI even weaker models, we've been experimenting with like we went from using Opus 4.8 daily to now we're using Claude code together with Sonnet 5 and it's performing great.

We pointed Haiku 5 the other day at a pretty complex part of the domain and asked it to tell us how it worked and it came back really great. And so what I'm noticing is that with because of how the properties of the grain approach, we're actually able to start like figuring out where we can descend the model size ladder. And because harnesses and their capabilities have decoupled kind of from model capabilities, so the harnesses are getting really good and they can control smaller models a lot better, too.

We're actually able to descend the ladder on the most firepower we actually need to work in the domain because we want very little novelty day-to-day in information systems work. The more novelty in the process, the more things can go wrong over in a system that lives for 5, 10 years, whatever. So, the fact that we can start applying less powerful models means that something must be working well about the harnesses ability with the model to understand how the system is built, understand the implications of making changes.

And then also, there's the added benefit of event sourcing as a paradigm, it's just more tolerant in the long run to unreliable sort of changing specifications and requirement underneath.

20:03Oren Toledano, Swimm CEO

Okay, you're a very dedicated person, so you didn't mention the cost aspect, but for, you know, when you're lowering the the the novelty of the model, you also pay less, which is definitely something that more and more enterprises are becoming aware of, you know, the token price. so, I think it's super interesting. You You You also are a very opinionated person and you said to me that you personally refuse to take accountability when a project hasn't been built this way. What do you mean by that?

20:38Cameron Barre

Yeah, so, you know, it goes back to what I was saying in the beginning. I'm a professional and I'm trying to stand out in a professional environment, and so, I find it to be I find it the idea of generating all this code and delivering it to someone, whether it's at a company or whether it's for a customer, and then when something goes wrong, not being able to look under the hood and understand exactly how it's constructed, I find that to violate all of my principles as a software engineer who takes it upon myself to mitigate execution risk.

And so, I'm only willing to take accountability for surface areas where the execution risk has been mitigated in some way. And to me, generating code without applying a uniform architecture underneath is is very un-risk-mitigated way to work. And I think it's something that the industry will start catching on to. It's just taking people time to catch up.

21:40Oren Toledano, Swimm CEO

Interesting. So, the idea behind the the podcast is to have a community of people who are, you know, dealing with software engineering with AI at scale. And most engineering managers aren't going to build their own grain, right? so, what should they actually do with this idea?

22:02Cameron Barre

Well, I would suggest they should think again. the way that we make software as a society is changing, and everyone who is involved in that process needs to understand what old habits we need to throw out and what new habits we need to adopt. And so, I would say, you know, our work Grain it's open source. we release a lot of information about it. Point your AI at it and do some research because these ideas aren't secret. They've existed for a while.

And I think if any engineering leaders were to really sit down, simmer with these, and think about them, it would give them a real foothold and foundation for actually coming up with a provable methodology to support their engineering teams going forward. And I'll be honest, like we've chosen to operate in the greenfield space and in the sort of conversion from legacy application space. And so, I'm not telling you that I have all the solutions to legacy company problems. We're kind of living in the AI-native world. And so, I think anyone who wants to get on that train would really, really benefit from going and looking into these ideas.

23:09Oren Toledano, Swimm CEO

Yeah. Okay, so we will we will put together with the description of this episode the link to your open-source project. And I think in this era, there is a lot of, you know, to learn one from the other and evolve with this. So, hope you build a strong community around that that is opinionated the same way you are. we're getting to the end of this interview. and if you there is one thing you want an engineering leader who's watching to walk away thinking after this conversation, what is it?

23:44Cameron Barre

I would say I want them to walk away thinking about how they and their team and their company could be accountable for their work and get the speed increases that come with AI technology.

23:58Oren Toledano, Swimm CEO

Right. I I I guess that's the whole the holy grail of engineering organizations these days. Cameron Barry, thank you so much for this insightful discussion. You're definitely on an interesting, you know, path to find the right balance between speed, right? disruption of how software development is being built and building the foundation and the the guardrails and, you know, the floor in the space to make the right decision while building code and building applications. So, thank you so much for this discussion and thank you for taking the time.

24:39Cameron Barre

Thanks Oren, and hope to come back one day as we continue proving out these ideas and talk about what we're learning.

24:45Oren Toledano, Swimm CEO

All right, see you soon then.

24:47Cameron Barre

Yep.