Code Review and Ship: From Paranoid Review to One-Command Delivery

Code review has a universal problem: everyone thinks they're being thorough, but everyone is looking at the same set of issues.

Is the naming clear? Is the logic obviously wrong? Are edge cases handled? These are all valid questions, but they're all surface-level — what actually causes production incidents is usually the deeper stuff:

N+1 queries.
Race conditions.
Trust boundary violations.
Missing indexes that make queries time out under high load.
Retry logic without idempotency, causing state corruption on retries.

These are the things your teammates might not catch in review — because the human brain isn't designed to run five failure scenarios simultaneously.

Gstack's /review does exactly that: systematically, without gaps, scans for high-risk issues.

/review: The Paranoid Senior Engineer's Checklist

/review isn't "help me look at this code." It has a structured review framework behind it that covers these dimensions every time:

Performance and Database

• Any N+1 queries? Database requests being triggered inside loops?
• Do new queries have corresponding indexes? Will high-frequency queries slow down as data grows?

Concurrency and State

• Any unsafe race conditions?
• Is shared state across requests properly protected?

Trust Boundaries

• Is external input being validated?
• Can user input carry malicious payloads that bypass logic?

Error Handling

• Does retry logic have idempotency protection?
• If an external API call fails, is the system state still consistent?
• Any possibility of partial failure — some things written, some not?

Resource Management

• Are connections, files, and memory properly released after use?
• Any orphaned uploads or data isolation issues?

When it's done, /review categorizes issues as "Critical," "High," or "Medium," and gives the exact location and fix suggestion for each — not "there might be an issue here," but "the query on line 47 will start getting slow when user count exceeds 10K, because it's missing an index — add a composite index on user_id."

Greptile Integration: Two-Layer Review Coverage

If your repo is connected to Greptile (an automated PR review tool), /review adds an extra step: reading Greptile's comments and categorizing them:

• Valid issues: added to critical findings, blocked until resolved
• Already fixed: auto-replies to confirm
• False positives: automatically pushes back with an explanation

The design logic: Greptile scans for patterns, Gstack makes judgments — two layers of filtering, lower miss rate. Gstack also records confirmed false positives, so the same pattern gets automatically skipped in the future — it gets smarter over time, no need to re-explain every time.

/ship: The Release Engineer's SOP

/ship isn't "push my code." It's an automated version of a complete release checklist:

1. Sync main — confirm your branch is synced with main, avoid merge conflicts
2. Run tests — run all tests, confirm no regressions
3. Resolve Greptile issues — handle open issues flagged by Greptile
4. Push branch — push to remote
5. Open PR — create a pull request with a clear description

Six steps, one command.

This might not sound complicated, but have you ever had this happen: excited after writing code, push directly, then realize tests weren't run, branch wasn't synced, PR description is empty — then a reviewer bounces it back, and you spend more time cleaning up than you spent writing the feature?

/ship exists so that "this mechanical correct process" doesn't depend on your mental state — whether you're racing a deadline at midnight, whether you just got interrupted by a Slack message — the release checklist executes with the same quality.

The Correct Order: /review Then /ship

Always /review first, then /ship — don't run them simultaneously, don't skip review and go straight to ship.

The reason is direct: /ship only confirms the process is correct, not the code quality. It doesn't care whether you have N+1 queries — it only cares whether the branch is synced and tests passed.

Correct flow:

Implementation complete
    ↓
/review  ← find issues, fix issues
    ↓
Issues resolved, all critical findings addressed
    ↓
/ship  ← run release checklist, push

Sometimes you're confident "this change is small, doesn't need review" — you can skip it, nobody's stopping you. But if something goes wrong, you'll look back and wish you had run it.

One Detail Worth Knowing

When /review runs, it reads your git diff — it's looking at the code you changed, not the entire codebase.

This matters because it means two things:

1. It won't run slowly because your codebase is large — it only looks at the scope of the change
2. The issues it finds are "problems introduced by this change," not "all problems in the entire codebase"

So if you have a large legacy codebase, don't worry that running /review will output hundreds of old issues — it only cares about what you changed this time.

---

Code quality confirmed, delivery process automated — next up is the most unique part of Gstack: giving AI real eyes to actually see your app.

→ QA and Browse: Give AI Eyes to Actually "See" Your App

---

Back to Series Overview

This is the fourth stop in the Gstack series, focused on /review and /ship. For the complete reading path and other post topics, return to Gstack Beginner Course.