Be as Lazy as You Can

I burned my entire monthly token budget in a couple of weeks trying to be lazy.

The experiment was simple. I wanted to get my agent to grab a ticket from Jira, collaborate with me on a plan, let it cook, and open a PR when ready. Not only that, I wanted to do this in parallel for all the work in my sprint. I wanted to outsource all the work to my agents and go do something else.

For better or worse, at my current job we have a token budget. As it turns out, if you let your agents run on their own as long as they need to complete a complex task, they will run through that budget rather quickly. And what I got back at the end of it was not up to the standards that I wanted.

That experiment sent me back to a phrase I have been carrying around for ten years.

The phrase

"If you want to be a good programmer you want to be as lazy as you can."

That was the first thing my professor said in my intro to Computer Science class at Kansas Wesleyan University. I have a Computer Science and Computer Information Systems degree from there, and honestly, I don't remember much about the classes I took during those three and a half years. But that phrase stuck. That is all I had to hear to know that I had chosen the right major, and as it turned out, the right career.

In my almost 10 years of experience I can now say that I love being a software engineer. Every day is a little different, there are always new problems, new libraries, new technologies, always something that will keep you on your toes. I don't remember the fundamentals or technicalities that I learned during college, but I keep that phrase always present.

What my every day reminds me is that "be as lazy as you can" does not mean to ignore your work and coast. It means to find the things that produce friction and use your skills to reduce that friction as much as possible.

The CLI that came out of being annoyed

One example that comes to mind is one of the projects that I am most proud of. In my previous job we had a multi repo approach for libraries and applications, and the process for creating new projects was a bit convoluted. Every time I needed a new library or application I had to go through a bunch of scattered documentation and a set of processes that would lead me to creating my project, and every time I would miss or skip a step.

I am a programmer, I can automate things. Let's take this silly process and make it as easy as possible so I don't have to remember all the steps and go fish for documentation that I will likely forget about.

From that friction a CLI tool was born. It was easy to use and removed all the friction of creating a new project. It made it so anyone in our organization could start a new project with a one line command. All scaffolding was taken care of, no digging for documentation, no pinging me about "how do I do this or that?" It all turned into look at this doc and run this command.

That is exactly what my professor meant.

The same instinct, pointed at agents

Every day I see little interactions, small adjustments, repetitive work that can be automated. That is where the lazy perspective has to come in and influence our decisions. Take something that bothers you and make it easier.

These days my workflow has completely shifted. A year ago I was optimizing my Neovim setup, trying to increase my typing speed and other things that made writing code easier and faster. Today I want to focus on how to improve my agentic workflow. AI, mostly in the shape of coding harnesses, has completely shifted the way we work as software developers, but the foundation is still the same: be as lazy as you can.

So pointing that instinct at my whole sprint felt like the obvious next move. It wasn't.

What actually went wrong

The token budget was the symptom, not the problem.

The agent spent an enormous amount of time and resources doing work that would have taken half of those resources with a more manual and thorough process. Left alone, it wandered. It explored paths it did not need to explore, and it arrived somewhere I could have pointed it to directly in one sentence.

The bigger problem was me. I was getting complacent with the output. I had been trusting the agents more and more and getting lazy on reviewing the quality of what came back. I was also losing track of the small decisions that were being made during the implementation.

That is where I realized that being lazy about a process is good, but being lazy about understanding and quality is not.

So I scaled back. I put my input back into the loop, and it turned out to be better on every axis I care about. I am more in control of where the work goes. It constantly challenges my understanding of the problem, because I have to actually have one to steer. And it is significantly more token efficient, because the agent is not paying to discover things I already know.

Where my value actually comes from

I am still working through my development process, and I am still trying to be lazy about it. I honestly want to keep working on these complex problems, but more than anything I want to understand the problems themselves. Outsourcing thinking is not the path to being lazy, it is the path to mediocre output with just as much overhead.

My current workflow splits each step into its own and keeps me engaged with the output of the agent at every checkpoint: planning, outlining, implementing, reviewing, testing, shipping.

I am noticing that my value as an engineer is my understanding of the processes, the complexity and the product. And the fact that I want to be lazy is a value add that the AI agents cannot access. Being lazy forces me to think critically about what we are doing, it forces me to optimize for my own good, for the better of my team, and finally for the best of the business.

This new development workflow will keep evolving, and I will keep trying to stay as engaged as possible to keep my mind sharp. At some point it might go back to a fully automated look, who knows, but I now understand that even if that is the case, I need to find a way to stay engaged in the process.

Another principle that I learned as a junior engineer was "slow down to go fast," which blends in nicely with this laziness topic. I will leave that one for another article. But with those two things in mind, I am going to keep optimizing and automating while keeping a high quality output.