Whats the model total param size and will you release the weights?
What does harness integration look like? Do you have an harness? Is it good at coding? What about tool calls? Do we have to wait a fixed amount of time for every step it takes?
If you have dyslexia and I know it, that brings it down to 20% of people. Combined with some other data, this is a pretty good factor to narrow it down to "who you are", right?
i let 4 different agents review the same dirty code base (200+ files changed, c++, game engine):
- deepseek v4.1 flash via deepseek API: took 20m to find one p1 issue that was relevant and a p2 issue that was irrelevant
- glm 5.3 flash NVFP4 via TP2 DGX Sparks: took 1h 5m to find a p3 documentation issue
- gpt 5.6 sol: took 5m30s for one p1 and one p2 issue. both relevant
- gpt 6.1 sol: took 4m30s for two p1 and one p2 issue. both relevant.
Worth to mention: none of those findings overlapped.
I let deepseek v4.1 flash and gpt 6.1 sol both plan fixes for the summary of the findings. in this particular scenario: gpt 6.1 sol planned to increase a buffer size from 128 to 256 to fit the 191 elements that blew past a test scenario. it included some headroom. deepseek v4.1 flash on the other hand decided to make it exactly 191 to satisfy the test, for example.
The TPS decode on deepseek is impressive. I never had a second / feeling of being left aone and though "damn this thing is working". Despite all my efforts, it took ~4x longer in a review, found less and planned worse than GPT 6.1 Sol. Wall clock time. I don't have token counts for comparison. If I were to grade those models from 1-10 (10 = top tier GG), I'd give deepseek a solid 6.5 and 6.1 sol a 7.5-8.0 maybe.
LLMs are non-deterministic, you could run the same prompt on the same code base with the same models, and have different result. I don't think only one run with each model is enough to draw conclusions.
New model comes out and someone says, "it can (or can't) draw ducks on bikes" or some esoteric thing. But it's not enough statistical power to claim anything other than a personal anecdote.
I got a flat tire in downtown today. Therefore, driving in downtown causes flat tires.
Honest question about the non-deterministic nature of llms. Every programming language provides some way to control the random seed. Is this not true in GPU programming land?
Yes, but for one thing, floating-point math is non-associative so even if you use the exact same random seed, you can get different results on different implementation kernels.
For another, the dependence on a random seed is just one example of how you can get different behavior. You could just as well get different results due to e.g. a tiny difference in prompt wording or punctuation or whitespace.
If a model passes some test on 70% of random seeds, and fails on the other 30%, then knowing the rough probability of success is much more useful than knowing one random sample of the outcome.
And empirically this kind of probabilistic success is quite common, because many LLM benchmarks report "pass@k" success rates that are much higher than the "pass@1" success rate on a single attempt.
I don’t understand what “floating-point math is non-associative” has to do with the random selection of possible result token set after the soft max operation. The weights of the model are set and don’t change during the many matrix operations(which is deterministic regardless of the floating point encoding scheme).
The reason GPUs are used for NN computation is that they are massively parallel. You have hundreds or thousands of cores that perform the same operation on different parts of the network.
Tiny variations in the computational environment, such as slightly different set of processes running on the system as well as tiny differences in core temperature or voltage - among many other factors, can cause computations to complete in non deterministic order relative to each other.
This meaning one run eventually calculates a+b+c, whereas another does a+c+b, yielding slightly different results. Those cascade down the chain, resulting, finally, in a different set of produced logits.
Notably, similar effects can and do affect pure CPU calculations on multi core machines, and as a matter of fact even on a single core depending on the architecture when considering eg pipelining, branch prediction etc.
Thus, real world matrix operations are not, in fact, deterministic.
Now, one could argue that all of these are negligible, but that is an empirical claim dependent on the problem at hand.
It depends on the execution order. Model computations can be scheduled differently depending on what else is going on. You need extra effort to guarantee the same order of execution. For example if addition saturates at 8, then 4+5-2 is non-associative.
It doesn't really matter for most purposes. Determinism doesn't make them any less chaotic, it's not like fixing the seed makes the output any more predictable. Some percentage of seeds will behave in ways you don't like for a particular input, and you can't know which beforehand.
On some models you can control the temperature so it responds the same every time to a specific prompt but the “randomness” of llms is usually a feature not a bug.
That may be the case, but simply running the same code review twice with the same model may give very different results as well. Impossible to know with the information we have.
yeah, there is definitely still a lot of vibes to all this still, I'm working on evals next to learn and leverage, to reduce the vibes component to the claims
today we can use some anecdata based on our observations, this also helps shape the dimensions we want to eval the agents-tasks on
In your case, is it a public repository that the llms might have found the issues for online?
I too am thinking about creating some benchmarks that I can understand myself. The LLM 'cheating' by finding known issues through some sort of history or online source is a path you want to protect against. Then again, you DO want them to be able to look online for people having similar issues.
I meant things like bugs. So lets say some open source project has a bug that is later found, you could theoretically use that in a benchmark for an LLM to see if it can find it.
quick reminder: this is a one shot pydantic token guess. if you try to use a model that was trained on reasoning? you're not getting any of the reasoning.
I dont think Determinate Systems was involved, despite their proximity to the Netherlands (Eelco being Dutch). They work with American arms manufacturers, so I suspect that may play a role.
reply