> If I tell them exactly how to build something the work needed to review the resulting changes is a whole lot less taxing.
Totally matches my experience- the act of planning the work, defining what you want and what you don’t, ordering the steps and declaring the verification workflows—-whether I write it or another engineer writes it, it makes the review step so much easier from a cognitive load perspective.
Git worktrees are global mutable state; all containers on your laptop are contending on the same git database. This has a couple of rough edges, but you can work around it.
I prefer instead to make shallow checkouts for my LXC containers, then my main repo can just pull from those. This works just like you expect, without weird worktree issues. The container here is actually providing a security boundary. With a worktree, you need to mount the main repo's .git directory; a malicious process could easily install a git hook to escape.
Cool. Operationally, are you using some host-resident non-shallow repo as your point of centralization for the containers, or are you using a central network-hosted repo (like github)?
If the former, how are you getting the shallow clones to the container/mount, before you start the containerized agent? And when the agent is done, are you then adding its updated shallow clones as remotes to that “central” local repository clone and then fetching/merging?
If the latter, I guess you are just shallow-cloning into each container from the network remote and then pushing completed branches back up that way.
I just have the file path to the inside of my LXC container. If you're using Docker you can just mount it. I only need the path twice (for clone, and for adding a git remote). After that I just use git to reference the remote for everything.
I probably don't have the perfect workflow here. Especially if you're spinning up/down Docker containers constantly. I'm basically performing a Torvalds role play, where I have lieutenant AI agents asking me to pull their trees.
>AI-generated code needs to be reviewed, which means the natural bottleneck on all of this is how fast I can review the results
I also fire off tons of parallel agents, and review is hands down the biggest bottleneck.
I built an OSS code review tool designed for reviewing parallel PRs, and way faster than looking at PRs on Github: https://github.com/areibman/bottleneck
This is a great article and not sure why it got so few upvotes. It captures the way we have been working for a while and why we developed and open sourced Rover (https://endor.dev/blog/introducing-rover), our internal tool for managing coding agents. It automates a lot of what Simon describes like setting up git worktrees, giving each agent its own containerized environment and allowing mixing and matching agents from different vendors (ie Claude and Codex) for different tasks
We are at a weird moment where the latency of the response is slow enough that we're anthropomorphizing AI code assistants into employees. We don't talk about image generation this way. With images, its batching up a few jobs and reviewing the results later. We don't say "I spun up a bunch of AI artists."
Not just visually organizing the terminals for the agents, but also keeping their environments and source trees straight, and merging them to the correct upstream branches, can quickly turn into a very complex co-ordination problem.
This is exactly why we built Sculptor (https://imbue.com/sculptor). You don't need to manually juggle multiple terminal tabs because each Claude Code agent gets its own container with a UI that shows all your running agents in one place. You can see at a glance what your agents are doing and jump between them instantly. All the history and context is preserved per-agent, so you can reopen any session later without having to dig through the backscroll in multiple terminals.
I did try out sculptor. I like the idea of the pairing mode - the syncing to the main branch is quite helpful.
A couple of items
1. As output comes back from Claude Code, I wish it were streamed to the screen in Sculptor. Seeing the text build up in realtime gives me the feeling of the agent being "alive". It's hard to describe - but I find it more delightful to see it streamed in realtime.
There are quite a few products designed to help manage multiple agents at once. I'm trying out Conductor right now - https://conductor.build/ - it's a pretty slick macOS desktop app that handles running Claude Code within a GUI and uses Git worktrees to manage separate checkouts at the same time.
I’ve seen minimal gains trying to adopt agents into my workflow beyond tests and explanations. It tends to be distracting.
It’s so interesting that engineers will criticize context switching, only to adopt it into their technical workflows because it’s pitched as a technical solution rather than originating from business needs.
The fact that we now have to write cook book about cook books kind of masks the reality that there is something that could be genuinely wrong about this entire paradigm.
Why are even experts unsure about whats the right way to do something or even if its possible to do something at all, for anything non-trivial? Why so much hesitancy, if this is the panacea? If we are so sure then why not use the AI itself to come up with a proven paradigm?
Any setups without Claude Code? I use CoPilot agent heavily on VSCode, from time to time I have independent grunt work that could be parallelized to two or three agents, but I haven't seen a decent setup for that with CoPilot or some other VSCode extension that I could use my CoPilot subscription with.
"- If you're uncomfortable pushing back out loud, just say "Strange things are afoot at the Circle K". I'll know what you mean"
Most of the rules seem rationale. This one really stands out as abnormal. Anyone have any idea why the engineer would have felt compelled to add this rule?
Async agents are great. They let you trigger work with almost no effort, and if the results miss the mark you can just discard them. They also run in the background, making it feel like delegating tasks across teammates who quietly get things done in parallel.
I can't seem to get myself to focus when one of these things is running. I transition into low effort mode. Because of this I've decided to have my good hours of the day LLM free, and then in my crappy hours I'll have one of these running.
I'm very happy to see the article covering the high labor costs of reviewing code. This may just be my neurodivergent self but I find code in the specific style I write to be much easier to quickly verify since there are habits and customs (very functional leaning) I have around how I approach specific tasks and can easily handwave seeing a certain style of function with the "Let me just double check that I wrote that in the normal manner later" and continue reviewing a top-level piece of logic rather than needing to dive into sub-calls to check for errant side effects or other sneakiness that I need to be on the look out for in peer reviews.
When working with peers I'll pick up on those habits and others and slowly gain a similar level of trust but with agents the styles and approaches have been quite unpredictable and varied - this is probably fair given that different units of logic may be easier to express in different forms but it breaks my review habits in that I keep in mind the developer and can watch for specific faulty patterns I know they tend to fall into while building up trust around their strengths. When reviewing agentic generated code I can trust nothing and have to verify every assumption and that introduces a massive overhead.
My case may sound a bit extreme but in others I've observed similar habits when it comes to reviewing new coworker's code, the first few reviews of a new colleague should always be done with the upmost care to ensure proper usage of any internal tooling, adherence to style, and also as a fallback in case the interview was misleading - overtime you build up trust and can focus more on known complications of the particular task or areas of logic they tend to struggle on while trusting their common code more. When it comes to agentically generated code every review feels like interacting with a brand new coworker and need to be vigilant about sneaky stuff.
IMO, I was an early adopter to this pattern and at this point I've mostly given it up (except in cases where the task is embarassingly parallel, eg: add some bog standard logging to 6 different folders). It's more than just that reviewing is high cognitive overhead. You become biased by seeing the AI solutions and it becomes harder to catch fundamental problems you would have noticed immediately inline.
My process now is:
- Verbally dictate what I'm trying to accomplish with MacWhisper + Parakeet v3 + GPT-5-Mini for cleanup. This is usually 40-50 lines of text.
- Instruct the agent to explore for a bit and come up with a very concise plan matching my goal. This does NOT mean create a spec for the work. Simply come up with an approach we can describe in < 2 paragraphs. I will propose alternatives and make it defend the approach.
- Authorize the agent to start coding. I turn all edit permissions off and manually approve each change. Often, I find myself correcting it with feedback like "Hmmm, we already have a structure for that [over here] why don't we use that?". Or "If this fails we have bigger problems, no need for exception handling here."
- At the end, I have it review the PR with a slash command to catch basic errors I might have missed or that only pop up now that it's "complete".
- I instruct it to commit + create a PR using the same tone of voice I used for giving feedback.
I've found I get MUCH better work product out of this - with the benefit that I'm truly "done". I saw all the lines of code as they were written, I know what went into it. I can (mostly) defend decisions. Also - while I have extensive rules set up in my CLAUDE/AGENTS folders, I don't need to rely on them. Correcting via dictation is quick and easy and doesn't take long, and you only need to explicitly mention something once for it to avoid those traps the rest of the session.
I also make heavy use of conversation rollback. If I need to go off on a little exploration/research, I rollback to before that point to continue the "main thread".
I find that Claude is really the best at this workflow. Codex is great, don't get me wrong, but probably 85% of my coding tasks are not involving tricky logic or long range dependencies. It's more important for the model to quickly grok my intent and act fast/course correct based on my feedback. I absolutely use Codex/GPT-5-Pro - I will have Sonnet 4.5 dump a description of the issue, paste it to Codex, have it work/get an answer, and then rollback Sonnet 4.5 to simply give it the answer directly as if from nowhere.
We need some action. Like a battle or something. Some really experienced programmer not using any AI tools, and some really experienced AI coder using these agents, both competing live to solve issues on some popular real world repositories.
I have 2 (CC and Codex) running within most coding sessions, however can have up to 5 if I'm trying to test out new models or tools.
For complex features and architecture shifts I like to send proposals back between agents to see if their research and opinion shifts anything.
Claude has a better realtime feel when I am in implementation mode and Codex is where I send long running research tasks or feature updates I want to review when I get up in the morning.
I'd like to test out the git worktrees method but will probably pick something outside of core product to test it (like building a set of examples)
44 comments
[ 3.9 ms ] story [ 58.4 ms ] threadTotally matches my experience- the act of planning the work, defining what you want and what you don’t, ordering the steps and declaring the verification workflows—-whether I write it or another engineer writes it, it makes the review step so much easier from a cognitive load perspective.
I prefer instead to make shallow checkouts for my LXC containers, then my main repo can just pull from those. This works just like you expect, without weird worktree issues. The container here is actually providing a security boundary. With a worktree, you need to mount the main repo's .git directory; a malicious process could easily install a git hook to escape.
If the former, how are you getting the shallow clones to the container/mount, before you start the containerized agent? And when the agent is done, are you then adding its updated shallow clones as remotes to that “central” local repository clone and then fetching/merging?
If the latter, I guess you are just shallow-cloning into each container from the network remote and then pushing completed branches back up that way.
I just have the file path to the inside of my LXC container. If you're using Docker you can just mount it. I only need the path twice (for clone, and for adding a git remote). After that I just use git to reference the remote for everything.
I probably don't have the perfect workflow here. Especially if you're spinning up/down Docker containers constantly. I'm basically performing a Torvalds role play, where I have lieutenant AI agents asking me to pull their trees.
I also fire off tons of parallel agents, and review is hands down the biggest bottleneck.
I built an OSS code review tool designed for reviewing parallel PRs, and way faster than looking at PRs on Github: https://github.com/areibman/bottleneck
(Warning: this involves adjusting timestamps a la https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que..., which is sometimes confusing...)
https://blog.scottlogic.com/2025/10/06/delegating-grunt-work...
Using AI Agents to implement UI automation tests - a task that I have always found time-consuming and generally frustrating!
Not while they need even the slightest amount of supervision/review.
I wish there were a way to search across all open tabs.
I've started color-coding my Claude code tabs, all red, which helps me to find them visually. I do this with a preexec in my ~/.zshrc.
But wondering if anyone else has any better tricks for organizing all of these agent tabs?
I'm using iTerm2 on macOS.
This is exactly why we built Sculptor (https://imbue.com/sculptor). You don't need to manually juggle multiple terminal tabs because each Claude Code agent gets its own container with a UI that shows all your running agents in one place. You can see at a glance what your agents are doing and jump between them instantly. All the history and context is preserved per-agent, so you can reopen any session later without having to dig through the backscroll in multiple terminals.
A couple of items
1. As output comes back from Claude Code, I wish it were streamed to the screen in Sculptor. Seeing the text build up in realtime gives me the feeling of the agent being "alive". It's hard to describe - but I find it more delightful to see it streamed in realtime.
2. Add more hotkeys.
It’s so interesting that engineers will criticize context switching, only to adopt it into their technical workflows because it’s pitched as a technical solution rather than originating from business needs.
Why are even experts unsure about whats the right way to do something or even if its possible to do something at all, for anything non-trivial? Why so much hesitancy, if this is the panacea? If we are so sure then why not use the AI itself to come up with a proven paradigm?
"- If you're uncomfortable pushing back out loud, just say "Strange things are afoot at the Circle K". I'll know what you mean"
Most of the rules seem rationale. This one really stands out as abnormal. Anyone have any idea why the engineer would have felt compelled to add this rule?
This is from https://blog.fsck.com/2025/10/05/how-im-using-coding-agents-... mentioned in another comment
When working with peers I'll pick up on those habits and others and slowly gain a similar level of trust but with agents the styles and approaches have been quite unpredictable and varied - this is probably fair given that different units of logic may be easier to express in different forms but it breaks my review habits in that I keep in mind the developer and can watch for specific faulty patterns I know they tend to fall into while building up trust around their strengths. When reviewing agentic generated code I can trust nothing and have to verify every assumption and that introduces a massive overhead.
My case may sound a bit extreme but in others I've observed similar habits when it comes to reviewing new coworker's code, the first few reviews of a new colleague should always be done with the upmost care to ensure proper usage of any internal tooling, adherence to style, and also as a fallback in case the interview was misleading - overtime you build up trust and can focus more on known complications of the particular task or areas of logic they tend to struggle on while trusting their common code more. When it comes to agentically generated code every review feels like interacting with a brand new coworker and need to be vigilant about sneaky stuff.
My process now is:
- Verbally dictate what I'm trying to accomplish with MacWhisper + Parakeet v3 + GPT-5-Mini for cleanup. This is usually 40-50 lines of text.
- Instruct the agent to explore for a bit and come up with a very concise plan matching my goal. This does NOT mean create a spec for the work. Simply come up with an approach we can describe in < 2 paragraphs. I will propose alternatives and make it defend the approach.
- Authorize the agent to start coding. I turn all edit permissions off and manually approve each change. Often, I find myself correcting it with feedback like "Hmmm, we already have a structure for that [over here] why don't we use that?". Or "If this fails we have bigger problems, no need for exception handling here."
- At the end, I have it review the PR with a slash command to catch basic errors I might have missed or that only pop up now that it's "complete".
- I instruct it to commit + create a PR using the same tone of voice I used for giving feedback.
I've found I get MUCH better work product out of this - with the benefit that I'm truly "done". I saw all the lines of code as they were written, I know what went into it. I can (mostly) defend decisions. Also - while I have extensive rules set up in my CLAUDE/AGENTS folders, I don't need to rely on them. Correcting via dictation is quick and easy and doesn't take long, and you only need to explicitly mention something once for it to avoid those traps the rest of the session.
I also make heavy use of conversation rollback. If I need to go off on a little exploration/research, I rollback to before that point to continue the "main thread".
I find that Claude is really the best at this workflow. Codex is great, don't get me wrong, but probably 85% of my coding tasks are not involving tricky logic or long range dependencies. It's more important for the model to quickly grok my intent and act fast/course correct based on my feedback. I absolutely use Codex/GPT-5-Pro - I will have Sonnet 4.5 dump a description of the issue, paste it to Codex, have it work/get an answer, and then rollback Sonnet 4.5 to simply give it the answer directly as if from nowhere.
For complex features and architecture shifts I like to send proposals back between agents to see if their research and opinion shifts anything.
Claude has a better realtime feel when I am in implementation mode and Codex is where I send long running research tasks or feature updates I want to review when I get up in the morning.
I'd like to test out the git worktrees method but will probably pick something outside of core product to test it (like building a set of examples)