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.
So... What you are saying is that we don't need 'install.md'. Because a developer can just use a LLM to generate a 'install.sh', validate that, and put it into the repo?
Good idea. That seems sensible.
Bonus: LLM is only used once, not every time anyone wants to install some software. With some risks of having to regenerate, because the output was nonsensical.
> What you are saying is that we don't need 'install.md'
I think the point was that install.md is a good way to generate an install.sh.
> validate that, and put it into the repo
The problem being discussed is that the user of the script needs to validate it. It's great if it's validated by the author, but that's already the situation we're in.
> The problem being discussed is that the user of the script needs to validate it. It's great if it's validated by the author, but that's already the situation we're in.
The user is free to use a LLM to 'validate' the `install.sh` file. Just asking it if the script does anything 'bad'. That should be similarly successful as the LLM generating the script based on a description. Maybe even more successful.
I still dont understand why we need any of them. If I am installing something, It would take me more time to write this install.md or install.sh than if I just went to the correct website and copied the command, see the contents, run it and opening help.
And since LLM tokens are expensive and generation is slow, how about we cache that generated code on the server side, so people can just download the pre-generated install.sh? And since not everyone can be bothered to audit LLM code, the publisher can audit and correct it before publishing, so we're effectively caching and deduplicating the auditing work too.
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.
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.
The solution, then, is to add comments to every difficult line of code and have an LLM check that comments match the code. Then you get precision and reliability of machine language + readability of human language
I’m not sure I agree with you that code is hard to read. I usually tend to go straight to the source code as it communicates precisely how something will behave. Well written code, like well written prose can also communicate intent effectively.
TBH. I never read prose that couldn't be in some way misinterpreted or misunderstood. Because much of it is context sensitive.
That is why we have programming languages, they, coupled with a specific interpreter/compiler, are pretty clear on what they do. If someone misunderstands some specific code segment, they can just test their assumptions easily.
You cannot do that with just written prose, you would need to ask the writer of that prose to clarify.
And with programming languages, the context is contained, and clearly stated, otherwise it couldn't be executed. Even undefined behavior is part of that, if you use the same interpreter/compiler.
Also humans often just read something wrong, or skip important parts. That is why we have computers.
Now, I wouldn't trust a LLM to execute prose any better then I trust a random human of reading some how-to guide and doing that.
The whole idea that we now add more documentation to our source code projects, so that dumb AI can make sense of it, is interesting... Maybe generally useful for humans as well... But I would instead target humans, not LLMs. If the LLMs finds it useful as well, great. But I wouldn't try to 'optimize' my instructions so that every LLM doesn't just fall flat on its face. That seems like a futile effort.
This seems like an incredibly long winded, risky and inefficient way to install bun.
I've never actually (knowingly) run Bun before, but decided to give it a try - below is my terminal session to get it running (on macOS):
$ nix-shell -p bun
[nix-shell:~]$ bun
Bun is a fast JavaScript runtime, package manager, bundler, and test
runner. (1.3.5+1e86cebd7)
Usage: bun <command> [...flags] [...args]
Commands:
run ./my-script.ts Execute a file with Bun
lint Run a package.json script
... (rest of output trimmed)...
This seems less auditable though, because now there is more variability in the way something is installed. Now there are two layers to audit:
- What the agent is told to do in prose
- How the agent interprets those instructions with the particular weights/contexts/temperature at the moment.
I’m all for the prose idea, but wouldn’t want to trade determinism for it. Shell scripts can be statically analyzed. And also reviewed. Wouldn’t a better interaction be to use an LLM to audit the shell script, then hash the content?
Yes, this approach (substituting a markdown prompt for a shell script) introduces an interesting trade-off between "do I trust the programmer?" and "do I trust the LLM?" I wouldn't be surprised to see prompt-sharing become the norm as LLMs get better at following instructions and people get more comfortable using them.
How is asking an LLM to make some random install script up better than a script designed by the application developer?
The install.sh is auditable, yes you need to know bash to be able to audit it, but the same is true for an LLM, it could hallucinate random commands that delete files or override other applications/configs.
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.
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.
Even bringing down the "theory" to paper in prosa will be lossy.
And natural languages are open to interpretation and a lot of context will remain unmentioned. While programming languages, together with their tested environment, contain the whole context.
Instrumenting LLMs will also mean, doing a lot of prompt engineering, which on one hand might make the instructions clearer (for the human reader as well), but on the other will likely not transfer as much theory behind why each decision was made. Instead, it will likely focus on copy&pasta guides, that don't require much understanding on why something is done.
That theory, or mental model, is a lot like a program, but of a higher kind. A mental model answers the question: what if I do this or that? It can answer this question with a different level of detail, unlike the program that must be executed completely. The language of a mental model is also different: it talks in terms of constraints and invariants, while the program is a step-by-step guide.
But if the person writing the prompt is expressing their mental model at a higher level, and the code can be generated from that, the resulting artifact is, by Naur's theory, a more accurate representation of the actual program. That would be a big deal.
It is much easier to use LLMs to generate code, validate that code as a developer, fix it, if necessary, and check it into the repo, then if every user has to send prompts to LLMs in order to get the code they can actually execute.
While hoping it doesn't break their system and does what they wanted from it.
Also... that just doesn't scale. How much power would we need, if everyday computing starts with a BIOS sending prompts to LLMs in order to generate a operating system it can use.
Even if it is just about installing stuff... We have CI runners, that constantly install software often on every build. How would they scale if they need LLMs to generate install instructions every time?
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.
I used minimax M2 (context it's very unreliable) for installation and it didn't work and my document folder is missing, help
how do you even debug this? imagine you some path or behaviour is changed in new os release and model thinks it knows better?
if anything goes wrong who is responsible?
I'm thinking isn't that what a readme is? But I guess these days due to GitHub, the readme is the entire project homepage, and the install instructions are either hidden somewhere there (hopefully near the top!) or in a separate installation.md file.
I shared a repo on HN last week that lets you use remote execution with these kinds of script files autonomously - if you want to. It had some interesting negative and positive discussion.
The post mentioned Pete Koomen's install.md idea as an example use case. So now with this launch you can try it with a real intstallation script!
I think it's a really interesting idea worth experimentation and exploration. So it's a positive thing to see Mintlify launch this, and that it's already on Firecrawl.dev's docs!
This is still a very early-stage idea, but I'm really stoked to see this today. For anyone interested in experimenting with it, it's a good idea to try in a sandboxed environment.
This seems like a very, very bad idea. If we don’t like curling into bash, then this is infinitely worse imo.
Just use package management and/or some proper dependency management system
What is the benefit of having this be a standard? Can't an agent follow a guide just as easily in document with similar content in a different structure?
Primarily this being a predictable location for agents. AI not having to fetch the sitemap or llms.txt and then a bunch of subsequent queries saves a lot of time and tokens. There's an advantages section[1] within the proposal docs.
I don't love the concept, but I do wonder if it could be improved by using a skill that packages and install script, and context for troubleshooting. That way you have the benefits of using an install script, and at least a way to provide pointers for those unfamiliar with the underlying tooling.
But I DON'T think the standard should start by piping the prompt directly into claude/model cli. I say this as someone who has seen, first hand, an exfiltration attack locally and almost fell for it after 20 years as a developer.
Even if initially the install.md is safe, install prompt scripts and the things they download aren't packaged and static. They're all surfaces to exploit. The sub-components can be changed between any install, this is true unless we image versions and cache the "safe" imaged version and approve it.
What would be safer to me is a hub that you give a single install script that creates "images", .e.g. DMG for a Mac, .exe for Windows, etc., for platforms. That may actually be an installer app that the User or Agent opens then finishes locally for configuration. Then you point your Agent to that hub.
Nevertheless, then I would just recall XKCD and say, why not just package it with NPM, PyPi, brew, etc.
Installing software should be deterministic and auditable. We have many decades of tool building in devops to facilitate this. It's bonkers to throw that all out for Markdown and LLMs.
Instead, have your LLMs write inputs to those tools. It's an easier task for them anyway and they only have to do it once, then you just run it
Using IaC tools gives you the following advantages:
1. IaC gives you Idempotent solutions- which is advantageous over an agent. What if the agent crashes half way through deployment procedures? How will you reliably resume an interrupted install?
2. IaC gives you reproducible builds
3. IaC gives you ability to install tools in a way that can be tested for compliance with any deployment standards you have
W/r/t frontier models:
Just tell them to go install stuff. They already have so much in their training corpus that you literally do not need to create this.
7b-14b parameter self hosted models may get some benefit from your approach. I find self hosted is less reliable for tasteful approaches. Micromanagement yields better results.
At some point in the future (if not already), claude will install malware less often on average. Just like waymos crash less frequently.
Once you accept that installation will be automated, standardized formats make a lot of sense. Big q is will this particular format, which seems solid, get adopted - probably mostly a timing question
Yes... yes let's make tasks we rely on LESS predictable.
Sorry but what the heck?
We should NOT standardize irresponsible behavior, in particular for repeatable tasks. This is particularly maddening when solutions like dependency resolution, containers, distribution of self-contained and binaries DO exist.
I understand that the hype machine must feed on yet another idea to keep its momentum but this is just ridiculous.
This innocent looking idea represents a shift in mentality: embracing laziness and giving up control to AI. And the latter needs to offer surprisingly little.
Well... Maybe just have a BIOS on your system that fetches a markdown, pushes it to a LLM to generate a new and exciting operating system for you on every boot.
The notion that humans and LLMs need different instructions feels flawed to me. Both humans and LLMs should be able to work with the same instructions.
Great, I can now combine the potential maliciousness of a script with the potential vulnerabilities of an AI Agent!
Jokes aside, this seems like a really wierd thing to leave to agents; I'm sure its definitely useful but how exactly is this more secure, a bad actor could just prompt inject claude (an issue I'm not sure can ever be fixed with our current model of LLMs).
And surely this is significantly slower than a script, claude can take 10-20 seconds to check the node version; if not longer with human approval for each command, a script could do that in miliseconds.
Sure it could help it work on more environments, but stuff is pretty well standardised and we have containers.
I think this part in the FAQ wraps it up neatly:
"""
What about security? Isn't this just curl | bash with extra steps?
This is a fair concern. A few things make install.md different:
Human-readable by design. Users can review the instructions before execution. Unlike obfuscated scripts, the intent is clear.
Step-by-step approval. LLMs in agentic contexts can be configured to request approval before running commands. Users see each action and can reject it.
No hidden behavior. install.md describes outcomes in natural language. Malicious intent is harder to hide than in a shell script.
Install.md doesn't eliminate trust requirements. Users should only use install.md files from sources they trust—same as any installation method.
"""
So it is just curl with extra steps; scripts aren't obfuscated, you can read them; if they are obfuscated then they aren't going to use a Install.md and you (the user) should really think thrice before installing.
Step by step approval also sorta betrays the inital bit about leaving installing stuff to ai and wasting time reading instructions.
Malicious intent is harder to hide, but really if you have any doubt in your mind about an authors potential malefeasance you shouldn't be running it, wrapping claude around this doesn't make it any safer really when possible exploits and malware are likely baked into the software you are trying to install, not the install.
tldr; why not just have @grok is this script safe?
This is some really fantastic feedback, thank you!
I personally think that prose is significantly easier to read than complex bash and there are at least some benefits to it. They may not outweigh the cons, but it's interesting to at least consider.
That said, this is a proposal and something we plan to iterate on. Generating install.sh scripts instead of markdown is something we're at least thinking about.
Off topic: I think there should be an extension to DHCP that distributes AI session keys, so that your vacuum, thermostats and robot chef can all call the LLM as soon as they connect to wifi.
I can't think of a more idiotic idea than a software package where every single user has a slightly different installation because the only way to install it is to feed a hallucinating random word generator with some vague instructions.
Since the article has been changed to tone down its provocative opener, which clearly had a kicking-the-anthill effect, I'm moving those original reactions to this subthread.
>Installing software is a task which should be left to AI.
I think the subtext here is actually revealing a deeper issue. Installing software sucks. It’s error prone and every project does it a slightly different way. What we need is standardization, and I can see why prose could be an attractive middle ground. Easier to understand but less precise may result in marginally better outcomes.
I’m concerned that this approach serves to fix the obvious problems while simultaneously introducing subtler problems.
Tangentially, I’ve been thinking about this a lot lately. There are projects like nix that are excellent at fixing a lot of problems in the software packaging and installation space that are great from a security perspective but are famously difficult to use. I’d personally like to see more work leveraging AI to increase the accessibility of these paradigms and not throw the bathwater out with the baby, so to speak.
Appropriately, I think this was probably drafted by AI too:
> How does install.md work with my existing CLI or scripts?
> install.md doesn't replace your existing tools—it works with them. Your install.md can instruct the LLM to run your CLI, execute your scripts, or follow your existing setup process. Think of it as a layer that guides the LLM to use whatever tools you've already built.
(It doesn't X — it Ys. Think of it as a Z that Ws. this is LLM speak! I don't know why they lean on these constructions to the exclusion of all else, but they demonstrably do. The repo README was also committed by Claude Code. As much as I like some of the code that Claude produces, its Readmes suck)
Yeah, removing that line right now. Went too fast and some this copy is definitely low quality :(. Incredibly ironic for me to say that AI needs more supervision while working at the company proposing this haha.
Any other feedback you have about the general idea?
I think my preferred version of this would be a hybrid. Keep the regular installer, add a file filled with information that an LLM can use to assist a human if the install script fails for some reason.
If the installer was going to succeed in a particular environment anyway, you definitely want to use that instead of an LLM that might sporadically fail for no good reason in that same environment.
If the installer fails then you have a "knowledge base" to help debug it, usable by humans or LLMs, and if it fails, well, the regular installer failed too, so hopefully you're not worse off. If the user runs the helper LLM in yolo mode then the consequences are on them.
The other problem is that without an LLM around, your install.md is suddenly not executable, which means you're effectively importing a massive dependency. Why should I have to burn some of my token quota or pay for extra tokens just to install something?
fascinating. i personally (biased bc i work at Mintlify) think a markdown file makes more sense than a bash script because at least Claude kind of has your best interests at heart.
>i personally (biased bc i work at Mintlify) think a markdown file makes more sense than a bash script because at least Claude kind of has your best interests at heart.
Most of the largest trends in "how to deploy software" revolve around making things predictable and consistent. The idea of abandoning this in favor of making a LLM do the work seems absurd. At least the bash script can be replicated exactly across machines and will do the same thing in the same situation.
Yeah, I'm going to add that as one of the downsides to the docs. The stochastic nature of the markdown vs. a script is for sure a reason to not adopt this.
Wait, but being serious. You can prompt the ai when you feed it this file to ask "do you see anything nefarious" or "follow these instructions, but make sure you ask me every time you install something because i want to check the safety" in a way that you can't when you pipe a script into bash.
Does that make any sense or am I just off my rocker?
No. Absolutely not. The opposite in fact. Your bash script is deterministic. You can send it to 20 AIs or have someone fluent read it. Then you can be confident it’s safe.
An LLM will run the probabilistically likely command each time. This is like using Excel’s ridiculous feature to have a cell be populated by copilot rather than having the AI generate a deterministic formula.
I would think that the common bash scripts we already have would provide an agent better context for installation than a markdown file, and even better, they already work without an LLM.
I can definitely see where you're coming from and agree to a large extent. I was asking myself that question a lot when thinking about this.
What pushed me over the edge was actually feeding bash install scripts into agents and seeing them not perform well. It does work, but a lot worse than this install.md thing.
In the docs for the proposal I wrote the following:
>install.md files are direct commands, not just documentation. The format is structured to trigger immediate autonomous execution.[1]
Fascinating. My thinking was that this is an upgrade over a bash script because you can prompt the AI to check it, clear installs with you, or otherwise investigate safety before installing in a way that isn't natural with *.sh. Does that make any amount of sense or am I just crazy?
Bash scripts give you visibility into what they are going to do by virtue of being machine instructions in a determimistic language. MD files you pipe to matrix multiplication has a much lower chance of being explainable.
Yeah, someone else was pointing that the bash scripts are guaranteed to do the same thing on every system which I think is in the same vein as your feedback. It's for sure a downside of the markdown that I need to explain the docs behind the proposal.
Time and time again, be it "hallucination", prompt injection, or just plain randomness, LLMs have proven themselves woefully insufficient at best when presented with and asked to work with untrusted documents. This simply changes the attack vector rather than solving a real problem
> "Installing software is a task which should be left to AI."
So, after teaching people to outsource their reasoning to an LLM, LLMs are now actively coaching folks to use LLMs for tasks for which it makes no sense at all.
Intent here is that this would be adopted by more difficult to install devtools which are unpackaged to the extent that you need a dependency like a specific version of Node, Python, or a dev lib.
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:
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.
IMO it's completely the other way around.
Shell scripts can be audited. The average user may not do it due to laziness and/or ignorance, but it is perfectly doable.
On the other hand, how do you make sure your LLM, a non-deterministic black box, will not misinterpret the instructions in some freak accident?
How about both worlds?
Instead of asking the agent to execute it for you, you ask the agent to write an install.sh based on the install.md?
Then you can both audit whatever you want before running or not.
So... What you are saying is that we don't need 'install.md'. Because a developer can just use a LLM to generate a 'install.sh', validate that, and put it into the repo?
Good idea. That seems sensible.
Bonus: LLM is only used once, not every time anyone wants to install some software. With some risks of having to regenerate, because the output was nonsensical.
> What you are saying is that we don't need 'install.md'
I think the point was that install.md is a good way to generate an install.sh.
> validate that, and put it into the repo
The problem being discussed is that the user of the script needs to validate it. It's great if it's validated by the author, but that's already the situation we're in.
> The problem being discussed is that the user of the script needs to validate it. It's great if it's validated by the author, but that's already the situation we're in.
The user is free to use a LLM to 'validate' the `install.sh` file. Just asking it if the script does anything 'bad'. That should be similarly successful as the LLM generating the script based on a description. Maybe even more successful.
I still dont understand why we need any of them. If I am installing something, It would take me more time to write this install.md or install.sh than if I just went to the correct website and copied the command, see the contents, run it and opening help.
And since LLM tokens are expensive and generation is slow, how about we cache that generated code on the server side, so people can just download the pre-generated install.sh? And since not everyone can be bothered to audit LLM code, the publisher can audit and correct it before publishing, so we're effectively caching and deduplicating the auditing work too.
This is much better. Plus you get reproducibility and can leverage the AI for more repeat performances without expending more tokens.
then how about you cut out the llm middleman and just audit the bash scripts already provided?
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.
> 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.
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.
The solution, then, is to add comments to every difficult line of code and have an LLM check that comments match the code. Then you get precision and reliability of machine language + readability of human language
I’m not sure I agree with you that code is hard to read. I usually tend to go straight to the source code as it communicates precisely how something will behave. Well written code, like well written prose can also communicate intent effectively.
TBH. I never read prose that couldn't be in some way misinterpreted or misunderstood. Because much of it is context sensitive.
That is why we have programming languages, they, coupled with a specific interpreter/compiler, are pretty clear on what they do. If someone misunderstands some specific code segment, they can just test their assumptions easily.
You cannot do that with just written prose, you would need to ask the writer of that prose to clarify.
And with programming languages, the context is contained, and clearly stated, otherwise it couldn't be executed. Even undefined behavior is part of that, if you use the same interpreter/compiler.
Also humans often just read something wrong, or skip important parts. That is why we have computers.
Now, I wouldn't trust a LLM to execute prose any better then I trust a random human of reading some how-to guide and doing that.
The whole idea that we now add more documentation to our source code projects, so that dumb AI can make sense of it, is interesting... Maybe generally useful for humans as well... But I would instead target humans, not LLMs. If the LLMs finds it useful as well, great. But I wouldn't try to 'optimize' my instructions so that every LLM doesn't just fall flat on its face. That seems like a futile effort.
This seems like an incredibly long winded, risky and inefficient way to install bun.
I've never actually (knowingly) run Bun before, but decided to give it a try - below is my terminal session to get it running (on macOS):
(Edited to wrap a long preformatted line)This seems less auditable though, because now there is more variability in the way something is installed. Now there are two layers to audit:
- What the agent is told to do in prose
- How the agent interprets those instructions with the particular weights/contexts/temperature at the moment.
I’m all for the prose idea, but wouldn’t want to trade determinism for it. Shell scripts can be statically analyzed. And also reviewed. Wouldn’t a better interaction be to use an LLM to audit the shell script, then hash the content?
Yes, this approach (substituting a markdown prompt for a shell script) introduces an interesting trade-off between "do I trust the programmer?" and "do I trust the LLM?" I wouldn't be surprised to see prompt-sharing become the norm as LLMs get better at following instructions and people get more comfortable using them.
The tradeoff is kind of like asking what flavor of bubblegum you would rather be chewing when you get hit by a bus.
I hear you, and I can see the pragmatism of your approach. I’m just not convinced that it’s better.
you assume 2 things: that the instructions will be followed correctly, and that the way they will be followed won't change with agent change
Neither of those things is actually true
People that got their home dir removed by AI agent did not ask for their home dir being removed by AI
How is asking an LLM to make some random install script up better than a script designed by the application developer?
The install.sh is auditable, yes you need to know bash to be able to audit it, but the same is true for an LLM, it could hallucinate random commands that delete files or override other applications/configs.
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!)
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.
> "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
That's a chance to plump for 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.
Even bringing down the "theory" to paper in prosa will be lossy.
And natural languages are open to interpretation and a lot of context will remain unmentioned. While programming languages, together with their tested environment, contain the whole context.
Instrumenting LLMs will also mean, doing a lot of prompt engineering, which on one hand might make the instructions clearer (for the human reader as well), but on the other will likely not transfer as much theory behind why each decision was made. Instead, it will likely focus on copy&pasta guides, that don't require much understanding on why something is done.
I agree that it will be lossy because all writing is lossy.
That theory, or mental model, is a lot like a program, but of a higher kind. A mental model answers the question: what if I do this or that? It can answer this question with a different level of detail, unlike the program that must be executed completely. The language of a mental model is also different: it talks in terms of constraints and invariants, while the program is a step-by-step guide.
"The map is not the territory" applies to AI/LLMs even more so.
LLMs don't have a "mental model" of anything.
But if the person writing the prompt is expressing their mental model at a higher level, and the code can be generated from that, the resulting artifact is, by Naur's theory, a more accurate representation of the actual program. That would be a big deal.
(Note the words "if" and "by Naur's theory".)
TBH, I doubt that this will happen...
It is much easier to use LLMs to generate code, validate that code as a developer, fix it, if necessary, and check it into the repo, then if every user has to send prompts to LLMs in order to get the code they can actually execute.
While hoping it doesn't break their system and does what they wanted from it.
Also... that just doesn't scale. How much power would we need, if everyday computing starts with a BIOS sending prompts to LLMs in order to generate a operating system it can use.
Even if it is just about installing stuff... We have CI runners, that constantly install software often on every build. How would they scale if they need LLMs to generate install instructions every time?
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.
imagine such support ticket:
I used minimax M2 (context it's very unreliable) for installation and it didn't work and my document folder is missing, help
how do you even debug this? imagine you some path or behaviour is changed in new os release and model thinks it knows better? if anything goes wrong who is responsible?
Maybe that is a reason for this approach. It changes the responsibility of errors from the person writing that code, to the one executing it.
Pretty brilliant in a way.
I'm thinking isn't that what a readme is? But I guess these days due to GitHub, the readme is the entire project homepage, and the install instructions are either hidden somewhere there (hopefully near the top!) or in a separate installation.md file.
I shared a repo on HN last week that lets you use remote execution with these kinds of script files autonomously - if you want to. It had some interesting negative and positive discussion.
The post mentioned Pete Koomen's install.md idea as an example use case. So now with this launch you can try it with a real intstallation script!
I think it's a really interesting idea worth experimentation and exploration. So it's a positive thing to see Mintlify launch this, and that it's already on Firecrawl.dev's docs!
We can all learn from it.
Show HN discussion of executable markdown here:
https://news.ycombinator.com/item?id=46549444
The claude-run tool lets you execute files like this autonomously if you want to experiment with it.
Github repo:https://github.com/andisearch/claude-switcher
This is still a very early-stage idea, but I'm really stoked to see this today. For anyone interested in experimenting with it, it's a good idea to try in a sandboxed environment.
This seems like a very, very bad idea. If we don’t like curling into bash, then this is infinitely worse imo. Just use package management and/or some proper dependency management system
What is the benefit of having this be a standard? Can't an agent follow a guide just as easily in document with similar content in a different structure?
Primarily this being a predictable location for agents. AI not having to fetch the sitemap or llms.txt and then a bunch of subsequent queries saves a lot of time and tokens. There's an advantages section[1] within the proposal docs.
[1]: https://www.installmd.org/#advantages
Hey I had a similar idea around skipping the “brew/bun install” copy+paste on a site and instead just give a short prompt to have the LLM do the work.
I like the notion of having install.md be the thing that is referenced in Prompt to Install on the web.
Edit: forgot my link https://dontoisme.github.io/ai/developer-tools/ux/2025/12/27...
I don't love the concept, but I do wonder if it could be improved by using a skill that packages and install script, and context for troubleshooting. That way you have the benefits of using an install script, and at least a way to provide pointers for those unfamiliar with the underlying tooling.
I'm in agreement that standardization is helpful.
But I DON'T think the standard should start by piping the prompt directly into claude/model cli. I say this as someone who has seen, first hand, an exfiltration attack locally and almost fell for it after 20 years as a developer.
Even if initially the install.md is safe, install prompt scripts and the things they download aren't packaged and static. They're all surfaces to exploit. The sub-components can be changed between any install, this is true unless we image versions and cache the "safe" imaged version and approve it.
What would be safer to me is a hub that you give a single install script that creates "images", .e.g. DMG for a Mac, .exe for Windows, etc., for platforms. That may actually be an installer app that the User or Agent opens then finishes locally for configuration. Then you point your Agent to that hub.
Nevertheless, then I would just recall XKCD and say, why not just package it with NPM, PyPi, brew, etc.
I feel like I should create a project called 'Verify Node.js v20.17.0+' that is totally not malware.
Author should explore Ansible/Puppet/Chef.
I’m not sure this solution is needed with frontier models.
Can you explain more? I see how those relate to a very limited extent, but I'm not getting your entire vision.
Installing software should be deterministic and auditable. We have many decades of tool building in devops to facilitate this. It's bonkers to throw that all out for Markdown and LLMs.
Instead, have your LLMs write inputs to those tools. It's an easier task for them anyway and they only have to do it once, then you just run it
Using IaC tools gives you the following advantages:
1. IaC gives you Idempotent solutions- which is advantageous over an agent. What if the agent crashes half way through deployment procedures? How will you reliably resume an interrupted install?
2. IaC gives you reproducible builds
3. IaC gives you ability to install tools in a way that can be tested for compliance with any deployment standards you have
W/r/t frontier models:
Just tell them to go install stuff. They already have so much in their training corpus that you literally do not need to create this.
7b-14b parameter self hosted models may get some benefit from your approach. I find self hosted is less reliable for tasteful approaches. Micromanagement yields better results.
At some point in the future (if not already), claude will install malware less often on average. Just like waymos crash less frequently.
Once you accept that installation will be automated, standardized formats make a lot of sense. Big q is will this particular format, which seems solid, get adopted - probably mostly a timing question
Yes... yes let's make tasks we rely on LESS predictable.
Sorry but what the heck?
We should NOT standardize irresponsible behavior, in particular for repeatable tasks. This is particularly maddening when solutions like dependency resolution, containers, distribution of self-contained and binaries DO exist.
I understand that the hype machine must feed on yet another idea to keep its momentum but this is just ridiculous.
This innocent looking idea represents a shift in mentality: embracing laziness and giving up control to AI. And the latter needs to offer surprisingly little.
Just another day of AI "solutions" desperately looking for problems.
Here's a proposal: app.md. A structured text file with everything you want your app to do.
That way we can have entire projects with nothing but Markdown files. And we can run apps with just `claude run app.md`. Who needs silly code anyway?
Some are already doing it with scripts: https://github.com/andisearch/claude-switcher. Install.md is just specialization of this.
Well... Maybe just have a BIOS on your system that fetches a markdown, pushes it to a LLM to generate a new and exciting operating system for you on every boot.
Wouldn't that be nice?
Why bother with the app at all? Just ask for the end result.
It will produce a different app every single time. :)
Sounds like fun!
The notion that humans and LLMs need different instructions feels flawed to me. Both humans and LLMs should be able to work with the same instructions.
Shameless plug:
If you like install.md, you might love Rundown!
I've made a Rundown version of an install here: https://rundown.cool/explore/install/
Great, I can now combine the potential maliciousness of a script with the potential vulnerabilities of an AI Agent!
Jokes aside, this seems like a really wierd thing to leave to agents; I'm sure its definitely useful but how exactly is this more secure, a bad actor could just prompt inject claude (an issue I'm not sure can ever be fixed with our current model of LLMs).
And surely this is significantly slower than a script, claude can take 10-20 seconds to check the node version; if not longer with human approval for each command, a script could do that in miliseconds.
Sure it could help it work on more environments, but stuff is pretty well standardised and we have containers.
I think this part in the FAQ wraps it up neatly:
""" What about security? Isn't this just curl | bash with extra steps? This is a fair concern. A few things make install.md different:
Install.md doesn't eliminate trust requirements. Users should only use install.md files from sources they trust—same as any installation method. """So it is just curl with extra steps; scripts aren't obfuscated, you can read them; if they are obfuscated then they aren't going to use a Install.md and you (the user) should really think thrice before installing.
Step by step approval also sorta betrays the inital bit about leaving installing stuff to ai and wasting time reading instructions.
Malicious intent is harder to hide, but really if you have any doubt in your mind about an authors potential malefeasance you shouldn't be running it, wrapping claude around this doesn't make it any safer really when possible exploits and malware are likely baked into the software you are trying to install, not the install.
tldr; why not just have @grok is this script safe?
Ten more glorious years to installer.sh
This is some really fantastic feedback, thank you!
I personally think that prose is significantly easier to read than complex bash and there are at least some benefits to it. They may not outweigh the cons, but it's interesting to at least consider.
That said, this is a proposal and something we plan to iterate on. Generating install.sh scripts instead of markdown is something we're at least thinking about.
Off topic: I think there should be an extension to DHCP that distributes AI session keys, so that your vacuum, thermostats and robot chef can all call the LLM as soon as they connect to wifi.
I just use nix for this
https://github.com/arianvp/claude-nix
flake.nix works much better and both for models and humans!
I can't think of a more idiotic idea than a software package where every single user has a slightly different installation because the only way to install it is to feed a hallucinating random word generator with some vague instructions.
Lame.
I mean this is what? feeding a prompt to claude. It could be any other file.
llms.txt makes sense as a standard but this is unnecessary.
[stub for offtopicness]
Since the article has been changed to tone down its provocative opener, which clearly had a kicking-the-anthill effect, I'm moving those original reactions to this subthread.
>Installing software is a task which should be left to AI.
This is such an insane statement. Is this satire?
Ok, I've toned that bit down for you!
>Installing software is a task which should be left to AI.
I think the subtext here is actually revealing a deeper issue. Installing software sucks. It’s error prone and every project does it a slightly different way. What we need is standardization, and I can see why prose could be an attractive middle ground. Easier to understand but less precise may result in marginally better outcomes.
I’m concerned that this approach serves to fix the obvious problems while simultaneously introducing subtler problems.
Tangentially, I’ve been thinking about this a lot lately. There are projects like nix that are excellent at fixing a lot of problems in the software packaging and installation space that are great from a security perspective but are famously difficult to use. I’d personally like to see more work leveraging AI to increase the accessibility of these paradigms and not throw the bathwater out with the baby, so to speak.
>Installing software is a task which should be left to AI
What?? How do I get off of this train? I used to come to hacker news for a reason...what the fuck am I reading
Appropriately, I think this was probably drafted by AI too:
> How does install.md work with my existing CLI or scripts?
> install.md doesn't replace your existing tools—it works with them. Your install.md can instruct the LLM to run your CLI, execute your scripts, or follow your existing setup process. Think of it as a layer that guides the LLM to use whatever tools you've already built.
(It doesn't X — it Ys. Think of it as a Z that Ws. this is LLM speak! I don't know why they lean on these constructions to the exclusion of all else, but they demonstrably do. The repo README was also committed by Claude Code. As much as I like some of the code that Claude produces, its Readmes suck)
Yeah, removing that line right now. Went too fast and some this copy is definitely low quality :(. Incredibly ironic for me to say that AI needs more supervision while working at the company proposing this haha.
Any other feedback you have about the general idea?
I think my preferred version of this would be a hybrid. Keep the regular installer, add a file filled with information that an LLM can use to assist a human if the install script fails for some reason.
If the installer was going to succeed in a particular environment anyway, you definitely want to use that instead of an LLM that might sporadically fail for no good reason in that same environment.
If the installer fails then you have a "knowledge base" to help debug it, usable by humans or LLMs, and if it fails, well, the regular installer failed too, so hopefully you're not worse off. If the user runs the helper LLM in yolo mode then the consequences are on them.
Acknowledged. The standard includes a link to the llms.txt for a site at the bottom which is intended to give it that "knowledge base" to query.
I think I agree with you on it needing to assist in event of failure instead of jumping straight to install though. Will think more about that.
The other problem is that without an LLM around, your install.md is suddenly not executable, which means you're effectively importing a massive dependency. Why should I have to burn some of my token quota or pay for extra tokens just to install something?
THIS is a good idea and use case. Rather than having every install be what every random commands chatGPT decided to spit out that day.
> Installing software is a task which should be left to AI.
Just like installing spice racks is a task which which should be left to military engineer corps.
Understood, just toned that bit down.
This has to be a joke right?
> Installing software is a task which should be left to AI.
Absolutely I don't think so. This is a very bad idea.
$ curl | bash was bad enough. But $ curl -fsSL | claude looks even worse.
What could possibly go wrong?
I gave Claude root to my $3 VPS and I'm delighted to have a server that "configures itself."
I wouldn't use it for anything serious, but that being said, I think it's in better shape than when I was running it.
fascinating. i personally (biased bc i work at Mintlify) think a markdown file makes more sense than a bash script because at least Claude kind of has your best interests at heart.
>i personally (biased bc i work at Mintlify) think a markdown file makes more sense than a bash script because at least Claude kind of has your best interests at heart.
Most of the largest trends in "how to deploy software" revolve around making things predictable and consistent. The idea of abandoning this in favor of making a LLM do the work seems absurd. At least the bash script can be replicated exactly across machines and will do the same thing in the same situation.
Yeah, I'm going to add that as one of the downsides to the docs. The stochastic nature of the markdown vs. a script is for sure a reason to not adopt this.
Tell that to the weekly thread where Claude nukes your home directory or similar
>Claude kind of has your best interests at heart.
That is such a wild thing to say. Unless this whole thing is satire...
Wait, but being serious. You can prompt the ai when you feed it this file to ask "do you see anything nefarious" or "follow these instructions, but make sure you ask me every time you install something because i want to check the safety" in a way that you can't when you pipe a script into bash.
Does that make any sense or am I just off my rocker?
You can do the same thing with any install script you might come across today.
True, that's a fair point. Do you think there's any merit to the idea that the UX of asking about a markdown file is more natural than a bash script?
No. Absolutely not. The opposite in fact. Your bash script is deterministic. You can send it to 20 AIs or have someone fluent read it. Then you can be confident it’s safe.
An LLM will run the probabilistically likely command each time. This is like using Excel’s ridiculous feature to have a cell be populated by copilot rather than having the AI generate a deterministic formula.
[flagged]
I try to have my brain have my best interests at heart, personally.
> Claude kind of has your best interests at heart
How we've all been blue-pilled. Sigh..
I usually complain about proposed standards not being under the /.well-known namespace, but in this case, wow. I can't even comment.
better or worse than llms.txt you think?
Worse, because many projects have INSTALL.md which is intended to be read and followed by humans, not LLMs.
(If LLMs can follow it, so be it, but at least humans remain the target audience.)
Can say install.md is to INSTALL.md what conventional are to ad-hoc commit messages.
I would think that the common bash scripts we already have would provide an agent better context for installation than a markdown file, and even better, they already work without an LLM.
This is a "solution" looking for a problem.
I can definitely see where you're coming from and agree to a large extent. I was asking myself that question a lot when thinking about this.
What pushed me over the edge was actually feeding bash install scripts into agents and seeing them not perform well. It does work, but a lot worse than this install.md thing.
In the docs for the proposal I wrote the following:
>install.md files are direct commands, not just documentation. The format is structured to trigger immediate autonomous execution.[1]
[1]: https://www.installmd.org/
[flagged]
"Don't be snarky."
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
"Don't be curmudgeonly. Thoughtful criticism is fine, but please don't be rigidly or generically negative."
https://news.ycombinator.com/newsguidelines.html
Fascinating. My thinking was that this is an upgrade over a bash script because you can prompt the AI to check it, clear installs with you, or otherwise investigate safety before installing in a way that isn't natural with *.sh. Does that make any amount of sense or am I just crazy?
Bash scripts give you visibility into what they are going to do by virtue of being machine instructions in a determimistic language. MD files you pipe to matrix multiplication has a much lower chance of being explainable.
Yeah, someone else was pointing that the bash scripts are guaranteed to do the same thing on every system which I think is in the same vein as your feedback. It's for sure a downside of the markdown that I need to explain the docs behind the proposal.
Time and time again, be it "hallucination", prompt injection, or just plain randomness, LLMs have proven themselves woefully insufficient at best when presented with and asked to work with untrusted documents. This simply changes the attack vector rather than solving a real problem
In a computing system, LLMs aren't substituting for code, they're substituting for humans. Treat them accordingly.
I don’t understand how this made it to the front page
This is hacker news now. Nothing else here to see, only slop. Everything here is: look what I prompted to take advantage of you
should've been posted on April 1st. would be better suited on that specific date! /s
> "Installing software is a task which should be left to AI."
So, after teaching people to outsource their reasoning to an LLM, LLMs are now actively coaching folks to use LLMs for tasks for which it makes no sense at all.
Why? One of the major day-to-day benefits of LLMs is that they can deal with all the bullshit of modern computing for you.
It's probably making more bullshit and sloppier bullshit at that
Or just, I don’t know… package your software?
Intent here is that this would be adopted by more difficult to install devtools which are unpackaged to the extent that you need a dependency like a specific version of Node, Python, or a dev lib.
I think you want docker?
[dead]
[dead]