To be clear, I’m not saying that the technology resulting from a software project should lack soul. It’s obviously a great thing when the authors of an application put a lot of care into designing its UX and operational efficiency; this is an art that LLMs do poorly today. But that is pretty much orthogonal from how the code reads. There is incredible, well-designed software out there which reads as totally boring, and that’s generally considered a good thing.

Also I’m not claiming that it is easy to do that; crafting boring code that still functions as intended is quite difficult. I’ve never seen an LLM do this without lots of hand-holding. The human touch is essential, but that doesn’t imply that a person using an LLM suddenly has stunted vision and lack of aesthetic.

I can’t recall ever wishing the code I was reading had more soul. In fact, usually when the soul of the author shines through, it’s because the code is too exciting and makes me nervous that it’s overly complex. I agree LLMs are terrible at writing prose; it ends up sounding very unnatural and readability suffers. But for the code itself, more often than not, you can achieve precisely the desired result by doing a little up front discussion with the LLM about implementation strategy, plus some revision at the end.

I like descriptive names, to a point. I’d rather have a slightly ambiguous name with a more descriptive sentence in the docs that I can see at the call site via LSP than a super long function name.

poopiendo

This is entering the rotation.

New shortest path meta dropped

https://arxiv.org/pdf/2504.17033

What about nftables?

when every company that has used AI assisted coding is forced to publish their source code

I guarantee you that will never happen. In the US? Do you live here? You think tech billionaires would ever suffer that kind of consequence?

Kent Overstreet

There are still various incompatibilities between the two, and it becomes relevant if you need to work with any organization that has standardized on Docker-specific tooling.

What exactly is your problem with Docker? It’s open source.

Also closed-source container images exist.

I don’t regret the times I show anger at work, but it’s a definitely a fine line that can leave me feeling a bit uneasy afterwards. It’s one of the “social capital” things; you need to earn enough good will to spend your anger on the battles that really matter to you.

Why would you want your entire home folder in syncthing?

I’m not sure I need a lot of compute on my NAS. I guess I might as well get as much as I can before it becomes cost prohibitive. Not planning on running any local LLMs on it though, so a GPU is probably overkill.

I’ve been thinking about getting a real NAS machine instead of having my gaming PC always on. This looks pretty slick.

Archdioces Linux

And by the fact of the longest part of programming being digesting code you didn’t write, in effect you’ve taken a long-cut and could have written it yourself faster.

The conclusion doesn’t follow from the premise. Just because an LLM may need to tweak something doesn’t mean it necessarily would have been faster to do it manually. Humans need to tweak things all the time, it’s called revising, and it’s an important part of improving code.

But I wouldn’t claim that using LLMs is always faster than coding manually, nor the opposite. There are times when LLMs do slow me down. It’s important to recognize when that risk is high.

But I’m quite certain that for prototyping specifically, i.e. building a desired UX to get a feel for it and experiment with whether the ideas are sound, LLMs are faster.

So you don’t get a valid answer, you just get a convincing one.

That’s why you shouldn’t trust an LLM’s reasoning; it doesn’t actually have sound reasoning abilities. You shouldn’t rely on an LLM to reason about problems, you should use it to generate code quickly when the reasoning has either already been done by a human and/or it exists in its training set. LLMs are closer to a search engine than a problem solver.

When asking the person why they did it…

I see no reason why this process is mutually exclusive with using an LLM. You can use both human reasoning and LLM code generation.

No disagreement from me about trivial changes. I make them in my editor all the time, assuming I even have an editor in front of me. Sometimes I don’t, and it’s possible to use dictation to an LLM to make trivial changes without touching a keyboard.

That means that reviews of LLM outputted code by their nature are either invalid and/or non-optimal.

Not convincing. I’ve given my reasons

Again, no one suggested that I would prototype with the LLM and then completely trust what it tells me about the code and what it learned from writing it. That is stupid.

You get the LLM to write code quickly and then you review it and perform experiments manually.

What you did not create, you have not understood.

So just because I didn’t write a book means I could never understand it from reading it? Are editors useless in the world of book publishing? Then what is the point of code review?

You act as if my LLM-assisted prototyping implies I made no decisions and didn’t read any code. That’s obviously a terrible way to use LLMs.

In the case of Rust, it makes sense both as a UX win and a way to abstract certain requirements of the build system. Languages don’t agree on how to do things like linking packages into a binary or versioning packages. If Rust left all of that unspecified, we’d probably have multiple competing package managers and ecosystems.