hiq

This is even more relevant in the context of generated code, where most of the time is spent reviewing rather than writing the code. Abstractions, by allowing the code to be more concise, help.

With LLM code, I'd rather have higher-level abstractions.

As another commenter, I'm probably at 100s per day.

A reason is that I use i3 workspaces, with each workspace being for different tasks, so I don't want to reuse a terminal that has another context.

One issue with keeping a single shell is that the history is full of irrelevant stuff. If you run commands that take a while and print a lot of output, you want it to be as clean as possible. If I want the beginning of the command, I can scroll to the top, and I don't end up with some unrelated output.

I also take quite notes in vim everywhere, often next to long-running commands, using tmux.

I often write multi-line commands in my zsh shell, like while-loops. The nice thing is that I can readily put them in a script if needed.

I guess that somewhat breaks with fish: either you use bash -c '...' from the start, or you adopt the fish syntax, which means you need to convert again when you switch to a (bash) script.

Were you working on it already, or did it take you less than 17 minutes to commit https://github.com/Lulzx/zpdf/commit/9f5a7b70eb4b53672c0e4d8... ?

> WhatsApp

This one is on its way to becoming part of the social media ecosystem. That's what the "Updates" feature is.

To get an idea of what it will look like, check out Instagram users who use it for both 1:1 messaging and social media (1:many) features. Which (again anecdotally) is widely used in younger generations.

Few of my friends use Instagram or TikTok, but I think we're just outliers. I see many (young) users, all the time, whenever I'm on the train.

> Germany trains (and Switzerland trains)

Other commenters have already set the record straight, pointing out that these are clearly not in the same cluster.

See also https://www.thelocal.de/20250430/switzerland-suspends-deutsc...

Pay-walled, but the title says it all: "Switzerland suspends Deutsche Bahn trains due to chronic delays". DB is so unreliable that it impacts the networks of neighboring countries.

I don't ever look at LLM-generated code that either doesn't compile or doesn't pass existing tests. IMHO any proper setup should involve these checks, with the LLM either fixing itself or giving up.

If you have a CLI, you can even script this yourself, if you don't trust your tool to actually try to compile and run tests on its own.

It's a bit like a PR on github from someone I do not know: I'm not going to actually look at it until it passes the CI.

If this code crashed all the time there'd be a business need to fix it and I could justify spending time on this.

But that's not what we're discussing here, we're discussing warnings that have been ignored in the past, and all of a sudden I'm supposed to take the political risk to fix them all somehow, even though there's no new crash, no new information.

I don't know how much freedom you have at your job; but I definitely can't just go to my manager and say: "I'm spending the next few weeks working on warnings nobody else cared about but that for some reason I care about".

It's rare that I work on a project I myself started. If I start working on an existing codebase, the warnings might be there already. Then what do I do?

I'm also referring to all the warnings you might get if you use an existing library. If the requirements entail that I use this library, should I just silence them all?

But I'm guessing you might be talking about more specific warnings. Yes I do fix lints specific to my new code before I commit it, but a lot of warnings might still be logged at runtime, and I may have no control over them.

What does a good developer do when working in a codebase with hundreds of warnings?

Or are you only considering a certain warnings?

Wild (and I guess most of the time bad) idea: on top of the warnings, introduce a `sleep` in the deprecated functions. At every version, increase the sleep.

Has this ever been considered?

The problem with warnings is that they're not really observable: few people actually read these logs, most of the time. Making the deprecation observable means annoying the library users. The question is then: what's the smallest annoyance we can come up with, so that they still have a look?

To be clear this library depends on libsignal.

That's my main way to find interesting links, especially as I usually find comments more interesting than the featured links. I default to the "top 20".

For paying users of Claude Code and other similar services, do you tend to switch to the free tiers of other providers while yours is down? Do you just not use any LLM-based tool in that time? What's your fallback?

> mostly because it’s new tech

Do you then think it'll improve to reach the same stability as other kinds of infra, eventually, or are there more fundamental limits we might hit?

My intuition is that as the models do more with less and the hardware improves, we'll end up with more stability just because we'll be able to afford more redundancy.

I'm assuming it's too heavy and has too much contact surface (so more friction), making it too hard to glide smoothly.

There's probably something with the position of the hand when you move the mouse as well. At least I seem to be moving mostly the wrist when I use my mouse, meaning that my hand and forearm are not always aligned; without this alignment, I feel there's more strain on the wrist when typing.

> They begin the year at $0 and they end the next year at $0.

Or they're dead.

If you save an extra $2000/year, what are you supposed to do with the money if you're always hungry, if you're always cold? I'm guessing you could buy food and clothes; you'd end up at $0, just slightly better off. If there's no safety net to rely on, you'd save to be able to face the next problem, and maybe pay it less with your health (which is a kind of invisible debt).

And that's even assuming there's some certain income you can rely on. In my case, I know that for the next few months, I'd at least get unemployment benefits if I lost my job. Not everyone get that, and if you don't, the income floor is $0 and it's way harder to budget.

Another aspect to consider is that maybe the case of a single person who would be in poverty throughout a long life is not representative of poverty. Some people get out of poverty, some fall into it, some die early from it. If we're considering a single person always starting at $0 and always ending up at $0, several years in a row, we already dismiss these nuances. I'm sure you can find such examples, someone who lived to be 80 with a constant wealth of $0, but how common are they really?

> Given the trajectory of inference cost, it unlikely that they would fail to reach profitability.

Is there evidence that their revenues are growing faster than their costs?

I've started using snippets for code reviews, where I find myself making the same comments (for different colleagues) regularly. I have a keyboard shortcut opening a fuzzy search to find the entry in a single text file. That saves a lot of time.

As an aside, I find most of these commands very long. I tend to use very short aliases, ideally 2 characters. I'm assuming the author uses tab most of the time, if the prefixes don't overlap beyond 3 characters it's not that bad, and maybe the history is more readable.

Thanks for sharing. Why at home? Is it simply your main setup, so you got rid of external displays thanks to it? I'd have thought that in a situation where you can easily use regular displays, these were still preferable.

I'm surprised that you find it comfortable enough for 6+ hours, especially since you probably need to keep it plugged in. I thought the consensus was that for most users it was hard to keep them on even for just a whole movie.

When do you use it? When you're on the go, like on a plane? Or even at home, or in an office? Mostly for coding? Can you use it all day long?

I don't think the tech is good enough for me personally but I'm hoping we get there in a few years.

There's a wild difference in features and ecosystem when using an iPhone, as well as quite some friction in changing, to the point that it's way more than simple brand recognition. iPhones tend to be more expensive, yet they are bought by a wide range of consumers who value them and the Apple ecosystem, the customer support etc. If brand recognition were the main reason for consumers to choose Apple devices, they'd have all switched to Android once they realized they can just pay half.

This friction to switch is just not there for chatbots offering substantially equivalent features. That's why ChatGPT is still mostly free: most users would leave the moment they impose stricter limits. If you know nothing about smartphones but they cost a significant amount of your income, well you try to know more before you buy anything. There's no reason to do that for chatbots yet given that they're free to use, just try it out and stick to the first one you tried until they make it bad enough for you to want to switch.

My point is that there'll be some layer doing that for you. We already have LLMs writing plans for another LLM to execute, and many other such orchestrations, to reduce the constraints on the actual human input. Those implementing this layer need to develop this context engineering; those simply using LLM-based products do not, as it'll be done for them somewhat transparently, eventually. Similar to how not every software engineer needs to be a compiler expert to run a program.

IMHO, don't, don't keep up. Just like "best practices in prompt engineering", these are just temporary workaround for current limitations, and they're bound to disappear quickly. Unless you really need the extra performance right now, just wait until models get you this performance out of the box instead of investing into learning something that'll be obsolete in months.

You're comparing the time spent over 2x with time spent over 1x.

I don't follow the comparison to Apple. Apple phones are not like Android phones, Apple computers are not like Windows computers. There's a real difference between Apple products and others. There's definitely an appeal for devices that just work and are polished (or so I've heard). I don't think ChatGPT has done that in its space.

> they aren't even monetizing aggressively

That's one of the issues with the current valuation: it's unclear to me how many of the 800M MAU will stick to ChatGPT once it monetizes more aggressively, especially if its competitors don't. How many use ChatGPT instead of Claude because the free version offers more? How many will just switch once it doesn't anymore?

OpenAI is already at a 500B valuation; the numbers I could find indicate that this number grew 3x in a year. One can reasonably ask if there's some ceiling or if it can keep on growing indefinitely. Do we expect it to become more valuable than Meta or MSFT? Can they keep raising money at higher valuations? What happens if they can't anymore, given that they seem to rely on this even for their running costs, not even speaking about their investments to remain competitive? Would current investors be fine if the valuation is still 500B in a year, or would they try to exit in a panic sell? Would they panic even if the valuation keeps growing but at a more modest pace?

Your comment made me realize that there's also the benefit of not having to handle the hardware depreciation, it's pushed to the customer. And now Apple has renewed arguments to sell better machines more often ("you had ChatGPT 3-like performance locally last year, now you can get ChatGPT 4-like performance if you buy the new model").

I know folks who still use some old Apple laptops, maybe 5+ years old, since they don't see the point in changing (and indeed if you don't work in IT and don't play video games or other power-demanding jobs, I'm not sure it's worth it). Having new models with some performant local LLM built-in might change this for the average user.

> Linux-like installation process

Maybe that of 20 years ago, it's very smooth these days if you use e.g. Debian.