Exponent CI integrates directly into your development pipeline to automate repetitive tasks that traditionally slow down your team. By configuring Exponent as a step in CI, you can eliminate common bottlenecks like fixing type errors, addressing code review feedback, and updating documentation—all while your team focuses on more valuable work.
Since Exponent runs autonomously in CI, only assign it safe, trusted, and non-destructive tasks. If you’re uncertain about a task’s safety, keep it to supervised environments where you can review changes before they’re applied.
When to Use Exponent in CI
Exponent CI excels at tasks that would otherwise interrupt your development flow:
- Automated code review: Spot potential bugs, suggest performance improvements, and check adherence to team conventions before human reviewers see the code
- Self-healing pipelines: Fix type errors like missing TypeScript interfaces, linting violations, and test failures automatically. No more failed CI notifications that force you to switch contexts
- Documentation maintenance: Generate release notes, update API documentation, and keep changelogs current based on recent code changes
- Accessibility compliance: Check that UI changes meet WCAG standards and suggest fixes for common accessibility issues
- Database optimization: Identify inefficient queries, missing indexes, and N+1 query patterns that could impact performance at scale
Authentication Setup
While this guide demonstrates GitHub Actions integration, Exponent works with most CI providers. For assistance with other CI systems, contact us at team@exponent.run.
To run Exponent in CI, you’ll need to securely store your Exponent API key in your CI environment:
- Retrieve your Exponent API key from your Exponent settings page
- Add your API key as a secret named
EXPONENT_API_KEY
. Basic instructions below, or detailed steps here
- Go to the repository or organization settings for the project you want to use Exponent in
- Select “Secrets and variables” → “Actions”
- Click “New repository secret”
- Add the name
EXPONENT_API_KEY
and paste your API key as the value
- Click “Add secret”
- Retrieve your Exponent API key from your Exponent settings page
- Add your API key as a secret named
EXPONENT_API_KEY
. Basic instructions below, or detailed steps here
- Go to the repository or organization settings for the project you want to use Exponent in
- Select “Secrets and variables” → “Actions”
- Click “New repository secret”
- Add the name
EXPONENT_API_KEY
and paste your API key as the value
- Click “Add secret”
Set up a token to authenticate with GitHub
For workflows where Exponent needs to interact with GitHub (posting comments, creating PRs, etc.), you’ll need a token with appropriate permissions:
-
Create a Personal Access Token (PAT) with repo
and workflow
scopes by following the instructions here
-
Add the token as a secret in your repository by following the same process as described above for the EXPONENT_API_KEY
secret, but naming your secret GITHUB_TOKEN
.
-
Create a Personal Access Token (PAT) with repo
and workflow
scopes by following the instructions here
-
Add the token as a secret in your repository by following the same process as described above for the EXPONENT_API_KEY
secret, but naming your secret GITHUB_TOKEN
.
Example: Setting up Self-Healing Typechecking
One of the simplest ways to integrate Exponent into your CI pipeline is to add it as a step to an existing workflow.
This example workflow automatically fixes TypeScript errors without human intervention.
To implement this workflow, create a file at .github/workflows/typecheck-with-autofix.yml
with the following content, or add the relevant commented steps to an existing typechecking workflow:
Before you begin, make sure you’ve added your Exponent API key and GitHub token as secrets as described in the Authentication Setup section.
name: Exponent Typecheck Autofixer
on:
pull_request:
types: [opened, synchronize, reopened]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.12"
- name: Run TypeScript type checking
run: tsc --noEmit > tsc_output.txt 2>&1
continue-on-error: true
id: typecheck
# ^
# └ Allow the workflow to continue even if type checking fails
- name: Install exponent-run
if: steps.typecheck.outcome == 'failure'
# ^
# └ Only run this step if type checking failed
run: pipx install exponent-run
- name: Login to Exponent
if: steps.typecheck.outcome == 'failure'
run: exponent login --key ${{ secrets.EXPONENT_API_KEY }}
- name: Install and authenticate gh CLI
if: steps.typecheck.outcome == 'failure'
run: |
sudo apt-get update
sudo apt-get install gh
echo "${{ secrets.GITHUB_TOKEN }}" | gh auth login --with-token
- name: Run Exponent to fix TypeScript errors
if: steps.typecheck.outcome == 'failure'
env:
PR_NUMBER: ${{ github.event.pull_request.number }}
PR_BRANCH: ${{ github.event.pull_request.head.ref }}
BASE_BRANCH: ${{ github.event.pull_request.base.ref }}
run: |
TSC_ERRORS=$(cat tsc_output.txt)
BRANCH_NAME="fix/typescript-errors-pr-${PR_NUMBER}"
git checkout -b $BRANCH_NAME
exponent shell --prompt "Address the following TypeScript errors by examining the code, any relevant related files, and making the necessary changes: ${TSC_ERRORS}. Once you've fixed the errors, I'll create a PR with your changes." --autorun --depth 5 --headless
git add . && git commit -m "Fix TypeScript errors from PR #${PR_NUMBER}"
gh pr create --title "Fix TypeScript errors from PR #${PR_NUMBER}" --body "This PR fixes TypeScript errors found in PR #${PR_NUMBER}" --base $BASE_BRANCH
# ^ ^
# └ Exponent will analyze and fix the issues automatically └ When done, create a PR with the fixes
Example: Setting up AI Code Review
Manual code reviews create bottlenecks in your development process. Reviewers may be busy with other tasks, reviews can be inconsistent based on who performs them, and waiting for feedback delays merges and deployment.
Exponent can perform initial code reviews automatically by catching common issues, ensuring style consistency, and identifying potential bugs before a human reviewer ever sees the PR. This saves your team time and provides consistent, immediate feedback to the PR author.
Add this workflow to, for example, .github/workflows/exponent-pr-review.yml
, to run automated code reviews on all your PRs:
Before you begin, make sure you’ve added your Exponent API key and GitHub token as secrets as described in the Authentication Setup section.
# Place this file in .github/workflows/exponent-pr-review.yml
name: Exponent PR Review
on:
pull_request:
types: [opened, synchronize, reopened]
jobs:
exponent-review:
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- name: Checkout code
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.12"
- name: Install and authenticate gh CLI
run: |
sudo apt-get update
sudo apt-get install gh
echo "${{ secrets.GITHUB_TOKEN }}" | gh auth login --with-token
- name: Install exponent-run
run: pipx install exponent-run
- name: Login to Exponent
run: exponent login --key ${{ secrets.EXPONENT_API_KEY }}
# ^
# └ Store your Exponent API key as a repository secret
- name: Run Exponent for PR review
env:
EXPONENT_API_KEY: ${{ secrets.EXPONENT_API_KEY }}
PR_NUMBER: ${{ github.event.pull_request.number }}
run: |
exponent shell --prompt "Review this pull request thoroughly and critically. Look for bugs, performance issues, and maintainability concerns. Provide actionable feedback. When you're done, post a comment to the PR with your review using the gh CLI." --autorun --depth 10 --headless
# ^
# └ Customize this prompt to match your team's requirements
Best Practices
Since Exponent runs autonomously in CI, there are several things to keep in mind that are a bit different from supervised settings.
Prompts
- Be specific: Provide detailed instructions in your prompts about what you want Exponent to do
- Include context: Reference team guidelines or standards that Exponent should follow
- Set expectations: Clarify what kind of output you expect (e.g., comments, fixes, documentation)
Here’s an example of a good prompt versus a less effective one, where the good prompt is more specific and includes context:
Less Effective Prompt:
“Fix database queries”
More Effective Prompt:
“Analyze the database queries in this code and provide specific recommendations for improving performance. Check for N+1 queries, missing indexes, and inefficient joins. Reference our query optimization guide at docs/database/performance.md”
Configuration
Manage Exponent’s behavior by always including these parameters:
--depth
parameter: Controls the number of steps Exponent can take (typically 10-15, depending on the complexity of your tasks)
--autorun
flag: Enables unattended execution—essential for CI environments
--headless
flag: Optimizes for non-interactive environments
- Job timeout settings: Set appropriate timeouts based on task complexity (usually 5-10 minutes)
Security
- Protect your secrets: Always store secrets as protected secrets, never hardcode them in your workflows
- Limit repository access: When possible, scope access tokens to only the repositories they need
- Use dedicated access tokens: Create separate access tokens for CI/CD usage to limit access and make rotation easier
Responses are generated using AI and may contain mistakes.