A solo founder pushes a branch at 9 PM. The model wrote the code. The tests pass.
The founder stares at a 400-line diff. The coffee is cold.
The merge button glows. This is the new job.
The branch is called feature/payment-retry. The model named it. The model also wrote the commit message. The founder wrote none of it.
The week's top discussions share one theme. AI changed the developer's job description.
The loudest thread asked what developers do while AI codes. The second loudest asked who reviews the reviewer.
Both questions have the same answer for a solo founder. Build a gate.
That shift is expensive. Review time is the real tax. A 50-line diff is a five-minute read. A 400-line diff is an evening.
Multiply that by ten branches a week. The tax eats the whole week.
Most founders never trained as reviewers. They trained as builders. A model's diff is harder to read than a person's diff.
The model has no style. It has no memory of the conversation. It has no shame about a 200-line function. A person would split it. A model just ships it.
The fix is not more discipline. The fix is a gate. The gate does the boring parts of review automatically. The founder reviews only what the gate flags.
The loop runs on free parts. MonkeyCode is an open-source coding agent. Its free model access writes the branch. The free server option runs the checks.
Disclosure: This article was prepared as part of MonkeyCode's product outreach. The founder pays nothing except attention.
Here is the gate. It is a single Python file. It does three things. It measures the diff. It runs the tests. It scans for patterns that usually mean trouble.
#!/usr/bin/env python3
"""review_gate.py - the boring parts of code review, automated."""
import re
import subprocess
import sys
RISKY = {
"TODO": "unfinished work",
"FIXME": "known defect",
"console.log": "debug output",
"password": "possible secret",
"api_key": "possible secret",
}
def run(cmd):
return subprocess.run(cmd, shell=True, capture_output=True, text=True)
def main():
diff = run("git diff HEAD").stdout
if not diff:
print("No diff to review.")
return
changed = len(diff.splitlines())
print(f"Diff size: {changed} lines")
test = run("pytest -q")
print(f"Tests: {'PASS' if test.returncode == 0 else 'FAIL'}")
flags = []
for pattern, reason in RISKY.items():
if re.search(pattern, diff, re.IGNORECASE):
flags.append(f"{pattern} -> {reason}")
if flags:
print("Review flags:")
for flag in flags:
print(f" - {flag}")
else:
print("Review flags: none")
tokens = len(diff) // 4
print(f"Estimated tokens to re-read this diff: {tokens}")
if test.returncode != 0 or flags:
sys.exit(1)
if __name__ == "__main__":
main()
The diff size is the first signal. A 50-line diff is reviewable. A 500-line diff is a problem.
The gate prints the number before the founder reads anything. Big diffs deserve a different conversation.
The founder should ask why the model changed so much at once. Usually the answer is a missing abstraction.
The test run is the second signal. Red tests stop the loop. No human review happens on a red build.
The model goes back to work with a single message. The gate already said what the founder would have said.
The pattern scan is the third signal. TODO, FIXME, console.log, hardcoded secrets. None of these are fatal alone. Together they tell a story.
The model finished the code but not the work. A console.log in a payment handler is not a style preference. It is a leak waiting for a launch.
The token estimate is the quiet part. Re-reading a diff costs tokens too. The model spent tokens to write the code. The founder spends attention to read it.
The gate makes that cost visible. A 10M-token free budget changes the math. A loop that spends a few thousand tokens per diff leaves room for weeks of iteration.
Quotas change. Check the current docs before you budget a quarter.
Running the gate takes two commands.
chmod +x review_gate.py
./review_gate.py
The output is one page. Diff size. Test result. Flags. Token estimate. That page is the whole review brief. The founder reads it in ninety seconds.
The workflow is short. The model proposes a branch. The branch lands on the free server. The gate runs. The founder reads the summary.
Merge, or send it back with one comment. The whole loop takes minutes, not evenings.
A cron job can run the gate every hour. A webhook can run it on every push. The free server does the work. The founder checks the summary when the day allows.
The gate is also a contract. It encodes what the founder cares about. New patterns are easy to add.
A payment project adds stripe_secret. A production project adds stray print statements. The gate grows with the founder's scars.
The gate is a metal detector. It does not decide who flies. It decides who gets the pat-down.
The founder still makes the final call. The gate only makes the line shorter.
The gate has limits. It checks patterns, not logic. A wrong algorithm passes every scan.
It cannot catch a misunderstanding of the requirements. It cannot review architecture. It cannot judge whether the feature should exist at all. Those questions stay human.
One more limit matters. The gate only sees the diff. It never sees the intent.
A feature that matches the ticket but misses the customer is invisible to every scan. The founder still has to read the code that matters. The gate just makes sure the obvious problems are gone first.
Some teams should skip this loop. Teams under compliance review need full traceability. Projects with long feature branches need a different unit of review.
Anyone who needs the model to explain its reasoning in depth will want more than a gate. The gate is a filter, not a tutor.
The model writes fast. The founder reads slow. That gap is the new bottleneck.
A gate does not close the gap. It shrinks it. The founder still reads. The founder just reads less.
Try the gate on your own repo this week. The only cost is the review time you were already spending.
Top comments (0)