How AI employees work through GitHub pull requests

AI can produce code quickly. That does not make a direct production write a good workflow.

The safer contract is the one engineering teams already understand: a scoped task, repository permissions, a branch, a pull request, automated checks, review, and a human-controlled merge.

Yodu can hold the business context and employee assignment while GitHub remains the source of truth for code review and release controls.

Quick answer

An AI employee should work in GitHub through the same controls as a human contributor: a scoped issue, least-privilege repository access, a dedicated branch, automated checks, review, and a human-controlled merge. Start with investigation and small fixes. Measure accepted pull requests and review cost, not generated lines of code.

What the research says

GitHub published a 2025 study involving 202 experienced Python developers. In GitHub's vendor-sponsored research, submissions created with Copilot were more likely to pass all tests and were over 10% more likely to pass blind code review.

An earlier GitHub controlled experiment found developers using Copilot completed a defined coding task 55% faster. That result came from one task and one product, so use it as a reason to measure your own workflow, not as a promised Yodu outcome.

That is encouraging, but it does not remove the need for review. The study itself measured quality through tests and human review. Those controls are the point.

Connect GitHub as a company tool

Open Tool access → App catalog, connect the intended GitHub account or installation, and confirm it appears under Connected.

Then leave the account switched on only for the engineering employee who needs it; switch it off for every other employee.

Start with read or draft-oriented work:

• issue summary
• pull request summary
• codebase investigation
• implementation plan
• release notes
• test-failure analysis

Repository writes pause at the approval gate before they run.

Scope the Yodu task

A useful engineering task includes:

• repository
• issue or incident link
• requested behavior
• acceptance criteria
• files or components in scope
• explicit non-goals
• required tests
• human reviewer

“Fix authentication” is not safe. “Prevent a logged-out user from opening /settings; add a regression test; do not change sign-in providers” is reviewable.

Keep repository controls in GitHub

Use GitHub's own control plane:

• least-privilege app permissions
• protected default branch
• required status checks
• CODEOWNERS
• pull request reviews
• human merge rights
• protected deployment environments

The official GitHub docs explain branch protection and GitHub App permissions.

Do not replace those controls with a sentence in the employee prompt.

A practical workflow

1. Human creates or approves the Yodu task.
2. Engineering employee reads the issue, repository context, and current checks.
3. Employee returns a short plan and risk note.
4. Human approves write work when the approval gate holds it.
5. Employee prepares branch or pull-request work through the available GitHub actions.
6. GitHub runs required checks.
7. Human reviews the diff and test evidence.
8. Human merges.

The exact write actions available depend on the connected GitHub toolkit and the account permissions.

Sensitive files need a stricter gate

Require named human review for changes involving:

• authentication or authorization
• billing and payments
• database migrations
• secrets or environment configuration
• deployment workflows
• data retention or deletion
• customer-data access

Use CODEOWNERS and branch rules so the repository enforces the decision.

Review the pull request like any other

Check:

• Does the change match the Yodu task?
• Is the diff smaller than necessary, or larger?
• Are new behaviors covered by tests?
• Did CI pass?
• Did unrelated formatting or generated files change?
• Are sensitive areas reviewed by the right person?
• Does the pull request explain the user impact and risk?

AI authorship does not make the review ceremonial.

Measure engineering value

| Metric | Why it matters | | --------------------------- | ------------------------------------------------------- | | Task-to-PR cycle time | Shows how quickly a clear issue becomes reviewable work | | First-pass CI rate | Reveals whether the employee produces testable changes | | Major revision rate | Shows scope and reasoning quality | | Review time | Captures the human cost, not just generation speed | | Revert or incident rate | Protects against optimizing for merged volume | | Accepted changes per dollar | Connects model and tool spend to useful code |

Do not use lines of code as the primary measure. More generated code can mean more review and more risk.

Start with investigation, then write

The safest first engineering employee task is often an investigation brief. It tests repository access, context, issue understanding, and communication without changing code.

When that works, move to a small fix behind branch protection. Expand from there.

The goal is not autonomous merging. The goal is to turn well-scoped engineering work into reviewable progress while keeping the repository's existing trust system intact.

Keep going

Set up the connection with the GitHub workflow guide, review how employee tool grants work, then use the AI employee audit framework to review evidence, approvals, and outcomes.