Transcript#
This transcript was generated automatically and may contain errors.
Happy to be here. I guess it's my first time in a long time giving a talk about something that isn't about data science tools or data infrastructure, data systems, things like that. Honestly, I mean, I was an AI skeptic for the longest time and didn't engage much with these tools or systems. And, you know, suddenly coding agents burst onto the scene and I would say that I haven't really written code in about a year, or at least not meaningful code. And so that's definitely put me into a contemplative mood thinking about the future of software engineering and what role there is for people like me today who have a lot of experience building software and systems and what's going to be our role going forward.
But in general, you know, it's clear that, you know, we as developers are already writing a lot less code. I essentially don't write code anymore. I think that's going to become increasingly the norm for a large category of systems. There may still be certain specialized systems, databases, things that require deep expertise and the agents don't know a lot about where they're still going to be written by human hand. I expect that the DuckDB developers are going to continue to write code by hand for a lot of things. But a lot of classes of software aren't going to be written by people. And so that begs the question, what is left for us to do?
And the argument that I, you know, I will pose in this talk, and I don't know that I will convince you of everything that I'm going to say, mainly my goal is to provoke ideas and dialogue about these things, is that these three kind of human traits of understanding the scope of what you're building, how to design it, how to architect it, and taste what makes it good are really the most important things that are left. But I will also argue that these were also the things that mattered the most in the first place. And that coding was this annoying human labor that got in the way of actually building the things. But if you didn't have these essential ingredients, it was very difficult to build a piece of high quality production software.
And that coding was this annoying human labor that got in the way of actually building the things.
And there are many pitfalls along the way that could result in creating software that fails to ship or falls apart under the weight of its own bad decisions. And let's face it, we use a lot of software products every day that simply aren't very good. I'm going to talk about that as well and what we're going to do about it. You know, there are people in the software craftsmanship community that have a lot spicier takes than I do. I followed Uncle Bob for going on 20 years since I read his book Clean Code in the late 2000s. And he responded to Brian Armstrong's recent tweet about cutting head count as a result of AI and having non-technical people shipping production code. And he said, honestly, I don't think he knows what he's talking about. What the agents give us is the ability to disengage from deep syntax, but they do not give us the ability to disengage from modular design and architecture. You still need to be deeply technical in these topics in order to produce good quality production code.
The Mythical Man-Month and software complexity
So if you've never heard about Fred Brooks, he was at IBM and led one of the largest software projects of the 20th century, building OS360, IBM mainframes. This led him to write the Mythical Man-Month in 1975, which you say, wow, 1975 is a long time ago, 51 years. Still is enduringly one of the most cited and most influential works on software management and software engineering in history. And even today you're starting to see, you know, I wrote an essay about the Mythical Man-Month, like Martin Fowler just wrote an essay about it. It is still influencing minds and it is coming up more and more in today's context of agents carrying an increasingly large burden of the software that we're writing.
Brooks's Law, the idea that adding manpower to a late software project makes it later, it makes it later. It's one of those things that, you know, people forget and then they have to relearn the hard way. I don't know if any of you have been in a company where a pointy haired boss says, this project is behind, we need to hire engineers to make it go faster. I'm usually the person in the room who's saying, wait, wait, like, have you read the Mythical Man-Month? Like, are you sure that this is a good idea? Maybe the problem is actually that you have the wrong people working on the project, not that you need to add people.
And so this idea of the surgical team that a small team of elite people outperform large teams of average ones is also one of the reasons why startups can deliver innovations and disrupt industries in, you know, short amounts of time and run circles around their much larger and more well-equipped competitors. One of the reasons that adding people to a software project can make it go slower is because of the communication overhead, which grows quadratically with the number of people. And so, you know, a 20 person software, 20 person engineering team versus a five person engineering team, there's just a lot more overhead in, you know, delegating work, splitting up tasks, going through design, getting everybody on the same page. You need to introduce layers of management to keep people on track.
Another idea that comes from this book is the idea that the difference between a working software, you know, project and a software product that you can sell and can be maintained in production is roughly like an order of magnitude in the amount of work. And, you know, now when we have agents producing software and it's alluringly simple to sit down with Claude Code, build a brand new piece of software and say, oh, looks good, I tested it, it works, like, let's ship it. And it's kind of missing kind of that layer of work, which is described in this 9X gap that would be involved in, you know, actually running that project in production over a long period of time and all the problems that can come up along the way.
And so, you know, so a lot of these ideas are summed up in thinking about software architecture and software design is this notion of conceptual integrity. And so it's the idea that when you look at a software project, you want it to seem like it was designed by one mind. So like one kind of coherent set of ideas, even if there were many people implementing and developing it. And so if you have a project that has a bunch of disparate or like discordant ideas, then, you know, that can create a lot of problems as the project scales. And so Brooks says, you know, if the project reflects one set of design ideas, it's better than having many good but independent and uncoordinated ideas. And of course, nowadays we have agents jumping in and adding lots of independent and uncoordinated ideas to all of our software projects.
Essential vs. accidental complexity
So in the No Silver Bullet essay in 1986, Brooks introduced this idea of two kinds of software complexity, the essential complexity, which is basically what the system solves, how it needs to be designed in order to be a working solution for what you're trying to build. And that involves the conceptual integrity and having a coherent picture of like these are the essential set of features for this to be a complete system. If we take anything out, the project is no longer a solution for what we're trying to solve. And then accidental complexity is everything else that is introduced by our tools and processes and technologies that we're using to build the system. And so that involves our programming languages, our build tools, like all of our systems that do testing and QA and continuous integration, you know, the boilerplate that's involved with interacting with databases and all that fun stuff.
And so agents are tremendously powerful tools for dealing with all of this accidental complexity that comes up while you're building a software project. You can say, you know, hey, Claude, hey, Codex, you know, hey, Gemini sometimes, go and refactor, you know, all of this code, change the test framework, rewrite all of the tests. It's happy to dive in and attack and deal with all of this complexity that is introduced by, you know, the tools and systems that you're using to build the project.
And I'm encountering this firsthand myself as I've largely moved on to use other programming languages other than Python, which I will show you in more graphic detail in a little while. I've never written a line of Go professionally or a line of Swift professionally. And yet I'm, you know, in any given day, I might be slinging, you know, 5 or 10 or 20,000 lines of code in these programming languages I'm not an expert in. Like, what are the right tools and frameworks and libraries that I should be using in each language. But, you know, I do look at the code and see whether, like, is there a lot of code duplication, code smells, classic refactoring signals. And to be able to tell an agent, like, there's code duplication in this file or these tests, like, seems like this test suite could benefit from test fixtures. And to be able to work at that high level of being able to speak in the language of refactoring and clean code and to be able to go and reformulate whole parts of a software project in small amounts of time has given me, like, a tremendous sense of agency.
The downside, of course, is that when the agents are working on, you know, the essential parts of the system, they have a difficult time distinguishing between the essential complexity and the accidental complexity. And they also generate new kinds of accidental complexity in doing the work that you need them to do. And so this could take the form of, you know, creating the right, having the wrong domain model, like, the right, you know, the wrong layering of classes or, like, failing to recognize that, you know, if you're building something UI related that you have to explain to the agent, like, we're using, you know, this is the model, this is the view, this is the controller. But if you don't explain that to them and articulate, like, this is how the system should be designed, the default output in a lot of cases is just going to be a hairball that becomes, you know, increasingly difficult for the agents to refactor.
And this gets worse and worse as time goes on because fresh agent sessions come into the existing code base and they're just as happy to, you know, bolt another appendage onto the Frankenstein rather than taking a step back and saying, okay, what is this code, how should this code really be designed? You know, what types of, what are the right abstractions, like, the right layering of components to make this easy to test and maintainable, easy to refactor, easy to think about. So it's very difficult because, you know, the agents, they've been, you know, reinforcement learned and reward hacked to just want to solve the problem that you put in front of them. And so if you need, if you want them to clean up and improve the quality of the code base, generally you have to ask them to do that explicitly. They won't just do it on their own.
Another closely related idea to this that I, you know, I have to mention is Conway's law, the idea that the software projects resemble the organizational structures that produce them. And so, you know, this is also one of the reasons why small teams often outperform large teams, because you have like a smaller group of people designing the whole system thinking in a coherent manner. Whereas when you say, okay, this person is responsible for the data plane, this, this, you know, this team is responsible for the UI, this, you know, team for some other part of the system, you end up having like a lot of, a lot of negotiation and a lot of discordance and kind of the interactions between, between those systems. And that makes, generally makes the software projects a great deal more complex and hard, hard to work with.
The greenfield-to-brownfield problem
Another, another issue that I've seen is that I think a lot of people are experiencing the joy of coding agents in the context of building greenfield software. So I don't know how many, for me, it's like actually a great joy to sit down and make dir and get in it and launch a fresh Claude Code session and start building something. And you're creating files, you're creating build systems, you know, you're, you're terraforming kind of in a godlike manner, you know, with, with a wave of your hand. But that's a lot different from taking agents and dropping them into an existing 3 million line production code base, which has been worked on by a hundred people over a period of 10 or 15 years.
And we've seen, you know, anecdotally that, you know, agents struggle with these, with these large brownfield projects. But if you start a brand new project with coding agents, and despite your best efforts, eventually there's going to come a point where your lovely, delightful greenfield project is going to turn into a brownfield project itself after, you know, a thousand agent sessions and something like that. And I don't know exactly where that, like, where that crossover point occurs, my sense is that it's somewhere in the low hundreds of thousands of lines of code. Like I noticed that, you know, just the feeling of getting things done in a 200,000 line fully agent developed code base, it's just a lot different from like a 30,000 or 40,000 line code base.
And so, you know, I do believe that we're, you know, continuing to accrue, you know, a similar but slightly different type of technical debt, but we're doing it at machine speed. And so, we're starting to encounter the kinds of system scalability, development scalability problems that used to occur much later in the lifespan of a project. So, you could be starting to have these issues after working on a project for only a week or two rather than, like, a year or two. And so, that's just a new problem that we just have to reckon with.
And so, you know, I do believe that we're, you know, continuing to accrue, you know, a similar but slightly different type of technical debt, but we're doing it at machine speed.
Scope creep and the role of saying no
So, if you think about, you know, how cheap and easy it is to generate code, it's easy to, you know, wake up every morning at, you know, 530 or 6 o'clock in the morning and while you're making coffee to drop your first prompt and ask, you know, ask one of the agents to build something. And the agents are happy to oblige. They, like, saying no is, like, almost not in their, I think it's not in their system prompts. Like, they're not allowed to say no, you know, unless you ask them to do something dangerous or illegal. And so, you know, if you ask them to build something for you, it's, you know, relatively rare that they're going to push back and say, like, no, that's not a good idea or, like, that's going to introduce, you know, too much complexity or are you sure that, like, this is the direction that you want to go.
Essentially, you know, we are having, you know, we're turning into, you know, a lot of us were individual contributors, you know, working with a tech lead or a software architect. But now we are essentially all turning into architects or even product managers where our primary role is saying no. And when the agent proposes to do something, we have to be able to recognize that and say, no, no, pump the brakes. Like, I do not want you to do it. And if you don't, well, the bad decisions will pile up and you're back to the tar pit.
This begs the question, how do you hold the agents accountable? And you can certainly use agents to, you know, do adversarial review and design and architecture review. But I think the human in the loop still matters a lot. And I think this goes back to, you know, the point that Uncle Bob was making in Uncle Bob's way that if you lack the technical expertise to recognize when the agents have gone off the rails or have gone in a bad direction that's introducing a lot of unwanted or unreasonable complexity in your system, you know, you're going to end up in just a giant mess. And right now there's lots of non-technical or not very technical people who are using coding agents to build software who are all going to be learning this the hard way and wondering why they're having such a difficult time just making the software work.
And so, certainly, I believe there's, you know, a shift in the skills that matter now. Like, I spent, you know, over 20 years writing code professionally, really priding myself on my ability to write code, you know, my ability. I'm an Emacs user. So, like, I got really good at all of the, like, key chords and, like, you know, being able to refactor code and navigate large code bases really quickly and type and write the code. And now I essentially don't have to do that anymore. And there's, but I do think that, you know, your ability to, like, build conceptual integrity, visualize the problems that you're solving and what the shape of the solution looks like, you know, is one of the most important skills that you can build. And I think that software engineers, especially computer science students, are going to have to spend a lot more time building this skill in a way that doesn't involve writing code.
Certainly, that, you know, the next skill, like, being able to explain and communicate with the agents, if you can't, you know, clearly articulate how you want the work to be done, it's, you know, agents will fill in the gaps with, you know, their own ideas about the way that things should be done. But it may not be right. And if you can't recognize that, you could spend a lot of time building a specification that creates, you know, creates things the wrong way or in a suboptimal way. And so, I do think that increasingly, like, we're going to be engaging primarily with specifications and less with the details of how to build things.
The opportunity: bad software and good taste
But there's a lot of software out there that isn't very good. Probably a lot of it you use every day and it frustrates you. I know that it frustrates me. Gmail.com frustrates me. Like, you know, most software products, as a builder of software, whenever I encounter something that seems not good, I'm often asking myself, like, what product manager thought that this was good, that this was okay to ship in this state?
And so, I do think that there is, you know, for individuals who have, you know, good design skills and good taste, there is a tremendous opportunity to go and recognize, like, this old software, which is created pre-AI, is bad. Let's make something good. And I would challenge everyone in the room, there's really nothing stopping you from doing this. And so, if you encounter software products in your life that, you know, they're not good, you don't have to accept them the way that they are. And I believe it's, you know, kind of incumbent on all of us to kind of embrace that challenge and be willing to reject the, you know, the status quo or at least the status quo pre-2026 and undertake work to build software projects that are good or at least better than the ones that we have. And because it used to be that, you know, the excuse was that it's hard to build things. Like, well, we would make it better, but we would have to spend a lot of money on engineers to write code to make it good. But now that that excuse is gone, that generating the code is free, the only excuses left are that you don't know what is good. Like, you don't know, you know, you don't know what's the right thing to build, and you can't recognize when it's good.
But now that that excuse is gone, that generating the code is free, the only excuses left are that you don't know what is good.
Personal agentic engineering stack
And so, you know, myself, like, I've, you know, embraced this completely and, you know, about six months ago, I went down the rabbit hole and it's like, okay, you know, it's time to build. Like, I spent a lot of 2025 in an existential crisis about, like, my role and, like, is my career as a software engineer over? Are the agents just going to be doing everything without me in the loop? And, you know, by about October, November, I was looking around, I'm like, agents are pretty good, and yet the software is not getting better very quickly, you know, very quickly. I should do something about that.
And so, I've been, you know, been working, you know, day and night, you know, largely seven days a week, maybe not the most healthy lifestyle generating code across a bunch of programming languages. One thing that's interesting is you can see a discrete point at the end of January where I became a former Python programmer. And so, you can see that delta at the end of January where I made up my mind to essentially delete almost all of my Python code and port it to Go. And so, I now largely consider myself an agentic Go programmer.
This also has influenced my choice of programming languages, and so I wrote an essay earlier this year talking about human ergonomics and agent ergonomics. One of the reasons why we use Python today is because it was an amazing programming language for humans to read and write, and why I got so motivated about building Pandas was like, wow, Python is an amazing programming language if only it could do data well. Fortunately, that ended up being a good bet and a good way to spend my time for many years. But now, agents don't care as much about whether Go is annoying to write or not. They care about whether they can compile and test really fast.
There's an aspect of distributing the software. Do you have to carry around a virtual machine? How do you install your dependency stack? Being able to build a static binary and just CP it onto a server on your tail scale network, build it in three seconds and deploy it in four seconds, is a really nice feature of the language. These old ideas of human ergonomics, readability and the ease of writing code and working with code, and your text editor or your IDE, they just don't matter as much anymore. I think that languages like Go and Rust that produce static binaries are prime beneficiaries of this new agent ergonomics.
I also think that because of the fungibility of programming languages, and frameworks, and the top part of the application stack, that this also is causing more value to be pushed down the stack. The things that are lower in the stack are the things that are still hard to build. I struggle to believe that agents could be set to work and could rebuild DuckDB. Maybe somebody will do it someday, but we're not close to that, and those developers are still writing code by hand. Hannes told me himself.
I don't even describe the way that I work now as vibe coding, because I feel like vibe coding has become this pejorative, like, yeah, I don't write the code, I don't read the code either. But that's not the way that I work. Jesse Vincent, who created Superpowers, he gave me permission to reuse this quote, which is from a private text thread. But the difference between vibe coding and agentic engineering is planning, architecture, and caring about the output.
I'll tell you a little bit about what I've been doing in my token maxing adventures. I've burned something like a billion tokens per day the last 30 days. I'm a little bit slower since I'm here at the conference, conference Wi-Fi and things like that. But I am a Superpowers user, and if you don't use Superpowers, which is I think the most popular spec-driven development skills framework out there, I highly encourage you to check it out. It's how I get everything done now.
But around Superpowers and spec-driven development, I've been building a collection of open-source projects to try to bring sanity to my world of agentic engineering. These buckets are code quality assurance, session intelligence, development, visibility, observability, and project management.
I think the idea is that it brings discipline to your planning process. So first, clarify what you want to build, answer a lot of questions about the design. It presents the design in clear stages where you can read this. Human, make a decision. Is this the right design? That's your opportunity. That's where you can add your value to make the right design decisions because the spec will then be created based on those design decisions. When the spec is created, you can review the spec, you can have other agents review the spec. But eventually, you convert that into an implementation plan which takes a long time to implement. I actually had a Superpowers plan that took 14 hours to implement. So sometimes, I find myself late at night, I got to get my plan implementing before I go to sleep. So I have something to look at in the morning.
But there's still a lot of bugs and problems in the generated code. He's talking about Claude being not a good code reviewer. I agree. The GPT-5 line of models is a much better code reviewer, code validator. So I found myself in the beginning of January asking Codex to review every commit that Claude was generating. After a minute, I was like, this should just happen automatically. Why do I even have to ask? So that was how RoboRev was born.
So now, I have agents generating code, and my mantra is like every line of generated code gets reviewed at least once, usually four or five times before it ever lands into a production code base. This is a system that I built to make all of that possible. I tend to rush things and this project keeps me honest. So one of the core concepts is that rather than reviews happening in the ephemeral agent session, the reviews all go into a ledger and they have to be explicitly closed. So it could be an agent closes the review or you close it yourself. But you don't want to do a code review and for the output of that code review to be lost like tears in the rain. So you want to explicitly say like, I read this either you or the agent looked at this code review, you addressed its feedback, and then you closed out the review. So now four months later, I've gone through something like 20,000 code reviews in RoboRev. So it truly is like a continuous autonomous code review system.
I also found that it was frustrating like losing track of all my agent sessions, and there are a lot of half-baked versions of agents view that were built. So I wanted to create a unified session database for every coding agent, full-text search, analytics about tool use, token spend, where am I spending? If I were paying API rates, where would I be spending money?
I did have the misfortune of deciding that I needed to build my own issue tracker after having Beads delete half of my code base three or four times. So I tried a bunch of the lightweight local issue trackers and didn't find anything that I liked. So a couple of weeks ago, I started building Kata, which I encourage you to check out. It's just a SQLite database. There are some stuff in it for issue federation, but it's very helpful for agents to be able to have issues, where they can leave comments and keep track of the state of understanding that issue as they're working on it. So it's another place where agents can record things aside from a collection of scattered and disorganized markdown documents, which is their default.
As we all know, GitHub has been falling apart. Barely works half the days. After a while, I just stopped going to GitHub because you click on the pull request tab. It says there's 27 pull requests, but there's only two showing them. So it's like, how do you even get work done on this platform? So I decided to basically build a new UI for GitHub. It uses the GitHub UI. So now this is, I don't go to github.com anymore. I use Middleman for keeping track of all my projects, all the activity, I merge pull requests, I comment on issues, I look at code reviews.
I've tried out a bunch of the parallel agent managers. I do currently use Superset, not Apache Superset, but superset.sh. It's got a lot of bugs. If anyone in the audience is from Superset, please fix the bugs that I've reported, please. But I do a lot of work in this system, and so at any given time, I might have 20 or 30 Git work trees on my machine, and especially when I'm dealing with inbound pull requests, to be able to go from pull request number, to Git work tree, to hey Claude, run RoboRev and fix what's wrong with this PR, and then I landed in Middleman. So that's how my process works in collaborative development.
So I'm running right up on time, and we've got a few minutes for questions, but I hope to provoke some thoughts about the future of software engineering, and I fully embraced this after being a skeptic for the longest time, and I'm having a lot of fun, and I think the fact that we get to build tools while we're doing it to figure out how to do this better makes it even more fun as a long time tool builder. So thanks for listening, and look forward to your questions.