1zael

Agreed. In my experience, product development is 60% of the work. There's a ton of other stuff like RTB tasks, infra overhauls, etc that good PMs acknowledge the importance of but is primarily driven by the engineering team.

Yeah I think this maps onto grep-based code search well. Right now agents grep, read the results, grep again, and every hit lands in context. This architecture turns that into one program: fan out the greps, filter and dedupe in the sandbox, hand back only what matters. The "won't know the codebase" worry flips around too. The first program shouldn't be "find the bug," it should be "build me a map" (grep the file tree, import graph, symbols). That needs zero prior knowledge, then the model plans the real search over that map. So it's less about replacing sequential exploration and more about making each grep step way wider without flooding context

[flagged]

How are people still flat-earthers after stuff like this

The order of priority for most people is: 1\ output quality 2\ latency 3\ cost. I will always pays more money if output quality is significantly better and latency is worth the tradeoff. There's also enough cost optimization strategies for applied AI applications that token cost rarely outweighs unless it's a SIGNIFICANT difference (e.x. 100-200% more).

asdf

Err I just tried this with Claude and it responded: "Drive — you need the car at the car wash."

:)

There's nothing novel in this article. This is what every other AI clickbait article is propagating.