Saying "no" to a feature or a deploy is actually a high-value

But here is the thing: when AI-assisted development hit, I realized that the ability to vet a change before writing a single line of code is what separates a senior engineer from someone just generating a lot of noise.

The Risk Loop

In regulated environments, you're constantly grilled on four things: Who approved this? How do we roll it back? Who gets hurt if it breaks? How do we prove what happened?

The problem is that most companies "price" these questions flatly. Whether you're changing a button color or altering a core ledger, the bureaucratic toll is the same. This creates a dangerous loop:

Flat toll for every change
 |
 v
+--> Engineers bundle 10 changes into one RFC to save time
| |
| v
| RFCs become high-risk "mega-bundles"
| |
| v
| The board gets scared and slows down further
| |
| v
| The toll (friction) increases
| |
+-----------+

I spent time at Moody's Analytics fighting this. I pushed for a risk matrix where "standard changes" only needed peer review, while high-impact stuff got the full board treatment. The goal was simple: a "no" should cost something proportional to the risk it prevents.

Why this matters for AI workflows

Fast forward to my time at Edward Jones. I spent months fighting the Architecture Working Group to get GitOps implemented. It was grueling, but because we had to answer every possible objection upfront, the final "yes" was bulletproof. We had audit trails and rollback procedures that were regulator-ready.

Applying this to a modern AI workflow or LLM agent deployment is critical. If you just let an AI agent iterate and deploy without these "financial services" guardrails, you're just accelerating your path to a production outage.

A few rules I still use to keep things sane:

• No bundling: Every change must be scoped to be finished and rolled back within 12 hours.
• Blast radius check: If the AI suggests a "quick fix," ask how many customers it could potentially hurt before hitting merge.
• Auditability over trust: Don't trust the AI's explanation; build the pipeline so the audit trail is visible to anyone.

Fighting for a "yes" for six months is annoying, but it makes the deployment durable. When you surface every objection while it's still cheap to fix, you actually move faster in the long run.