Years to Months: How Engineering Processes, Teams, and Leadership Are Evolving Around AI Agents | May 10, 2026

A company-wide suspensions platform - cross-org, compliance-sensitive, and touching dozens of service teams - we shipped in a matter of months. A core system woven through every service at the company - we deprecated in two months. An agent that went rogue, deleted a company’s production database, and covered it up.¹ These are not unrelated stories. The first two are wide-scope, cross-functional initiatives which were scoped at a year but were completed in a matter of months, the first using a fleet of AI agents working in parallel with human review, and the second using AI agents across every step of the process, from authoring to review to coordination. On the other hand, the third story is one of many coming from industry of what can go wrong when using AI agents. Coding got cheaper, but deciding what to prioritize and verifying it was built correctly became all the more important.

I have seen four aspects evolve significantly over the past year, more than across the decade before it, while leading engineering teams and building distributed systems at scale: the constraints on engineers, the design of teams, the mechanisms those teams run on, and the job of the person leading them. What follows is what changed, and how the teams adapting best are responding.

• The constraints on engineers changed. With generation cheap, the constraints became judgment, verification, and alignment.
• Team design is evolving. Senior-heavy, agent-backed pods working towards end-to-end outcomes.
• Team mechanisms are evolving. Increasing autonomy for agents, guardrails as code, agent-to-agent review, data infrastructure and eng tooling even more important, monitoring as the safety net, measurement focused on outcomes.
• The EM role is evolving. Context, selective depth, systems, traceability, influence without authority are even more important.

Delivery and Taxi Transportation Platform with Gig-Economy Marketplace eBook | February 27, 2021

Designing a Delivery and Taxi Software Platform

The sharing economy has given rise to a wave of new online multi-sided marketplace apps and business models, where consumers and sellers are matched across a unique, differentiated set of products and services. In this series, we will explore the applications, domains, and software subsystems applicable to a wide variety of transportation use cases – from restaurant and grocery delivery (e.g. DoorDash, Instacart), to taxi and rideshare services (e.g. Uber, Lyft), to third-party deliveries and shipments (e.g. Shipt, Convoy, Uber Freight).

Specifically, we will design a three-sided gig-economy marketplace and transportation software platform that matches:

• Customers, making purchases and requesting rides
• Third-party vendors, including merchants and taxi services
• Gig-economy drivers, delivering goods and people

A range of transport timeframes will be supported – from same-hour to several days out. Drivers can choose to schedule work in advance to guarantee sufficient working hours or work on-demand for maximum flexibility, obtaining work in real time. Multiple competing goals must be balanced: low-latency, cost-efficient fulfillment with accurate ETAs for customers; consistent, high-availability delivery and transport for vendors; and fairness, transparency, and flexibility for drivers.

We will explore the platform’s end-to-end architecture, including:

• Product flows across web and mobile apps
• Backend systems, APIs, and event-driven services
• Core domain models, such as order management, route planning, dynamic pricing, ETA prediction, driver-route targeting and matching, forecasting, and payments
• Infrastructure strategies, such as horizontal scaling, observability, reliability, multi-region fault isolation, service discovery, networking, and security
• Machine learning services for forecasting and optimization
• Technical analysis of design patterns, consistency models, data modeling, and technology choices

The Economics of Multi-sided Market Design and Matching Theory | January 11, 2021

Market Design is the economic study of designing marketplaces to achieve specific desired outcomes using different mechanisms or rules. Auction Theory, Matching Theory, and Game Theory are related areas of study, with Auction Theory focusing on using prices to influence market outcomes, Matching Theory focusing on finding the maximal outcome of pairs of mutually-interested participants in a market, and Game Theory focusing on optimizing decision-making of independent competing actors. Marketplaces are distinct from centralized planning in that the market participants themselves make the decisions as opposed to a centralized planning system making the decisions. Marketplaces can be seen everywhere in our lives from in nature in how animals mate, to the traditional stock exchange clearinghouse where a buyer and seller are matched at an optimal price point, to auctions like that of radio spectrum to telecom providers, to modern online job boards, websites like Ebay, Amazon, Craigslist, and Airbnb, and gig-economy apps likes DoorDash and Uber.

We’ll go over Market Design and Matching Theory, four historic examples, what causes markets to fail, and finally the principles of good Market Design.

Software Architecture - Mapping, Navigation, and ETA System | January 2, 2021

Mapping and navigation functionality is all around us today, from dedicated applications such as Google Maps and Apple Maps to applications with built-in mapping capabilities like Uber, Lyft, Yelp, and DoorDash. These applications provide users the ability to see where they are located, their surroundings, geographical search functionality, and often both the route to a given location and an estimated time of arrival (ETA). The technology to support this geospatial functionality is complex and specialized. Here we will design our very own mapping, navigation, and ETA software solution supporting billions of users and hundreds of millions of points of interest.