Episode Details

Back to Episodes
The Lazy Engineer Doesn’t Exist

The Lazy Engineer Doesn’t Exist

Published 2 months, 1 week ago
Description

In response to: “Software engineers are facing an ‘identity crisis bordering on depression,’ Menlo Ventures partner says” — Thibault Spirlet, Business Insider, June 22, 2026.

Deedy Das, a partner at Menlo Ventures, looked at what AI coding tools are doing to engineering teams and saw two kinds of people. The first he calls lazy — engineers who let the model write the code, answer the questions, file the updates, and engage as little as the system will tolerate. The second he calls craftsmen — the experienced ones who now spend their days reading, reviewing, and repairing the flood of machine-written code the first group ships. Most engineers, he says, are living through an identity crisis bordering on depression. The craft they loved is dead.

Keep craftsmen. Put down lazy.

Here is the argument. The divide Das describes is real, but he has named half of it wrong, and the wrong name hides who is actually on the hook. The so-called lazy engineer is not lazy. He was never formed — and then he was handed a power tool and paid to pull the trigger. He is doing, precisely and rationally, what his employer measures. Somewhere upstream a company decided that the way to capture AI’s promised productivity was to count adoption — tokens spent, tickets closed with the assistant, the percentage of commits that touched the model. And the moment you measure the tool instead of the work, you manufacture the crutch. You don’t get craftsmen at scale. You get a building full of people optimizing the number on the wall. The craftsman doesn’t survive that system; he subsidizes it. He eats the review burden, the defect hunt, the silent cleanup, unpaid and unnamed, while the dashboard upstairs turns green. The craft is not dead. The unformed relationship to the craft is collapsing — and nobody built these people the other kind. That’s the argument.

I watched this exact movie play out in steel and torque, twenty years before it arrived in pull requests. I was running General Motors’ Lansing Grand River plant.

GM had done the expensive, sensible thing across all its plants: computer-controlled DC electric nutrunners, every critical fastener run by a tool that monitored its own torque and reported up into an electronic error-proofing system. State of the art. Corporate sent torque auditors to confirm each plant was using the tools, and using them correctly. The machines were genuinely good. And if you wanted a number that proved the capital had paid off, it was right there on the wall: compliance, green across the board.

Here is what the green did not tell you. The monitor watched the tool, not the joint. Under the wrong run of conditions it would fail to record a missed fastener — and worse, if a tool could reach a little too far, an operator could run a bolt down on the wrong vehicle entirely, and the system, satisfied that a rundown had happened inside its window, would call it good and release the line. The car that actually rolled out the door short a bolt was logged as fine. Months later a dealer would call about that very car, you would pull its build ticket to see what went wrong, and the ticket would swear nothing had — because the fault had quietly landed on the record of the car ahead of it or behind it in the sequence. The system was confidently, auditably green about a defect it had already shipped to a customer.

So who actually caught those? Not the system. The formed operator — the one who had spent years learning what a seated joint feels like in the hand before any light confirmed it — would look at a green light and still know something was wrong, and stop. The operator who had never been formed trusted the light, because trusting the light was the whole of what anyone had taught him. Same tool. Same green light. Opposite outcome. The variable was never the tool. The variable was the human the tool had been handed to, and

Listen Now

Love PodBriefly?

If you like Podbriefly.com, please consider donating to support the ongoing development.

Support Us