Engineering brief
Letting AI approve low-risk PRs cut Duolingo's median merge time
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
- Identify which PR categories already get rubber-stamped by reviewers before building any AI approval flow.
- Add a Slack channel and eval set for agent misclassifications, and make fixing the prompt a weekly maintenance task.
- 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
AI war rooms can crack legacy code, GEICO's $1,000 day shows
GEICO's $1,000 AI war room mapped legacy claims domains in a day. The deciding factor was human approval gates, not model choice.
The next AI bottleneck is governance, not individual developer speed
Don Syme wants agents running continuous maintenance inside GitHub Actions. The promise is a self-tending repo. The catch: cost, guardrails, and who approves…
Agent loops run by themselves; comprehension debt is the new bottleneck
Loop engineering automates prompting, but agents still need human goals, documented intent, and review. Comprehension debt is the part most teams will miss.
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.