How I Code Today
I don't use IDEs anymore. I barely ever see code. My primary tool is a terminal window. At the moment I'm using the Grok TUI, although I've also used Codex and Claude. I tell it what I want, how it should get to where I want, what tools to use, what constraints to apply, and what thresholds to apply. Then I watch it very carefully. I look at the architecture it generates, and I try to get as much intelligence about what it has done as I can without forcing myself to go all the way to the code.
My working hypothesis is that human beings are too slow when dealing with code. If we're going to move at the speed of the agents, we're all going to have to back off a little bit and maintain high-level supervision. The level of code is probably out of our domain now, for the most part.
Why I Changed My Mind About AI
Two years ago I said AI is not the future of coding. What changed? The AIs.
Even as much as a year ago, I was fiddling around with AIs, and they did things rather stupidly. I was convinced this was just not going to go anywhere. It's a nice little tool, I can use it a little bit, but I still have to be deep in the code. Then, around January, I started to see a change. All of a sudden I could ask the agents to do something and they would do it better. Not great, but better. And virtually every month after that, it has gotten better and better.
I've just extracted myself from a rat hole I'd been in for the last two or three months, building constraints that would keep the models in place. Now they've completely outgrown that. I don't need those constraints anymore.
Three Constraints That Keep Agents in Line
I still use the same constraints. The difference is that I've relaxed the austerity with which I enforce them.
Constraint number one: unit tests. If you don't have agents write unit tests, so far as I have seen, they will go off into Wonderland. Unit tests are a double-entry bookkeeping approach: the agents have to say everything twice, and that keeps them in line. Many times I have seen an agent break a test, then back off and realize it needs to go another direction. You can see that as you watch the code stream by in the window. You can't read the code, but you can see what's going on.
Constraint number two: CRAP. It's an old metric from about 2007, Change Risk Analysis and Predictions. It combines test coverage with cyclomatic complexity, and the number skyrockets if you've got a very complicated function that isn't tested. It's perfect. I used to keep CRAP down to four. Then I thought that was probably too restrictive and backed it off to six. At this point I think 12 is probably okay. That's part of the relaxing I've been doing, because the agents are getting so much better.
Constraint number three: mutation testing. Everybody knows that a code coverage tool doesn't tell you what has been tested, it just tells you what has been executed. Mutation testing proves that the coverage is actually covering things that are tested. The tool makes modifications to the source code and expects every modification to fail a test. Any modification that doesn't fail a test is a surviving mutant, and I have the agents kill all the surviving mutants, within limits. There are some things it can't kill and some things it shouldn't. But for the most part, it gives you much higher reliability on the coverage numbers.
Keeping Tests Aligned with Intent
Agents can write tests that pass while reflecting a misunderstanding of the task. I handle that two ways.
First, I am the final arbiter. I run in a very tight loop. I force the agents to make changes, then I execute the code and play with the system. Things I don't like, I tell it to change. For applications where something pops up on the screen and you can move through the steps quickly, that works great. The agents misunderstand a lot of things. They can't really see the screen, and they don't interact like a human would, so a lot of human factors they just ignore.
Second, Gherkin. If you've got a fairly elaborate system that requires a lot of behavioral specification, it is wise to have humans produce that, and I like Gherkin, the old behavior-driven development language, for it. I've had my agents build Gherkin interpretation tools that parse and execute the Gherkin, so you have a second set of tests that are authored, or at least reviewed, by humans.
Agents Can Handle More Than Humans
I wanted small functions because human beings are extremely limited in their short-term memory.
Keeping more than five or six or seven things in your mind at once is beyond most humans. Agents don't have a short-term memory constraint like that. They can manipulate many different facts simultaneously. So I'm relaxing that.
The way I measure it is whether the agents get confused. You can see when an agent gets confused: it starts breaking tests, breaking something else. Agents will do all the things a human would do if you task-saturate them.
I've Pretty Much Stopped Reading Code
I still look at it from time to time. I'll pop up a little window, look at a module, and think, I don't like that module. But most of the time, 95% of the code I never see.
One Human Can Now Do the Work of a Team
This is my wild conjecture, but it seems to me that a single human can now do the work of a team. Therefore, our reliance on software teams is going to change dramatically. Instead of a tight-knit group of five or six developers constantly communicating with each other, I think we're going to have isolated individuals producing much more code than before, much larger kinds of elements. And they'll have to communicate at a very narrow interface boundary.
The amount of collaboration, I think, is going to decrease, even though the amount of functionality increases.
That's pure conjecture on my part. It might go in the absolute opposite direction.
UML, Reborn
I've got a fairly elaborate project I'm working on, and a tool that breaks it down into UML. The tool is coupled to an agent, so they communicate back and forth. I can click on items, expand them, collapse them, play what-if games. It looks like UML, but it's dynamic: I can drill down, and if I go far enough, I can drill down to the code. Usually I don't have to, but every once in a while I will.
I could walk through this diagram with you and explain the way the system works pretty quickly without you ever having to look at the code. This was the old dream of UML, but UML was conceived as a static thing you did before you wrote the code.
This is now a dynamic thing you do after the code is produced, so that you can inspect what the agents have done and then undo the horror that they have created. Because there's an agent attached, I can say: I don't like the way this is arranged, can you move those things around?
My intent is that something like this is the way we will all have to interact with systems over the next couple of years. What do we care about in designs? That the system is properly partitioned, that we can decouple things that are highly variable and isolate things that are highly static. Those are the things a software engineer is really worried about. In a depiction like this, you can see that. You can circle things, say this is bad but that's good, and then have an agent shuffle things around and make it better.
Teams Need Disciplines Before Anything Else
The first thing any team needs is a set of disciplines: rules they all decide to follow until they have a meeting and decide they've got to break one. Rules like: we're going to have unit tests, we're going to drive coverage as high as possible, we're going to keep CRAP below a certain threshold, we're going to mutation test within certain limits, and we're going to verify that it has all been done correctly. After that, maybe Gherkin is part of it if it's a big enterprise system. Maybe human review in a GUI cycle is part of it.
The thing you want to avoid in any kind of team, or even individual setup, is the vibe coder who just prompts his way to something that appears to work. You want to make sure it actually does work.
Why I Stopped Building Harnesses
The real giveaway was that I never used the harness to create the harness. The whole time I was creating it, I was just driving a single agent, and the agent was getting better and better.
The breakthrough moment for me was about ten or twelve days ago. I sat down with an agent, Grok at the time, and had a 45-minute in-depth discussion, proposing things and getting counterproposals back. The kind of discussion I could only have with an extremely seasoned senior engineer. I would propose something, and the agent would say, "No, that's stupid, you can't do that. Here's why." And it would be right.
If I am willing to invest that much trust into a single agent, and give it that level of consideration, why am I putting it into a harness that makes it act like a menial slave?
A Different Kind of Exponential Curve
I lived on the exponential curve from the 1960s on. Moore's law was running like gangbusters; we needed new computers every year and a half. All of that was driven by exponentially shrinking electronics. We are now on a different kind of exponential curve, the AI exponential curve, and it's being driven by growing power and growing real estate, which has a very severe physical limitation. I don't know how long we're going to be on that curve.
Only Humans Can Be Responsible
The agents are not responsible for anything. They're entirely irresponsible. Only humans can be responsible, at the moment and probably over the next several years. That means we software developers have to take our skill and experience, apply it to what the agents have produced, and then sign off, with all the responsibility and all the repercussions that implies.
I'm going to make sure that the system is deployable and rational, without devolving all the way down to reviewing the code. Reviewing the code isn't very useful anymore, and it slows everything down like crazy.
Somehow we humans have to take responsibility for the systems at just above the code level. Leave the syntax to the agents, but everything else we still hold near and dear to our hearts, and we are responsible.
Clean Code Still Applies
I wrote the second edition of Clean Code just before I started this AI thing, right at the moment when I thought AI wasn't going to go anywhere. It has a lot more examples, but it's pretty much the same as the previous book. And in the end, all the same principles apply, even with agents. You still want the code to be clean. You still want good partitioning, good dependencies, good names, and you still want to manage your comments properly.
The thresholds might be different. The boundaries might be a little different. That's where I'm exploring things at the moment. But all the rules are still there.
I'm not going to change anything in any of the fundamental principles in Clean Code. It still all applies. And it is the responsibility of the developers, the humans, to make sure those rules are applied properly.