Comments URL: https://news.ycombinator.com/item?id=49724928

Points: 2

# Comments: 0

If you consider this as a cost to be compared against the question: "What does it take to be able to prove that you have a model that can solve the hardest problems that humans know about?", then spending a some amount of thousands/millions to know the boundaries of that seems not too important in comparison.

You've also got to consider this as compute that's allocated to pushing the frontier of what models can do, so while it's using GPUs that have been paid for etc., it's not like it's a cost that's supposed to be use less of this so that others can have capacity. If you made researchers afraid to use capacity like this, a lot of the things that improve would tend to do so significantly slower. (some may say that's a good thing ;)

A good way to think about this is when tokens are free, you get to choose whether you're optimizing for latency or intelligence rather than having to consider price.

---

Publically, tibo (Codex owner) in Feb this year: https://x.com/thsottiaux/status/2024649339344445825

> OpenAI employees currently get unlimited inference. Usage is now peaking at > XX billion tokens per week for some of them.

Mathew Berman (AI Youtuber) in Jun: https://x.com/MatthewBerman/status/2067270730795134984

> I've used 25 billion tokens in the last 7 days.

My guess was it was probably this was more a nerd snipe than any action from OpenAI that was a "massive team" being put on it. Literally someone looking at this and asking "I wonder if our models are good enough yet".

It's easy to assume that having access to massive compute amounts means significant coordination, but this assumes that you're looking at the costs of this sort of thing from an external lens. Internally, tokens are often treated as free and infinite.

> A real capacitor makes the task more interesting. A ceramic part may provide much less than its advertised capacitance once it has voltage across it. Parts have tolerances. Adding more capacitance costs more, takes up space and makes the rail slower to recharge when the power returns. A design that works with nominal values can fail with the parts that arrive.

It sounds like from a reasonable reading of the benchmark post that there's some things that are being tested that are assumed to be criteria that you expect the models to intuitively find those things to be important (i.e. the stuff about working on parts that have tolerances etc.). If that's so, then this really feels like mostly an exploration of whether an LLM has a good understanding of unstated constraints and has an appropriate in distribution set of priors that would be able to form models where it's reasonable to design on those lines.

It's hard to tell whether this is a problem though as the methodology is imprecise.

If you're spending time on evals against your own product, I'd be super curious to see how far you can get to by using a top tier model to produce generalized instructions for lower tier models. E.g. in a loop: "This eval missed X. what's the simplest single instruction that would have helped this session consider that as necessary that can benefit all future runs. Stick that in AGENTS.md and retest."

NY Times: https://news.ycombinator.com/item?id=49543821

Comments URL: https://news.ycombinator.com/item?id=49544650

Points: 50

# Comments: 39

I have some speculation that maybe the people doing the model post-training tend to be younger researchers that haven't worked on large complex software systems, so their taste isn't as developed in this regard about what things are important here.

But this is an area that can be steered with appropriate early instructions ("When choosing tradeoffs of implementation, build for long term maintainability and understandability of code over implementing just the exact code necessary to solve the issues. etc. chain of thought often includes information that would have to be repeated in a future agent session, make sure to persist it to code or external docs so that future sessions and user understanding is respected.")

It can also be done as a post-change step with similar effects. And you can use your agents to build this layer into your general modus operandi for dealing with the crimes of generated code. But one of the things that all AI labs should be doing is looking at AGENTS.md on real project as being hard expressions of what failure modes real projects have noticed in models generally. Don't wait fo the bugs to be raised on these things, use express preferences that show that there's a problem. Go trawl github for these in bulk to use for future post-training.

This is somewhat of a high impact argument to test. I wonder if the case will eventually get to working this point out.

> The latest models got even worse.

Which models? This is one of those things that likely has both model and domain specific aspects that impact your experience. In my experience with OpenaAI models predominantly (I previously worked there), they've improved significantly over the last 6-12 months. My experience with Claude is worse, but I haven't spent as much time getting into a mechanical sympathy there. They're still not perfect though and I have many steering docs that help avoid the biggest problems in the models I use when generating docs.

I think for this argument to be true, the axiom that supports it is that the models have just as much context as they will ever have, and you cannot see being able to give them more / enough to be able to understand your perspective. That feels unlikely to be a position that doesn't change. As a society we're giving more and more context each day to this, and that makes this a valid opinion now, but one that erodes over time.

My guess is the actual bottleneck would be directory traversal and metadata stuff - i.e. trying to keep the pipe full, not saturation effects.

Yeah I know on src/dest. I've done this sort of approach countless times in various technologies in the past 40 or so years, but that always puts the mechanism for checking things in onus of the human rather than having that one command that does it all right.

Anyway, not a slight on rsync in the slightest - it doesn't have this probably because no-one realistically actually needs it most of the time.