The bottleneck moved to the people who cannot code

There is a version of the AI productivity story that only counts engineers, and it looks great. Merged PRs go up. Migration timelines collapse. Test coverage climbs.

Then you go and ask the BI team how long it takes to get a new dashboard, and the answer is the same as it was in 2023.

Where the queue actually sits

In most organisations of a few hundred people, the flow of an internal tool request looks like this.

Loading diagram...

Two queues, in series. The first one is a prioritisation queue and it is honest: an internal report will lose to revenue work, and it should. The second one is a capacity queue, and it is the one that quietly eats everything.

DevOps ends up as the funnel for every request that has no other owner. Somebody needs a cron job scheduled. Somebody needs a secret injected. Somebody needs a hostname, a certificate, a scoped IAM role, an SSO integration, a cost tag. None of those tasks is hard. All of them require a person with production access, and there are four of those people.

Making engineers faster does nothing to this. If anything it makes it worse, because faster engineers produce more things that need hosting.

The teams that fixed it went sideways, not faster

The published accounts I find most instructive are not the ones where engineers got faster. They are the ones where the people who are not engineers started shipping.

Pinterest has documented two years of this with unusual honesty. It began in 2024 with Text-to-SQL inside Querybook, their in-house query tool. They reported a 35% faster SQL task completion, and they published that number specifically because it was lower than lab studies suggested. A second iteration added retrieval over embeddings of more than 100,000 tables, which lifted first-shot SQL acceptance from 20% to over 40%. By March 2026 it had become the Pinterest Analytics Agent, which converts historical SQL into intent embeddings so the agent understands business questions rather than table names. Within two months it reached 40% of the analyst population and became the most-used internal agent at the company, with ten times the usage of the runner-up.

The thing to notice is not the agent. It is that they built an internal vector-database service to industrialise the pattern. The analyst-facing win required platform work.

Block went further in reach. Roughly two-thirds of its 10,000-plus employees use Goose weekly, and that includes sales, design, and support, per Forbes in November 2025. Recipes are what carried it out of engineering. A recipe is a file you can send someone, and running it does not require understanding it. Block contributed Goose to the Linux Foundation's Agentic AI Foundation in December 2025.

Spotify's Fleet Management attacks the second queue directly. It has executed code changes across thousands of repositories since 2021 and auto-merges when tests pass, over 270,000 automated PRs in 2022 alone. The bottleneck was writing the deterministic transformation scripts, so in February 2025 they replaced that step with Honk, a background agent that takes migration instructions in plain English. Everything else stayed. By November 2025 Honk had merged more than 1,500 AI-generated PRs with reported time savings of 60% to 90%.

Read those three together and a pattern falls out. None of them gave non-engineers a coding agent and hoped. Each built the boring infrastructure around the agent first: a vector service, a recipe format, a fleet-wide PR pipeline. The agent is the cheap part.

The uncomfortable shape of the fix

If the constraint is that shipping a tool requires production access, and there are four people with production access, there are only two ways out.

Hire more of those people. This does not scale and it is not the interesting answer.

Or remove production access from the critical path by making the deployment path itself a template. The scheduled job, the read-only dashboard, the internal web app. Each one exists as a hardened starting point that already contains logging, secrets handling wired to the real secret store, access control behind the company identity provider, telemetry, and tests. The analyst describes the tool. It scaffolds from that template. It goes through the same checks every other change goes through. It deploys onto infrastructure the platform team already runs.

Nobody grants anybody production access, because the template already has the access it needs and no more.

This is the part where I think most "AI for the enterprise" pitches go wrong. They sell the generation step, which is the step that already works. The generation step is not why your BI team waits a quarter. Your BI team waits a quarter because the output of the generation step has nowhere to go.

What this does to the DevOps team

The obvious worry is that self-serve tooling means DevOps drowns in support requests for tools they did not build.

The published accounts suggest the opposite, when the templates are real. Shopify's central LLM proxy, the one every AI request in the company routes through, is run by about six engineers, with per-user cost alerts. That is not six engineers fielding tickets. That is six engineers owning rails that everyone else runs on.

The work changes rather than growing. Instead of provisioning the fiftieth cron job by hand, the team maintains the scheduled-job template. Instead of chasing a dependency bump across fifty repositories, they fix the template once and the update propagates as pull requests to everything built from it. Instead of reviewing each tool's approach to secrets, secrets handling is inside the scaffold and there is nothing to review.

That is a genuinely better job. It is also a different job, and the transition is not free. Somebody has to build and own the first three templates before anyone benefits, and during that period the team is slower, not faster. Every account I have read describes that dip. None of them found a way around it.

What I am not claiming

I am not claiming that giving finance a template library turns finance into an engineering team. Most of what non-engineers need is genuinely narrow: a scheduled report, a read-only view of data they already have access to, a small internal form. That narrowness is the reason a template envelope works at all. It is also the reason the envelope has to have an edge, and things outside it have to be refused clearly rather than attempted badly.

Next month I want to go through the published platforms properly, side by side, and pull out the parts they all share. There are fewer than you would expect.

---

dkod rebuilds ungoverned AI-built internal apps under governance, from approved templates. Discovery starts with dkod-signals.