Recent submissions

Comment · 1 day ago
Oh it's Jacob - I used to work w/ him on his acquired startup, Pluto. He was very AI-pilled; I'm not surprised at the results. I remember wading through the AI-generated Python he had written. I think Pluto had something like 500k or 700k lines after 18mo. Everything was duplicated; there was no reuse of anything. Dozens of features, which mostly worked, not all did.

As a product that I would regularly use, Pluto missed the mark for me. As a SWE in 2023, I couldn't meet Jacob's mentality. Today, it's how a lot of us ship software.

I didn't love the product but I have to respect the process: he was able to sell his company. For some, what he did is success.

Comment · 6 days ago
Finally!! Can’t wait for git lfs support to land, and I can move back to mostly using jj
Comment · 20 days ago
What’s bad about this paper?
Comment · 26 days ago
That David Weber twist was absolutely terrible. Ruined the book for me.
Comment · 28 days ago
Well, I do love building it... but it's a bit of a time-sink, y'know?

I used Orca for ages and that was great; I'm just tired of having to scroll back through a convo to find that "one last blocking question" that Claude or Codex spit out 15 tool calls and subagent messages ago.

Building my own tool is super fun though...

Comment · 28 days ago
One thing about these tools - and, as discussed, there are many - that they mostly seem to share is that they all show coding agents work as a transcript of a conversation.

Why?

The underlying conversation has nothing to do with the work. That there is one context window is an implementation detail.

I've built one of these for myself, and instead it shares questions, plans, findings, assumptions as distinct UI elements. The conversation is hidden: your focus is on "what's next".

Are there other meta-harnesses doing the same thing? I'd love to stop building my own and use a product someone else has already built!

Comment · 1 month ago
What is a submarine article?
Comment · 2 months ago
Unfortunate to see an otherwise-good article padded by AI-isms ("But here’s the twist: that search I described earlier was never sent to botd. All the history was in SQLite, so I pointed another agent at it and got the analysis anyway. The tool died; the data didn’t.", amongst other examples).

Maisem Ali writes about how they have not stopped engineering despite handing production of code over to AI. I think that's an interesting perspective for a few reasons, but most of all, I'm not sure I agree.

First, we see a prime example of how that can blow up. "botd died this month. It crumbled under its own weight." It's hard to imagine how an agent harness (or is it an overlay on top of other harnesses?) could crumble under its own weight from sheer technical complexity. What makes a tool like this "crumble"? If properly architected, it seems that any outside change could be adaptable. Failing tests could be fixed.

This AI coding evolution has given us the ability to spin up prototypes we don't understand the inner workings of, but I believe for anything of value (and, I would argue, botd appeared to have value to Maisem) we should at the very least understand and influence the architecture and engineering of what we're building. If Maisem had done that for botd, it would not and _could not_ have "crumbled under its own weight". Whatever outside influence required change within botd would have been manageable.

Second, the off-loading of the production of this article indicates to me a lack of respect (with no offence to Maisem, because this is what much of the industry is doing today) for the value in thinking through the writing process. There's a lot that I've learned personally about software I worked on that only came to me through trying to write explainers. Taking a step back from the software we build and looking at it from a birds-eye view, to share how it is constructed or how to use it, helps develop our understanding.

Maisem's article is already very good, and I hope that is demonstrative of their own writing! I would read more! But I want to read words written by a person for other people. AI can help edit, it can help us build ideas, but in code and in our written word, AI should not be _the author_.

Comment · 2 months ago
Of course, now you’ve piqued my interest - what is it that you want from your library management tool?

FWIW the tool I’ve built has no built-in ereader because I use apps like Apple Books or my kobo to read. i don’t need another half-built ereader

Comment · 2 months ago
I love it! Thanks for sharing. That makes perfect sense - available from anywhere with limited infrastructure.

Looking forward to seeing what comes next for Bookshelf!

Comment · 2 months ago
Having built a tool in this space, I enjoy seeing all the Calibre alternatives that have been coming out in the last few years! It's fascinating to see the specific wants that people have.

Bookshelf, for example -- what possesses someone to make an ebook library that _only works on object storage_? Is this a weekend project, answering the question of "what would this look like"? Or was it something the author wanted for a long time?

Comment · 3 months ago
It's not _theft_ because nothing is _stolen_. The tokens are being used in a way that breaches the contract agreed to by whomever set up the account with OpenAI, Anthropic, Kilo, Antigravity etc. but it's not theft.
Comment · 3 months ago
Fun idea and a great easter egg, but as a game, the tutorial needs some work. I was so lost for so long and I'm still not sure I understand half of the game!
Comment · 3 months ago
You’re expecting the wrong thing. The demo demonstrates the insane inference rate of dedicated hardware. Iirc it’s llama 3 or something. Not a very good model by today’s standards. But it runs at 16k tokens per second, an order of magnitude above the competition.

Imagine what’s possible if you had GLM-5.2 turned into a hardware chip like this.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton