Engineering brief

Letting AI approve low-risk PRs cut Duolingo's median merge time

InfoQ3 min read · saves 37 min

At a glance

The brief is enough

Relevance
Practical value
Radar
Time horizon
This year
Warnings
None

Duolingo let an LLM approve roughly 10% of PRs and median merge time dropped from 18 to 12 hours. The catch: AI literacy, tight guardrails, and a human feedback loop did the work, not the model.

AI can take over low-risk engineering workflow steps safely if guardrailed, but organizational readiness and feedback loops matter more than the model.

Watch if you're designing an autonomous AI code-review or merge workflow and want a production example with guardrail decisions.

Summary

The signal. Duolingo's DevEx AI team runs an LLM-based PR risk assessment in production. Every pull request is scored low, medium, high, or undetermined from title, verification steps, diff, and risk definitions. Low-risk changes that pass repo config get auto-approved by a bot, merging with no human reviewer. Roughly 10% of all PRs now merge this way, and median time to merge across the org dropped from about 18 hours to 12 hours over six months.

The guardrails. The system is deliberately conservative. Low risk covers markdown, small straightforward changes, and routine config updates. Medium and high risk catch API version bumps, auth, logging, permissions, infrastructure, and core features. Repo config can restrict the bot to code owners, exclude directories, disable AWS changes, skip compliance-heavy repos, and block new engineers during onboarding. Eligible authors can still opt out and request human review.

The precondition. Training came before automation. Duolingo ran lab-style workshops, built AI observability dashboards tracking usage, cost, and models by team, held office hours, ran a Slack channel and bi-weekly meetups, and used vendor relationships for early access to Cursor features like team rules. AI tool adoption went from 80% to 100%. That literacy changed behavior: engineers reported misclassifications to a Slack channel instead of rejecting the bot.

The feedback loop. Wrong risk labels flow into a dedicated Slack channel, become an eval set with expected labels and keyword extraction, and are used to fine-tune the risk prompt. The prompt grows with developer feedback and stays backwards compatible. A couple of messages per week is the maintenance load. This loop is what makes the system trustworthy, and it depends on engineers being willing to engage with the model rather than fear it.

The missing data. There is no strong defect-rate signal. Sarah says about 200 PRs flow per day and one or two auto-approved changes get reverted, which is hard to compare with normal human-review outcomes. She also says the bot has not, to her knowledge, been involved in a site incident. That is reassuring, but it is not a controlled comparison showing automated low-risk approvals are as safe as human ones.

The real takeaway. The cascade effect matters most: accelerating the easy 10% lowered median merge time for all PRs, freeing reviewers for riskier work. The project pivoted Meta's diff risk score: instead of gating risky changes, Duolingo removed friction for safe ones. Copy the flywheel, not just the bot: find changes people already rubber-stamp, guardrail a conservative classifier, and create a visible correction channel. The bot is the last step, not the first.

My take

The useful part of Duolingo's story is the ordering: literacy, observability, guardrails, then automation. Too many teams start with the agent and discover trust, accountability, and misclassification problems later. I'd be careful with the headline metric, though. A 10% auto-approval rate that cuts median merge time by six hours is promising, but without defect-rate or rework comparison, it is not proof that the bot is safe. It is proof that low-risk work was already being rubber-stamped by humans. I'd copy the feedback loop and the narrowing rules before copying the bot itself. That is where the durable engineering value sits.

What to do with this

  1. Identify which PR categories already get rubber-stamped by reviewers before building any AI approval flow.
  2. Add a Slack channel and eval set for agent misclassifications, and make fixing the prompt a weekly maintenance task.
  3. Define your guardrail list before rollout: code owners, directory exclusions, compliance repos, AWS changes, and onboarding blocks.

Watch the video

This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.

Related breakdowns

Get TL;DW

Too Long; Didn't Watch.

A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.

Free. Weekly. No hype.

Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.