twotwotwo

People often talk about how fast old software is, but one of the things that stands out about GeoWorks for me is how small it was while doing a lot.

Of course, lots of things that make modern software bigger are things we very much don't want to do without--full Unicode support, accessibility, clever rendering, improvements to quality of life. But our 'foundations' are also built higher; the Web platform and a bunch of native toolkits provide a lot out of the box. (The platform doesn't include all the widgets that are now quasi-standard, of course, so we build a lot on top anyway.)

There are also a ton of useful third-party libraries you can call on without getting too bloated, and there's a lot that would have been bloated then but not now: in the 90s you probably wouldn't embed an SQL DB you didn't really need, but SQLite is a pretty safe dependency now.

Nothing in particular I'm really driving towards here but I think "how do I keep the code to functionality ratio good" can still be an interesting angle from which to look at high-level design decisions even as a lot of the circumstances and numbers have changed over decades.

Fred Wrixon's Codes and Ciphers was fun for me and a friend around this age, and it looks like it's been updated in the decades since.

One angle from which it's fun is just learning operations you can do on text (and text represented as numbers). Empirically it turns out just Shannon's "diffusion and confusion" and lots of rounds gets you far in symmetric cryptography, which we can see from a lot of simple RAX primitives working fine. But it's nice for reasons outside cryptography to get a feel for the zoo of other things you can do, what offers diffusion and nonlinearity, how you can ensure a function's reversible, etc.

If you did one topic from public-key land, I think Diffie-Hellman is easier to understand than RSA without much build-up: it makes sense from the basic properties of exponents (ones modular arithmetic doesn't change), and modular arithmetic connects to fun stuff about the primes. Merkle hash signatures also make sense with just symmetric cryptography, and are post-quantum-resistant!

I hadn't really thought about how you'd even approach PQ encryption, but maybe ECC-based McEliece is cool? You can get a feel for it even without detail on the hard decoding problem, and error correcting codes are their own interesting topic.

We weren't signed up but as a measure of the scale of this we still wound up with a couple of Imagination Library books through book exchanges or buying used online -- i.e. there are enough of these 300M books floating around that if you have a kid there's a good chance you run into them.

I like the sibling comment "We should be more ambitious with the people we build." -- there are so many great things people with some means can be doing!

Folks really want to decide if this is pro or anti and respond to that. It's neither.

In a world with only LLMs doing the day-to-day of proving, you still want more than just proofs dumped out as soon as they pass adversarial review or formalization. The first proof code that passes checks may be a mess that's hard to build on; the path to a result, including failures, is full of interesting stuff; naming, generalizing, linking, and organizing things are tasks that move us from today's raw material to tomorrow's future directions.

Folks get this about code: "it works" isn't the same as "it's good." We knew it before LLMs, out of practical necessity as projects became hard to build on.

An odd thing to me is it would not be that big a concession for the labs to openly talk about the difference between the math artifacts they're releasing and what mathematicians do. It's analogous to the Claude's C Compiler post noting it wouldn't replace a prod C compiler. They could talk about paths from a rough initial product to 'production' math, say they hope future models will continue to improve as math collaborators and expositors, and so on.

For the compiler, the gaps would be trivially obvious to their customers, so it was an obvious call to acknowledg them. With their math output, the difference between a proof dump and the kind of well-written, contextualized mathematical program the community pursues is apparently subtle and deep enough the companies can't get themselves to acknowledge there is any difference. So the companies self congratulate and then are yelled at on the Internet instead.

(Ant seems to have wised up a tiny bit about this compared to OAI, and e.g. Ant handed a recent result to some experts in complexity theory to understand and refine and publish rather than just dumping a Claude-written PDF.)

And yes the drug discovery piece was weird. There are good relevant points: it'd be good to understand pharmaceuticals better (helps us find others, understand side effects, etc.); when we get a mystery result, it's worth effort to try to work our way to proper understanding; anything that could help us understand (reasoning etc.) shouldn't be hidden. But as presented it's both not a lot like math and accidentally a lot like those "would you choose..." questions that always get so much engagement on social media.

Yep, it's unfortunate how often folks sort something into pro or anti then reach into their bag of anti or pro arguments without relatively little attention to the specific thing they're talking about.

As a sibling of your comment points out, "opposition to AI's convenience" is not Tao's position. He has used LLMs to help with the problems he's talking about -- https://terrytao.wordpress.com/2026/07/21/a-digestion-of-the... and https://terrytao.wordpress.com/2026/08/12/a-digestion-of-the... turn opaque straight-from-the-model results into things that can be understood.

The Sendov example has a piece coders will hopefully recognize: he found a formalization that was 1/6 the amount of code of the original one. And the analogy with code goes further--the messy version will run/pass the proof checker, but the one that's been cleaned up and made sense of is a better foundation for future work. That's true even for future LLM-assisted work.

So it's not about whether mathematicians take advantage of LLM help (Tao favors that) but, more or less, whether the point of math is just to make a bigger version of the GitHub dump vs. everything else: readability/comprehensibility, negative results that fill in the map around a problem (not just 'lighthouse' theorems), organizing results to plan out future work, and so on.

I am always uncertain about impressions, but mine agree with this. I liked Luna 5.6 on Amazon Bedrock (which got >100 tps) for doing well-specced tasks fast. 6 seems to both be served slower by Bedrock and may spend more turns/tokens to get to the same place, so...not as fun.

And, of course, GPT-6 came out as Anthropic fixed a bunch of stuff with their models -- faster (via fewer tokens, and TPS for Sonnet), easier to work with, better results, cheaper (via pricing and, again, fewer tokens). I don't know if the timing and the suddenness of the improvement on Anthropic's side sharpened the vibes comparison this round, but Internet opinion went pretty clearly to Anthropic.

FrontierCode's results make it look like Sol-6.1 may slot in well where you'd use Sonnet or Opus's low effort.

One thing I don't think any of this reflects is that many well-specified coding tasks, including the self-testing and doing research and tracing out dependencies and so on, aren't really bleeding-edge now: Luna-5.6 and small open models handle them fine. Stuff like "why is this box dropping connections?" or "here's a thing I want you to model/figure out" can benefit from bigger models. But far from everything does!

The Jacobian one is great, and fits here -- 1) the counterexample came out as a tweet of a single expression which seems exceptionally hard to turn into something sensible, which crystallizes the lab's approach; 2) it links (like the Sendov post) to a chat transcript showing a little of what was involved in untangling it (though of course all that went into asking the right questions is invisible!).

For other folks, the post: https://terrytao.wordpress.com/2026/07/21/a-digestion-of-the...

The transcript: https://chatgpt.com/share/6a5fdc7a-d6f8-83e8-bbea-8deb42cfed...

This is worsened by OAI/Ant's strategy of grabbing the glory and running rather than spending effort trying to to advance understanding of math. Tao, who is quite sophisticated in use of AI, has said a lot about this, including in meme form: https://mathstodon.xyz/@tao/117068266026618494

The AI labs' approach to math is immature in a way they can't get away with in coding. In coding, they realize that a pile of code that technically works is not enough: they need the code output to be a foundation to build on, and they need their agents to work well with humans which means explaining things in a way that makes sense.

In math, their goal seems just to be to exploit mathematics' reputation as full of hard problems with a general population that can't tell a pile of Lean from a good proof. OpenAI pretty much said this work is just to show off at the end of the post. Anthropic said their FLT formalization is a research artifact they do not intend to clean up or improve in any way.

Besides uniting mathematicians in irritation at the labs, the other flaw with this strategy is that it ignores that organizing knowledge is part of intelligence, much like not just producing a mess that runs is part of programming. You can write a proof that uses algebraic geometry because someone organized what could have been a bunch of disparate ideas (or fragments of a Lean repo no one will read) into a toolbox where an expert can find the tool they need.

I hope they change tack. Perhaps instead of making an explicit strategy of taking the credit from mathematicians but doing little for actual understanding, they could let some math departments at their swarms or best models, ask for a bit of acknowledgement, and hopefully they approach it by trying to write good papers, simplify, etc. rather than just rushing for headlines. (Tao's post about digesting an LLM-generated proof https://terrytao.wordpress.com/2026/08/12/a-digestion-of-the... is an interesting read for a sense of what he means by 'digestion'.)

On that last note, it's also important (Tao's also noted) for the mathematical community to properly value digestion and organization of results, so that given the incentives of mathematics and availability of new tools you end up with good papers and textbooks and so on, not just mathematicians taking the labs' current role of pushing incomprehensible-even-to-specialists proof code to repos.

Making things understandable is part of intelligence as much as producing the initial artifact is. Even if the proof checks out in Lean (or the code runs and passes QA) if it's a mess, it will be hard to use it to do anything further.

This does not only matter doing cutting-edge mathematics. This, about the 'digested' version versus the original, should feel familiar to some folks here:

> This formalization is more streamlined than the original formalization (it has about 15,000 lines of code, compared with around 90,000 for the original proof).

and if you've ever tried to turn an overly vibed piece of code into something that makes sense:

> it has taken me several days (with heavy AI assistance) to perform such a digestion, to place the proof in proper context with previous literature and to simplify and streamline the argument to highlight the main ideas

If you see something that is confusing or overly clever, please don't assume it must be for some good reason you don't understand and move on--ask questions, get it simplified, try to get it worked out. Future you will appreciate it.

About the argument that a beam's strength:weight ratio worsens as it grows: do the artificial structures humans use, like house frames or bridges' trusses, recover strength:weight ratio? Would a theoretical giant with a skeletal structure like a bridge or a house's frame be better off than one with a human-like skeleton of the same material? (And, related to another comment here, guessing the actual structure of bone produces some improvement relative to something solid?)

Hard to make big predictions, but it sure looks like at least this level of capability is going to be available in the open and relatively cheap to run.

The 'floor' has gone up: today's model a bit behind SOTA is like model releases that were blowing people's minds a few months ago. Compared to, say, DS R1, this is far out stuff.

This, Luna, and (if it's good in practice) Laguna S are also fast and light not just cheap. And, as happened before, DeepSeek's first but other open model makers likely follow.

And a small, fast model taking small steps is...fun? More like working with code.

One read is 1) they're getting a lot of traffic for Flash, 2) they've said they're updating Pro soon and expect that to lead to a traffic spike for Pro, but 3) that would leave them overloaded, so 4) they're going to raise prices to avoid it.

It's interesting that most open models adding 1M context did it in a way that reduces KV cache size (though DeepSeek was the most aggressive, using compressed attention on all layers), but only a couple providers turned it into a discount on cache reads.

The field of mathematics is smart about this and knows the difference between a pile of Lean code and understanding, and mathematicians try to get from the unintuitive explanations to something that makes more sense, e.g. https://terrytao.wordpress.com/2026/07/21/a-digestion-of-the... (where incidentally Tao used a chatbot to help take apart the problem, but with a lot of interaction and work from his side).

Making things understandable is mathematics, and more generally a kind of intelligence, and is crucial to continued progress. You couldn't use algebraic geometry to disprove a conjecture if people hadn't organized (what could have been just) a pile of random observations into something called algebraic geometry.

Historically LLMs have done best where it's possible to train using an objectively verifiable reward function. Computer programs are pretty good on this front and so are Lean proofs. (Of course, they don't only do things you can RLVR heavily, but those have progressed fastest.) Not sure where 'making mathematical knowledge more understandable' falls on that spectrum.

Understandability isn't only important for advanced math. Keeping computer programs from becoming a mess is a challenge in high-level organization too, and the chat with the user is an explanation task. If you look online at what people say about large LLM-built codebases (SlopCodeBench is a neat effort to make make it concrete, but common wisdom seems to mostly agree on the general problem) and chatbot prose, I don't think everyone considers those solved problems!

It's hard to tell how thoroughly the labs grasp and care about this at an organization-wide level. I'm sure at least some maybe-results exist inside labs but haven't been published because the humans couldn't verify them and didn't want to be embarrassed with a false result. (Maybe also why counterexamples are a lot of the first results published: often simple to verify, even if hard to obtain.) A good sign would be if results in a few months come out more like what mathematicians consider well-written papers explaining results in a more intuitive way, fewer shocking announcements of bare counterexamples in tweets. It's probably a slow climb to get there.

Singer-songwriter Silvana Estrada named an album released last year Vendrán Suaves Lluvias (meaning There Will Come Soft Rains). She talked about how she and her brother read The Martian Chronicles as kids and she remembered the Sara Teasdale poem quoted at the end. She said she composed the songs at a difficult time in her life and, I guess, something about that image in the story (and the poem in it) resonated then.

For anyone curious, there's a Tiny Desk Concert of songs from the album at https://www.youtube.com/watch?v=o9PoZ0Vcb_s and an interview, in English, at https://www.youtube.com/watch?v=WcQbB7Dc83U

(Shared this on another post of the story last night, figured I might as well here, too.)

Okay, a stretch for HN, but: singer-songwriter Silvana Estrada named an album released last year Vendrán Suaves Lluvias (meaning There Will Come Soft Rains). She talked about how she and her brother read The Martian Chronicles as kids and she remembered the Sara Teasdale poem quoted at the end. She said she composed the songs at a difficult time in her life and, I guess, something about that image in the story (and the poem in it) resonated then.

For anyone curious, there's a Tiny Desk Concert of songs from the album at https://www.youtube.com/watch?v=o9PoZ0Vcb_s and an interview, in English, at https://www.youtube.com/watch?v=WcQbB7Dc83U

I think this rates as too obvious to say among anyone remotely close to this, but worth noting there is a lot of distance between an exploit and any real confusion.

Proofs aren't generally machine-read-only. An exploit of a proof system kernel doesn't necessarily look like normal proof code. Exploits can be fragile: 'safe' tweaks break them. If an exploit used maliciously is found, the person sneaking it through wouldn't exactly be thanked for it. And the window for exploits overall seems to be shrinking: Lean/nanoda are easier to secure than, say, Chrome.

If someone wanted to deliberately sow confusion (my career advice is not to do that!) they would probably have better luck with a subtly wrong formalization or an informal proof. If they have prover kernel bugs, they should report them and get free T-shirts.

Still, it's cool to see how they're hardening Lean.

This thread has some context. A proof-system researcher found some proof-system bugs and presented them a funny way:

https://leanprover.zulipchat.com/#narrow/channel/270676-lean...

A mathematically-inclined reviewer (or an LLM) can quickly identify that it's an exploit. (Two exploits; it's crafted to hit a bug in another proof checker, too.)

The post gestures at this, but a natural follow-up, beyond fixing specific bugs around this exploit, would be to task some security-oriented models with proving False in Lean, or with reviewing the code for potentially unsound steps, missing checks, or even useful 'hardening'. That's happening and bugfixes are landing as a result.

There is a blog post waiting to be written (that I won't write) about the size/effort tradeoffs, and particularly how small models get some surprisingly good results with lots of turns and reasoning.

DeepSWE will let you chart turns taken or tokens used, and FrontierCode will chart tokens. If you use that, you can see Sol high and Terra max get about the same DeepSWE number, but Terra max takes twice the turns. Luna max scores a smidgen lower with even more turns.

Smaller models relying on lots reasoning may "scale down" better on easier tasks, because unlike size, reasoning effort is dynamic: the model can see the task looks easy and stop. On DeepSWE, the cost curves for the three 5.6 models are almost on top of each other, but on FrontierCode Extended, the version of FrontierCode with the most everyday tasks in the mix, there's a spread of costs at the ~55% level.

The recent Laguna S 2.1 model (118B, 8B active) puts up surprising coding numbers for its size, and the lab behind it specifically credits its "way of working (persistence, verification, willingness to backtrack)". Some other open models that folks report getting good mileage out of seem to get there partly by throwing a lot of reasoning at the problem.

There is a little bit of a question, if some models rely on getting it wrong a bit more at first and external checks catching the problems, of whether they're also more frequently getting things wrong they can't self-verify (say, quality of UI or API design) and then it falls to the human to find it. Still, getting the results they're getting at all is neat.

Some benchmarks historically favored reporting only on the max variants, maybe because they want to show the frontier? but that is not always what you need for practical decision. (AA has the full effort sweep for Opus 5 and Sol/Luna/Terra at least.) And at least FrontierCode finds Opus 5 taking a hit in performance above 'medium'.

I am not trying to pick a winner here. I'm probably not going to use tiny models on max for everything, but I think it's cool that you can get so much more out of a small model by amping up reasoning, tool use, and persistence.

This is great--LLMs 'forgetting who they are' is one of the most uncanny things they do, and the note about why static benchmarks underperform human attackers is on point.

One sort of wild idea: 'give words a color'. That is, the harness/API adds a signal to the input vector (using a few 'role' dimensions or just adding some other vector to the embedding vector) to tell the model the role of an individual input token. It'd be kind of like how positional info is added. It might make some things a little weird--its output will be 'snapped' to the "tool call" or "assistant output" color when it's read back in, for example, regardless of what 'color' came out of the network. A lot of weird stuff happens in models already, though, and this may be less weird than trying to make them behave as formal grammar parsers reliably with security at stake.

A while back I'd dreamed about this as a way to keep models from confusing different kinds of training data: not all input can be high-quality sources, but knowing that a phrase was seen in a scientific paper/encyclopedia, an opinion piece, a work of fiction, a conversation, etc. reduces the chance of confusion. I know they can pick that kind of thing up from other signals like writing style or context, but exactly those signals that lead them astray in prompt injection, and sometimes even leads humans astray when something's written like a credible source but isn't!

Years ago work was bit by the analogous thing in MySQL. Like it usually does, it took a chain of events:

- We wrote a cronjob to periodically DELETE for a retention policy on a table we'd just created. Most senior person on the team reviewed it, looked fine.

- Unusually for us, we prioritize QA'ing a different feature for release, delaying the release of this cronjob and a bunch of other code.

- During that delay, the new table accumulated many times more rows to be deleted than we'd expected during review.

- Release happens. All looks well since the initial delete wasn't a migration and cronjob hasn't run yet; engineer doing the release signs off.

- Cronjob runs, deleting hundreds of millions of rows quickly.

- Next day, replica lag's high and MySQL's transaction history is very high. MySQL keeps transaction history around until purge threads have visited all the affected pages on disk.

- The bad cluster conditions last for days and lead to other problems.

This omits detail and the 'noise' of everything else we were watching. But it gets across how the code and MySQL behaved.

Like most exciting events, it led to multiple changes to avoid a repeat. For retention policies, our new approach was one at the end of PlanetScale's post, to partition and drop old partitions. Transitioning to this from a huge unpartitioned table can be fun!

If a table is append-only and already huge, with lots of rows already past the retention threshold, you might only copy the rows to be kept to the new partitioned table: copy what you can, lock tables, do a last catch-up copy and swap tables. (Roughly the blog's 'performant one-off delete'.)

If the table's merely kind of big, gh-ost or such could allow you to ALTER without causing lag, locking, etc.

At a scale below that, you could run a slow incremental 'nibble' delete while watching server stats, and a step below that, plain ALTERs or DELETEs are fine.

Using partitioning has fun bits, too. In MySQL, the partition key has to be part of any unique index, understandably. But you have to keep that in mind when you're using INSERT..ON DUPLICATE KEY UPDATE and relying on uniqueness to trigger the update. Things stay interesting!

I hear Vitess shops like PlanetScale usually don't run multi-terabyte myqsld instances in the first place: even when physical nodes are big, they run many smaller mysqlds on them. That wouldn't make all this fully irrelevant--huge deletes would still sometimes be worse than copy-swap-drop--but it does seem real handy for taming issues that tend to worsen with mysqld size, like replication lag. All to say, little bit jelly of their setup over there!

To repeat, not a dig at FrontierCode, which is substantial progress in benchmarking. But I'd argue modeling the rest of process is tha(aaa)t valuable and becomes more so as coding capability progresses:

Async agents interact on a longer timescale, but they interact. Again, experienced SWEs, consulting agencies, etc. ask questions before and after implementation, accept notes, etc.; they vary at how good they are at it; and how well they do it is a big factor in the success and failure of projects.

LLM interaction ability isn't saturated or mature; asking for point edits mostly works, but e.g. when I try to get Opus to ask clarifying questions or surface tricky bits to focus review, it's not close to a human-level response -- it's both noisy and misses key stuff. (Handling uncertainty has been a weak point for LLMs since early on, which might not help.) Other aspects of good interaction are even harder, like digging into a potentially mistaken request, or proposing a good 80/20 tweak to the spec.

There's a different, shorter-term reason to model interaction: it better tells users the value to expect now. It turns out my employer doesn't love infinite Opus use. (Go figure.) Kimi and Sonnet do comparably on FrontierCode. Are they about the same to use, or is one flailing while the other one just needs a couple rounds of fixups? If I saw a benchmark that credibly approximated 'this model will save you this much time vs. that one' that would put it well above existing ones.

I do think a bunch of discussion, investment, etc. is based on the idea the industry will essentially be replaced with successful one-shotting with little interaction. The mistake there is to assume back-and-forth is inessential and only happens because the agents aren't that good at coding yet. For a long time lots back-and-forths were driven by the models' limitations at raw coding, which might've made that idea more appealing.

As the coding side gets better, drawing the rest of the owl becomes the hard part. The world is messy and so is one's software's boundary with it. (I'm not saying the tasks don't get longer, I'm saying interaction gets more important as they do.) My conviction here might partly because in my sort of work the requirements and big picture were always thornier than typing the code; I'm suspicious that as raw coding gets easier for everybody they will hit something analogous.

Anyway, again, what y'all are doing is progress. I do want to stick up for the idea that a lot of critical things aren't raw coding ability. (I'm not alone in that, I don't think!) I'm definitely not here to say someone's Doing It Wrong as they do it more correctly than I've seen it done--just asking "would the patch get accepted?" is a huge step.

I'm liking the effort to make new, no-longer-saturated benchmarks. I'll also be a bit suspicious if some model aces it -- matching OSS maintainers' taste more often is a plausible improvement in quality but if they nail it every time they've been memorizing.

Not saying FrontierCode should've done this, but benchmarking the interaction would be interesting. That is, if I get a diff with a blocking problem but writing a comment gets fixed, that's a lot different from if the model has hit a wall. Better, if there's a problem but the model flagged it in a short list of questions or worries to me before or after coding, it can get sorted without taking much of my time. Stick an LLM in the loop instructed to behave like a user or reviewer with some rubric-ish info that wasn't in the prompt. Then, look at how much the pretend user has to do to get to a quality result with a given model, if they can get to one at all.

You could say 'why worry about interaction? the goal is the model just gets it perfect' but I think that imagined end state just is not a thing: tasks will get bigger but there will still be interaction. Handling comments and asking good clarifying questions when needed are real capabilities. Human SWEs interact plenty and real engineering has a certain density of questions about requirements, taste, and other big vague things.

If you worry about sending your data off for inference, Fireworks is one of the companies serving open models with solid performance and compliance/zero data retention sorted out. OpenCode supports them and many others. Cursor uses them. They don't have the super-cheap cache reads deal that DeepSeek's own endpoint does, but are still well below Anthropic API rates. (Though crucially you're not paying API rates now!)

DeepSeek and Xiaomi's deals on cache reads go with their models' latest gens making caching cheaper (using less space for KVs). No open-model inference provider has decided to match the pricing. I'm sure that says something about how inference pricing works, but not completely sure what.

Agree with others that top open models aren't on the frontier, and I would expect differences doing big-picture planning or anywhere you're only giving broad brushstrokes and looking for a lot to be guessed. But they do seem fine at coding from a a concrete plan! No experience in huge codebases because I only use them outside work, but they seem good enough about gathering info before they dive in that I'd expect them to grep around as they need.

An annoying caveat: individual subscription plans, used heavily, are much cheaper than the API -- see https://she-llac.com/claude-limits -- which complicates any argument about cost. I still think open models are worth playing with. They're one of the things that let us treat this as a technology rather than just as the product offerings of one of a few companies.

We have a lot of synapses, but (agreeing with you) I don't find that sufficient to explain why humans (or animals!) do what we do. If you throw zillions of parameters at a problem with a weak architecture, you get really high-fidelity memorization, and we're not awesome at memorization compared to machines.

Humans can do an impressive amount of generalization from one error or surprise, and as is often rightly noted, don't need trillions of words to get going. And it all seems to happen some 'forward-only' way, without backpropagation -- we don't have AdamW or MuonClip helpfully nudging our synaptic connections towards whatever would have scored well on our most recent test. It is relevant that we're creatures with goals -- reinforcement learning is the only stage where there's a taste of that for neural nets -- but the learning differences seem at least partly independent of that.

I suppose it could turn out that, even if not sufficient, the large number of synapses is necessary to all this, like we're effectively buying a lot of lottery tickets that give us a shot at fishing interesting hypotheses out of the experiences flowing by. But I'm still awfully suspicious that we don't have the right mathematical model for learning messy ideas all worked out yet.

Whatever is the darker shade of blue in the bottom-right graph had a bump at the same time cost did. Perhaps that's output tokens (which include reasoning)?

The fielded systems require something that wasn't there in the original model of zero-knowledge proofs. That could be as little as a trusted-enough public source of randomness: the prover makes their initial commitments, plays the verification game with a verifier whose challenges are controlled by the next outputs of the public RNG, and as long as the other party trusts that the RNG and prover aren't in cahoots, that's enough. Doing a trusted setup process beforehand is another tool used by a bunch of deployed systems.

That doesn't mean anything's practically wrong with the fielded ZK proof systems, just that's how you reconcile the article's "no non-interactive proofs under these assumptions" with people out in the real world using non-interactive proofs.

This paper brings up another logical possibility, that there could be a non-interactive proof with no RNG or setup that doesn't meet the precise original definition of zero-knowledge proofs but is zero-knowledge practically speaking. I don't know whether we'll actually see better fielded ZK proof systems come out of this approach!

It is kinda neat how the density can trickle down. When an individual SSD can hold tens of TBs, recent-gen drives can do millions of random reads/s each, and one socket can handle lots of RAM and many cores, it doesn't take the fancier chassis with two sockets or lots of storage bays to handle pretty substantial data work.

On the other hand, current part prices are not neat; a commodity platform only helps so much if none of what you want put in it is affordable! And other factors like power and cooling can push you away from optimizing for density. I just like that along with the ludicrious becoming possible, merely great stuff becomes more feasible.

Kagi has it as an option in its Assistant thing, where there is naturally a lot of searching and summarizing results. I've liked its output there and in general when asked for prose that isn't in the list/Markdown-heavy "LLM style." It's hard to do a confident comparison, but it's seemed bold in arranging the output to flow well, even when that took surgery on the original doc(s). Sometimes the surgery's needed e.g. to connect related ideas the inputs treated as separate, or to ensure it really replies to the request instead of just dumping info that's somehow related to it.

You could model more of the process: the dev's work as well as the model's, and the cost of catching a bug later or deploying it live. Those tasks push me further towards smaller tasks in general. (And they make the Gas Town type stuff seem more baffling.)

- Smaller chunks make review much easier and more effective at finding bugs, as we've known since long before LLMs.

- Greater certainty provides a better development experience. I've heard people talk about how LLM development can be tiring. One way that happens, I think, is the win-or-lose drama of feeding in huge tasks with a substantial chance of failure. I think if you're succeeding 95% of the time instead of 70%, and the 5% are easier to deal with (smaller chunks to debug), it's a better experience.

- Everything is harder about real-world tasks because they aren't clean verifiable-reward benchmarks. Developers have context that models don't, so it's common that a problem traces to an detail not in the spec where the model guessed wrong. For real-world tasks "failures" are also sometimes "that UI is bad" or "that way of coding it is hard to maintain." And it's possible to have problems the dev simply doesn't notice. The benchmarks' fully computer-checkable outcomes are 'easy mode' compared to the real world.

- Fixing agents' mess becomes more work as task sizes increase. (Like the certainty thing, but about cost in hours than the experience.) Again, if the model has spat out 1000 lines and stumped itself debugging a failure, it'll take you some time to figure out: more time than debugging 250-line patch, and the larger patch is more likely to have bugs. And if an issue bug makes it out to peer review, you can add communication and context-switching cost (point out bug, fix, re-review) on top of that.

- Bugs that reach prod are really expensive. More of a problem when a prod bug can lose you customers vs., say, on most hobby things. Ord's post gestures at it: there are "cases where failure is much worse than not having tried at all." That magnifies how important it is the review be good, and how much of a problem bugs that sneak through are, which points towards doing smaller chunks.

How significant each factor is depends on details: how easy the task is to verify, how well-specified it is (and more generally how much it's in the models' wheelhouse, and how much in mine), how bad a bug would be (fun thing? internal tool? user facing? can lose data?).

I think the dynamics above apply across a range of model strengths, but that doesn't mean the changes from say Sonnet 3.7 to Opus 4.5 didn't mean anything; the machine getting better at getting the info it needs and checking itself still helps at shorter task lengths. Harness improvements can help, e.g. they could help keep models of the 'too much context, model got silly' zone (may be less severe than it once was, but I suspect will remain a thing), build better context, and clean up code as well as spitting results out.

Besides taking more of your time up front, involving yourself more also tends to drift towards you making more of the lower-level decisions about how the code will look, which I find double-edged. You have better broad context, and you know what you find maintainable. But the implementer, model or another person, is closer to the code, which helps it make some mid-to-low-level decisions well.

Plan modes and Spec-Kit type things can help with the balance of getting involved but letting the model do its thing. I've liked asking the LLM to ask a lot of questions and surface doubts. A colleague messed with Spec-Kit so it would pick one change on its fine-grained to-do list at a time, which is a neat hack I'd like to try sometime.