idk how you would define "no tracking", but this is using vercel insights, a tracking tool.
altought i prefer the default HN interface, i think the ui is generally fine and you did a good job and avoided overengineering.
with a text heavy page like HN, the most important thing is imo to carefully choose a font family and font properties (line-height, letter-spacing, etc.).
as is, the default HN does a better job with this but leaves a lot of room for improvement as well.
personally, i'm using a few lines of css to add dark mode to default HN and zoom in to 125% cause the default font-size ist too small for me (an old person).
Much of it is just "put this magic string before your prompt to make the LLM 10x better" voodoo, similar to the SEO voodoo common in the 2000s.
just remember that it works the same for everyone: you input text, magic happens, text comes out.
if you can properly explain a software engineering problem in plain language, you're an expert in using LLMs. everything on top of that people experimenting or trying to build the next big thing.
documents like https://github.com/obra/superpowers/blob/main/skills/testing... are very confusing to read as a human.
"skills" in this project generally don't seem to follow set format and just look like what you would get when prompting an LLM to "write a markdown doc that step by step describes how to do X" (which is what actually happened according to the blog post).
idk, but if you already assume that the LLM knows what TDD is (it probably ingested ~100 whole books about it), why are we feeding a short (and imo confusing) version of that back to it before the actual prompt?
i feel like a lot of projects like this that are supposed to give LLMs "superpowers" or whatever by prompt engineering are operating on the wrong assumption that LLMs are self-learning and can be made 10x smarter just by adding a bit of magic text that the LLM itself produced before the actual prompt.
ofc context matters and if i have a repetitive tasks, i write down my constraints and requirements and paste that in before every prompt that fits this task. but that's just part of the specific context of what i'm trying to do. it's not giving the LLM superpowers, it's just providing context.
i've read a few posts like this now, but what i am always missing is actual examples of how it produces objectively better results compared to just prompting without the whole "you have skill X" thing.
I fully agree. I’ve been running codex with GPT Pro (5o-codex-high) for a few weeks now, and it really just boils down to context.
I’ve found the most helpful things for me is just voice to Whisper to LLMs, managing token usage effectively and restarting chats when necessary, and giving it quantified ways to check when its work is done (say, AI-Unit-Tests with apis or playwright tests.) Also, every file I own is markdown haha.
And obviously having different AI chats for specialized tasks (the way the math works on these models makes this have much better results!)
All of this has allowed me to still be in the PM role like he said, but without burning down a needless forest on having it reevaluate things in its training set lol. But why would we go back to vendor lock in with Claude? Not to mention how much more powerful 5o-codex-high is, it’s not even close
The good thing about what he said is getting AI to work with AI, I have found this to be incredibly useful in promoting, and segmenting out roles
Also the format seems quite badly written. Ie. those “quick references” are actually examples. Several generic sentences are repeated multiple times in different wording across sections, etc.
Everything is just context, of course. Every time I see a blog post on "the nine types of agentic memory" or some such I have a similar reaction.
I would say that systems like this are about getting the agent to correctly choose the precisely correct context snippet for the exact subtask it's doing at a given point within a larger workflow. Obviously you could also do that manually, but that doesn't scale to running many agents in parallel, or running automomously for longer durations.
Just because a popular new tool runs in the terminal, doesn't make it a shining example for the "Unix philosophy" lol.
the comparison makes no sense if you think about it for more than 5 seconds and is hacker news clickbait you and i fell for :(
1. Small programs that do a single thing and are easy to comprehend.
2. Those programs integrate with one another to achieve more complex tasks.
3. Text streams are the universal interface and state is represented as text files on disk.
Sounds like the UNIX philosophy is a great match for LLMs that use text streams as their interface. It's just so normalized that we don't even "see" it anymore. The fact that all your tools work on files, are trivially callable by other programs with a single text-based interface of exec(), and output text makes them usable and consumable by an LLM with nothing else needed. This didn't have to be how we built software.
Right, and Claude Code is a large proprietary monolith. There’s nothing particularly UNIXy about it except that it can fork/execve to call ripgrep (or whatever), and that its CLI can use argv or stdin to receive inputs. That’s nowhere enough to make it “UNIX way”.
UNIX is proprietary too, and also a kinda large monolith. UNIX philosophy or UNIX way is just the standard lingo to describe using many single-purpose (usually command line) programs to accomplish your task, there's nothing more to it, so this AI tool definitely is UNIXy in this way. I'm not old enough to even remember if that was how folks even actually used UNIX systems most of the time back in the days, but it doesn't really matter, that's just how we talk these days.
I mean, you are also a large proprietary monolith. I can't exactly take the run a shell part of your brain and leave the 8 hours of sleep part out. That seemingly is a limitation of intelligence we've not got around yet.
The fact that the AI interpreter will use small commands makes it very useful.
Uh, my only objection way about talking about Claude Code as “UNIX way/philosophy”. While there are some similarities, they’re nowhere sufficient to call it so.
(As far as I’m aware our brains are opposite of UNIX, starting right from the fact they had evolved and were not designed at all. And the article is about Claude and not me.)
The purpose is not so much Claude Code, but that LLMs running semi-autonomously in a shell environment with access to Unix tools are powerful in a way that a web chatbot is not. Replace Claude Code with some other TUI such as opencode and, modulo some of the specifics of CC's implementation, the truth still stands.
The Unix philosophy here is less about it being a terminal app (it's a very rich terminal app, lots of redrawing the whole screen etc) and more about the fact that giving a modern LLM the ability to run shell commands unlocks an incredibly useful array of new capabilities.
An LLM can do effectively anything that a human can do by typing commands into a shell now.
So you'd write (presumably a big) admin web interface in straight XML + CSS by hand? I don't know the details, but that sounds like a very long and painful process which will end up being hellish to maintain, plus a huge amount of training time for new devs to get familiar with the system.
If you even find new devs who'd want to work on this. Who wants to acquire very niche domain knowledge that you can't apply anywhere else?
> So you'd write (presumably a big) admin web interface in straight XML + CSS by hand?
That's not what I said. I think, that what you mean when you say "by hand" is the opposite of generating XML (and in case of XML, it's not CSS, the stylesheets are XSL that transform XML into HTML).
Before JavaScript frameworks were a thing, technologies like ColdFusion, JSP, ASP Classic proliferated. You can even find remains of this approach in relatively modern frameworks like Django. The idea was to generate XML or directly HTML on the server and send it to the client ready to be displayed rather than sending JavaScript that will request more data as it interacts with the user to build the interface. The former would be called "thin client", while the later is the "thick client". The former used to be more popular because programmers didn't see JavaScript or HTML as a worthwhile to learn language, not enough to build programs in it. It was seen as a target for transpilers.
This was before single page applications, or AJAX... The perceived downside of this approach was that for sites with many very similar pages the application server would have to generate a ton of HTMLs, which would be hard to cache server-side, so, allegedly, it would work slowly (compared to AJAX, where a basic HTML page with JavaScript framework would sit in cache and communicate using XML or JSON with the server to build missing parts).
XML + stylesheets is one of the ways to address this problem: essentially it does the same thing, but without JavaScript in the middle. The function of the XML part of the equation is to transfer the data that needs to be displayed, and the stylesheet transforms the XML into HTML that the browser knows how to display. Stylesheet can be generic and reused between different XMLs. It's not as flexible as using JavaScript but a lot easier on resources, and will probably beat AJAX solution in terms of speed.
Another benefit of XML + stylesheets is good integration with the browser testing tools. With tools like Selenium, you will always struggle to catch page state changes, and will not be able to respond to change as it happens, instead needing to poll for expected condition (that might never materialize). Stylesheets take this aspect completely away because there's nothing in them that happens asynchronously or in chunks. Unlike in single page application, where "page loaded" is undefined, there's an obvious way to tell when "page loaded happens".
The problem of XML + XSL(T) is that people have some preconceived notions about it. Very few people know the tool well, and for no particular reason, most people who know anything about the tool know very little about it, but are also very angry about it. Lots of polls for the "worst programming language" would mention XSL(T)... While the truth is that it's just very different from C, and that's what irks programmers. From engineering perspective, sites like, eg. this one, or Reddit or GMail would land themselves well to XML + XSL(T), but the reality is that modern day Web programmers, well, a lot of them, don't even know they have such a tool.
> Similarly, the bare metal solution consisting of nginx with manual Let’s Encrypt cert setup was too much of a hassle.
It's not a hassle. Setup once and then forget about it. It's dead simple, easy and there's a million tutorials on it online.
But it's boring (this is where I'm going to old-man-ramble about things, so better stop reading now). Imo, that's why we have so much bloat, complexity and overkill use of containerization that requires orchestration in software and devops. We don't go the easiest possible route, but the one that seems interesting and most fun.
I totally get playing with new stuff and going totally over board just to host a static html file for a personal project, with the goal to learn something new.
But it's not just personal projects, it's whole companies that adopt this kind of approach, not even thinking 2 years ahead, when the "cool new software" you used is now not only not cool and new anymore, but abandoned and unmaintained.
I get that this is just a random "i did a thing" blog post, but this just annoys me :(
Sorry to annoy you ^^. I'm not a native speaker and I guess it's my wording in the post. What I meant is "setting it up for every new project I would be working on might be cumbersome".
Honestly I thought only friends and family would read it and I didn't spend enough time polishing the nuances in the writing. I didn't expect it to blow up so much :D.
But going back to the point I fully understand your frustration about the overcomplicated approach. Though for my defense I'm planning on hosting many more apps using this setup. In fact I already am but didn't want to overcomplicate the post.
I left it for part 2. Subscribe RSS for followup xD. I feel like a YouTuber after saying that.
