Introduction to Code Review

By Axl Ibiza, MBA · Free introductory course

Axl Ibiza builds Hermes with Hermes. This course introduces code review through that work: an agent system whose behavior continues across conversations, tools, workspaces, providers, and restarts. The question is what a proposed change means for that living system and the people who depend on it.

This course develops the beginner’s understanding of code review from Axl’s work on Nous Research’s Hermes Agent. It introduces the relationships that make a review useful, the language of a real proposal, and the difference between a supported conclusion and a plausible comment. Agents are active engineering participants throughout: they investigate, implement, execute checks, review, and help make decisions. Evidence and independent challenge establish the strength of their conclusions. Axl’s public reviews provide a few light examples; the separate Advanced Code Review Masterclass examines those reviews in depth and includes the structured JSON.

A review should leave the system better understood. A comment earns its place when it contributes to that understanding.

Axl is a Nous Research contributor, the Hermes Godfile Slayer and Swarm Architect, and the creator of the graph-gated engineering and adversarially verified transformation architecture documented in All Gods Must Die. This introduction teaches the perspective behind his review work. The detailed advanced mechanisms belong to the separate Masterclass. The public paper is the source for the account of agent engineering, and the cited review records are the sources for the historical examples. Axl’s public paper.

Pin the head and the base before you start

The repo always moves. Contributors push fixes, maintainers update the target branch, and related work lands while you are reading. If you keep chasing the latest head, the thing you are reviewing changes faster than you can finish assessing it. You can spend an entire day reviewing different versions of the same proposal and still have no completed review of any one version.

Start by pinning the exact head commit and base commit for your review. The head is the proposed version you are assessing. The base is the version you are comparing it against. Record the full commit identities, not only a branch name or a pull request number. A branch can move; the named commits identify the objects your review is about. Keep both pins fixed until that review is complete.

Every claim in the review belongs to that pair. The changed source, surrounding behavior, test result, and conclusion must describe the identified artifact. A passing result from a later head cannot quietly certify the earlier one. A failure in code that only exists on a later target branch cannot quietly become a defect introduced by this diff. A source link to a moving branch cannot preserve the object of a historical finding by itself.

You can notice a new push without adopting it. Record that another revision exists and finish the review you started. Your conclusion names its head and base, the work it established, and the boundary of that assessment. Completion does not mean that the repository has stopped moving. It means you have finished an inspectable review of the version you agreed to assess. A recommendation about the current merge candidate requires an assessment of that candidate; an old result cannot be silently relabeled as current.

Re-review from the previous review

When you re-review, the previous review is your standard, and the previously reviewed head becomes the comparison base for the new changes. Pin that previous head and the new head before beginning the next review. Carry forward the original findings, promised behavior, evidence, and unresolved questions. You are measuring what changed against a consistent account of what needed to be true.

That gives the contributor a fair, usable question: did this repair satisfy the obligation the previous review established? Credit a demonstrated repair. Retain an unresolved finding when its basis still applies. Withdraw a claim when new evidence defeats its premise. Identify a genuinely new finding as new. If a requirement changes, say that explicitly rather than silently rewriting the standard against which the author is being assessed.

Keep the original target or comparison history available when it matters to causal attribution. The new-change comparison and the question of what this proposal introduced against its intended target are related but distinct. The Advanced Masterclass develops that distinction. For the Introduction, retain the essential discipline: one fixed head-and-base pair per completed review; the previous review supplies the baseline for the next one. That is how you reach a finish line while the repo continues moving.

The cost of a drive-by review

Before learning how to review code, understand why an active repository can suffer from more review. A comment arrives with a confident verdict, a severity label, and a proposed repair. Someone must now decide whether it describes a real problem. If the comment never established the requirement, the relevant execution path, or the consequence, that investigation has been handed to the contributor and maintainer. The reviewer has produced an obligation for other people without first doing the work that would justify it.

This is the drive-by problem. It is defined by unsupported conclusions and abandoned responsibility. A short review can be excellent. A newcomer can find a decisive defect. An agent can perform substantial investigation, implementation, testing, and independent review. A long comment written by an experienced person can still be drive-by work if it claims more than its evidence establishes. The quality question is what the review contributes to understanding and deciding the actual proposal.

Attention is part of the engineering cost

A maintainer cannot safely dismiss every polished objection. A plausible allegation might expose a consequential failure. The recipient therefore reads the source, checks the discussion, reconstructs the alleged path, and asks which revision the comment describes. An unsupported review creates this cost while leaving the underlying question unresolved. The contributor may spend the next work session disproving an invented requirement instead of completing a real repair. This is a mechanism of wasted effort, not a claim that every review consumes a measured number of hours.

Duplicate comments create another burden. A finding may already be recorded, assigned, or repaired. Reposting it without checking that history splits the discussion and makes the same issue look like several independent problems. A stale verdict can keep accusing the latest revision of behavior that belonged to an earlier one. Severity language can then become a substitute for following the actual source. The repository receives more pressure without receiving more knowledge.

The damage can reach the implementation. A contributor trying to satisfy a loud objection might remove a legitimate capability, flatten an intentional distinction, or broaden a change until its original purpose becomes difficult to assess. A suggestion to remove state, reject an input, or disable a surface needs a reason connected to the product promise. Making the concern disappear by deleting the promised behavior is not a successful repair.

Two light contrasts from Axl's Hermes reviews

Consider the prompt-pin work in Hermes PR #126167. At revision cebeaef4, Axl distinguished a working synthetic-turn repair from a regression test that could miss removal of the operation it claimed to protect. A later human turn supplied state before the assertion read it. That distinction let the review explain what worked and what the evidence failed to establish. Axl's historical review.

Here is an instructional contrast, not a quotation from another reviewer: a comment that sees the weak test and declares the production repair broken would collapse two different conclusions. A comment that sees the passing test and declares the entire behavior proved would make the opposite mistake. The useful contribution identifies the relationship between the asserted result and the operation under assessment. You can understand that distinction without being given the advanced investigation machinery.

The compaction example shows the importance of returning after a repair. Axl's review at revision 8069537 identified a distinction that survived an initial reload but was lost before a later persistence cycle. At 59b3240, he assessed dskwe's repair and closed the specific projection-loss concern. The earlier finding remains a valid historical observation; the later assessment records changed source and new evidence. The original finding, the repair assessment.

Another instructional contrast is repeating the original objection after that repair without examining the new revision. Doing so would make the discussion less accurate. A review earns its authority by remaining answerable to the artifact. Credit for a real finding includes responsibility for acknowledging a real correction. Neither the author nor the reviewer benefits from preserving a disagreement after its technical basis has changed.

A real claim that had to be withdrawn

One later Hermes prompt-pin review at head 4982dcd charged the proposal with a broken caller drawn from a later version of main. The cited caller file was absent from the reviewed head and both relevant historical bases. The existing caller on the reviewed branch already used the new argument. A subsequent reconciliation withdrew that finding while retaining the separate concerns that remained supported. This is an actual mistaken claim, summarized without identifying the reviewer. The historical reconciliation.

The mistake matters even though a failure in a later composition can be real. It assigns the failure to the wrong artifact and can send the contributor to repair code their reviewed branch does not contain. The useful conclusion distinguishes the completed review of the pinned proposal from a later integration question. Withdrawal corrects the technical record; it does not mean that every other observation was false. The Advanced Masterclass examines this case and the other anonymous examples in detail.

A review leaves a record other people will use

Review comments persist. Future contributors search them to understand why a rule exists. Agents retrieve them as context for another task. Maintainers may use them when deciding whether a proposal is ready or why it was delayed. An unsupported allegation can become a false explanation of the system when later summaries omit the missing evidence. A repaired historical problem can be mistaken for a current defect if the conclusion is never updated.

That record also affects how people understand each other's work. An unjustified claim that a contribution is unsafe or incomplete can distort the contributor's reputation. Taking over an existing finding can erase the person who discovered it. A sweeping closeout can hide the person who implemented the repair or the limits of another participant's test. These consequences follow from how the record is reused; they do not require inventing a measurement of reputational harm.

Use severity and merge recommendations with the same care as behavioral claims. A consequential defect can warrant a strong recommendation. A question, preference, or untested possibility should remain identifiable as such. The reviewer should explain the consequence and the support for the recommendation, while respecting the repository's actual decision ownership. Posting a categorical demand does not grant authority to decide the project's requirements or its merge policy.

What useful participation looks like

The purpose of this Introduction is to help you enter that conversation intelligently. Read the proposal and prior discussion. Learn what the change promises. Ask an honest question when the source leaves a relevant relationship unclear. Explain an observation at the strength its evidence permits. Preserve the contributor's work and existing credit. If a reply disproves your premise, correct or withdraw the claim so the next reader receives an accurate account.

You can read this complete course in HTML, and your agent can read the same HTML. The teaching and source links remain usable without a JSON file. An agent can help explain an unfamiliar concept or follow a cited review while you study. The separate paid export supplies structured relationships for advanced work; understanding this Introduction does not require that export or a purchase.

Useful participation includes supported acceptance. It includes recognizing a sound repair, explaining why a suspected problem does not apply, and leaving an unresolved question with the person who owns the requirement. Independent reviewers are welcome. New participants are welcome. Agents are engineering participants. None of those roles is excused from the obligation to make a substantive conclusion inspectable and to update it when the evidence changes.

Explicit anti-goals of this Introduction

• Chasing a moving head or base until the review has no finish line. Pin both commits, complete that review, then begin a separate re-review from the previous review and its reviewed head.
• Verdicts after skimming a diff. A changed line acquires meaning through the proposal and surrounding behavior; a confident reaction cannot supply that context.
• Posting copied agent output as an established finding. An agent's candidate must remain connected to the source and evidence that support it. Fluent prose alone establishes neither.
• Promoting suspicion into a demonstrated defect. Questions and hypotheses are useful when their status is honest. An unsupported failure claim creates a repair obligation prematurely.
• Multiplying duplicate or stale criticism. Read the existing discussion and changed revision so your contribution advances the actual question rather than restarting it.
• Removing useful behavior to silence a concern. A repair must respect the intended capability or identify an explicit product decision to change it.
• Using severity as an invented merge veto. Recommendations need supported consequences and accurate scope; repository decision authority is a separate fact.
• Treating human authorship as proof or agent authorship as disqualification. Both humans and agents can do substantive review. Evidence and independent challenge govern the conclusion.
• Requiring credentials, tenure, or familiarity with every subsystem before participating. A bounded, supported observation or honest question can be valuable from a newcomer.
• Protecting the reviewer's first verdict at the expense of the record. Correct errors, credit repairs, and withdraw unsupported claims so future readers inherit the best available understanding.
• Providing an automated verdict generator or the paid course's operational package. This complete introductory course teaches judgment through light examples.

Code review should make a proposal easier to understand, challenge, improve, and decide. That is the skill this course begins to teach. Axl's Hermes work supplies the examples because the behavior, evidence, authorship, and revisions can be inspected in their original records. Learning to respect those relationships is the first step toward contributing reviews that a repository can use.

1. What a code review actually does

Hermes is a useful place to learn review because a change rarely ends at the line where it begins. A message arrives. The agent receives context, chooses an action, uses a tool, and may carry information into another turn. A conversation may continue after the process that first received it has stopped. A setting may reach a provider through an adapter. A workspace can influence what the agent understands about the task. Code review asks whether a proposed change preserves or improves the behavior promised across the relevant relationships.

For a beginner, the first useful definition is straightforward: a code review examines a proposed software change and the reasons to accept, revise, or investigate it further. The reviewer can be an engineer, an agent working in a review role, or a coordinated combination. What makes the activity review is the assessment of a proposal against its purpose and evidence. Merely describing the changed lines does not finish that assessment. Neither does producing a polished opinion about them.

The proposal matters because software is shared work. In Hermes, a contributor may be fixing how a synthetic continuation preserves conversational context, how a workspace is identified, or how an update coordinates its participants. Each proposal asks others to rely on a particular result. The reviewer’s task begins by understanding that result. “This makes the function shorter” describes an edit. “This preserves the existing conversation after this kind of continuation” describes a behavior another participant can depend on. Those statements require different kinds of attention.

A review is therefore a contribution to the repository’s knowledge. It connects the author’s stated purpose to the implementation and the consequences that matter. It can establish that a change is sound within a stated scope. It can identify a conflict between intended and actual behavior. It can expose a requirement that has never been settled. It can also explain why an apparent problem is harmless in the relevant path. All four outcomes can improve the project. A useful reviewer is willing to reach whichever one the evidence supports.

That perspective is central to Axl’s original Code Review as Knowledge Mapping curriculum. A review makes relationships visible: the promise, the participating code, the observed behavior, the uncertainty, and the resulting decision. The advanced course develops that idea rigorously. Here, start by noticing that every substantive sentence in a review concerns a relationship. A function “preserves” a value. An adapter “passes” a setting. A test “checks” an outcome. A contributor “implemented” a repair. The verb tells you what the sentence claims happened between the named things.

This also explains why review is larger than finding defects. Consider a Hermes change that genuinely preserves a conversation’s intended state. Establishing that result is valuable even if the review contains no blocking finding. The author receives a clear assessment. A maintainer can see the basis for the recommendation. A future contributor can understand what must remain true when changing the same path. That shared understanding is a concrete product. A review that invents an objection to look busy can destroy it.

The reviewer should remain conscious of the proposal’s scope. A change to one adapter does not automatically establish a guarantee for every supported surface. A focused result about one persistence path does not establish all possible restart behavior. A source explanation can be decisive for a narrow question while leaving a larger operational question open. The correct response is to express the conclusion at the strength established, then identify the important remaining boundary. That is a useful decision, not an apology for failing to know everything.

This course will keep returning to Hermes because that setting gives the words practical meaning. Context is information an agent uses. Persistence is what carries information beyond one process lifetime. A provider boundary affects what another service actually receives. An update changes a running installation. A reviewer who understands those promises can ask useful questions before mastering every implementation detail. Learning review begins with learning what the system is being asked to do.

2. Why an agent system needs useful review

Hermes continues through state. A conversation has a history. A task can outlast the turn in which it began. A message can be accepted now and processed later. Information can be represented differently when it is stored, loaded, prepared for an agent, and sent to a provider. A correct local operation is valuable, but the user experiences the composed behavior. That is why review must understand enough of the surrounding system to assess the promise being made.

Axl’s paper describes Hermes as a stateful, self-regulating agent system rather than a thin interface that forwards a prompt and returns a response. That account is the setting for his engineering work. It includes the relationships between information, action, feedback, and continuity. The introduction does not need the paper’s full architecture to explain the consequence: changing a representation, ownership rule, or lifecycle can change what later participants know or do. All Gods Must Die, Section 2.

Think about what a person actually expects when they use an agent. They expect the task they gave it to remain the task. They expect a chosen workspace to describe the work being done. They expect an accepted message to remain available for processing. They expect a tool’s outcome to be distinguished from an intention to use the tool. They expect a resumed conversation to retain the information necessary for its next decision. These are ordinary product expectations, and each can cross more than one function or process.

Review helps turn those expectations into understandable engineering questions. If a change says it preserves context, which context does it mean? If it removes an identifier, does that identifier carry an obsolete reference or information a later participant still needs? If it improves a restart path, what survives between the two lifetimes? A beginner does not need to answer every one immediately. Recognizing that the promise has an object is the beginning of a useful review. Vague words become clearer when connected to a user-visible consequence.

Review also protects the ability to change Hermes again. A small implementation choice can place responsibility where the next contributor cannot find it. A copied rule can make two consumers disagree later. A fix can quietly rely on an assumption that is obvious to its author today but invisible six months from now. A good review leaves the reason for the chosen behavior in the record. That reduces the amount of rediscovery required before the next change can be made safely.

The cost of poor review is especially visible in an active agent repository. A confident but unsupported comment forces a contributor to investigate a claim that the reviewer did not establish. Repeated reports of the same mechanism can obscure the original finding. A suggested repair can remove a legitimate capability to make a narrow check pass. A large summary can bury the only observation that matters. The problem is not simply volume. It is attention being spent on material that fails to advance the engineering decision.

Agents can expand the capacity for useful review considerably. They can read source, trace participants, run checks, compare revisions, and organize evidence at a scale that would otherwise be expensive. The gain depends on how the work is structured and assessed. An agent that executes a relevant check produces evidence. An agent that independently challenges a premise can expose a mistake. An agent that repeats an unsupported conclusion produces another unsupported conclusion. The tool’s label is less informative than the work and artifact it actually supplies.

For the beginner, that yields a practical measure of value: what can another participant now understand, inspect, decide, or repair because of this review? The answer might be one clear finding. It might be a verified explanation of a sound change. It might be an unresolved product decision that needs its owner. It might be a correction to an earlier review. The measure is an improvement in shared knowledge and the decision it supports, not the number of comments or the severity words attached to them.

3. The language of a real pull request

A pull request is a proposal and a record of discussion. It holds an explanation of the change, a branch containing commits, a comparison against another branch or revision, and responses from participants. In Hermes, it is where the contributor’s intended result meets the repository’s constraints and review evidence. Understanding the objects in that interface prevents a beginner from turning one kind of signal into a claim about something else.

A branch is a name that can point to a different commit after another push. A commit identifies a particular version of the source. A diff shows the changes between versions. A review submission records an assessment at a point in that conversation. A check records an automated run with its own command, inputs, and assertions. These objects appear together on the page, but they answer different questions. The interface does not make them interchangeable merely by placing them beside one another.

A real Hermes title makes the distinction easier to see. PR #132365, proposed by teknium1, is titled “fix(update): update marker v2 (owner liveness, no age ceiling) + checkout lock held by the whole update tree.” That title describes a substantial intended result involving update ownership. It gives a reviewer a useful starting question. It does not by itself establish that every participant in the update tree behaves according to the promised ownership rule. The review and implementation evidence must supply that assessment. The original proposal.

The pull request number remains stable while the branch can change. That matters when reading a historical review. Axl’s review of an earlier revision may describe a defect the author later repaired. The review can remain true as a historical account without describing today’s head. A beginner should learn to distinguish “this review reported this behavior at this revision” from “this behavior exists now.” The first may be supported by the record. The second requires current evidence.

A source link pinned to a commit gives the reader a stable object to inspect. A link to a moving branch can show different code tomorrow. Both link types are useful, but their purpose differs. For discussing an exact historical finding, a pinned source link keeps the sentence connected to the code it describes. For locating the current implementation, the live branch may be the right navigation point. An informed reader notices which kind of question the link is intended to answer. GitHub’s explanation of permanent links.

The same care applies to review status. A technical comment can contain a recommendation without becoming a maintainer’s merge decision. An approval records a particular reviewer’s judgment. A request for changes has meaning within the repository’s permission and branch rules. A resolved thread records a discussion state. It does not execute a missing check or establish that every consequence has been assessed. Read the words and the recorded status as related facts, while preserving the difference between them. GitHub’s review terminology.

Checks deserve equally concrete reading. A passing result means the run accepted the assertions it executed. A failing result means some part of that run did not complete successfully. To understand its relevance, inspect what ran and what failed. A test can fail because of the changed behavior, an environment issue, an unrelated assumption, or a setup problem before reaching its subject. A green badge and a red badge are starting points for understanding the run. Neither supplies the whole explanation on its own.

The pull request also carries people and prior work. Read earlier discussion before adding another finding. A contributor may already have explained a limitation. Another reviewer may have discovered the problem. The author may have published a repair and identified its new revision. Those facts change what useful participation looks like. The beginner’s goal is to join the actual conversation with the actual source in view, rather than treating the comment box as an empty space waiting for a new verdict.

4. Read the promise before reacting to the patch

The purpose of a Hermes change is a better starting point than its most interesting line. A contributor is proposing a result: preserve a conversational distinction, normalize a workspace key, coordinate an update, or retain context during a continuation. The reviewer needs to understand what that result means for the participants who depend on it. Without that understanding, elegant source can be admired or criticized against an invented requirement.

Read the proposal’s explanation and linked issue. Notice the reported experience, the behavior that should replace it, and the boundaries the author says are included. A title is useful shorthand, but the body and discussion may contain a narrower promise. A change can address one part of a larger issue while leaving another part separately owned. A reviewer should make that relationship clear instead of silently expanding the author’s responsibility to every nearby problem.

The first light example comes from Hermes PR #130909, proposed by dskwe to preserve the compaction summary cache prefix. In this setting, compaction changes the representation of conversation history so the agent can continue working with a manageable context. Axl’s historical review found that a producer distinction survived the first reload but disappeared from an intermediate history used by a later persistence cycle. The beginner’s lesson is simply that “the first reload is correct” and “the distinction survives its required lifetime” are different promises. Axl’s review at revision 8069537.

You do not need the reproduction machinery to understand why that distinction matters. A user experiences the continued conversation, including later turns and restarts. A passing observation at one point in that continuity can be useful while leaving a later point unanswered. The review became informative by identifying which promise had been established and which remained. The advanced course follows the actual source, evidence, and repair closely. Here, retain the simpler question: how long must the meaning introduced by this change remain available?

Purpose also guards against the reviewer’s preferences becoming accidental product policy. Hermes may deliberately preserve a piece of state across a continuation while refreshing it for another kind of event. That difference can be essential to the user’s task. A reviewer who prefers a cleaner-looking uniform rule should first understand the intended distinction. Simplifying source is valuable when the simpler source still fulfills the promise. It is not evidence that the promise should be changed to suit the simplification.

The proposal’s words can hide ambiguity. “Preserve context” might refer to visible message text, the workspace behind it, or information used to construct the system prompt. “Same workspace” might mean the same path spelling, the same resolved location, or the same physical directory. “Exclusive update” might mean one command begins at a time or that every effect remains under one owner. A beginner can contribute by asking which meaning the change promises, even before knowing how the repository implements it.

A useful question identifies the unresolved object. “What context is intended to survive this continuation?” is clearer than “this seems risky.” “Does this claim cover another persistence cycle?” is clearer than “needs more tests.” The question should give the author something specific to answer. If the source and discussion already provide that answer, the reviewer should incorporate it and move on. Review is a process of learning enough to decide, not a performance of permanent uncertainty.

Reading purpose first also helps recognize a legitimate narrow change. A fix to one timestamp rule need not redesign every conversation-state feature. An update ownership repair need not become a new plugin architecture. A reviewer may notice a broader opportunity, but should explain its relevance or keep it separate. The project benefits when a bounded proposal remains reviewable and related debt remains visible under its own owner. Conflating the two can slow sound work without resolving the larger question.

By the end of this chapter, the beginner’s contribution is tangible: translate the proposal into a sentence about intended behavior before writing a sentence about alleged failure. Identify who or what depends on that behavior. Keep the implementation preference separate from the requirement. Then assess the code in the context of the promise the contributor actually made. Hermes supplies complex examples of that discipline, but the first move is accessible to anyone willing to read carefully.

5. Keep the revision inside the question

Hermes is an active repository. A contributor can push a repair while another reviewer is still reading an earlier version. A surrounding implementation can change on the main branch. A linked discussion can describe an old limitation that no longer applies. These are ordinary features of collaborative development. A review becomes misleading when it treats the moving conversation as if it were one unchanging source artifact.

Pin the exact head and base before this review begins, and keep both unchanged until it is complete. The repo can continue moving while you finish that bounded assessment. A beginner should attach a technical observation to the version it describes. “At this revision, this path drops the distinction” has a clear object. “This PR drops the distinction” can become ambiguous after a new commit. The purpose is not to make every comment cumbersome. It is to keep the observation usable when the author responds, when another reviewer checks it, and when someone later reads the discussion to understand how the repair happened.

In the compaction example from the previous chapter, the named historical review belongs to a particular source revision. A later assessment belongs to a later revision. Both can be useful. The later result does not turn the earlier finding into a mistake simply because the defect has been repaired. The earlier result does not establish that the later code remains broken. The review record becomes clearer when the reader can see the sequence: observation, proposed correction, changed artifact, and updated assessment.

The same distinction applies to the base of a comparison. A diff does not show “all changes” in the abstract. It shows the difference between two selected versions. If the reviewer compares the proposal against a source that already contains unrelated changes, the resulting interpretation may assign a behavior to the wrong cause. At introduction level, you need not master branch ancestry. You should understand why the sentence “this change introduced the behavior” requires an appropriate comparison rather than only a failing observation on one tree.

A review can find an important pre-existing problem while examining a proposal. That result should retain its value and its origin without being falsely attributed to the current contributor. The reviewer can explain whether the proposal depends on the affected path, whether it leaves the broader issue open, and whether a separate issue owns the repair. In Hermes, where related state and lifecycle work can proceed concurrently, this distinction helps contributors improve the system without inheriting responsibility for every historical weakness nearby.

Time also changes the meaning of reported checks. An author may have run a relevant selection at an earlier head. A reviewer may have executed a narrower check at the current head. Both observations deserve accurate labels. A broader old result is not automatically stronger evidence for today’s artifact than a focused current one. Conversely, a new focused result should not be advertised as a complete rerun of the old selection. Each receipt should say what it actually describes.

Agents can perform these comparisons and organize the history. An agent can retrieve a pinned source, compare commits, reconcile earlier findings, and identify a changed premise. It can also make a mistake if it loads a moving branch while writing about an older review or summarizes an old test count as a current result. The repair is to keep source identity and evidence identity explicit in the work. Adding a person to the workflow does not fix a mislabeled artifact by itself. The artifact needs to be identified correctly.

For a new reviewer, the most accessible habit is to notice movement. An author’s reply includes a new commit: record it, finish your pinned review, then inspect it in a separate re-review whose comparison base is the previously reviewed head. A review links an older head: read it as historical evidence. A test summary lacks a source revision: determine which artifact was tested before extending its conclusion. A comparison calls a behavior new: ask what it was compared with. These are reading skills that improve technical judgment long before you can independently investigate every source path.

Keeping the revision inside the question makes disagreement easier to resolve. Two participants may both be correct while describing different artifacts. Once the versions are named, the team can compare the actual claims rather than arguing over a sentence whose object has changed. That is one reason source identity belongs in knowledge mapping: it gives a technical conversation a stable place to stand while the software continues moving.

6. The patch is a window, not the whole room

A Hermes diff shows where a contributor edited. It cannot display every relationship that gives those edits meaning. An unchanged caller may consume the changed result. A stored record may come from an older version. A desktop reader may interpret state written by a command-line path. A provider may receive a representation prepared several steps away. The reviewer uses the diff to locate the change, then learns enough of the relevant surroundings to assess its promise.

That does not mean every review requires a complete repository census. Scope should follow the proposed behavior. A correction to one displayed message may need a small surrounding explanation. A change to workspace identity needs attention to what identifies the workspace and what later relies on that identity. An update ownership promise needs attention to participants that act during the claimed interval. The right surroundings are the ones required to understand the consequence being assessed.

A second light example is Hermes PR #124787, proposed by lihongyuan99 to normalize the workspace pin key to a resolved path. Axl’s historical re-review distinguished the captured workspace bytes from the identity recorded alongside them. It credited repaired cases and identified remaining questions about workspace ownership and capture-time identity. The introductory lesson is that two valid-looking values may still fail to describe the same thing at the time the system needs them. Axl’s re-review at revision 4a90a34.

A path is a way of referring to a location. A snapshot is information collected from some source. A stored identity is a claim about that source. Understanding each object separately is necessary, but the user depends on the relation among them. The free course leaves the exact review probes and repair obligations to the Masterclass. Here, notice the question the relation creates: what connects the context being used to the workspace it is supposed to describe?

This way of thinking is useful for reading an agent system. The text an agent sees may be a representation of a file, a conversation, a configuration, or a tool result. A representation can remain well formed after its connection to the relevant source has changed. A field can exist without having the intended meaning. A label can remain familiar while the underlying object has moved. Review asks about those connections because the system’s later decisions depend on them.

An agent reviewer can follow the connections through source and artifacts. It can identify a consumer, inspect where a value originated, or examine what a transformation retains. That is substantive engineering work. The important boundary is the part the reviewer actually establishes. A source traversal that identifies a likely consumer is useful; a conclusion about native filesystem behavior needs evidence appropriate to that environment. The reviewer should identify the remaining boundary instead of quietly treating it as crossed.

There is a temptation to turn any unseen path into a claimed failure. Resist it. The fact that another consumer may exist is a reason to investigate or state a limitation. It is not evidence that the consumer behaves incorrectly. There is an opposite temptation to treat the edited function’s local correctness as a complete answer. That can be equally weak when the proposal concerns a relationship beyond the function. The useful middle position is a concrete scope and a conclusion attached to the actual work.

The scope can also include what should remain untouched. A change to workspace normalization should preserve legitimate aliases or other behavior the proposal intends to support. A review that removes capability to eliminate one uncertain case may make the software worse. Understanding the surrounding room includes understanding the successful behavior users already rely on. A reviewer needs that context to distinguish a repair from a change in the product promise.

For beginners, the visible patch supplies a practical starting point. Name the edited object. Name the promise it participates in. Identify the next relationship required to understand that promise. If the relationship is already clear and bounded, say so. If a material part is unresolved, name it precisely. This habit gives the reviewer a way to grow outward from source without pretending that one glance at the diff establishes the whole system.

7. Build a shared explanation, not a pile of reactions

A Hermes review can contain source links, inline comments, a review body, test observations, replies, and later corrections. The value comes from how those pieces connect. A collection of individually plausible sentences can still leave the maintainer unable to understand what is wrong, what is already sound, and what would resolve the uncertainty. Knowledge mapping gives the discussion a shared object: an explanation of the proposal’s behavior and the basis for the decision.

At introduction level, the map can be expressed in ordinary prose. The contributor wants a context distinction to survive. A transformation handles that distinction. A later participant depends on it. The reviewer has an observation about the connection. That observation supports a limited conclusion. No special format is required to recognize those relationships. A table, diagram, or structured export can help later, but a beginner should first be able to state the connection clearly in a sentence.

A useful explanation separates the purpose from the implementation and the observation from the interpretation. The purpose describes what should happen. The implementation is the artifact being assessed. The observation describes what was inspected or executed. The interpretation explains what the observation means for the purpose. When a review blurs those roles, the reader cannot tell whether a statement comes from a requirement, a source fact, a test result, or the reviewer’s inference.

Hermes makes the distinction tangible because the same information can have several roles over its lifetime. A message is received from a surface, becomes input for the agent, may enter storage, and may later be replayed. A reviewer may know that one representation contains a field while still needing to establish what happens after another transformation. A shared explanation identifies which stage is under discussion. That prevents participants from answering a question about one lifetime with evidence about another.

The map also includes disagreement. An author may supply a caller that changes the reviewer’s interpretation. A second reviewer may identify a missing state. An agent may execute a control that defeats an attractive causal explanation. Each contribution changes the shared understanding. The record should show the changed premise and updated conclusion. It need not preserve the first explanation as the winning story merely because it was written confidently or arrived first.

A strong comment can therefore be short. It may identify the observed condition, the source relationship, and the consequence for the promise. A strong review body may connect several such comments to one underlying obligation. More wording helps when it makes a difficult argument easier to inspect. It harms when it repeats uncertainty or turns one mechanism into a list of disconnected accusations. The amount of prose should serve the reader’s ability to decide what the review establishes.

Agents can help build and maintain this explanation. They can synthesize records while retaining source identity, separate a newly observed fact from an earlier finding, and update the map after a repair. They can also accidentally absorb prior contributions into a fresh summary or replace a careful qualification with a broad verdict. That is why summarization is engineering work with its own obligations. The summary must preserve the relationships that made the underlying evidence meaningful.

For the beginner, useful review language follows the map. A question identifies information that is needed. A finding describes an established conflict with the promised behavior. A suggestion offers an improvement without pretending the present implementation is defective. An assessment explains what is supported and what remains open. These forms can coexist in the same review. Keeping them distinguishable lets the author respond without having to decode whether a preference is being presented as a requirement.

The resulting record should let another participant continue the work. They should be able to locate the source being discussed, understand the promise, identify the evidence boundary, and see the remaining decision. In Axl’s approach, that continuity is part of review quality. The explanation belongs to the shared engineering record, where future people and agents can use it, challenge it, and improve it without reconstructing the whole conversation from scattered reactions.

8. Know what you know before you post

Axl builds Hermes with Hermes. That matters to this course because agents are part of the engineering work it teaches: reading source, investigating behavior, implementing changes, examining evidence, and reviewing committed artifacts. Hermes is also the system being improved. Her architecture gives this work continuity through memory, sessions, tools, skills, and delegated tasks. The review has to account for that operating system around the model. All Gods Must Die, Section 2, pages 8–11.

Consider what changes when a codebase is also the agent’s own working body. Moving a function can change how her tools behave. A documentation correction can change what users believe she can do. A reusable procedure can shape a later investigation. Review becomes a way to help the system grow while keeping its behavior and history legible. The work is practical: source files, executed checks, relationships, and records that another participant can inspect.

An agent can carry a substantial responsibility. It can inspect a subsystem, follow its consumers, investigate a failing path, implement an agreed change, or assess a committed artifact. Another agent can investigate from a different position. The useful question is what each role must establish and what evidence its result supplies. The work is not confined to suggestions that a person must then perform manually. Agents can execute the actual work and reach supported decisions within their assigned responsibility.

Axl’s public Hermes campaign used agents as analysts, adversarial witnesses, adjudicators, implementers, and fresh reviewers. Coordination kept the contributions connected. Executable checks examined properties the change needed to preserve. Each responsibility produced an artifact, and each acceptance decision had an evidence boundary. The advanced course explains the architecture in detail; the introduction establishes what agent review means in this setting. All Gods Must Die, Section 6, pages 24–27.

A reader can ask what was inspected, which version was examined, what the reviewer could see, what behavior was exercised, and which observation could challenge the result. Those questions apply to work produced by people and agents alike. A person’s confidence does not supply a missing execution receipt. An agent’s correct execution does not stop being evidence because an agent ran it. Authority follows the responsibility and evidence relevant to the property being assessed.

The paper records an instructive case in which a moved Hermes collector no longer used the dependency location an existing test patched. The test appeared green, but the intended connection between its arrangement and the running code had changed. An adversarial reviewer caught that gap. The introductory lesson is accessible: the result of a check needs a real connection to the behavior named in the claim. An agent can investigate that connection and produce an inspectable finding. All Gods Must Die, Section 8.3, pages 29–30.

Independent challenge matters because a producer’s explanation can reproduce its own mistaken premise. That limitation applies to human and agent producers. A separate investigation can discover something the first missed; a mechanical check can establish a property without relying on the explanation. Independence still has limits. Agents may share assumptions, and agreement alone does not guarantee truth. The paper states that boundary explicitly. All Gods Must Die, Section 9 and Section 26.2.

This is the basis for knowing what you know before publication. State which conclusions come from inspected source, which come from executed behavior, and which remain proposals or unresolved questions. Credit the participant who supplied the work. When a correction becomes a regression check or an explicit source record, the next session can inherit an improved system rather than only a memory of a conversation. Review participates in that improvement.

The responsibility at publication is to preserve the supported meaning. A generated summary can be useful, but its fluency cannot enlarge the scope of the evidence it summarizes. A human-written summary has the same restriction. An agent-produced decision can be substantive, but it should remain attached to the artifact and responsibility it assessed. The beginner should learn this distinction without being taught that agent intelligence is limited to brainstorming or that human identity automatically certifies a result.

9. What the available evidence actually says

In Hermes review, evidence is something that helps decide a particular claim about an identified artifact. Source inspection, an executed test, a contributor’s reported result, a user experience, and a design explanation can all contribute. They do not contribute the same thing. Reading them accurately is one of the most useful skills a beginner can develop before learning the Masterclass’s detailed evidence methods.

Source inspection establishes facts about the code at the revision inspected. You may see that a transformation retains a field or that a caller applies a guard. That is useful information. To conclude that a user experiences a particular outcome, you may also need to understand whether the path is reached and what later participants do. Source is not weak evidence; its strength depends on the sentence it is being asked to support. A precise source claim can be more useful than a broad execution claim that never reaches the relevant behavior.

An executed check establishes an observation under its actual conditions. The conditions include the artifact, environment, inputs, substitutions, and assertions. A passing result can be decisive for the property the check genuinely observes. It can leave another property unresolved. A test’s name and an author’s description help locate its intended purpose, but the implemented assertion determines what the test actually accepts or rejects. Those can differ without anyone having intended to mislead the reader.

The third light review example comes from Hermes PR #126167, proposed by JoaoMarcos44 to preserve prompt pins across synthetic turns. Axl’s review separated an implementation repair from the committed regression test’s sensitivity. A later human turn occurred before the durable assertion, so the passing observation did not by itself establish the earlier write the test was supposed to protect. Axl also credited z1gon, public handle ehz0ah, for a separate fixture finding. These were distinct contributions. Axl’s review at revision cebeaef4.

The introductory point is about observation, not a recipe for probing the subsystem. A check can see the desired state while another operation supplied it. To understand the result, the reviewer needs to know what the observation distinguishes. The Masterclass examines the actual review evidence and its limits. Here, take away a reading question you can use immediately: does this result establish the particular operation the surrounding sentence claims it establishes?

Contributor-reported results should retain their attribution. An author may publish a broad test selection while a reviewer independently examines a focused component. The review can discuss both, but should say which results were independently executed and which were reported by the contributor. This is not a contest over whose checks count. It keeps the evidence chain understandable. An attributed integration result and an independently executed component result have different origins and may answer different questions.

A user report also has a role. If a Hermes user says a resumed task lost its context, that describes a consequence the repair may need to address. It does not identify the responsible function by itself. The investigation can connect the experience to source and execution. Dismissing the report because it lacks a tidy test can discard the problem the change was meant to solve. Treating it as proof of one guessed cause can be equally misleading. The report supplies a real question that needs an explanation.

Logs and screenshots record selected aspects of an event. A log can show that a continuation was scheduled without establishing that it later executed. A screenshot can show a setting without establishing that the active provider received it. The distinction does not make the record useless. It helps the reviewer connect the artifact to the claim it actually supports. When the claim concerns a later boundary, another observation may be needed at that boundary.

Negative observations need care as well. A search with no match establishes something about its search surface. A passing selection with no failures establishes something about the scenarios and assertions it exercised. Neither establishes that no defect exists anywhere in Hermes. A useful review makes the scope of the negative result visible. That lets another participant decide whether the result is sufficient for the proposed change or whether an important surface remains unexamined.

You can now read a test summary, source link, or reported result with a more useful question than “does this look convincing?” Ask what sentence the artifact can support. Ask whether the source, observation, and conclusion concern the same revision and behavior. Ask whose work supplies the result. These are accessible habits, and they make the later advanced methods intelligible rather than turning them into impressive names detached from engineering decisions.

10. What a review can responsibly conclude

A review of Hermes should end with a decision the next participant can understand. That decision may be that the assessed behavior is supported, that a demonstrated defect remains, that a material requirement is unresolved, or that the evidence is insufficient for a particular claim. These outcomes are useful when they are clear about their object. A vague verdict leaves the contributor guessing what work remains and leaves the maintainer guessing what the review established.

A supported conclusion names the behavior and scope. For example, a review can establish a particular context-preservation property in the exercised path without claiming that every possible conversation lifetime is covered. It can establish that a proposed guard agrees with the specified event distinction without claiming that all adapters have been examined. That width is not a weakness when it matches the proposal’s relevant obligation. It is an honest account of what the evidence permits the team to rely on.

A finding needs more than an interesting source pattern. It identifies a conflict between the implementation and an intended result, with a supported consequence. If the reviewer observes that a value is absent but has not established what the absence means or whether the path is reached, the review may still contain a useful question. Calling it a confirmed defect would outrun the evidence. The distinction helps a beginner contribute without disguising uncertainty as technical authority.

A requirement can also be genuinely unresolved. Hermes behavior may depend on whether a continuation should preserve an existing prompt identity or receive new authoritative inputs. Code can implement either rule neatly. The reviewer needs the intended distinction to assess correctness. If the proposal and prior discussion do not establish it, the useful result is to expose the decision that must be made. The reviewer should not silently choose the requirement and present the choice as a code repair.

An evidence gap is different from a demonstrated failure. A native platform path may remain unexecuted in a review that establishes another platform’s behavior. That gap can matter to release confidence, and it should remain visible. It does not become a reproduced native defect merely because the source concern is plausible. Conversely, the lack of native execution does not prove that the concern is harmless. The team needs to understand which claim is established, which is inferred, and which awaits the relevant observation.

Decisions can be made by agents working within an assigned review responsibility. An agent can evaluate a contract, inspect source, execute a check, and recommend acceptance or revision based on those artifacts. Its decision should be traceable and challengeable. A human decision should meet the same standard. The label of the decision maker does not substitute for the evidence. The surrounding project still controls repository permissions and the actual merge or release authority.

Severity and confidence concern different things. Severity asks how consequential the behavior would be under the established conditions. Confidence concerns how well the claim is supported. A serious possible consequence does not make an uncertain path certain. A thoroughly established minor behavior does not become severe because the explanation is detailed. A beginner need not master a priority taxonomy to understand this distinction. It prevents alarming language from doing the work that source and observations should do.

A good conclusion includes what is sound when that matters to the decision. In an agent system, a repair may preserve legitimate ordinary behavior while addressing one problematic path. Crediting that result helps the contributor and maintainer understand the change rather than seeing only a list of objections. It also helps distinguish a needed repair from a redesign that would remove capability. Review is an assessment of the proposal’s behavior, including its successful behavior.

Finally, keep a technical recommendation separate from the repository’s formal action. A review can offer a precise assessment while the maintainer retains the merge decision. A comment can explain why a concern remains without being a repository-enforced block. Clear boundaries improve trust because readers know what the assessment means. The review should finish with the supported decision, its important limits, and the specific remaining question or obligation. That is a concrete handoff, even when the honest conclusion is that additional evidence is still needed.

11. A small edit can belong to a larger promise

The size of a Hermes diff does not tell you the size of its behavioral promise. A small edit can affect information used in later turns. A new field can pass through several representations. A changed ownership rule can affect participants in different languages or processes. Review scope follows the consequence being claimed. Counting edited lines is useful for navigating the artifact, but it is not a reliable measure of how much context the decision requires.

The fourth light example returns to teknium1’s update proposal, PR #132365. Axl’s historical review followed the ownership promise across update, recovery, child lifetimes, and the Desktop reader. A newly correct producer could not by itself establish the whole protocol when another participant interpreted or mutated the shared state differently. The beginner’s lesson is that a system promise depends on the relevant participants agreeing about the shared rule. Axl’s review at revision 0e53955.

That is enough detail for an introduction. The Masterclass explains the actual subsystem analysis, evidence, and remaining native-platform boundary. You can already recognize why reading only the new lock implementation would leave the reviewer without the full object of the promise. The user needs the installation update to behave correctly across the participating work, rather than merely seeing one function acquire something called a lock.

The same reasoning helps a beginner read other Hermes proposals without manufacturing a new finding. A provider setting may be accepted in one interface, resolved elsewhere, and consumed by a backend. A message can be received through one adapter and processed through shared gateway code. A workspace can be selected through a command and later represented in an agent’s context. The reviewer should identify the relevant relationship before assuming that the visible input or local result settles the user-visible behavior.

Surface differences matter. The CLI, desktop application, and messaging adapters may expose related capabilities through different lifecycles. Their implementations need not be identical to serve a shared product promise. At the same time, the presence of a similarly named feature does not establish equivalent behavior at restart, cancellation, or an external service boundary. A useful reviewer asks which behavior is intended to be common and which platform constraints are deliberately different.

Axl’s public paper treats platform alignment as engineering work grounded in actual adapter surfaces and official platform behavior. It distinguishes capability gaps and preserves the ownership of work already being tracked. This introduction retains the accessible point: a feature name is a starting label, and the actual user experience determines what the review must understand. The detailed campaign machinery belongs in the Masterclass. All Gods Must Die, Section 3’s platform-parity account.

A larger promise also needs proportionate boundaries. If the proposal only fixes one reader’s interpretation, the review should not advertise a universal ownership guarantee. If the title does promise the whole update tree, the review should explain which participants supply that guarantee. If another contribution owns an adjacent path, retain that relationship. This gives the author a fair scope and gives the maintainer a record that does not hide unexamined work behind a reassuring feature name.

Agents can investigate those surroundings. They can locate a separate reader, compare rules between paths, and examine where ownership ends. Their work can make a system promise more legible than a single reviewer’s initial local reading. A summary still needs to distinguish the participants actually inspected from the participants only suspected. The usefulness of automation comes from the additional established relationships, not from claiming a complete map merely because a tool produced a large inventory.

For a beginner, the practical question is simple: who or what must rely on this result for the proposed behavior to work? Answering it identifies why an unchanged participant can belong in the review. It also identifies where the review may stop. You do not need to survey all of Hermes because a patch has five lines. You need to understand the participants that give those five lines their claimed meaning, and keep the conclusion inside the relationships actually established.

12. Preserve the capability the change is meant to improve

Hermes is built to do useful work. Review should help preserve and improve that capability. A repair that prevents one failure by disabling the intended feature may satisfy a narrow assertion while failing the user’s actual need. An architectural simplification can be attractive while removing the distinction a conversation depends on. A restrictive rule can look safer while making a legitimate tool path unusable. The reviewer needs to understand successful behavior as well as failure behavior.

This is especially important for stateful agent work. A synthetic continuation has a different role from a fresh authoritative input. A persisted representation has a different role from provider-facing content. A workspace alias can be a legitimate way to reach the same project. An accepted message may remain owed to the user even when another event arrives. Review must keep those distinctions available when a repair changes the surrounding implementation. Flattening them can replace one defect with a quieter loss of capability.

The light historical cases already introduced show why legitimate controls matter to the explanation. The workspace review credited cases that had been repaired and ordinary behavior that remained correct. The prompt-pin review distinguished the implementation result from the test’s observation. The compaction review followed the meaning that needed to survive without treating all metadata as interchangeable. The detailed controls are paid material. The introductory principle is accessible: learn what must continue working before choosing a repair that makes a concern disappear.

A reviewer should resist converting a preference into a new prohibition. If Hermes deliberately supports a feature through more than one surface, the review should assess the intended boundaries rather than demand one interface be removed because it is easier to reason about. If a user-selected behavior is part of the product promise, a repair should preserve it under the relevant constraints. A suggested change should explain which property it restores and what legitimate behavior it keeps.

That does not mean every capability must survive unchanged forever. Product requirements can evolve, and a maintainer may choose a different behavior. The point is to make the change in promise explicit. A reviewer who proposes removing a capability is making a broader design recommendation, and the discussion should identify it as such. It should not be smuggled into a finding whose stated purpose is only to repair an implementation defect.

Successful behavior also informs the interpretation of a suspected problem. A source pattern may look dangerous until the reviewer finds the documented guard that limits it. A state may appear reachable until the actual admission rule excludes it. A proposed redesign may appear necessary until an existing component already owns the responsibility. Finding that explanation is useful work. The reviewer can withdraw or narrow the concern and record why the relevant path is sound.

Agents can establish those results just as they can find failures. An agent investigation that demonstrates an already-covered path can save an unnecessary change. An agent that identifies a legitimate control can prevent an overbroad repair. The requirement is meaningful evidence, not a quota of defects. Axl’s paper records audits whose correct contribution was to establish that the feared bypass was already covered on the inspected surface. Such work improves the system’s knowledge without manufacturing a patch. All Gods Must Die, Section 3.1.

For a beginner, preserve two questions beside one another. What would make the proposal wrong? What must remain right? The first prevents rubber stamping. The second prevents a repair from destroying the capability it is supposed to improve. Those questions are especially useful in agent systems because the intended behavior may involve continuity, autonomy, and several representations of the same work. A narrow source observation can miss both the failure and the successful path.

The resulting review can explain a repair obligation without dictating an arbitrary implementation. It identifies the property the system needs and the legitimate behavior the repair must retain. The author can then use the repository’s architecture to choose the appropriate mechanism. This is more useful than demanding a favorite pattern at every source location. Review earns authority by clarifying the actual promise and its supported behavior, while leaving design decisions with the people and agents assigned to make them.

13. Re-review the changed artifact

A new commit changes the object being assessed. In Hermes, a contributor may repair the exact behavior a review identified, add a regression, adjust the scope of the proposal, or explain a constraint that changes the earlier interpretation. The next useful contribution is an updated assessment of that artifact. Repeating the earlier verdict without examining the repair does not establish anything about the new code.

Re-review uses the previous review as its standard and the previously reviewed head as its change-comparison base. Pin that base and the new head; keep both fixed until the new review is complete. Preserve the earlier findings and acceptance conditions so the author is measured against a consistent standard. Re-review begins with continuity of the question. What was the original concern? Which relationship did the repair change? What evidence now applies? What remains unresolved? The reviewer should retain the original finding’s source identity while assessing the new revision. That lets the record explain progress without turning history into a contest between the first comment and the latest response. An earlier true finding and a later true repair can coexist in the same engineering account.

The compaction example from Chapter 4 provides a light illustration. Axl’s later review at revision 59b3240 recognized dskwe’s repaired history builder and distinguished independently executed component evidence from attributed integration results. It credited the implementation and committed regression separately from the earlier findings. The updated assessment could close the specific lifetime defect while keeping its evidence boundary visible. Axl’s repair assessment.

That is a useful model of intellectual honesty. The reviewer does not need to defend the old objection after the source changes. The contributor does not need to erase the earlier finding to receive credit for a repair. Another participant can supply further verification without becoming the original discoverer. The record gets stronger when the different contributions remain distinct and the conclusion follows the artifact currently being assessed.

A repair can resolve the reported example while leaving a related obligation open. A re-review should say which conclusion has changed and which has not. It should avoid the broad word “fixed” when the established result is narrower. It should also avoid retaining a broad objection when the author has demonstrably repaired the relevant path. The question is what the new evidence supports, including the progress it establishes. Both overstatement and refusal to credit progress can mislead the maintainer.

A new commit can introduce a different issue. If that happens, identify the new behavior and its evidence rather than quietly replacing the old finding with a different objection under the same wording. Finding identity is useful because it shows whether the discussion concerns one repair obligation or several. The beginner need not implement an advanced tracking system to keep that distinction. A clear sentence naming the old result, new source, and remaining issue can make the conversation understandable.

Agent reviewers can perform re-review and reconciliation. They can compare the changed artifact, execute a relevant observation, and update the assessment. They should examine the actual repair rather than using the author’s “addressed” reply as evidence of behavior. They should also retain attribution when organizing a long discussion. A summary that says “we fixed it” may hide the contributor who implemented the change and the reviewers who established distinct requirements. The map should keep those people and roles visible.

Re-review also benefits from stating what was not repeated. If the reviewer independently checked a component while referring to the author’s broader integration result, that distinction should remain in the assessment. If an environment boundary remains unexecuted, do not relabel it as current proof. If the original observation no longer applies, explain why. These statements make the decision useful because another participant can see both the established repair and the important remaining evidence.

The record then becomes a history of increasing understanding. A reported problem prompted investigation. A finding identified a relationship. A contributor changed the implementation. New evidence supported a revised conclusion. The project can learn from that sequence, and future agents can retrieve it without being told that a historical defect is a current verdict. This is why re-review belongs in an introduction: review competence includes the ability to change your conclusion when the reviewed artifact changes.

14. The people are part of the technical record

Hermes is built through contributions from people and agent-mediated work. A proposal has an author. A finding has an origin. A repair can belong to another contributor. A verification result can come from a separate reviewer or agent role. A final synthesis can connect all of them. Preserving those distinctions is part of technical accuracy because the repository’s knowledge comes from identifiable work, not from the last paragraph written about it.

The four light examples in this course retain the proposal authors. JoaoMarcos44 proposed prompt-pin preservation. lihongyuan99 proposed workspace pin-key normalization. teknium1 proposed the update ownership change. dskwe proposed the compaction cache-prefix change and later implemented the repair discussed in the cited assessment. Axl Ibiza authored the review analysis used to teach these introductory distinctions. Those are different contributions, and naming one should not erase another. The original pull request and review links preserve the source records.

The prompt-pin example also shows why discovery and verification should remain separate. Axl’s review credits z1gon, public GitHub handle ehz0ah, for a fixture finding while describing its own test-sensitivity analysis. A later reviewer may reproduce one or both observations. That reproduction can add evidence, but it does not become the original discovery simply because the later summary is more concise. The contributor’s chosen public identity is enough; the reviewer should not invent or expose a different identity. The attributed review record.

Attribution gives future readers a way to inspect the origin of a claim. They can find the first explanation, identify its revision, see what evidence it supplied, and distinguish later amendments. That makes the engineering record more resilient to an inaccurate summary. If a claim changes as it travels, the reader can return to the source. Credit therefore protects knowledge provenance as well as recognizing the contributor’s work.

This matters particularly when agents consolidate material. An agent can retrieve many records and produce one useful explanation. The explanation should preserve who supplied the design, finding, implementation, and verification. It should not claim that the agent invented Axl’s architecture merely because it can describe it. It should not credit the operator with a contributor’s implementation merely because the operator asked for a summary. Synthesis is a contribution, but it has its own role in the map.

Axl’s public paper treats authorship as a load-bearing part of engineering continuity. Its French documentation account preserves iacker’s seed contribution while distinguishing the pipeline, gate, and later review work. The beginner’s lesson is that useful correction and preserved authorship can coexist. Improving another person’s contribution does not require rewriting its origin. The Masterclass explores the fuller contribution record and its relationship to review evidence. All Gods Must Die, Section 17 and the credit account.

Authorship also needs accurate technical boundaries. Being the originator of a method does not prove a particular implementation satisfies it. Being the author of a patch does not prove the patch works. Being credited for a finding does not make every later inference correct. Evidence still decides the behavioral claim. Attribution identifies whose work supplied a premise or artifact so that the claim can be understood and assessed honestly.

A beginner can practice this without elaborate machinery. Read prior discussion. Link the original finding when describing it. Name the contributor who implemented a repair. Attribute a test result that was reported by someone else. Identify a new observation as new verification when it checks an existing finding. If the public record uses a pseudonym, preserve it. If the source does not establish a role, avoid inventing one to make the narrative feel complete.

The final review should make collaboration more legible. A maintainer can see who changed the source and what the reviewers established. A contributor can receive credit without the review concealing an unresolved problem. A future engineer or agent can retrieve the right original artifact. In Axl’s knowledge-mapping approach, people belong beside source and evidence because each contributes to the history through which the system became understandable. That history is part of what review is responsible for preserving.

15. Learn the system without pretending to know everything

Hermes spans conversations, tools, providers, workspaces, adapters, and installation behavior. A beginner can be overwhelmed if code review is presented as a demand to know every one of those surfaces before saying anything. The useful entry is a bounded question with a real source. Learn enough of the relevant relationship to contribute honestly, then expand the scope when the proposal’s promise requires it. This gives the learning a concrete object and avoids turning uncertainty into an invented verdict.

Start with an understandable purpose. The free course’s light examples name accessible questions: does meaning survive the needed lifetime, does context describe its intended workspace, does an observation establish the operation it claims to protect, and do participants share the ownership rule? You can understand why those questions matter before reproducing the detailed investigations. That understanding makes the advanced material easier to learn because the mechanisms will answer questions you already recognize.

Read the public sources as arguments rather than templates. Notice the intended behavior, the source revision, the evidence, the conclusion, and the limits. The structure can teach you what a good review explains. The finding itself should not be copied onto another proposal merely because the new source contains a similar term. A snapshot, a replay, or a lock can participate in a different contract elsewhere. The new artifact needs its own investigation and its own conclusion.

Agents are valuable learning partners and engineering participants. They can explain unfamiliar source, trace an actual path, execute a check, examine alternative interpretations, and produce a supported assessment. Their work should make your understanding more concrete. A useful explanation lets you locate the relevant source and identify what the result establishes. If you cannot tell which artifact a summary describes or what evidence supports its conclusion, seek that connection instead of treating the polished prose as knowledge.

A reviewer also needs to understand access and environment boundaries. You may be able to inspect the source while lacking a native platform or the external service required for a broader execution claim. An agent may have access to one checkout while another role executes elsewhere. The important response is accurate scope. State the material boundary and identify the evidence needed to cross it. Do not turn limited access into either a universal safety claim or a reproduced failure you did not observe.

Learning review should increase useful throughput. That means more correct, completed understanding for the effort spent, including the checks and decisions that make the work trustworthy. Asking every conceivable question can stall a sound proposal. Skipping a decisive boundary can make a quick verdict expensive later. The reviewer’s judgment is to focus effort on the relationships required by the actual promise and consequence. This is why a narrow, established conclusion is often more valuable than a long list of possible concerns.

Existing work is part of that efficiency. A prior reviewer may already have identified the issue. Another pull request may own the repair. A contributor’s explanation may settle the requirement. An already available component may supply the needed behavior. Reading those records before producing a new claim prevents duplicate work and helps preserve coordination. A beginner who learns this habit can contribute more effectively than a reviewer who immediately searches for something new to say.

There will be cases where a sound review finds no defect. There will be cases where the right contribution is a question to the requirement owner. There will be cases where an agent investigation supplies decisive evidence while a human summary adds little. There will be cases where an independent challenge rejects an appealing explanation. A mature approach makes room for all of these outcomes. Review quality comes from how the result advances the project’s understanding, not from forcing the work into one preferred narrative.

You are ready for more demanding review when you can keep the object of the question clear as the system becomes larger. You can distinguish a source observation from a user consequence, a current revision from a historical finding, a contributor’s result from your own execution, and a useful suggestion from a required repair. The Advanced Masterclass develops the methods for doing that work across harder boundaries. The introduction gives you a reliable reason to want those methods rather than a set of slogans to post at contributors.

16. What comes next

You can finish this introduction with a real change in how you read a proposal. You know why Hermes must be reviewed as a stateful agent system. You can identify the behavior a contributor is promising, understand which revision a review describes, and distinguish a source observation from a broader consequence. You can recognize agents as real engineering participants while asking what their artifacts and evidence establish. You can preserve the people who supplied the work. Those are useful skills before any purchase.

The four light review examples show where the next level begins. A compaction change can work on its first reload while losing a distinction needed later. A workspace key can look correct while the relationship between captured context and identity still needs examination. A passing regression can observe state supplied after the operation it claims to protect. An update implementation can be sound locally while another participant remains outside the promised ownership relation. Understanding why those questions matter is the introduction. Establishing their answers is advanced review.

The Advanced Code Review Masterclass follows Axl’s actual Hermes reviews heavily when showing good practice. It examines the source links, reasoning, evidence, controls, contributor responses, repair assessments, and remaining boundaries that make those reviews useful. You see how a serious finding is built, how an attractive explanation is challenged, and how the conclusion changes after a repair. The cases are engineering arguments at named revisions, with the authorship and evidence limits preserved.

The paid course is a distinct course, priced at $179. It does not package or reprint these sixteen introductory chapters. It develops the full original twenty-seven-chapter Code Review as Knowledge Mapping curriculum and the advanced material around it. The two courses have different jobs: this introduction gives you the frame for seeing the review problem; the Masterclass teaches the deeper work needed to investigate and defend the review decision. You can use either course independently at its intended level.

That deeper work spans contracts, causal explanation, subsystem participants, state and lifetime, test sensitivity, compatibility, security boundaries, deployment, and re-review. It treats source traversal and diagrams as ways to make an argument inspectable. It examines the difference between a test that passes and a test that can reject the missing behavior. It shows why a repaired local path can leave a wider obligation unresolved.

The tangible package includes the complete advanced reader and editable manuscript, source-linked SVG diagrams and their Mermaid sources, attributed historical review analyses, developed case chapters, and structured course data. The complete JSON companion is included in the paid course. It preserves the course’s connected concepts and source records in a machine-readable form that an agent can navigate. It is a substantive companion to the teaching, and this free introduction contains no JSON file or extracted data payload.

The JSON matters in the context of Axl’s practice. An agent can use connected source material to retrieve a concept, follow a review relationship, and inspect the originating evidence. The advanced course teaches how to preserve those connections and their boundaries. A structured file does not certify a new proposal merely because it contains an earlier review. The new artifact still needs an actual investigation. The value is a usable, authored source package and the course that explains how its relationships support the work.

The Masterclass also develops the public research behind building Hermes with Hermes. It explains how agent responsibilities, independent challenge, executable checks, and durable records work together in a consequential engineering process. The introduction has shown why those relationships matter. The paid course gives them the technical depth, worked evidence, and connected material needed for serious review. A buyer is receiving a complete body of teaching and tangible artifacts, not another version of the beginner prose or an unverified verdict generator.

This is the offer: learn to construct a review another engineer or agent can inspect, challenge, update, and act on. Learn from Axl’s actual Hermes work, with original findings and contributor repairs credited correctly. Follow the evidence beyond the attractive local result to the behavior the system promises. The Advanced Code Review Masterclass — $179 is the next course for that work. The Introduction stands on its own; the Masterclass earns its place by teaching the investigation this course has deliberately left for the advanced level.

Why the knowledge export is paid

I priced the Advanced Masterclass at $179 in part because it includes knowledge.json: the connected review knowledge I handcrafted through thousands and thousands of successful reviews on the Hermes codebase. I take the consequences of distributing that skill set seriously. I cannot afford to send a concentrated package into the world detached from the judgment required to use it.

The price asks for some skin in the game. If you want the file enough to purchase the advanced course, I expect a commitment to learning the reasoning, studying the evidence, and taking responsibility for the claims you bring to another contributor. You are buying a complete advanced education and its powerful knowledge companion. Paying does not make a conclusion correct or give you authority over the repository.

This Introduction contains no such file. You read the course. Your agent can read the HTML course too; reading an HTML file is entirely compatible with substantive agent engineering. You do not need a JSON download or a purchase to learn this introductory material. The advanced export adds the authored structure and connected source relationships that the paid course develops at depth.

That is the distinction I am choosing for this offer: freely available introductory understanding through a full course to read, and a separate paid commitment for the advanced teaching and complete knowledge export. The anonymous bad-review examples explain why I care about what happens when a powerful review method is used without the responsibility that gives its findings value.

Sources and authorship

This is Axl Ibiza’s free Introduction to Code Review, revised around his work on Nous Research’s Hermes Agent and his practice of building Hermes with Hermes. The review examples are light readings of his public historical assessments. They are dated source records, not present-day verdicts about moving branches. The advanced course contains the detailed analysis and JSON; the two course texts remain distinct.

• Axl Ibiza, MBA — All Gods Must Die: Adversarially Verified Transformation. The public paper supplies the account of Hermes as a stateful engineering system, agent roles, independent challenge, executable verification, documentation work, and preserved authorship. Its campaign evidence describes the historical state reported in the paper. Read the canonical paper.
• Hermes PR #130909 — compaction cache-prefix preservation. Proposal author dskwe. Axl’s lifetime finding is pinned to 8069537bdce8aba21b10bc8c220696465119f84d; his repair assessment is pinned to 59b32400fc7ee259132d45a76c6da15a59aa329e. Original lifetime review, repair assessment.
• Hermes PR #124787 — workspace pin-key normalization. Proposal author lihongyuan99. Axl’s cited re-review is pinned to 4a90a34bad6f7c7b4438b9bd085ff453254a4f92. Original re-review.
• Hermes PR #126167 — prompt-pin preservation across synthetic turns. Proposal author JoaoMarcos44. Axl’s cited review is pinned to cebeaef4f6b0d15b8334d15f75934a78afa1539b and credits z1gon, public handle ehz0ah, for a distinct fixture finding. Original review.
• Hermes PR #132365 — update ownership. Proposal author teknium1. Axl’s cited review is pinned to 0e53955c74ac01dda11dd3367155de419af6ceab. Original review.
• GitHub — platform terminology. Primary documentation explains pull request review states and permanent source links. It supplies interface definitions, not Axl’s agent engineering doctrine. Pull request reviews, permanent source links.

Continue with Axl

Advanced Code Review Masterclass

Study the detailed review investigations, evidence, repair assessments, and connected knowledge behind Axl’s practice. Includes the complete offline course and the authored knowledge.json companion.

$179 USD · One-time purchase

Explore the Advanced Masterclass →