Workshop: Find the Technical Debt Your AI Reviewer Left Behind in 75 Minutes

Recent developer threads have shifted from AI writes code to AI remembers assumptions you forgot. That shift makes technical debt review a skill rather than a one-off cleanup chore. This workshop turns the fear of invisible AI side effects into a repeatable, 75-minute exercise you can run with a small team today.

AI-generated code usually carries context from the conversation that produced it, including stale assumptions about interfaces, cache invalidation, and dependency versions. A structured review passes that context back into the open before it hardens into technical debt. The method below relies on a runnable diff scanner, three contradiction scenarios, and a memory handoff note. You can adapt it to any language or framework.

Why memory makes AI code debt-prone

Large language models generate code consistent with whatever they remember, not necessarily with what your repository currently looks like. A cache read function can survive perfectly while the invalidation rule in another module changes elsewhere. The result is code that compiles but violates implicit contracts.

This is different from human-caused technical debt because the original reasoning trail is rarely visible. Human developers usually leave PR comments; AI assistants leave only a conversation log and a diff. Without reviewing both together, you will judge the code against your own guesses instead of the model's actual reasoning.

The workshop gives you a safe, repeatable way to surface those invisible conditions. You do not need a big codebase or production traffic to make it useful.

Workshop setup and timing

Reserve a repository you can safely fork, a working AI code assistant with conversation logging, and a terminal. Total time is 75 minutes, split into four exercises.

• 0–10: Capture the git range and export the AI conversation log.
• 10–35: Run the debt scanner and interpret the three warning classes.
• 35–60: Work through three contradiction scenarios.
• 60–75: Write a 10-line memory handoff note for the next AI session.

The only prerequisite is access to a git repository with at least one AI-assisted commit. If you want a zero-cost lab, one free-tier option appears at the end of this article.

Exercise 1: Capture a reviewable memory trace

Check whether your AI tool stores conversation logs and which git commit range changed the code. Export the relevant session and the diff together, so reviewers have both artifacts side by side. Without both files, you are reconstructing history instead of verifying it.

git log --oneline -5
git diff HEAD~2..HEAD > review.diff
# export the AI conversation for that session as conversation.json

The exact export format does not matter as long as the conversation is timestamped or named after the branch. Keep the diff and the conversation in the same workshop directory. That small habit makes every later exercise faster.

Exercise 2: Run a dependency-aware diff scanner

Most debt from AI code hides in dependency mismatches, dead fallbacks, and re-invented utilities. This Bash script reads a diff and scores three warning classes: leftover markers, deprecated calls, and duplicate definitions.

#!/usr/bin/env bash
# debt-scan.sh <diff_file>
set -uo pipefail

file="${1:?Usage: bash debt-scan.sh review.diff}"

todo=$(grep -c -E 'TODO|FIXME' "$file" || true)
deprecated=$(grep -c -E '@deprecated|deprecated\(|// deprecated' "$file" || true)
dupes=$(grep -o -E '\b(class|def|func|const) [A-Za-z_][A-Za-z0-9_]*' "$file" | sort | uniq -d | wc -l)

echo "todo=$todo"
echo "deprecated=$deprecated"
echo "duplicate_definitions=$dupes"

Save the script and run it with bash debt-scan.sh review.diff. A score above zero does not mean reject the change; it means read those lines aloud and ask why they appeared.

A zero score is also not proof of health. The scanner only finds textual markers, so your team must still check semantic debt like missing timeouts or stale cache keys.

Exercise 3: The three contradiction checks

Divide participants into pairs and give each pair the same three 5-minute cases. Every case contains one hidden contradiction between the new code and the rest of the repository.

• Case A: The AI adds a Redis client and a cache-read path, but tests bypass the cache entirely. Does the test suite still prove that stale data cannot be served?
• Case B: The AI inserts a new environment variable into the application code. Is there a corresponding default or .env.example entry, or will local setup break silently?
• Case C: The AI rewrites a utility function to use the latest dependency release. Does package-lock.json still pin the old version, creating a gap between declared intent and installed truth?

Use this decision table to record each pair's verdict:

Case	Hidden debt	Accept if	Reject if
A	Missing TTL or invalidation rule	Cache has explicit expiration	Cache grows without bound
B	Missing configuration default	CI fails loudly with clear error	Missing variable is ignored
C	Dependency version mismatch	Lockfile updated together	Lockfile contradicts source code

Exercise 4: Write a memory handoff note

Each pair writes a 10-line Markdown note describing what the next human or AI must remember before touching the reviewed code. The note becomes the seed for the next conversation memory and prevents the same debt from being regenerated.

# Handoff: item cache refactor

- Redis TTL is 300 seconds; do not remove it.
- Tests must run without Redis by using a fake client.
- `CACHE_PREFIX` should default to `dev` in local environments.
- Never call `fetch_from_db` without checking the cache first.

A good handoff note states one invariant per line and avoids general advice. The next AI session can load this file as context, which is more reliable than hoping memory persists across multiple chats.

Worked example and expected output

Consider a small FastAPI endpoint that an AI assistant just modified to use Redis.

from redis import Redis

r = Redis.from_url("redis://localhost:6379")

@app.get("/items/{item_id}")
def get_item(item_id: str):
    cached = r.get(item_id)
    if cached:
        return cached
    item = fetch_from_db(item_id)
    r.set(item_id, item)
    return item

Running the scanner on this diff produces todo=0 deprecated=0 duplicate_definitions=0. The real defect is missing TTL, not a marker, which explains why the scanner cannot be the final source of truth.

The scenario exercise should catch it because Case A explicitly asks how the cache knows when to expire. If no pair mentions TTL, repeat the three case checks with a different code sample.

Free-tier infrastructure option

To run this workshop on a zero-budget lab, MonkeyCode's open-source project provides free model access and a free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

As of this writing, MonkeyCode's current free tier includes 10 million tokens and a free server playground, enough for the entire 75-minute exercise. Verify the exact quota from the README before scheduling a class, since free tiers change frequently.

This option is useful because the workshop only needs a small codebase and a handful of prompts. You do not need a production API key to understand how AI memory creates debt.

Limitations and who should not use this approach

Skip this workshop if your team cannot access conversation logs or if you need a regulated audit trail for every AI decision. The scanner catches textual markers, not semantic mistakes like missing TTLs or stale cache keys.

Free-tier quotas are an availability promise, not a service-level agreement, so production teams should still run their own controlled evaluation. Use this exercise as a training tool, then build a stricter checklist for your real review process.

Run the workshop once with a small safe repository, and you will quickly see which debt patterns are unique to your team's AI workflow. That baseline is more valuable than any single tool or model.