upvote
it doesn't worry me too much tbh. This is really just cutting corners and going this route leaves you with some kind of additive ship of theseus piece of software you don't understand and require your frontier model to work with, which just... becomes more additive and gross. right now we're in some proverbial heyday of everyone seeing how absolutely grand of a thing they can make with frontier models. over time i expect some old design philosophies to take hold with people who use LLM's successfully and find a place again paired with developers who understand why such layered methodologies are important... because this whole AI thing wasn't the silver bullet CEO's and crazy execs thought it was. They will eventually get sick of the support burden of badly designed stuff. i anticipate a bit of pendulum swinging back towards "still using AI, but we need smart people to do it because it's expensive and we want it done right". Right now a lot of companies are being extremely reckless imo and they haven't fully realized/felt the cost implications of trainwreck software yet.
reply
What if those “cost implications” are just asking Opus 6.7 to fix whatever issue cropped up?
reply
Exactly.

In a way, that’s the situation today. You can pay an experienced developer $$$$ to do it right, or you can outsource it and pay $$ but pay extra for more layers of review, have lots of unfixed bugs and more tech debt.

You are proposing that instead we pay the frontier model to clean it up. If it can, I expect it to cost somewhere in the neighborhood of an experienced dev because that’s the alternative. That’s the way the frontier AI companies will extracting the value of the work from you.

reply
> I expect it to cost somewhere in the neighborhood of an experienced dev because that’s the alternative

But there's two ways this could be true: Frontier models costs rise, or (more likely) experience dev costs fall

reply
Opus on enterprise pricing is not exactly cheap.
reply
In complex systems, issues keep piling up faster than you can fix them.
reply
> haven't fully realized/felt the cost implications of trainwreck software yet

As long as the API is private or not dependent on by automated systems and you have good test coverage, you can get away with bad code IMO since you can always refactor. If it looks stupid but it works (and can be refactored/fixed/improved later if needed) it aint stupid.

reply
Used to say this about dev written code, if it has tests, I can usually live with it.
reply
IMO the fundamental principles and "conflicts" are still the same, but many have forgotten about them with all the hype and sense of speed. The industry will slowly rediscover them.
reply
Support burden? When did companies care about customer support or system maintenance?

They already did the bare minimum allocation to both despite engineering screaming at them.

I highly doubt executives are going to accept slower release and sale cycles in order to provide better support.

If anything, I expect this trend to accelerate. I’m imagining the opposite, a plethora of AI slop with increasingly burned-out engineers.

reply
> slower release and sale cycles

Sales are out of their control.

If there’s a market for quality and you don’t have it, sales are going down no matter what the PHB wants.

If there’s not, watch out for the vibe-coded competitor.

reply
Buggy slop products will burn buyers and then people will buy less. The very-early-80s video game companies shoveled out slop, including a few games that wouldn't even launch. Which led to the Great Video Game Crash of 1983.
reply
I've been using layered development techniques like the parent says even with frontier models, just one agent at a time with Zed.
reply
deleted
reply
I just use a suite of tests to enforce the mechanical standards (dry, encapsulation, etc) and arch documents for shape + reviews of new work against the two. I’m not seeing any significant drift.
reply
Yea, this is one thing that gets me. Vibe coding and freestyle prompting gets wildly different results. Starting from a set of specs and expectations routinely gets me reviewable and we'll tested code. Sure, running the full test suite alot slows things down and uses more tokens, but when I hit a five hour or weekly window, I just roll up my sleeves and start working without the model because the code is layed out the way I expected and is designed to fit my meatbag workflow and pace.
reply
You must not be looking very closely yourself then.
reply
When is the last time you used a frontier model? Any chance you work someplace that forces you to use last year's model (or any American open weight model)?
reply