what used to be teams of many can pare down to teams of 2.
I've been thinking about this too. 6-8 people in a dev(ops) team, scrum-style, may make things more chaotic, though I haven't had the opportunity to validate this in the field yet. If teams get smaller, intra-team will get more hierarchical though, and the real pressure could be upward the hierarchy. I think that operationally, you'll want to catch things pre-merge now more than ever: post-merge bugfixing is expensive if only the LLM understands the code, because the fix is still only as good as the prompt.
Something we've been trying that seems to go well is jumping on a screen share, and tag-teaming planning mode.
This makes sense because you synergize the 20x that way. In my own setup this is async - I no longer chat - because it's cheaper to redo than to spend interactive time, as the latter puts a timing requirement on my brilliance. The LLM is much more consistent than I am in 2026, because it doesn't get tired.
The more detailed docs may be a bigger efficiency gain than with code.
Yes. "Everyone" has LLMs now (wishful thinking but let's assume that.) Process is much more of a differentiator now. That's why I said the other day that releasing a buggy project is inexcusable now. If I wanted something buggy, I'd throw a one-liner at claude/codex in yolo mode and cut out middleman markup. But say I need a lightning wallet, I am confident that if you can ship with attention to detail, yours will be better than mine, as long as you cover my usecase. Because your prompts will be better than mine: you have thought much more about Lightning than I.
Diverse tool/model preferences catch things we might not otherwise too, up to and including re-do of anything done with free Antigravity tokens.
Yes. The re-do is super important. I never used to close my own PRs on my own repos and redo from scratch. Now, I'm relentless: nope! do it again.
I've been thinking about this too. 6-8 people in a dev(ops) team, scrum-style, may make things more chaotic, though I haven't had the opportunity to validate this in the field yet. If teams get smaller, intra-team will get more hierarchical though, and the real pressure could be upward the hierarchy. I think that operationally, you'll want to catch things pre-merge now more than ever: post-merge bugfixing is expensive if only the LLM understands the code, because the fix is still only as good as the prompt.
This makes sense because you synergize the 20x that way. In my own setup this is async - I no longer chat - because it's cheaper to redo than to spend interactive time, as the latter puts a timing requirement on my brilliance. The LLM is much more consistent than I am in 2026, because it doesn't get tired.
Yes. "Everyone" has LLMs now (wishful thinking but let's assume that.) Process is much more of a differentiator now. That's why I said the other day that releasing a buggy project is inexcusable now. If I wanted something buggy, I'd throw a one-liner at claude/codex in yolo mode and cut out middleman markup. But say I need a lightning wallet, I am confident that if you can ship with attention to detail, yours will be better than mine, as long as you cover my usecase. Because your prompts will be better than mine: you have thought much more about Lightning than I.
Yes. The re-do is super important. I never used to close my own PRs on my own repos and redo from scratch. Now, I'm relentless: nope! do it again.