I've written before about software factories and how they're the wrong form factor for most dev shops. I overstated the gap, though: Software factories aren't wrong, they're incomplete. If you're focused on throughput, that's great. But look around you, my brothers and sisters - the throughput isn't all of the problem. Nobody needs MOAR FUNCTIONS, we need more ambitious products and we need more control of those products' quality.
Back in July, Thariq Shihipar of Anthropic went onstage at AIE World's Fair and gave a banger of a talk titled Field Guide to Fable. In it, he speaks about how he works with this latest batch of frontier models, specifically Fable 5. The line of his that really stuck with me from this presentation is to 'Be Unreasonable'. This is such a gem of a line, and it's going to age very, very well for 2 distinct reasons.
#1 These models are reasoning models. They're going to continue to eat away at tasks in software that demand reasonable mindsets. Bug fixes, developing a feature to spec, version updates, back testing - all of these pieces require reason. They won't discover novel ideas without getting nudged in the right direction, which brings me to my next point...
#2 Work requiring a lack of reason is what we get to play with. Product evolution, setting new performance standards, remixing this tool over here with that idea over there. This is the fun, inventive, creative space we get to occupy now. We have to be ambitious! It's not just something we can do, it's the whole game now.
Say it with me: Ambition is the whole game now. As more and more parts of the SDLC are "solved" by AI, machine-spirited away into the software factory, the ask of us as builders and creators is to be unreasonably ambitious with what we attempt to build.
This idea really landed for me w/ fable 5.1 and astra 6, both of which are world-changing models (again). Grappling with how to best leverage these models left me with a heavy dose of AI Psychosis for about a week. But in testing them out, I realized what these models are best at: handling unreasonable requests. Your biggest ideas, wildest thoughts, divergent, scope-shattering questions. This complements the idea of a software factory magnificently, and that's what I'll talk through below.
You're ambitious, you grow, the discipline comes in after to clean up and keep things running. In the before-times, as you went after new products or large new features, you always had to staff up to support the feature. You'd get an idea for a product, assemble the team to build and support it, and then get started building.
Now, with the afore-mentioned unreasonable model, we sling world-changing ideas with our second cups of coffee, get the team excited about the potential of the product, get it to a working state, and ship by the end of the week.
At Aarden, we used this approach recently to completely re-vamp how we render map layers within our product. It started with a prompt in the tone of "I want to make our map on the explore page best-in-class, performance-wise". After a weekend of nudging, checking-in and slight course-correcting, we ended up with a new approach to rendering map layers that is orders of magnitude more performant both in time to render and amount of data rendered.
But once you ship your idea, the game isn't over. To get that idea to actually survive in the harsh world of real users, competition, and code rot, you need to relentlessly monitor usage, refine functionality, and harden your idea.
That grind is what comes next, and that's what software factories are perfectly suited for.
This is the part I was overly focused on before. People were talking about their software factories like that was the whole point. What I see now is that software factories are a crucial part of a larger system. Software Factories handle the discipline, so that we can focus on being unreasonable.
Dex Horthy wrote about this here, but the idea of a software factory goes all the way back to a NATO conference from 1968. It's been an institutional ideal for almost 60 years! Continuous evaluation and improvement of application quality is now achievable by any team willing to put in the work to assemble the pieces. Historically, this is where the bulk of software engineering really lived - bug fixes, support, version updates - in other words, reasonable work. But now we can build that work into the software machine.
So where does that leave us?
You need to assemble a workspace for your team where ambition and rapid iteration can live side by side. I was describing this to a friend the other day - at Aarden, we don't want to just have a software factory. We want to have an experts' workshop, built out to support and encourage unreasonable creativity, invention and experimentation. This support comes from tools that can handle going deep on individual ideas, and tools that can process tasks and work autonomously. A software factory should be like a CNC machine, a machine press, or a planer. It exists as a helpful tool, as part of a larger system focused around harnessing the true potential of these wild string prediction machines.
We have access to these amazing technologies, and they're going to continue to get better. We owe it to ourselves to build out a space where we get to build unreasonable things.