There's a huge load-bearing assumption in it, as well, which is that AI agent-generated code is correct and bug free. The tight loop only works if the agent reliably produces working, correct, production-ready code. If that were the case, the loop might be intent -> build -> observe. But in reality, it's likely intent -> build -> realize the AI hallucinated an API that doesn't exist -> fix -> discover it broke something else -> fix -> realize the architecture doesn't fit a constraint you thought you had -> start over.
Not to mention that SDLC things like, I dunno, PR reviews and requirements planning aren't some arcane ceremony designed to waste everyone's time. The ceremonies themselves might be bloated, but the function serves a purpose. Generating 500 PRs isn't a flex either. Volume is not a feature. If your system produces more changes than you can verify, you don't have a review problem, you have a quality problem.
There's some truth buried in here, but the overarching post is so wildly disconnected from real software development that I'm having a hard time following along.
Greenfield prototypes? Sure, maybe there's a case for that. But the minute you hit any novel or complex system with more than a couple of engineers, this falls apart pretty fast.
what people are betting on is that the latter reality will give way to the promised land of intent -> build -> observe. the prize for that is self-evidently enormous.
A more interesting take on this, in my mind, would be "The SDLC lifecycle has shifted away from engineers and toward product managers," but that's not the author's argument either. They're arguing that it's _dead_, which is clearly not the case.
