Weekend Build Log: A Cheap Technical Debt Radar for AI-Generated Code

Conclusion first: In one weekend, I built a lightweight scanner that flags AI-generated code with a high risk of accumulating tech debt. It runs on free model calls and a free server. The key was cutting scope aggressively, not building a big pipeline.

Recent community threads about technical debt in an AI-heavy workflow keep circling the same problem: code gets cheaper to create, but the cost shows up later. Most teams cannot reliably tell which files came from a model. Even when they can, there is no quick way to estimate how much that code will hurt the next person who touches it.

So I built a tiny radar. It scans a repo, finds files that look AI-generated, scores them on a rough debt risk scale, and publishes an HTML report. Nothing fancy. It just gives a starting point for a human review.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The one-sentence pitch

A CLI tool that takes a repository path and outputs a JSON + HTML report of low, medium, and high risk files.

What I actually built

• debt_radar.py — the scanner and scorer.
• A very basic HTML template to visualise the results.
• A shell script to run it over a test repo.

That is the whole thing. No database. No background workers. No auth.

The scope cut

My first plan had three parts:

1. Scan the full git history and show debt trends over time.
2. Post inline comments on PRs when risky files are added.
3. Support JavaScript, Python, and Java.

All three got cut. I kept only one language (Python), only the current working tree, and no server-side automation. The report is static HTML.

That cut is why it shipped in a weekend.

How the scanner works

Step 1: Find candidate files

The scanner looks for markers commonly left by code generators:

• generated by, auto-generated, or do not edit
• Large single-function blocks with no explanation
• Unusual indentation patterns from model output

A simple regex catches most of it.

import re

def looks_generated(text: str) -> bool:
    patterns = [
        r"auto[- ]generated",
        r"generated by",
        r"do not edit",
        r"spawned by"
    ]
    return any(re.search(p, text, re.I) for p in patterns)

Step 2: Score the risk

I used a small heuristic first, then sent the file to an LLM through MonkeyCode's free model access for a second opinion. The heuristic gives a baseline; the LLM adjusts it based on context like unexplained branches or missing error handling.

def heuristic_score(text: str) -> int:
    score = 0
    lines = text.splitlines()
    if len(lines) > 400:
        score += 10
    if len(re.findall(r"TODO|FIXME", text)) > 2:
        score += 15
    if not re.search(r"def |class ", text):
        score += 5
    return score

The final score is min(100, heuristic + llm_adjustment). The JSON report includes both numbers so you can see where the judgement came from.

Step 3: Host the report

MonkeyCode's free server option lets me host a static page without provisioning anything. I generate the HTML locally and push it with a simple scp command. That covers the demo.

A real run on a test repo

I ran the scanner on a small repository that already had a mix of hand-written and model-generated files.

python debt_radar.py --repo . --output report.json

The output looked like this:

{
  "files": [
    {
      "path": "src/parser.py",
      "heuristic": 35,
      "llm_adjustment": 20,
      "final": 55,
      "reason": "large parser with no exceptions handled"
    },
    {
      "path": "src/utils.py",
      "heuristic": 5,
      "llm_adjustment": 0,
      "final": 5,
      "reason": "looks hand-written and well documented"
    }
  ]
}

From there, the HTML report rendered red, yellow, and green rows. That was the demo.

What I skipped on purpose

• Git history trend — would have required an index and a date-based query layer.
• PR automation — needs authentication, event handling, and a merge gate.
• Multi-language support — each language needs its own style rules and AST parsing.

All of those are valuable. None of them are needed to test the core idea: can a cheap tool tell you where AI code might cause pain?

Limitations

• The heuristic is naive. It misses a lot of generated code that does not carry obvious markers.
• The LLM adjustment is based on a prompt I wrote in thirty minutes. You can improve it, but it will never be precise.
• The risk score is a hint, not a measurement. It cannot replace a human reading the file.
• I only tested it on Python. Your mileage will vary on other languages and codebases.

Who should not use this

• Teams that need strict governance and audit trails. This tool gives opinions, not compliance.
• Teams with a tiny codebase where you already know every file. The noise outweighs the signal.
• Anyone expecting a zero-config product. This is a weekend prototype, not a mature tool.

Final note

If your team is drowning in AI-generated PRs, a $0 fanout like this is a reasonable first step. Run it once, look at the red rows, and decide if the conversation is worth having. I learned more from cutting scope than from the features I originally wanted.

If you want to try the same approach, grab MonkeyCode's free model access and a free server slot — both work without a credit card.