DEV Community

Cover image for How I Cut My Code Review Time in Half by Wiring AI into My Terminal
caicaibig-tige
caicaibig-tige

Posted on

How I Cut My Code Review Time in Half by Wiring AI into My Terminal

Last month I was drowning in pull requests. Our team had grown from 4 to 11 engineers in six months, and I was the unofficial reviewer for most backend changes. I'd spend 90 minutes every morning just reading diffs, and by the time I got to the actual logic, my brain was fried.

Then I broke down and actually integrated AI into my local workflow instead of just pasting code into a browser tab like a caveman.

The Problem With Copy-Paste AI

Look, we've all done it. Copy the function, open chatgpt.com, type "review this," paste, wait, copy response back. It works for one-off stuff but it's friction-heavy and you lose context fast. The real issue is that AI lives outside your environment. Your git history, your lint config, your actual project structure — none of that travels with the paste.

Step 1: A Local Diff Summarizer

I wrote a tiny Python script that hooks into git and pipes the diff to a model via API. Nothing fancy:

import subprocess
import os
import requests

def get_staged_diff():
    return subprocess.run(
        ["git", "diff", "--cached"],
        capture_output=True, text=True
    ).stdout

def review_diff(diff):
    api_key = os.environ["OPENAI_KEY"]
    resp = requests.post(
        "https://api.openai.com/v1/chat/completions",
        headers={"Authorization": f"Bearer {api_key}"},
        json={
            "model": "gpt-4o-mini",
            "messages": [
                {"role": "system", "content": "You are a senior reviewer. Flag bugs, not style."},
                {"role": "user", "content": diff[:12000]}
            ]
        }
    )
    return resp.json()["choices"][0]["message"]["content"]

if __name__ == "__main__":
    diff = get_staged_diff()
    if diff.strip():
        print(review_diff(diff))
    else:
        print("Nothing staged")
Enter fullscreen mode Exit fullscreen mode

I bound this to a git alias (git review) and suddenly my morning routine was: stage, run, skim the AI notes, then do my own pass. The model caught two null-pointer risks last week that I'd have missed pre-coffee.

Step 2: Stop Juggling API Keys

The annoying part of the above is every provider wants its own key, its own base URL, its own quirks. When I wanted to A/B Claude vs GPT on SQL generation, I was managing two env files and rewriting the request shape.

I found https://xinghuo1300ai.com which aggregates 30+ models under one API key. I swapped my requests.post target to their endpoint and just changed the model string. No more key spaghetti. For a solo dev or small team this removes a real source of drag.

Step 3: Make It Boring and Reliable

The trap is treating AI like a magic oracle. I set three rules:

  • AI never approves. It flags, I decide. If the script says "looks good," I still read the diff.
  • Cap the input. Truncating at 12k chars above keeps latency under 4s and costs ~$0.002 per run.
  • Log everything. I write the diff hash + AI response to a local SQLite file. Two months in, that log helped me spot a pattern: the model is great at catching missing error handling, useless at judging business logic.

What Actually Changed

After ~6 weeks: my review time dropped from ~90 min/day to ~40. Not because AI reviewed for me, but because it pre-surfaced the boring stuff (unclosed resources, off-by-one in loops, missing null checks) so my human attention went to architecture and intent.

The honest downside: sometimes it hallucinates a problem that isn't there, and I waste 2 minutes confirming it's fine. Net positive still, but it's not free.

If You Try This

Start with the script above. Don't over-engineer. Add a pre-commit hook only after you trust the output. And if you're bouncing between models, tools like https://xinghuo1300ai.com make model switching trivial without rewriting your client code.

For me, the win wasn't "AI in my workflow" as a slogan — it was deleting the alt-tab-to-browser step and keeping my eyes on the terminal where the code actually lives.

Top comments (0)