Triage a Codebase into a Human Review List
A small, inspectable experiment with its inputs, decisions and limitations recorded. This guide is not a production guarantee.
Use caseAdd one narrow, explicit decision to code or a workflow
A companion to a codebase-classifier demo: make a review shortlist, not automatic code edits.
Source · vogel · @ryanvogel · X companion
2026-09-21 · Editorial update; no live model call
Problem
Section titled “Problem”An AI-generated repository can contain unrelated helpers and unclear structure. The author shares a Jev codebase classifier. Our exercise is narrower: classify short file summaries into human-review buckets.
Use labels to guide inspection Small scope → Grounded summaries → Role suggestions → Read source → Review change
No automatic deletion or refactor.
Before you begin
Section titled “Before you begin”-
Use a small fictional or authorized dataset. Do not paste private customer data into an unfamiliar service.
-
A current browser for reading. Check the linked project for its own runtime, access and cost requirements.
1. Choose a small review target
Section titled “1. Choose a small review target”Pick five non-sensitive file summaries. Start with only a few labels, such as UI, data access, tests and unclear. Do not upload credentials, private repository content or whole dependency trees.
2. Write the expected labels first
Section titled “2. Write the expected labels first”Label these files yourself and record why an ambiguous file should remain unclear. A directory name alone is not evidence of what a module does.
3. Compare suggestions, not code patches
Section titled “3. Compare suggestions, not code patches”Inspect the source demo, then classify only the summaries through a reviewed adapter. Keep the original path, proposed label and a flag for human review. Never delete or refactor files based on a label alone.
4. Use a different sample to validate
Section titled “4. Use a different sample to validate”Test unfamiliar summaries after changing your criteria. Record disagreements and review time rather than claiming a cleaner architecture from one demo.
Build a review map, not a deletion plan
Choose one small feature directory rather than an entire repository. Record the path and a short, source-grounded description of what each file does. Exclude secrets, customer data, generated files and dependency trees. If another model creates the summaries, record that extra inference stage; a wrong summary can produce a perfectly consistent but wrong classification.
Define a few roles and keep Unclear for mixed or insufficient evidence. A component that fetches data and renders a view is not automatically bad architecture. The label is a suggestion about where a maintainer should inspect the implementation. Preserve links to the actual files.
Validate on files not used to design your criteria. Ask whether the map made review more understandable and which suggestions were misleading. A later refactor is a separate task with dependency analysis, tests and approval. Never turn a model category directly into file deletion, relocation or a claim that code is secure.
| File | Visible role | Suggestion |
|---|---|---|
| UploadButton.tsx | Selects a file | UI |
| uploadRepository.ts | Stores metadata | Data access |
| upload.test.ts | Checks rejection | Tests |
| processUpload.ts | Mixed responsibilities | Unclear |
Fictional repository map, not the author’s scan.
Result and cautions
Section titled “Result and cautions”A small, inspectable experiment with its inputs, decisions and limitations recorded. This guide is not a production guarantee.
- A valid label can still be wrong. Keep a review path and keep irreversible actions outside the exercise.
- A community demonstration is not an independent benchmark. This collection does not reproduce the linked video or repository.
- You can identify the input, its source, and the fields that leave your system.
- Original identities, failed rows, uncertain cases and human corrections remain visible.
- You distinguish an offline fixture, an author demo and a live evaluation you ran yourself.
Source boundary: compiled from the linked public sources; not reproduced here. Review classifications before acting; they do not run actions automatically.
Related guides
Section titled “Related guides”Does this prove code is useful?
Section titled “Does this prove code is useful?”No. Use references, requirements and tests.
Why not send every file?
Section titled “Why not send every file?”Start with a minimal, authorized scope that a person can inspect.