I recently built a home network configuration system I had been deferring for years. The reason was not complexity. It was overhead. Debian packaging has a lot of well-specified, repetitive mechanical work: the kind where you know exactly what the output should look like but do not want to produce it by hand. With an AI assistant, I described what each package needed to do and got a correct skeleton back in seconds. The overhead that previously made a dozen small packages feel like a large project collapsed to almost nothing. I built it the right way, and it took a weekend rather than a month of accumulated evenings. The technical details are in a separate note.
It is not that AI can do things I cannot. It is that AI changes the cost of doing things I already know how to do.
The pattern this reveals Link to heading
The example isolates something specific about where AI tooling actually helps: not capability, but economics. The question is what was previously not worth doing that now is.
There is a whole class of tasks like this: work where the barrier is not knowledge or judgement, but mechanical overhead. Boilerplate. Format compliance. Repetitive structure that follows rules you understand but do not want to apply by hand. For that class of task, the threshold for “worth doing properly rather than cutting corners” has shifted significantly.
The implication for how I work as an engineering leader is real. The question I used to ask before tackling a piece of technical debt or a backlog item was: is this worth the time it will take to do it properly? That calculation has changed. Things that previously sat below the threshold now clear it. The list of things worth doing properly has grown.
The list of things worth doing properly has grown.
What this is not Link to heading
It is not that AI makes hard problems easy. Architectural decisions, debugging subtle failures, understanding an unfamiliar codebase, designing something that needs to be right: none of that has changed much. Those problems require judgement and understanding, and AI is a useful sparring partner but not a replacement for doing the thinking.
The mistake I see most often is confusing these two categories: using AI for the work that requires genuine understanding, and expecting it to perform as well as it does on the mechanical work. It does not. The confidence looks similar; the reliability is not.
The value is in recognising which category a task falls into. The mechanical and the conceptual are different kinds of work, and they call for different kinds of help.
When the barrier is overhead, reach for AI assistance. When the barrier is understanding, do not outsource the understanding.
What it means for teams Link to heading
The engineers I work with who use AI well have internalised this distinction. They reach for it when they know what they want and are grinding through the mechanics of getting there. They stay hands-on when they are still working out what they want.
The outcome is not just faster output. It is a different set of things getting done. Work that previously sat below the threshold gets done properly now. That is a real shift in what a team can deliver, and it compounds over time.
This is a small example of something I think matters at scale. When the cost of doing things properly drops, the average quality of what gets built goes up. That is the dividend worth capturing.