ai / review
An agent writes most of the code in my changes. How much of it I read depends on the project and the change. This is how I decide.
Checks gate the merge
sockeye runs the checks on every push and refuses to merge
a change whose checks are not green. The checks are the
Go checks, the project's tests, and project-specific
scans such as nullscan. A check that a reviewer used
to do by reading, such as "does this scan NULL into a string", is a
line in a Checkfile.
When a check fails, I paste its output into the agent in that worktree. See git / workflow.
Skim and approve
I skim most of a teammate's changes in the sockeye web page. If the checks are green and nothing stops me, I reply in Slack with a green check emoji. No agent runs.
When the agent reviews
I bring in an agent when the skim raises a question or when the change is large. I also bring one in when the change looks over-engineered and a simpler version is possible. Then I open a new tab and:
cd "$(soc checkout APP-1A)"The command checks out the remote branch into a local git worktree.
I prompt the agent with my question, or ask it to find what the
change could drop. I read what it finds and the lines it points at.
Then I post one comment with soc comment APP-1A. A review in sockeye
has no threads and no approve verb. See
git / workflow. A yes can also be a sentence
in the comment.
Screenshots
A check can tell me a template renders. It cannot tell me the page looks right. For a change to a stylesheet or a template, the agent runs browse on each changed page at phone, laptop, and desktop widths. It puts the screenshots in its reply. I review the visible outcome.
What I read
I read the title and description in full. Then I scroll the diff and stop where something stands out. That can be a schema change or a new Go package. It can also be a set of unit tests that backfill coverage for a bug fix, or a file I did not expect the change to touch. I do not read check output unless a check fails.