Linkblog/2025/03/12

Online discussions about using Large Language Models to help write code inevitably produce comments from developers who’s experiences have been disappointing. They often ask what they’re doing wrong—how come some people are reporting such great results when their own experiments have proved lacking?

[…]

I’ve been getting great results out of LLMs for code for over two years now. Here’s my attempt at transferring some of that experience and intution to you.

Simon’s coverage of LLMs, but also contributors, such as the great llm CLI tool, have been both plentiful and consistently posted / updated.

Usually his web blog is posting other peoples snippets, which I can say nothing ill about as the writer of this link blog which is just that at the moment, but today we’re treated to a full sized Simon himself post!

Here are some of my favorite points brought up in his post:

Set reasonable expectations

Ignore the “AGI” hype—LLMs are still fancy autocomplete. All they do is predict a sequence of tokens—but it turns out writing code is mostly about stringing tokens together in the right order, so they can be extremely useful for this provided you point them in the right direction.

[…]

Context is king

Most of the craft of getting good results out of an LLM comes down to managing its context—the text that is part of your current conversation.

[…]

Vibe-coding is a great way to learn

Andrej Karpathy coined the term vibe-coding just over a month ago, and it has stuck:

[…]

Language choice is always a hot topic! We extensively evaluated many language options, both recently and in prior investigations. We also considered hybrid approaches where certain components could be written in a native language, while keeping core typechecking algorithms in JavaScript. We wrote multiple prototypes experimenting with different data representations in different languages, and did deep investigations into the approaches used by existing native TypeScript parsers like swc, oxc, and esbuild. To be clear, many languages would be suitable in a ground-up rewrite situation. Go did the best when considering multiple criteria that are particular to this situation, and it’s worth explaining a few of them.

A lot of armchair expert programmers shouting why not Rust, Rust fast Rust fast why not C#, C# fast C# fast.

Understand these folks really did consider their options for this, rewrites are not done lightly.

From Simon Willison’s Webblog

Hi everyone, I’d like to show you the Haskell project I’ve been working on for practically forever (5 years). It’s a video game!

It’s a simple multiplayer action game called Pixelpusher that’s meant to be intuitive and frivolous.

You’re on teams and you fight each other with drones, mostly by trying to smash them into stuff. This trailer will show you what I mean.

It’s open source and I’ve also made it available for free on Steam.

While I am a functional enjoyer, I think other languages / paradigms are better for gamedev personally.

But, it is always nice to see people who do make this technical choice not just write a fnacy medium post, or build an advanced ECS engine, without actually shipping anything.

Here, Alex has not only shipped, but shipped something that doesn’t look like a university undergraduates final semester gamedev project they were required to make for marks without any love (which it seems that’s the bulk of these ‘look I made a game using lambda calculus wow):

Large Language Models (LLMs) are rapidly saturating existing benchmarks, necessitating new open-ended evaluations. We introduce the Factorio Learning Environment (FLE), based on the game of Factorio, that tests agents in long-term planning, program synthesis, and resource optimization.

Who needs to play Factorio when an LLM can do it for you?

Great talk by the creator of Zig, Andrew Kelley, on data oriented design.

A lot of discussion on the memory layout of structs, and approaches you can take to better optimize for modern day CPUs.

He references ‘Andre Weissflog’s - Handles are the better pointers’ article, which I’ve heard reference to in the Odin circles I’ve been hanging around (Andrew actually does reference Odin in this talk funny enough).

He also references this graphic:

Notice the x scale, its logarithmic, the difference between a L1 read, a L3 read, and a Main RAM read, is quite visual here.

One thing brought up in his talk, is that sometimes, memoization of an expression that needs math to compute, might just be cheaper to recompute when you need it than store, since yes you’d save the computation, but only potentially wrecked by an expensive memory read.

TL;DR: The DuckDB team and MotherDuck are excited to announce the release of a local UI for DuckDB shipped as part of the ui extension.

DuckDB is shipping with a UI! This is really nice.

Such a great tool, a piece of technology like this shipping with a GUI view on top of it is great too, no need to potentially export this into some other tool to extract insights from it, just do duckdb -ui.

A few months ago we announced a $10,000 bounty to make the best possible visualization of our data showing the ISBN space. We emphasized showing which files we have/haven’t archived already, and we later a dataset describing how many libraries hold ISBNs (a measure of rarity).

Very cool competition, check out the first place!:

“everything is a file” but as a game development environment. top-level virtual filesystem, where VM (lua) scripts are the equivalent of userland processes and device drivers are files to read and write data from. maybe there’s a dedicated protocol for such, like 9P. so you can send typed data across pipes to and from engine components, as well as device and input drivers. or something, idunno.

Very interesting concept.

Very nice to see a seemingly suckless CSG impl.

Very cool room made using Crocotile 3D.