Are You Building for Humans or for Agents?

Most of the assumptions baked into platform engineering were written for a human user. Cognitive load. Flow state. A delightful UI. Documentation that reads well over morning coffee.

Now ask yourself: what changes when your customer is an agent?

That was the question Arthur Freyman opened with on the latest Stacked Sessions. Arthur runs core infrastructure at ZipRecruiter, with close to three decades in the field and a long-running connection to the security community (he still heads back to DEF CON every year). His talk at SCaLE this year landed on a single, uncomfortable premise: the customer is changing. The human you used to build for is becoming an agent operated by a human. And that breaks a lot of what we've taken for granted.

This is the shift to agentic infrastructure: platform systems built for AI agents as primary users, where structured access, persistent context, and explicit constraints matter more than the polished UIs we used to optimize for. AI agent infrastructure isn't traditional platform engineering with an LLM bolted on. It's a different product, with a different customer.

Agentic infrastructure: the customer is no longer a human

Arthur's premise is that coding is becoming a solved problem. Not the thinking, not the spec, not the judgment. Just the act of generating code that does a thing. If you accept that, then most code in the next few years gets written by agents, with humans operating at the spec layer.

That changes what you build for.

"We don't need a pretty UI for an agent," Arthur said. The interface, the docs, the polish were for the human. The agent needs constraints, context, rules, and structured access. Two different products, even if they sit on the same plumbing.

We've been writing about this shift for a while (see Weaving Agents Into the Developer's Flow and How to Write Specs for AI Agents for related angles).

Why DIY may no longer be sacred

This is where Arthur got a little heretical. One of the longest-held principles in software engineering is don't repeat yourself. Build it once, make it reusable, evolve it over time. Good engineering.

But if an agent generates throwaway code every cycle, and it's cheap and fast for that agent to produce a fresh solution every time, does the principle still hold the same weight?

"I may simply not care if my Claude Code or Codex decided to produce a brand new set of code to solve the problem," Arthur said. "Maybe there's a cost optimization vector that's still worth considering. But at the end of the day, I may simply not care if it decides to reuse a tool or create a brand new one for a similar-ish task."

That's a load-bearing assumption getting kicked out from under us. Worth chewing on. (Our post on what happens when building becomes free explores the broader version of this argument.)

Velocity is exposing your rickety systems

What's actually happening inside engineering orgs right now: AI is making people faster. Not 10% faster. Multiples faster on the right tasks. And that velocity is exposing every duct-taped, half-broken, "we'll get to it later" system in the pipeline.

The bottlenecks shift. The PR review that took 30 minutes was fine when you had two PRs a day. Now you have a hundred. That 30 minutes is the entire factory backing up.

Arthur paraphrased Buffett: when the tide recedes, you find out who's been swimming naked. The systems you've been patching for years were fine at baseline. They're not fine at 10x. The 2025 DORA State of AI-assisted Software Development report bears this out: pull request size up sharply, incidents per PR multiplying, throughput rising while stability slips.

The good news is you probably already know where your weak spots are. Start there. Two related reads: More Code, Fewer Releases: The Engineering Visibility Crisis AI Created and When the Bottleneck Isn't the Code.

DORA still matters. Token count doesn't.

I asked Arthur whether DORA and SPACE are still relevant in an AI-heavy world. His answer: they're the best proxies we've got for velocity and reliability, and those are still the things the business cares about. (Our take on this lines up.)

What's missing is good instrumentation for how developers actually interact with AI. Token counts, Arthur said, are the new lines of code. Track them and you'll get gamed. "If you want me to burn a million tokens because you're tracking that, I will do that tomorrow."

The interesting signals are different. How many times does someone reprompt the agent to finish a task? How well are they parallelizing sub-agents? Where do correlations show up between AI usage patterns and lead times for specific apps? Most AI coding tools export OpenTelemetry-standard metrics now. Start collecting them. Try to mine them. We're all early here. (For more on the measurement problem, see Your AI Coding Investment Is Working. Here's Why You Can't Prove It.)

Vibe coding feels like pre-DevOps

This part made me sit up. Arthur described a pattern he's seeing: a product designer builds something in Lovable that looks like a working app but reads like a PRD, and then hands it to engineering with "deploy this." Sound familiar?

It should. That's the "works on my laptop, ops problem" meme from 15 years ago, just shifted up the stack. The DevOps movement wasn't really about tools. It was about culture. Embedding early. Talking to each other. Killing the throw-it-over-the-wall mentality.

Now we may have to do that work again, between product and engineering, in the era of vibe coding. Same friction, different boundary. We've covered the parallel pattern in Why Some Org Transformations Stick: Lessons from DevOps and Agile for the AI Era and the product-engineering version specifically in The Product-Engineering Bridge.

Context is what's scarce

The most important problem Arthur named, and the one I haven't seen anyone solve well, is how to externalize tribal knowledge so an agent can use it.

A new human engineer can sit next to the principal who's been there ten years and pick things up by osmosis. An agent can't. Without that context, the constraints, the architectural decisions, the "we tried that in 2019 and it broke production" lore, the agent will confidently generate code that's wrong in ways no one notices until it ships. If you're investing in AI agent infrastructure without solving the context problem, you're building a faster path to the wrong answer.

Arthur quoted Tyler Cowen: context is that which is scarce.

The related challenge is what Arthur called the O(n) to O(1) problem. Today, every developer who runs into the same agent mistake has to correct it themselves. Tomorrow's developer hits the same wall and corrects it again. The corrections need to persist. The feedback needs to compound. Right now, it doesn't.

Arthur also pointed out that the platform's role doesn't disappear in all this. It shifts. Today's platform team is on its way to becoming tomorrow's agent orchestration platform, providing shared constraints, policy enforcement, and consistency across however many agents end up running concurrently in your org. The plumbing matters more, not less.

If you solve the context problem in your org, you've solved the most expensive problem of the next two years. (Two related pieces: AGENTS.md Files: The Research Says You're Probably Doing Them Wrong and Comprehension Debt: The Hidden Cost of AI-Generated Code.)

Why this is the most exciting moment in years

Toward the end, Arthur said this is the most excited he's been in a long time. Same. The pivots are real. The assumptions are getting kicked out. The orgs that build real agentic infrastructure, not just bolt AI onto existing tools, are going to look very different in eighteen months than the ones still arguing about whether to allow agents. (The agentic era is already here, and most teams are still driving stick.)

The customer changed. The factory still matters. The work, as always, is figuring out where the bottleneck moved to next.

---

Listen to the full Stacked Sessions episode with Arthur Frayman for more on platform engineering in the agent era, value stream mapping with your grumpiest engineer, and how to manage up on AI spend without getting gamed by your own metrics.