Multi Boxing LLMs

Geoffrey Huntley 28 Jan 2025

Been doing heaps of thinking about how software is made after https://ghuntley.com/oh-fuck and the current design/UX approach by vendors of software assistants.

IDEs since 1983 have been designed around an experience of a single plane of glass. Restricted by what an engineer can see on their screen, how fast they think and how fast the compile chain can go.

Over the years that have gone by, this experience of IDEs has gotten better due to the ability to open multiple files at the same time and we now have multi-monitor workstations which have enabled engineers to view multiple files concurrently without switching between tabs.

However, it's still a synchronous design. These coding assistants such as Cursor, Windsurfer, Cody and GitHub Co-pilot have all been designed to fit in with pre-existing decisions (baggage) thus I'm starting to think this is a flawed approach.

how work is allocated

Products are the result of a cumulative effort of shipping tasks. In the workforce today, engineers pick a "single" story from the backlog.

With these turbo charged IDEs engineers can ship faster but it's got me pondering the following question...

why does an engineer pick only one story?

Instead of allocating a singular story from the backlog what if it was the engineering norm to pick multiple stories.

I've been playing around with this at home and running multiple coding agents concurrently to build stories concurrently and oh fuck fuck - it reminds me of World of Warcraft multi-boxing. Why level one character when you can do three or four at the same time?

The key to making it work is ensuring these agents don't fight with each other by splitting the work into separate discrete domain units of work within the same code-base or checking out the code-base multiple times.

next generation IDEs are required

So, I've been wondering what does the next generation of IDE's look like in this post LLM world. Why do I need to have multiple IDE's open?

What if instead of being shackled to design inherited from Turbo Pascal in 1983 - where IDEs are centered around humans we had a fresh take - IDE's are designed around software assistants first, humans second.

What if we ripped out the "collaborate with humans" functionality from Zed and inverted it so instead it's "collaborate with LLMs" and an unbounded amount of LLMs could be connected into the the IDE.