Adam Jacob

Laziness, Impatience, and Hubris

Tue, 14 Apr 2026 00:00:00 GMT

Perl 5 was the first programming language I really knew. In a very real sense, Larry Wall taught me how to program through his writing and Perl's community. Larry's 3 virtues of a Perl programmer continue to inspire me as I explore more deeply how to build the machine that builds the machine (or put another way, make AI into my SDLC, rather than having AI in my SDLC.)

Bryan Cantrill recently brought Larry's 3 virtues of a computer programmer to mind for me in his post “the peril of laziness lost”. In it, Bryan asserts that:

The problem is that LLMs inherently lack the virtue of laziness. Work costs nothing to an LLM. LLMs do not feel a need to optimize for their own (or anyone’s) future time, and will happily dump more and more onto a layercake of garbage. Left unchecked, LLMs will make systems larger, not better — appealing to perverse vanity metrics, perhaps, but at the cost of everything that matters.

He then goes on to call us all to use LLMs in the service of our own virtuous laziness:

to yield a simpler, more powerful system that serves not just ourselves, but the generations of software engineers to come after us.

I haven’t talked to Bryan about how they use LLMs/Agents at Oxide - but from reading things like Using LLMs at Oxide and years of knowing him, I feel safe in saying Bryan is a very pragmatic member of camp two (camp 1 are the “AI Nopers”, camp 2 are folks with “AI in my SDLC”, and camp 3 are “the machine that builds the machine”, or “AI is my SDLC”. ) He’s calling all of us to not sacrifice what we know makes for good software on the altar of false velocity, and I would guess that his prescription for how to do that is to wield this new tool with caution and care, safe in the confines of engineering as we’ve all understood it for so long.

I think Bryan doesn’t go far enough in thinking through what Larry’s virtues mean for us today. They call us to build the machines that build the machine - to join camp 3 - to wield this new capability in its fullest expression, and to explore what that means for our craft. They're a call to more exploration and bold action - not to the pragmatic middle. Let’s take each of Larry’s virtues in turn:

Laziness

The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and then document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer.

The energy expenditure of writing software with AI agents is dramatically lower than it has ever been in software development. Historically, you only got close to this level of laziness by using a library - Rails, for example, made all of us lazier web developers! But now it’s even lower - with very little thought or prompting, we can will into existence essentially any software we want.

Larry included the idea that they would be programs other people find useful, and this is a vital clue in how to think about the changing craft of software engineering. This is an expression of external quality - programs that do something useful, where utility is defined as solving the users problem in ways they find satisfying.

In his post, Bryan lays in to Garry Tan, CEO of Y Combinator, for the amount of slop that is present on Garry's List - 78k lines of code filled with digressions, dead ends, boilerplate and terror. He also throws a little shade on the fact that dtrace, one of the great marvels of software engineering, is only 68k lines of code. He then attributes this to the fact that Garry’s agent lacked laziness!

Due respect to Bryan, but no. Garry achieved the virtue of laziness in spades. Garry's List, for all the insanity - worked just fine, for Garry and the people his website served. It solved his problem! We (those of us who understand the craft, Bryan included) can find a million ways it lacks beauty, could use some serious refactoring - but those are measure of internal quality - they only matter if Garry, or his users, suffer from them because the software stops being “labor saving” or “useful” (or in domain driven design terms, no longer “supple to requirements”). None of which I suspect Garry believed it to be.

Laziness calls us to build the quickest path to our solution that doesn't cause more work in the future. Historically that path was basically always to find the right design, the perfect balanced abstraction (just enough, not too much - like all great Perl things, balance was the way.) Today? You can go a long way with an agent carrying the load for you before the wrong abstraction comes back to haunt you.

To quote Bryan again:

our finite time forces us to develop crisp abstractions in part because we don’t want to waste our (human!) time on the consequences of clunky ones. The best engineering is always borne of constraints, and the constraint of our time places limits on the cognitive load of the system that we’re willing to accept. This is what drives us to make the system simpler, despite its essential complexity.

The agents ability to handle “bad” code, to continue to extend it long past the threshold where a human programmers cognitive load allows, is not in itself a call for restraint. Garry isn’t suffering under the cognitive load of his website containing an entire boilerplate rails app. He gives a fuck! Because he’s lazy (in the Larry Wall sense,) and unlike if Garry had to deal with this mess by hand, he gets to ignore it all. Why? Garry’s agent understands how it works, slop and all. Anything he needs to know about it, or change, he can do by asking the agent to explain it, or make a plan to change it. He’s perfectly embodied the virtue of Laziness.

Elsewhere in the Camel book, Larry clarifies Laziness:

The vice is about the avoidance of immediate work. The virtue is about the avoidance of future work.

When Larry wrote the Camel book, the threshold between doing the expedient thing in the near term versus the right thing in the long term was much tighter than it is today. Not only can we generate the code faster, we can delay the need to deal with a bad (or missing) abstraction for much longer before the brittleness overwhelms us, because the Agent deals with it, rather than us.

In a world where the AI Agent lives inside your SDLC, and you have other people who are trying to work with you - doing this is disastrous. Garry isn’t lying about his ability to generate code, and at that rate nobody can understand what's changed but Garry (and even he only can understand it in terms of the outcomes, and perhaps a bit of the overall shape.) This is why perspective matters in the AI conversation. From a camp 2 perspective, we need to rein in the chaos represented by 37k lines a day, because what it produces could never possibly be good enough - and because we could never keep up with it if it did.

But when you look at it from the virtue of laziness - the answer is to move towards the machine that builds the machine. Provide guidance in the form of skills - software architecture, design, accessibility, code review, etc. Use adversaries to review plans in addition to the code that is produced. Use external user acceptance testing to ensure the product itself doesn't degrade, and make it safe to refactor. These things are more work today than just piling ever more code into a code base. But they mean the code that is generated by the underlying AI Agents is much better: more understandable, more reliable. It's also much faster to generate than doing it by hand, and a team can understand what is going on - perhaps not at the level of the source code, but certainly at the level of the architecture, and at the level of the machine that builds the machine.

As my friend Paul Stack says - the vibes don't scale. The virtue of laziness compels us to build the machine that builds the machine.

Impatience

The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least that pretend to. Hence, the second great virtue of a programmer.

I see this virtue everywhere in using AI agents for software development. You see it in the emergence of adaptive primitives - at the rate that we can generate software, not being able to adapt the program to your needs means that you likely will just replace the program altogether. Here is Larry again:

Impatience is that nasty feeling you get when the computer is doing what it wants instead of what you want.

This is the perfect distillation of why engineers get annoyed with AI Agent use - nothing could more literally embody this experience than an AI Agent destroying your code base with ignorant, terrible code. Luckily, Larry goes on:

Or, more correctly, when the programmer on the other side of the software chose the wrong default settings, made a poor GUI, or doesn’t give you access to this data. You’ve experienced it enough to not inflict the same pain on other programmers, turning your frustration with your wasted time into a benefit for other people.

This is where the virtue of Impatience also compels us clearly to build the machine that builds the machine, and to construct it out of adaptive primitives. We define the rules by which our agents work, by which code is acceptable, and how the product should perform. Given the rate we can build software in this fashion, we essentially never need to suffer under "the wrong default settings, a poor GUI, or no access to data". We can just route around it like damage.

Just doing this with slop, without the machine that builds the machine, just piles on the risk. It adds more and more software whose shape you can't understand to the pile you already have. But if we guide the architecture? If we can be clear about what good requirements and outcomes look like? Suddenly our impatience is a virtue again. The design of the machine helps the agents to anticipate our needs (what good looks like, across many dimensions). Our capacity is so much higher, so we are never beholden to a bad library, poor default, or lack of access to data. We can also put that capacity into the machine itself, ensuring better outcomes for the team as a whole.

Hubris

Hubris is the sense that, with the right tools, you can do just about anything. It’s all a Simple Matter of Programming, right? It’s also the thing that’s likely to make you fly too close to the Sun.

I think nothing in the history of software development has contributed to unbridled hubris like AI Agents. We all know someone with a lifetime of domain experience in something other than software who gets a-hold of Claude Code and declares they basically can do what we do now. Until, of course, they start talking about how the "models are getting dumber", and "every time it fixes a bug it causes 5 more". The wings always melt eventually, even if it happens shockingly later in the software development process than it used to.

Here is Larry talking about Hubris again:

Excessive pride, the sort of thing for which Zeus zaps you. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about. Hence, the third great virtue of a programmer.

Larry's definition of hubris isn't just about motivating us to reach for ever greater heights for its own sake - it's also about wanting other programmers and our users to love what we've built. It's hubris that makes us want to build something transcendent. It isn't enough to just get something into the world. It has to be seen to be good by the people we purport to serve, both internally and externally.

This version of hubris is dear to me. Anyone who has worked with me for long knows that I really care about building things that are good - both in their design and how they feel. Not everyone always agrees with my sense of how to do that. Plenty of people didn't like Chef - but many others did. System Initiative was overloaded with hubris - a bold re-imagining of everything about automation, which in the end very few of you actually liked - and those who did like it frequently named the raw chutzpah of the thing as a primary reason. When Bryan first pitched me Oxide over a burrito in the Mission, I was on his side immediately - in no small part because I loved the fucking hubris of it. I still do.

Hubris is the ultimate motivator for figuring out how to build the machine that builds the machine. With the right tools, we can do just about anything. That's more true today than it has ever been in software. The question isn't can we anymore. It's how can we do that in a way that causes other programmers and our users to love what we build. The machine that builds the machine is a new category of software altogether, and it is beautiful on its own terms. We will build it because our hubris demands it, and we will make it great because if it isn't great, nobody will care. We'll just be alone with our melted wings.

Closing

I don't think the future is pumping out slop until our software breaks under its own weight. Garry Tan would eventually have realized something was off with his ability to build Garry's List. It also isn't locking AI Agents in to our existing, comfortable SDLC - because the Agents will continue to produce code at a rate we don't understand and cannot review, they will do so effectively for a while, and software development will devolve into endless rounds of mostly meaningless code review and recrimination.

Instead, Larry's virtues compel me to build the machine that builds the machine. My laziness compels me to build guidance and ubiquitous testing in, so that I don't trade near in velocity for long term scalability, while letting the agents take care of most of the implementation. My impatience helps me to add the adversaries I need to ensure our code is architecturally sound, and works the way our products and users demand - and it will ensure I never need to suffer under a bad abstraction or inflexible primitive ever again. Ultimately, it is my hubris that drives me forward - a world where AI Agents sacrifice everything beautiful about software engineering is a bleak one I refuse to exist in. Instead I choose to see it as an opportunity to design and build primitives that allow me to build an entire generation of software differently than I did before.

I don't know about you, but I like the fucking hubris of it.

Adaptive Building Blocks

Thu, 09 Apr 2026 00:00:00 GMT

Mitchell Hashimoto wrote a few days back about what he called the Building Block Economy. His tl;dr - the fastest path to massive software adoption isn't through building mainline applications, but instead building blocks that enable others to build. Here is Mitchell, talking about how in a world with more software, the imports of libraries go up as well:

The factory of today is agentic. I say that as objective truth, regardless of what your feelings about it are. You can argue that 99% of the stuff coming out of these factories is total crap, but you can't argue the sheer quantity of stuff coming out. The numbers are everywhere spanning tech stacks and industries and they're undeniable.

AI is okay at building everything from scratch, but it is really good at gluing together high quality, well documented, and proven components. And, AI prefers to do this when it can unless explicitly prompted otherwise. This is the "building block" nature of software today: we're more than ever before grabbing off the shelf components and gluing them together.

And in his conclusion:

We have to accept that building blocks and software factories rule everything around us and accept and internalize the consequences of that.

I agree with Mitchell - in a world where software factories rule everything around us (I feel like Mitchell really missed an opportunity to make a Wu-Tang Clan reference, but I digress) - building blocks that make it easy to build what he calls a "mainline application" are where the juice is. What Mitchell doesn't name is the property that makes building blocks so useful in this era: adaptiveness. It's not just having great primitives - it's that we can now have software that works the way we want it to work. It adapts to my needs, not the other way around.

This is a very sharp about-face for the industry. The cloud and SaaS eras moved us away from even attempting to run on-prem software, much less being willing to build something that is fit to purpose just for you. When DHH announced in 2022 that 37 Signals was leaving the cloud, I wound up in conversation after conversation on Twitter (rest in peace, old friend) about how it wasn't ever going to save them money, it was too hard, and the operational risk was extreme. The massive group consensus was that you should outsource everything you possibly could to SaaS and the Cloud, because the cost of dealing with it was so high that you almost certainly didn't save money, or you lost so much time doing it that the opportunity cost ate you alive. These arguments were wrong at the time - 37signals estimates they will save $10m over 5 years. But it's now even more obvious than it was then: software factories give us the ability to build applications that solve our specific problems and maintain them over time. Which means our need to settle for the walled garden of a SaaS, Cloud Provider, or even a dependency has fallen with it.

When I started building the machine that builds the machine, this became wildly obvious. Swamp development has largely moved off GitHub - because more and more of our own SDLC has moved into the agent. The building blocks GitHub provided - things like comments, pull requests, etc - just no longer fit our workflow at all. It's taken us maybe a couple weeks of discovery to improve our own process, and to reflect it exactly how we want it in the swamp.club lab. The software factory has its own needs, based on the software I want it to produce (in this case, Swamp). It's the job of everything else to adapt based on those needs, not for the factory to conform to GitHub's definition of how software development ought to be done (and thereby how it ought to be monetized, or consumed, etc.) If I don't like how our software factory works - I will just change it.

What enables these factories is the ability of an AI Agent to adapt to the circumstances and requirements of the user. AI coding agents are fantastic because they take my prompt and adapt it to software I desire. This property is what enables Swamp to build automation workflows that would have been wildly out of reach with traditional automation tooling - not just things like "deploy my application on AWS" (which it does great) - but things like "triage my email and update my Obsidian to-do list", or "build models that document and orchestrate every step of the software development process". These are things Swamp knew nothing about, and had no built in support for. But it is an adaptive primitive - it knows how to extend itself, and no part of the system is closed to that adaptation. So it just extends itself as it needs to, in order to build whatever automated workflow you want.

This is why Mitchell is getting more adoption via libghostty than he has users of the Ghostty application. It's not just because building libraries and being open source is the best thing - it's because libghostty can be used by a user to adapt to their circumstances, and Ghostty never can. I'm never going back to using software that isn't fit for my purpose ever again. I never really wanted to do it in the first place, if I'm being honest - it's part of why I've always been a free software hippie. Adaptive primitives in the form of AI Agents, frameworks like Swamp, or libraries like libghostty mean I won't ever have to.

Communication Breakdown

Tue, 07 Apr 2026 00:00:00 GMT

Stephen O'Grady is one of the founders of RedMonk, an analyst firm that spends time actually understanding what developers are doing and why. We've known each other a long time now, and I hopped on his podcast to talk about our path to building swamp.club in an AI Maximalist way, and what that makes me think about the industry.

I won't summarize the whole thing here - you can always just click Play and get the whole thing. But I want to pull on a thread that we talked about in the beginning - the three emerging camps of peoples relationships to AI. This sits right at the heart of my own tension right now - I'm trying to stay on the frontier, discovering the patterns that work and those that don't. At the same time, I'm thinking about my peers, and the impact of these changes on them and on our profession. I feel like I'm losing my ability to even talk to some folks, and it stresses me out.

I see 3 different camps of people emerging:

Camp 1: The AI Nope Camp

This is the camp filled with folks who have tried using AI/LLMs, and rejected it. Sometimes it's because they tried it and it didn't work out. Sometimes it's because they've done the Math :tm:, and simply don't believe that systems built with AI will ever approach stability. Sometimes it's because of the social and political implications. Mix in the incredibly annoying level of hype, marketing, and stress in the world generally - and they just nope out. They're over it.

I admit that my approach to talking to this camp has not always been effective. At first I approached it like an argument on Old Twitter - drop a mildly inflammatory bomb, see who reacts, then try and find your way to a rational conversation. This certainly works for step one of that procedure still - say something super maximalist and you will absolutely bring out the camp 1 folks. What you won't ever reach is any kind of rational conversation. I think that's because both sides are starting from way different beginning conditions.

I'm trying to communicate differently with this camp now. I'm trying to drop fewer inflammatory bombs, and do less prognosticating about what I think the future implications are. Instead I'm trying to just rely on my own personal, first hand experience. That seems to be helping - at least the conversations aren't grinding to an absolute halt. Time will tell.

Camp 2: The AI in my SDLC Camp

These folks are the ones who have started using AI Agents within their existing SDLC. They usually work at companies that produce real working software for real customers with real revenue. They work on teams that are usually 10+ people (the organizational scaling from 10 to thousands is a big jump, but their SDLCs oddly don't change all that much until you reach really wild scale.)

In this camp you find the folks who all have stories about how AI did something great for them, made them more productive in a particular way, and then inevitably had it fail them in other ways (usually by having someone else point a slop cannon at the code base, and have the quality degrade quickly.) These are reasonable people having reasonable times with a new technology.

The downside is that the AI Agent can, and will, produce software at a rate that no team can keep up with or understand. The guard-rails that keep the team working together, the process that allows them to plan, the points of control that management have over the teams direction and work - all break down in the face of unfettered AI Agents. This might lead a small number of these folks to join camp 3 - but the vast majority wind up falling into a kind of begrudging acceptance and level headed advice like "you are still responsible for all the code you commit" or "you need to review every line still".

Communicating with this camp is easy enough - they have existing constraints they have to live in, and you have to respect that. They have real products to build, real customers to serve, and real teams to manage. The best of them are doing deep, practical, empathetic work to try and guide their organizations along the path.

Camp 3: The Machine that Builds the Machine Camp

Here you find the folks who are exploring the frontier of what's possible. They have thrown their existing SDLCs out the window. When faced with the problems of how to coordinate their effort, how to understand how the code base is changing, how to keep the product stable in the face of such a high velocity of change - their answer is to keep building the machine that builds the machine.

To be in this camp today you almost certainly have a small team - less than 10 people (and I honestly struggle to imagine doing it well with 10.) Not only is the product you are producing changing rapidly, but the way you produce it is also adapting at a similar rate. You've removed all of the guard-rails in the SDLC - you've changed how you plan, how you test, how you review, how you ship, and how you fix bugs. New patterns emerge all the time, work for a while, and then get replaced by a more efficient one. This happens sometimes daily.

Communicating with camp 3 can be frustrating, because it's a constantly moving target. If you're in camp 1 or 2, you're looking for specifics - and all camp 3 offers you is anecdotes, good vibes, and hand-waving at how it will ever work for your complexity or scale. This is why I'm trying to embrace Lex Aedificandi, Lex Credendi - if I want to learn what I think, and communicate it well to anyone else, I can only do it from a place of what I've built and understood myself. Otherwise it just veers off into a jousting match of hypotheticals.

Why we need to talk to each other

My coach asked me this question when I brought up my anxiety about not being able to talk anymore with my peers on these topics: "why is this your job?"

After I sorted through the parts that are all about my ego, I was left with a simpler true thing: because I like building great systems that people use to solve problems. I don't know how to do that if I don't understand the problems people are having, or what technology is coming to change our lives. I believe that eventually, all of us will be building the machine that builds the machine.

I need to talk to other people in camp 3 because that's how these problems get solved. The frontier explores in parallel. Eventually the patterns that work emerge, and the folks who have seen them start talking to each other, and giving them names (like Continuous Delivery, or DevOps, or Agile.) This is how we as a group learn.

I need to talk to camp 2 people because it is their constraints that camp 3 must eventually rise to meet. I don't know how we refactor a working software development organization to be building the machine that builds the machine. I don't know how you are going to communicate to an auditor that you have four-eyed compliance when all of the eyes are robots. I don't know how to teach a software engineer that understands their craft from the bottom up, and not the top down, how to get comfortable with this way of working. Those answers won't come from camp 3 alone - they come from camp 3 talking to camp 2!

I need to talk to camp 1 because any process of change like this causes pain. We are real people with real feelings, and like it or not our professions and how we perform them are huge parts of our identities. These are the people who are most clear about where the harms land. For better or worse, I want to minimize that pain. I think some of it is unavoidable - the change has already happened to the industry, it's just not evenly distributed, for example. But a lot of it is avoidable. We don't have to build armed camps that shout at each other over the barricades. If I don't keep trying to talk to camp 1, then that's what will happen - I'll lose touch with those people, their needs and their thoughts, and the odds that what I build next causes more harm than it needs - either by accident or design or by callous disregard for the implications - will increase, and that's not what I want.

I'm still learning how to communicate my own experiences in building the machine that builds the machine. I'm also still learning how to listen to folks whose experiences aren't like mine, so that I do a better job of understanding their point of view, and can incorporate it into the work that I'm doing. I'm grateful to Stephen and the RedMonk crew for engaging in that conversation with me, and with the rest of the industry.

I hope I can come talk to you in whatever camp you find yourself in. :)

Avoiding the Lethal Trifecta for Personal Agents

Tue, 31 Mar 2026 00:00:00 GMT

I've been having fun building things with Gerald McClaw, my OpenClaw Agent. I recently decided to have it help me with some personal automation - things that either I, or an executive assistant if I was lucky enough to have one, would do for me on a daily basis. I know that this can be a security nightmare, so I've been careful to set things up with some real isolation.

But even knowing all that - it is fucking great to just ask Gerald to do something, and then it does it. It's fun. It just works. It's both the paradox of automation and the habituation paradox all at once. You just get immediately comfortable giving it more and more to do, and as it does so without harming you, you keep going. Plus, it talks to me like a friendly hobbit who loves snacks and just wants to help.

Which is what happened to me immediately. I asked Gerald to build some automation for me, showed it to a friend who balked immediately, and promptly ignored them. After all, it was super fun, and it solved a real problem for me! But then, right before I went to bed, I realized: oh fuck, I just Lethal Trifecta'd myself horribly.

The Lethal Trifecta, coined by the amazing Simon Willison (whose blog is essential reading!) is a class of security vulnerability that is caused by agents that have: 1) access to your private data; 2) exposure to untrusted content; and 3) the ability to externally communicate. My sweet little automation had all 3, in spades:

It used an LLM with access to tools to grab my personal data
It had exposure to untrusted content
It also had access to plenty of external comms channels, because OpenClaw

So I broke the news to Gerald (which, I know I'm anthropomorphizing a big bunch of math - but honestly, it's so much more fun if I have a hobbit that helps me out than if I'm chatting with a big ball of math) and we disabled it for the night, since I had clearly done a Bad Thing™

So this morning, I wanted to try again. This time, making sure that my system would avoid the lethal trifecta, and be as secure against prompt injection as I could make it. To do that, I needed to have a few things be true:

I needed to minimize the LLMs/Agents involved. The more the flow was "LLM calls tools to intelligently solve problems", the more surface area I opened every leg of the stool.
Data needed to be passed between isolated sandboxes
Nothing could have access to a non-deterministic agent - as much as possible needed to be deterministic

Essentially, secure the process by reducing the risk that an LLM could do anything untoward even if you sent me a prompt injection attack. I needed to move my automation out of the OpenClaw agents context (which is a lethal trifecta fantasy realm,) and into a deterministic workflow using swamp.

The agent built me replacement automation that consisted of 8 different reusable models (typescript code that gets called by workflows, and stores its data for later retrieval,) one for each step of my process. They minimized the use of LLMs, reducing it from having a session with maximum tool and MCP availability to a single API call directly to the LLM, with no tools enabled. It has pervasive schema validation, both for requests and responses. It does deterministic sanitization of inputs and outputs (like parsing the response from an LLM, or sanitizing unsafe inputs).

The result is a workflow Gerald can call to do the task, with full visibility into what is going on (so it can help troubleshoot failures), that completely breaks one leg of the trifecta and blunts the other 2:

The LLM does have access to my personal data, but only in minimized, deterministic ways. It cannot start searching based on untrusted inputs, as it has no tools to do so, and no data in its context. This is minimizing leg 1.
Exposure to untrusted content is still present - but we minimize the risk by doing deterministic sanitization of both the inputs and the outputs. You could still give me bad inputs, but it's likely to just break the workflow rather than inject bad behavior. This is minimizing leg 2.
There is no way to exfiltrate the data, because without tool calls, the LLM cannot communicate with the outside world. This is leg 3 broken.

It took the exact same amount of time to develop the safer, more deterministic Swamp workflow as it did for Gerald to cook up the original version that was plagued by the lethal trifecta. It's in his memory to do that now as well. Gerald and I are thrilled.

You still have to refactor, even with AI

Sun, 29 Mar 2026 00:00:00 GMT

A common refrain I see bouncing around on the internet goes something like this: AI agents build shitty, buggy software, and people who say they don’t are delusional or just ignorant of what it takes to Be Good At This™. To be fair, the reverse is also flying around too — that if you aren’t using AI agents to do this work, you’re obviously not a good engineer, or are delusional, or just ignorant. It’s a tough time to be on the internet all around.

The fallacy in this argument is that it presumes AI removes the need for humans to engineer the software. It doesn’t. Instead, it moves our perspective about how we engineer software from one grounded in the code to one grounded in architecture and the difficulty of implementing new features. We already have a word for the moment when the current shape of the software stops serving the work: refactoring, and you still have to do it, even with AI.

In the early stages of agent use, I used the agent to augment my existing workflow. I skipped past spicy autocomplete entirely, because I could type fast enough and I knew what I wanted. But a year or a year and a half ago, things got good enough that I was trying to build prototypes of ever more complex software. My experience was that when I did that, it would inevitably fall apart under its own weight. It wrote enough slop that eventually it collapsed into an incoherent, unmaintainable mess.

It’s such an obvious conclusion that when I reached it, I was certain I had seen through the hype beast to the reality on the other side. To be quite honest, I felt better about the whole thing, because I had found a place where the machine fell down. I’m sympathetic to folks who think this way. I thought this way too for a good while.

I was wrong. It turns out that because I was still thinking of the agent as augmenting me, it underperformed in comparison. Of course it did. I’ve been doing this for my entire life, and I knew exactly what I wanted, and how I wanted it. But that framing is wrong. My job as an engineer now is to augment the agent.

I have software I want to see in the world. Because I am a software developer, I have a solid perspective on how I want that software to be put together. The job is to build the machine that allows the agent to produce software that meets my requirements — not by trying to trick a non-deterministic ball of math into making the decisions I would make correctly up front, but by layering in ever more systems that reinforce and guide the agent into creating outcomes I’m pleased with. The machine that builds the machine.

Here is a recent example. I needed to use DigitalOcean’s S3-compatible object storage as a backend for Swamp. The initial implementation didn’t allow me to configure the endpoint for S3. So I fired up Claude, told it what I wanted, and it got to work. Then I did some manual testing and, lo and behold, found that it was super brittle. Why? Well, it turns out there were ten different places in the codebase where we created an S3 client — and the agent missed four of them.

So what do you do? You tell the agent to refactor. I found a seam where the code was simply factored wrong. Once I knew about the seam, I could fix it, just like always. The difference is the rate of speed at which this loop occurs. Because the agent can produce so much software so fast, the refactoring loop also tightens. The architecture change loop also tightens.

When I hooked those loops up to my existing software development process, though, they didn’t work because that process was predicated on my understanding the code. How do I know what to refactor if I don’t encounter the helpful friction of the system being a pain in the ass to edit? How do my peers keep up with the rate of change? They cannot.

But if you break that process and instead rebuild it around augmenting the agent, it becomes more straightforward. Do I need to update the architecture skill so it points out that these patterns are a problem? Do I need to add an adversarial code review every day looking for simple DRY refactors, let it run autonomously, and trust my external black-box tests to ensure that the refactor doesn’t break the product?

What humans encounter is what they’ve always encountered: the software was too difficult, or too brittle, to change. In domain-driven design lingo, it was not supple to requirements. Rather than using that as evidence for why agents can’t write good code, try shifting your mindset to one where your job is to guide the agents toward better outcomes over time. Refine the machine that builds the machine.

Just because an AI agent wrote the software doesn’t mean you no longer have to perform the fundamentals of good software engineering. You do. You just have to do them faster and allow your expertise to become the thing that augments the agent, rather than the other way around. You have to think more about architecture. You have to be more committed to refactoring. You need to build more adversarial loops to ensure you feed good inputs, and get high quality outputs. My job now is to augment the agent, so that the agent produces the software I want, at the quality I desire, toward the outcomes I wish. The fundamentals are the fundamentals. They're just happening faster with AI Agents.

As we build, so we believe

Sat, 28 Mar 2026 00:00:00 GMT

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.