Live data from Hacker News

Unix philosophy and filesystem access makes Claude Code amazing

alephic.com

61–70 of 223 posts

Re: Unix philosophy and filesystem access makes Claude Code amazing

#61
There's something deeply hypocritical about a blog that criticizes the "SaaS Industrial Complex"[1], while at the same time praising one of the biggest SaaS in existence, while also promoting their own "AI-first" strategy and marketing company.

What even is this? Is it all AI slop? All of these articles are borderline nonsensical, in that weird dreamy tone that all AI slop has.

To see this waxing poetic about the Unix philosophy, which couldn't be farther from the modern "AI" workflow, is... something I can't quite articulate, but let's go with "all shades of wrong". Seeing it on the front page of HN is depressing.

[1]: https://www.alephic.com/no-saas

Re: Unix philosophy and filesystem access makes Claude Code amazing

#62
You know how people used to say the CLI is dead?

Now, due to tools like claude code, CLI is actually clearly the superior interface.

(At least for now)

It's not supposed to be an us vs them flamewar, of course. But it's fun to see a reversal like this from time to time!

Re: Unix philosophy and filesystem access makes Claude Code amazing

#63
post #50

LLMs are one large binary that does everything (maybe, if you are lucky today) exact opposite of the unix philosophy

sure, but that's not what we're talking about here.

the article is framing LLM's as a kind of fuzzy pipe that can automatically connect lots of tools really well. This ability works particularly well with unix-philosophy do-one-thing tools, and so being able to access such tools opens a superpower that is unique and secretly shiny about claudecode that browser-based chatgpt doesn't have.

Re: Unix philosophy and filesystem access makes Claude Code amazing

#64
post #8

I do really like the Unix approach Claude Code takes, because it makes it really easy to create other Unix-like tools and have Claude use them with basically no integration overhead. Just give it the man page for your tool and it'll use it adeptly with no MCP or custom tool definition nonsense. I built a tool that lets Claude use the browser and Claude never has an issue using it.

The light switch moment for me is when I realized I can tell claude to use linters instead of telling it to look for problems itself. The later generally works but having it call tools is way more efficient. I didn't even tell it what linters to use, I asked it for suggestions and it gave me about a dozen of suggestions, I installed them and it started using them without further instruction. I had tried coding with C…

I have a Just task that runs linters (ruff and pyright, in my case), formatter, tests and pre-commit hooks, and have Claude run it every time it thinks it's done with a change. It's good enough that when the checks pass, it's usually complete.

Re: Unix philosophy and filesystem access makes Claude Code amazing

#65

Earlier quoted context omitted.

"Good marketing" doesn't have to mean "Marketing that is maximally effective" Filling food with opioids would be great for business, but hopefully you understand how that is not "good business"

True, but you are arguing about the merit of the actual product, which neither I nor the comment I responded to were talking about at all. Marketing tactics can be applied to good and bad products, and FOMO is a pretty common one everywhere, from "limited remaining" to "early adopters lock in at $10/mo for life" to "everyone else is doing it".

No, I am not arguing about the merits of the product, I am explicitly saying that using FOMO as a marketing tactic is shitty and bad and should make a person who does that feel bad.

I do not care that it is common. I want it to be not common.

I do not care that bad marketing tactics like this can be used to sell "good" products, whatever that means.

Re: Unix philosophy and filesystem access makes Claude Code amazing

#66
post #51

>The filesystem is a great tool to get around the lack of memory and state in LLMs and should be used more often. This feels a bit like rediscovering stateless programming. Obviously the filesystem contents can actually change, but the idea of an idempotent result when running the same AI with the same command(s) and getting the same result would be lovely. Even better if the answer is right.

If it's consistent one way or the other it would be great: consistently wrong, correct it, consistently right, reward it. It's the unpredictability and inconsistency that's a problem.

Re: Unix philosophy and filesystem access makes Claude Code amazing

#67

Earlier quoted context omitted.

I view it as more or less irrelevant. LLMs are fundamentally black boxes. Whether you run the black box locally or use it remotely, whether you train it yourself or use a pretrained version, whether you have access to the training set or not, it's completely irrelevant to control. Using an LLM means giving up control and understanding of the process. Whether it's OpenAI or the training data-guided algorithm that cont…

I on the other hand think it's irrelevant if a technology is a blackbox or not. If it's supposed to fit the opensource/FOSS model of the original post having access to precursors is just as important as having access to the weights. It's fine for models to have open-weights and closed data. It's only barely fitting the opensource model IMHO though.

The point of FOSS is control. You want to have access to the source, including build instructions and everything, in order to be able to meaningfully change the program, and understand what it actually does (or pay an expert to do this for you). You also want to make sure that the company that made this doesn't have a monopoly on fixing it for you, so that they can't ask you for exorbitant sums to address an issue you have.

An open weight model addresses the second part of THIS, but not the first. However, even an open weight model with all of the training data available doesn't fix the first problem. Even if you somehow got access to enough hardware to train your own GPT-5 based on the published data, you still couldn't meaningfully fix an issue you have with it, not even if you hired Ilya Sutskever and Yann LeCun to do it for you: these are black boxes that no one can actually understand at the level of a program or device.

Re: Unix philosophy and filesystem access makes Claude Code amazing

#68
A few days ago I read an article from humnanlayer. They mentioned shipping a weeks worth of collaborative work in less than a day. That was one data point on a project.

- Has anyone found claude code been able to documentation for parts of the code which does not:

(a). Explode in maintenance time exponentially to help claude understand and iterate without falling over/hallucinating/design poorly?

(b). Use it to make code reviewers life easy? If so how?

I think the key issue for me is the time the human takes to *verify*/*maintain* plans is not much less than what it might take them to come up with a plan that is detailed enough that many AI models could easily implement.

Re: Unix philosophy and filesystem access makes Claude Code amazing

#69

You know how people used to say the CLI is dead? Now, due to tools like claude code, CLI is actually clearly the superior interface. (At least for now) It's not supposed to be an us vs them flamewar, of course. But it's fun to see a reversal like this from time to time!

I don't remember any advanced computer user, including developers saying that the CLI is dead.

The CLI has been dead for end-users since computers became powerful enough for GUIs, but the CLI has always been there behind the scenes. The closest we have been to the "CLI is dead" mentality was maybe in the late 90s, with pre-OSX MacOS and Windows, but then OSX gave us a proper Unix shell, Windows gave us PowerShell, and Linux and its shell came to dominate the server market.

Re: Unix philosophy and filesystem access makes Claude Code amazing

#70

Earlier quoted context omitted.

The light switch moment for me is when I realized I can tell claude to use linters instead of telling it to look for problems itself. The later generally works but having it call tools is way more efficient. I didn't even tell it what linters to use, I asked it for suggestions and it gave me about a dozen of suggestions, I installed them and it started using them without further instruction. I had tried coding with C…

I have a Just task that runs linters (ruff and pyright, in my case), formatter, tests and pre-commit hooks, and have Claude run it every time it thinks it's done with a change. It's good enough that when the checks pass, it's usually complete.

A tip for everyone doing this: pipe the linters' stdout to /dev/null to save on tokens.
Post reply on HN