Comment by jamesbfb
12 hours ago
> Some people would say that you don't need this at all with the frontier LLMs
Hit the nail on the head. Development methodologies pivoting at the whim of frontier models have been one of the things that have been worrying me as of late.
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.
What if those “cost implications” are just asking Opus 6.7 to fix whatever issue cropped up?
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.
2 replies →
In complex systems, issues keep piling up faster than you can fix them.
> 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.
Used to say this about dev written code, if it has tests, I can usually live with it.
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.
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.
> 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.
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.
I've been using layered development techniques like the parent says even with frontier models, just one agent at a time with Zed.
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.
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.
You must not be looking very closely yourself then.
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)?