> 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.
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.
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.
But there's two ways this could be true: Frontier models costs rise, or (more likely) experience dev costs fall
That's only true if a single company owns the frontier, otherwise the alternative is "a rival frontier model" and the cost will be the marginal price of the compute + amortized training costs.
You're car will have spun off the road and you'll find it harder and harder to control it and keep it on the road because you have less and less visibility into the vehicle, nor will you be able to clearly see out your windscreen to use the car and road metaphor. You'll be driving blind eventually, unless your working on some simple closed toy problems and/or other small systems.
Building large systems means understanding the system. Without understanding the system, you lose control of it.
The LLM can probably help you understand the system to gain/regain some control of it again, but now you're becoming a system specialist rather than someone who's repeating, "fix it" and "make it good" or whatever.
Self-trained people (like me) are particularly susceptible to it and we're heavily represented in the software world. A lot of us either recognise that (or are coached) and invest the time learning the benefits, and limitations of, software architecture. And, importantly, keep reflecting, learning and updating our practise.
I keep going back to the YOLO mode every other year and try out new languages to see if we still need the structure and abstractions. Then VMs came along and all I can say is they're both even more important and now we have an army of virtual "ADHD idiot juniors developers" at our finger tips it's even easier to tell the good and bad abstractions from each other.
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.
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.
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.
To reach a more optimal solution, significant human steering is reqiured for every tiny decision. It’s the same as how early models needed hand holding on the basics, playing out again in the finer details. Human experts need to inject “eureka moments” from the outside.
And no feedback loop that I’ve tried has been able to conjure an understanding of these finer details that, as far as I can tell, just aren’t represented in the weights.
Modeling the basics of software engineering was easy, since things like writing code that passes some tests is easy to RL. But for anything not easily RL-able, we’ve basically ran out of human generated tokens to distill from.
Without some breakthrough in generalization, I remain unconvinced that we’ll be able to model the finer details of software engineering by looping the existing training corpus back into itself. Garbage in, garbage out.