You Gotta Push Back

The other day I was reviewing work a subcontractor had done for our client's designer. It sounded like a simple UI inconsistency that needed fixing, so I was surprised the submitted work ran to hundreds of lines of code.

Digging in, I found the subcontractor had built a brand-new "date picker" component from scratch, where before the app just used the native HTML input. Why? Because the designer's work item asked that all dates across the site be formatted consistently. The native date picker takes its formatting straight from the user's operating system, so the only way to get total consistency is to roll your own.

The contractor dutifully executed the request. But pushing back ("Can we make dates consistent everywhere we control them and leave the rest to the operating system?") would have produced something far simpler and more focused.

Part of maturing as a software engineer (and really any professional) is learning to surface the trade-offs in a client's request: sure, we can do exactly what you asked, but tweak it slightly and it's cheaper, faster, better.

In agentic coding, the roles flip. Now you're the client, and you need to watch for the moments where a senior engineer would have pushed back. That's why I always start in plan mode and check whether the proposed scope matches my intuition for what the job should involve. Especially when the AI wants to spin up new objects, routines, or preprocessors, it pays to ask: are we doing this because it's the right way, or because of some fringe requirement that can't otherwise be satisfied?

AI is trained to be pleasant and agreeable. That's exactly why you can’t be.