AI Agent for Automated Feature Flag Removal
duolingo · Education · 2025 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.2 (schema v2)
Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.
Problem
Domain: Software maintenance automation
Duolingo wanted to remove obsolete feature flags without repeatedly spending engineer time on routine code cleanup.
Constraints:
- repo-local code changes
- PR creation
- non-deterministic agent failures
- rapid internal deployment
Architecture
Duolingo built the feature-flag remover as a Temporal-orchestrated coding-agent workflow. A Platform Self-Service UI starts a gateway workflow, which dispatches a feature-flag-removal worker. The worker resolves the requesting user’s GitHub account, clones the target repository into a temporary local directory, invokes Codex CLI in full-auto/quiet mode inside a sandboxed ECS/Temporal setup, and creates an assigned pull request when code changes are found. Temporal supplies local testing, retries, and workflow composition for future coding agents.
Diagram confidence: explicit (topology described by the source).
flowchart LR platform-self-service-ui[Platform Self-Service UI] --> gateway-workflow[Gateway workflow] gateway-workflow --> feature-flag-removal-worker[Feature flag removal worker] feature-flag-removal-worker --> github-account-lookup[GitHub account lookup] feature-flag-removal-worker --> repository-clone-activity[Repository clone activity] repository-clone-activity --> codex-cli-activity[Codex CLI activity] temporal-retry-layer[Temporal retry layer] --> feature-flag-removal-worker temporal-retry-layer --> codex-cli-activity codex-cli-activity --> pull-request-creator[Pull request creator] github-account-lookup --> pull-request-creator
Components
| Component | Role | Interacts with |
|---|---|---|
Platform Self-Service UI |
Internal page where engineers start automated feature-flag cleanup. | Gateway workflow |
Gateway workflow |
Temporal dispatcher namespace workflow that kicks off the feature-flag-removal worker. | Platform Self-Service UI, Feature flag removal worker |
Feature flag removal worker |
Main Temporal workflow coordinating user lookup, repository clone, Codex execution, and PR creation. | Gateway workflow, GitHub account lookup, Repository clone activity, Codex CLI activity, Pull request creator |
GitHub account lookup |
Activity that resolves the requester so the resulting PR can be assigned correctly. | Feature flag removal worker, Pull request creator |
Repository clone activity |
Clones the repo to a temporary local directory for local code operation. | Feature flag removal worker, Codex CLI activity |
Codex CLI activity |
Runs Codex CLI as a full-auto quiet subprocess to edit the cloned code. | Repository clone activity, Pull request creator |
Temporal retry layer |
Handles non-deterministic agent failures such as crashes, no changes, hangs, or incomplete runs. | Feature flag removal worker, Codex CLI activity |
Pull request creator |
Creates a GitHub PR and assigns it to the requesting engineer when changes are found. | Codex CLI activity, GitHub account lookup |
Data flow
An engineer launches cleanup from an internal self-service page. The gateway Temporal namespace starts the feature-flag-removal workflow, which first gets the user’s GitHub account, then runs the main work activity. That activity clones the repository locally, asks Codex CLI to remove the feature flag, and if changes exist creates a pull request assigned to the requester.
3 supporting quotes
Why this architecture
Duolingo chose this shape because coding agents operate well on local code, while normal GitHub access can happen outside the AI call. Temporal made rapid prompt iteration and retries practical for non-deterministic agents. Keeping clone, agent work, and PR creation together avoided worker-locality problems where a later activity might run on a different machine without the cloned code.
3 supporting quotes
Models used: Codex CLI model
Scale
- The team moved from chosen stack to prototype in about one day and production in about one week.“Once we settled on our tech stack, we had a prototype running in ~1 day, and a productionized version in ~1 week.”article, stated
- The initial implementation expanded from a Python-only prototype to also cover Kotlin.“Much of the week was spent on prompt engineering and feature development (such as extending the Python only prototype to also cover Kotlin), with the rest figuring out reusable patterns.”article, stated
- The pattern is intended as a reusable foundation for future Duolingo agents operating on code.“we wanted to start figuring out patterns for building additional agents that operate on our code.”article, stated
Alternatives considered (roads not taken)
Separate clone, agent operation, and PR creation into reusable Temporal activities
Rejected because: Separate activities may run on different workers, so the agent could lack the cloned code.
Continue LangChain/fast-agent implementations
Rejected because: Codex CLI accepted their merged prompt and worked quickly after one to two weeks of alternative toolchain development.
Wait for a formal Codex SDK
Rejected because: Running Codex CLI as a Python subprocess was good enough to ship without waiting.
Patterns
durable-execution (orchestration)
Temporal provides local testing and retry behavior for nondeterministic agentic cleanup workflows.
tool-use-orchestration (software-engineering)
The agent operates on local code in a cloned repository, then standard tooling creates the pull request.
Tradeoffs
Which agent integration to use.
Chose Codex CLI as a subprocess over waiting for a formal SDK or continuing bespoke LangChain/fast-agent builds.
Rationale: The CLI worked quickly enough to ship despite being less ideal than an SDK.
Temporal activity boundaries.
Chose keep clone, agent operation, and PR creation in the main work path over splitting clone and agent work into separate reusable activities.
Rationale: Temporal worker locality means the cloned repository might not exist where a later activity runs.
Agent integration maturity.
Chose Codex CLI subprocess now, SDK later over waiting for a formal SDK before shipping.
Rationale: The CLI was less deterministic and less ideal than an SDK, but it worked quickly enough to productionize the tool.
Gotchas (what bit them)
Splitting clone/agent/PR work into separate Temporal activities can break local workspace assumptions.
Root cause: Temporal may schedule each activity on a different worker, so the cloned repo may not exist where the agent runs.
Resolution: Keep clone, agent operation, and PR creation in one activity where local filesystem state is preserved.
Evaluation
The post reports implementation speed and production readiness rather than formal accuracy metrics.
Metrics: prototype in one day · production in about one week
Outcomes
- Duolingo shipped a reusable agent pattern for future code-infrastructure agents.
This is a narrow internal automation, not broad autonomous development.