Session 05

Workflow integration·and code review

Program
Agentic engineering
With
Arndt Voges
From
Arndt Voges Consulting
Where
Remote

From a working change to merged code

Workflow and reviewHands onClose

50 min workflow and review, 25 min hands on, the rest together

0:00
Workflow and review
0:50
Break
0:55
In the session·one ticket from story to pull request, then a review together
1:20
Homework, close
1:30
End

Where we are

  1. 01Core concepts
  2. 02Preparing the codebase for agents
  3. 03Writing a good spec
  4. 04Feedback loops
  5. 05TodayWorkflow integration and code review
  6. 06Claude Code in depth
  7. 07Orchestration and subagents
  8. 08Claude Code alternatives
Codebase, spec, loop, and now review. The last step on the path of one ticket.

The agent can check its own work now.
Today: how that work gets into main.

What we cover today

BranchCommitJiraSentry
WorktreeReviewMCP server
Pull requestREVIEW.md/code-review
Product ownersRubber-stamping

Part one

Gitfirst

Always version the agent's work.

Git is the undo button.

Commit before every agent run. A bad run then costs one reset, not an afternoon.

Branch or worktree?

ONE AGENT: A BRANCH shop/ your checkout agent on branch voucher-fix main voucher-fix Roll back with one git command. SEVERAL AGENTS: ONE WORKTREE EACH checkout-a/ its own folder agent branch a checkout-b/ its own folder agent branch b checkout-c/ its own folder agent branch c one repository, one .git No two agents edit the same files on disk. Caveat: more checkouts, more dev servers, cleanup afterwards.

Let it write the commit message
and the pull request description.

It knows what it changed. You check that the description matches the diff.

Part two

Connectingyour tools

The agent reads the ticket itself.

MCP server

A program that gives Claude Code new tools,
such as reading a Jira ticket.

Connect what you already use

terminal
claude mcp add --transport http --scope project jira   <jira server URL>
claude mcp add --transport http --scope project sentry <sentry server URL>
claude mcp add --transport http --scope project figma  https://mcp.figma.com/mcp

# project scope writes .mcp.json: it goes into git, the team shares it
Jira, Sentry, Figma: each one removes a copy-paste step. [VERIFY server URLs and what your IT allows]

Figma: from link to component

URLs

The spec has the URLs of the frames, one per state: Copy link to selection.

MCP server

The agent reads layout, tokens and annotations. Reading needs a Dev or Full seat.

Code Connect

Maps Figma components to your code components. Without it, the agent rebuilds what you already have.

Rules

Figma generates a design system rules file. It goes into .claude/rules/.

What an MCP server returns,
the model sees.

Every result enters the context and leaves your machine. Start with read access.

Part three

Codereview

Where the bottleneck moves.

Review is the new bottleneck.

Larger pull requests, more of them, and the author's mental model of the code is no longer there to draw on.

Move review upstream

WHERE THE REVIEW TIME GOES TODAY Spec Tests Every line of the diff UPSTREAM Spec and criteria Tests What is left business rules, product owners do they check the criteria? your line-by-line list A reviewed spec and passing tests leave less to read in the diff.

You determine what still gets read line by line

Each team decides, writes it down, and puts the list into its review instructions.

Review subagent: a first pass, never the last word

/code-review

Built into Claude Code. Reviews your branch in a background subagent and follows your CLAUDE.md.

Code Review

Anthropic's managed review on GitHub pull requests. Reads a REVIEW.md with your rules. [VERIFY hosting and plan]

Your own

A custom subagent, only for what those two miss.

Review rules, written down

REVIEW.md (illustrative)
# Review instructions

## Important means here
Breaks behavior, leaks data, or blocks a rollback.
Style and naming are Nit at most.

## Always check
- Migrations stay backward compatible
- Prices stay integers in cents
- No customer data in log lines

## Do not report
- Anything lint or CI already enforces
- Files under src/generated/

The failure mode:
approval becomes reflexive.

High volume, everything plausible, and an approval stops meaning anything. Cap the size of a pull request.

Working very closely on the spec with the product owners
is going to be a game changer for you.

Let them meticulously define the business rules and acceptance criteria. Review there, not in the diff.

Hooks as gates.

Tests before every commit, whether or not the agent remembers. Session 04, now as part of the workflow.
In the session

One ticket, from story to pull request.

A team member drives, with their own setup · then the room reviews that pull request together

Example homework, to be tailored to your team

Homework: three options

Team artifact

Review rules on top of /code-review

Run it on a real pull request, write down what it missed as rules, run again. One finding caught, one missed.

Measurement

One week of pull requests

Size, time to first review, time to merge, findings from people and from the subagent. We compare teams.

Integration

Ticket to pull request, no copy-paste

Connect the ticket system. One ticket from story to open pull request without pasting anything.

Next session:
Claude Code in depth.

Arndt Voges Consulting · arndt@arndtvoges.com · arndtvoges.com

<stop>