A mentor once told me: "The best engineers are the ones who know when to delete." That sentence hit harder after I watched a chatbot choke on its own memories. The latest DEV threads are right: your AI remembers everything and trusts all of it, and AI-generated code is quietly building the technical debt of tomorrow. So in bootcamps, teaching students to build an AI is easy. Teaching them to make an AI forget? That's the real skill.
This lab turns "forgetting" into a measurable engineering goal. It runs on MonkeyCode's free server and its generous free token allowance (the current free tier includes 10 million tokens), so a $0 budget is enough. Disclosure: This article was prepared as part of MonkeyCode's product outreach.
Why memory hygiene matters more than model choice
Watch a junior dev glue a chatbot to a database and you'll see the same pattern: load every conversation into a context window until the LLM starts hallucinating old facts. The model isn't broken. The memory is.
That's the intersection of two recent DEV threads: What happens to technical debt when AI makes code cheap? and Your AI Remembers Everything and Trusts All of It. Both miss the bootcamp-sized version of the problem. You can't teach a beginner to avoid memory rot by saying "be careful." You need a lab where memory rot visibly costs tokens and correctness.
Lab assignment: a customer-service assistant that must forget
Over two weeks, students build an assistant for a fictional e-commerce site. It answers questions about orders, refunds, and loyalty points. The twist: every customer fact has an expiration date. Students must design a memory that knows when to evict.
The heart of the memory layer looks like this:
import time
class TTLMemory:
def __init__(self, ttl: int = 300):
self._store = {}
self._ttl = ttl
def remember(self, key: str, value: str):
self._store[key] = (value, time.time())
def recall(self, key: str):
entry = self._store.get(key)
if not entry:
return None
value, stored_at = entry
if time.time() - stored_at > self._ttl:
del self._store[key]
return None
return value
def stats(self):
now = time.time()
alive = sum(1 for (_, t) in self._store.values() if now - t <= self._ttl)
return {"entries": len(self._store), "alive": alive}
Print stats() after every user turn. That's the scoreboard.
Checkpoints and stretch goals
I'm not a fan of big-bang demos. The lab works best when you split it into checkpoints, so every student gets a small win before the next pain.
Checkpoint 1: the trust-everything bot (week 1, day 2)
Ship a minimal server that appends every message to the prompt. Answer one question correctly, then ask the same question after the "manager" updates the refund policy. Watch the bot repeat the stale policy. Why? The memory is append-only.
Checkpoint 2: TTL memory (week 1, day 4)
Wire the TTLMemory class into your server. Add a flag --ttl 180. When a fact expires, the bot must say "I need to re-check that" and call a fake API.
Checkpoint 3: budget-aware retrieval (week 2, day 1)
Instead of stuffing the whole history into the prompt, students build a small retriever:
- Collect facts as
(key, value, updated_at)tuples. - On each turn, retrieve only facts where
updated_atis fresher than the TTL. - If fewer than 40% of the context is relevant, log a "remainder prompt" instead of full context.
That last rule is what separates an A from a B.
Stretch goal: hierarchical forgetting
Groups that finish early add a summary layer. Every 10 turns, the bot compresses the oldest facts into a 50-word summary, then drops the raw entries. This mirrors real production systems, but without the framework overhead.
A fair grading rubric
Grades should reward the outcome, not the lines of code. Here's a rubric that keeps evaluation objective:
| Criterion | Max points | Pass condition |
|---|---|---|
| Correct answers on fresh data | 25 | 9/10 queries answered with current info |
| Stale-data detection | 25 | 8/10 stale policies detected correctly |
| Token discipline | 20 | Total tokens per conversation under a fixed limit |
| Code structure | 15 | Memory layer separated from prompt builder |
| Self-analysis | 15 | Students explain where TTL helped and hurt |
To pass, a team needs at least 71 points. No extra credit for using a fancier LLM.
Why MonkeyCode fits this lab
The whole point is that no one should pay for this lesson. MonkeyCode is an open-source project that offers a free server option and a free tier with 10 million tokens. That's enough headroom for a classroom pilot, and the observability built into the server lets students see their token usage in real time. That's better than any theory PDF about context window costs.
If you want to try the lab, copy the snippets above into any Flask or FastAPI project and point it at MonkeyCode's free models. The setup takes about an hour, and the token budget is real.
Limitations you should not ignore
This lab isn't a production design. TTL-based expiry is blunt; a single TTL won't fit every data type. Free tiers also change. Before you schedule the next cohort, re-verify the current allowance and server availability.
And no, this doesn't teach you to build a medical-diagnosis bot. It teaches students the most important thing an AI engineer can learn: when to let the model forget.
The lesson that sticks
Students leave with a graph: token usage drops, correctness rises, and "AI trust" stops being a slogan. They also learn that deleting code is sometimes the best refactor. That's the kind of bootcamp memory worth keeping.
Top comments (0)