cloudhead

cloudhead

@cloudhead.io

Computers, graphics, protocols. Working on @radiant.computer Previously @radicle.xyz

255 followers58 following141 posts

I think Fable 5 / GPT 5.6 write better code than the average open source developer now. My reaction to seeing an AI-generated OSS repo is starting to go from negative to neutral.

This. It’s just as hard to write high quality code with agents, if not harder.

antirez@antirez.bsky.social

About the conversation around automatic programming, how useful or useless it is. Well, for me it is quite simple: you need to be very good to multiply your output. Retaining quality is harder now, but if you manage you are accelerated 100x. Instead of fighting I enjoy the race.

It would be cool if you could rebase a conversation with an LLM after editing one of the earlier prompts. Just like `git-rebase`, but over a chat log. This would allow edits to trickle down to all subsequent responses.

Vibed a little TUI to configure my Obsbot webcam under Linux, since there is no official software. Works great!

The major downside of vibe coding is that you end up with 1) much more code, and 2) badly factored code, which leads to 3) very poor token efficiency when making changes. It probably still all works, but the cost of maintenance and change grows much faster than for manually written/reviewed code.

More code incidently also means 4) higher cost to audit, 5) more bugs and 6) poorer cpu and memory performance. Still, lots of hand-written software is slop and people still pay for it.

If you're building something to last, it's probably not a good idea to vibe code it, unless you plan on rewriting it in the future.

I know plenty of very talented engineers who use AI assistance because they are able to produce better work with it. It's just a tool. Moderate people, not tools.

This is what the output of `git show` should look like. I've taken some of the work I did on terminal-based diff rendering for @radicle.dev and made it work as a general git-diff tool.

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

Radiant Computer@radiant.computer

Radiance compiles itself in 0.2s from scratch on the experimental amd64 backend. It's fast 💨

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!

Radiant Computer@radiant.computer

🪵 Radiant Log #012 -- A fixed point has been reached. radiant.computer/log/012-radi...

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.

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 💥😵‍💫

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.

I've been in the deep end on the Radiance AST -> IR lowering pass, but I'm starting to see the light of day. I did things a bit differently this time in terms of code production, and I'm not sure it was worth it: I had Claude generate this compiler pass from scratch, which resulted in...

View full thread

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.

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 been in the deep end on the Radiance AST -> IR lowering pass, but I'm starting to see the light of day. I did things a bit differently this time in terms of code production, and I'm not sure it was worth it: I had Claude generate this compiler pass from scratch, which resulted in...

View full thread

Sometimes, adding 10 lines of code in another module (something it wasn't instructed to do) would allow for removing 50 lines in the module it was working on. It's not clear whether this is solvable via prompting due to unknown unknowns at the time of prompting.

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

I've been in the deep end on the Radiance AST -> IR lowering pass, but I'm starting to see the light of day. I did things a bit differently this time in terms of code production, and I'm not sure it was worth it: I had Claude generate this compiler pass from scratch, which resulted in...

... a 6000 LOC Radiance module which I've been reviewing and simplifying for the last two weeks. The code it generated is mostly correct and well tested, but I've been able to reduce it to 4300 LOC while keeping functionality intact and simplifying things that could be simplified. It's been...

... an interesting exercise. Could I have written this myself in less time? Maybe, I'm not sure. The biggest issue with getting Claude to write code like this is that it doesn't *think*. For instance, it's happy to work within the given constraints without asking "why do these constraints exist?" --

One of the greatest skills in software engineering is to know how much code is needed to implement any given feature. This lets you immediately tell, without reading the code, whether it doesn't account for something (code too short), or it's overcomplicating the solution (code too long).

Writing code has become a lot faster, but understanding code hasn't. What can we do about that?

cloudhead@cloudhead.io

The biggest problem with vibe coding is understanding the state of the code base at any given time. The reason to write code yourself, or to review all the code written by an agent is to have a clear mental model of the program. This is still a major bottleneck.

Don't say "there's no need to understand it", the code is not just the code, the code defines the program and user experience fully. Not having a clear grasp of this is a problem, because the agent doesn't make better decisions than you with regards to your product.

The biggest problem with vibe coding is understanding the state of the code base at any given time. The reason to write code yourself, or to review all the code written by an agent is to have a clear mental model of the program. This is still a major bottleneck.

Interpreted languages have an edge in multi-agent workflows, because agents can't break the build for other agents. Compiled languages have an edge because they created more effective agentic loops. Languages with optional type-checking probably are the best of both worlds in this respect.