990 posts tagged with "insider"

Your platform team measures success by developer adoption. Monthly active engineers on the internal API. Time-to-first-call for a new service. Net promoter score from the quarterly DX survey. Every one of those metrics assumes a human is on the other end of the request — someone who reads a getting-started guide, copies a curl example, and grumbles in Slack when the error message is unhelpful.

That assumption is quietly becoming false. The fastest-growing consumer of your internal APIs is not a person. It's an agent: a coding assistant resolving a ticket, a workflow that reconciles invoices overnight, a support bot that calls six services to answer one question. These callers don't skim your docs — they ingest your tool schemas into a context window. They don't file a bug when an error is cryptic — they silently retry, burn tokens, and give up. And they are about to outnumber the humans.

Your dashboard has never looked better. Pull requests merged are up almost double. Commits per engineer are climbing. Lines of code are pouring in. Every activity chart points up and to the right, and the AI coding tool you rolled out six months ago looks like the best money the org has spent all year.

Then you check the one number nobody puts on a slide: how long it takes for a customer to actually get something they asked for. It hasn't moved. In some quarters it's worse. The team is producing more of everything except the thing the business buys.

This is the velocity mirage. The metrics that are easy to count went up, and the outcome that matters quietly went the other way. It is one of the most expensive measurement failures in engineering right now, because it looks exactly like success.

There is a specific kind of regret that only happens on AI teams. You spend a quarter building an elaborate workaround — a multi-step prompt chain, a custom reranker, a hand-tuned tool-routing layer — and ship it. It works. Then six weeks later a new model drops, does the whole thing natively in one call, and your quarter of work is now dead weight you have to rip out. The feature didn't fail. The floor moved.

This is the structural problem with planning AI features in 2026: the substrate you're building on is improving faster than your release cycle. From 2023 into mid-2025, frontier labs shipped on a roughly six-month cadence. By Q1 2026 that compressed to substantive releases roughly every four weeks, with stretches where five labs shipped inside a thirteen-day window. The thing you're standing on moves under you between planning and launch.

Ask any engineering leader whether they're locked into a model vendor and they'll point you at the abstraction. "We route everything through a gateway. Swapping providers is a config change." The endpoint is one line. The base URL is an environment variable. On paper, migration is a Tuesday afternoon.

Then they try it. They flip the config to a different model family, the integration tests stay green, and production quietly falls apart. The JSON that always parsed now arrives wrapped in a markdown fence. The classifier that hit 94% drops to the low eighties. A prompt that ran clean for a year starts refusing one request in twenty for reasons no one can reproduce. The endpoint swapped in seconds. The behavior did not come with it.

This is the lock-in nobody budgets for. It doesn't live in your contract or your SDK. It lives in your prompts — thousands of small accommodations your team made, one at a time, to the quirks of a single model family. You didn't choose a model. You married one, and the prenup is every prompt you've ever shipped.

The first thing a team does when its inference endpoint starts missing latency targets is buy more GPUs. The second thing it does, a month later, is notice that p99 latency barely moved while the bill doubled. The cards are sitting at 40% utilization and the tail is still ugly. Somebody adds an autoscaler. The autoscaler thrashes. Now there are more cards, more cost, and the same complaints from the same users.

The mistake is treating slow inference as a capacity shortage. It almost never is. What you have is a queueing problem wearing a capacity problem's clothes. Tail latency on an LLM endpoint is governed by how requests of wildly different sizes share a fixed pool of compute over time — which is the textbook definition of a scheduling problem, not a provisioning one. Until you understand the queue discipline your serving stack is actually running, every GPU you add is just a more expensive way to be slow.

Look at any AI product roadmap and you'll find columns for the things you're going to launch: a new agent, a better retrieval pipeline, a model upgrade, a fine-tune. Every item is a birth. Nothing on the board is a death. There's no column for the model you'll stop supporting, the prompt you'll retire, the eval set you'll archive, the feature you'll turn off. Roadmaps are optimistic by construction — they're a list of futures you're promising to create.

That omission is fine for deterministic software, where a feature you shipped two years ago mostly keeps working until you touch it. It is quietly catastrophic for AI systems, where the things you shipped are decaying whether you touch them or not. A prompt tuned to GPT-4's quirks degrades the day the provider nudges the model. An eval suite written against last year's failure modes stops measuring anything real. A model you depend on gets a 60-day deprecation notice you didn't plan for. A roadmap that only plans launches is accruing silent liability on every line it doesn't track.

A clinical decision support tool has exactly one job: help a doctor reason about symptoms, medications, and treatment plans in the same vocabulary the doctor would use in their own notes. That means the agent has to talk about overdose thresholds, drug interactions, contraindications, and dosing by name. None of that is optional. It is the product.

So it is a special kind of failure when the model interrupts a consult to say it cannot provide medical advice without professional oversight — to a professional, mid-consult, about a patient in front of them. The doctor didn't change. The patient didn't change. The prompt didn't change. What changed was a safety filter the team doesn't own, tuned against a population the team isn't part of, updated on a schedule the team doesn't control.

This is the vendor moderation seam, and it is one of the least-discussed boundaries in applied AI. Most teams treat the provider's safety layer as a fixed property of the model, like its context window. It isn't. It's a policy — a living one — and right now it's your product's policy whether you wrote it or not.

The demo worked. You typed a question, the agent called three tools, reasoned through a multi-step plan, and produced an answer that made the room lean forward. Someone said "ship it." Three months later you're still not shipped, and nobody can quite explain where the time went.

Here is where it went: the demo was 10% of the work. It was the brain. The other 90% is the plumbing — the evals, guardrails, observability, cost controls, and fallback paths that nobody claps for because they're invisible when they work and catastrophic when they don't. That 90% is the demo-to-production tax, and most teams budget for it as if it were a rounding error.

The numbers say otherwise. MIT's 2025 study of enterprise AI found that 95% of generative-AI pilots delivered no measurable P&L impact. A separate analysis put it more bluntly: for every 33 proofs of concept an enterprise starts, four reach production. That's an 88% mortality rate, and the cause of death is almost never the model. It's everything the demo let you skip.

Most finance teams filed their first LLM bill in the wrong drawer. It arrived during the experimentation phase, when a handful of engineers were prototyping with an API key, and it looked like exactly what it was at the time: research and development. A few thousand dollars a month to figure out whether the technology worked. So it went into R&D, mentally and sometimes literally, and nobody thought harder about it.

Then the feature shipped, usage climbed, and the same line item that was a rounding error in Q1 became the fastest-growing cost on the cloud invoice by Q4. The problem was never the dollar amount. The problem was that the cost had quietly changed categories — from a fixed bet on building something to a variable cost of serving every customer who used it — and the mental model hadn't moved with it.

That misclassification is the single most expensive accounting mistake in AI products right now, and it's not really an accounting mistake at all. It's a forecasting one.

Every team shipping an LLM feature eventually holds the same meeting. Someone asks whether the new model — or the new prompt, or the new retrieval tweak — is good enough to ship. The senior engineer who spent the weekend testing says it feels sharper. The PM says a customer complained about exactly this last week. The skeptic on the team pulls up a transcript where the old version was clearly better. Forty-five minutes later, nobody has changed their mind, and the decision gets made by whoever talks last or outranks the room.

That meeting is a symptom. It recurs because the team is trying to settle an empirical question — did this change make the system better or worse? — with anecdotes, and anecdotes don't converge. You can stack them all day. The reason the debate never ends is that there is no shared instrument that everyone agrees to be bound by. The meeting that should have been an eval is the meeting where you discover you're missing one.

The quarter your team adopted coding agents, two things happened that nobody put on the same slide. Throughput went up — more pull requests, more merged code, more tickets closed. And your three most senior engineers got slower. Not lazy-slower. Drowning-slower. Their own commits dried up, their calendars filled with review, and the one-on-one refrain shifted from "here's what I shipped" to "I spent the week unblocking everyone else."

This is the seniority inversion. The people whose time was supposed to get more leveraged by AI are the ones who got buried by it. And it isn't a motivation problem or a tooling gap. It's a structural consequence of what agents actually do to the shape of work: they make generation cheap and verification expensive, and verification is the one task you can't hand to a junior or to another agent.

A prompt-variant experiment runs on the production traffic of an AI-assisted search product. The success metric is a click on any suggested action in the response. Variant B ships responses that are roughly forty percent longer with more enumerated options. The click-through rate is eleven percent higher with three nines of statistical significance. The experiment is declared a winner and shipped.

A month later, the weekly customer satisfaction survey drops two points. Nobody connects it to the launch because the experiment has already been written up as a success and the team has moved on. A quarterly review eventually traces the satisfaction drop back to the prompt change, and the diagnosis lands hard: variant B won not because it gave users better answers but because longer answers contained more clickable surfaces. The click handler fired more often per impression because there was more to click, not because what the user read was more worth acting on.