gritzko

The blog post paints a vivid picture of a slop volcano. We speak of code its authors never read, never share, and never accept patches. So the entire point of git is moot.

On the other hand, some lower-level tools have to be simple, reliable and efficient. Here, sharing is critical. Even the authors of the post shared some incremental improvements to git. Here, the slop-cannon-scalability story is moot.

I think git is becoming a protocol. One product can no longer cover these cases.

I remember sharing packlog ideas on the Git Discord. God knows whom I cross-pollinated then.

I think Git is becoming a protocol and that is good. Let a thousand flowers bloom. On the other hand, would any of the parties mentioned share their code with anyone? If so, would anyone be ever interested in using it?

Technically, malloc() is a library function, not core C. My point is this: guarantees cost complexity, and you always have to keep in mind the assumptions and how much of it is theater. So, neither way is strictly better. It depends. For immutable data, lifetimes don't buy much, for example.

If you don't allocate, why do you even need Go or Rust? LLMs handle less elegant syntax just as well. I use a zero-malloc C dialect with slices and bounds-checking.

Just recently I was sketching a smallish database in zero-malloc C. https://replicated.live/blog/db That was partly because most LSM data structures are read-only, so mmap was good enough and concurrent access was safe for the bulk of the data.

The "hot zone" (memtable) then requires some intricate engineering, but that is the case either way.

You can go quite far with zero-malloc C.

Regulation should not be a problem, there are several past precedents https://en.wikipedia.org/wiki/Chipknip

StarCraft probably has hundreds of bot implementations lying on GitHub. Which makes this bench a recall-from-the-training-set competition, essentially. I tried that method on old games that certainly do not have a ton of bot implementations on GitHub. It revealed some interesting aspects about LLM reasoning and ways to use it. https://replicated.live/blog/games

Overall, this is a useful benchmarking approach. May take some newer papers and evaluate them this way.

These productivity gains must go somewhere.

E = mc²

E energy necessary to integrate changes

m mass of the monorepo

c rate of commits

This graph shows that Yandex Web crawler farm was hit. The other option, it was shut down to accommodate more critical services that got hit. (I worked for Yandex 20 years ago, one crawler guy was in the same room.) Not sure if troll farms got affected in any way, that is a different business entirely, no overlap.

The interesting aspect is this: Yandex was taken from its owners semi-consensually. Similarly, the original owner of the troll farms was blown up in a business jet. He staged a mutiny cause his dirty bloody business was about to be taken from him non-consensually. Some other large non-consensual takeovers unfold for 5 years, soon 6.

What an appetite!

I made AIs (the new kind) create AIs (the classic kind) to battle in old games. That was a serious experiment! http://replicated.live/blog/games

Do these runtimes have some value today? Sort of. But the cost of reimplementing them goes down, down, down. I made two bespoke JS runtimes within a year. Next year it will be even easier.

Deno/Bun see the picture better than I do, and they decided it was the right time for an acquihire.

OK, I guess we will see Turing's Bombe in a browser before Christmas?

> the joy and creativity of writing code, of solving seemingly-impossible puzzles with ones mind

Find tougher puzzles then

Exactly. I switched to Linux in the 90s.

Ah, yes, sorry. At this point, XP and DOS are almost synonymous for me.

The entire point of the port was to add headless play for AI training. But porting the old interface and playing it in the browser was lots of fun. Can not upload that to GitHub, obviously.

Opus 5.5.

So much fun. I recently ported some old strategy games. Claude does it almost on its own http://replicated.live/blog/games

opus 5.5 medium web "Lantern"

gpt-5.6 web "Serendipity"

opus 5.5 medium code "Lighthouse"

opus 5.5 high code "Lantern"

fable 5.1 medium code "Lantern"

fable 5.1 high code "Lantern"

flash 3.6 web "Serendipity"

gemini 3.1 pro web "Ephemeral" (this one was thinking real hard)

A hero hacking for free food and a chance to swap Cloudflare credits for stolen goods on the black market. That is W.Gibson's original cyberpunk spirit.

I recall playing this game as a preschooler. It was mostly psychology and bluff. Very interesting.

Last weekend, I made Claude play Panzer General II. I am pretty sure it will be in the weights soon, so it was valuable as an environment the LLM is not trained for. It accumulated experience in Markdown, made some tools to parse the game data and it got to a decent level of skill. It reached the last battle.

I tried to make it win the last battle, but that was beyond its ability. Further accumulation of "hard earned lessons" in Markdown only made its behavior more chaotic.

Still, a very decent result, comparable to what I achieved back in the day (late 90s).

> This is not surprising in hindsight and is probably the optimal strategy. The agent extracted quest requirements, quest givers, turn-in NPCs, and spawn coordinates from AzerothCore SQL files to provide the concrete checklist and locations for planning.

> Using this data, it's also able to create an optimal strategy for quest order and preparation.

Bwahaha

"Now we talked so much about Codemode, it might be worth explaining what that even is."

Hits hard.

I looked into them. Most of them use some CRDT-ish machinery to merge concurrent ticket changes. (Fixing merge conflicts in tickets would be too disappointing.) As a CRDT person, I noticed that implementing CRDT merges in git itself mostly makes that machinery unnecessary. Then you can keep your tickets in plain Markdown, having CRDT merges for both code and metadata. I have it working here btw

https://replicated.live/blog/meta

The git-ness of this argument exceeds 100%.

The motivation fades to make things intuitive.

Very interesting post. Feels like my comment from two days ago [1], elaborated. I must thank the author for verbalizing all the concerns.

So now we have a fork: red-pillers who want to regenerate software all the time (esp those with unlimited token budgets) and blue-pillers who want to maintain more code mass per developer-head. Plus, we have software artisans.

That will be an interesting horse race.

[1]: https://news.ycombinator.com/item?id=49774239

This is close to my default workflow. One Fable to rule them all, many Opuses to implement. All work is planned, tracked and logged in plain Markdown tickets. No magic. Nothing to talk about.

Still, I have to keep an eye on it or it devolves into a mess real fast. An example from yesterday: I noticed the commit added 10K lines where it clearly should not have. 5min of digging: it was a combinatorial state explosion in the parsers. All at once because a shared grammar was tweaked. Oopsies like this happen all the time, and with every passing hour it becomes harder to fix.

Can only rely on that chief-of-stuff for mundane things.