Comment by zzleeper
13 hours ago
(Posting partly so I can revisit my predictions when they open access more widely)
A big problem I have with OpenAI's models (and of course Claude) is that they tend to write the most over-engineered pieces of code, beyond the imagination of any architecture's astronaut.
Just this week I asked 5.6-sol-ultra to update a 1000 LOC python script I had, to "incorporate the key lessons learned when using it for another project".
I left it overnight and went to sleep. In the morning I realized it had created a monstruosity of 180 PYTHON SCRIPTS, with maybe 100,000 lines of code, each more crazy than the other. It took me minutes even to track where a single action took place, due to all the crazy imports, defensive coding, and premature optimization.
Similarly, anything they write is riddled with jargon that almost feel like they want me to give up trying to understand. Made up phrases that ended up with me having no idea of what was going on.
So now to my assessment: The reason why " Nobody Has Actually Built a Software Factory" [1], and why even SOTA LLMs struggle so much with open-ended unsupervised tasks is precisely this. They somehow let complexity explode, and unless it's also accompanied with an explosion in e.g. the number of agents, the amount of processing time, etc. then projects become broken/unmanageable.
Sure, LLMs are great at producing code that can be thrown out, so they are amazing when searching for exploits, for instance. But as of 5.6 they still lack either a better harness that encourages KISS principles, or a better RL step.
(And not sure why, but doubt Astra will fix this.. they seem to be aiming for AGI and for beating crazy benchmarks, which is not very aligned with KISS)
> Just this week I asked 5.6-sol-ultra to update a 1000 LOC python script I had, to "incorporate the key lessons learned when using it for another project".
> I left it overnight and went to sleep. In the morning I realized it had created a monstruosity of 180 PYTHON SCRIPTS, with maybe 100,000 lines of code [..]
Sounds like the model has accurately internalized the second-system effect and is fully ready for demanding enterprise use.
Probably this complexity was needed to beat all those benchmarks.. While I hate the code it produces, and the overwhelming documentation, I really enjoy how sometimes it's able to keep trying new things and testing, till it finds something interesting and valuable.
The defaults are bad, but these models are highly steerable.
For simple scripts adding to the prompt something like "do not over engineer, do not gold plate, no CLI args, keep it simple" does wonders.
For whole projects, I have a 3 page anti-bloat.md which describes what not to do, stuff like:
> Minimize lines of code, number of files, classes, protocols, factories, wrappers, and dependency-injection objects. Prefer a coherent implementation that is easy to trace end-to-end.
> Use concrete dependencies directly. Do not create protocols, abstract base classes, or adapters unless there are already two real implementations.
> Use direct state fields or a small state dataclass; do not introduce generic lifecycle, state-machine, observer, snapshot, or event framework classes.
The funny thing it was codex which wrote this, I've asked it to analyze an over-engineered abomination that it produced, and to categorize all the bloat it could find.
I also use "do not overengineer and do not gold plate." I also sometimes tell it to "avoid bike shedding." These are high signal words to the model(s) and they work!
I also have found what I believe is a bad training bias in the design of release related CI workflows toward proof of release artifact provenance.
Both major frontier models love provenance programming in CI, so much that they will spin endlessly trying to solve basic CI functionality at the same time as ensuring SHA's match up across lengthy (often already complex) cross-system pipelines.
I had thought some of my durable context was causing this, and sought to strip anything that might be triggering this behavior.
But then I come upon some more work in release workflows comes up, and boom its back! I couldn't believe it, I called the AI out on it and it agreed it had been told specifically not to do this but was doing it anyway. It did kindly stop and remove the commit(s).
Somewhere, something was oversampled in training because the AI will try their damndest to build this stuff. The worst of it is that it can often involve lengthy, sometimes resource-heavy CI runs so the validation of this unnecessary stuff can have very long feedback loops.
And, sometimes you actually need the provenance. In this case, I've had success forcing the AI to split the work up into functional capability completely devoid of artifact ~chain of custody and get that right before attempting any kind of provenance work.
Bit of a rabbit hole on this, but the above cost me a lot of burned tokens so hopefully helps someone...or some AI.
[dead]
Would you mind posting that code to github? I'm curious about the complexity you're describing.
If not, no worries!
Sure, why not: https://github.com/sergiocorreia/overengineered-rand-mcnally
The original script was mostly very simple python:
1. Download some public PDFs. 2. Have a double for-loop (over PDFs and pages within PDF), 3. Use a library to call gemini-3.7-flash and ask it to run some OCR 4. Save JSON outputs, save a csv with results, validate with some Stata code
New code folder was 189 files. Just the PDF download folder is now 7 files involving an adapter, a source manager, an acquisition manager, etc.
Every instance of saving a file involves saving a temporary copy and then moving it, so e.g. I lose power, we minimize the risk of corrupted files.
And so on!
https://github.com/sergiocorreia/overengineered-rand-mcnally...
> +14,360
> -349
LGTM!
Thanks!
Exact same thing happed to me. I gave it a small/medium-sized ticket, walked away, came back to a 25,000 LoC monstrosity that both Fable and another 5.6 Sol agent said is 98% useless and should be thrown away.
Contractors have been charging by the hour for eons. What makes you think tokens are any different for OpenAI?
> monstrosity that both Fable and another 5.6 Sol agent said is 98% useless and should be thrown away.
This is why you should really have a sub agent review the code before allowing a commit.
Your harness will do it all for you. Just ask.
Based on the propensity for models to love their own words, a different model to check might be a good idea.
1 reply →
You should have a sub agent adversarially enforce KISS before every commit.
"You should have a sub-hammer to adversarially enforce that your primary hammer accurately drives nails into wood"
We wouldn't accept such behavior from any other tool, machine, or computer program. At least most of us would not. To paraphrase the old saying: Some people, when confronted with a problem with an AI model think "I know, I'll use an additional AI model." Now they have two problems.
I find it very intriguing that two lineages of models -- from two different companies -- that are supposed to be painstakingly RL'd to become human-level programmers are actually consistently bad at it out of the box in very similar ways. One would think that at least one of OpenAI and Anthropic would (could) have pushed their model to a direction different from "if you can solve a 100-line problem in 10,000 lines, do it".
Human level programmers generally suck too. Unending security holes have been human behavior ever since we started sharing computers.
Also, programming isn't a destination, it is a process and everyone has a different ruleset on what that process looks like. Writing a computer program of any complexity is not a determinalistic process. Trying to compare it to a detemanilisic tool will just leave you with broken analogies and a poorer understanding of the world.
Or another way to say this. If programming were deteminalistic we'd have solved it without AI.
1 reply →
Also very puzzling to me. And the jargon-speak, albeit is more of an issue for Claude, is still puzzling. Wonder what part of RL led to this.
> We wouldn't accept such behavior from any other tool, machine, or computer program.
Von Neumann, 1952: "Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components." The whole result is that you get an arbitrarily reliable machine out of unreliable parts by adding more unreliable parts and voting. Every ECC memory and RAID array descends from it.
And then another sub agent that argues for the whole system to be re-written in another language
The voices in my head argue about the direction of the project enough already
If that's your goal, then yes. Invoking sub agents (with a fresh context) corrects most of these problems. Ask your harness to create a commit gate.
5 replies →
How can I set such a sub agent up?
In your harness, say:
"Going forward, do not allow a commit without a sub agent code review."
1 reply →
Future of Software Development.
Why would you put it on ultra high thinking and let it run all night to do a simple task it makes no sense the error is the users. And of course OpenAI is gonna let you burn as many tokens as you want doing this.
On the flip side if its a super simple task, surely a "next gen dev replacing" LLM can figure out when to stop. Even more when it's a higher level of reasoning.
I think this is fair. If you ask a staff engineer to delete the duplicate files from a directory, he will likely do it faster and more efficiently than a level 2 engineer.
But perhaps this is the kind of thing that the best 'ai guys' out there solve with something as surprisingly simple as an instruction to "Always try a simple solution first and optimize only if you find clear proof of a problem." I feel like prompts like that seem too simple to work, but some of the time they shockingly do.
This is user error.
Prompting the model and giving it a proper set of documentation are still vital skills that aren’t magically going away.
Yes, it turns out that using these machines is a littler harder than "make me the thing I want, make no mistakes, do it the way I want you to do it". This isn't "prompt better" advice, it's just to say that you can't simply set it and forget it. There is still engineering work to be done. If you're not watching the thinking traces and catching when it's about to go off the rails, it'll gladly do so. But you can stop it and redirect it.
It's like a Tesla fsd; it kind of works but you have to be vigilant since it's been known to turn into oncoming traffic, so you have to be ready and able to take over at any time.
Or maybe think of it like a roomba. You can put it on your floor and eventually it will clean the whole thing. It will do it inefficiently, vacuuming over the same spot 30 times; and the actual work will involve wandering around and bumping into everything. If the stairs are not blocked off it will plunge right off. But those shortcomings don't mean it can't be used to reliably clean the floors.
Or it’s like being an engineering manager, where poor direction on your part results in the team chasing rainbows and unicorns in an attempt to please you. But sure, it’s the tool’s fault!
1000 loc of script, why even leave it there for the night? were there rocket trajectory calculations??? I don't think so. should be ready in 5 mins tops. why people make their own lives harder?
You should have some basic context file about software practices you prefer, otherwise it gets bloated.
I just went to bed and left it running; was expecting maybe 20 minutes :)
And I did gave the program a bunch of code guides -- this [1] for instance -- which included quotes like "Prefer straightforward code over clever code." but somehow that didn't matter.
[1] https://github.com/sergiocorreia/overengineered-rand-mcnally...
I'm an AI professor, and the same thing happened to me. I had written out contracts and specs for some novel algorithms to compare. And instead it created a new sandboxed environment with 20k lines of code to ensure we do gold standard science.... didn't implement the algorithms at all. In another case, I left it overnight with a plan, and it decided to write a 50k line new overly engineered plan. Suffice to say, I don't use any frontier models for doing coding work anymore. I use them to make detailed plans and use good worker AIs for execution, which don't overthink everything.
You write many pages telling the AI to split and structure the scripts into a bunch of folders, so why are you surprised it did exactly that!?
I just ask it verbatim “recommend some cleanup” with /plan, review, and then apply.
>were there rocket trajectory calculations???
Code-wise, they're simpler than you might think, hehe.