Agents Made Every Interrupt Feel Free

A customer dropped a Slack: “I found this. Wouldn’t it be great if we could do that?”

I used to park those, write them down, and get back to the product that actually moved the number.

Now I paste it into an agent, because starting looks free. Twenty minutes later I have a branch, a passing test file, and a demo. I feel useful. I have not gone back to the bigger work. I have also not counted review, deploy, the bug this will throw in production, or the hour I will spend tomorrow explaining the shortcut to the next person who touches it.

Good engineers are doing this everywhere. Laziness is the wrong diagnosis. They are available, and a cheap start is how the day gets stolen. Agents made every request feel like something you can finish before lunch. Generation hid the bill. The interrupt still collects it.

I have a hypothesis about who wins the next decade, and I want the argument on that. The park is not part of the bet, and you still owe it today.

The Interrupt Is the Selection Mechanism

A request used to cost a day of typing and a fight for a sprint slot. Ugly friction, but it filtered junk. Now you can have a working copy of the flow before you have loaded the real system in your head. The demo shows up before the invoice does.

Write-ups on agents keep hitting the same notes: they ship the visible eighty percent and leave you the production twenty, vibe coding works until other people have to live in the code, and generated output needs a human owner who can explain and maintain it. I agree with the notes. I also think they describe the mess after someone pasted, not why the paste happened.

The missing piece is how the work got chosen.

A developer is on the thing that should move the product. A customer, a PM, or their own itch arrives: I found this, wouldn’t it be great. They paste it into an agent because the start feels free. They get lost in the side quest. They do not return to the bigger picture.

Sometimes nobody pinged them. They saw a small ugly thing while loading the real system, pasted it because cleanup looked like ten minutes, and spent the afternoon on a helper the user never asked for. The Slack did not require a paste.

You know the product work is the work. You take the cheap request anyway. You picked the request and the model typed it.

The hidden bill is still the old bill: time to load the real system, review, deploy, the defect you will train the next person on, and the context you dumped to start the side quest. None of that is free. Generation hid it.

Then the product gets a new kind of damage. You keep the primary function and bolt on a shortcut. The shortcut works in the demo and lives in neither the architecture nor the user’s path. You did not ask how the screen or the service fits the rest of the system. You locally optimized a request. Do that thirty times and you get a product whose parts were started as separate yeses and no longer add up to one experience a user can finish.

People look at that pile and blame the machine for bad architecture and bad UX. I think the human is choosing the work. The model will generate whatever you start. If you start every Slack, you get a product that reads like a Slack archive.

Code got cheap is the cousin about judgment once typing is cheap. Big PRs is the cousin about review size. This one is the moment before either of those: did this request deserve to enter the shop at all?

If everything is urgent is the leadership version of alarm inflation. This is the individual version, where you became the alarm.

What I Think Wins

I keep betting on discipline and patience, boring as that sounds.

The person who can sit in the bigger product while the Slack lights up will own the next decade. That forecast can be wrong. The person who cannot will ship demos that look like progress while the user’s week stays broken.

Waiting is not cover for a live outage, a promised ship date, or a broken path a user is on today. Those requests are the work, and the cheap start is everything else.

The move is to stop treating a fast start as a cheap finish. Park the request on a list you will read at the end of the day, not in a new worktree. Name the bill out loud: load time, review, deploy, the defect, the abandoned product hour. Ask one systems question before you paste: where does this live in the architecture, and where does it live in the user’s week? If you cannot answer, you are not ready to generate. If the answer is “it lives nowhere, we would be inventing a side door,” you already have the decision.

You do not control how many “wouldn’t it be great” messages arrive. You still control whether you treat the agent as a reason to start. Email and hallway requests had the same vice. The agent made the vice cheap enough to run all day.

A junior on a ticket mill still owes the park. A contractor on someone else’s backlog still owes the systems question. Missing seniority does not make the interrupt free. A manager who scores you on opened branches is circumstance. The paste is still yours.

Tell Me Where This Breaks

I hear three answers. The model is the problem, fix the model or the scaffold. The org is the problem, no intake, no later pile. Speed is the strategy and the mess is tuition. All three can be true. None of them decide which request should have been typed. The engineer still hits paste.

I could be wrong on the decade. Maybe generation quality is the main leak and the interrupt is a side story. Maybe the teams that win will take every request and get frighteningly good at cleanup. I do not think that is what I am watching. I think the filter moved from “can we type this” to “will we wait,” and most people have not noticed they need a new muscle. Wrong on the decade still leaves the park owed this afternoon.

If you have a counter-example, I want it: a team that takes every Slack, ships, and still has a coherent product, or a case where waiting was the slop. Send it.

Final Thoughts

Agents did not invent the cheap yes. They removed the last excuse for saying the yes would take too long.

Generation hid the bill. Review, deploy, defects, and the product you abandoned for twenty minutes still collect it. If we keep blaming the model for architecture and UX that a human chose to start, we will keep starting slop and calling it a tooling problem.

The engineer who can wait, stay on the bigger work, and think through the few requests they take, will eat the field. I think that is the hypothesis. I want the argument.

Ready to train the muscle that stays on the work that matters? Join us at MasteryLab.co.