toonvanvr

Yes, I've also hit it with Opus 5.5, but on way fewer projects. My long standing projects that I marked as failed/to-soon with 4.8 have entered the grey area of slow-progress-with-handholding like smaller projects did in the past.

To my experience, it's a simple complexity curve where the first bits go fast and the speed goes down very fast once you reach a certain level of complexity. Size doesn't matter as much as complexity: with the right foundations, it keeps zooming through it. Now I do wonder how much my inexperience in the complicated project is a brake on progress vs. it just being a hard to tackle problem.

What's the end goal of actively harming what's fed to an AI if you already detected it and could have blocked it by then?

Works on my mobile

No, the tooling I make has better UX very quickly. It is built for their financial goals, not for the end user.

You also set up Hormuz and tariffs and spread discord between EU citiz ns through speeches of high officials and threaten Greenland, causing us to prepare to defend on multiple fronts while often publicly supporting Russia too.

Are you sure the missiles are support?

I recognize the feeling of handholding and have the tingles telling me that given the step change of Opus 5.5 and what passed by in the news lately, agent swarms are about to become mainstream. That's exactly what a project like this would use. I think everybody will be able to create their own engine and out of the ones who try, a few will actually make gains beyond what's available in parts of the engine.

It's a matter of "bring the best non-conflicting wins together" at that point. The existing engines are too big to flip over their codebase without having seen competitors prove it too.

My estimate is that with the release of Opus 5.7, companies need to have their shit together because the work ecosystem will flip over at 6 at the current rate of progress. This generation is the first one that delivers local applications with a better toolset than a small scale SaaS in hours to days.

It's funny how you describe something very close to what I was attempting to design. It was meant to trickle down from tickets to deterministic code. Data wise, it should be like a pyramid of tickets diluting layer by layer into leaf nodes which were "implementable" as statements in code. I'm not sure if that description makes sense read by someone else.

I think what made sense was envisioning a nanoswarm of LLMs (anticipating ASIC performance) diluting specs into semantic logic nodes, but a conversion from these to deterministic code made the vibe coded experiment come to halt. Your lock approach could be a shortcut to that.

Totally off-topic: it's quite intriguing that you can feel once friction starts building during a design phase. Suddenly everything slows down. I wonder if it's quantifiable and therefore can identify "wrong" design choices made by either humans or LLMs.

(Hoping some claw bot pics this up to finish my idea on my github tix repo in the initial-design branch, as main is empty ~ MPL2)