It’s a blend. There are plenty of changes in a production system that don’t necessarily need human review. Adding a help link. Fixing a typo. Maybe upgrades with strong CI/CD or simple ui improvements or safe experiments.

There are features you can skip safely behind feature flags or staged releases. As you push in you fine with the right tooling it can be a lot.

If you break it down often quite a bit can be deployed safely with minimal human intervention (depends naturally on the domain, but for a lot of systems).

I’m aiming to revamp the while process - I wrote a little on it here : https://jonathannen.com/building-towards-100-prs-a-day/

Definitely made me feel old to see bit-shifting needed an explainer! I must admit as I was reading I was "why is he explaining this? it's obvious!".

Indeed. And plenty of successful merges end up with code that won't compile.

FWIW I've struggled to get AI tools to handle merge conflicts well (especially rebase) for the same underlying reason.

Code not compiling is still the good case, because you’ll notice before deployment. The dangerous cases are when it does compile.

I've seen merged code where the memory barriers were misplaced.

Very true.

I realized recently that I've subconsciously routed-around merge conflicts as much as possible. My process has just subtly altered to make them less likely. To the point of which seeing a 3-way merge feels jarring. It's really only taking on AI tools that bought this to my attention.

I'm surprised to see that some people sync their working tree and does not evaluate their patch again (testing and reviewing the assumptions they have made for their changes).

If it’s any comfort, I don’t hear many JS/TS/Node/etc developers calling them threads or really thinking of them that way. Usually just Workers or Web Workers — "worker threads" mostly slips in from Node. Even then, "worker" dominates.

In terms of tradeoffs, if you’re coming from the single event loop model, they’re pretty consistent with the rest of JS. Isolation-first, explicit sharing, fewer footguns. So I think the tradeoffs are the right tradeoffs.

FWIW, traditional threads have their own tradeoffs (especially around IO). In JS that’s mostly a non-issue, so the "I need 1000s of threads" case just doesn’t come up very often.

Thanks!

I'd assume that this will be a bit like JSON schemas - the decoding will eventually get smart enough to validate in the output in line with more complex rules.

Agree on the "behind it's back" too. I might make a change that in the case of "--fix" give the LLM the diff on the spot.

The other advantage I've not been able to quantify yet - I've been able to *remove* stuff from CLAUDE.md/etc in favor of lint rules. e.g. prefer ?? over || -- all the way through to "use our logging framework" -- as a lot of the nitpicks in my instructions were bits like this. This keeps the instructions to higher level architectural stuff.

If you know what you need, my experience is that a well-formed single-prompt that fits the context gives the best results (and fastest).

If you’re exploring an idea or iterating, the roles can help break it down and understand your own requirements. Personally I do that “away” from the code though.

> Humans and LLMs both share a fundamental limitation. Humans have a working memory, and LLMs have a context limit.

But there’s a more important difference: I can’t spin up 20 decent human programmers from my terminal.

The argument that "code was never the bottleneck" is genuinely appealing, but it hasn’t matched my experience at all. I’m getting through dramatically more work now. This is true for my colleagues too.

My non-technical niece recently built a pretty solid niche app with AI tools. That would have been inconceivable a few years ago.

Would you entertain the idea that "work was never the bottleneck", or even "building products was never the bottleneck"?

We need to address Jevons' Paradox somehow.

I love Jevons’ paradox too, but if we apply it here don’t we still end up with more software?

Definitely would entertain -- I do agree with your framing. I just think the article undersells the impact of fast+cheap codegen.

Lowering the cost of implementation will (has) expose new bottlenecks elsewhere. But imho many of those bottlenecks probably weren’t worth serious investment in solving before. The codegen change will shift that.

I think that's where a heck of a lot of the frustration on this topic is coming from. Some engineers claim to have solved the code generation issue well enough that it hasn't been the bottleneck in their local environment, and have been trying to pivot to widening the new bottlenecks for a while now, but have been confounded by organisational dynamics.

To see the other bottlenecks starting to be taken seriously now, but (if I'm to be petulant) all the "credit" of solving the code bottleneck being taken by LLM systems, it's painful, especially when you are in a local domain where the code gen bottleneck doesn't matter very much and hasn't for a long time.

I suspect engineers that managed to solve the code generation bottlenecks are compulsive problem solvers, which exacerbates the issue.

That isn't to say there are some domains where it still does matter, although I'm dubious that LLM codegen is the best solve, but I am not dubious that it is at least a solve.

I guess that what people debate on here is what “decent” mean. From my experience, these llms spit out dog shit code, so 20 agents equal 20x more dog shit.

Atwood has been writing about speculative futures for a long time, so it’s interesting to watch her react in real-time to one of them actually happening.

The post captures something real about LLMs: the interface makes the interaction feel like a social exchange even when you know perfectly well it isn’t. Despite knowing better we attribute intention/emotion/feeling to the LLM. I felt that the most in her (somewhat bleak) sign off at the end.

I have moved towards super-specific scripts (so I guess "CLI"?) for a few reasons:

1. You can make the script very specific for the skill and permission appropriately.

2. You can have the output of the script make clear to the LLM what to do. Lint fails? "Lint rules have failed. This is an important for reasons blah blah and you should do X before proceeding". Otherwise the Agent is too focused on smashing out the overall task and might opt route around the error. Note you can use this for successful cases too.

3. The output and token usage can be very specific what the agent needs. Saves context. My github comments script really just gives the comments + the necessary metadata, not much else.

The downsides of MCP all focus on (3), but the 1+2 can be really important too.