{
  "$type": "site.standard.document",
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreidzdntwj3lp26maqgmgjzjhtnmnfcsoqqw4xd2xroxa76mwqtjx5u"
    },
    "mimeType": "image/png",
    "size": 324142
  },
  "description": "Val Town is the Salt Fat Acid Heat of vibe coding platforms",
  "path": "/slow-mode",
  "publishedAt": "2026-05-19T00:00:00.000Z",
  "site": "at://did:plc:a2rdzfdxkjwerrfrpbwcipb2/site.standard.publication/3jd443afc2222",
  "textContent": "<img src=\"https://imagedelivery.net/iHX6Ovru0O7AjmyT5yZRoA/a89756ca-682c-4a58-8249-5a18c25f0400/public\" alt=\"New Yorker Cartoon. Stop and Think. It sort of makes you stop and think, doesn't it.\" />\n\n---\n\n> Despite the countless failed attempts at trying to democratize coding while\n> not understanding coding, we’re faced with the reality that you cannot\n> understand code without engaging with it. <br> -Lars Faye,\n> Agentic Coding is a Trap\n\nLars’s blog post got me thinking: what if we designed a deliberately slow,\nhand-holding agent? One that keeps the human programmer involved, to understand\nand learn. One that doesn’t paint you into a corner with slop. No one-shotting,\nno agentic looping, but instead moving at a human pace to match your particular\nhuman knowledge at the time. I use the word programmer on purpose because I\nthink even vibe coders should at least be learning programming concepts, like\nwhat data their app needs to store and how, or where that data travels (say,\nfrom their laptop to a data center in Ohio then into a database somewhere else).\n\nWe’ll call this Slow Mode.\n\nSlow Mode 1.0 with Claude Code\n\nAs a low stakes experiment, I first wrote Slow Mode 1.0 as instructions in\n for\nusing Claude Code + the Val Town MCP server:\n\n\n\nStop and think\n\nOf course, when an LLM thinks or reasons, it is really just generating more\nand more text.\n\n> ...the models can only “think” by spooling out more text — while human\n> thinking often does the opposite: retreats into silence, because it doesn’t\n> have words yet to say what it wants to say. <br> -Robin Sloan,\n> Thinking Modes\n\nLLM “thinking” can be problematic, assuming it’s important to me to understand\nwhat’s happening. I’d actually like to see the thought process, if you can call\nit that. In some ways, I think it’s a feature, not a bug, that a slow mode agent\nwould brainstorm linearly, token by token. It’s the machine’s way of\nrubber ducking, and I\nthink we should be doing it together. I should be talking aloud and then\ndictating or typing the next decision or question back to my robot\ncollaborator-teacher. I should be making some edits in the code myself,\nextracting a helper function here, renaming a variable there, running the code,\npoking around the database. I like that my slow agent keeps me in the weeds, so\nI can keep the whole program in my head. Like this:\n\n<img src=\"https://imagedelivery.net/iHX6Ovru0O7AjmyT5yZRoA/4c2238ad-56b1-452b-bc2b-665032739f00/public\"\nalt=\"Before I refactor - two quick decisions: 1. What should we name it? Something like fetchNewVals, getRecentVals, fetchPublicVals? 2. Same file or a new file? It's small enough to stay in main.ts, but if you anticipate adding more helpers, a separate file might be cleaner from the start.\" />\n\n<!-- In old fashioned programming, you might generalize a function the third time you\nwrite it—not the first, and probably not the second. With Slow Mode,\ngeneralizing might mean adding to your preferences in the instructions file once\nyou’ve repeated yourself a few times (\"ok, I want Claude to know that I always\nprefer CSS modules\"). -->\n\nI find coding in Slow Mode to be more pleasant. It’s partially the prompt\nenforcing Slow Mode, but in large part it’s also me self-enforcing by staying\nfocused and thinking (much easier when your agent doesn’t run off for 10 minutes\nin a loop!). Slow is smooth, and smooth is fast.\n\nSlow Mode 2.0 (Slow Townie)\n\nAfter experimenting with Slow Mode using Claude Code + Val Town MCP, we’ve\nstarted privately testing Slow Townie within Val Town.\n\n\n\n<!-- LLMs never seem to directly ask about your knowledge like a coworker or friend\nwould. Like, “do you know how cookies work?” It’s good to stop and think,\ntesting what I know and where I have gaps. In Slow Mode, the agent asks. While\nbuilding a val to\ncheck domain availability, Slow\nClaude asked, “do you know what RDAP is / want me to explain how it works before\nwe use it?” And when testing Slow Townie, it asked whether I’m “familiar with\nSQLite, or would [I] like a quick explanation?” -->\n\nThe instructions are pretty much the same as above in  for now, but\nan ideal slow mode would factor in your particular knowledge and preferences,\nbuilding on the “memory” feature that many agents currently use. We should have\na lot to learn from prior art when it comes to personalization.\n\nYOLO Mode\n\nThe polar opposite of Slow Mode is YOLO Mode, where your agent loops again and\nagain without stopping to ask for permission. It fulfills vibe coding’s original\ndefinition. In Townie we do have YOLO Mode (a.k.a. “Allow all”) because, well,\nto each her own. I enjoy YOLO’ing sometimes, typically when the stakes are low\nand time is short.\n\nBut more often than not, it’s important to me that when I need a break—when I\nshut the laptop to go for a walk or cook dinner or sleep—my robot takes a\nbreak, too. Contrary to what seems like consensus among tech workers in San\nFransisco, I think my agent should mostly stop working when I do (and I myself\nshould probably stop working around dinner time most nights!). Plenty of\ndevelopers I respect feel the opposite—fair enough.\n\nTrading productivity for learning\n\nVal Town’s end goal is end-user programming, the dream that anyone should be\nable to customize their own software. Like a spreadsheet, there should be a\nnatural gradient from beginners making something useful in the first hour to\nexperts spending hundreds of hours on complex models. Users progress along that\ngentle slope by learning continuously over time. But is end-user programming\nabout learning, or about building the thing? I think it’s about both: the more\nyou learn while building, the better you get at building.\n\nThere’s an inherent learning-versus-productivity tradeoff when using AI. I am no\nstranger to\nsacrificing my own learning\nor solid understanding of an implementation to prioritize shipping. When you\nhave a lot on your plate, that can be the right side of the tradeoff. But\nthere’s also a\nshort-term gains versus long-term maintenance\ntradeoff, and I’m betting Slow Mode will help with that.\n\nLearn to cook\n\nI know many people think moving more slowly means falling behind, or worse, that\nby insisting on understanding code we’re gatekeeping. By embracing Slow Mode at\nVal Town, we’re telling vibe coders we believe in your ability to learn\nfundamentals about code that might’ve previously seemed unreachable. Building in\nVal Town (or elsewhere) with Slow Mode should empower you. You should feel like\nyou know what you’re doing, not like you’re dependent on your agent and helpless\nif there’s downtime.\n\nIt’s like cooking with recipes versus learning about food fundamentals so you\ncan improvise in the kitchen and create food that’s all your own. Val Town is\nthe Salt Fat Acid Heat of vibe coding platforms.\n\n\n\nPrior art\n\nWe’re not the first to propose something like Slow Mode. It turns out Claude\nitself already has a\n“Learning mode,”\nostensibly for education but also relevant to professional and hobbyist (vibe)\ncoders. ChatGPT has “study mode”\n(also more geared toward students). Just last week, the same day I wrote the\nfirst draft of this very essay, a Claude/Codex Skill for “deliberate skill\ndevelopment” attracted a bunch of GitHub stars and Hacker News comments.\n\nJust like Val Town\nfast-followed all the best coding assistants\nwhile building Townie, we’d like to learn from others and share our own\nimprovements to Slow Mode along the way.",
  "title": "Slow Mode"
}