Left to themselves, LLMs prefer writing that's really atrocious. e.g. The writing will try and make everything sound profound.
The other problem I've noticed is e.g. LLMs will write in stuff that's inappropriate for the content of the text. e.g. Writing out stuff that looks like a chat reply, in commentary or descriptions or whatever.
I'd distinguish, though, between "sloppy writing" & "LLM generated writing". I'd agree if you didn't put in the effort to check the writing is of high quality, then perhaps the other parts are also not high quality.
I don't think just because "AI" wrote it it's bad. I wouldn't prefer e.g. sloppy human writing over well-crafted LLM-written text.
This readme the main thing which sticks out is the "what you get" bullet points are rather dense/verbose for bullet points. But aside from that it seems fine.
I'm a technical writer and I use agents a lot for my work and personal projects. I also created a basic open-source preset for agents to create end-user documentation.
During the preset testing, I created dozens of READMEs using agents. Although I can't say that any of them were perfect for me, most of them were good enough.
README is a very special kind of document. For small projects, it's often the only one that potential users will read. The README should explain what the product is, what problems it solves, how to get started, provide some examples, and explain the restrictions. It should cover all these topics in a concise way so that even readers who aren't used to read long texts can easily read through it. It's definitely up to human to make it clear and easy to understand.
It's a similar trade-off to using Terraform to manage a resource, compared to just modifying some cloud resource directly.
You pay a higher upfront cost, but you end up with declarative code which has advantages for maintenance.
With NixOS, rollbacks from changes to system state are trivial; and the whole system is configured from a single starting point, which makes it easy to track down why things are a certain way.
For a personal workstation, it's not necessarily a practical trade-off.
> Just remember that NixOS is only for personal and hobby use cases, as it is maintained by a large community of people that can ship any code they want without review, anchored on the honor system.
This is somewhat inaccurate, and loosely written.
It would be more meaningful to talk about the nixpkgs repository. If you wanted to, you could use Nix with your own vetted nixpkgs codebase.
Whether there are any contributors who can merge without review I'm not sure, but the typical path for contributions is to go through review.
It is permitted to merge code from anonymous people, who could be alter-egos of the maintainer themselves, or whoever stole their credentials. Code signing is not enforced and never will be. I authored the rejected RFC for enforcing code and review signing myself. It is at odds with the community honor system volunteer hobby contributors wish to maintain.
Review is entirely honor system in the nix ecosystem.
This is a hard truth I really need those promoting it for high security use cases to understand.
> The point isn't some people not understanding whatever stuff with limited effects, it's no people understanding anything important.
Using an LLM doesn't mean "I must write this code in a way that I cannot understand it". I'd encourage using the LLM to write code in a way that you can understand.
> When corporations own it exclusively, they can do whatever they want with it.
This is an argument in favour of open-weight models.
> Well, no, for a lot of us, there really is no other side. Slop farming is not software engineering and it never will be; scribbling some Markdown that begs agents to omit bugs is not equivalent to using high-level languages with thoughtful abstractions to directly define program behavior.
Would you look at a piece of code elegantly using high-level abstractions to model some problem written by a human and go "see, look, code is beautiful"... and then look at the exact same code written by an LLM and say "this is slop"?
> Moreover, it's downright offensive for a purported expert to defer their expertise to a SAAS black box.
With programming, it's just the opposite, though.
Programmers work with abstractions. Understanding the full system down to how atoms work is too much to think of when e.g. writing an API handler. So instead you work with modules and their interfaces.
Pre-LLM, if you need some task done, you wouldn't write it all out yourself if there was some external package which did the work for you.
Of course, when using an LLM, you don't need to surrender your ability to think about the problem and solution.
What is an abstraction? An abstraction is far more than a black box. From a previous comment:
> High-level programming languages use well-defined, limited syntax to encode program behavior in a deterministic way. Compilers translate these directions into programs that should have identical behavior between compiler runs and between different compilers. (If they don't, that's a compiler bug, or else an artifact of UB.) This means you can structurally and provably rely on the high-level programming layer without worrying about what's underneath: the assembly is abstracted away. You also get the massive benefit of being able to tweak and improve the assembly layer independently of the programming language layer, so long as the contract between language and compiler is not violated.
> If AI is a "layer of abstraction," so is working with a bunch of contractors to make your app. The definition is broadened to the point of absurdity. (Solely: "I don't have to think about code anymore," which only touches on the most superficial aspect of an abstraction.)
With a good high-level abstraction, I can mostly think on the level of the abstraction, but I can also dive down through the layers and figure out what's actually going on in each one.
> Would you look at a piece of code elegantly using high-level abstractions to model some problem written by a human and go "see, look, code is beautiful"... and then look at the exact same code written by an LLM and say "this is slop"?
Using is one thing; inventing is another. I have seen no evidence that LLMs have the capacity to discover and leverage new abstractions. To me, that's the most exciting part of programming: finding ways to reify powerful concepts and then turn complex tasks into simple ones, ad infinitum.
You want tests to be obvious "at a glance". And then some of the tests should at least indicate it's covering (for the most coverage of the system it reasonably can) the cases we care about.
The name of the test should indicate what it's doing.
For unit tests, these should check only one thing, and the test can be structured into "assemble, act, assert" style tests.
On the implementation side: code which touches state is tricky. -- So, minimize the amount of code which touches state (or rather, shift as much code as you can to stateless code, which is easier to bring under test).
So how do you test that gnarly function that outputs a long series of states that interact with each other based on order in non obvious ways? Like, say, a compiler?
In systems where I've taken complex inputs and transformed it into complex outputs, I'd make it as easy to bring each particular pass under test, have snapshots that the same transformations resulted in the same outputs (insofar as I did want that consistency).
I'd think with a compiler, though, it can still be practical to describe the input you depend on as a value.
In distributed systems, your service might rely on another service which might be broken, might return different values than you expect, might return slower than you expect, etc. and so testing the parts of your system which depend on other services can be tricky.
Point is, you can arrange a lot of your code into "it's easy for me to ensure this part works", and you can see wins from that, even if as a whole the full system can be difficult to bring under test.
I think any of the "JSON + functions" configuration languages mentioned in this thread (there are many) would be just as good.
Writing configurations in a modular way is really neat to be able to do. Rather than having to manage a single YAML file with the resource manifest, you can construct the resource by combining different parts of it.
e.g. rather than { image = "backend", tags = ["backend"] }, { image = "cache", tags = ["backend"] }, you could factor out the `tags`. -- Doing this from a "JSON + functions" language makes more sense than Helm's approach, from my experience.
The module system that NixOS uses builds an abstraction over this: each module declares like { options, config, output }. So the module author defines the option & output, and the module users declare the config, then the system knows how to render the configuration.
The part unique to passkeys is that the ability to disallow use is already sitting dormant everywhere and literally just needs websites to flip a switch. The other things you mentioned would all take effort for websites to set up.
Pre-LLM: Nix is "high effort, moderate reward". The cost is: you have to learn a tool which does things apparently completely different to how other tools do things.. you have to put up with a lot of friction, pay all the pain upfront, and the benefit is that may be later it's easier to get the package again.
It's just not a practical trade-off for most developers.
With LLMs, the cost-benefit trade-off changes.
You can use this cloud provider's LLM to get you a good result. You get the benefits, and the cost is 'just' "ask the LLM to do it".
Similarly: it's easier to assess whether produced code does the right thing, than to come up with that code from scratch.
Without LLMs? The inaccessibility also comes from being a niche tool. Not many use it, so not many software projects accommodate it or consider it, and you might have to come up with workarounds yourself.
This doesn't really do anything to dissuade me from my point of view. So it was a complex system with an extremely high barrier of entry that even nix proponents admitted.
It remains so, only now you want people to blindly trust LLM output for this system.
Some tools are good even though they have a high barrier to entry.
That people use resources to help them use tools they don't understand too well is hardly new. e.g. Classically you might copy-paste from StackOverflow after finding an error, or some people watch YouTube videos about it.
I'd say LLMs make it easier to get to the point where you can understand it, though. So it's an accessibility increase.
> It remains so, only now you want people to blindly trust LLM output for this system.
This isn't related to Nix, though. You could ask an LLM to create the most mainstream Python code ever and blindly trusting it would make as much sense.
For system management, Nix has the advantage of being declarative. e.g. For NixOS you get to read the code and review what it's doing.
Is the high barrier to entry essential though? Is there something about the nix domain that would mean any solution would have as high a barrier to entry? Or is it something they could have simplified greatly, and just never did? (Asking as an outsider, I've always been curious about this).
I went into Nix thinking I would understand the whole thing and then distill a very simplified version, but as it turns out, a significant amount of the complexity is basically required for it to work like it’s supposed to, given how builds and runtimes and dependencies across various languages work, which is unfortunate
Here's a rough sketch: the Nix expression language is really configuration oriented; it's a "JSON + functions" kind of language. You write Nix to describe how a package is built; the ideal case being "./configure && make && make install" as such. The resulting packages are put in a Nix store. (Almost) every dependency is put in the Nix store; so your program links against libraries in the Nix store, or runs other sources from the Nix store.
- Nix is "just" declarations of those instructions which output into directories and everything gets symlinked. But, it can take time to build an intuition for how to do things.
- There's some fundamental friction where most Linux systems assume shared libraries are available globally in a typical place on Linux. -- e.g. Python's "wheels" come with precompiled dependencies which assume shared libraries are available in a global place. Nix doesn't provide that.
- "Why not just provide globals?" For one, by having everything not be global, you can have multiple versions available at the same time.
- Since Nix is quite 'strict' by default about everything coming from the Nix store, it practically means 'paying' for all the difficulties up front. (There's a trade-off where you could write packages in a less strict manner; this is great for iterating, but bad for maintainability).
- Since Nix is strict about symlinking all dependencies, often if upstream software does things in a "quick and dirty manner" (e.g. hardcodes "/bin/bash", hardcodes paths for binaries to run, etc.) then it can be difficult to describe how to package that software with Nix. -- Fundamentally, you're taking something which works loosely, and bringing it into a stricter system.
- Upthread the comment mentions "flakes". Flakes provide both dependency management (i.e. being able to declare other Nix codebases you'll use), as well as a standard entrypoint into a Nix codebase. -- Without flakes, the UX is a bit cumbersome..
- The majority of packages which people use come from "Nixpkgs" package repository. This has a lot of organic complexity to it, coming from multiple contributors, with competing ideas for achieving results.
- With Nix being a "json + functions" language.. not sure I'm articulating this right, but it means that practically a large codebase is built as a single 'expression' (i.e. soft boundaries between bits of code).. and the tooling for troubleshooting problems is ... not very good.
- The Nix expression language is functional and lazy. This can be rough for people who don't have this background.
- Since Nix adds a layer of abstraction, it means you might need to have both a broad and a deep understanding to get something working (e.g. understanding how to drive Python or Linux in non-conventional ways). -- A kind of "do everything properly" which more conventional systems don't require.
So ... some aspects could be easier. But I think there's a fundamental friction to it.
> Something is making us fat, and it sure looks like its the UPFs.
A couple of years ago I lost 20kg (~40lb) of body weight.
I find this phrasing odd. -- Should I say "something made me lose 20kg of body weight", or should I say "I was able to improve the food I ate, and I lost 20kg of weight".
I tend to think that even without scientific literature, people know that e.g. lettuce is "healthier" than chocolate cake and fried chicken.
The term "UPF" seems like a weird term that puts the moral responsibility on the food manufacturers, rather than on "us" who are fat and want to lose weight.
"Moral responsibility" feels like a weird term to use here.
From an epidemiological standpoint, something changed in the environment that caused obesity rates to start rising in the 70s and 80s. There are many theories as to exactly which environmental change is the cause. Figuring out what that change was would be a good thing.
If your concern is about your own health as an individual? I want to lose weight now? I think it's useful to say "I have agency, I can lose weight". If you have the agency to lose weight, it makes sense you can take on the responsibility for having gained weight.
"Why did society in general get fatter?" is a different question. And if your main concern is "how can I lose fat?" it's not directly interesting.
This is a useful criticism.
Left to themselves, LLMs prefer writing that's really atrocious. e.g. The writing will try and make everything sound profound.
The other problem I've noticed is e.g. LLMs will write in stuff that's inappropriate for the content of the text. e.g. Writing out stuff that looks like a chat reply, in commentary or descriptions or whatever.
I'd distinguish, though, between "sloppy writing" & "LLM generated writing". I'd agree if you didn't put in the effort to check the writing is of high quality, then perhaps the other parts are also not high quality.
I don't think just because "AI" wrote it it's bad. I wouldn't prefer e.g. sloppy human writing over well-crafted LLM-written text.
This readme the main thing which sticks out is the "what you get" bullet points are rather dense/verbose for bullet points. But aside from that it seems fine.
reply