ha - wh33zie and I have had this discussion before about sans-io on hn at https://news.ycombinator.com/item?id=40872020
2,444 karma · joined June 6, 2011
I suspect you're getting down voted on this as it feels like this is a failure to educate yourself on something that feels like it should be relatively easy to do so in less time than it took to type your message.
I've also given various models access to the tools necessary to measure performance and instructions to make things faster and they do pretty well. Hill climbing on a validatable measure is reasonably easy these days.
My direct experience here directly contradicts pretty much everything you've said can't be done. I.e. the human out of the loop stuff.
(Bias, I'm more familiar with Codex than Claude as I worked on Codex when I was at OpenAI, but mainly on the TUI not the app - take my better than Claude with a grain of salt perhaps).
I think to do this well, you have to have all the comms, code for various projects over time and do large scale analysis with tooling to get the various outcomes. A lot of "good and bad architecture" is really post-hoc rationalization of decisions that worked, and it's likely super noisy.
I'd love to see this done, regardless of how difficult it is.
Counterpoint: people at corporations who want to contribute to OSS that is GPL licensed often cannot because the legal risks of doing so is too high for many corporations to bear. MIT / Apache licensed software doesn't have this problem. Yes, you might have that software internally forked and used and see that as a net loss, but more often you'll likely find that a company does not want to own their own fork of an open source product and actually contributes back. GPL is friction there, and its supposed benefits seem (at least in my limited experience in 20 something years in the industry) don't seem to outpace this downside. (I put my money where my mouth is on this and release all my OSS as MIT/Apache generally).
Obviously big things like the Linux kernel or other fundamental tooling this doesn't apply, but for anything smaller the GPL is bad.
One comment I had (I think I may have posted something like this on a github issue too) is that the site has that feel a bit of the sort of UI from the early 2000s - like helm, or cold fusion dashboards. There's something about it that screams developer generated UI rather than designer influenced. The light mode looks ok, but the greys on the dark mode don't feel particularly scream well suited to a theme website. (Obv. just my purely subjective opinion here).
The swatches preview on the search results pages probably should be much smaller swatches - similar to the copy embed perhaps. And the background of the top part of the card should match the background of the theme.
https://github.com/orgs/community/discussions/208952#discuss...
Instead or alongside this, how about making notifications good? There's some concrete simple improvements that would help triaging in general.
1. Provide ways to filter notifications of a specific state (merged, shipped release, closed) so these can be handled in bulk easily
2. Filter by type (issue / pr / release)
3. Provide access to the done state as a filter and via the api, so we can use non github website tooling to manage the notifications
4. Filter by author (e.g. let me filter dependabot notifications so I can handle them in one pass)
5. Show and allow filters on PR check status so I can look at PRs that are ready for a quick next step rather than ones that require digging into failures etc.
6. Make this all available properly via the API so I can let my clanker interact with this stuff based on rules that it has to help me triage stuff. Right now there are enough missing fields from the notification APIs that it makes it impossible to work around the shortcomings of the notifications with tooling (without screen scraping /notifications).
All of these things would be better for interacting with work to be done.
A general rule on this is if the information would make it easier to understand what work is to be done, to choose it, to act on it in bulk or in batches of similar actions, then that info belongs in the UI and the API.
---
Also. Please make it possible to subscribe to a discussion comment, but unsubscribe from a discussion. I want to read replies to this comment, but don't care to get a notification on every reply to this entire discussion. Unsubscribing. Tag me if you want me to read a reply here.
Please someone at github, hear this. Discussions are useless for feedback as you cannot subscribe to just the single thread you posted, only the entire discussion. That means I have a a binary choice of drinking the firehose or ignoring all future comments on some feedback I care about.
Please fix this.
I'd say the narrative that AI agents are a looming danger to the world is probably undersold rather than overhyped. I'm not particularly a doomer on this, but I have an infosec background too, so have a fair idea of what the combination of agentic harnesses + a malicious mindset could do to people/companies/nations/politics/world if wielded incorrectly. I think the good guys will win on this, but there will be plenty of interesting things that happen in that journey.
A good thought process might be to think back to the various large internet worms of the 2000s (Code red, Nimda, SQL Slammer, ...) which were mostly monoculture 0-days (not technically but close enough). Now consider if you no longer have monoculture / single bug as the limitation plus an ability for the hosts to take part not just as attack surface, but also cognition and planning. There's lots of variants of this and they're not particularly far fetched scenarios.
It's likely that OpenAI has gotten as good as it is because it ignored the traditional sysadmin stuff and went scrappy.
I worked there, but this is just my opinion and guesses, not facts.
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."
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.