Sounds a bit like the idea behind shadcn/ui. You start from the generated components, but the idea is to fork the code.

(Then they seem to also have added their own kind of dependency management thing to update components, which seems to me to kind of defeat the purpose..)

There are lots of good use cases for vibe coding (”never reading the code”), prototypes, various explorations and one-offs. I’ve done various kinds of migrations where I didn’t bother to review the code much, just the output.

Possibly also some user-facing tools with a limited task and runtime environment.

Incidentally, these are all use cases where performance isn’t critical, typically, so you might as well write them in Python or Typescript or whatever makes most sense for the task.

Real production code? Yeah, you still need to be able to read it and understand it.

You don’t need to read the code if you have a robust test suit to validate the output. The article implies testing is the new “reading”. If I spend 10 minutes reading code to find an edge case bug, I have lost the benefit of using AI. AI code is legacy code the moment is generated because I can’t tell why some lines were chosen, so the only way for me to add more features or refactor legacy code is by being very rigorous with testing.

Same. Meanwhile, I _read_ more code than I ever have.

Furthermore, for the example given, it would have made a lot of sense to me to generate those article summaries on the backend. Once and for all, no need to burden each client device (which are going to need to download the content anyway), no need to tie yourself to a specific provider (Apple in this case), can have the same experience everywhere. Of course, the backend could use a local (to itself) model.

Not saying it’s _wrong_ either – maybe it doesn’t use a backend of its own (the client downloads content directly from some predefined set of sites), maybe there is functionality to adjust how the summaries work that benefit from doing it on device, etc. Just doesn’t convince me that ”local AI should be the norm”.

I would say yes, there’s a difference, in general. I would much rather leave the unsafe code to crates used and tested by many other applications, than have them in the application code itself.

What really does not serve the reader any value is this comment now appearing on nearly every single HN thread. (And neither does my comment, sorry about that.)

If you like the article, upvote. If you don’t, don’t.

I appreciate when people tell me something is AI written, so I can avoid reading it.

But people claim that text is AI-written on the most ridiculous grounds, like using proper typography. You might be missing out on interesting stuff!

I'm always missing out on interesting stuff. There's more great stuff being produced every day than can ever be read. It's just one more heuristic to apply.

I would usually agree, but I think we should be obligated to call out slop when we see it.

In a possible defense of grandparent, whenever I pirate movies these days (seldomly), it would be not because I don’t want to pay, but either because I want the offline reliability or because I just can’t find it elsewhere.

(The latter would however not be the case for Titanic, I imagine.)

I like it when the two paradigms can be combined. Where you (or a non-developer) can set up a dashboard by point-and-click, but in the end there’s a source file that can be downloaded, revision controlled, deployed to different environments.

And in the best of worlds, that file format is simple enough to be understood in code reviews and scenarios where you want to generate them programmatically, not a huge incomprehensible json or xml.

I find this to be only even more important in 2026 where you could then also let a code agent generate the dashboard (any agent, any dashboarding software – no need for bespoke agent embeddings in the dashboard UI).

The mouse clickers can click their mouses and those of us (humans and machines) who prefers working with text files can do that. A good file format should take both into account.

This is being addressed in the article. The service no longer does this, and he apologizes.

Yes, I agree. It's been small enough of an issue for me to care (I have `~/.parallel/will-cite` set by my dotfiles repo, so wouldn't even see it on a new machine), but now I switched to `rust-parallel`.

Picked that one because it was supposedly the fastest, I liked the Github page and I will remember the name :) And I guess I was hoping for it to be a drop-in replacement for `parallel` interface-wise, which it turned out it was not, but my needs are quite minimal. I used to do:

ls | parallel 'echo {} && git -C {} fetch --prune --all'

Now I do:

( for i in $(ls); do echo git -C $i fetch --prune --all; done ) | rust-parallel -p