Give a programmer 100 files to rename and there is a good chance they will write a script.
They might spend as long writing it as they would have spent renaming the files. But the next time, they run the script. The computer gets the repetitive job.
That is the useful kind of laziness programmers have always valued. You put effort into making sure you do not have to keep putting effort into the same thing.
In 2026, that instinct has somewhere new to go. We can ask an agent to write the script too.
And increasingly, we can ask for the application around it, the interface we want, and the changes that make it better to use.
I think we should be getting lazier. There is more we can make when we stop insisting on personally doing every step required to make it.
I still want the buttons aligned
Yesterday, I wanted some buttons aligned in a label-printing app.
For most of my career, that would have meant opening the stylesheet, finding the right element, checking how the layout worked, and remembering which combination of CSS properties would move it where I wanted.
This time, I described what looked wrong and asked for it to be fixed. The AI found the relevant documentation, worked out the CSS, and changed the layout, styles, and borders.
I looked at the result and kept going.
I still care whether the buttons are aligned. I care quite a lot. But I can express that at the level of what I see on the screen, without first translating it into the framework’s layout rules.
The old approach to automation saved me from moving files around by hand. This saves me from working out every implementation detail by hand. I can spend that attention noticing what else would make the application better.
That feels a little like getting a superpower.
The unit of work got much bigger
For much of 2025, my experience with AI coding still resembled an accelerated version of the old workflow. Ask for a function or a feature, review the code, test it, then move on to the next piece.
During 2026, that changed.
Writing code by hand was a good way to spend a career. I enjoyed finding a clean implementation and understanding why it worked. That experience still helps me. I just do not feel obliged to preserve all the manual work that came with it.
DHH’s recent Rails World 2026 keynote made the case for going “pencils down” on handwritten code. I recognize the excitement. What makes this transition compelling to me is how much more I can ask the computer to do.
I can give an agent a larger outcome and have it work across the application. It can investigate unfamiliar code, read documentation, make changes, run checks, and work through the problems it finds. I can come back to something substantial enough to use and give feedback on.
The difference is visible in the kinds of requests that feel reasonable now.
Port this driver to Linux. Rebuild this interface so it works properly on a phone. Investigate why this service keeps using more memory. Set up a review system that takes feedback and produces another version.
Those requests used to contain a long list of things I would have to learn or implement myself. Now they can start a body of work that continues while I turn to another project.
The scope I can ask for has expanded, and so has the number of projects I can move forward at once. Yesterday made that change hard to ignore.
Two printers, all the way down to the driver
Over the weekend, I had been working with an obscure Chinese thermal label printer. Its old Mac software was based on a port of a Windows driver and had not been updated in a long time.
With AI’s help, I reverse engineered it and built a native Mac driver.
Yesterday, that driver got ported to Linux. The Linux computer was configured to share the printer over the network, and the driver gained features that had been missing on Linux. I can now print without moving a USB cable between computers. A small quality of life improvement.
Then there was the smaller Brother label printer attached to a Raspberry Pi.
That one already had a Python-based web application for printing. Yesterday, its old Flask and Bootstrap interface was replaced with a React app with a better mobile experience. It gained saved labels, sample labels, formatted text with different fonts, and settings that could be changed through the interface instead of a hard-coded file.
The printer controller also gained paper-type detection and controls for sleep behavior.
This covered the whole experience, from communication with an obscure device to the placement of buttons on a screen.
The label app is a small project. But being able to improve all of it this way is a big change. I could ask for what I wanted, try the result, notice something else, and keep refining it.
Previously, each layer would have been another reason to stop. Now it is another thing to ask about.
Meanwhile, other work kept moving
At the same time, I was improving a marketing production system for the beverage company.
It gives me a local web interface where I can approve assets, reject them, or leave feedback. An agent checks for feedback every ten minutes and works through revisions.
The system tries to maintain ten items waiting for review in each category, including social posts, ads, email, and video. When a queue runs low, it starts another brief and asset. Approved work moves into the relevant scheduling or delivery platform, including Klaviyo for email.
Yesterday’s changes focused especially on making the email workflow better.
That is a larger example of the same shift. I am describing how the process should work and improving it by using it. The software connects the pieces and carries the work forward between my visits to the review screen.
This is the sort of process I wrote about in loop engineering. Generation, review, and revision become parts of a continuing workflow.
There were other jobs underway too:
- A neglected WordPress site about kava got server updates, fixes, a new theme, and new graphics. A research and rewriting pass across roughly 1,800 posts began and is still running.
- The programmable button pad on my desk got a configuration for switching between projects and businesses, along with a new window-management setup.
- About 50 GB of old Docker images got cleaned up, after a detour to check some old Bitcoin-related images for anything worth preserving. No treasure.
- A marketing and production plan for merchandise sales got started.
I also made network cables and wired in some computers. Those still required me to pick up a tool.
A day like this would have looked unreasonable to me a year ago. The range is as striking as the volume. Driver work, interface design, server maintenance, marketing operations, and desktop customization could all make progress without waiting for me to personally execute every step.
Small fixes and bigger ambitions
The printer projects might sound like a strange use of all this capability. That is part of why I like them.
Greater productivity gives us room to do things that are enjoyable or convenient, as well as things with an obvious business return. An obscure printer can have a better interface. A setting that used to require editing a file can become a button. A tool that was awkward on a phone can become pleasant to use.
At the same time, bigger projects become realistic.
The live baseball stats system was one example. It connected independent data services, a Go backend, and live elements on a WordPress site. That was a level of ambition I would previously have had a harder time reaching for.
These are two consequences of the same change. Less implementation work falls directly on me, so I can afford to care about more details and attempt larger systems.
Being able to do more gives us room for some ridiculous side projects as well as the serious ones. A label printer can get a complete overhaul while something much bigger is moving forward.
There is still someone doing the developing
The useful kind of laziness has always required paying attention to the result. A script that renames the wrong files has not saved you any work.
You have to notice that the interface is awkward. You have to explain the behavior you want. You have to recognize that memory usage is growing, that the result is wrong, or that the proposed solution misses the point.
Then you ask for a change, inspect the result, and keep going.
My technical background helps me do that. It gives me a vocabulary for the problems and a sense of what to investigate. But I do not need to hold every API, framework convention, or layout rule in my head before I can make progress.
I can ask for better usability. I can ask the agent to investigate performance or memory use and check whether its changes helped. I can encounter a bug while using the application and start work on it immediately.
The implementation still has to be right. I can delegate more of it and still be the person deciding whether the software does what I wanted.
The next time something is slow or awkward, I have another option besides putting up with it or setting aside a weekend. I can ask an agent to investigate, then use what it builds and ask for the next improvement.
When the software gets easier, value moves
There is a business consequence here too.
As the cost of implementation falls, having the software becomes less of an advantage on its own. More people can build a capable application. More features can be copied or replaced.
I expect more of the value to sit in what forms around the software. A community people want to belong to. A network that becomes more useful as others join. A marketplace where buyers can find sellers who actually respond and fulfill orders.
For the manufacturing project I have been thinking about, the application enables the business. The relationships and successful transactions are what would make it valuable.
That makes this an especially interesting time to build. We can spend less effort getting the basic software into existence and more effort discovering what people will do with it.
The part I liked most got better
I think I will remember 2026 as the year my software-development job changed.
The daily work feels different. The size of a reasonable project feels different. Even the little annoyances around my desk feel temporary in a way they did not before.
Yesterday ended with two better printers, improvements to a marketing system, a revived website with substantial work still underway, and a computer setup that fit the way I work a little better.
The best part of software development has always been seeing an idea come to life. You imagine something the computer could do, and eventually you get to use it.
Now there is less work between those two moments. I can describe an idea, watch it take shape, try it, and make it better. Sometimes that means an ambitious system for the business. Sometimes it means a little printer finally behaving the way I want.
I enjoyed the years of writing the code myself. But seeing the idea become real feels more magical than ever.
If being lazier lets me do more of that, I intend to get very good at it.
