considering dark software factories -- changelog
^ considering dark software factories -- changelog
video - Github researcher on how we should collaborate with agents in teams - 2026-04
Coding agents are greatly speeding up individual developers, but team coding alignment is important and hard to arrive at. Implementation has gotten so fast that nobody wants to pre-plan upfront anymore, so alignment has been relegated to the review phase, which is late: you get duplicated and throw-away work. PRs are not the ideal interface to review both design and implementation, either.
Agreeing what do build is becoming a new bottleneck. Really, designing, planning, and coding need to be merged and be iterative. You need real-time collaborative editing of a shared artifact to support a group working together. So, group chat (with agents in the chat, too) and a micro VM that runs the artifact being worked on.
The implication is that this will allow the review phase to be more limited. Perhaps it can then go back to being more of an engineering-focused activity where engineers work with agents to ensure that the non-functional requirements are supported by the code.
blog post - welcome to Gas City - 2026-04
Is Claude Code a dark factory? . I hadn't thought of it that way, before, but with its use of subagents, perhaps yes! And the darkness is a problem. You want high observability. You want the lights on and you want windows so you can see what's going on!
mechanisms for making agents more reliable
Updated Steve Yegge's AI adoption Chart to add several more levels.
blog post - Anthropic scaling managed agents 2026-04 they are codifying some of the abstractions necessary for long-running agents, both to solve immediate problems, and also to abstract away temporary harness "hacks" to immediate problems that the bitter lesson will eventually remove the need for.
tweet - multi-agent orchestration kanban as form factor
My thoughts on what is the 'spec' in spec-driven development?
Added a page called unlocking very parallel development, since I'm staring to see posts about how people are doing it. A lot of them are essentially cobbling together their own tooling to create rough dark software factorys, but some of the techniques are compelling, so I'm going to start capturing them there.
From blog post - modularity in spec files I find the code-associated specification files very compelling, but I also think that code-associated specification files are just a part of the documentation context graph.
tweet - video of Symphony and Codex and Linear 2026-03 which made me think about diff - software factory vs. dark software factory
As I started reading Symphony spec, I started having thoughts on Symphony Spec and Gas Town 2026-03
I also thought "Hmm... pulling from Linear is kinda cool, but really an issue tracker doesn't feel like the right place for app specification.
It was bound to happen... blog post - managed gas town
Introduced the agent task and agent task -- trigger types, since I needed them to talk about the types of automation that Cursor is doing.
Also added agent task -- change review app to address the "how do you make things extremely easy for humans to review?" question.
Media
tweet - video - Cursor automations 26-03 describes agent task -- trigger type -- cron and agent task -- trigger type -- event
tweet - the hard part about parallel agents in isolated workspaces... "the hard part after that is orchestration under load. code merge sequencing, CI failure routing, and keeping agents from drifting"
I added site - background agents - 2026-03 to key media
I also added Annotated version of 'Welcome to Gas Town' to key media. I haven't read through it carefully and taken notes, yet. But soon!
Initial version. Added dark software factory -- key media with two excellent pieces of media: