🧍 You are the bottleneck 0:00
Lesson one of Tiny Software Factories opens with a claim that is easy to dismiss and hard to argue with: "you and I are the bottleneck. Every time you sit in the terminal prompting one agent back and forth, you are the system." His estimate is that eighty percent or more of what we do now could run without us, given the right system around the agent.
That one-line distinction is the whole course compressed. In the loop, your attention is the scheduler: the agent cannot proceed without your next message. Near the loop, the work has already happened by the time you look, and your job becomes feedback, decisions and approvals — a shift from driving to reviewing, which is precisely the shift most people never make because the terminal is comfortable.
🙃 Done wrong on purpose 0:38
The subtitle of the lesson is "agentic engineering DONE WRONG", and the first ninety seconds are spent justifying it. Tiny Software Factories, he says, is a crash course in "many dark patterns of agentic engineering that will not scale" — a deliberately compressed, lossy version of the larger curriculum. In exchange you move fast, break things, fix them, and ship.
The framing is refreshingly honest about the trade, and he repeats it so nobody misses it:
- TSF is near-loop: fast, rapidly deployable, intentionally imperfect.
- IA3 (Infinite Agentic Engineering) is out-loop: fully autonomous systems that operate without you — higher leverage, harder.
- These are not long-term solutions. They are "meant to move you from zero to value at the cost of basically everything except getting the job done".
🏭 What a tiny software factory is 2:11
The definition is given slowly, and every clause carries weight:
| Clause | What it rules out |
|---|---|
| Built to solve one specific problem | The general-purpose agent platform you keep rebuilding instead of shipping |
| With a proactive agent | Reactive chat that only exists between your messages |
| Around the clock | Anything that stops when the terminal closes |
| In a durable environment | Session-scoped state that dies with the process |
| With you near the loop, not in it | You as the scheduler of every step |
"Proactive" is the word doing the most work, and he defines it mechanically: a durable agent plus a trigger inside a sandbox. Not enthusiasm, not a system prompt that says "be proactive" — a process that keeps running plus something that fires it. The behavioural consequence is his refrain for the whole lesson: it doesn't wait for you to work, it works for you, then waits.
That exact sentence appears verbatim in the README of his public durable-pi repository, which is worth noting: this is not a slide concept invented for a sales page, it is the description of code he ships.
♻️ Why near-loop beats in-loop 2:46
Four reasons are given, and they escalate from tactical to structural:
| Reason | The argument |
|---|---|
| You are not required in the loop | You give feedback, make decisions, approve work the agent already did. The feedback becomes a data flywheel: every signal makes the factory better. |
| Rapidly deployable | One meta skill and one command mounts a new factory next to your codebase. Point it at a repo, drop it in a sandbox, zero to working agentic system in minutes. |
| Extensible by design | Every prompt, tool, hotkey, extension and theme is accessible to you and to your in-loop agent — you build the system that builds the system. |
| Proactive, not reactive | Configure it to start before you wake up; when you check in, the work is waiting for review. |
The honest counterpoint he offers along the way is that building a scalable software factory takes enormous time even with strong models, and "the result is always one more feature away". The tiny factory is the opposite bet: a compressed working system with good defaults that you can stamp down repeatedly instead of perfecting once.
🗺 The feature map and the empty factory 5:44
Rather than demo features one at a time, the course plots them on a feature map with three dimensions: effort to unlock, value of having it, and the skill required. For simplicity he collapses to value and effort, and spreads features across four factory levels, worked incrementally.
Then the concept that anchors everything: the empty factory. A fully built template with every feature you need to specialize — and no specialization. It has no purpose until you give it one. In the browser demo it is a minimal UI with two sidebars and a centre pane, and the trick is that every element in it is a capability you are meant to repurpose.
🧩 Three panes: agent, lists, focus 7:06
The scaffold is deliberately boring, which is the point — it maps to how work actually arrives.
| Position | Feature | Rationale |
|---|---|---|
| Right | The agent on your right | A durable agent inside the factory, always on, always one message away. "Every application can be supercharged with an agent." |
| Left | Lists on your left | Every product is a list of something. What's in your list? In the demo it is pages — deliberately designed to be replaced. |
| Center | Focus in the center | The primary thing you and your agent work on: pages, artifacts, markdown the agent builds, tweaks and tunes on your behalf. |
To prove the empty factory is real, he runs a single prompt: explain the basics of Python, TypeScript and Rust in nested folders in pages. The agent creates the pages, populates them, and the centre view focuses the content. Two tool calls later, you are looking at a working generative UI — not a mockup.
It is the most portable question in the video. A competitive-intelligence factory lists sources. A support factory lists tickets. An on-call factory lists incidents. The list is the schema of the problem; the agent is the operator; the centre pane is where judgement happens.
🤝 Agent access parity 9:15
The design rule: everything you can do, your agent can do — every control in the UI has a matching agent tool. The demo shows the agent listing its own page tools, then editing pages, then changing themes, moving a context bar into full-width mode, and switching themes without a single manual click.
His justification is about speed, and about small operations compounding: "it's the small operations that you take, that I take, that stack up big over time". If a two-second UI action is not exposed as a tool, you have reserved it for the human forever — and the human is the slow path.
🎛 Core four control 9:56
The claim: "you do not truly own your agent if you do not have core four control" — context, model, prompt, tools. Whatever harness you use, if those four are not exposed, you are a tenant, not an owner.
| Core four | What the settings screen exposes | Why it matters |
|---|---|---|
| Context | A context bar, auto-compaction at 200k tokens, forced compaction at 500k | Long-running agents must shed context deliberately, not crash into the window |
| Model | Model selection and thinking level, broken into tiers | Right model for the job at the right performance, cost, speed trade-off — "don't fixate on one model" |
| Prompt | A prompt-engineered system prompt, plus custom and extension prompts appended at any time | The system prompt is where domain behaviour lives |
| Tools | Full tool list with descriptions and parameters in the syntax you prefer | Tools are the blast radius |
Two details deserve more attention than a demo usually gets. Tiered model selection means the factory routes by task difficulty rather than paying frontier prices for a formatting job — the same discipline his public OpenRouter state of models work is about. And compaction thresholds as settings are the difference between an always-on agent and one that dies at the context limit mid-task; the mechanics of self-compaction appear in his public self-compact-pi-agent extension, where a long-running agent watches its own context and compacts itself.
🪞 The agent that modifies itself 11:41
The demo that gives the video its charge. One prompt — "disable all coding tools, update thinking level to max" — and the agent turns off its own read/write/edit/bash tools and raises its own thinking level, visible afterwards in settings.
He calls it reflection for AI agents: a durable agent with the right tools can reconfigure the harness it runs inside, up to a limit you set. It is also, he says immediately, dangerous without controls.
The uncomfortable half: an agent that can disable its own tools can, by the same mechanism, be argued into enabling them. Any factory where parity extends to configuration needs an out-of-band limit — a file, a policy, an allowlist — that the agent cannot edit while it is running. Otherwise "up to some useful limit" is a limit that exists only in the system prompt, and prompt is one of the four things the agent can change.
🧱 An extensible harness of capability slices 12:49
Under the advanced settings there is a list that explains the architecture: the agent is not one harness but a composition of capability slices.
- Factory harness — the base loop and session
- Coding tools — read, write, edit, bash (disabled live in the demo)
- Page harness — the list objects and their operations
- Image generation harness — an extra layer of capability
- Factory controls — the settings, themes and UI operations
Four additional layers stacked on the default coding-agent settings, and the promise is that harness engineering new capabilities into the near-loop agent is a matter of composing more slices. "Tools that feel great to operate make for a better experience, and better experiences mean you're more willing to invest in the tools you're building."
🌊 Liquid software: DX and UX as configuration 13:55
The final product feature: themes, nav bars, hotkeys and animations are all things you or your agent can change. In the demo the agent swaps to another dark theme, adds a context bar to the agent nav bar, adds a status indicator to the global nav, moves the bar to full width because it was "scrunched", then drops it again when it proves unnecessary.
He calls the result liquid software — "it's meant to be changed, it's meant to be customized" — and the argument is causal rather than aesthetic: "in a world where software can change at light speed, our core tooling, our core applications must be built with that in mind".
⏰ Cron prompts: it works, then waits 16:10
The last feature is the one that turns a nice UI into a factory. Cron prompts: prompts on a schedule, run by your agent while you are away. Every entry has three fields — a name, a schedule, a prompt — and nothing else. The hotkey is R.
The live demo is deliberately mundane: "every minute, add a new file to each of our programming languages, break down one new concept each". The agent pushes back — it has no file rights, and once a minute is a lot per day — then confirms and starts using page tools instead. Moments later the pages hold context managers for Python, utility types for TypeScript, lifetimes for Rust, each with "why it matters" and "common mistakes".
The transcript ends here, mid-sentence at 18:26 ("turning your empty software factory into a…"), a few seconds before the video's 18:36 runtime — likely a course CTA. Nothing technical is lost.
💥 Where the shortcuts bite 1:33
The video's own list of dark patterns, from the description, with the failure mode each one is heading toward. He promises each breaks somewhere and you will know where; these are the seams I would watch.
| Shortcut | What it buys you today | Where it breaks |
|---|---|---|
| One agent | Simplicity, shared context, nothing to coordinate | One context window is one failure domain; parallelism and review-by-another-agent disappear |
| Cron in the server | The fastest possible scheduler | No queue, no retries, no idempotency — a missed tick is silent, an overlapping tick is a race |
| A JSON config | Everything in one diffable file | No schema, no validation, no migrations; the config becomes a program nobody tests |
| Agent-written pages | Content appears without you writing it | Layout drift and duplication; nothing checks that a page is still true |
| SQLite on one box | Real persistence with zero operations | Single machine, no failover — and the agent's state now lives in the same box as your laptop's uptime |
| Bash in your codebase | Maximum leverage with minimum code | Unbounded blast radius: a durable agent with shell access and a schedule is a background process you cannot fully audit |
📦 What is actually public today 5:44
The factory template itself is course material, not a repository — so I checked what is public and maps to each feature. It turns out most of the load-bearing parts exist as MIT-licensed code with the same vocabulary, which is the strongest evidence that the demo is a real system.
| Feature in the video | Public repo | Status |
|---|---|---|
| One meta skill stamped into a repo | disler/super-simple-software-factory — "repeatable agents-plus-code workflows, packaged as one skill" | MIT, ~1.0k★ |
| Durable, proactive agent | disler/durable-pi — "they work for you, then wait" | MIT, ~330★ |
| Cron-driven proactive loop | disler/pi-durable-news-agent — sweeps on a cron tick, ranks Hype / Facts / Signal | MIT, ~150★ |
| Auto / self compaction | disler/self-compact-pi-agent — agent watches its own context and compacts | MIT, ~80★ |
| The meta-skill for distributing agentics | disler/the-library | MIT, ~430★ |
| Sandbox for the durable agent | disler/agent-sandbox-skill — isolated execution via e2b | No licence file declared |
"Pi" in the takeaway — "whether you route through OpenRouter or run a pi agent harness" — is Mario Zechner's minimal, MIT-licensed terminal agent (pi.dev), which deliberately ships without MCP, sub-agents or plan mode and is extended with TypeScript packages. That choice is consistent with the whole TSF argument: a small harness you own beats a large harness you configure.
✅ Claims checked
| Claim | Verdict | Evidence |
|---|---|---|
| A "tiny software factory" = one problem, proactive agent, around the clock, durable, human near the loop | Definition is internally consistent | Used identically throughout the lesson; matches the shipped repos' descriptions |
| "Proactive" = durable agent + trigger inside a sandbox | Correct mechanism | A stateful process plus a scheduler is what makes work happen without a prompt; the sandbox bounds it |
| Every UI control has a matching agent tool (agent access parity) | Demonstrated live | Agent lists pages, edits them, changes themes and layout by tool calls |
| Agent can disable its own coding tools and raise its thinking level | Demonstrated live | Settings screens shown after the prompt; "reflection for AI agents" |
| Auto-compaction at 200k, forced at 500k | Product configuration | Shown in the settings UI; the specific thresholds are this factory's defaults, not a universal standard |
| "You and I are the bottleneck; 80%+ of work can run without us" | Speaker estimate | No source given; directionally consistent with agentic-engineering practice, but the number is a rhetorical figure |
| "These are anti-patterns that will not scale" | Self-declared and fair | He states it repeatedly, including in the description; treat the architecture as scaffolding, not a destination |
| Durable agents keep working when the browser closes | Verified in his public code | durable-pi: persistent agents with web, terminal and curl clients |
| Cron prompt = name + schedule + prompt | Demonstrated live | Created in the UI; fired on the minute while the video continued |
| Pi is a minimal MIT harness you can own | Verified | pi.dev / earendil-works/pi, MIT, ~119k★; no MCP, sub-agents or plan mode by design |
| The upstream public repos are open source | Verified via GitHub API | MIT licences on the five repos listed above; the sandbox skill declares none, so it is source-available rather than licensed |
| Course framing and presale | Commercial content | Lesson one of a paid programme; the presale link is excluded from this article by policy |
Transcript notes. Auto-captions were clean. The transcript ends at 18:26 mid-sentence, ten seconds before the video does — a CTA cut, not missing content. Star counts were read from the GitHub API on 2 November 2026 and drift; treat them as approximate.
🔑 Key takeaways
- In loop you prompt, near loop you respond. If your attention schedules the work, you are the system — and the system is the bottleneck.
- Proactive is mechanical, not motivational: a durable process plus a trigger inside a sandbox. Nothing else makes an agent work while you sleep.
- One problem per factory. The general-purpose agent platform is the thing you keep building instead of shipping; the template you stamp down repeatedly is the thing that ships.
- Every product is a list of something. Find your list, expose it on the left, put judgement in the centre, keep the agent one message away on the right.
- Agent access parity is the multiplier: if a control has no matching tool, you have permanently reserved it for the slow path.
- Own the core four — context, model, prompt, tools. Without them you are a tenant of someone else's harness, and model tiering plus compaction thresholds are the two that decide whether long-running agents survive.
- Self-modification is really self-constraint. The valuable version is the agent narrowing its own toolbelt for a task — but the limit must live outside the prompt, because the prompt is one of the four things it can change.
- Treat the harness as slices, not a monolith: factory, coding, pages, image generation, controls. Add and drop capability instead of adopting a new agent.
- Cron prompts are the minimum viable scheduler — name, schedule, prompt — and the fastest path from "my agent is a chat" to "my agent is a colleague".
- Shortcuts are legitimate if you keep the receipts. One agent, cron on the box, JSON config, SQLite, bash: each is a defensible first version and a known wall. Write down the wall before you hit it.
- The sandbox is what makes the shortcuts survivable. Durable agent + schedule + shell + config parity is the maximal-blast-radius combination in this design.
- Know which loop you are building. Near-loop factories optimise for shipping now; out-loop systems optimise for operating without you. Confusing the two is how you get autonomy you cannot audit.
🔗 Resources
- The source video — IndyDevDan, "Tiny Software Factories: Agentic Engineering DONE WRONG", 18:36, 2 November 2026
- disler/super-simple-software-factory — repeatable agents-plus-code workflows packaged as one skill (MIT)
- disler/durable-pi — durable agent network with web, terminal and curl clients (MIT)
- disler/pi-durable-news-agent — a proactive agent that sweeps on a cron tick (MIT)
- disler/self-compact-pi-agent — an agent that watches and compacts its own context (MIT)
- disler/the-library — meta-skill for private-first distribution of skills, agents and prompts (MIT)
- disler/agent-sandbox-skill — isolated execution environments for agents (no licence declared)
- pi.dev — Mario Zechner's minimal MIT-licensed agent harness
- earendil-works/pi — the toolkit: unified LLM API, agent loop, TUI, coding agent CLI