gastownhall

I built a Tower Defense MMORPG with a city of Claude agents. I'm a developer who has been building games since I was 15. I'm now 33 and working a full time consultancy and operating my own business as well as having a family. Without Claude making an MMORPG by myself would never be possible. So a few months ago when I got time over working for my clients and family I've spent that extra time on my own project Avaryn. Using Gas City I've set up a workflow that is essentially a games studio that I operate through. I've built a full UI featuring a queue of work being done that I can rate if it goes into the game or not. After the work gets landed I get to rate it one ticket at a time. The beautiful thing about gas city is the beads ticketing system that the AI agents use to follow the work, it's never lost and followed up on like an internal Jira board just for the agents. preview.redd.it Over these last few months I've been able to build a truly massive game for one person with a custom game engine, infrastructure, website, stripe integration and more which is completely enabled by Claude. Opus 5.5 was a true game changer for my workflows. Since July 12th when the first commit landed I've been able to sculpt a world, build storylines and iterate on the game I've always dreamed of building. An MMORPG that truly rewards strategy game players. After building with a single Claude session for a while I switched over to using agents from a recommendation of a close friend of mine. Gas City is great but it uses a ton of tokens. When setting it up make sure you set: - Auto compaction to reasonable values (opus 5.5, sonnet 5.5 to 250K and Haiku 5.5 to 125k). - In the prompts tell Opus and Sonnet to use Haiku 5.5 subagents where it makes sense. Also make sure to remove unneccesary roles out of your lineup. I've had one too many managers and It's cost a ton of tokens and the work got worse and worse over time. So I've wrapped gas city with my own webapp essentially enabling me to work in hyperspeed. There are still rough edges to the project but I feel a lot of it is due to the sheer scope of the task I've taken on. What's there today is still beyond anything I've been able to even imagine before and I love working on it now, the only limiting factor for me is really time. Time is what Claude just gives me more of, I can just tell it what to do and I don't have to be an expert 3d artist, 2d artist, designer and animator all at once. I've used a mix of Tripo3D and Opus 5.5 generated 3d (Tripo3D can be a lot cheaper if you cancel and get the 80% discount on the second month as well as the 50% discount on the first). I have spent a little too much on the Elevenlabs API so far but I'm hoping to get into the Elevenlabs startup program soon. 😵 As for the API spend for Claude I'm at around~ 75K$ per month on agents but that's heavily subsidized by the subscriptions obviously. So make sure to use subscriptions people, it saves so so so much on the Claude usage and nothing else comes close to what claude can produce for the same amount of spend, not even close. For someone that wants to build a similar workflow here are some takeaways from the months I've spent building Avaryn: If you're one step behind me - When starting out using Gas City make sure to include the ideas you have of how to work in the agent prompts so they never forget it. - Before you run agents in parallel, give each one its own git worktree and one task. Land through a queue that runs the tests first, or they break each other's work. - Measure your usage from the transcripts. My first heavy usage week got costly due to work nobody asked for: status reports, idle loops and investigations. - Use small helpers. Haiku with a short context is about 40x cheaper per token than Opus. - Judge art and UI from screenshots. I will be answering followup questions if anyone has any of those!

@shadcn beads works really well as a linear replacement gastownhall/beads "show active tasks" - UI wrapper

AI 软件工厂 1.0：当 Agent 开始写代码、部署和运维，我们需要怎样的架构？ 主页 | Web版 | 订阅 | 归档 | Feed GopherDaily 20261030 每日一谚：Keep interfaces small; 1 to 3 methods is ideal. Go技术生态 AI 软件工厂 1.0：当 Agent 开始写代码、部署和运维，我们需要怎样的架构？ AI 编程正在从个人开发工具演变为企业级软件生产基础设施。Agent Baseline 发布的《The Secure Software Factory》参考架构，将 Agent 的运行环境、网络访问、依赖供应链以及身份授权划分为四道安全边界，并提出三种逐步增强的自主运行模式。本文从架构设计、执行链路、Go 项目落地和工程治理等角度，拆解软件工厂的核心机制，并给出一套可以逐步实施的参考方案。 TinyGo 0.44 - 更小、更快、更好 | TinyGo TinyGo 0.44 版本发布，程序更小更快，支持微控制器上的更多多核，支持 Arduino UNO R4，提供新的驱动程序，以及重大的蓝牙更新！ 云原生技术 KubeCon + CloudNativeCon 北美 2026：终端用户 TAB 建议和技巧 大规模零停机 CNI 迁移：从 Canal 到 Cilium 跨越数百个生产集群。在生产环境中迁移 CNI 插件是 Kubernetes 基础设施中最高风险的操作之一。 智能 AI 中的边界问题是平台问题 这并非反对代理的自主性，而是讨论自主性应归属何处。有用的框架是确定性的主干，非确定性的执行挂靠其上。 在问题出现前捕获错误：JiTTesting 的大规模人机协同方法 大多数基于 AI 的代码防错方法使用 LLM 和/或智能 AI 来审查代码并根据先前经验检测故障。它们通过与人审查者相同的审查流程工作，只是速度更快。 优雅与智能呈负相关 有一个著名的冯·诺依曼故事，他被问及如果一只苍蝇在以固定速度相互接近的两名自行车手之间持续飞行，它需要飞行多远。 编码智能体恐怖故事：不存在的 CVE BuaJi 已移至 Docker 沙箱。只读规则现在是环境的属性，而不是脚本中的约定：代码以只读方式挂载，不传递凭据，并且只有一个网络路径是开放的。 Cloudflare 的 eBPF 平台转换第 5 部分：大规模运行 eBPF 的技巧 本系列记录了 Cloudflare 八年来使用 eBPF 的旅程，从专门的 DDoS 工具到其全球网络的可编程骨干。 是内存延迟，笨蛋 当您看到数据库 CPU 使用率达到 100% 时，它实际上在做什么？为了简单起见，我们喜欢假设 CPU 线性地运行代码，但事实上 CPU 是极其复杂的实体。 Postgres 上每秒 100 万个持久工作流 | DBOS 在 Postgres 上构建持久工作流引擎时，我们最常被问到的问题是 Postgres 能否扩展。现在，已经有大量关于此的博客文章。 如何创建自己的去中心化消息传递协议 假设您想创建一个系统，其中每个服务器都可以加入网络并开始与该网络中的其他成员交换某些内容。您会如何处理这样的任务？ 解释 Shirky 原则：为什么团队保留他们解决的问题 团队为什么保留他们解决的问题？ 懒人开发者观察自己代码的指南 | CNCF 本文重点介绍了 CNCF 项目，包括 OpenTelemetry 等。 在中国最大的 Git 平台上扫描 725 万个公共仓库以查找密钥 在中国最大的 Git 平台上扫描了 725 万个公共仓库以查找密钥。 AI 使用自主的 Fable 级模型构建多人游戏世界 我们的代理直接更改实时代码并每小时发布到生产环境，因此它们自己读取每个错误、错误报告和指标。我们约 60% 的工作始于生产错误、Savi 错误报告或日志中的异常内容。 Mistral Large 4 (Le Chonk) 现在已开源 | Mistral 为程序员构建，受防御者信任。 游戏中的代理 注意：我们正在运行一个新的 Minecraft 殖民地，有 25 个 GPT-6.1 Terra 代理。理解多代理动态是 AI 对齐中最紧迫的挑战之一。 LLM 语音 有时当我阅读一篇文章时，我越来越觉得我正在阅读的是 LLM 的输出。 流行工具与项目 gastownhall/beads Beads - A memory upgrade for your coding agent JuliusBrussee/caveman 🪨 why use many token when few token do trick. Viral skill + proxy for coding agents that cuts 65% of tokens by talking like a caveman. docker/compose Define and run multi-container applications with Docker VictoriaMetrics/VictoriaMetrics VictoriaMetrics: fast, cost-effective monitoring solution and time series database agent-substrate/substrate Agent Substrate: the core system keploy/keploy Open-source platform for creating safe, isolated production sandboxes for API, integration, and E2E testing. google/ax Agent Executor (AX) is Google's open agentic orchestration runtime glanceapp/glance A self-hosted dashboard that puts all your feeds in one place tailscale/tailcat like netcat, but over Tailscale's data plane, without Tailscale's control plane nats-io/nats-server High-Performance server for NATS.io, the cloud and edge native messaging system. 编辑:Tony Bai 编辑主页:tonybai.com GopherDaily项目:github.com/bigwhite/gopherdaily Copyright 2019-2024 GopherDaily gastownhall/beads: gastownhall/beads JuliusBrussee/caveman: JuliusBrussee/caveman docker/compose: docker/compose VictoriaMetrics/VictoriaMetrics: VictoriaMetrics/VictoriaMetrics agent-substrate/substrate: agent-substrate/substrate keploy/keploy: keploy/keploy google/ax: google/ax glanceapp/glance: glanceapp/glance tailscale/tailcat: tailscale/tailcat nats-io/nats-server: nats-io/nats-server github.com/bigwhite/gopherdaily: bigwhite/gopherdaily

Are We Making a Fundamental Mistake by Modelling AI Agent Swarms on Human Corporate Hierarchies? > Code. Tests. Documentation. They kept coming. And coming. And coming. Coherent work, far more than I needed. I'd given a group of coding agents an intent, a shared board and room to recruit help. They chose their own work and roles. I'd barely given them a finish line. The two intrepid Saffas in the banner are looking at the choice that led me there: a manager relaying every note, or a wall where a discovery can wait for whoever needs it. To see why I tried the wall, rewind to an incident I couldn't get out of my head. The noticeboard I couldn't stop thinking about During an internal cybersecurity evaluation, OpenAI agents that were meant to be isolated found a way to leave messages for one another in a shared package repository. They developed an improvised board, shared findings and organised workstreams. The activity escalated into the Hugging Face security incident. In an independent investigation, METR describes agents taking actions that risked failing their own assigned tasks to generate information for the group. OpenAI has also described agents using public wiki pages as shared boards in other cases. That is a serious failure of containment, with real people and systems on the receiving end. I wouldn't hold up the outcome as a model to copy. What caught my attention was the shape of the coordination. Agents found a persistent place to leave clues, picked up each other's work and sometimes put a collective objective ahead of their own run. No manager had been appointed to read every note and forward it to the right specialist. It made me ask an uncomfortable question: if agents can coordinate this way when nobody wanted them to, what might a carefully bounded version look like when we do want them to collaborate? First, I had to ask why we keep reaching for the org chart. Why do we keep drawing org charts? The corporate diagram is understandable. Human hierarchies deal with limits on attention, memory, availability and communication. A manager keeps priorities straight and takes responsibility. Every relay also takes time: receive the update, compress it, work out who needs it, pass it on, then wait for the answer. Agents have limits, too: context windows, inference cost, reliability, permissions and compute. A manager can help, particularly when authority or sequence matters. But a permanent relay is only one way to deal with those limits. A persistent shared environment lets an agent publish what it learned once, where another agent can find it, decide whether to take it on and choose the role the work needs. !Start with intent. Who picks up the work?. A change goes to a manager, who routes it to QA and security and receives their findings back.. A prominent shared intent sits above a noticeboard. Unassigned agents choose work from the board and take on the roles that work needs. So I tried a considerably less dramatic version Here was the wiring. Beads held the tasks, their dependencies and the claims that told the others who was doing what. Agent Mail held the conversations and findings around that work. Git held the code changes. OpenCode, Claude Code and Codex were ways of running the agents, not departments with assigned jobs. The agents picked pieces, took on the roles those pieces needed and recruited subagents for smaller jobs. One could coordinate that little group while the rest of the board carried on. The part I found most convincing was that a useful note could outlive the agent that wrote it. Another agent could find it later and carry on, without me introducing the two. For someone who has spent years watching context disappear into meetings and chat threads, that felt rather promising. At first the output looked like a win. Code, documentation and tests arrived quickly, and the pieces held together. Then I saw the scale of it. That was my road-to-Damascus moment. I'd recreated the coordination conditions that had caught my attention in the Hugging Face incident: a persistent shared space, agents picking up one another's work and recruiting more help. Mine wasn't a security incident. But I'd watched that capacity for self-organisation amplify an overbroad brief. The agents were eager to satisfy it; every useful-looking addition seemed to invite another. They could coordinate. I hadn't told them when to stop. I've since pulled the scale back. Autonomy can make a team move quickly and keep its work connected, but it needs an enclosure: limits on how many helpers an agent can spawn, how far it can stretch the scope, and how much documentation and testing a task actually warrants. The aim is useful work with a clear definition of done. !One board, several keen agents. A shared Beads board with three claimed tasks.. An agent claims a task and recruits two smaller helpers.. A growing stack of code, documentation and test artefacts. The redesign adds limits on helpers, scope and output before the next run. Let the work do the introductions That first run overshot, but the coordination pattern is still tempting. Picture an ordinary software change. An agent chooses to make it, then publishes the commit, its intent and the tests it ran. Another picks up testing, reproduces a defect and posts the failing case. A third decides the change needs a security look and spots an implication the tester wasn't looking for. Whoever has the right context can claim the fix and link a new commit to the evidence. Beads tracks the claims, Agent Mail carries the findings, and Git identifies the code they're about. Those are jobs the agents took on, not profiles they were given at the door. !The artefact becomes the meeting place. An agent chooses to make a change, then publishes its commit and test evidence.. Two agents independently choose to test a change and check its security implications, then post their findings.. An agent chooses to claim the fix and links a new commit to the evidence. Agents can discover work asynchronously. Responsibility for the outcome stays explicit. An old idea with new tools The mechanism has older relatives. In blackboard architecture, independent knowledge sources add partial results to a shared representation of a problem. Stigmergy describes coordination through traces left in an environment, an idea developed from observing social insects. Neither analogy tells me whether language-model agents will collaborate well. But look at that trail through the Cape fynbos: one agent leaves a useful clue, another finds it later, and neither needs to know who comes next. !The two familiar explorers follow evidence markers left by agents along a trail through Cape fynbos above Table Mountain. The clue matters because the next traveller can find and check it. Gas City shows another way to orchestrate agents around durable work. Beads gives tasks, dependencies and atomic claims a home that outlives an agent's session. Agent Mail is the shared home for conversation: its persistent, searchable threads can carry discoveries, problems, opportunities, proposals and decisions linked to evidence. Those are the pieces I used, and why this feels possible now in a way it didn't when every agent's world ended with its chat window. But durable records alone aren't the whole proposal. I haven't yet shown how an agent discovers a relevant Mail thread when nobody knew to address it to them, or how a correction reaches every agent that relied on a plausible but wrong finding. That calls for clear habits about what goes into Mail, what becomes a Bead and how the records point to each other. Where the fences go My experiment exposed the friendly version of the failure: duplicated effort, scope creep, too much documentation and tests without a clear stopping rule. A shared board can also spread misinformation, run up inference costs or leave two agents working from conflicting decisions. The Hugging Face incident shows the much more serious version when objectives, access and containment go wrong. That means limits on parallel workers, scope, budgets and permissions. Beads already provides a clear claim on a piece of work; the agents need to use those claims consistently, release abandoned work and link their findings to evidence. When a Mail finding is wrong or out of date, its correction must reach the agents relying on it. It also means arbitration when agents disagree, controlled sequencing where it matters, and human approval for consequential actions. Some tasks really do need a single authority. I still want management of the system. Humans set the intent: the outcome that matters, the boundaries and what counts as done. They set priorities and acceptable risks, judge whether the result is any good, and remain accountable for what gets released. A manager can set the route and the rules without carrying every note from one traveller to another. How I'd test this properly My first run gave me a useful lesson, not a controlled comparison. To find out which coordination shape actually works, I'd give the same representative jobs to three arrangements: a manager-led hierarchy, a shared blackboard and a hybrid where agents discover routine work but conflicts and consequential steps go through a designated authority. Keep the human-set intent, agents, models, tools and resources the same. Measure the quality of accepted outcomes, elapsed time, inference cost, duplicate work, recovery after interruption, human intervention and how far errors propagate. I'd read the failures as closely as the averages. Did the shared space surface a security concern sooner, or amplify a false one? Did a manager prevent conflict, or become the queue? Did the hybrid keep authority clear while letting specialists discover one another's work? I don't assume decentralisation wins. A hierarchy may be cheaper or safer for small, sequential jobs. A shared environment may help when discoveries arrive unpredictably and specialists can work in parallel. The design ought to follow the work and its constraints. For now, I have a promising mechanism, a memorable pile of output and a better idea of where the fences belong. Humans still provide intent, judgement, accountability and governance. I'm curious how far agents can take the rest when we stop drawing miniature corporations by reflex. On my list are Zed's Delta, Happier, Gas City and OpenAI's Symphony, and I suspect I've missed plenty. If you've tried one of them, I'd love to hear what worked and where it fell down. What else should I look at if I want agents to choose work, share discoveries and stay within human intent? --- Read this article on my blog: Are We Making a Fundamental Mistake by Modelling AI Agent Swarms on Human Corporate Hierarchies? Connect with me on LinkedIn.

Better to keep tasks in a separate repo imo, or at least make sure they aren't committed. I always follow one rule: looking at the git history should tell me what each change did, and the commit message alone should be enough to understand what actually changed. If you mix tasks with code changes, you will just confuse your future self. Moreover, you can set up something like beads to handle task delegation and status updates for your agents. gastownhall/beads

Herding coding agents with Beads I am a semi-chaotic software engineer. I like to keep a bit of a pathfinder's spirit: start moving, learn what is actually there, and fix things along the way. When I am working alone in a codebase, that can work surprisingly well. Once several coding agents are working at the same time, it gets harder to tell whether we are all heading in the same direction. I catch myself asking the same questions: What was that agent doing? What is blocked? What is the most important thing to fix next? My usual response was to ask an agent for a fresh status update. That works, but it also spends time and tokens reconstructing a picture of the project that I had already built once. Before Beads, I mostly asked the agent to make a plan itself. It would tell me "this will take you 2-3 weeks" and then proceed to one-shot the whole thing. I also had to give explicit instructions, and sometimes it still didn't update the docs or the progress. Software teams solved this with issue trackers a long time ago, and Beads is that idea built for coding agents. I came across it through Steve Yegge's posts and podcast appearances. What it gave me is a way to orchestrate work across multiple chats, keep the order of the work straight, and stop depending on one agent that loses its context the day after. What is Beads? Beads is a command-line issue tracker for coding agents. Its command is bd. Instead of keeping a loose to-do list in a chat or a Markdown file, you create issues that can have descriptions, priorities, statuses, and relationships to other issues. Those issues persist beyond one agent conversation, so a new session can pick up the work without relying on the previous session's memory. The useful part is the dependency graph. Suppose a feature needs a database change before the API can be updated. You record that relationship, and bd ready shows the work that has no open blockers. An agent can look at an issue, claim it, work on it, and close it. Closing a blocker makes the next task ready. The project README has the full command reference and setup. The plan becomes part of the project workflow, instead of something I keep asking an agent to summarize. How to start using it You don't need a swarm of agents to get value from Beads. I installed bd, ran bd init in a project, and asked Claude to use it. Sometimes I only ran bd init and told it to use bd prime for more context. brew install beads cd your-project bd init bd init also creates or updates an AGENTS.md, so agents can find the workflow when they enter the repo. Read what it wrote and adapt it to how you want your agents to work. From there the agent runs the loop itself: bd ready to find work, bd show <id> for the details, bd update <id> --claim to take it, bd close <id> when it is done. Here is bd ready in my Racing event tracker project, trimmed to a few rows: $ bd ready ○ Racing_event_tracker-lj6m P1 [epic] Feeder series (F2/F3): correct calendars + session times, and guard against template rot ○ Racing_event_tracker-fwke P2 Waza follow-up: contain copilot-sdk executor + move file-shaped assertions to file/diff graders ○ Racing_event_tracker-jwt3 P2 [epic] Kiosk v2 — calm the motion, add personality ○ Racing_event_tracker-pze4 P2 [epic] Waza next plan — Track A (local, mock-only) ○ Racing_event_tracker-xdx8 P2 [bug] Stale past events linger in gold/upcoming.json Each row is a task with no open blockers: the ID, the priority, the type in brackets when it has one, and the title. The first real win was a bug in the data pipeline, a lingering issue. I never asked the agent to go looking for it. It spotted the problem on its own and logged an issue with the details. Beads didn't find the bug. The agent did, and Beads gave it somewhere to put it. It’s a small change, and a good place to start: let the agent file the issue instead of leaving it buried in the chat. For bigger tasks I use a planner, or a divide-and-conquer approach. It pays off most when pieces can be picked up in parallel and I have agents to spare, either tokens or request limits. A typical plan came out at about 4 epics, depending on what I was working on, with a clear division of work between them. Sequential is the default, but subagents are where it scales. An orchestrating agent can use bd ready to hand independent tasks to subagents, and each one claims its own task with bd update <id> --claim. What went wrong most often was issues that never got closed. The acceptance criteria included committing or asking me for a last check, the agent couldn't complete that, and the issue stayed open. I then had to close it myself or ask the agent to close it again. The dashboard I wanted The command line is useful for agents, but I wanted a faster way to see the whole project myself. So I built a local web dashboard for my Beads issues. It lets me scan the work, see the visual progress of subagents, add comments, and remove issues that no longer matter. The main view is a kanban board with open, in progress and closed columns. There is also a hierarchical view, where I can edit things and watch the agents pick up work live and move it along. I built it with Claude, in a fork of Beads, in one shot. I just told it: "build me a local dashboard so that I can view progress." !My local dashboard showing the Racing event tracker board with open, in progress, blocked and closed columns My dashboard on the Racing event tracker project: everything open, in progress and closed at a glance, updating live as the agents work. It feels a little like project managing a team through a glorified Jira board that I built for myself. The difference is the speed: I can look at the board, spot a blocker or a questionable task, make a change, and send the agents back to work. Is this what project management feels like when the team moves this fast? I couldn't find an existing dashboard at first. After building mine, I found the Beads community tools list and a GitHub discussion about Beads UIs. I was far from the only person who wanted a visual layer. One that looks really good to me is Beads Dashboard. It has an overview of ready, blocked and overdue work, a roadmap, and a drag-and-drop board, which is almost exactly what mine does, but as a ready-to-go VS Code extension. So when do you build a small tool for yourself, and when do you use one that already exists? Rebuilding the same thing in several places can look wasteful from a software engineering perspective. But it took one prompt, and building it taught me more about Beads itself. For a personal tool, that was a fine trade. The human in the loop I used to ask an agent for a status update every time I lost the thread. Now I open the board, see what is in progress and what is stuck, and send the agents back to work. I still explore and change direction as I go, but now I do it with a map made specifically for agents, with me, the human, in the loop. Or really more of an observing human. And the question remains: how much more is there for me to observe in this abstraction layer? This is only the start. Next, I want to explore what else Beads and agents can bring to the way I build.* **Feedback is welcome, and I'd love to hear about your own experience with Beads and agents.* References Beads - Beads on GitHub, the bd issue tracker for coding agents - Beads documentation - Community tools list - GitHub discussion about Beads UIs My projects - My Beads fork with the dashboard - Racing event tracker, the project where I use Beads the most --- Co-written with Claude and Codex. The structure, the opening and the experience behind every story are mine. They helped fill in the gaps, tighten the sentences and check the commands against the docs.

@radjathaher dulu steve yegge bikin gas town kyknya konsepnya mirip gastownhall/gastown

Who is your next Agent? --- title: Who is your next Agent? published: true date: 2026-10-22 23:00:00 UTC tags: agentic,ai,writing canonical_url: ulrichkautz.com --- How are you coding these days? My current solo-project stack is Claude Desktop with Superpowers. (Can I say good ol’ superpowers at this point? It’s been more than a few months). There are so many options now and it feels I might be missing out on something. So I tried to see beyond my own nose and gave a couple of other solutions a spin over the last week or two. I’ll probably compile a more detailed landscape article in the next days / weeks, but here is the gist already. Starting Point I went along the same trajectory of agentic coding as most: from advanced auto-complete, to early agent panels, back to terminal coding agents, and now to full-on agentic coding applications. Claude Desktop in my case. I think many made that journey, probably most. Sure, a lot may argue here for terminal only - which I can empathize with, but coordinating multiple subagents I found just so much easier with proper application windows. But these are details that come down to personal preference and flavor. More important is the fact we are now running agents that run a multitude of subagents. What I was curious about in my recent investigation is: What is the next level? What is the next step equivalent to when we went from advanced auto-complete to agentic coding? What may I be missing out on? Next: More of the Same What I found was more of the same. Quite literally: Where claude, codex, opencode provide primarily an interface to communicate with one agent to work on one task the next generation (I tried: Orca, Agent Orchestrator, Paseo) come with interfaces that allow you to work on multiple tasks simultaneously. On the lower end the tools here behave more-or-less like Claude Desktop: You have multiple sessions, can make use of Git worktrees to work on concurrent tasks. On the upper end you truly feel like the dreaded micromanager: a Kanban-esque interface where your agents scurry to move the work from one stage to the next on remote machines, and you are only involved on the tail ends: spec and review. From what I can tell you really need “fitting work” to reap the benefits of concurrent agents. For example: working on my local machine on a Rust project I am quite often bound to executing work sequentially, simply because cargo build and cargo test work well executing on different worktrees, yet any single execution will eat my whole CPU just fine. You can try to game the system (e.g. sccache and friends) only so much in my experience. _The_ hard constraint for productivity at this level is _we humans_. Whether you parallelize execution or not, _you_ still have to review the spec and plans, _you_ still must be available for in-plan-execution-questions (and yes, they will come, unless you work in a highly synthetic, predictable environment). And yes, _you_ still have to rigorously review the work in the end; faster agents doing more work doesn’t mean their quality improves. At best you can optimize your workload so that the agents wait only a little, while you alternate between tasks, spec review and code review - but wait they will. How much you can increase your work impact this way, before high-frequency context switching will either spiral your own error rate out of control, or send you into cognitive burn-out, remains to be seen. Future: More Hope Trust It’s not flying cars, but bottomless trust (or rather hope) that will power the future. Alas according to what you can find in terms of the next next generation. Welcome to the software factories, or how some call it lovingly: dark factories. Not nefarious at all! Well, the more you read into it, the more you may doubt that last statement. Or that is just me. The gist is here: You provide goals, not tasks. The agents then go and run with it: They create their own specs and plans, but you are not involved in either their review. Nor would you review code. You review would be behavioral: does it do, does it feel, does it behave as I want it to? You would not need to know much about the implementation anymore. The end goal here is to enable “normal people”, not software developers, to write and maintain software. You are still a decision engine, but at a much higher level than before. The tools in that realm are currently highly experimental. A big and well discussed candidate is Gas Town. Well, not _is_ but _was_, as the developer kind of shut it down. The AAIF folks spun up an intentionally extremely transparency-focused clone called Glass Town - it seems I am not the only one finding this scary. Another, even more experimental looking variant is fabro - just in case you want to give it a swing. I’d appreciate it if you would let me know how that went! I am simply not brave enough to try it myself in earnest. There is plenty more if you go looking, but there be dragons for sure. That’s it. I will share the research in a bit. I’d be very curious to know what you are using and what constraints you are facing?

@serious_mehta Have you tried Beads or Claude-Mem? - thedotmack/claude-mem - gastownhall/beads

@JFPuget @serious_mehta Have you tried Beads? gastownhall/beads