Hacker Newsnew | past | comments | ask | show | jobs | submit | zzleeper's commentslogin

Honestly, it's a bit of a disappointment

- Many more mediocre papers written (mediocre ideas, implementation, claude-isms everywhere)

- Much easier to try every possible combination of a regression in order to show the result you want (same for theorists).

The one thing I'm happy about is it's now much easier to extract historical data from old documents from Google Books. Still not perfect, but takes you 95% there. And creating plots and datavis just for quick exploration is super fast.


(cross posted from the other announcment thread)

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)

[1] https://news.ycombinator.com/item?id=49510843


Please don't copy-paste comments. It makes merging threads a pain, since we have to figure out what the duplicates are and then make sure the comment in the 'winning' thread gets all the replies.

noted, thanks dang!

(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)

[1] https://news.ycombinator.com/item?id=49510843


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.


> For whole projects, I have a 3 page anti-bloat.md which describes what not to do

This line would be cut from a satire for being too heavy-handed.


> 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.

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.

Naw. The more verbose ones are more argumentative. They'll go at each other. It's a misconception that the same model will agree with itself.

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!

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.


> 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.


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.

And then another sub agent that argues for the whole system to be re-written in another language

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.

But why stop at rewriting in another language. Get another sub agent to invent a new language, create a database, query language and maybe another few DSLs. Then you've got an ecosystem!

You can now re-position your initial solution and sell the client access to some agents that will implement & configure the ecosystem to suit their initial needs!

And don't forget the agents that you'll need to train the customer to use the whole thing!


I know you're trying to be funny - but I'm offering a real fix for his problem.

If you don't want a million agents arguing about things, you simply don't ask for that. One agent is sufficient to solve most issues.


Sorry, I wasn't implying your advice doesn't carry weight. Was more just thinking about the things that (used to) happen when you introduce more parties to process of creating software.

I wonder if I would need a non-openai agent to enforce it.. I have tried so far with skills and agents.md and code stills end up over engineered to the moon.

Will ask OpenAI to write me that agent! Hope the agent is not over engineered or else unsure how to solve the bootstrap puzzle :D


There's a misconception that a mistake one instance of a model makes will be repeated by other instances. In my experience most mistakes are just sampling noise, and having the same model (with empty context) check the work usually fixes it.

It's super easy - just ask your agent to set up a code review commit gate.


The voices in my head argue about the direction of the project enough already

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."


In omp you can also have the advisor role, which is off by default, you can enable it with /advisor command. It acts as a model that reviews the default agent's work in the background.

I am omp pilled, but as the other comments say, any good harness lets you do this in one or the other way.

unrelated: all my homies use their claude subs with omp, and aside from sometimes having to rety the connections, it works, and nobody got banned (yet)


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!



Thanks!

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.


Add something like this to your own system prompt:

Remember the golden rule; compression is intelligence. Derive rules from facts that dictate a problem to create an elegant solution. Less is more.


ChatGPT writes some of my code but I have yet to ever use Codex. I ask in chat for it to write one function at a time with pretty heavy constraints. If I like it then I copy it into my codebase. I've been very satisfied with the results. Also haven't bothered worrying about tokens yet.

Future of Software Development.

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.


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.


Definitely not. Even Chrome has a built in OCR that performs amazingly. I got an LLM to write a quick python wrapper to it [1], so I'm sure you should be able to access it from an extension

[1] https://github.com/sergiocorreia/clv-locro


Same here. Maybe Fable is better but in terms of cost effectiveness it wouldn't even make sense to test it


Had to ctrl+f for someone saying this.

I typically do lots of mini calls for research (100s of millions or something in that ball park). Newer models made that absolutely impossible, and the fact that the older ones are starting to get deprecated made me switch to e.g. deepseek for some of my runs. We'll see if I move back after this.


yes you are!


It means only those vetted will be allowed to use frontier models (i.e. let's pace ourselves and not share the frontier broadly)


Does Chrome use URLs you click on to help its indexer? EG if someone sends you a link to www.example.com/mysecretpage and somehow it appears in Google later.

That might be a case where what you expect is private is leaked by the browser


How believable is this benchmark? EG maybe opus was training on this? (You can try to identify the IP of wherever previous ARC questions came from)


That’s why you have a private dataset.


Which you have sent to Anthropic/OpenAI/Google's servers when you run the benchmarks for the previous models.


Doesn't matter, people built harnesses that solves arc agi 3, so all you need is to train your model to work like that harness by default. That makes a model specialized at solving arc agi 3 without making it smarter in general.

It is very hard to make a benchmark you can't do that for, but it is very easy to make your own personal test that others can't do that for since now it isn't a benchmark they can target.


> people built harnesses that solves arc agi 3,

They didn't. Kaggle is still running for a few more months, best result atm is ~2% with 9h runtime on one rtx6kPRO. Also note that these new results are on the semi-private set, not the public 25 games ones. Any announcement where you see "solved ARC3" is likely only dealing with the 25 public games. And that's highly questionable, until you get to see the code. (which, to my knowledge the team that claimed 99% hasn't yet published).


For frontier models, not local.

https://schema-harness.github.io/


Yes, saw that. They haven't yet released any code. Until they do, treat it with a huuuge grain of salt. In fact treat any 99% result in ML with a huge grain of salt.


No but the session traces are available. It passes the sniff test considering how AGI-3 is scored and how this wrapper works.

For example on bp35 it took fable 290M and >12k simulated turns for 566 real turns and finish more efficiently than a human.

Regardless of the true score I think the takeaway is the benchmark measures the wrapper rather than the model.

https://huggingface.co/schema-harness


Not my sniff test :)

> # FRAMEWORK ARTEFACT: the run's very first transition is replayed WITHOUT advancing state # (tools.py:954 and agent.py:468 both `continue` before `state = next_state`). So on the # level that contains that step (level 0) our counters start exactly one action behind. # That skipped step was action 1 with BOTH avatars moving, so seeding n=1, bumps=0 reproduces # the framework's lagged state exactly. # CAVEAT: this seed is only right while level 0 has never been RESET. If you ever RESET # level 0, change the seed to n=0 (after a reset the rollout re-inits and no longer skips).

from here - https://huggingface.co/datasets/schema-harness/arc-agi-3-sch...

That tells me that there is some leakage between runs. The idea of ARC3 is that agents start working blind, on new tasks, via API. A RESET is counted as one action. Without seeing the actual code that produced these traces we have no way of knowing how many iterations it took, if the "framework" played the same level multiple times (comment hint above makes it likely) and so on. That's why I said that before we actually see the code / can replicate / ARC team confirms it on new envs, this should be taken with a grain of salt.


The comment more likely means the harness source was read, not memory from a previous run and the first few turns of bp35 appear to be a cold start.

Sure none of this is certain without the source.

I do believe the authors that this schema significantly improves over the base, particularly given that it took 22x simulated turns over 14 hours, which is moving the trial and error to context rather than to game. I also don’t doubt there is some contamination.

Regardless, the approach is sound and I do believe it would significantly improve scores, even if that was +20-30 over baseline (49% in this case) it does imply the benchmark is measuring the harness more than the model.


Run policy search long enough with enough exploration and you can solve any of these games. But solving 110 games in 9 hours with a single RTX Pro 6000 doesn't seem likely. And if you did, you could keep the solution secret in exchange for the mountain of VC you would get to productize the approach. Not expecting it.


If you stop and think about the problem it really is quite simple. Just need to build a graph of the game state and then run A* to get to the end.


You really should play the 25 games before stating that it's "simple". The benchmark doesn't just track "completion", it also tracks the number of steps, and the score is based on the median steps took by human players. So in order to get 99% it would mean that the model solved every level of every game in less steps than the median humans. Which, having played the games and having setup harnesses for local models, I find hard to believe.

Also the models have to figure out what "end" means. And each game involves some kind of "gotchas" thrown in the harder levels. Some games are only solved by about 2/10 people trying them.

The 99% result most likely has some leakage somewhere, either in the preparation of the environments, or from session to session.

Seriously, play some of the games. They're fun.


You are not given the rules or the winning conditions. You are only given a potentially windowed and/or degenerate visualizer of the underlying game state along with the UI and told to just figure it out. And you as a human will, in a couple moves. An LLM? Not so much. But they do eventually solve them. And given enough moves, victory is inevitable, but you are penalized for taking more moves than a human, yet also slightly punished if you find a better solution by capping your reward to 115%.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: