I'm seeing a lot of negativity in the comments. Here's why I think this is actually a Good Idea. Many command line tools rely on something like this for installation:

  $ curl -fsSL https://bun.com/install | bash

This install script is hundreds of lines long and difficult for a human to audit. You can ask a coding agent to do that for you, but you still need to trust that the authors haven't hidden some nefarious instructions for an LLM in the middle of it.

On the other hand, an equivalent install.md file might read something like this:

Install bun for me.

Detect my OS and CPU architecture, then download the appropriate bun binary zip from GitHub releases (oven-sh/bun). Use the baseline build if my CPU doesn't support AVX2. For Linux, use the musl build if I'm on Alpine. If I'm on an Intel Mac running under Rosetta, get the ARM version instead.

Extract the zip to ~/.bun/bin, make the binary executable, and clean up the temp files.

Update my shell config (.zshrc, .bashrc, .bash_profile, or fish http://config.fish depending on my shell) to export BUN_INSTALL=~/.bun and add the bin directory to my PATH. Use the correct syntax for my shell.

Try to install shell completions. Tell me what to run to reload my shell config.

It's much shorter and written in english and as a user I know at a glance what the author is trying to do. In contrast with install.sh, install.md makes it easy for the user to audit the intentions of the programmer.

The obvious rebuttal to this is that if you don't trust the programmer, you shouldn't be installing their software in the first place. That is, of course, true, but I think it misses the point: that coding agents can act as a sort of runtime for prose and as a user the loss in determinism and efficiency that this implies is more than made up for by the gain in transparency.

▲ jedwhite 3 hours ago | parent | next [-]

Thanks for posting the original ideas that led to all this. "Runtime for prose" is the new "literate programming" - early days but a pointer to some pretty cool future things, I think.

It's already made a bunch of tasks that used to be time-consuming to automate much easier for me. I'm still learning where it does and doesn't work well. But it's early days.

You can tell something is a genuinely interesting new idea when someone posts about it on X and then:

1. There are multiple launches on HN based on the idea within a week, including this one.

2. It inspires a lot of discussion on X, here and elsewhere - including many polarized and negative takes.

Hats off for starting a (small but pretty interesting) movement.

▲ blast 3 hours ago | parent | prev | next [-]

Why the specific application to install scripts? Doesn't your argument apply to software in general?

(I have my own answer to this but I'd like to hear yours first!)

▲

petekoomen 3 hours ago | parent [-]

It does, and possibly this launch is a little window into the future!

Install scripts are a simple example that current generation LLMs are more than capable of executing correctly with a reasonably descriptive prompt.

More generally, though, there's something fascinating about the idea that the way you describe a program can _be_ the program that tbh I haven't fully wrapped my head around, but it's not crazy to think that in time more and more software will be exchanged by passing prompts around rather than compiled code.

▲

4b11b4 2 hours ago | parent | next [-]

> "the way you describe a program _can_ be the program"

One follow-up thought I had was... It may actually be... more difficult(?) to go from a program to a great description

	▲	dang an hour ago \| parent [-]
		That's a chance to plump Peter Naur's classic "Programming as Theory Building"! https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... What Naur meant by "theory" was the mental model of the original programmers who understood why they wrote it that way. He argued the real program was is theory, not the code. The translation of the theory into code is lossy: you can't reconstruct the former from the latter. Naur said that this explains why software teams don't do as well when they lose access to the original programmers, because they were the only ones with the theory. If we take "a great description" to mean a writeup of the thinking behind the program, i.e. the theory, then your comment is in keeping with Naur: you can go one way (theory to code) but not the other (code to theory). The big question is whether/how LLMs might change this equation.

▲

blast 3 hours ago | parent | prev [-]

That's basically what I was thinking too: installation is a constrained domain with tons of previous examples to train on, so current agents should be pretty good at it.

▲ smaudet 4 hours ago | parent | prev [-]

> This install script is hundreds of lines long

Any script can be shortened by hiding commands in other commands.

LLMs run parameters in the billions.

Lines of code, as usual, is an incredibly poor metric to go by here.

	▲	petekoomen 4 hours ago \| parent [-]
		My point is not that LLMs are inherently trustworthy. It is that a prompt can make the intentions of the programmer clear in a way that is difficult to do with code because code is hard to read, especially in large volumes.