Team Pride in the Age of AI Development (Supplement): Reviews That Retain Human Judgment

My previous article received many reactions, which surprised me.
It was read more than I expected, and it made me sharpen my focus a bit.

In the previous article, I intended to write it in a way that applied to both individual developers and teams.
However, I might not have fully covered "reviews," which are unique to team development.
Therefore, as a supplement, I will summarize how to approach reviews in this post.

---

How to Approach Reviews

Now that AI can write code, both implementation speed and the number of trial iterations have increased significantly.
Efficiency is unavoidable for both individuals and teams, and there is no reason not to adopt it.

However, the more AI takes over the work,
the more the area that humans should handle concentrates on "judgment."

Judgment here refers to the act of deciding on
assumptions, boundaries, failure handling, and priorities.

AI can make suggestions. It can organize. It can implement.
However, the logic that "it's correct because the AI said so" does not hold up.
That is precisely why we need to reclaim judgment through reviews.

And even if a review passes, the responsibility does not disappear.
Responsibility remains with both the person who created the cause and the person who overlooked it.

In the era where AI writes code,
it is an era where "being able to choose and decide" is more valuable than "being able to write."
That's why individual growth is more important than before.
Because the difference in judgment directly translates to the difference in the team's strength.

---

Design: GAI reduces “omissions.” The team holds the judgment

Many problems that occur in design are "omissions."
GAI is strong at identifying perspectives and helps reduce these omissions.

• Rephrasing requirements
• Identifying exception patterns
• Adding non-functional perspectives

However, GAI does not guarantee the correctness of assumptions.

Because the text it generates is so natural, there are increased risks such as:

• Proceeding with a shallow understanding
• Hallucinations being mixed in

That's why the ethos of a design review is this:

"Turning the AI's proposal into a team agreement."

The more GAI produces, the more important the input (assumptions, constraints, and objectives) becomes.
And evaluating the output requires a deeper understanding than before.
The burden decreases, but the focus of effort simply shifts.

---

Implementation: GAI increases “speed.” Do not let go of judgment

When moving down to implementation, problems shift from "omissions" to "deviations from the design."
GAI speeds up implementation, but at the same time, "plausible-looking implementations" also increase.

Implementation reviews become a task of reliably checking perspectives that must not be missed, rather than scrutinizing every single line in detail.

The order of verification should be as follows:

• Intent: Why is it in this form?
• Boundary conditions: Upper/lower limits, NULL, empty, timeouts
• Exceptions and failure handling: Is it swallowed? Can it be recovered?
• Scope of impact: Impact on other features/layers
• Team conventions: Naming, responsibilities, exception policies, logging policies

Code written by GAI works.
However, "working" and "being correct" are different things.

GAI can prepare the implementation.
But it is the team that judges whether that implementation is "correct" or not.

Two especially dangerous phrases are:

• "Because GAI says so"
• "Because it works for now"

This is an abandonment of judgment, and since no rationale is shared, it leads neither to individual growth nor to team consensus building.

Rephrase them as your own judgment like this:

• "I am using this implementation to satisfy this assumption in the design."
• "I have verified up to this case, but others have not been checked."

The ethos of an implementation review is this:

Passing "maintainable implementation" rather than just "working code"

Certainly, using GAI reduces the burden of writing.
Instead, effort is required to spot differences and stop deviations.
As long as you don't let go of judgment, reviews will be a weapon to protect team quality.

---

Testing: GAI Increases “Coverage.” Fixating Judgment

Using GAI in testing increases coverage. Test data can also be easily created.

You can also utilize it for identifying test perspectives (normal cases, error cases, boundary conditions), generating test case proposals from specifications, and checking for omissions in regression testing.

However, you cannot bake intent into it.
What you want to protect and to what extent you want to guarantee it—the team must take on those judgments.

In testing, the following two are important:

• What you want to guarantee (Acceptance criteria)
• What constitutes a failure (Failure conditions)

The ethos of testing is simple. Testing is the task of fixating judgment in a "non-human-dependent" form.

"Making the judgments agreed upon in the review reproducible through testing."

Testing exists not for the number of tests, but for aligning the team on "what to protect." If that is done, the judgment from the review will withstand the "next change."

---

Summary: AI is a tool. Humans are the ones who use it.

Even if a review passes, the responsibility of the person who created the cause does not disappear.
At the same time, those who review cannot escape the "responsibility of overlooking" it.

Responsibility cannot be delegated.
However, we can create mechanisms so that responsibility is not lonely.

Reducing omissions in design,
stopping deviations in implementation,
and leaving judgment in tests.

Not letting go of judgment.
I believe that is the ethos of a team in the era of AI development.

The speed of creating with AI has increased.
But at the same time, the speed of breaking things also increases.
For example, if "incidental refactoring" or "batch formatting" is mixed in,
the scope of impact spreads all at once.

In both design and implementation, unintended parts end up being changed "incidentally."
That's why we shouldn't outsource the whole thing and instead leave room for human intervention.
That is what it means to not let go of judgment.

Reviews exist across the entire range, from requirements to testing.
That is why we must always approach them with ethos, and we are capable of doing so.

As the last bastion of team development,
AI is a tool. Humans are the ones who use it.
Continuing to uphold that may be the role of reviews in this day and age.

---