Hello Curious Coders,

You ask an AI agent to build a feature, and it starts editing files directly in your working tree. At first, the speed feels useful. Then the change grows, an unrelated file moves, and you realize you no longer know which decisions belong to the feature.

There is no clean boundary around the work. Rolling back means reconstructing what happened from a long conversation, and the conversation is not the artifact you will eventually merge.

That is the problem Git can solve, but only if it enters the workflow before the agent starts writing code.

In the last post, we put the project’s process into claude.md, agents.md, and the smaller documents they reference. Now Bruce wanted to see whether those instructions would survive contact with a real feature.

The test started with a modest question: “What’s the next priority for development?”

Claude read plan.md, found the remaining task, and proposed an increment. Then it planned the work, created a feature branch, wrote the code and tests, ran verification, and prepared a pull request.

Nobody restated the Git procedure because the repository already knew it.

Git was no longer the place where the agent deposited finished code. It had become part of the agent’s control system.

Put Checkpoints Around the Work

An agent can make several reasonable decisions in a few minutes. The danger is not speed itself. The danger is letting those decisions accumulate without a place to stop and inspect them.

A feature branch gives the work a boundary. The pull request turns that boundary into something you can review, while verification determines whether the change is ready for that review.

In this example, the feature was small but real. The Wordle dictionary needed to distinguish possible answers from words that were only valid guesses. Claude updated the schema, changed the context functions, added tests, and kept the increment isolated from main.

The first run also exposed an ordinary integration problem: the GitHub app had lost its authorization and needed to be connected again. That was useful information. A quiet test feature is a good place to discover that your workflow depends on credentials that have expired.

This is why you test the process before giving the agent a large assignment. You are checking whether the checkpoints exist when you need them.

Make Verification Answer Yes or No

The tests passed, but the compiler still produced warnings.

Warnings invite interpretation. A developer might decide that two unused variables are harmless and move on. An agent can make the same judgment, but perhaps differently on the next run.

Bruce asked Claude to clean up the warnings and make warning cleanup part of review. Claude changed the verification command to compile with --warnings-as-errors.

That replaced judgment with a signal the build could evaluate.

Bruce puts it this way:

“So I look for measurements that are quantifiably yes or no as often as possible.”

— Bruce Tate

A clean compile and passing tests do not prove that the design is correct. They answer narrower questions, and that is exactly why they help. Did the compiler report a warning? Did a test fail? The workflow can act on those answers without guessing what “good enough” means.

Database migrations need similar care. On a larger system, adding a field, changing the application to use it, and removing the old field may belong in separate pull requests. If deployment stops halfway through, the application is less likely to end up with code and schema that disagree. Bruce skipped that extra separation for this one-person example, but the boundary should reflect the cost of failure.

Give the Agent a Better Instruction

You can apply this today by changing one repository instruction.

Before:

Build the next priority.

After:

Create a feature branch, implement one increment, run
mix compile --warnings-as-errors and mix test, then open
a draft pull request only if both commands pass.

The second version does more than request code. It tells the agent where the work belongs, how large the increment should be, what evidence counts as verification, and when a pull request may be created.

Write that sequence into the repository guidance instead of repeating it in every conversation. The memorable rule is simple: branch first, verify before review.

Once the pull request exists, review the increment rather than the chat that produced it. The conversation may explain Claude’s reasoning, but the diff shows what will enter the system.

Bruce also recommends letting a different model review the pull request. One model writes the change, while another model such as Copilot or ChatGPT examines the diff. GitHub rulesets can request that review when a draft pull request is opened or updated, giving the authoring model another source of scrutiny before a human makes the final decision.

The Next Experiment

Once Git creates boundaries around AI work, you can let the agent move quickly without treating every attempt as permanent. A failed attempt becomes information held safely inside a branch.

Bruce describes the next step this way:

“You’re going to build something tentatively. If you don’t get what you want, you’ll throw it away, improve your prompting, and build it again. And in this world, that’s cheap.”

— Bruce Tate

That is the setup for the next post. The workflow can control the branch, verification, and pull request. What lands inside that pull request is a different question, especially when Claude is given broad freedom to build the interface.

— Paulo & Bruce