Run yourself *on normal hardware*? Yeah, there's a pretty big gulf between that and a frontier model.

It's not about the specific "BioPykrete" example, it's the technique that's interesting: using proteins to bridge dissimilar materials in composites. It's using them in a way that's sort of like how an emulsifier lets you bridge lipophilic and hydrophilic compounds

Think, say, plastic-ceramic or plastic-metal composites. We can do these today (say, Colorfabb Bronzefill 3d printing filament), but the addition of ceramic or metallic particles makes the material properties generally worse, not better. The plastic just does not bond well to the particles; you have to significantly limit the percentage of metal or ceramic in your mix, and it makes them much harder to work. But what if they *did* bound well? You could easily produce materials with significantly boosted strength, abrasion resistance, etc, but with the low-temperature workability of plastics (note: they'd probably have to be thermoset, not thermoplastic, or low-temperature thermoplastics; proteins have heat survivability limits)

And why stop at metals and ceramics? You could literally just use "dust", just ordinary mineral dusts (clays, silt, etc) as a bulk filler in plastics, yet instead of ending up with a weaker product than working with pure plastic, you'd end up with a stronger one.

Maybe you don't even need a plastic. Maybe you can do what they're doing and bridge cellulose to an inorganic material? Then you're *really* operating on waste. Ice has the advantage of a low melting point in this situation, letting you use that component as a fluid - but cellulose can be dissolved in a number of substances, so perhaps you mix a cellulose-protein slurry with metal or mineral powders and then vaporize/recover the solvent?

Or even forgetting "novel" products, what about conventional composites? If you can bridge high-tensile fibres (such as carbon fibre) better to the polymer matrix that they're in, then you can help eliminate one of the main failure mechanisms of said composites, as well as making the behavior far more predictable. Because like metals (and unlike ceramics), a protein-bridged compound shouldn't be brittle; breaking one bond shouldn't introduce a discontinuity (like a ceramic), it should just reconnect after breakage (like a metal). Such composites should have ductility.

I don't know how widely applicable this will be, but technology that helps bridge dissimilar compounds is nothing to scoff at. And today we have tools like AlphaFold to assist with the design

As for the caveats:

* The concept of coupling agents is also not new, we already use various coupling agents to bond plastic to metal particles in metal-plastic composites and the like - they're just not great at their jobs.

* The aforementioned temperature limits

* Potential production challenges (though industrial enzymes are as cheap as like $15-50/kg, so seems viable?)

* Other coupling agents may offer better advantages; it's not a static field.

I haven't looked up the history, but I would imagine that the "XL" is for the fact that it can handle images up to 1B x 1B pixels (1 exapixel).

Both lossy and lossless, and so much more.

It's this.

And on the compression side, there's a lot of really cool stuff that lets it happen. For example, it dynamically resizes the blocks from 2x2 to 256x256, and they don't even have to be square. It may apply DCT in one, AFAS in another, etc - whatever is most efficient. It uses edge preserving filters to keep the edges of features clean. It can draw in splines and clone regions from one part of an image to another. Where it has to throw away high frequency noise (film grain, noisy textures, etc), it statistically samples the properties of the noise and saves that, and then regenerates equivalent noise. In "busy" areas, like say tree bark or whatnot (where the human eye isn't good at discerning changes), it throws away more precision there, and instead allocates it to details located in fragile flat areas, such as skin and shadows, that the eye is attracted to. It works in default in XYB colour space, based on the actual interactions of the cones in the eye, so it can aggressively quantize things which the brain cannot detect. And in the choice between fast but not-great Huffman coding vs. better but slow and patent-encumbered arithmetic coding, they instead use rANS, which is nearly as fast as Huffman but as efficient as arithmetic coding, and faces no patent challenges. Which is also why you can take a legacy JPEG and rapidly losslessly reincode as JPEG-XL and get a file that's ~20% smaller - you're swapping Huffman for rANS.

(That's the lossy mode - there's also a dedicated lossless mode)

Though already CI/CD pipelines were choking on the unit tests. So they aren't *free*.

Had an LLM generated request that was pretty straightforward, and the LLM generated 272 unit tests for a very simple function. Can't really afford that.

Also, despite the 272 unit tests, when I tried to try it out in the way a human would, it immediately failed. All the mocking the AI generated never actually properly imitated the real world. However, the submitter was *quite* proud of having hundreds of unit tests, despite them being, in this scenario, utterly worthless.

Like always, more code != more valuable software behavior.

So you have the AI doing overtly silly things. Someone asked to adjust layout to fix a gap in a webpage. Eventually they submitted their pull request, hundreds and hundreds of lines of CSS. Often the exact same rule repeated 5 times, which I'm guessing is how many rounds the operator went with the system before the gap actually closed. The lines were *mostly* just '!important'ing already existing rules, which had no impact, but hey, worth a shot right? Ultimately I discarded the merge request and made the one-line css tweak that was actually relevant.

Then you have the AI doing... well arguably slightly silly things. Like protecting against an invalid value redundantly throughout a call stack. Arguably defensible, as maybe one day the deep function will be called from somewhere else and passing through the error might not present it with the most informative context.

Finally the AI doing... well things the human should have been doing. With the advent of a lot of code scanning, this is less likely, but things like calling functions in C and charging ahead without ever checking the status of the call. functions that, practically speaking, will likely never fail, however you really *should* be being more defensive about the possibility.

The 'human review as a bottleneck' isn't really the angle I would fixate on. Completely unfettered AI usage also stalls out in many situations. If the AI can't get there on its own trivially, then it's going to leave an almost-correct looking mess that isn't quite there but is very hard to get across the finish line. If the AI can get it, then it's probably not 'software being shipped', because while perhaps slightly better than a generic off-the-shelf existing procedure, probably not worth the trouble to 'ship' a solution that largely overlaps with a lot of generic stuff.

Everyone knows that pretty much by definition volumes are low, that's the whole definition of a shortage.

The vendors may still be happy, perhaps even happier if the sky high prices produce at least as much revenue at high margin.

Ahem

I'm with you, but realistically speaking, if the mindset is already there, the material was likely already at high risk of plausible nonsense, not as thought out as the reality, but something to satisfy a check box for someone else. And the hope for process improvement is frequently not there, as raising a "do we really need to do this" invites "you must not care about safety/security/whatever". In many scenarios *no one* wants to be potentially on the hook for approving a process optimization that ends up biting them because they didn't understand why those things were in the process. Even if it is patently obvious to all involved there's no point, or if there was it was already failing. Frequently process dictated by someone that has no *real* stakes in anything involved, but needs to be performative.

The GenAI approach is the way to pay lip service and skip the debate. And if something messes up? "Ooops, well you know how AI just does that sometimes". I've seen that *so many times* and people just laugh it off and keep slopping and no one is holding folks accountable for failing to audit the AI results adequately. So they get credit when the slop works, and they deflect blame when it doesn't.

Don't we all! Hard drives, RAM, *and* GPUs, I'm in the market for it all.

I also want to buy silver-tin alloy for casting, and hey, what do you know, silver and tin are also both at astronomical prices due to in no small part the AI boom.

At one point you have to just stop waiting. Prices could start falling tomorrow, but then again, that could have been said at any point for the past several years.

They don't have the revenue to survive much longer,

They were profitable in Q2. You can't extrapolate that endlessly, but they're not a cash incinerator anymore. And they have $15-20B on-hand pre-IPO. They're fine.

Anthropic is more or less breakeven *despite* being engaged in a massive 10x YoY scaleup for approaching 4 years running. Companies undergoing even "normal" scaleup rates are almost never profitable, let alone 10x/yr. Any slowdown in scaleup, or any shift in market pressures from intense jockeying for position to starting to pay back investors, and this drives them into deep profitability

The threat to Anthropic has nothing to do with whether its current business is sustainable or deeply profitable at its core. It is. Its threat is one I've been highlighting for years and now we're really starting to see: once something is "good enough", people start to question why they should be paying more for better. We now have the rise of a bunch of crazy cheap, yet quite coding-competent models like GLM 5.3 Flash, Qwen 3 Flash, MiMo 2.6 Pro, MiMo 2.6 Flash, Muse Spark 1.3 Contributor, etc. The latter two are almost too cheap to meter. Now, you still need an orchestrator, for planning, supervision, management, etc; it can either be a human or a higher-end model. But you don't need to pay for, say, Opus to get good coding done these days. Anthropic, like OpenAI, is built on charging a sizable premium over inference costs because they have the best and people will pay for it. And sure, in non-verifiable fields (say, medicine), maybe people keep paying for the best, whatever it may happen to be. But the more of the "bulk" coding and the like moves off these premium models and into dirt-cheap models, that seems to represent a real threat to their business model.

Anthropic's response thusfar seems to be "join them". Claude 5.5 Haiku is a good model "flash" model, and they've set quite affordable pricing for it, definitely fitting into the above category. But that doesn't really solve the problem. Their best hope is that Jevon's Paradox kicks up: that now that big projects are so cheap to implement, people keep taking on even bigger projects, scaling their income from cheap flash models like Haiku, orchestrators like Sonnet and Opus, and non-verifiable tasks where people will generally always want to pay for the best. But will that compensate? Hard to tell. This is the threat to Anthropic.

It *sounds* like they are using it for generating bureaucratic material.

Certainly comparatively speaking the stakes are just so much lower, but I've seen a bit of that in my company.

In my case, it's material that generally no one reads, or maybe someone that doesn't matter. GenAI has become a way for people to tick the checkboxes that they think don't matter without trying to debate the reason for the checkboxes.

Suppose the question is whether or not some token gesture facilitated by the GenAI *actually* matters but it's easier to "AI it away" than actually hash out that detail. Does it facilitate people who "I know what I'm doing, just let me do what I know is right" proceed without adequate and accurate oversight. Or is it the case that these situations were already ineffective at oversight, but effective at having whatever would have happened either way just happen in slow motion.

Huh, does stuff like this work in vim? /prompt write me an implementation of the Navier-Stokes equations for a zero-turbulence boundary condition in python, with a sleek modern GUI and test geometry

Unrelated aside, but back in the day when there was just vi, there was always a debate as to whether it's pronounced "vee" or "vie". Eventually my friends and I agreed on a way to settle the debate: we'd have a text-to-speech program read it out for us, and treat whatever it said as canon.

It said: "six".