Skip to content
Frontier Docs

How we build

Frontier’s development process combines advanced automation with human oversight to maintain code quality, accelerate delivery, and foster a shared knowledge base. Our system leverages AI agents to handle routine tasks and provide continuous feedback, while critical decisions and final quality gates remain firmly under human control. This approach ensures high standards without sacrificing developer velocity.

Automated Code Review and Quality Gates

Section titled “Automated Code Review and Quality Gates”

Frontier maintains robust code quality through a layered approach to review and quality assurance, blending automated checks with human judgment.

Automated Reviewers

Section titled “Automated Reviewers”

Multiple AI-powered review bots are integrated into the pull request (PR) workflow, providing continuous, advisory feedback:

  • Claude Code Review: An autonomous CI workflow running on AWS Bedrock (using the Sonnet model) provides per-PR reviews. It posts a sticky summary and inline comments but is advisory and non-blocking. This review respects the review:paused label, which suppresses AI review during human iteration.
  • Qodo/PR-Agent: This tool reviews human-authored PRs via a GitHub App. A separate workflow (qodo-review-bots.yml) runs Qodo on bot-authored PRs (which the App skips), also utilizing a Bedrock Sonnet model.
  • CodeRabbit: Run locally as part of the prepare-pr quality loop (rather than as a hosted PR bot in our flow) — its findings are expected to clear before a PR is opened.
  • Other AI Reviewers: Bots like Aikido, BugBot/Cursor, and GitHub Copilot contribute additional advisory feedback, with their comments aggregated by the pr-fix workflow.

For on-demand, human-gated AI review, a separate Claude Code workflow can be triggered by mentioning @claude in a comment, review, or issue body.

Required Quality Gates

Section titled “Required Quality Gates”

The GitHub native merge queue enforces a strict set of required CI checks, and a PR must pass all of them before it can be merged to main. These five categories of checks are the only automated gates that directly prevent a merge:

  • Lint: Enforced by Biome (for both formatting and linting) and OXLint. Type-aware linting is mid-rollout — enabled on parts of the codebase and expanding toward full --type-aware coverage. Includes an advisory ‘clean-on-touch’ pass over changed files.
  • Type-Check: Ensures type safety across the monorepo.
  • Test: Runs the test suite to validate functionality. For efficiency, type-check and test jobs are incremental (--affected) on PRs, but the full suite runs in the merge queue and on push to main as the final safety net. A check-relevance gate can fast-skip heavy jobs for docs/config-only PRs.
  • Check Unused Code: Identifies and blocks merges with unused code.
  • Check Circular Dependencies: Prevents problematic circular dependencies in the codebase.
  • Complexity: Cognitive complexity is enforced locally via Biome’s noExcessiveCognitiveComplexity (maximum 15) at an error level, causing bun check and the lint CI to fail. Agents are instructed to target <=10 for new code.

Advisory Quality Gates

Section titled “Advisory Quality Gates”

Beyond the required gates, several other quality checks provide important, non-blocking feedback:

  • SonarQube: Performs full-coverage analysis when a human applies the sonar-requested label to a PR or as a required hard gate within the merge queue. It is not run on every PR push.
  • CodeQL: Provides security static analysis as an advisory policy gate.
  • Coverage Ratchet: An advisory check for new code coverage (targeting >=80%), which posts a comment but currently does not block merges (tracked as FRO-780).

Pre-PR Local Quality

Section titled “Pre-PR Local Quality”

Before a PR is even opened, developers utilize local quality tools:

  • The prepare-pr skill implements a mandatory local quality check loop, involving both an automated code-reviewer agent and CodeRabbit, which must pass with zero findings.
  • The bun pr-ready command locally runs pre-commit checks, sonar:check-pr, and bugbot:check-all.

Emphasis on Human Gates

Section titled “Emphasis on Human Gates”

Despite extensive automation, human judgment is paramount:

  • All AI reviewer feedback (from Claude, Qodo, Aikido, BugBot/Cursor, Copilot, CodeQL, CodeRabbit, and Blocks) is advisory and explicitly filtered out of shepherd’s merge-readiness decision by ruleset. Only the mechanical CI checks described above are hard gates.
  • The review:paused label acts as a hard shepherd enqueue guard, preventing any PR from merging while it’s paused for human iteration or review.
  • Enqueueing a PR for merge explicitly requires user approval.
  • Any use of bypass flags (e.g., --force, --skip-checks, --skip-triage) with shepherd commands requires a mandatory --reason, and an audit-trail comment is automatically posted to the PR.
  • Agent-authored PRs typically land as drafts, requiring human review before they can be marked “ready for review.”
  • CHANGES_REQUESTED bot reviews (a hard policy enforcement) necessitate a shepherd dequeue, fix, and re-queue cycle.

The Shepherd Orchestration System

Section titled “The Shepherd Orchestration System”

The @frontierx/shepherd CLI is the core of Frontier’s PR pipeline orchestration, managing the lifecycle of pull requests and coordinating with GitHub’s merge queue.

PR Pipeline Stages

Section titled “PR Pipeline Stages”

shepherd classifies each open PR into a distinct pipeline stage: TRIAGE, FIX, CI_WAIT, VERIFY, QUEUE, MERGE_QUEUE, and MERGED. An additional MERGE_QUEUE_EJECTED stage handles PRs removed from the queue. This system aggregates feedback from various review tools (bots, CI annotations, issue comments) into a single triage manifest, which shepherd uses to determine the current stage and any blocking reasons.

Merge Order Planning

Section titled “Merge Order Planning”

The shepherd plan command helps prioritize merges by computing a recommended merge order. It uses a scoring heuristic based on factors such as Linear project priority, PR age, file-overlap isolation (how much a PR conflicts with other open PRs), and PR size. It also reports pairwise file-overlap conflicts between PRs.

Enqueueing and Safeguards

Section titled “Enqueueing and Safeguards”

The shepherd enqueue command integrates with GitHub’s merge queue using gh pr merge --auto. This action is protected by a series of guards:

  • Hard Guards: These cannot be bypassed and automatically reject draft PRs, those with a ‘do not merge’ or review:paused label, PRs already in the queue, or those previously ejected.
  • Soft Guards: These checks (such as failing/pending required CI checks, merge conflicts, unresolved inline comments, or error annotations) can be bypassed for specific reasons using --force or --skip-checks/--skip-triage flags. However, a mandatory --reason must always be provided, and an audit-trail comment is posted to the PR for transparency.

Autonomous Fixes

Section titled “Autonomous Fixes”

For PRs classified into the FIX tier, shepherd dispatches general-purpose pr-fix sub-agents to run in pre-created Git worktrees. These agents autonomously execute a full pr-fix workflow, which includes rebasing, local fixing/linting/type-checking, applying bot suggestion patches verbatim, and pushing changes with force-with-lease. Worktrees are created sequentially to prevent git worktree add corruption.

Merge Queue Robustness

Section titled “Merge Queue Robustness”

The shepherd system is designed to absorb and manage recurring merge-queue flakiness. This includes handling issues like SonarCloud memory errors (which required deleting node_modules before Sonar scans in the CI) and frequent ‘re-trigger CI after merge queue ejection’ events. The MERGE_QUEUE_EJECTED stage and rerun-ci capability allow shepherd to manage these operational challenges automatically.

Knowledge and Memory Systems

Section titled “Knowledge and Memory Systems”

Frontier leverages advanced systems to build, manage, and continuously enrich its codebase knowledge and developer memory.

Graphify

Section titled “Graphify”

On every push to main, a CI job for graphify regenerates a knowledge graph from the codebase. This process involves three phases: an AST-only refresh (which is free), incremental Gemini enrichment for only new or changed non-code files (such as documentation or images), and a wiki export. The resulting graph is published to an orphan graphify-graph branch and as a 30-day artifact. Engineers can pull the latest graph locally using bun run graph:sync. This knowledge graph serves as an authoritative, code-derived source for agents and developers querying architecture or symbol definitions, prioritizing it over direct code grepping.

Supermemory

Section titled “Supermemory”

Supermemory serves as the dev-agent memory layer, storing prior decisions, plan context, and session-specific information from agent interactions. This system is explicitly separate from the product’s customer-facing knowledge base. Isolation is achieved through distinct containerTags (a repo_frontierx project tag combined with a per-checkout personal claudecode_project_* tag) and separate API keys for agent memory versus the product KB.

Learnings Store

Section titled “Learnings Store”

A continual-learning Stop hook implements a self-improving feedback loop for our agents. After specific thresholds are met (e.g., at least 10 completed agent turns, 120 minutes since the last run, or significant transcript advancement), this hook triggers a sub-agent. This sub-agent extracts durable learnings from the current session transcript, writes them to a learnings.jsonl file in a separate, auto-committed Git repository, and then pushes these learnings to Supermemory’s repo_frontierx via bun learnings:sync. This continuously enriches the shared developer memory with real-time insights from agent interactions.