the description is gold, everyone can find something wrong about it.

And yet somehow the tech blogs and such always scream about developer productivity. Go faster. Go faster.

From what I’ve seen over the years, only mids care about finishing fast.

The guy who wrote this is an idiot, but he became so in a world where "LoC" is a metric -- one that Goodhart would love, but alas.

This is honestly the road to hell and the ~good intentions in one.

I am genuinely trying to keep up with things, but what I see is completely different from what you've been describing

1. My recent experience with launching a swarm (3-4 Claude opus agents) ended up with a fiasco: a simple task ate $15-20 Claude credits in less than ten minutes. Looks indeed like science fiction, but doesn't produce anything

2. In my current role as a team lead, I had to review a lot of code and I do what I haven't ever done: decline the whole PRs as they contain a lot of architectural changes that complexify the system in order to achieve the goal.

3. I write much less code with Claude code these days, mostly because I don't trust it and have to recheck every single scenario. I trust junior engineer in our team more than I trust this instrument.

Opus 4.6 is genuinely pretty decent at programming now if you give it a good backbone to build off of.

Soup from a Stone.

nah such narratives are mostly pushed by Ai companies (it is obvious they need to sell it as business tool not personal buddy). Of course some managers/companies are buying into this narrative, and it is also understandable bc idea sounds like panacea especially if sell it further to investors :) and we see whole circle of snake oil sales

Dude this boils down to "moving a hundred people is simple, I am a trained pilot and I used this 747 to move them"

Like great, you have the thousands of hours of training time required to understand a machine of that complexity and produce results.

Joe dirt has 8000 hours in his puddle jumper, and that's the majority of the people these 747s are being foisted upon. They know how to fly, and they provide that service reliably.

Telling them to move 5 people with a machine they don't need the volume or distance of, is irresponsible.

What I have found: all that stuff that was evolving over the last 30 years: roadmap definition, sprint planning, unit tests, regular independent code reviews, etc. etc. etc. that those of us who "knew what we were doing" mostly looked down on as the waste of time that it was (for us), well... now you've got these tools that spew out 6 man-months of code in a few hours, and all those time-wasting code quality improvement / development management techniques... yeah, they apply, in spades. If you do all that stuff, and iterate at each quality gate until you've got what you're supposed to have before proceeding, those tools actually can produce quality code - and starting around Opus 4.6 I'm not feeling the sort of complexity ceiling that I was feeling with its predecessors.

Transparency is key. Your code should provide insights to how it is running, insights the agent can understand (log files) insights you can understand (graphs and images, where applicable), if it's just a mystery box it's unlikely to ever do anything complex successfully, but if it's a collection of highly visible white boxes in a nice logical hiearchical structure - Opus 4.6 can do that.

Unit tests seem to be well worth the extra time invested - though they do slow down progress significantly, they're faster than recovering from off-rails adventures.

Independent reviewer agents (a clear context window, at a minimum) are a must.

If your agent can exercise the code on the target system, and read all the system log files as well as the log files it generates, that helps tremendously.

My latest "vibe tool" is the roadmap. It used to be "the plan" - but now the roadmap lays out where a series of plans will be deployed. As the agent works through a plan, each stage of the plan seems to get a to-do list... Six months ago, it was just to-do lists, and agents like Sonnet 3.5 would sometimes get lost in those. Including documentation, both developer facing architecture and specifications (for the tests), and user facing, and including updating of the documentation along with removal of technical debt in the code at the end of each roadmap plan stage also slows things down, and keeps development on track much better than just "going for delivery." So, instead of 6 months of output in a day, maybe we're making 2 months of progress, in a day, and generating about 10x the tests and documentation as we would have in those 2 months traditionally - in a day of "realtime" with the tool. 40:1 speedup, buried under 500:1 volume of documents created.