23,372 karma · joined December 14, 2018
Not sure if it had something to do with my env (NixOS), but either way it was a turn off since I see 20-30 MB with GTK3 which is about the size of my full-featured macOS AppKit apps.
Over the last year, I've noticed that the recommended option for technical questions has become one that is always sufficient to the point that I'm once again in a tastemaker position, not in the "here's a better idea btw" position.
And if that's true, then my participation in the intermediate steps isn't strictly necessary to get a well reasoned position that's only directionally wrong.
For example, I want to be asked about general shapes/categories of commands as they first appear for a project and then my decision shapes future classification and gets refined and re-scrutinized over time.
But it gets better every few months. Claude and/or Codex now show a one-line summary for the inline python3 script or grep or pcap command they want to run.
But the thing is that most of this can be encoded in a markdown file for agents to read if it doesn't already come out of the box in the next round of sota models. And funnily enough as agents get smarter, you risk being overprescriptive where you hamstring the agent from making a pivot that would have led to better engineering.
The future is pretty clear to me at this point that we won't need software engineers looking over the shoulder and instead it's just a "user with taste" asking for revisions.
In fact it might actually be the solution that works.
Imagine if an intelligent agent (in service of the user) had to approve every new outbound connection, system call shape, filesystem command, etc. that arbitrary software wanted to make.
HN has a lot of moderation just to keep this place a pleasant place to be. One of the most basic levers in that direction is to prohibit the worst slurs.
Nikita shows up in the replies of a guy with 12k followers complaining that he doesn't get his small payout anymore, and Nikita posts a screenshot of how the guy posted the same text message 12 times in two years, and that's why the guy isn't allowed to make money on X anymore.
As if X has solved low quality reposts so well after turning on monetization that the head of product himself is doing manual demonitization detective work on the final stragglers.
Meanwhile, the biggest accounts on the For You page are zero effort repost bots raking in money, and Elon decided that you're allowed to post the N-word freely. https://x.com/search?q=n*****
Also, X is now just TikTok. Not just its video system (click any video and now you can swipe through recommendation algo), but its text posts too since the whole website is adversarially trying to post their way to a monthly payout.
So while LLMs solve the technical implementation side, there's still upside since now we get to materialize the dang thing we were setting out to build in the first place.
Though there's a huge sense of loss since so much of our skills and identity and time and value were devoted to the engineering side.
But you could be defensive with a security checklist in agents.md and have adversarial review, if you wanted.
And even if you aren't that robust about it, terminal apps are the sort of ideal vibe-coded app since, using it daily, you are giving it a constant real world test that uncovers issues to be fixed incrementally.
Is neovim over tmux over ssh glitching? LLM can fix it.
Is codex or claude code overwriting lines in the TUI, maybe due to alt screen, but it also happens in other major terminal apps? LLM can figure out why and whether you can come up with better general architecture to fix it.
Is there behavior you wish you had but no other terminal app supports? LLM can add it.
You can end up with a far better product than what you would find in the wild, and it's a fun sort of work.
But at the same time LLMs also let you question why you’re using a dependency if it’s causing certain issues for you.
e.g. I got tired of waiting for libghostty to publish a new stable release since the one in March which would have a memory leak fix I reported, so I spent a week of getting LLMs to build my own solid pty/terminal emulator. Now I have my own and frankly I'm in a better position having done it.
That's a ridiculously massive change to our relationship with software projects.
When I brew one big carafe, then I have this compulsion to drink it, like every new task needs a prelude where I get up to refill my mug.
But now there’s too much friction to brew the 2nd or 3rd cup since I know I won’t even feel it.
> The reviews are irrationally nitpicky, choosing one quibble and making the entire review about that. Somehow the apps deserve an overall one-star rating based on that one factor?
Yet OP thinks having a "Review me pls" nag, especially for paying customers, is a trivial thing that users should just brush aside? How about some humility and respect for the user instead of doubling down.
Not to mention the irony of nagging people to review it and then getting mad at the reviews.
That said, I know the frustration and OP surely could have made his point about better examples.
It’s amazing what a good professor can get you to do and love.
If this were a major issue then you'd have to always nail your Rust architecture correctly from day 1 to handle future unknowns, and this isn't the case.
More importantly, LLMs are more than capable of figuring out how to rearchitect code and they have no problem making sweeping refactors for you, especially throwaway experimental ones that were way too expensive to do not long ago.
Thankfully over the centuries some people have used their human moral intuitions to gloss over some of the worst parts. But would’ve been much nicer to not have those parts at all.
What you quoted is just how people paint LLM-heavy users just like how people used to paint JavaScript users as incompetent.
That there are people using LLMs to write 100% of their robust, derisked code disarms their argument or commits them to a sillier one like TFA's "we ban LLMs because you might get it to build a CI pipeline before you have users".
Yeah, with AI you can just fork code, get a fix/feature added, and then have AI fold back in changes if you even care about them.
Maybe people didn't realize you meant that the collective effort of human maintainers is what's dying? As AI gets better it becomes even more trivial to drive a project. The idea of bike-shedding with other people or campaigning to get in some feature that's critical to you becomes pointless.
Just last month I forked libghostty to have AI implement some features I wanted for my personal terminal project, then last week I started getting AI to build me my own terminal engine in Swift.
It came up with its own smart architecture like splitting the execution plan vs render as pty feeds come in, and many other nice things I wouldn't have had the foresight to consider on day 1 had I started the project myself. Not to mention it would have taken me many months of time I don't have.
Granted, it's a week of daily work to get it to a point where I'd use it, and probably another week of polish to where I'd swap libghostty for it. Especially with my slower AI workflow that guarantees robust, well-designed code. But I've written no code, the writing is on the wall, and this is the worst AI will ever be.
It's bog standard, very mild technical debt.
But the problem is a low quality spam problem, not a "people use LLMs at all" nor a "people don't care about the code like real artisanal engineers" problem. Neither of which are something you can police btw since they can't be proven.
How do you build a platform that is resistant to spam and low quality submissions? If you want an honor system, why not set the self-policing bar at low quality content instead of what you feel is a proxy for it?
> with people who have fully adopted claude in their work flows. They don't care about the code they push.
This just isn't true and it's the cynnical self-limiting assumption the belies rules like the TFA. It's like when HN was full of people claiming that you weren't a real engineer and didn't care about code if you used Javascript.
I've vibe-coded some pretty cool things that I use daily, and I've put some serious work into vibe-coding them. Months of work, infinite polish, infinite revisions, without writing a single line of code. It feels like the right level to be at with 20 years of software experience.
LLM use has merely freed up the chore work so that I can focus on more important directional concerns, polish the testing system to completely derisk it, and then do it in parallel with everything else I'm working on.
I'm starting to see the "LLM users don't care" assumption as a somewhat understandable defensive posture that mostly comes from resistance to the world changing and watching the value of our expertise go to zero. Something I still grapple with every week btw. Maybe if you accepted the idea that veteran software engineers can completely replace the code writing experience with AI while delivering good software, it involves swallowing a pill you're not ready to swallow?
Codeberg's new rule about LLMs is about as enforceable as a rule against bad code quality and that is the more interesting discussion.
In the blog post they complain about AI-assisted projects being too polished, using CI resources even though it's a one-man project with zero users. (Reasons they don't give for banning it in the TOS)
So, what's the rule exactly? Can I set up release builds on my one-man project or not? What about when the clearly vibe-coded project does it, do I report them? Does everyone just remember to not check in their AGENTS.md when pushing to codeberg?
I think things should just cost money. Far better than a nonsensical honor system around LLMs which has the obvious outcome of hiding LLM use.
That said, they can foster what ever environment they want. I think it's just a regressive self-limiting view that tries to pretend like the world isn't changing with rules that have bad downstream outcomes, as opposed to a platform that accepts reality and figures out what to do from there. And I find that disappointing.
That's why I dropped creatine since I didn't notice any benefits when I tried it for a year.
And I like how its starry night decided to accentuate the church/steeple in the village backdrop.
Pretty cool how it did these with a scrappy little tool palette. What a fun idea.
The rectangular smudge tool is a weird tool in the first place, but it's cute to see the models try to use it.
It might underspecify, but that is just a quality of the spec. And as long as there is any discretion at implementation time, then the spec necessarily underspecifies to some degree. The goal of a spec is often to be clear on key directional concerns. Consider RFCs.
There's a trade-off between specification and implementation discretion. But if you think about starting at one end ("an internet forum") and then incrementally expanding the specifications ("it has topics with many posts in a linear paginated list"), there's some point where everything you care about is in the spec, and the rest is left to implementor discretion.
That's what I'd consider a good spec and a good LLM prompt.