Nowhere in this do I see how maintaining the history in this manner even benefits AI. I haven't seen evidence that it can benefit from an insanely over-granular change history.

This is not debating the volume of code, it's the granularity of delivering it as tiny 'changesets'. Just because you *can* create a system that can partition changes into 3 second intervals does not mean there's any value for machine nor human in doing so.

To start, the condescension is hardly helpful.

The point stands, you have to consider the audience for the change tracking. How much granularity is really useful even for the AI models themselves to digest? Certainly no human will digest, but I also don't think the AI is going to be prioritizing putting hundreds of thousands of change history entries into the context window on the off chance that it is relevant to the task at hand.

It seems like a solution to pretend around change management while abandoning any actual use of change management, by human or machines.

O Lord of the Abyss, Prince of Darkness, Morning-Star, please hear my cry: I invoke thee, Lucifer! Turn your gaze toward the Vatican's operating rooms! Guide the surgeon's scalpel with your claws! Burn the tumors from the Holy Father's chest with the infernal fires of Hell! Cast your curses upon any bacterium that may seek to cause opportunistic infection! In the darkness I beseech thee.

Hail Satan, please save the Pope, Amen.

It's cheap and easy to audit OSS for malicious code with AI these days.

It's not really about Microsoft. Increasingly, Europe sees the US as a potential threat who blackmails allies, even a potential invader, rather than an ally.

Literally just yesterday the US shut off intel-sharing to Ukraine (which mainly helps with targeting incoming drones) and blocked all Starlink terminals in Ukraine moving faster than 100kph (e.g. terminals on air-defense interceptor drones), both in effect dramatically hurting Ukraine's ability to defend against Russia's nightly drone waves - all in order to pressure Ukraine into stopping striking Russian oil refineries while Trump seeks to buy more Russian oil and Russia keeps strikig Ukraine's energy infrastructure.

We all know that the US could do this sort of stuff to any of us. We have to move US companies out of our critical paths.

Once upon a time, when the US called for aid after 9/11, Europe stood up. More Danes died per capita fighting in Afghanistan, in a war that was not their own, than Americans did. This year, Denmark was rapidly rushing explosives and bags of blood to Greenland to prepare for firefights against invading US forces.

All of Europe got the message. We're not dining with friends - we're on the menu.

Though in that scenario, it seems bad or useless for the AI as well, as the bloated change history is a waste of context window. Unless they just ignore it in which case what was the point in bothering.

But perhaps it is just another attempt to normalize "human shouldn't be in the loop" mindset, the new toy is but an excuse to say you *should* be having a codebase that is being changed every couple of seconds without bound.

I just cannot wait for that day. When people have a least a *little* less incentive for certain folks to butt in on other people's jobs and tell them how it should be done, despite never even doing nor using an AI to do said job in a serious capacity.

This story triggered a colleague to tell me that I need to stop using git, despite never having used *any* version control scheme nor even using an AI to generate code, just super armchair software development. I do not understand that mindset of people that invested in the nitty gritty of software development without the will to actually do software development.

A changeset history is only so useful compared to analysis of the code as it is. Even pretty large context windows need prioritization. I would think an overly granular changeset history would be a really low prioriity.

Compared to more aggregated changes into fewer changesets, where the history would be probably more digestable, even for AI consumption.

We can't actually know if it is 'actually quite good', because we have only their own self-assessment to go on.

No way to debate how it compares with git partial/shallow clones in broader circumstances. They don't want to share it, they just want to use the concept to fluff their image. It might be amazing, it might be trash, impossible to say anything substantial based on this.

The issue is the situation isn't binary.

Linus comes along with an attempt at nuance and suddenly all sorts of high-slop vibe coders think they are just like Linus.

I know a team that has gone very hard on slopping it up AI, though they just had a flamewar where the AI bros bitched that the more careful people were holding them back by insisting on human review and rejecting merge requests where the human didn't understand what they were submitting.

The thing is, this team was already pumping out shit code for years, so in their case the AI might actually be compelling. Infested by PHB thinking of 'hire many people in random geography, to change each year as different geographies are proven to be shit when you only pay bottom of the barrel'. They have been rotating cheap labor forever hoping for the magical geo where the cheapest people are still skilled (no such geography exists, the bottom of the barrel in any geo is trash). So AI is next on their search.

Absolutely on point. Even if you did decide the volume of code was acceptable, there's no way you need to land 30,000 commits in a day. That's less than 3 seconds per change.

If a human were pushing too many changes, I'd tell them to slow down and take a bit more time per commit. Larger commits that are more manageable instead of rapid fire tiny commits that are impossible to wrangle. If you say the AI commits are large even rapid fire, the point still stands in relative terms.

Commit histories should be there for humans to operate on. To follow the progression of changes, to bisect in case of a long delayed bug, or as the increment to trigger a deployment activity. No human can follow a commit log of 30,000, the AI doesn't need a commit log to do whatever it is doing, bisect is prohibitively slow with that many commits, you need to jump to something other than just picking out of the commit log by that time, and there's no software on earth than needs to be redployed every 3 seconds.

Slopping it up so hard that git was the bottleneck absolutely should not be the brag they think it is.

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).