Bio, Work & Ideas
Kush Agrawal
On this page
Kush Agrawal designed and shipped Duolingo’s autonomous test-generation pipeline, which takes agent-written tests through pull requests, CI, automated review, and human approval. A staff software engineer working on developer tooling and AI-assisted workflows for Duolingo’s iOS platform team, Kush supports an engineering organization of more than 100 engineers. His work addresses a concrete challenge: adding tests to an application with nearly 1.8 million executable lines without leaving engineers to shepherd every generated change manually.
Kush previously worked at Stripe and Uber and holds a B.S. in electrical engineering and computer sciences from UC Berkeley. His earlier mobile engineering work included building and launching mobile applications at Stripe and leading Uber growth projects involving cash payments and PIN-based dispatch. At Duolingo, his focus includes the infrastructure other engineers use to change a large iOS application.
Giving coding assistants a structure to follow
In his writing on AI-assisted Swift development, Kush treats a coding assistant as knowledgeable about the language but unfamiliar with an application’s constraints. He recommends defining requirements, asking the assistant to restate its understanding, and reviewing its proposed implementation before it generates code.
His skeleton files make architectural decisions tangible: developers create protocols, empty classes, and minimal views that establish where responsibilities belong, then let the assistant fill them in. The engineer decides how the pieces fit together before delegating their implementation. Kush describes using AI while adding a SwiftUI file-watching panel to an older AppKit application, an example where the generated code had to fit an existing application structure.
His work with repository instructions addresses what the assistant needs to know during that process. He favors task-specific rules selected when relevant, so each interaction does not require the entire repository’s engineering guidance. That approach brings its own maintenance burden: different assistants need overlapping documentation, and someone must keep the instructions useful.
Kush also calls for evaluation for coding rules. He wants to know whether an instruction increases code acceptance, whether revising it makes results worse, and which rules actually improve outcomes. Writing more guidance is only useful if engineers can assess its effect.
Carrying generated tests through review
Duolingo’s test-generation system puts these questions into practice. Scheduled Temporal workflows select untested code, Claude Code agents open pull requests, and a lifecycle manager monitors CI, attempts to repair failures, and runs AI review. Humans provide final review and approval before changes merge.
Duolingo reports merging 250 generated test pull requests containing approximately 85,000 lines of tests, increasing coverage of core model-view-viewmodel components from 9% to 30%. Those results describe a collaborative engineering effort: Kush designed and shipped the pipeline, while the team contributed supporting infrastructure and changes that made the application easier to test.
One obstacle was a dependency on a concrete client that prevented repository classes from accepting mocks. The team changed those classes to depend on a protocol and added a lint rule to preserve that design. This improved the code’s testability and gave future generated tests a workable way to substitute dependencies.
The pipeline then exposed another constraint: reviewer bandwidth. Producing tests faster could outpace engineers’ ability to assess them. Human approval remained part of every merged pull request, making review capacity a practical limit on throughput. Kush’s September 2026 session also describes the team using the same workflow structure for additional migrations across Duolingo.