[2/2] Agentic coding at Airbnb (Agents column)

In the past. post We stopped at the fact that the guys from Airbnb had three goals when implementing the agency approach to development, and now it is interesting to see how they went to them.

In order to realize the first goal, namely "bring agents to Airbnb", they built Air Chat - an abstract wrapper over several engines. This gave a single entry point: you can quickly roll out new CLI agents and updates without tying the entire platform to a single vendor or tool. They went on to MCP very early because the standard was close to their existing tool-calling approach. As a result, Airbnb was able to: wrap favorite IDE tools in the MCP server, embed MCP clients in IDE plugins, and the configuration and synchronization of servers centralized through Air Chat CLI. Over time, it has grown into an ecosystem with more than a dozen internal MCP servers, including analytics and CI tools.

In order to realize the second goal, namely “bring Airbnb knowledge to agents”, they changed their approach to working with the knowledge base. (knowledge base). They used to have a linear one-shot schema: query → knowledge endpoint → answer. It worked poorly for the agent regime. But they decided not to play with modeling. (fine-tunning) as the main way, but just wrapped up obtaining knowledge from the knowledge base (knowledge base) In MCP, agents were then allowed to iteratively refine the information: if the first answer didn’t fit, the agent refines the search, changes the terms, and does deeper research inside your internal knowledge.

They also described how they tried to build their own multi-agent orchestration model with planning/coding/validation agents, but the market moved too fast and the small team did not have time to build the necessary muscle. So Airbnb didn't go with "we have to write our own orchestrator," but instead took a pragmatic turn. (pivot)The main agent now lives as a CLI-agent, and on top it has a thin pad for other surfaces. It's cool that the guys were honest about their decision - often NIH syndrome. (Not Invented Here) does not allow to make such a decision or even if it is made, it does not allow to tell about its adoption:)

And if you take the kids out of their way, they’re like this.

1. Agentic coding is not just a chat in an IDE, it is a new inner loop, where the agent repeatedly pulls the LLM, tools and internal knowledge, and at the output brings code that still needs to be viewed by a person before PR.
2. Growth comes not only from the agent’s auto-approve setup, but from the engineer’s ability to manage multiple parallel workspaces; on Airbnb, some advanced users open up to five agent sessions at a time.
3. The agent does not solve anything by itself: around him you need sandbox / workspace infrastructure, auth, security paved path, templates, installation in one team and a normal review culture.
4. And the organizational conclusion of the guys is: do not break the existing habits of teams for the sake of fashionable AI UX. The idea of “let’s move all IntelliJ users to VS Code because it’s better agentic tooling” quickly failed. Instead, remove barriers, meet developers where they already work, and standardize only what is truly stabilized in the marketplace. At the same time, the quality should not be omitted “because it is AI”: the standards remain the same, the review is mandatory, the code must also be ready for sale, and it is dangerous to use auto-approve without a stuffed hand.

In general, the main idea is not to buy the best AI assistant. (Claude Code, OpenAI Codex, Cursor, choose your favorite)It's about putting together a well-trodden path around agents: surfaces to interact with, access to knowledge, challenge tools, standardization, measurement, and human review. And only then wait for the real increase in key metrics of development, not the local wow effect.

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign