This is lesson one of Tiny Software Factories (TSF), a crash course from IndyDevDan on building small, useful software factories that work for you around the clock. The goal is to move you from being stuck in the loop to being near the loop. Each lesson shows an empty factory and a running factory, so you understand the capabilities first and then apply them to a real problem.
The title is deliberate. He calls these anti patterns: a highly compressed, lossy version of his infinite agentic engineering lessons, which focus on the harder out-of-the-loop work of fully autonomous systems. TSF trades long-term correctness for speed, a "useful local maximum" for getting results at all costs. In his words, it is blitz scaling for agentic engineering, and the focus is on getting things shipped.
What it is. A tiny software factory is built to solve one specific problem, with a proactive agent that works around the clock in a durable environment while you stay near the loop instead of in it. He says these properties will repeat as themes throughout the series.
Why it matters. When you are in the loop, you prompt. Near the loop, you respond: you give feedback, make decisions, and approve work. That feedback creates a data flywheel where the factory improves with each signal. He argues that you and I are the bottleneck, and that 80 percent or more of the work we do now can run without us with the right system in place.
How to apply. Pick one specific problem and define what a proactive agent would do about it while you are away. Decide where in your workflow you only need to give feedback and approve, and move your effort there.
What it is. The factory is rapidly deployable: you can mount a new one next to your code base, point it at your repo, or drop it in a sandbox and go from zero to a working agentic system in minutes. It is also extensible by design: every prompt, tool, hotkey, extension, and theme is accessible to you and to your in-loop agent.
Why it matters. Building a scalable software factory takes a ton of time, and the result is always one more feature away. A tiny factory is a highly compressed working system with great defaults that you can deploy over and over. Its near-loop agents also keep working: you can configure one to start before you wake up, so the work is waiting for your review. It works for you, then waits.
How to apply. Treat the factory as a quick fix that you redeploy per problem. Customize the pieces that matter to the specific job, and set the agent to produce work ahead of your next check-in.
What it is. The series reveals features through a feature map with four factory levels. Each feature sits on dimensions of effort required, value gained, and skill required; he keeps it simple by focusing on value and effort. The empty factory is the template, fully built with every feature you need to specialize but with no purpose until you give it one. It shows a minimal interface with two sidebars: an agent on the right, lists (here, pages) on the left, and a focus area in the center.
Why it matters. Every software factory must operate on something. Pages, artifacts, and simple markdown documents give you and your agent a shared surface. In the demo, a prompt about Python, TypeScript, and Rust basics fills the lists with nested folders and pages you can open and tune.
How to apply. Start from the template and replace the list with whatever your product is a list of. Keep the center view as the one place you and the agent both work.
What it is. Agent access parity means everything you can do, your agent can do: every control in the UI has a matching agent tool. The settings expose what he calls the core four (context, model, prompt, and tools), including a context bar, auto compaction at 200K, force compaction at 500K, model selection with thinking level in tiers, a system prompt, and the full tool list.
Why it matters. He says you do not truly own your agent if you do not have control of the core four. If you master them, you master your agent. Parity lets you move at agent speed, and the agent can even modify itself: in the demo it disables its own coding tools and changes its thinking level on request. He warns this can be very dangerous if you do not control it properly.
How to apply. Review your own agent's context, model, prompt, and tools, and set sensible limits on what it may change about itself.
What it is. The near-loop agent is built on slices of capability. Under advanced settings, the harness shows the factory harness, coding tools (disabled in the demo), a page harness, an image generation harness, and factory controls, with four layers stacked on the default coding agent. The interface is also customizable: themes, nav bars, hotkeys, and animations, all changeable by asking the agent.
Why it matters. Tools that feel great to operate make for a better experience, and a better experience means you are more willing to invest in them. In a world where software can change at light speed, he argues core tooling must be built for change. He calls this liquid software.
How to apply. Shape the interface to how you work. Ask the agent to change themes, move the context bar, add status to the nav bar, or add an animation that shows when it is working.
What it is. A cron prompt is a prompt on a schedule, run by your agent while you are away. Each cron has a name, a schedule, and a prompt, and that is really all. In the demo he asks the agent to add a cron that runs every minute and adds a new concept file for each programming language folder.
Why it matters. This is how you move near the loop and eventually out of it. The agent picks up each scheduled event and keeps stacking up work. Because the factory is a durable application, he can refresh or close the browser window and the agent keeps working. He calls cron prompts a powerful, simple way to run repeat jobs.
How to apply. Describe the repeat job, the schedule, and the prompt, and let the agent create the cron. Start with a low-stakes job to confirm the output before relying on it overnight.
Tiny software factories are deliberately imperfect: fast to deploy, easy to change, and built so a proactive agent keeps working while you give feedback and approve. The empty factory is the starting point, and the next feature, as the video ends, turns that empty factory into a working one. The practical question for you is which single problem is worth handing to a factory first, and which parts of your own work you could move from in the loop to near the loop.