Just wanted to share this quick video demonstrating the value of git worktrees with Claude code.
Working on many things in parallel on the surface is very overwhelming.
So we need to start by creating a slow and intentional process for shipping high quality features (i.e. brainstorming documents, planning documents, todos, triage, multi-agent reviews, etc). Create your own, or use plugins like compound engineering/gsd/superpowers.
Compound engineering for example can take many minutes between each prompt as it explores and thinks. It creates great output (given strong input) at the cost of time, like any person would.
Once you have a process you like, it should be the equivalent of you pair coding with a better version of yourself.
Pair coding with one person at a time is not scalable.. I.e. trying to watch the changes and pair code with two people writing different features at the same time would be a nightmare.. and the same can be true with pair coding with a few agents in parallel.
So to leverage worktrees you need to shift your perspective of shipping a single feature, to managing the outcomes of many engineers.
Imagine each worktree is an engineer on your team, assign work the same way (i.e. no two worktrees should be working on exactly the same feature), then simply answer their questions/help them test their changes/provide feedback.
You only review code when the worktree agent has reviewed their own code enough times that they (Claude) are happy with the result and submit a PR. Then you review the code, just like any other person on your team. Ask for changes and back to testing.
AI makes code is cheap, your time is still valuable, so figuring out how to scale yourself is always going to be better than a tool that tries to scale for you.
Just wanted to share this quick video demonstrating the value of git worktrees with Claude code.
Start by slowing things down. Create a repeatable process for shipping high quality features - using plugins like compound engineering/gsd/superpowers.
Compound engineering for example can take many minutes between each prompt as it explores and thinks etc.. so all of the sudden you have time.
If you are working from a perspective of managing the outcomes of many agents instead of pair coding with one, it can dramatically alter your output.
Imagine each worktree is an engineer on your team, assign work the same way, help them test their changes and provide feedback. Only review code when they have reviewed enough times that they (Claude) are happy with the result and submit a PR. Only then do you review the code, just like any other person on your team. Ask for changes and back to testing.
I’m a designer who codes, and for those who have had trouble expressing the value and finding a role that enables both, here is how I’ve positioned it:
As the primary designer for a product, who can also implement the design - the amount of communication needed between design and engineering literally evaporates.
I tell my devs they can build an ugly v1 of any feature simply for the sake of speed, and I’ll go in after to clean it up and make it look consistent. they don’t need to waste time with CSS.
Design changes so often after implementation, that I don’t even keep a living design file, most changes happen directly in code. If I do need to design something as part of a pitch or meeting material I take a screen shot of the product and just modify that.
Having worked as only a designer, and then only as an engineer, I can’t express how much faster my team is when design is part of engineering.
Speed is most critical to startups, I’ve always found interviewing with startups and presenting this skill set is highly sought after when expressed properly.
Hey everyone - today we launched a demo for people try our “ChatGPT” like tool (but not using ChatGPT) for asking questions about recent Wall Street events. Would love any feedback!
Our platform analyzes events relevant to investors, company financials, and textual data to give investors an edge.
Our back end consists of Python and node based micro-services. We also utilize machine learning and big data to analyze equities and events, and to transcribe and analyze audio. We capture and re-broadcast audio via WebRTC, SIP, HLS, DASH. Our APIs are a mix of REST and GraphQL. We utilize Docker, AWS services, Terraform.
You may be a fit if:
* 3-5+ years of professional software development experience, ideally some of which was spent in a startup or fast-paced environment, but this is flexible for the right candidate
* You enjoy thinking about systems design, and diving deep into the details
* You are a self starter and can make decisions quickly
* You have good communication skills and can support project stakeholders
* You have experience working with Python, SQL, GraphQL, AWS, Docker, ElasticSearch
* It would be amazing if you had WebRTC, SIP, telephony, experience, but is not required
reach out to elliot [at] aiera if you're interested!
Obviously you’re entitled to your opinion. We don’t have jr. members on our team, but if we did, they’d be assigned a project like anyone else. If the project was a bug, that would be reasonable. This process is for the intern and every other dev to avoid reading a giant list of potentially stale bugs anytime they have a short gap between work. it keeps them working on A) what they were assigned, or B) something small that people have been clamoring for.
Why do you have a giant list of potentially stale bugs?
The policy described in the linked-to article is roughly equivalent to saying that every bug/issue must be passed to someone, who is in charge of that issue, including closing them.
The main difference is that there's a single tracker instead of "personal workload lists".
What happens to the workload on a personal list if the person is unexpectedly out of work for a month?
Now that I've read a bit more:
> Developers will only want to hear the same request so many times, before losing whatever is left of their sanity, and deciding to address the issue.
What happens if the stakeholder's sanity runs out first?
> Why do you have a giant list of potentially stale bugs?
Most places I've worked have a bug log? Priorities balance between new feature development and fixing bugs / tech debt. If a bug isn't high priority, or the feature it was about has been changed or removed, the bug might now be stale - but still exists in a list somewhere.
> The policy described in the linked-to article is roughly equivalent to saying that every bug/issue must be passed to someone, who is in charge of that issue, including closing them.
It's the opposite, it's saying that if the bug / issue isn't easy enough to be solved right then, it needs to be reported again later, or added to the official prioritized road map.
> What happens if the stakeholder's sanity runs out first?
I think my earlier rhetorical question came across as one of inquiry.
Most place have a bug log. Some of the OSS projects I'm involved with have bugs I've submitted over a decade old.
My comment was meant to lead in to how a centralized bug system is not the issue - it's one of process. If a bug comes in, and either people accept a bug or close it right away, then it's the same as having a personal work list.
Except that the failure modes, like when people suddenly must be on leave for a month, are less severe.
(With the proviso that some people use personal work lists with a different interface than the centralized system might offer.)
