For example, my work on schema, my protobufs/flatbuffers language replacement for multiplayer games, parallelizes very nicely across 15 languages on the sprint system. https://github.com/mas-bandwidth/schema.
See roadmap here: https://github.com/mas-bandwidth/schema/blob/main/ROADMAP.md
Very difficult to coordinate this amount of work in || without some sort of structured work system.
Even more AI coding work here if you are curious: https://patreon.com/masbandwidth
[–] drphilwinder 2 days ago
[–] glennfiedler 1 day ago
Past a certain number of things, you can have a conversation with Claude in one session but even in Fable 5.1 or Opus 5.5 it's going to forget some and they just scroll out of context and get compacted away. Once enough things are in flight they start getting forgotten, or half-started, then the next thing is in flight and so on. When I start noticing this, I know it's time to switch over to the sprint system.
The other thing is simply I want to go really wide and work on something and it's too slow when working with traditional child agents per-model. The LLMs generally won't "work to width" naturally (for whatever reason) and the sprint system is really good at pushing and ensuring that each model involved in the sprint not only works, but works at whatever particular width they are assigned (16, 32, 64 cards...) and stays working that way.
If you work without a sprint system, you'll find yourself continually reminding the AIs manually "hey, can you please work to width?", "hey, you have 10 cards ready can you please work on them now?". These things are "squishy" when worked on in LLM space, they'll kinda do it, then a few hours later forget, and by morning they're puttering along at a few cards each.
But by putting everything into mechanical structure (sprint system that drives all the LLMs via push notifications), they will more reliably remember to work at width, they will not forget anything they were assigned to work on (this is stored in redis cards, not in their memory that compacts), and the whole system can work much wider and you get done a lot faster!
[–] drphilwinder 1 day ago
I can't.see myself specifying 60 bits of work to work on in parallel. So I guess you're doing some kind of task decomposition.
But I'm not convinced that this is that much more efficient, given the complexity of the coordination overhead.
E.g. in my mental model, 3 big tasks takes about the same amount of time as 60 small tasks after planning and coordination.
What's your experience?
Edit: and all the harnesses do subagents pretty well now anyway, so dynamic parallelism when you need it.
[–] glennfiedler 1 day ago
[–] drphilwinder 17 hours ago
[–] glennfiedler 3 days ago
[–] genxy 3 days ago
I did some prototype games, one thing that worked really well for me was having a deterministic replay system where the agents could drive the gamestate via recorded inputs. Kept me from having to do any playtesting or debugging in the main agentic loop.
[–] glennfiedler 3 days ago
https://github.com/mas-bandwidth/fixed3d -- port of box3d to fixed point :)
https://github.com/mas-bandwidth/fixed -- fixed point math library
[–] iainmerrick 2 days ago
I do you think now need to watch out for the opposite problem. These things become so easy to build that the temptation is just to go ahead and build. But unless you really do need them, all that new code just goes to waste. The cost to produce has become very low, but sometimes the value can end up being negative.
[–] glennfiedler 2 days ago
[–] genxy 2 days ago
Big fan of RDF, your sexpr notes are hilarious https://github.com/mas-bandwidth/fixed/blob/main/docs/roadma...
What tooling do you have around this?
[–] glennfiedler 1 day ago
And then the AIs can easily write tooling in lisp to manipulate these structures, and you can talk to them from some golang program in a verb like way, sort of like a redis client.
I was planning on doing this to effectively replace issues/PRs in git, and have my entire future work set that I import into sprints stored inside this lisp sexpr.
It's implemented in nova-sprint as a tracer bullet (search for "roadmap" scripts in lisp...), but I definitely see this as something I want to keep pushing harder on.
It's a really effective thing, storing all your work in a data structure, and then being able to manipulate that data structure. beats having to hammer the GitHub API when you ask questions like "OK so what else can we bring into the sprint now?"
=)
At what point do you think you tip over from getting away with a handful of agents working on different things in one repo, to needing a comms/coordination system for your tasks?
I think there must be a burden to run this and I'm guessing it only pays off when you get to some kind of scale. What is that scale? Other human team members? Sheer workload?