Airbnb Built the System Around the Tool — And That Changes Everything

I've been in and around developer tooling for a long time. I remember the first time I watched a team roll out a shiny new IDE plugin with great fanfare, mandatory demos, a Confluence page nobody read, and then... nothing. Six months later, half the engineers had uninstalled it. The tool was fine. The system around the tool was missing entirely.

That memory came rushing back when I stumbled on Linas Beliūnas sharing a 15-minute talk by two Senior Staff Engineers at Airbnb. Stepan and Mike, who build tools for engineers on Airbnb's developer platform, laid out something I have not seen explained this clearly anywhere else: what it actually takes to make agentic coding work at enterprise scale. Not which tool to buy. The whole system you have to build around the tool.

You Bought the AI Coding Tool. Who's Maintaining Your Scrapers?

This issue is about the system you build around the tool. For most AI teams, the weakest part of that system is the web data feeding it: brittle scrapers, rotating proxies, and selectors that break every week.

Bright Data Scraper Studio takes that layer off your plate. Describe the data you need in one sentence, and it writes a scraper you own:

Build the system. Skip the maintenance.

Most enterprises I talk to are somewhere on this journey: they have licensed a coding assistant, maybe piloted it with a few teams, and are now wondering why adoption is uneven and the productivity graphs are not bending the way the vendor promised. Sound familiar?

Airbnb's engineering team started 2025 with a bold vision — not an incremental improvement plan, but a step-function change. Stepan (one of the two engineers presenting) put it plainly in the talk Linas shared: "If you only think about incremental improvements, it's kind of hard to make a big change." He has been building tools for engineers for close to two decades, and he says he has never seen productivity graphs like the ones agentic coding is producing. That is not nothing, coming from someone who has seen several waves of developer tooling come and go.

But here is the part enterprises keep skipping: Airbnb did not just deploy a tool.

That is four infrastructure layers before you even get to the tool itself.

ACTION BYTE: Map your current agentic coding rollout against these four layers — sandboxed environments, review tooling, skill-level frameworks, adoption culture. Which ones exist? Which ones are missing? That gap is where your productivity is leaking, not the model.

I want to spend a minute on the skill-level framework piece, because I think it is the most underrated element here and the one I see enterprises get completely wrong.

Agentic coding is not one thing. It is a spectrum. On one end, you have a junior engineer using an agent to autocomplete boilerplate and catch syntax errors. On the other end, you have a senior engineer orchestrating an agent to run multi-step workflows across repos, write tests, and propose architectural changes. Treating those two use cases with the same tool configuration and the same guardrails is a recipe for either over-constraining your seniors or burning your juniors.

Airbnb's team figured this out. The Linas Beliūnas post is worth fifteen minutes of your time precisely because it gives you the mental model, not just the punchline.

This also connects to what the team at Latent Space covered in their Tenex deep-dive with Alex Lieberman and CJ Hess. CJ describes spending less time directly coding as models get better, and more time getting customer context into a form the model can actually use. That is a new engineering skill. It is not something you get by buying Cursor and telling everyone to "use AI more."

What I'm seeing in the trenches: the engineers who thrive with agentic tools are the ones who can think clearly about what the agent needs to know, not just what they want it to do. That is a craft. It needs to be developed deliberately, with frameworks and feedback loops, not left to individual experimentation.

ACTION BYTE: Before your next all-hands demo of your agentic coding tool, pull three engineers — one junior, one mid-level, one senior — and ask each of them separately: "What does the agent need to know about our codebase to be useful to you?" The answers will tell you exactly what your skill-level framework is missing.

Are you building one agent per person, or one agent for everyone? That question is not as simple as it sounds.

The team at Every made a dramatic call: they deleted 86,730 lines of code from their personal-agent product, Plus One, and replaced the entire fleet with a single shared company agent. Willie Williams wrote up the full story, and it is a must-read for any enterprise leader thinking about agent architecture right now.

The short version: running a personal agent for every user was operationally brutal. Each user's agent lived on its own cloud machine, keeping those machines healthy left the small team almost no time to improve the product, and many users who tried it stopped using it. The behavioral insight that cracked it open was simpler than they expected — Plus One was most useful when people borrowed someone else's agent. Once one person connected their agent to the analytics tool, the whole team started asking it growth questions.

That is a shared infrastructure insight, not a personalization insight. And it maps directly to what Airbnb built: a system that scales because the infrastructure is shared and deliberate, not because every individual customized their own setup.

The other move Every made was handing their infrastructure to Anthropic's Claude Managed Agents, which dramatically reduced operational overhead. The lesson here is not "use Claude." It is: choose what to build versus what to hand off, and be ruthless about it.

ACTION BYTE: If you are running or planning personal agents for each employee, stress-test the assumption. Ask your team: where did the most value actually show up? If the answer is "when someone else's agent was involved," you may be one architecture decision away from a much simpler, more powerful system.

I have been a fan of Alex Lieberman's work for a while — he is one of those rare founders who thinks out loud in public in ways that are genuinely useful, not just promotional. So when he showed up at AIE New York with CJ Hess to talk about building an AI-native software development lifecycle at Tenex, I paid close attention.

Tenex's bet is unusual: pay AI engineers for the work they deliver, not the hours they spend. The incentive structure runs toward output quality, not input volume. The feared failure modes — inflated estimates, bad code to rack up story points — have not been the biggest problems. The harder question is how to reward work that does not fit neatly into a ticket: understanding a customer's problem, designing an architecture, deciding what to build at all.

That last part is where I see most enterprises get stuck with agentic tools. They measure the wrong things — tokens generated, PRs submitted, lines of code written (Yes this is still happeing!) — and miss the value that is actually compounding: better problem framing, cleaner architecture decisions, faster feedback loops between engineers and customers.

IMHO, this is one of the most important and challenging org design questions of the next two years. What do you measure when the code itself gets cheaper to generate?

ACTION BYTE: Pull your current engineering metrics dashboard. Circle every metric that measures input (hours, lines of code, commits). Now ask: what would you measure if code generation were essentially free? Start designing for that measurement system now, before the transition catches you flat-footed.

I have witnessed several AI hype cycles, and I try to hold both truths at once: the productivity gains from agentic coding are real, AND the financial scaffolding underneath this buildout is showing cracks. Ignoring either one is a mistake.

Ed Zitron's piece "AI Had Better Work Out" is the kind of cold water I think enterprise leaders need to read alongside the Airbnb success stories. Zitron has been consistently tracking the financial reality underneath the AI boom — the mismatch between capital deployed and revenue actually materializing. He is not a doomer. He is an accountant with a newsletter. And right now, the debt markets are starting to notice that hyperscalers are borrowing at a pace that assumes AI revenue will scale faster than it demonstrably has so far.

Meanwhile, SpaceX reported $14.6 billion in Q3 revenue, with 52% of income now coming from its renamed "Super Intelligence" business — Cursor, Grok, and a neocloud operation that now runs 1.7 gigawatts of compute. The Information reported that the Super Intelligence line alone generated $7.5 billion in revenue. That is a real number. But so is the $19.6 billion in capital expenditures in the same quarter, with $35-40 billion projected for the year.

The lesson for enterprise AI leaders is not "stop investing." It is: build systems that generate measurable returns, not systems that generate activity. The window to demonstrate real ROI from agentic coding is not infinite. The market is paying attention.

ACTION BYTE: Run a 90-day ROI snapshot on your current agentic coding investment. Not lines of code. Not developer satisfaction scores (though those matter). Real business outcomes: cycle time, defect rates, time-to-production. If you cannot name three numbers, that is your most urgent problem.

"I've not seen such graphs of productivity so far. It's amazing." — Stepan, Senior Staff Engineer, Airbnb Developer Platform, on agentic coding in 2025

My reaction: I believe him. And I also know that those graphs do not appear automatically. They appear at Airbnb because two engineers spent years building tools for other engineers, thought carefully about sandboxing and review and skill-level progression, and treated the rollout as a systems problem rather than a procurement problem. Most enterprises are at step one — they have the license. The engineers at Airbnb are at step five. That gap is the whole ballgame right now.

The window to close it is open. It will not stay open.

Until next Tuesday, keep navigating the AI world one bit at a time!