Every operations team we work with has a list.
Not the big list — not the conversions, the new fund launches, the regulatory build-outs. Those get project plans and steering committees and executive attention. The other list. The one that lives in someone's notebook or a long-running email thread. A report that would be genuinely more useful with one additional column. An exception message that says validation failed when it could say which field and why. A tolerance threshold that made sense three years ago and now generates twenty breaks a week that a person clears by hand every morning.
None of these are hard. Each one is worth maybe a few hours. And most of them never get done.
I want to talk about why, because I don't think the reason is what clients usually assume, and I think it's starting to change.
Twenty years on both sides of the queue
I've spent over two decades in financial services. I started as an operations analyst, moved into reconciliation, then recon specialist, then operations manager, and eventually into product management. I've watched the tooling evolve the whole way — from Excel macros that were genuinely load-bearing to the applications our clients use today.
So I've been on both sides of that list. I've been the person clearing the same twenty breaks every morning, knowing exactly what change would stop them and having no way to make it happen. And I've been the person on the vendor side receiving that request and putting it into a queue.
Here is what happens to it there. A small change isn't just its own effort. It has to be specified, scoped, estimated, prioritized against everything else, assigned, developed, tested, and released. The overhead of moving a small change through that process has historically been larger than the change itself — sometimes much larger. So when a two-hour fix costs two weeks of process, it loses. It loses to the compliance deadline, it loses to the client implementation, it loses to the platform work. Every time.
That isn't neglect. It's arithmetic. But the effect on the client is the same: you asked, we agreed it was a good idea, and nothing happened.
What's actually shifting
The interesting thing about AI in software development isn't that it writes code. It's what it does to that arithmetic.
I'm a product manager. Writing code was never in my job description — my job was to define what to build and why, and the how belonged to engineering. What's changed is that I can now take a small, well-understood change from idea to working implementation myself, without consuming engineering capacity to do it.
I started small and deliberately low-risk. And what struck me wasn't the novelty of it. It was that the calculation had moved. The change was worth doing on its own merits, and for the first time the cost of doing it was proportionate to its value.
Why judgment is the part that matters
I want to be precise here, because the interesting claim is not "AI writes code."
The hard part of that small change was never the code. It was knowing which change to make. Knowing what's safe to touch and what isn't. Knowing which downstream process consumes that field. Knowing that this looks like a display issue but is actually a data issue, and that this other one looks trivial but sits next to something fragile. Knowing what needs a real engineer.
That knowledge comes from twenty years of clearing breaks and running operations teams. It doesn't come from a prompt. What AI changed is that this judgment no longer has to be translated into a written requirement, handed off, queued, and interpreted by someone who wasn't in the room when the problem was described. The person who understands the problem can act on it directly.
That's the shift I think matters for our clients — not that engineering gets faster, but that domain expertise gets closer to the product. The distance between someone who deeply understands custody operations and the thing that actually changes in the software is getting shorter.
What this doesn't mean
It doesn't mean product managers pushing code to production.
Everything that governed changes before still governs them: code review by engineers, testing, release management, the same controls and approval gates. What's changing is who can author a small change, not who approves it, tests it, or ships it. If anything, the discipline around scoping matters more, not less — because the constraint that used to filter out small changes was capacity, and capacity is a blunt filter. Judgment has to do that work now.
I still lean on our engineers for anything with real complexity or risk, and I always will. There's a category of work where the right answer is an experienced developer, and knowing where that line sits is part of the judgment I described above.
Where we are
I'll be straightforward about this: we're early. This is a change in how our product organization works, and we're still learning what it's good for and where it isn't appropriate. I'm not describing a shipped capability or making a claim about our roadmap.
But it's changing how I think about that list — the small things clients have mentioned that were always reasonable and never quite made the cut. For twenty years the honest answer to most of those was "it's a good idea, but it won't clear the bar." I'm less convinced that bar sits where it used to.
If you're an operations leader reading this, you probably have that list. I'd be interested to know what's on it, and whether you're seeing the same shift inside your own organization.