The previous five pillars built an engineering system: a repository, a review process, automated delivery, and the controls that make the whole path defensible.
This pillar adds a participant to that system. Not a replacement for any part of it — a participant, which can read the repository, propose changes, run commands, open pull requests, and review other people’s code.
The question the pillar answers is not “can AI write code”. It is:
Start with AI + GitHow do you put an AI assistant — or an autonomous agent — inside an engineering process without weakening the process?
Continue to Git for DevOps & Infrastructure
Section titled “Continue to Git for DevOps & Infrastructure”You have learned how GitHub Copilot and AI agents can operate inside repository workflows — shaped by instructions, bounded by tools and permissions, and reviewed by people who remain accountable.
The next pillar applies Git engineering to infrastructure itself: Terraform and OpenTofu repositories, container source and image identity, Kubernetes and GitOps reconciliation, Ansible automation, and the repository architecture platform teams build on. The same distinction carries over — configuration shapes, and permissions, policy and reconciliation enforce — with a higher cost of being wrong, because an infrastructure commit can change networks, delete data and take services offline.
Continue to DevOps & InfrastructureWhere AI sits in the lifecycle
Section titled “Where AI sits in the lifecycle”A vertical chain: repository, AI context, developer intent, plan, code changes, tests, Git diff, AI and human review, pull request, CI/CD, merge. AI participates in the middle of a loop whose ends are unchanged.
Read the top and bottom of that chain. The repository is unchanged and the merge policy is unchanged. AI operates in the middle, and everything it produces arrives as a Git diff that has to survive the same tests, the same review and the same rules as a diff a person typed.
That framing is the whole pillar, and it is why this material sits after Git Security & DevSecOps rather than before it. An organisation that has not decided what its merge policy is has nothing to hold an agent to.
The central principle
Section titled “The central principle”AI can accelerate engineering work. Repository policy, tests, code review, security checks and human judgement remain the controls that decide whether the work is correct.
This is not caution for its own sake. It follows from a specific property of the technology:
An AI system produces output that looks like the output of understanding. A human who does not understand a codebase writes code that looks confused. A model that does not understand a codebase writes code that looks confident. The usual signal that something is wrong is absent, which means the signal has to come from somewhere else — and “somewhere else” is tests, review and CI.
A worked version of the same point, which recurs throughout this pillar:
What AI actually does across the lifecycle
Section titled “What AI actually does across the lifecycle”The capabilities are broader than “autocomplete”, and they cluster into six kinds of work.
Understanding. Explaining an unfamiliar codebase, summarising what a commit range did, reconstructing why a design decision was made from the history that records it. This is the lowest-risk and most consistently useful category, because the output is an explanation you can check against the repository.
Producing text about code. Commit messages, pull request descriptions, release notes, documentation. Also low-risk, with one specific failure mode: text that describes intent the diff does not contain.
Writing and modifying code. The category everybody thinks of first, and the one where the output needs the most verification — because a plausible-looking function that calls a method which does not exist compiles in the reader’s head and not on the machine.
Operating tools. Running commands, reading logs, driving Git, calling APIs. The point at which an assistant becomes an agent, and the point at which permissions start to matter.
Reviewing. Reading a diff and reporting problems. Genuinely useful as an additional layer, and structurally unable to be the last one — a reviewer with no stake in the outcome and no memory of the last incident is not accountable for the merge.
Delegating. Handing a scoped task to something that works on it independently and comes back with a pull request. The newest category and the one with the most to get wrong.
The five clusters
Section titled “The five clusters”AI + Git
Using AI on history, commits, conflicts, releases and documentation.
GitHub Copilot
Copilot across editors, and the durable instructions that shape it.
Copilot CLI
An agentic engineering environment in the terminal.
AI Code Review
AI review as a layer that adds to human accountability rather than replacing it.
AI Agents
Delegating scoped engineering work through agents, skills, MCP and automation.
AI + Git
Section titled “AI + Git”The lowest-risk, highest-frequency application: using AI on history, diffs, conflicts, releases and documentation. It comes first because it teaches the habit the rest of the pillar depends on — giving the model the actual repository state rather than a description of it.
GitHub Copilot
Section titled “GitHub Copilot”Copilot as an engineering environment rather than a suggestion box: chat, agent mode, and the durable customisation — instructions, prompt files — that makes it behave consistently on your codebase rather than on the average codebase.
GitHub Copilot CLI
Section titled “GitHub Copilot CLI”The terminal surface, and the most distinctive one. An agentic environment with a permission model, custom agents, skills, hooks and MCP, sitting exactly where DevOps work already happens.
AI Code Review
Section titled “AI Code Review”Review as an additional layer. What Copilot code review reads, how to tune it, how it interacts with required approvals, and the security consequence of review instructions living in the branch being reviewed.
AI Agents + GitHub
Section titled “AI Agents + GitHub”The advanced cluster: the cloud agent, repository-level agent configuration, MCP, skills, issue-to-pull-request workflows, and release engineering. This is where permissions, trust boundaries and auditability stop being theoretical.
Context is the whole game
Section titled “Context is the whole game”If one idea determines whether AI is useful on your codebase, it is this: a model’s output quality is bounded by what it can see, and what it can see is much smaller than your repository.
A model does not “know” your codebase. For any given request it has a context window containing some combination of: your prompt, files the tool retrieved or you attached, a summary of the conversation, and any durable instructions you configured. Everything outside that is invisible — and its absence produces confident, wrong answers rather than “I don’t know”.
This explains most of the failure modes in this pillar:
- A commit message that describes intent the diff does not contain — the model was given a summary rather than the actual diff.
- Code calling a method that does not exist — it saw the shape of your API from surrounding code and inferred the rest.
- A conflict resolution that compiles and is wrong — it saw both sides of the conflict and not the code that depends on the result.
- A “fix” that closes an alert without fixing the flaw — it saw the alert and the file, not the deployment.
It also explains what actually helps, which is unglamorous: attach the real files, paste the real error output, and write durable instructions so the conventions that are obvious to you are visible to it.
Choosing a customisation mechanism
Section titled “Choosing a customisation mechanism”Copilot has accumulated several ways to shape its behaviour, and they are easy to confuse. The distinction that matters is when each one is loaded.
| Need | Mechanism |
|---|---|
| Always-on repository guidance | Repository custom instructions |
| Rules that apply only to certain paths | Path-specific instructions |
| Cross-tool agent guidance | AGENTS.md, where supported |
| A repeatable prompt you invoke deliberately | Prompt file |
| Task knowledge loaded only when relevant | Agent skill |
| A specialised persona with its own tools | Custom agent |
| Access to external tools or data | MCP server |
| Deterministic checks at lifecycle points | Hooks |
| A distributable bundle of the above | Plugin |
The three most often confused:
Instructions are always on. Everything in them costs context on every request, which is why a 2,000-line instructions file makes results worse rather than better.
Prompt files are invoked. You choose to run one, for a specific task.
Skills are loaded when relevant. The agent decides, based on the skill’s description, whether this task needs it. That makes the description the most important line in a skill file.
Support is not uniform across surfaces — prompt files, for instance, are available in some IDEs and not on github.com or in the CLI. Each cluster states the current position for its own surface, and Repository Instructions is the page that lays out the whole decision.
Three ways to work with AI
Section titled “Three ways to work with AI”Most confusion about “how much should we let it do” dissolves once these are named separately. They are not a maturity ladder — each is correct for different work.
Assistant. AI suggests; a human executes. Chat, completions, an explanation of a diff. The human is in the loop at every step because the human is the one typing.
Supervised agent. AI executes, with approval for tool calls and commands. The developer is present and watching. This is agent mode in an editor and the Copilot CLI in a terminal.
Delegated agent. AI performs scoped work in an isolated environment and returns a result for review. Nobody is watching while it runs, so the controls are the scope you set beforehand and the review you do afterwards. This is the cloud agent.
The move from supervised to delegated is not a question of trust in the model. It is a question of whether the work is scopeable — whether you can state the goal and the acceptance criteria clearly enough that a result can be judged without having watched it being produced.
The agent model
Section titled “The agent model”Where an agent is involved rather than an assistant, this is the loop, and every stage is somewhere things go wrong:
Goal → Context → Instructions → Model → Tools → Plan ↓Result ← Validation ← Environment feedback ← ActionsGoal — what you asked for, which is usually less complete than you think. Context — what it can actually see. Not the repository; the part of the repository it retrieved. Instructions — the durable rules, from repository instructions and skills. Tools — what it can do. The security boundary. Plan — its decomposition, which is worth reading before the actions happen. Actions — edits, commands, API calls. Environment feedback — test results, compiler errors, command output. The only ground truth in the loop. Validation — whether the result meets the goal, which is a judgement it cannot make about itself.
Then the Git controls take over, and they are the same ones from the previous five pillars:
Result → Git diff → Tests → Pull request → Review → Repository policyNothing in the second line is AI-specific. That is the point. The output of an agent enters the system as a diff, and a diff is a thing this curriculum has spent five pillars teaching you to evaluate.
Security, integrated rather than appended
Section titled “Security, integrated rather than appended”Pillar 5 applies throughout, and three concerns are specific enough to state here.
Permissions are the control. An agent can do what its tools and credentials allow. The defensible shape is the one Pillar 5 already argued for: scoped tokens, short lifetimes, no standing production credentials, changes arriving as pull requests rather than pushes to the default branch. An agent with organisation-admin access is an unreviewed administrator.
Repository content is untrusted input. An agent reads code, documentation, issues, pull request descriptions and comments. Anything a contributor can write is something the model may read as instruction. That is prompt injection, and the defence is architectural — limited tools, limited credentials, human review — rather than a filter.
Adding a tool adds attack surface. An MCP server makes an agent more useful and gives it more to do. A read-only integration and a write-capable one are different security decisions, and the second one deserves the scrutiny you would give a service account.
Terminology, precisely
Section titled “Terminology, precisely”Four surfaces are routinely used interchangeably and are not the same thing. Getting them straight early saves confusion in every later article.
| Surface | Where it runs | What it does |
|---|---|---|
| Copilot Chat | IDE or github.com | Conversation; suggests, explains, generates |
| Agent mode | Your local development environment | Autonomous edits in your workspace, with approvals |
| Copilot CLI | Your terminal | Agentic work with tools, permissions and custom agents |
| Copilot cloud agent | A GitHub-hosted environment | Delegated tasks, returning a branch and a pull request |
GitHub’s own documentation is explicit that the cloud agent “is distinct from the agent mode feature available in your IDE” — the cloud agent works in a GitHub-hosted, Actions-powered environment, while agent mode “makes autonomous edits directly in your local development environment”.
This pillar keeps those names separate throughout, and says which surface it means every time.
What this pillar will not tell you
Section titled “What this pillar will not tell you”Being explicit, because AI material tends toward the promotional and this site does not.
No productivity claims. You will not find “AI makes developers 55% faster” here. Those figures come from studies with specific tasks, specific populations and specific measures, and quoting them out of that context is worse than saying nothing. What you will find is what each tool does, what it costs to verify, and where it fails.
No model rankings. Model availability changes monthly and depends on your plan and your organisation’s policy. Pages discuss capability, latency and cost as trade-offs to reason about rather than maintaining a league table that is wrong by the time it is read.
No claim that any of this is optional-free. Every capability here has a verification cost. A tool that produces a change in ten seconds and requires four minutes of review has not saved four minutes; it has moved the work from writing to reading, which is often a good trade and is not a free one.
No architecture where an agent is the last check. Several pages describe agents doing more autonomous work than most organisations currently allow. None of them end with the agent merging its own change.
Common mistakes
Section titled “Common mistakes”The failures that recur, collected here because they cut across every cluster.
Accepting a generated command without reading it. Especially destructive Git operations and anything touching infrastructure. The command is a suggestion; running it is your decision.
Resolving a conflict without running the tests. A file with no conflict markers compiles. That is not the same as the merge being correct.
Writing a huge instructions file. Always-on context is charged on every request. Long instructions crowd out the code the model needs to see and get followed less reliably, not more.
Confusing the mechanisms. Instructions are always on; prompt files are invoked; skills load when relevant. Using one where another belongs produces behaviour that seems intermittent.
Granting broad tool permissions to save time. Approval fatigue is real, and --allow-all-tools
solves it by removing the control. Narrow, specific allowances are the sustainable answer.
Giving an agent production credentials. There is no task in this pillar that requires it.
Skipping CI because the agent said the tests passed. The agent reporting a green run is a claim. CI running is evidence.
Treating an AI security fix as a fix. Closing an alert and removing a vulnerability are different outcomes that look identical. Pillar 5 covers why.
Letting untrusted repository content reach a privileged agent. Issue text, PR descriptions and comments are written by whoever can open them.
Asking for a change without acceptance criteria. An underspecified task produces a confident answer to a question you did not ask.
Prerequisites
Section titled “Prerequisites”This is the last pillar, and it assumes the other five.
- Git internals and history — how Git works and Git objects. AI Git troubleshooting is unusable without them.
- Workflows — branching, rebasing and merge conflicts.
- GitHub engineering — pull requests, CODEOWNERS and the API.
- Actions — workflows and OIDC.
- Security — least-privilege access, rulesets and supply-chain security.
You do not need any machine learning background. You need to be able to read a diff and reason about what a command will do.
Where to start
Section titled “Where to start”Mental model
Section titled “Mental model”Start with AI + GitAI is a fast, tireless, confident contributor with no accountability and no memory of what went wrong last time. Everything this curriculum has taught about reviewing contributions applies unchanged — and matters more, because the usual signals of a contributor being out of their depth are missing.