Careem's AI Agent Writes and Tests dbt Models Before Humans Review Them

A backlog and a failed first attempt

Careem runs ride-hailing, grocery delivery, food delivery and remittance. Its data engineering team is lean and supports more than 5,000 models. The stack is built in-house and runs on open source from ingestion through transformation to BI, with dbt handling transformation.

In a dbt Summit 2026 breakout session, Niyazulla Khan Pathan, engineering manager for the data platform team, and Akash Srivastava, lead software engineer on the same team, described a backlog of over 100 pending data requests. Each used to take one to two weeks to answer.

The first fix was to point an LLM at the problem and let it write models. According to the session, that failed. A human reviewer who skims AI-generated code for patterns, rather than reading every line, can miss the one corner case that breaks a pipeline and damages the business's trust in the numbers.

"Confidence comes from validation, and not really from the code generator," Srivastava said.

Four pillars built around validation

That principle shaped a four-pillar agent architecture.

• Context layer: built on open metadata, it gives the agent table and column-level documentation, lineage, a glossary of internal terms like AOV and GTV, and centralized metric definitions.
• Spec locking: the agent must ask clarifying questions about grain, metric definition and filters before writing anything. At Careem, "revenue" alone could mean GTV, GMV or order count, so the agent now asks which one is meant.
• Golden and transient layers: the golden layer is reserved for fully governed, federated metrics. The transient layer holds one-off analyst requests, which get a 30-day lifespan before promotion to a data mart or automatic cleanup. The team cleared out 3.6 petabytes of transient data in the last year.
• Structural guardrails: every agent-generated change is isolated in a sandboxed dev environment with separate IAM roles, storage paths and compute, so the agent cannot touch production.

On top of this sits an agent loop that compiles, tests and materializes each change. It catches failures such as type mismatches and fixes them until the run succeeds, all before a human reviews the pull request.

The live demo

In the demo, an analyst typed a plain-English request: "I want a daily food revenue for each merchant." Within minutes the system produced a fully tested, documented dbt model and a pull request.

The first sandbox run failed on a data type mismatch. The agent read the error, corrected it and reran. The second run failed because a needed column was in a different source table. The agent used the context layer to find it, joined it in and reran. Only after a clean run did the pull request go to a human.

The automated checks went beyond standard dbt tests. They verified that data moved correctly from bronze to silver to gold and validated the model's storage location against Careem's domain conventions.

Results and what it means

Careem reports that metric delivery time dropped from two to three weeks to hours. Roughly 90% of new models at Careem now come out of the framework, and there have been no sev0 or sev1 incidents since the process was introduced.

The team also added duplicate-request protection. Because every change runs through the dbt manifest, a second request for a column that has already been added is redirected to the existing model rather than creating a near-identical one.

The timeline was short. Careem started evaluating dbt in December, had the full infrastructure built by March and had the agent live by April or May. The legacy warehouse migration took only a few additional weeks.

For data teams weighing AI-generated code, Careem's account points to where the effort went: the checks around the generator. As Pathan put it in closing the talk: "The generator is easy. The validation layer is the product."