# This repository is a hundred dated directories of live-coded AI sessions > ai-that-works is not a library. It is the archive of a weekly show, with one top-level directory per episode, each holding whatever code was written on air that Tuesday, plus a makefile for one episode's app. Reading it is a way to see working code for problems the documentation does not cover, and the directory names are a better index than any changelog. **ai-that-works/ai-that-works** — 🦄 ai that works - every tuesday 10 AM PST - Repository: https://github.com/ai-that-works/ai-that-works - Website: https://www.boundaryml.com/podcast - Stars: 1,981 · Forks: 145 - Language: TypeScript - License: not declared - Published: 2026-09-30 · Updated: 2026-09-30 · Language: en - Canonical page: https://hysenlabs.com/projects/ai-that-works-ai-that-works ## The directory listing is the product, and it reads as a syllabus There is no library here, and the fastest way to understand the repository is to read its top-level entries as a table of contents. Every entry is a date, and the dates are weekly, so the listing is a curriculum. Read across a few months and a coherent syllabus emerges without anyone having written one. Early entries are about large-scale classification, reasoning models versus prompts, and code generation with small models. Then design work: twelve-factor agents, designing evals, policies turned into prompts, and an episode on working with a very large tool catalogue. Then context: context engineering, decaying resolution in memory, multimodality, and advanced context engineering for coding agents. Then evaluation again, several times over, including a session on evaluating many models against the same prompt and a later one on evals for classification specifically. Then agent reliability: interruptible agents, event-driven agents, agentic backpressure, and coding agent tools comparing bash against a tool protocol. Then the operational layer: latency, worktrees, email as an interface, PII redaction and sensitive data scrubbing, and dynamic schemas. Read the list and you can see what a working group thinks about each week, which is more informative than any single episode. ## What you actually get in a directory The top-level entries are directories, one per session, and their names are dates plus a slug, so a directory can be checked out on its own if you only want one episode. Inside a typical directory you would expect the code that was written live: a Python script, a small service, prompts, and configuration. The top-level listing shows this directly for one of them, where a whole application has a backend and a frontend with its own dependencies, and a makefile at the repository root wraps the commands. That application is the exception rather than the rule, and the exception is instructive, because it is the one case where the code was substantial enough to need a database, an OAuth setup step and separate development servers. Most entries are closer to demonstration code: enough to run, not enough to depend on. There is also a committed desktop settings file, an environment file for direnv, and editor configuration at the root, which tells you this is a working directory someone uses rather than a curated collection. The presence of assistant configuration at the root suggests the episodes are partly prepared with an AI coding tool, which is consistent with the toolkit the readme lists, including an agentic coding tool alongside a cursor-like editor. ## One episode is a real project with a makefile, and it shows the pattern The makefile is the only build tooling described in the repository, and it belongs to a content pipeline episode. It opens with a help target listing its commands, each of which is a single line of shell wrapped in an echo. The setup target changes into a backend directory and syncs dependencies with a Python package manager, then changes into a frontend directory and installs with the JavaScript package manager, then prints its own next steps: set up the database, configure OAuth, and copy the example environment files and fill in credentials. That help output is a decent small model of how to structure a demo project, and the separation between a backend on a port and a frontend on its own dev server is conventional rather than exotic. The development targets follow the same shape, starting a backend server with a Python web server and a frontend dev server, and the test targets are honest about their state, echoing a message and tolerating failure when no tests are configured. The database target is described as showing setup instructions rather than performing them, which is a sensible choice when the backend provider is not fixed. Nothing about this is unusual, and that is the point: a session that builds a real application produces a real project, and the makefile is the proof that it was meant to be run rather than only read. ## Running one of the episodes There is no install for the repository as a whole, so the useful entry point is a single directory. For the content pipeline episode, the documented commands come from the makefile, and the development path is the informative one because it shows the toolchain the session assumed: ```bash cd 2025-06-24-ai-content-pipeline/backend && uv run uvicorn main:app --reload --host 0.0.0.0 --port 8000 ``` ```bash cd 2025-06-24-ai-content-pipeline/frontend && npm run dev ``` A Python web application server with a reload flag on port 8000 in the backend, and a frontend dev server on its own port, is the whole architecture. If you prefer not to use the makefile, the setup steps it prints are the same commands in the same order: sync the backend, install the frontend, read the database instructions, configure OAuth, then copy the example environment files and supply credentials. The readme's own pre-reading list names the same tooling for the show as a whole, with a Python package manager for Python, a JavaScript package manager for TypeScript, Go modules for Go, and a prompting domain-specific language as the prompt layer. For everything except the content pipeline episode, expect to read rather than run, and expect the session's own README or notes inside the directory to be the only instructions that exist. ## The show format explains the shape of the code The readme is a promotional page for a weekly live session, and reading it explains why the code looks the way it does. It runs for an hour on a fixed weekday, on a video call, with live coding, questions, and a stated goal of taking an application from demonstration to production. Episodes are numbered and dated, and each entry in the table carries a code link and, for upcoming ones, a registration link. That format has direct consequences for the artefacts. A session has to reach a working state in an hour, so the code is written to demonstrate an idea rather than to be the final version, and a half-finished refactor left in a directory is normal rather than a defect. The same applies to the claims: a topic chosen because it is interesting that week may be overtaken within a month, and the directory name tells you the date precisely so you can weigh that yourself. Two things in the readme are worth noticing as content signals rather than marketing. One episode argues that generating text for routing and classification is an antipattern, which is a specific and falsifiable engineering position. Another covers what it takes to shave latency down to the hardware limits, which is the kind of topic that only makes sense in front of people who do this for a living. ## Licensing, versions, and the honest limits of the archive Three facts constrain how you should treat this repository. First, the licence is not stated. There is no licence field, no licence file, and the readme does not mention terms. That is not a minor gap: without a licence, default copyright applies and you have no permission to copy the code into a product, so the correct use is to read it and reimplement what you need. Second, there are no releases, so nothing here is versioned in the way a dependency is, and the last push on 2026-09-20 reflects the most recent session rather than a maintained project. Third, the archive is growing faster than anyone could review it, one directory a week, so a topic you care about will appear in a directory you found by searching rather than in a curated index, and there is no marker in the listing saying which episodes produced durable code. The realistic uses are three: find the episode closest to your problem and read its code, use the topic list to work out what questions a working group is asking this year, and use the dated names to see how fast the tooling in your stack is being replaced. What the repository is not is a library, a framework, or a set of examples you can point a new developer at and expect them to maintain. ## Conclusion Use ai-that-works as a pattern catalogue when you are stuck on a specific AI engineering problem and want to see working code for it rather than a tutorial that stops at the first awkward case, because the value is entirely in the volume and the specificity of the topics, from agent backpressure to PII redaction to latency work. Do not adopt it as a dependency or a starting template, because there is no package, no version, no release history and no stated licence, which means you cannot rely on it for anything you ship. Four things to know. That the archive is organised by date, so the directory name tells you when an idea was discussed and not whether it is still current, and the whole point of an episode is that the tooling was new that week. That most directories are self-contained scratch code rather than a maintained project, so quality varies with whoever happened to be on air. That a handful of episodes have their own makefile with setup, development and test targets, and those are the closest thing here to a runnable project. And that the licence field is not stated, so treat the code as reference material you can read and reimplement rather than as something to copy into a commercial codebase. The last push was on 2026-09-20 and no GitHub releases are published. ## FAQ ### What is the ai-that-works repository? It is the code archive of a weekly live session about AI engineering, with one top-level directory per episode, named by date and topic slug. Each entry links to the code written for that session, and the readme states the goal is taking an AI application from demonstration to production. ### How do I run code from an episode? Change into the episode directory and follow its own instructions. The content pipeline episode has a makefile whose setup target syncs a backend with uv and installs a frontend with npm, then tells you to set up the database, configure OAuth and copy the example environment files. Most other directories are demonstration code meant to be read. ### Can I use this code in a commercial project? Not without resolving the licensing first. The repository states no licence, so there is no permission to copy the code into a product. Treat it as reference material you can read and reimplement. ### What topics does the show cover? The directory listing spans agent design and reliability, context engineering, evaluation, latency, retrieval, and tooling questions. Named episodes include twelve-factor agents, agentic backpressure, interruptible and event-driven agents, coding agent tools comparing bash against a protocol, dynamic schemas, and PII redaction and sensitive data scrubbing. ### How often is the repository updated? There is one top-level directory per weekly session, and the last push to the main branch was on 2026-09-20. No GitHub releases are published, so nothing in the archive is versioned as a dependency would be. ## Sources - [ai-that-works/ai-that-works on GitHub](https://github.com/ai-that-works/ai-that-works) - [Issues](https://github.com/ai-that-works/ai-that-works/issues) - [Project website](https://www.boundaryml.com/podcast) - [README](https://github.com/ai-that-works/ai-that-works/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ai-that-works-ai-that-works