As we build, so we believe

The frontiers of using AI agents to write software are expanding at a ridiculous rate. One thing I’m learning is that, for me, the best way to deal with it is to actually start pushing the frontier forward myself. Trying to be a passive consumer of the frontier is exhausting. Nobody knows what to actually do, or what is going to work long term. The edge is adapting and building itself faster than I can understand, at least if I’m trying to understand it the way I’ve always understood previous technology transitions. The more I push myself (and the team building Swamp pushes each other), the more I know that I am deeply uncertain. So that’s the truth: the frontier is fucking wild, it’s absolutely working, and for me the only way to handle it is to start building it.

My friend Courtney Nash, during another tumultuous moment in the industry (the “DevOps Transformation” or the “Digital Transformation,” depending on where you sat at the time — but basically the moment we decided all the enterprises on earth were going to be software companies, and they all had to learn how to work at roughly the speed of internet companies), once called me the “Malcolm Gladwell of DevOps.” (I don’t think she meant it as a compliment — which, honestly, is one of my favorite kinds of friends in general.) The thing is, she wasn’t wrong — the thing I do best is synthesize things, and then try and build practical technology that makes them easier to do. If I let myself stay too long without building something practical, I run the real risk of being intellectual for its own sake — and if I’m not careful, that can turn into being convincingly vapid.

I’ve also become an Episcopalian, and as I’ve gone on that journey I encountered a saying they have: “Lex Orandi, Lex Credendi.” Roughly translated: “the law of prayer is the law of belief,” or even more roughly, “as we pray, so we believe.” (When I chatted with a Muslim friend of mine about this, she laughed at me and was like, “why would you need a saying for that?”) That saying has seeped into me, and it’s become a bit of a guidepost for me when dealing with this shift in how my work gets done. I have no idea what I actually believe about how AI will transform the industry. What I know is that if I get to work building it, I will learn what it is that I believe. They will reinforce each other. I will find my footing through walking the road and doing the work.

That’s where the Latin for this blog comes from. “Lex Aedificandi, Lex Credendi” — roughly translated (by Google, because I don’t speak Latin), “the law of building is the law of believing.” More accurately for me: “as we build, so we believe.” I’m going to build things on the frontier, and from building those things I will learn what I believe about the future of all the things I care about in my work. (For the record, that’s 80% the people who do this work with me, both directly and in the industry, and 20% that I care about the “how” of it, because I find joy and satisfaction in the craft.)

Today, that looks like the realization that the job of building a new software product is now the job of building the machine that builds the machine (or software) you want. This has always been true — building technology products is the process of building socio-technical systems that work to solve both your internal problems (how do we work together?) and the external problems (whatever the software is supposed to do for the people who use it). The existing process breaks in the face of the velocity possible once you start building a machine that builds the machine. And the more I try and map the way I built software, the way I lead teams, and the way I thought about building companies and businesses to that new velocity, the worse the new machine that builds the machine functions.

The analogy I’ve been using to try and explain it to the people who love me is that it’s like the water pressure in your house just increased by an order of magnitude (a 10x increase). If that were to happen, every single pipe in your home would probably burst. Now imagine that it was an adaptive, fast-moving increase: it started at 10x, but someone was using that increase in order to build a new system that jumps the order of magnitude again — not a 10x increase, but a 100x increase from the baseline. It’s an imperfect analogy, but I think it gets to the heart of the scary bits: everything would break.

In our small team, the first thing that broke was all our points of control. I was convinced that software architecture really mattered in creating good outcomes with AI agents, so we built a skill for doing domain-driven design in TypeScript, and we asked our agents to follow it. But I knew that when I watched Claude churn through some work, it frequently still didn’t get it right. So what did I do? I tried to make sure that all the people who were working on the codebase did the right thing when they talked to their agents. I became this insufferable micromanager, trying to make sure the people on my team knew how to look for the signs of weakness I was seeing, and correct for it. Otherwise, obviously, the entire codebase would crumble like a house of cards!

They reacted poorly. I mean, in their defense, they reacted with as much kindness and grace as one can muster, because they too are going through their own journey with how all this works, and none of us knew the answer. We had some fights before it became clear what the problem was: trying to ensure the inputs were right so that the outputs would be good. I can’t do that anymore — people’s ability to task the agents with work exceeds my ability to vet those inputs. Instead, I have to only ever look at the results, and then decide how I feel about that. For someone who prides himself on inventing things, on building great software, on leading great teams — and, if I’m honest, my own egotistical belief in my ability to be the one who was great at it — it was a crushing realization.

Here is a practical example. I wanted to refactor how the internals of Swamp worked, because I could see that we were going to need the ability to build different user experiences on top of it. Historically, work like that requires a huge amount of consensus-building. You’re going to change the way the software works, and you have to bring your team along for the ride. It also brings a bunch of risk — people are working away on that codebase. A big refactoring means they have to slow down, or at least consider slowing down, to accommodate whatever changes you are making — because if they don’t, your refactor will never be able to land. So I tried to do all those things, and what I got for my efforts was frustration. I used an agent to help me design the architecture. I evaluated 12 different shapes before I even brought it to them. Every rightful question they asked and critique they raised I had an answer for. It was, for them, an excruciating experience. They quickly got to the point of “okay man, just do it, because it sounds like you already know what you want to do.” Which frustrated me, because I was like: “this is a big deal! I’m going to change the architecture of the software! You must understand it deeply so we can all stay aligned!”

Fuck! I was absolutely doing the right thing. I’ve been leading engineering teams for a long time. I was doing the right thing! But not when the cost of the refactor is less than a day’s work to churn through 40k lines of software. Not when the cost of being wrong, assuming it worked, was also essentially zero. They already trusted me to be a good steward of the code. They already trusted that I’m a good software architect. I just needed to trust myself, and extend that same trust to them.

So we changed our system. The new rule is: everyone working on Swamp is someone whose creativity we want to see reflected back to us at 100% of its power. If you think it needs to happen, then it needs to happen. If it turns out to not be quite right, no problem. We’ll adjust, using that same creativity. If you want to talk about it up front, fabulous. If you know what to do? Go for it.

If you are still working in the socio-technical structure of the last 30+ years of software development, that rule only ends in one way: absolute and total disaster. But for us? In practice? We use that as the new constraint, and we build the machine around it. We have skills that reflect the code we want to see: architecture, design, accessibility, testing. We do adversarial review against our plans. We do adversarial code review using the same standards against the implementations. We have external, comprehensive user acceptance testing for the whole system, which defines the contracts we want to enforce on the user’s behalf, which frees us up to refactor the internals safely.

All those things suddenly make it so that, if anyone’s work gets through all those hoops, the odds we like the outcome are very high. For things like bugs, we have tools built into Swamp that send fantastic bug reports. We vet them for prompt injection, but largely we can just let the machine handle the fix without even guiding it. We can’t do that yet for things like large refactors or sweeping architecture changes. But that’s fine. The tools work great for that too — they just need more human guidance.

Every time we find a seam in how we work together, we solve it by adding more automation to our machine that builds the machine. It’s evolving so quickly that describing it to you today would be obsolete tomorrow. But it’s working. It’s fun. I feel like our team is moving out of the storming we were going through, and are starting to move from norming to performing. The technical side of the machine is too, and I’ll say a lot more (and so will my co-workers, I’m sure) about that as it starts to settle down.

So that’s my advice to you. If you’re feeling lost and annoyed by how quickly the frontier seems to be moving, adrift in a sea of meaningless hype — maybe try Lex Aedificandi, Lex Credendi as a way out. Just start building a new machine to build the machine. Let your trust and faith in your peers grow, and explore the frontier together. Let everything break, and just rebuild it together. It’s working for me.