Here Be Monsters: What Do You Still Need to Know When Agents Do the Work?

CI was failing. This was unexpected. I have dialed in my agentic workflow to a point where I would be surprised if one of my agents committed a branch that had failing tests. Maybe it's a CI flake or environment issue? Wait, it's SonarQube complaining about App.tsx? Did we pull in a new suspicious dependency from npm or something? Nope. SonarQube is flagging this file for cyclomatic complexity. Haven't seen that one in a while. Yep. App.tsx consists of about 30 lines of code, except 15 of those lines are actually entire components that Codex decided to write each on a single line. That itself would be ok, just run it through prettier and we're done. But that doesn't explain the cyclomatic complexity. Each of these was a fairly involved component with a good amount of display and business logic. Old self would have carefully refactored it and made sure the code was readable. On the other hand, Codex didn't care that entire components were on a single line, and more importantly, it didn't mind the complexity. It had been happily and reliably iterating on that file through several features. The CI tool was flagging an issue, perhaps correct, perhaps incorrect. But this is a real system so I had to dive in. After formatting the files, I went through and inspected the components and logic. Did Codex go beyond what a typical dev might have in terms of covering edge cases and did it slightly over-engineer it? Yes, but it was all correct. No complaints from me. All of the complexity was warranted by the business requirements. So I told Codex to make SonarQube happy, which it did by refactoring and splitting things up into 10 files. CI passed; things shipped. Although this particular incident had a quick resolution, you can probably imagine how it could have gone much worse. This was, after all, code I had never seen before. This is where our industry is headed: Owning a software system will depend a lot less on having written it (or similar systems) by hand; instead, what will become most important is knowing just enough to know when something is wrong, and being willing and able to dive as deep as needed, when needed. Divebots and golden nuggets Imagine that you're on a boat (you decide what type of boat you like) and your job is to collect little nuggets of gold from the bottom of the ocean. Up until very recently, if you wanted to get your bag of gold you would need to jump into the water, swim to the bottom, look around, and stuff your bag. Easy peasy if you're in clear, shallow waters, but you can imagine how quickly this can escalate into something much more difficult. So as the shallow water mines started drying up, you and fellow engineers built all sorts of machinery and tooling to extract gold from ever deeper and more dangerous waters. This worked well for the most part, you and your team would carefully assemble, maintain, rotate the machinery and would constantly dive to the seabed mining operation to keep it running. Every so often you'd hear about the collapse of some mining operations, sometimes due to the sheer underwater pressure, other times through accidents, or operator incompetence. The challenge is that this is a very geologically active world, so the seabed keeps changing with some mines drying up and new ones popping up in different places. Good news though! The last few years have seen the development of ever more sophisticated divebots that can go down and build a mining operation on their own. You just tell them where to build and off they dive and only surface to give you updates and gold nuggets. Things are great, you can now relax on your boat while your divebots do their thing and all you have to worry about is how much gold you can stuff into your boat. This is the Optimists camp.

Until...

"Wait till your divebots go too deep and get lost". "Haha your divebots brought you stuff that looks like gold but is actually shiny octopus poop". As the divebots proliferate you see more and more horror stories. Divebots getting lost and forgetting what they are supposed to be building. Divebots building something so complex and grotesque that they have trouble maintaining it, only for it to be discarded by the next generation of divebots. All of the underwater mining operations went from being carefully designed and engineered cathedrals to more like haphazard mansions, with hidden passages and horrors lurking. The more detached from the operation you are, the more spectacular the failures. This is the Skeptics camp. Here Be Monsters The software engineering industry (and I suspect many other industries soon) is living through a version of the above scenario. You probably already know whether Skeptic or Optimist describes you better, even if you're still not sure which camp you want to commit to. The traditional wisdom is that in order to develop and maintain a non-trivial system you need to have a proper working model of it. I think few people would argue with that. And in software engineering you would acquire that working model by working directly with the code. Years and decades of practice writing and reading code give you the knowledge and tools needed to understand the systems you're responsible for.

Every production incident, every late-night debugging session, every successful release.