Good engineering + clever use of LLMs will become unbeatable. We're just getting started.

Trying out autoresearch to reduce compiler code size. Not bad, let's see how much of it I'll keep.

An AST editor is always how I imagined the future of code editing -- text is just the visual representation of it, but the editor should operate directly on the AST. This also makes things like code formatters redundant.

This is directionally right: ki-editor.org

Radiant is open-sourcing its compiler toolchain and launching code.radiant.computer today.

Congrats!

Some more details about compiler bootstrapping, fixed points and trust.

Though originally the fixed point was reached after 3 stages, it is now reached in 2!

The problem with agents is they don’t know what they don’t know. We humans do have an intuition for it.

The Radiance compiler has reached a fixed point.

This means it can now compile itself and generate identical output to itself.

user> just fix all the bugs I'm tired and going to bed.
llm> ok, I'll fix all the bugs.

... 8 hours later ...

llm> Wait, the issue might be... Actually... blah blah
llm> But wait! Let me just.. blah blah blah
user> I'm going back to bed.

A.I. and the Future of Computing A new kind of personal computer

🪵 A new log entry was posted: "A.I. and the Future of Computing"

radiant.computer/notes/ai-and...

The bootstrapping stage is a bit of a mindfuck.

R0 = C implementation compiled with clang.
R1 = Radiance implementation compiled with R0.
R2 = Radiance implementation compiled with R1. ⬅️ We're here.

1. Writing a compiler in C to compile Radiance to RV64 ✅
2. Porting the C compiler in (1) to Radiance ✅
3. Compiling the ported compiler in (2) with the compiler in (1) ✅
4. Compiling the self-hosting Radiance compiler (3) with itself 💥😵‍💫

I can't think of anything more soul crushing in the UX space than trying to make a keyboard work on a smart phone's touchscreen. It simply is the wrong interface.

In fact touchscreens are the wrong interface for most things.

ios-countdown.win

I haven't, looks very interesting!

Yes, this is a web-based Git repository browser created from scratch in a couple of hours using an LLM.

Great read, thanks! You might find @radiant.computer interesting, it is very Wirth-inspired.

Bryan Cantrill: Andreessen’s Folly - The False Dichotomy of Software and Hardware YouTube video by Jane Street

Great talk about hardware/software co-design and why serious software developers should think about hardware. This is one of the core principles of @radiant.computer

h/t @lorenz.leutgeb.xyz

www.youtube.com/watch?v=v0Jj...

Incompatibility allows true progress.

Radiant Log #011 A new kind of personal computer

🪵 A new log entry was posted: "Radiance Intermediate Language"

radiant.computer/log/011-radi...

Agreed. Having used both extensively I think the reason is simply that the Claude Code CLI is much better, and Claude is faster at coding.

"On Being a Computer Scientist in the Time of Collapse" is a really excellent and thought provoking read. I'm one of those optimists that is heavily criticized in this essay.

web.cs.ucdavis.edu/~rogaway/pap...

I was wondering what that was

‘What Remains of Edith Finch’ puts every other game I played recently to shame. What a crazy experience.

It's a bit like power tools, they are faster but less precise, and may not give the same results in the end, due to the process being different.

It's generally still quicker to do certain kinds of edits by hand, if you want something very specific. There's also the fact that writing code is a way to form thoughts and ideas that can be superior to prompting, ie. as purely a thinking tool to explore a design space.

And "by hand" doesn't mean typing every character manually, but using Claude in a piecemeal fashion, ie. telling it specifically what functions to write, vs. telling it what the end state should be.

The problem is identifying how Claude will perform early enough in the process, and that's hard, even with experience using LLMs. I think in the future I will limit this kind of workflow to maximum 2K LOC, anything over that should be written by hand or broken up in pieces somehow.

It does seem like focusing specific code leads to better results, eg. if I ask it to simplify the function `lowerFieldRef`, it would find opportunities to simplify the code which it wouldn't if I asked it to do that for a set of functions which includes that one.

I've done multiple passes (and even with Gemini 3), essentially asking it to find patterns and factor them out, or maximize code re-use, and yet through manual review have noticed dozens of obvious simplification opportunities it did not point out to me. This is quite unfortunate.

Another issue is that it seems to forget code it's written, so it doesn't diligently factor out similar behavior the way a human would. You would think that it's good at noticing patterns in the code, but it isn't, even when specifically prompted to review its code and simplify it...