Two years ago, if a revenue ops analyst wanted a tool that pulled data from three systems into one view, they filed a ticket and waited. If they were lucky, an engineer picked it up in a quarter. If they weren't, it sat in the backlog forever, because "small quality-of-life tool for one team" loses every prioritization fight against "feature that affects the roadmap." That's not a criticism of engineering teams. It's just math. A ticket that saves one person twenty minutes a day will never beat a ticket that unblocks a customer deal.
That math hasn't changed. What's changed is that the analyst doesn't need the engineer anymore.
Give someone with no coding background a Claude or ChatGPT seat and a real problem, and they can produce a working tool in an afternoon. Not a mockup. Not a slide deck describing what they wish existed. An actual thing that pulls the data, does the calculation, and renders a page. I've watched this happen inside engineering orgs at more than one company: the tickets that used to sit untouched for a year are just getting built by the people who filed them.
This is, on balance, a good problem to have. Every one of those "nice to have" tickets that never got prioritized represents real time someone was spending on a workaround instead of the work, and multiply that across a whole company and you get a lot of quietly wasted hours. Once in a while, one of those homegrown tools turns out to be good enough that half the team ends up using it. The people closest to a workflow are often the ones who see the fix most clearly. They just never had a way to build it before.
But building was never the hard part of shipping software
Ask anyone who's actually run an engineering team what a feature costs, and code is maybe a third of it. The rest is review, access control, monitoring, the on-call rotation that has to know the thing exists, the decision about who's allowed to see what data it touches. Companies built entire platform teams around that "rest," precisely because getting it wrong is expensive and getting it right takes real expertise.
None of that infrastructure exists yet for the tools nontechnical builders are shipping today. So what happens instead? The tool gets posted in a Slack channel, where it rots the moment nobody remembers it's there. Or it gets deployed to whatever free hosting the builder found first, with no login screen, sitting on the open internet next to whatever spreadsheet or API it was reading from. Or it gets built against a real production database using credentials that were never meant to leave one person's laptop.
The building problem is basically solved. The company still hasn't figured out what happens after "it works."
That's the gap that matters right now, not whether AI can write good enough code (it increasingly can), but whether there's anywhere safe to put what it writes. Solve that, and the ticket backlog that's been quietly ignored for a decade starts clearing itself out, one afternoon project at a time.