I think the assumption here that might not hold is simply that increases in efficiency and smaller size will be achieved by linearly just training smaller models better.
You are absolutely right that there is a physical limit about these things, but very often I find that the solution is a clever way to work around the problem. Maybe the problem with knowledge of the models will be improved by them looking the information up in a better way - so smaller models will not have to have the knowledge trained in but will default to checking. Maybe Models will, I dunno, focus on training in assembler and start to only ever check the compiled output so they only ever need to learn assembler and will then compile the solution to reason about the assembler code.
Obviously that last part is a ridiculous example because I'm not gonna be able to come up with a solution myself - I'm not nearly smart enough for that. But I h ope you get what I mean. Not going the direct route but instead finding solutions people didn't think of before.
One of the big problems is that no one actually does read these scripts. You could say "Oh but it's their own fault, duh" but theres a very legitimate argument to be made users going the path of least resistance and that you shouldn't offload this responsibility on your users.
Regarding appImage or rpm, attackers need to build and package these to inject these, while this curl | bash pipe opens up the possiblity of payloads simply by taking over the domain. And this isn't really that far fetched, just think about the Notepad++ update payload recently. The regular package was unaffected while the domain used for the update was taken over.
Then theres also the argument about normalization. Just like he said, this isn't just something he said, this is a very real argument. You don't want to teach users bad habits. Even if / you / inspect the code you get, not everyone will. And ultimately, we should strive to make the Internet a safer place, if only to get less botnets.
This is the same as terms of service agreements. There's a crowd mentality around it where only one person with enough of a voice needs to read it and scream. It's brittle because if everyone thinks that then nobody checks it but the probability scales with the attention it gets.
Totally agree we should make the internet safer, this is just a clarification that we don't necessarily need everyone to check it. One person who always checks everything and sends this to their LLM and posts a viral post can be a deterrent.
The installer is one threat. You're then running this on your machine which is the next threat.
Most of the agents.md and what people use it for / write into is does, in fact, not make a difference.
Now, sure, this study is a bit old for LLM standards - as everything beyond the current month is - but
a) I haven't seen any tangible evidence to the contrary and
b) Since the basic inner workings of LLMs haven't changed I'd be sceptical of this not still applying.
I think one major side effect of LLMs moving so fast is that best practices and how to use this tool is very much not catching up as fast.
No one knows what is best and what actually makes a difference, doubly so because LLMs are / very / hard to quantify - even benchmarks themselves are very rough estimations.
People do, in fact, use stuff which makes no difference all the times.
That's not what the study says. from the abstract:
> We conclude that while context files are useful for specifying non-standard coding practices, any attempts to improve performance should be rigorously evaluated before deployment.
The purpose of AGENTS.md is not to improve "coding performance" as the study looked at, it's to give an agent practical instructions that are useful to your specific workflow. For example you want it to use a certain format or specific tools for your project. This is stuff that can't be learned during training and must be loaded into the agent's context at the project level.
Yes, but since we are specifically talking about claude.md, Anthropic themselves claim on their website these files "serve[s] multiple purposes: providing architectural context, ..." (https://claude.com/blog/using-claude-md-files)
They also recommend starting with an /init command, which is also something the study very specifically called out as "having a marginal negative effect"
And from personal experience, I can only confirm that many people seem to see this as the main purpose of agents/claude md files - a persistent architectural overview of your project.
Quick Edit: My point simply being that I think it's understandable if some people don't understand the big deal about these files because they've had a drastically different experience than other people - anthropic themselves recommend apparently totally ineffective practices on their website, and the starter tool present in many harnesses seems to even have a (marginal) negative effect.
Since it seems like this not only improved sizes but also performance I can't wait for some benchmarks and comparisons. If you don't have a separate GPU for inference, every single GB matters so a comparison between specific Q4 Quants is really interesting to me.
Currently I very much can't decide between going for a bit of a lower Q4 Quant to squeeze out a bit of buffer and ctx or wondering if a slightly higher (IQ4_XS vs Q4_K_M/XL) is worth it
This has been frustrating me for a while and is part of why I explore other coding agents.
As many advantages as pi has in some areas, there are definitely areas where I believe the hype to be a bit overstated. While the config folder is, ultimately, not relevant for performance, how this was and is continued to handled is a bit frustrating for me.
They have made it abundantly clear it's not going to change however so I'm looking at how other coding agents perform currently.
In practice this requires duplicating the upstream build and release pipelines, so now you need yet another agent running in the background (+ periodically going off the rails + eating tokens) which incurs more up front cost and cognitive overhead.
In my experience "throw another agent at it/fork it" consistently creates unsupervised trainwrecks.
Fully agree with this. I did that for pi for a while, maintained it and brought merges from upstream while having my own patches on top but then went on holidays and there was that refactor where the agent pipeline failed... now I'm stuck on the version from april/may (works great but I can't use extensions; and I'm too lazy to debug/fix while everything works great).
off: I'm working on my spare time on a code mode lisp alternative (great opportunity to learn lisp) and might switch to it fully as long as I built some simple evals (I'm concerned about token usage, which is why i forked pi the first time)
Sure but I'm really not that invested in one single harness. I tried out pi because people were recommending it so much. It turns out I personally have some things which annoy me, so I try out others now as well.
If I don't find anything which fits me I might fork it, but even that little effort is not really worth it if theres something which fits me better.
I already found maki which...seems to do the exact same job pi did for me, and I wanna check out crush as well.
What's even more frustrating is that there's a very simple and elegant solution suggested in the thread, to simply check for an existing folder and use the proper convention if not found.
Oh sorry - basically just a github ticket to an explanation about the .config folder. Pi doesn't respect XDG_BASE_DIR specification, and even if you use the env var it combines cache and config.
The ticket is closed and this will not be changed, period.
From what I understood in the ticket ( I haven't confirmed independently) it's the later. You can set an environment variable to move the .pi directory ( into your XDG Config dir) but it's both the cache and config combined.
Am I wrong or are these evaluations, while interesting, not really meaningful for anyone doing serious development work?
I'm asking because I personally only use AI with specific and detailed instructions, building my projects piece-by-piece.
I mostly don't look at the low level code and some of it I don't understand as much as I'd like, but I very much give much more technical instructions than a simple, two sentence prompt.
So, it seems to me this "oneshot from a simple prompt" eval is fairly meaningless when it comes to model evaluation itself, as it is in no way representative of real world application.
This would be more something for "vibe coders", people with little to no programming background wanting a website?
I checked out the development benchmarks for agents, and was suprized to find that they're not really representative of many of my own day-to-day development workflows.
It appears that they're mostly testing the ability to make business tasks autonomous, with ~20% associated to development tasks (ssh here, install this, etc.), but not actual programming.
Seriously, I can't stand these tests of 1000 input tokens generating 1 million output tokens. You can't really convey anything interesting in 100 words, so like almost who cares what it produces? No one is providing value if the extent of their contribution is so small.
Much more interesting is providing a million tokens of meaningful input and getting 1000 tokens out (high level critique of a detailed design doc, finding a subtle bug in a big codebase, etc).
I think both can be interesting, but surely the 100 words will lead to a lot of variability in the exact shape of the result because so much of the spec will be left up to the LLM. However, it is still interesting to judge the quality of the result and how self-consistent it is. Not by looking at the actual webpage, but by looking at the code and whether it is nicely organized, makes proper use of abstractions, and in general doesn't feel like spaghetti.
Great - can you show us some examples of these? Every time this topic comes up here it’s full of people saying “you’re using it wrong” and apparently it should just be intuitive. Yet all the material is like this.
As someone who's done web development for 20+ years, I find the model personalities pretty dang fascinating, especially how they develop (and evolve) design sensibilities.
I'm interested to know how the classic AI "purple preference" emerged (organically?) and if the beige wave came out of specific training efforts to combat it?
To your point on development work (the code itself), I was talking to some friends on the Google Chrome team about any research understanding the model's preferences around framework ergonomics and abilities to properly implement core web standards for given tasks. I think that would be super fascinating.
Beige+Orange 100% came from Anthropic intentionally training this, it's their own theme. I don't remember what their first release was that defaulted to this - it may have been Sonnet/Opus 4. Before that, not one other model used it, nor was it a particular popular theme. For light themes, white and off-white had been ultra-dominant. Anthropic themselves were the outlier with beige, which is also why the change to beige stood out so much.
I'm repeatedly noticing that people working at big ai and tech companies are surprisingly not that... good... at using ai? It's like theyre doing a plausible thing to get something done and calling it a day
1. Long form task based examinations like this that test the ability of the model+harness to remain on task, tool calling, overall effectiveness and taste.
2. More direct 1:1 and qualitative comparisons that you might get with a tool like https://evvl.ai/ - which also uses OpenRouter and does similar one off model comparisons (or lets you use it as a MCP from your dev env to be like: "take the prompt from this loop and try it against these other models")
I've been using code review as my benchmark. Launched a massive parallel Fable/max code review on my lone lisp codebase and recorded all the results and transcripts. Switched to OpenAI and am now running the exact same code review with Sol/max.
It's still a work in progress but preliminary results reveal that Sol is able to reproduce 70%-90% of Fable's performance. This is a very meaningful result for me because code review is what I use AI for.
> Am I wrong or are these evaluations, while interesting, not really meaningful for anyone doing serious development work?
As a non-designer trying to build something solo, I think value's in the higher-tier models being able to brainstorm and infer a variety of design directions, as well as dissect the "this looks off" comments that would frustrate human designers.
Some of the frontend design skills try to bridge the gap, but the better models perform far better as is, and often better without one of those frontend design skills trying to ram their own workflows in.
Yes, I would be very interested to see follow up prompts that adjusted visual elements as if feedback from the client, then some prompts to change the menu and pricing. Id like to see how well the AI's can maintain their own work.
I've been super impressed with one shot AI images and designs in the past, but have never been able to adjust a design without things going off the rails.
I'm in a similar situation is you are, having ADHD, and my observations have been similar. I've been more hestiant to use AI at all for a while at the beginning but even now I only ever use it for one thing at a time. It helps me tremendously with the things I want to have done but not do - find out who clutters my home directory, build a small DMS plugin for local models, stuff like that. But even if I work on a bigger task and idea, it's mostly one thing I use it for at a time.
Maybe you're right in the fact that the coping mechanism help with that. Maybe using LLMs is similar in that it is easy to lose focus for neurotypicals so having lived with that we know how to handle it. Or maybe it's just us, who knows.
I don’t know, there may be something to this. I shared this post with another ADHD friend of mine and he also resonated with your and my experience, not the OP’s.
Now I want to do a study!
I wonder if the extremely fast dopamine hits of LLM use trigger the same sort of dopaminergic response that ADHD does when faced with a stimulus? If so, are we simply better at dealing with those swings, since we’ve literally dealt with them our entire lives?
I’m also interested in a study as I also have ADHD and this is also my work loop. I tend to cut up and serialise rather than parallelise. I can not deal with the degree of context switching described in this blog post. I’d have felt frayed within two weeks.
My complete guess is there's a level of bravado or over-confidence about it.
It's obviously massively generalising, but I'd say someone without ADHD is more likely to feel like the number of tasks they can do at once is only limited by pesky things like physics and time, and LLMs "solve" this by allowing them to do more at once.
A bit like when a good manager takes on more and more reports and their ability to manage the larger team goes completely to shit, but without the useful feedback loop of the grumpy, mismanaged team.
It's also relying on the assumption that the checking LLM only ever corrects wrong statements and never incorrectly "corrects" an already correct statement, which might not always be the case as well.
You are absolutely right that there is a physical limit about these things, but very often I find that the solution is a clever way to work around the problem. Maybe the problem with knowledge of the models will be improved by them looking the information up in a better way - so smaller models will not have to have the knowledge trained in but will default to checking. Maybe Models will, I dunno, focus on training in assembler and start to only ever check the compiled output so they only ever need to learn assembler and will then compile the solution to reason about the assembler code.
Obviously that last part is a ridiculous example because I'm not gonna be able to come up with a solution myself - I'm not nearly smart enough for that. But I h ope you get what I mean. Not going the direct route but instead finding solutions people didn't think of before.
reply