That's exactly how you should do it. You can also plug in an MCP for your CI or mention cli.github.com in your prompt to also make it iterate on CI failures.
Next you use claude code instead and you make several work on their own clone on their own workspace and branches in the background; So you can still iterate yourself on some other topic on your personal clone.
Then you check out its tab from time to time and optionally checkout its branch if you'd rather do some updates yourself.
It's so ingrained in my day-to-day flow now it's been super impressive.
I’m really wondering what internally causes this. No one likes it when they have outages, but it keeps happening. Is this a culture thing? Like pressure to ship features fast? Some under staffed teams or lack of ownership on some crucial components?
Definitely all good questions. I've noticed that there seems to be a bit of convergence between Azure DevOps and Github (Enterprise) and am curious how co-mingled the teams or management are at any given level or not.
I'm mixed on the cultural changes at MS and have historically preferred GH's approach. I'm hoping MS moves closer to GH than the reverse. I'm not working with/at either company and don't really have a lot of insights to offer other than observations from the outside.
Because iterating multiple sessions through multiple terminals is obviously more efficient and seamless than interacting thought a scuffed IDE side panel ui.
People getting really poor results probably don't recognize that their prompts aren't very good.
I think some users make assumptions about what the model can't do before they even try, so their prompts don't take advantage of all the capabilities the model provides.
I thought they meant that it's a noop as a tool in the sense that it takes no external action. It seems nonetheless effective as a means of organizing reasoning and expressing status along the way.
There is something much deeper going on when you force yourself to actually write things down. This is especially relevant in engineering.
That is why "RFCs" are so prevalent in many tech companies. They are often just as useful to the writer as they are to the reviewers.
I've been looking for this for some time now. This is amazing if it delivers.