Financial services has a reputation among engineers: it's the place where velocity goes to die. Ask anyone who shipped software at a startup and then took a job at a bank, a broker-dealer or a ratings shop. The pipelines run slower. The approvals multiply. Somewhere in the building, a committee with "advisory" in its name holds veto power over your Tuesday deploy.
I've spent most of the last decade inside that reputation, at Moody's Analytics from 2016 to 2019 and at Edward Jones since 2022. I'm here to defend it.
Partially.
Regulated environments taught me a skill I didn't recognize as a skill until AI-assisted development showed up without it: saying no before the first line of code exists.
In financial services you don't get to ship it and see what happens. Before any change moves, somebody asks four questions. Who approved this? How does it roll back? How many customers can it hurt? And if it goes wrong, how will you prove what happened?
Early on, those questions felt like drag. I'd come from eight years of commodity trading systems where we moved faster and asked later. Most engineers experience the questions that way for their whole careers, and I get it. They're slow. They're repetitive. They arrive at the exact moment you're ready to move.
But the questions were cheap to ask. The expensive part was the pricing.
At Moody's I sat in Change Advisory Board reviews where a one-line configuration toggle got the same treatment as a schema migration touching every customer. Same form, same meeting, same lead time. The board asked good questions. It priced them all identically.
Engineers respond to flat pricing the way you'd expect. They bundle. Why pay the toll ten times when you can cram ten changes into one RFC and pay it once? Except now the RFC is riskier, so the board slows down, so the toll goes up, so the bundles get bigger. I watched that loop feed itself for two years.
Every change pays the same toll
|
v
+--> Engineers bundle ten changes into one RFC
| |
| v
| RFCs get riskier
| |
| v
| The board slows down
| |
| v
| The toll goes up
| |
+-----------+
Flat pricing on the no. The loop feeds itself until somebody reprices the toll.
In January 2019 I wrote a proposal to reform our CAB. Four change types instead of one. Whitelisted standard changes needed peer review and a manager's sign-off, then they shipped. High-risk changes needed a director's approval on both the IT side and the business side before the board ever saw them. Behind it sat a plain risk matrix: impact measured in customer blast radius, likelihood measured in testing confidence.
One rule from that proposal still shapes how I work. Every change scoped so it can be finished and rolled back within 12 hours, no bundling allowed. If any part fails, the whole thing comes back out.
The real subject of that proposal was pricing. A no should cost something proportional to the risk it prevents. Waste your nos on config toggles and nobody will hear the one that matters.
At Edward Jones I felt the process from the other side of the table, as the person asking for the yes. Bringing GitOps to a broker-dealer meant months in front of the Architecture Working Group and the Technology Advisory Board, answering the four questions over and over with more specificity each round.
It was slow. It was also the most useful design review the initiative ever got. By the time the first team deployed to production through the new pipeline, we had a tested rollback procedure and an audit trail a regulator could walk without me in the room. Nobody had to trust me.
And the yes held. Progressive deployments with Flagger came later and inherited that trust. A yes you fight six months for tends to be durable, because every objection surfaces while it's still cheap to address.
I've been the person slowing the room down, too. I've asked the blast-radius question in meetings where you could watch the energy leave the table. Thirty years in, I can report that the question has never once been popular.
It's still the job.
AI-assisted development generates change faster than the four questions can be asked. That's new. Every previous wave I've watched (client-server, web, cloud, containers) still moved at the speed of human hands. This one doesn't.
I know the pace is real because I've lived on it. Over five months I built a 41-repository framework mostly by writing rules and letting a model generate code against them. I also know what the pace does without a working no. On July 1 I audited my own pipelines and found two months of green checkmarks hiding zero real conformance passes (I wrote that story up last week). I had built the four questions for other people's changes and skipped some of them on my own.
Financial services firms are now running that experiment with thousands of engineers instead of one. The instinct to treat this wave as ungovernable is wrong. The four questions don't care whether a human or a model wrote the diff. Who approved it, how it rolls back, how much it can hurt, how you'd prove what happened: the muscle regulated industries spent decades building is exactly the one this moment calls for.
Most industries teach you to ship. Financial services taught me to answer for what I shipped.
Of the two lessons, the second one is about to be worth a lot more.