DEV Community: MediBlackSand

I Was About to Cancel Claude. Now Gemini Is Rate-Limiting Me Out of My Own Plan.

MediBlackSand — Thu, 25 Jun 2026 06:02:05 +0000

The Almost-Cancellation

About six months ago I was one renewal away from cancelling Claude. Not because it got worse, because I just wasn't opening it. Rate limits I kept hitting on the rare day I did, and a Gemini 3 Pro that had just landed and felt better at almost everything I cared about: Python, JavaScript for the artistic coding side projects (a whole separate post, another day), general "what can this thing actually do" exploring.

Gemini 3 Pro earned the roughly 30 AUD a month on its own. Add the Drive storage I was already half-paying for elsewhere and the image and video generation that was genuinely solid, not a tacked-on afterthought, and the upgrade looked obvious. I downgraded Claude in my head before I'd even opened the app to do it.

Then Something Shifted

Sometime this year that stopped being true. Not Gemini getting worse, Claude getting sharply better: coding accuracy, front-end output, MCP, agent behavior, all of it improving in a way I noticed week to week instead of release to release.

I started running the same prompts through both, mostly out of curiosity at first. Then out of habit, because I kept trusting Claude's answer more often than not. Same task, same wording, and Claude's version was the one I'd actually ship.

The Downgrade

So I went the other way on Gemini. Dropped down to Google AI Plus, the cheap tier, around 15 AUD a month. I wasn't using it daily anymore, and I didn't want to keep paying full price for a tool that mostly sat there.

These days Gemini is what I open for googling instead of the traditional "googling", or for the smaller stuff I don't want eating into my Claude usage. Nothing heavy. Nothing I'd call real work.

And even at that, low-stakes level, I'm getting a lot more "I'm having a hard time fulfilling your request, can I help you with something else instead?" on requests that aren't unusual at all. Just now, checking back in to write this, I've lost access to the better model completely and landed in a flat rate limit. Not slower. Just off.

What This Actually Is

I'm not saying Gemini is bad. Six months ago I'd have written the exact opposite post about Claude, and meant it just as much. What I'm noticing is smaller and more annoying than "which one wins": 15 AUD a month bought me a tool I can poke at, not one I can actually lean on. That's not really a capability problem. That's the cheap tier telling you, politely, that you're not the priority.

Closing Thought

I didn't downgrade because Gemini got worse. I downgraded because I wasn't using it enough to justify the higher plan. But the cheap tier doesn't meet you at "occasional and light," it meets you at "barely worth keeping." Pay less and you don't just get less model, you get less patience for using it at all.

I Built Two AI Tools. The Second One Told Me How I Should Be Learning AI.

MediBlackSand — Thu, 25 Jun 2026 01:46:26 +0000

The Problem

TeachSim taught me LangGraph because the bot had to actually work, with real conversations running through it. GitHub Digest taught me about silent failure modes the same way, by breaking quietly until I went and figured out why. Both stuck because I needed the concept to function, not because I sat down and studied it first.

I already tried the conventional route once. (It probably applies to everything I do and learn throughout my life.) I opened Anthropic's own intro course for Claude Code, the official one, and gave up a few lessons in having retained almost nothing. Nice material, no stakes, nothing to actually break, so nothing stuck.

I want to go deeper into AI engineering now, not just orchestration around an API. Fast.ai for the fundamentals, then something heavier for the practitioner-level material. And I caught myself about to repeat the exact same pattern: open a course, start at lesson one, hope the urgency turns up eventually.

The Discovery

GitHub Digest is supposed to surface tools I wouldn't find by scrolling GitHub Trending. It's already done that for real: RTK, sst/opencode, playwright-mcp, and a course called AI Engineering From Scratch all came out of the pipeline, not a deliberate search.

The course is the part that actually got to me. I've shipped two production-ish projects on Claude Code and OpenCode, and the entire depth of my knowledge of either tool is "enough slash commands and CLAUDE.md conventions to get something running." I've never deliberately learned MCP, skills, subagents, hooks, plugins, or checkpoints. I just use whichever tool happens to work that day.

Stacking real ML fundamentals on top of that felt like a bad idea. I'd be fighting the tools and the material at the same time.

The Setup

Two machines, two networks I switch between. Claude Desktop with filesystem access is the constant supervisor on both: it reads the actual files, checks claims against source, catches scope creep before anything ships. OpenCode, tunneled to a small VPS running DeepSeek through OpenRouter, and the Claude Code VS Code extension are the interchangeable workers that do the typing.

I'd been treating both workers as interchangeable without understanding what makes them different underneath. That's the actual gap.

The supervisor role isn't theoretical, either. Yesterday's task started with the usual pre-flight check: start the tunnel, confirm it's up, then begin. Partway through, OpenCode, running on DeepSeek, killed the tunnel itself and took the whole pipeline down with it mid-task. Claude Code hasn't done anything like that so far. I've now got a "don't touch the tunnel process" rule that only applies to OpenCode, which is a guardrail I built by getting burned, not by reading ahead to Phase 4.

The Plan

Eight phases was designed pulling from three resources, claude-howto, Anthropic Academy's official course catalog, and opencode.school, none of those orderings made sense to follow as is so the curriculum runs on its own sequence instead:

Phase	Theme
0	Foundations (a self-check, not a lesson — already know this)
1	MCP — extend what the agent can reach
2	Skills — formalize what it now knows how to use
3	Subagents — split work across multiple agents
4	Hooks — add guardrails before something destructive happens
5	Plugins — package it all into one install
6	Checkpoints — undo a bad session without losing real work
7	Final Results

Each phase, I get to pick: solve a real problem in one of my live projects, or build against a notable open-source project picked because it's a strong production example, not a toy demo. For Phase 1, the real-project version is wiring GitHub's MCP server into GitHub Digest instead of hitting the REST API directly. The open-source version is installing playwright-mcp, Microsoft's own browser-automation server, and pointing it at something real.

I haven't done either yet. This is a design brief for a course I'm about to do slowly. The rule I'm holding myself to is that a phase isn't done when I've read about it, it's done when it produces a real fix in one of my actual projects.

Why MCP First

It's the one concept every later phase either uses or assumes you've used. Skills often wrap MCP calls. Subagents delegate to MCP-equipped agents. Hooks govern what an MCP server is allowed to touch. Start there and everything later has something concrete to point back at.

It's also the most demonstrable. Watching an agent drive a real browser for the first time is something you see happen. A permission setting from Phase 0 is correct and completely invisible. If I want this to survive contact with my own attention span, the visible payoff has to come first.

What's Coming Next

Skills, subagents, hooks, plugins, checkpoints, in that order, against real projects wherever I can manage it. After that's the actual point: Fast.ai, then the heavier material, with the tools already out of the way instead of competing for attention with the harder stuff.

Closing Thought

The bet is that learning the tools you already use makes you slower before it makes you faster. I could open OpenCode right now and ship something without understanding half of what's available to it. Spending real time on this first is a trade: less momentum this month for not relearning the same tool friction later, while I'm meant to be thinking about something harder. I'll find out if that's the right call once I've actually started.

This is part of an ongoing series: TeachSim, GitHub Digest, and now the plan for the tool-mastery work sitting underneath the next phase of learning AI engineering properly.

Find me on GitHub: github.com/mediblacksand

I Built a Personal Intelligence System That Curates GitHub and News for Me — Here's How It Works

MediBlackSand — Mon, 22 Jun 2026 05:40:18 +0000

I Built a Personal Intelligence System That Curates GitHub and News for Me — Here's How It Works

A personal intelligence system that reads the news and scrapes GitHub for you, curates it with an LLM, and delivers it to your phone before you've finished your coffee. No dashboard. No login. Just three briefings, on a schedule you set.

The Problem

I'd already built TeachSim, a multi-agent system running on an LLM via OpenRouter, delivered entirely through Telegram, hosted on a budget VPS. Once that stack existed, the obvious question was what else it could power. The quickest win turned out to be information consumption itself.

The actual itch was how I was consuming news. Google had been pushing me daily feeds for years: algorithmically chosen, entirely passive. I never decided what showed up, I just scrolled what arrived. I wanted to try the opposite, same infrastructure, a completely different job. An LLM doing the choosing instead of an engagement optimized feed, for both the news I read and the open-source ecosystem I found increasingly interested to keep a tab on day to day.

That second half turned out to matter as much as the first. I don't have time to manually browse GitHub Trending every day, and Trending rewards absolute popularity over genuine novelty. The bet was that an LLM scanning broadly and judging by relevance rather than star count would surface things I'd never have found otherwise.

It has. Real tools the pipeline has actually surfaced for me, not things I went looking for: RTK, sst/opencode, and AI Engineering From Scratch, among others. That alone justified building it: the self-directed version surfaces tools I'd never have found through a popularity-ranked feed.

What GitHub Digest Is

GitHub Digest is a personal automation system that delivers three scheduled briefings straight to Telegram:

A morning news briefing: dozens of RSS feeds across world events, technology, AI research, and a few specialist categories, curated down to a handful of stories that fed into Deepseek V4 Flash and judged actually worth my attention that day.
A GitHub Discovery digest: a wide net of GitHub Search API queries surfacing repos I haven't seen before, tiered into "gem" (brand new, low stars, high velocity), "exploding" (star count accelerating fast), and "hot" (established but trending this week).
A weekly Momentum briefing: tracks a personal watchlist of tools over time and reports what changed, in plain language rather than a star-count delta.

Plus an on-demand command layer, so I can pull any of the three manually from my phone, check system health, or manage my watchlist without touching a terminal.

The Architecture

Sources (RSS feeds / GitHub Search API / personal watchlist)
            │
            ▼
       Scrapers (per-source rate limiting, per-feed age windows)
            │
            ▼
       Analyzers (LLM curation — picks what's actually worth surfacing)
            │
            ▼
       Delivery (Telegram bot, chunked for plain-text limits)
            │
            ▼
   Always-on command listener (on-demand pulls, watchlist management)

Three independent scrape-to-analyze-to-deliver pipelines, each on its own schedule, sharing a single delivery layer and a single listener process. All running on a single-core, 1GB budget VPS, which turns out to be the single biggest constraint shaping every other decision in this build.

The curation step runs through an OpenRouter-routed LLM call: currently a fast, cheap model chosen specifically because curation needs consistency and low cost at high frequency (three runs a day, every day) rather than frontier-level reasoning.

Under the Hood

The model's real output isn't always where you'd expect it, and this one fails silently. The LLM doing curation sometimes returns its actual content in a reasoning field instead of the standard content field, depending on how it worked through the ranking task internally. The first time this happened, nothing crashed and no error appeared anywhere in the logs. The pipeline ran to completion, the cron job reported success, and the briefing that arrived on Telegram was just empty. That's a worse failure mode than a clean exception: an empty message looks like "nothing happened to be newsworthy today," not "something broke," so it took a few quiet mornings before the pattern was obvious enough to investigate. The fix is a fallback chain every analyzer checks in order, content → reasoning_content → reasoning → text, rather than assuming the model will always populate the field the API docs imply it should. It's a one-line change once you know to make it, and an invisible one until you've been burned by it.

Cron doesn't speak the same language as your terminal. Every scheduled job activates the Python virtual environment with . venv/bin/activate rather than source venv/bin/activate, and the reason is more fundamental than a style preference. source is a bash builtin; cron runs jobs through sh, not bash, and sh doesn't recognize it. The job had been tested manually dozens of times in an interactive terminal, where source works fine because the terminal is bash, so the activation line looked correct right up until it ran unattended for the first time, failed to activate the environment, and silently used whatever Python and packages happened to be on the system path instead of the ones the project actually depends on. No error, no crash, just a job quietly running against the wrong environment until something it depended on wasn't there. . is the POSIX-portable equivalent and works in both shells. The fix is one character, but only once you understand why an interactive test can pass while the unattended version of the exact same command fails.

How Repos Actually Get Chosen

"Show me what's new on GitHub" is a bad prompt on its own. You get either noise or the same dozen famous repos everyone already knows about. Getting to a daily handful that's actually worth reading took a few layers of filtering before an LLM ever sees a candidate.

Casting a wide net first. The scraper runs a large batch of targeted search queries across several broad technical categories, each phrased to surface different kinds of repos: some queries hunt for brand-new activity, others for established projects with recent momentum, others for specific technical niches. No single query style finds everything; the combination is the point. The constraint shaping all of it: GitHub's search-specific endpoint caps out at 30 requests per minute, tighter than the general API limit and easy to blow through with this many categories firing in a loop. The scraper sleeps 2.1 seconds between calls, landing at roughly 28 requests a minute: close enough to the ceiling to finish a full run in a few minutes, far enough under it to never trip the limiter. A 403 anyway triggers a full 60-second backoff before retrying, rather than hammering an endpoint that just said slow down.

Code search hides the one number that matters. GitHub's code-search endpoint is useful for finding repos by what's actually in them, not just their name or description, but the nested repository object it returns is missing the star count entirely. Every code-search hit needs a second, separate API call to fetch the full repo record before any tiering logic can run. Skip that step and half your candidates silently sort as zero-star nobodies.

Tiering compares each repo against itself, not a fixed bar. Three tiers, and none of them use a flat "must have N stars" threshold:

Gem: very new (under two weeks old), low absolute stars, but high velocity relative to its own short life.
Exploding: older, but its star count over the last comparison window is accelerating sharply versus its own recent trend.
Hot: established, but trending this week compared to its own historical baseline. A popular repo having an ordinary week doesn't qualify; one having an unusually active week does.

That last distinction matters: a repo with ten thousand stars and no LLM-relevant recent activity is no more interesting on a given day than one with two hundred. What's being measured is change against the repo's own pattern, not absolute popularity.

The LLM is told explicitly not to just rank by stars. The curation prompt frames the task as picking what's meaningful: genuine novelty, technical relevance, and whether it's something I'd plausibly have missed without this pipeline. A repo near the top of the star-velocity list can still get passed over if it's a fork, a tutorial repo, or something with no real substance behind the trending number.

The weekly tracker measures change, not snapshots. For repos on a personal watchlist, every run stores that day's stats and compares them against the last stored snapshot, so the weekly report is a genuine delta (stars gained, momentum direction) rather than a restated current state. The explanation style is deliberately written for someone encountering each tool for the first time, since a watchlist can easily span tools outside what you use day to day.

This watchlist isn't auto-populated the way the daily Discovery digest is. It's a small, deliberately curated set I add to by hand through a chat command whenever something earns a permanent spot. Right now it's three repos: langchain-ai/langgraph (the orchestration framework underneath the multi-agent architecture I run in Teachsim, so a breaking change there has direct downstream consequences for things I've already shipped), pydantic/pydantic-ai (a newer agent framework from a team whose validation library I already trust, worth watching to see whether it earns the same trust in the agent space), and sst/opencode (a coding agent I started to use when Claude is in rate limits or blocked etc, so velocity here is a signal about where that category of tool is heading). None of these were discovered by the pipeline. They're things I already knew mattered and wanted tracked automatically instead of checking manually. The weekly report tells me, in plain language, whether each one had a quiet week or a meaningful one.

How the News Actually Gets Judged

"Is this worth reading" sounds like a single judgment call, but treating it that way is exactly how you get an inconsistent briefing: solid one day, padded with filler the next. The news analyzer runs off a fairly opinionated rubric instead, applied the same way across a few hundred headlines a day.

It's told what not to include, explicitly. No celebrity news, no sports results, no weather unless it's catastrophic, no stock prices, no opinion pieces that don't contain any new information. That exclusion list does more work than any positive instruction: it's far easier to define "not worth your time" precisely than "worth your time" precisely.

It's allowed to skip a category entirely. If a section has nothing worth including that day, the model is told to drop it rather than pad it with a weak story just to fill the slot, and it has to report which categories it skipped and why in a short line at the end. Silence has to be justified, not just defaulted into.

Every kept item earns its place with two sentences, not one: what happened, and separately, why it matters. A story can be true and notable and still get cut if the model can't articulate the "so what" in one clean sentence. That forces an actual relevance judgment instead of a "this happened" summary.

One section is deliberately anti-safe. There's a slot reserved for something unexpected: outside the normal categories, the kind of thing a curious person would find interesting precisely because nobody assigned it there. Without that forcing function, an LLM left to its own judgment tends to pick safe, obviously-important stories and nothing delightful or odd.

The model runs at a low temperature for this task. It's tuned for consistent judgment calls, not creative variation. I want the same story judged the same way today and next week, not a slightly different read each run.

So it's not magic curation. It's a rubric, and the LLM's job is applying it consistently across a volume of headlines that doesn't scale if you're doing it by hand.

Honest State of It

This is a single-user, single-region tool, not a product. It runs on a deliberately cheap VPS with real RAM constraints, which has already ruled out some approaches I considered (self-hosted text-to-speech, for one: the model and codec overhead alone would compete with the always-on listener process for memory). The codebase isn't open source right now while I keep iterating on it.

It's also entirely text-based today. Voice and richer formatting are designed but not yet built, more on that below.

Deepseek V4 Flash via Openrouter seems to be doing a good enough job, it allows me to read the gist of interesting news sometimes behind paywall and there was only once that I read the LLM thinking process rather than the actual news. Re-generating the news fixed it straightaway. Is it providing me a wholesome view of news and the world? Maybe not but it sure beats Google providing me with generic news everyday.

What's Coming Next

Voice layer. The morning news briefing gets a parallel spoken version: a handful of top stories, rewritten for speech (no URLs, no markdown, abbreviations spelled out) and sent as a Telegram voice note via an API-based text-to-speech call. Self-hosting TTS isn't viable on this hardware, so this stays API-based and stays cheap. The cost estimate for daily voice generation lands at a few cents a month.

Email as the primary reading surface. Telegram's plain-text formatting and message-length chunking work fine at the current volume, but there's no rich formatting and no searchable archive: real problems once content volume grows. The plan is to make HTML email the main place I actually read the full briefing, while Telegram steps back to a notification ping plus the voice note plus on-demand commands. Same underlying pipeline, a second delivery path added alongside the existing one, gated behind a feature flag so the live system never breaks while the new path gets built.

GitHub Discovery, scaled up, and the math that constrains it. The plan adds several more topic categories to the search net, which sounds like it just means "more queries," but the 30-requests-per-minute search ceiling doesn't move just because the scope does. Roughly tripling the query count means the per-call sleep interval has to widen too, from the current 2.1 seconds to something closer to 3.2, or the scraper starts tripping the same limiter it was built to respect. The tradeoff is a longer run time in exchange for broader coverage: still comfortably a single-digit number of minutes, just no longer the fastest pipeline of the three. Repo counts per category will also stop being uniform. The categories I care about most get more picks per day, the narrower ones get fewer, and that's a deliberate choice rather than an oversight.(It took me a long time to talk with Claude to decide what fields and topics to track, there are just way too many fields and repos in Github!)

Broader news scope, same constraint-driven approach. The news pipeline scales similarly, more feeds, more output sections, with the per-feed age-window logic (different freshness lookback for daily-cadence sources versus slower-publishing ones) carrying over unchanged, since that part of the design already solved the problem correctly the first time.

None of this changes the core shape of the system. It's still three pipelines, an LLM doing the judgment calls, and a phone that doesn't need an app to receive any of it.

Closing Thought

The bet here is that the bottleneck in personal information consumption usually isn't access, it's triage. There's no shortage of news, and no shortage of interesting open-source work. What's scarce is time spent deciding what's worth reading. Handing that decision to a cheap, fast model running on a five-dollar VPS, three times a day, has been a more useful experiment than I expected going in.

GitHub Digest is a personal project, currently text-only with voice and email delivery in active development. Built with Python, scheduled via cron and systemd, curated with an LLM via OpenRouter.

Find me on GitHub: github.com/mediblacksand

I Built a Three-Agent AI Training Simulator on Telegram — Here's How It Works

MediBlackSand — Thu, 18 Jun 2026 04:27:26 +0000

A working Telegram bot that stress-tests trainees with a pressure character, coaches them in real time with Socratic hints, and scores their performance. All from a single message.

The Problem

Most AI training tools do one of two things: they quiz you, or they roleplay with you. Neither is quite right for professional skill training. A quiz tells you what you know. A roleplay with a helpful AI tells you what you should have said.

The missing piece is pressure. Something that watches how you respond under realistic conditions, nudges you when you're heading the wrong way, and then gives you an honest account of how you actually performed.

That's what I wanted to build.

What TeachSim Is

TeachSim is a Telegram-based training simulation. A trainee starts a session, gets dropped into a realistic workplace scenario, and has to navigate it in real time. What they don't see: two additional AI agents are watching the whole conversation. One is ready to offer a Socratic hint if the trainee stalls or heads in the wrong direction. The other is building a scored performance report that fires the moment the session ends.

Three agents. One conversation. The trainee only ever talks to one of them.

The Architecture

The three agents run as nodes in a LangGraph StateGraph, sharing a single state object that tracks everything (conversation history, escalation level, hints used, resolution signals, scoring dimensions) across every exchange.

User message → Chaos node → Mentor node → [conditional]
                                               │
                                  session_active=False → Score → END
                                  session_active=True  → wait  → END

Each agent gets its own LLM client tuned for its role:

get_chaos_client()    # temperature=0.75 — natural, varied character dialogue
get_mentor_client()   # temperature=0.3  — measured Socratic hints
get_scoring_client()  # temperature=0.1  — deterministic JSON report

All three call DeepSeek V4 Flash via OpenRouter. The model string is deepseek/deepseek-v4-flash. Switching providers means changing one file in the environment.

The Two Live Scenarios

Girls in STEM: Responding to an Excluded Student

The trainee receives a message from a student named Jamie who feels pushed out of a STEM group. They have to draft a reply. The Chaos Persona (Jamie) escalates if the trainee stalls, over-apologises, or writes something technically correct but emotionally tone-deaf.

This scenario is grounded in the Brooks (2025) TALK framework, with three patterns the scoring rubric explicitly tracks: responsiveness (did you address what Jamie actually said, not just the emotional category?), superfluous apology (hedging that signals your discomfort rather than addressing hers), and topic pyramid (connection first, explanation second, practical close third). The mentor reads the trainee's actual drafted reply before deciding whether to intervene, not just a keyword trigger.

Claude Code Assessment

The trainee is assessed by an AI trainer persona, Alex (warm, patient) or Jordan (direct, challenging), against a tiered competency framework before being granted access to Claude Code. Up to 16 exchanges, three difficulty levels, coverage thresholds that change by tier.

Novice difficulty always routes to Alex regardless of selection. Expert difficulty requires 80% coverage across all three tiers before the readiness verdict fires.

Under the Hood

The Chaos Persona escalates. Escalation level runs from 0 to 4 and never decrements. If the trainee stalls, makes repeated mistakes, or produces something clearly off-target, the persona gets more direct and less patient. The trainee can't reset the mood by being polite. They have to solve the actual problem.

The Mentor is silent until it identifies an issue. Mentor triggers are defined per scenario as structured conditions with IDs (MT-01 through MT-99), severity weights, and a max_fires ceiling. The same trigger won't fire twice. When it does fire, the hint appears as a coaching note, separate from the main conversation. The trainee knows the system is watching; they don't know exactly when it will speak.

New scenarios need no Python. The entire scenario definition lives in a JSON file: persona, escalation arc, resolution conditions, mentor triggers, scoring rubric, difficulty variants. Pydantic validates every JSON at startup. Adding a new simulation topic is a schema problem, not a code problem.

Try It

The bot is live at @teachsim_bot. Start a session, pick a scenario and difficulty, and see how the Chaos Persona responds to a weak first reply.

1. Open Telegram → search @teachsim_bot
2. /start
3. Pick a scenario
4. Pick a difficulty (novice / standard / expert)
5. Send your first message

Sessions time out after 20 minutes. The score report fires automatically when the session resolves or the trainee runs out of exchanges.

Honest State of It

Two scenarios in production. Four were built; two are deprecated because the training value is not as high as the two in production. The repo is currently private while I decide whether to open source it. The bot is single-instance, single-region, not designed for concurrent scale yet.

On Open Sourcing

I'm still deciding. There's enough going on here (three-agent LangGraph with per-agent temperature tuning, data-driven scenario schema, Socratic mentor triggering) that it might be more useful as a reference implementation than as a closed tool. If there's interest from people who want to build domain-specific training simulations on top of it, open source makes sense. If you'd use this for something, tell me what.

What's Coming Next

TeachSim was built around workplace and tool scenarios: high stakes, clear right answers, measurable outcomes. The architecture works well for that. But the same three-agent design (pressure character, silent mentor, scored report) maps onto a much older and harder problem: everyday conversation.

I'm planning a second, more substantial simulation platform on the same foundation. This one is grounded in Alison Wood Brooks' conversation research, specifically her work on topic flow, follow-up questions, the patterns that make people feel genuinely heard versus politely processed. The mentor in TeachSim watches for technical mistakes. The mentor in this one watches for the conversational habits most people don't know they have: the question that shuts a topic down instead of opening it, the pivot that signals discomfort, the apology that's really about the speaker.

38 situations are designed across six tiers, from a first meeting and a first date through to emotionally complex, high-stakes conversations. Nine JSON files are built. Two are bot-tested. The architecture is the same; the theory layer underneath is different and deeper.

More on that when it's ready. If conversation science and AI simulation overlap with something you're working on, follow along.

Closing Thought

The bet TeachSim makes is that pressure-testing is the missing layer in AI training tools. Most tools will tell you the right answer after you get it wrong. This one makes you find it under conditions that feel like the real thing. Whether that produces better retention, faster skill transfer, or just higher stress is something I'd like to measure. If you run a session and have a reaction, good or bad, I want to hear it.

TeachSim is live at @teachsim_bot. Built with LangGraph, DeepSeek V4 Flash, and python-telegram-bot. Repo currently private; open source decision pending. A second simulation platform based on Alison Wood Brooks' conversation research is in development on the same architecture.

Find me on GitHub: github.com/mediblacksand

Reference: Brooks, Alison Wood. Talk: The Science of Conversation and the Art of Being Ourselves. Crown, 2025.

In loving memory of Zhang Fu, 1950–2026.