Laziness: You’re doing it wrong.

Reclaim those lost “opportunity costs” of typing in code.

Your AI assistant is trying to help you… Let it. (You don’t have to trust it completely)

I’m lazy.

I think that makes me efficiently use my time.

I think that lets me save my energy for things that matter more than whether I need a colon or a semicolon to separate these elements of my PATH environment variable (or do I have the time to actually “do the right thing” write code to handle both so that my code will work in Windows and Linux/MacOS).

I recently had a conversation with Gemini about the Rust programming language. It started with a narrow, focused discussion about the .unwrap() method (one of the few “not recommended” features of the language), and for the next hour or so the discussion meandered to topics of Haskell (Monads), union types, error handling, fearless concurrency and the borrow checker.

The conversation flowed so naturally… the AI rewarded my insights with mild but satisfying sycophancy, led me from topic to related topic not as an author would group chapters in a book, or a speaker would segue to a new concept… but following the links of my own train of thought! It reinforced connections I’d already made in my mind to other experiences, programming languages, and concepts. It really clarified a lot of things I’ve been struggling for a few years now to absorb via “katas” (programming exercises) with my co-workers, reading (okay, skimming) Rust books and occasionally playing around with the language myself. Is this how we will learn in the future? Or am I just doing something I don’t think a lot of people are doing (yet?). Did I waste an hour that I could have been writing software? If you stay curious, laziness doesn’t mean dumb.

Agentic programming (a.k.a., “Vibe Coding”, a.k.a., “Pairing with Bots”) seems to be very focused on the actual act of generating code. I grow somewhat weary of the oft-repeated, “Don’t trust the code AI generates” trope… Do you trust the code that junior developer just out of school put into your mission-critical server? Yeah, you shouldn’t trust that either. Maybe it wasn’t the junior dev, but rather a burnt-out senior dev that is distracted and chasing a second remote side-hustle. It has ever been so. Only the paranoid survive, code needs to earn trust regardless of author.

What do Developers Actually Do Now?

Shocking news flash: typing in code is a small part of a developer’s job.

I want to focus on what we should actually be spending time on now that the code generation part can usually happen in seconds, not hours. Here’s a list of things developers may have been somewhat involved in before… but have now been liberated to help with more than ever:

1. Learning… Take a “side quest” to deeply understand, as I did above.
2. Requirements Elicitation… Have you talked to your PM lately?
3. Testing… Somebody’s gotta do it. AI wrote the code, so get after it!
4. Design Prototyping… Generate 2 or 3, they’re cheap, keep the best one.
5. Research… What else is out there? How did others solve this?
6. Experimentation… Try something completely different. It’s cheap.

Having worked with a small team and heavily leaning on agentic coding tools for the last year and a half, my life… not just my professional job… has changed dramatically. I’m now free to tackle ambitious re-architectures and tech debt projects our small team often dreamed about in years past, perhaps even started, but couldn’t get anywhere near the goal of shipping to customers as quality software. We release dozens of times a week, with only a handful of developers. From that description, it probably doesn’t sound like I’m taking every opportunity I can to be lazy… but I am. And therein lies the secret. Let your AI assistant help you do most things.

How can my AI assistant help me even more?

Composing new source code fast is certainly very helpful, and primarily what a text generator is best at doing. A friend of mine asked me what I thought an appropriate amount was to budget per developer on AI. In mid-2026 I think a reasonable place to start is $100–$200 per month on the frontier model fixed-price plans. The question was asked “Do you really need the latest Opus to ask StackOverflow-type questions?” No, you don’t. In 2024, that would have been a reasonable question and an unreasonable price. But it’s not 2024 anymore, is it? If you’re still just asking stack overflow questions, you’re doing it very wrong in 2026.

If you need further evidence of how things have changed, almost a million people have decided they would rather work for an AI model than ask it StackOverflow-type questions: https://rentahuman.ai/ .

This is (not) the way…

(By the way, I switched from Nano Banana 🍌 to ChatGPT images and that one seemed to capture what I was going for distubingly well 😨 ☝️.)

Let me flip that script, and tell you a happier tale of something I did recently because of my laziness…

The “gold standard” for usability testing of User Interfaces (GUIs) is in-person testing where prototypes or early test releases of software are presented to willing test subjects, along with a “goal” or “scenario” expressed by an in-person observer, who is usually an interaction design professional that is qualified to observe the user’s attempts to accomplish said goals and ask follow-up questions to elicit what is and is not working with respect to enabling that user to understand and use the interface.

I haven’t been making a user interface, but rather an MCP server recently… and I was not looking forward to trying to test it, mostly because the only real measure of whether is working or not is through an LLM. You can probably see where I’m going with this, I had my “minions” (like, every machine capable of running a decent local LLM in my house) do this testing for me over a weekend. On monday, I had a few hundred “observations” from a second LLM that was watching the interaction, capturing the errors, struggles, re-tries, etc. and noting the circumstances of the failures that were occurring. I did get a lot of failures due to the fact that these models aren’t “genius”-level tool-callers… but that was a benefit in many ways, as it highlighted the ways LLMs could fail to use the MCP server properly. It felt like a big success, and I had a lot more fun managing the minions than I would slogging through the tool use scenarios with my pair programmer. It was very satisfying to have Claude synthesize and help prioritize the observations, then attack them one by one… and test them within the same Claude Code session. It was probably the equivalent of months of human work to generate that much feedback.

So, the point is… view your laziness as a virtue when you are the bottleneck standing between what you currently have and released, working software. In 2026, you almost certainly are.

Lazy programmers unite!