aroussi

Thanks! You can download the first few chapters here (free, no opt-in):

https://productionaibook.com/hn

If it makes you want to get the full book - I wont stand in your way

That's where the human architect comes in (for now at least). We'll try to think of features that would have the least amount of conflicts when merged back to main. We usually max it at 3, and have a senior dev handle any merge conflicts.

The system is trying to solve: breaking down large projects into small tasks and assigning sub-agents to work on each task, so the code, research, test logs, etc. stay inside the agent, with only a summary being surfaced back up to the main thread.

The real idea is to make sure that each agent works in its own little world and documents everything. So the main thread context is occupied with the understanding of the project instead of code snippets.

That's exactly why we use separate agents as "context firewalls". Instead of having the main thread do all the work and get its context polluted, with sub-agents, each agent works on one thing, then provides a summary to the main thread (much smaller context use) as well as a detailed summary in an empty file.

We created a "/pm:import" command before making this project public to pull existing repo issues into local. Hopefully, this will work well. We have tested it, but this is not one of the functionalities that we use on a daily basis internally. Fingers crossed :)

OP here. It really depends on how you use parallel agents. Personally, I don't run multiple instances of Cloud Code nor do I use multiple screens. I find it hard to focus :)

That being said, if a task requires editing three different files, I would launch three different sub-agents, each editing one file, cutting down implementation time by two-thirds.

OP here. I wouldn't necessarily call it a waterfall, but it's definitely systemized. The main idea was to remove the vibe from vibe coding and use the AI as a tool rather than as the developer itself. By starting off with knowing exactly what we want to develop on a high(ish) level (= PRD), we can then create an implementation plan (epic) and break it down into action items (tasks/issues).

One of the benefits of using AI is that these processes, which I personally never followed in the pre-AI era, are now easy and frictionless to implement.

OP here. These numbers are definitely in the ballpark. I personally went from having to compact or clear my sessions 10-12 times a day to doing this about once or twice since we've started to use the system. Obviously, results may vary depending on the codebase, task, etc., but because we analyze what can be run in parallel and execute multiple agents to run them, we have significantly reduced the time it takes to develop features.

Every epic gets its own branch. So if multiple developers are working on multiple epics, in most cases, merging back to the main branch will need to be done patiently by humans.

To be clear, I am not suggesting that this is a fix-all system; it is a framework that helped us a lot and should be treated just like any other tool or project management system.

Damn those em dashes lol

Kidding aside, of course we used AI to build this tool and get it ready for the "public". This includes the README.

I will post a video here and on the repository over the weekend with an end-to-end tutorial on how the system works.

Cheatsheet is available via /pm:help

With that being said, a video will be coming very soon.

We gave up on that dream a while back lol. Instead, we analyze which tasks can be run in parallel (different files, etc) and which need to be worked on sequentially.

I'm going to create a video and post it both here and on the repository over the weekend

100%! Use agents as "context firewalls". Let them read files, run tests, research bugs, etc, and pass essential data back to the main thread.

Yeah, I agree. I never let the AI make any architectural decisions (and I also watch Claude Code like a hawk lol). That being said, since we started using this system, we noticed that our PRDs and implementation plans (epics) became more detailed, giving the AI a lot less wiggle room.

Essentially, I'm treating Claude Code as a very fast junior developer who needs to be spoon-fed with the architecture.

I agree wholeheartedly!

When we break down an epics into tasks, we get CC to analyze what can be run in parallel and use each issue as a conceptual grouping of smaller tasks, so multiple agents can work on the same issue in parallel.

The issues are relatively large, and depending on the feature, every epic has between 5 to 15 issues. When it's time to work on the issue, your local cloud code will break it down into minute tasks to carry out sequentially.

Great idea! I'll whip something up over the weekend and post the video here and on the repo