Perpetual Motion Machine

The way agentic AI is changing the software engineering job reminds me of a perpetual motion machine.

“A perpetual motion machine is a hypothetical machine that can do work indefinitely without an external energy source”.

With a brief prompt to start the process, an agentic loop can keep iterating and iterating until it determines that a task has been completed. I can come back later to evaluate the progress, and then start the cycle again. The perpetual aspect of this is not that the agentic loop can run endlessly.¹ It’s the fact that if I need code to be written, I no longer have to synchronously sit and type it out on my keyboard. I can launch a task before my morning commute and at least get a rough draft implementation started instead of having to wait until I’m at my desk at work. The gears never stop churning.

Walking And Chewing Gum

I multi-task often while working. I’ve become very accustomed to bouncing between different screens, like writing code in one window while I’m waiting for a build in another. But actively trying to focus on multiple things comes with a lot of cognitive load. This has become much easier with agents, at least for writing code. I can have multiple sessions going without having to think about syntax, imports, or folder structures. Shifting from synchronous processing to async delegation is a step-change for the parallelizability of work.

Motion Is Not Necessarily Progress

Agentic coding is not a panacea. Think of a Roomba robot vacuum. It’s able to cover a ton of ground with minimal intervention. But sometimes you need something more targeted. If there’s a specific spot to clean, it’s a lot more practical to pull out a hand-held vacuum than to wait for 30-minutes while the robot vacuum drives in the wrong direction. If your home has stairs, you need to carry the vacuum up or down a level to get full coverage. And if you have a black carpet or flooring, the machine fundamentally does not work because the cliff-sensor thinks it’s about to drive off a ledge. Software engineering works the same way. If you expect to operate the software you’re writing at any level, you still need to read the code for understanding, validate the correctness of the implementation, and nudge the agent in the right direction when it goes off the rails.

What Is The Next Bottleneck?

Amdahl’s Law: the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used.

I’ve seen a lot of discussion lately on whether writing code is the true bottleneck in software engineering or if there are other factors that slow development down. Opinions vary on this but certainly the speed of code generation is changing how we work. Engineers are finding their existing workflows challenged by rapid code generation. More code means more strain on PR reviewers, and some teams are abandoning the traditional PR process entirely by having the person prompting the agent conduct the “PR review” themselves. Increasing the pace of change also puts more pressure on CI/CD systems for builds and deployments. Changes to software inevitably introduce bugs. If you have 10X more changes, how does that impact root cause analysis? How do you realize this potential velocity without getting slowed down by your deployment pipeline that takes two weeks to roll out a change?

Finding Leverage

From time to time I revisit the paper “Nobody Ever Gets Credit for Fixing Problems That Never Happened”, which details the negative feedback loops that teams fall into. My team delivered many new features in the last year. But some of these features created new problems for our customers and ourselves as operators that we failed to predict. More features means more surface area for problems to pop up, and nobody wants to operate a service that causes people to get paged in the middle of the night multiple times a week. What will happen to my team’s operations if we accelerate feature development even more?

Since we can now produce code without using as much mental capacity, we are freed up to focus on higher leverage things. What keeps me up at night is the question of how can we continue to scale and automate our operations before they spin out of control. I think resolving ambiguity and reducing complexity² are key factors in driving sustainable software growth, and I plan to focus my energy towards those two things. I want to identify the most critical (customer) problems and solve them in the simplest way possible, while avoiding sharp corners and pitfalls.