Instruction

What ‘Agentic’ Means in Continuous Integration?

An agentic workflow is one in which an AI system is given a goal, access to tools, and the ability to take multiple steps toward that goal without continuous human prompting.

In the context of code review, the agent receives the pull request diff (and usually additional repository context), analyses the changes against project conventions or known risk patterns, and produces structured feedback. Usually inline comments, a summary, or both.

When this process is embedded in continuous integration or CI, the agent is triggered by a GitHub event, most commonly as a pull_request opened or synchronized. The runner checks out the code, gives authentication to the AI service, supplies the necessary context, and posts the agent’s findings back onto the pull request. From the developer’s perspective the review appears automatically, much like a status check from a test suite or a linter.

Note: A linter is a common name for lint checks or static code rule verification.

Therefore, the only manual parts of the process would be pushing or opening the pull request, and reviewing the findings. Everything else is automated by the agentic AI.

In practical day-to-day engineering work, this means every pull request gets a first-pass review automatically and consistently, even when teammates are in different time zones or busy with other tasks. The agent does not replace reviewer judgment, but it does reduce the amount of repetitive checking humans must perform and allows human attention to focus on architecture, product behavior, and risk trade-offs.

This arrangement differs from interactive use of the same models in three important ways:

1. The prompt and tool permissions are fixed in advance; there is no opportunity for mid-conversation clarification.
2. The agent must operate under strict time and budget constraints so that the CI job remains predictable.
3. The output must be machine-consumable enough to be posted as GitHub review comments rather than free-form chat.

Since the non-deterministic nature of large language models remains, the human reviewer is still required. The CI step simply reduces the volume of routine findings that a human must surface manually and provides a consistent baseline across every change.

To describe it another way, the workflow should be treated as a quality amplifier rather than an authority. If the agent flags a possible issue, that signal is useful and should be investigated, but merge decisions should still be made by engineers who understand feature intent, release timing, and system constraints.

Architectural Patterns for Invoking an AI Agent on a Pull Request

A reliable agentic review step rests on four pillars: event trigger, authentication, context assembly, and result publication.

The event trigger is almost always a pull_request workflow that fires on opening and synchronizing. Restricting the paths that trigger the job (for example, ignoring pure documentation changes) keeps token consumption under control. Concurrency groups prevent multiple overlapping reviews of the same pull request when a developer pushes rapidly.

Authentication is handled through the or organization secrets. For GitHub Copilot, the relevant credential is typically a GitHub token with appropriate permissions or a dedicated Copilot API key, depending on the integration method in use at the time of writing. The secret is never hard-coded; it is injected at runtime via the standard GitHub Actions secrets mechanism.

Least-privilege permissions are essential:

1. The job needs read access to the contents.
2. It needs write access to pull requests so that it can post comments.
3. It should not be granted broader repository or organization rights.

Context assembly is the most subtle design decision. At minimum, the agent must receive the diff. In practice, it also benefits from the full set of changed files (not merely the patch) and a short description of the pull request. Any repository-level guidance files, like CODE_REVIEW.md, AGENTS.md, or any project-specific style documents, assist in aligning the review with the project’s standards and review expectations. Optionally, a limited amount of surrounding sources can help the agent understand call sites or related types.

Passing the entire repository is rarely necessary and quickly inflates the token count. A pragmatic approach is to check out the repository with sufficient history, compute the diff against the base branch, and then selectively include the files that appear in the diff, plus a small set of supporting files. Some official GitHub Actions encapsulate this logic; when you build a custom workflow, you are responsible for selecting and passing the appropriate files yourself.

Result publication normally uses the GitHub API to create a pull-request review or individual review comments. Inline comments that reference specific lines are far more actionable than a single summary comment. Therefore, the agent’s output must be parsed or constrained so that file paths and line numbers can be reliably extracted - which many current integrations handle automatically.

To keep this feedback trustworthy, many teams define a simple policy for actioning comments: confirmed defects are fixed immediately, uncertain findings are discussed in-thread, and clearly incorrect findings are acknowledged and dismissed. This creates a transparent audit trail and helps the team calibrate how aggressively to rely on automated feedback over time.

Choosing GitHub Copilot as the Primary Demonstration Tool

GitHub Copilot provides a natural starting point for iOS teams already working inside the GitHub ecosystem. It offers both interactive IDE assistance and, through its pull-request review capabilities and associated Actions, a pathway into CI. The integration surface is comparatively stable, documentation is widely available, and many organizations already possess the necessary licensing.

That said, the same architectural patterns apply equally to Claude Code (via the official anthropics/claude-code-action) and to OpenAI Codex-style agents (via openai/codex-action or native Codex GitHub features). Later lessons will compare these alternatives side-by-side.

For the present lesson, the focus remains on a single, complete configuration so that the underlying design decisions are clear before additional tools are introduced.

Starting with one tool keeps the learning path concrete. You can understand trigger setup, permissions, context passing, and comment publication in one coherent implementation before comparing provider-specific differences in model behavior and token consumption. In later lessons you’ll compare different AI agents which could be fitting for CI pipeline integration - so knowing one tool will help make comparisons easier as we know what to compare to.

Token Count Considerations

Token consumption is the primary operational constraint of an agentic review. A typical iOS pull request that touches a few Swift files, a storyboard or SwiftUI view, and a modest amount of supporting code might generate a few thousand to a few tens of thousands of tokens. Depending on how much surrounding context is supplied and which model is selected.

As a rough order-of-magnitude guide:

Note: Extremely large diffs or aggressive inclusion of the full repository context can push the token count too high for routine use.

The important principle is transparency: Every lesson that invokes an AI agent should surface an estimated token count so that learners develop an intuition for how large a review actually is.

In production, you’ll typically factor in token-budget caps, timeout limits, and the ability to skip reviews for draft pull requests or changes matching specific path patterns.

Setting up the AI Tools Used in This Module

Earlier modules covered Claude Agent within Xcode and Cursor external to Xcode. The agents in this module run in GitHub Actions, so they need their own accounts and repository secrets. You do not reuse the Xcode Claude Agent or Cursor setups here.

This lesson — GitHub Copilot pull_request review. First, enable Copilot for the GitHub account or organization that hosts the sample repository, and then add the Copilot or GitHub credential as a repository secret. This is the pull-request review product and, not the Copilot Xcode extension. You can follow GitHub’s current Copilot code review documentation to enable it; as the demonstration only wires the workflow.

Later lessons — Claude Code Action and OpenAI Codex Action. These are CI agents, not the Claude-in-Xcode chat from earlier in the program.

• Claude Code: Create an Anthropic account, then store an API key (ANTHROPIC_API_KEY) or OAuth token as a repository secret. Official action: anthropics/claude-code-action. Setup notes live in the Claude Code GitHub Actions documentation.
• Codex: Create an OpenAI account, then store an API key (OPENAI_API_KEY) as a repository secret. Official action: openai/codex-action.

Note: For storing API Keys as a GitHub repository secret, see GitHub’s documentation. You’ll create the upcoming lessons secrets before that lesson’s demonstration. The pattern is the same for every tool: account, secret, and workflow.

Preparing the Starter Project

The demonstration uses the same starter project used in earlier modules. The repository is assumed to contain a working GitHub Actions workflow directory and to be configured with the necessary secrets.

You’re encouraged to follow along and try out the practical for yourself, but before you begin, ensure that:

• The repository is hosted on GitHub.
• GitHub Actions are enabled.
• The Copilot setup from the previous section is complete, including a secret (a property in GitHub repository settings) that holds the required Copilot or GitHub credentials.
• The default branch is protected or at least monitored so that you can open a realistic pull request.
• You can use any editor, however, this module’s demonstration uses Visual Studio Code. Visual Studio Code is configured with GitHub using extensions.

It is also helpful to prepare a small, intentional code change in advance (for example, a tiny refactor or a validation fix). Using a focused change set makes the first run easier to interpret because the resulting AI comments are directly attributable to a narrow diff rather than a large mixed update.

With the conceptual foundation in place, the next section demonstrates the concrete steps required to wire GitHub Copilot into the pipeline and to observe the resulting review comments.