Meal deals are in every supermarket in the UK. Petrol stations even do them.
Also, as a foreigner who lives over there, I think they are... sad? I'm surprised they got a positive reception from your coworkers. For me they are a backup and a failure to do something more interesting.
What people don't realise is the startups here in the UK run on miserable sandwiches, tasteless crisps and energy drinks. Middle management lives on slightly more expensive platters from Pret.
Unless you live in bumfuck nowhere theres zero reason to be subjecting yourself to a supermarket meal deal, we've got an overabundance of independent food places in towns in the uk.
This is one of those things that varies by cultural cachet rather than actual quality. It's not that different from people living off Japanese konbini, but those are perceived as much cooler.
Most cities will have local sandwich options as well near major office districts, but they might not be as cheap.
> LLMs aren’t lazy. They don’t cut corners because a simpler solution feels good enough. If they know how to solve something thoroughly, they will.
I don't know why they think this, but no? Perhaps it's badly expressed, but LLMs cut corners all the time. It's sort of their core fault really.
Anyway, I disagree with the core premise[1]. Re-writes are not cheap, because 1) code can be so bad it's unclear how to rewrite it[2], b) code can be so significant it's challenging to rewrite it (architectural choices, schemas, etc), and lastly if you're ever wanting to own your own code and not rent it from LLM companies, having it understandable by a human is still a goal worth working toward.
[1] To be fair, I think OP _might_ be talking about rewriting in the moment of the thing being built, but with some unspoken rule that once they think the change is good enough, then they are reviewing all the code? They don't make it clear..
[2] it's not even that hard. Write a test that exercises an end result and not the rule that causes that end result and 6 months later you've forgotten why the code is like that. I had to maintain a piece of software once where the primary form of tests were a bunch of snapshots of an end report being generated, based on some initial data input, mostly all unlabeled. The code was like "do this SQL query on table A and then take the second result". Why the second result? Your guess is as good as mine! I couldn't even work out why they were querying table A and not table B...
> I don't know why they think this, but no? Perhaps it's badly expressed, but LLMs cut corners all the time. It's sort of their core fault really.
I think this is a matter of perspective about what counts as "cutting corners".
I think they look like you describe only because they have limited competence; this is on the basis that when I asked one to make a fusion reactor simulator (to see if it could) by using open source plasma physics libraries which it had itself suggested at the start of this process (e.g. WarpX), it didn't take the "lazy" option of actually using those libraries, it tried to write its own plasma physics simulation from scratch "as a fallback if we can't install the libraries".
As it was not sufficiently competent, the resulting "simulator" was hilariously wildly unphysical.
Would have been much better if it had been lazy.
To your deeper point: I agree. In this case it made so much of a mess that there was no point trying to rescue it; as it was done from scratch, throwing it away and starting again was fine*, but if this had been pushing commits that got interleaved with real work on the main branch of an existing project it would have been a serious issue.
* or in my case, not even bothering to start again. Like I said, this was done to see if it could.
The diligence to the absurd that you describe is really just a consequence of cutting corners at planning stages. Consider an organization that relies heavily on formal proofs and specifications to one that uses what fits on the 3 bullets allowed in a PowerPoint slide. The first might do less work over all because the second is cutting corners in planning.
Perhaps, though I find myself disagreeing as the planning stage where it itself told me about WarpX. It just then made stupid decisions when left to itself.
Can plan… just not well. Can code… just ok. Can do TDD… just most of the time.
Definitely none of these well enough to be a dark factory though.
Yeah, well.. I think a lot of engineers don't have reason to see the bulk of the industry but if you took an exactly median manager, programmer or PM and ask them a few things you also tend to find that they don't even notice that they will contradict themselves in their answer to a second question, etc. Organizations in general are harnesses that try to get some kind of result out of some pretty sloppy attention.
> Organizations in general are harnesses that try to get some kind of result out of some pretty sloppy attention.
Certainly.
LLMs have superhuman attention, and are so cheap that they can be left running for absurdly long outputs. Despite this, still not high on the competence scale (yet*).
A human doesn't output a few million tokens every day, not even counting our inner monologues, but the AI asymptote to an upper bound of quality somewhat worse than a senior human.
* I would like to have a new job before they reach this point. Got a mortgage to repay.
> I think this is a matter of perspective about what counts as "cutting corners".
The nature of probabilistic sampling practically guarantees that corner cutting is always just a few samples away. Certain sampling strategies can mitigate this, but there's no way to fully eliminate it, without fully eliminating it from the training data and guarding against it during training. Model reasoning can help by giving the model space to draft and review its approach before it executes, but models still aren't guaranteed to follow their own thinking. A mistake or shortcut can always simply slip in during generation and it won't always be caught and corrected.
How on earth are you going to move the needle on "honesty or effort put forth by an LLM" at the logit-choosing stage, though?
To me that's like inferring that you can keep a GPS system from choosing suboptimal cross-country routes by affixing a camera to the grill of the car with sufficient visibility to examine the next fifty feet of pavement.
- Good logits and sampling strategy can make cases like those exceptionally unlikely -- sufficiently so for one to assume it won't realistically happen.
- Once a bad path is sufficiently taken, it tends to be a lot more likely to continue.
This leads to real-world advice:
- If a model refuses your request, do not argue with the refusal; edit your original message or otherwise regenerate -- the presence of refusal tells the model it should continue refusing.
- More generally, don't allow the model context to get contaminated with behavior or commands you don't like -- describing what to do is more effective than describing what NOT to do.
- It's rude to push unreviewed model outputs onto others.
I'm not saying corner-cutting is a thing that is necessarily all over the place (even though there are countless examples in the wild). I'm also not saying it always results in random stops, or that doing one thing bad makes everything else bad. What I'm saying is that bad decisions could be hidden anywhere, at any time, even if everything else looks fine. Such is the nature of current LLMs.
> - Once a bad path is sufficiently taken, it tends to be a lot more likely to continue.
no they demonstrably self correct with injected bad tokens
> - If a model refuses your request, do not argue with the refusal; edit your original message or otherwise regenerate -- the presence of refusal tells the model it should continue refusing.
wish i could do that with humans :P
> - It's rude to push unreviewed model outputs onto others.
Yes but that's not why.
Same real-world advice applies to stuff random fresh graduates make. I remember being one of those.
indeed. That being said, there is a psychological effect of reviews that doesn't exists with LLM. One of the thing that make reviews effective is that when we code, we know someone will look at our code and judge it. It might be subconscious, but it's there.
Not all tools are made for inexperienced people. Not everything is idiot proof. This is OK!
In my experience using the AUR:
1. when you first install the package you can read the build script (and you should). These are in a very standard structure, and if the one you are reading is weird and complicated consider not installing it. No one is forcing you to. Almost every build script I read just downloads a build from a tagged github release.
2. when you get an upgrade you are shown the diff. For almost every AUR package I use this is literally just changing the $VERSION variable and the subsequent $HASH of the download. It is trivial to see if anything (in the AUR script) is happening that is sneaky.
It's really not that scary. And if it's considered scary, there are literally dozens of other linux distros (not to mention Windows or MacOS) you could be using instead.
I'm not asking for myself. Yes, I understand the build process, and know what to check. I've also written PKGBUILDs before and have had packages in AUR. I'm sure you understand it too, as well as many people here.
But many users don't. As far as I can tell, there is very little actual guidance about what to look for, not even to the extent of what you explain here, on the wiki. Users are told to check the PKGBUILD, and warned about AUR-helpers being dangerous, but in practice, it seems AUR-helpers are widely used, and many users likely just click through PKGBUILDs they won't be able to understand.
And, again, this attack was a relatively obvious one. Other attacks could be made much harder to notice.
Worse, distributions like CachyOS are being broadly promoted to a user base who can't be reasonably expected to check over AUR packages themselves. Unlike ArchLinux, those sometimes do seem to promote AUR-helpers. In some cases, those distributions are apparently including AUR-sourced packages in their actual repositories.
Questions about these topics often result in typical Archlinux hostility. And in some sense, that's understandable: there are other distributions that most users should be using, and the frustration of people using Archlinux who shouldn't be is wearing. It is nice to have a distribution that offers the flexibility and space for experimentation that Archlinux does. It's one of the reasons I use it on some of my machines, while at the same time recommending against most others using it.
To some extent, this is just a wide cultural difficulty with Linux, and there isn't a clear answer. On one hand, you want enough gatekeeping to keep users away from potentially dangerous systems they have no interest in understanding, and that they'll rely on without understanding in situations where they shouldn't. On the other, you don't want to keep out users who are interested in learning.
> But many users don't. As far as I can tell, there is very little actual guidance about what to look for, not even to the extent of what you explain here, on the wiki. Users are told to check the PKGBUILD, and warned about AUR-helpers being dangerous, but in practice, it seems AUR-helpers are widely used, and many users likely just click through PKGBUILDs they won't be able to understand.
That's where the whole "Not everything is idiot proof" thing comes in. The distribution is pushing the responsibility on users to vet what they do, across everything, not just installing AUR packages, so naturally this also applies to installing 3rd party software.
If you don't know what to look out for, maybe don't install stuff you don't know what it will do. Sucks as an answer if the distribution is looking to "Make it as easy as possible for every user" but that's not Arch Linux ultimately, it does ask you to care about things like that, if you don't want to, it might not be the OS for you. And that's of course OK and not something bad. I know this sounds like gatekeeping, but it's more of a culture difference than anything, and probably not even a problem.
> distributions like CachyOS are being broadly promoted to a user base who can't be reasonably expected to check over AUR packages themselves
That'd suck, but not the impression I've got from CachyOS. There is a FAQ entry that seems to get the gist of AUR correct, that it's basically random software from random users, nothing is assumed safe: https://wiki.cachyos.org/cachyos_basic/faq/#aur-safety-pract...
> this is just a wide cultural difficulty with Linux, and there isn't a clear answer
I don't think "a answer" is needed here. What some read as "gatekeeping" and "Arch Linux hostility" is in reality just a difference of culture, and that's not a bad thing. Some distributions are for making things "easy for newcomers" or some focus on "best UI and UX" and others "most barebones for experienced users to setup themselves", and all of them as valid as the other. The tricky (and slow/time consuming) part is that you have to try a bunch before you find which one(s) aligns with your own perspectives and ideas.
Ultimately, users can learn best together with distributions that align with how they think and want to work.
>What some read as "gatekeeping" and "Arch Linux hostility" is in reality just a difference of culture, and that's not a bad thing.
Oddly enough, when I was writing that, I wasn't thinking about Arch, but Ubuntu. Years ago, I can remember a situation of a PPA being used for developing something I was involved in somehow, and while the PPA specifically noted that users shouldn't use it, they just did anyway, because they wanted what they saw as the latest and greatest versions of those packages. When the PPA owner added a package that set the default wallpaper to a warning about adding the PPA and updating all packages from it blindly, the users blamed them, rather than understanding the message. At the same time, I was actually using that repository legitimately, and it was useful.
So 100%, I agree that it's highly dangerous that the distro's the next tranche of people unfamiliar with linux (gamers dissatisfied with Windows) move over with, are based on hecking Arch. It feels like a massive upcoming footgun.
I think the issue is those repos being based on Arch though, not Arch itself.
To be fair, among all the linux users I know, no one except developers/cs-adjacent would actually get hit by this. The point is that "noob users" use packages that are, to put it short, maintained by a big company. Or it's something that's there in the official repos. And the big companies always maintain their own supply chain till the end, i.e they maintain their aur packages or their curl | bash endpoint themselves. So it ends up being alright.
Stuff that tinkerers use is often some random fork of a fork of a gitHub repo, maintained by someone else, and the aur package maintained by a fourth person. That's where the mess is. Thankfully, these are also the users you can expect to read a pkgbuild diff.
We must live in different realities, because I have the direct opposite experience.
Perhaps we are defining "job" differently? AI can, with much coaching, _perhaps_[1], do some _aspects_ of a programmer's job. But not all of it, or even the most important parts of it.
[1] given that we have spent the past many decades pointing out that developer productivity is possibly impossible to measure, or at least very hard; given "done" vs "done done"; given the history of "rock star" developers creating messes behind them, the difference between short and long term thinking and the external imperceptability of that difference; given all of that, we haven't really had enough time to form a valid opinion on what AI can do, in the long run.
Back when Snowden leaked all of the spying information, the only thing the States cared about was whether they spied on their own citizens. The fact that they spied on the citizens of their allies, including yes, the EU, barely made the news.
I don't think it makes sense the assume the US considers any country its ally.
sorry that's what I meant: I remember watching their depositions or whatever they were called, and their only concern was whether or not they had spied on US citizens. Whether or not they spied on their allies, I do not recall any coverage of from their primary news outlets (or inside their depositions) at all.
It shares that intelligence with the countries it was gathered from. It's been explicitly stated many times that this is an intentional work around for weak constitutional provisions on protection of citizens.
I spy on your guys. You spy on mine. We all share notes.
This isn't a "The US vs. The World" this is "The Wealthy vs. The Poor."
I agree with the sentiment and dislike Kissinger, but that quote is always paraphrased and out of context.
The full quote makes it clear Kissinger was saying, in the context of the Vietnam War, that the US should come to the aid of their friends:
> "Word should be gotten to Nixon that if Thieu meets the same fate as Diem, the word will go out to the nations of the world that it may be dangerous to be America's enemy, but to be America's friend is fatal."
I'm well aware of its context and original meaning, and I'm very happy to twist its meaning into something Kissinger would disagree with any chance I get.
It is endlessly... amusing (?) to me, that we as a community spent decades trying to make it clear that our productivity is not easily measured because what we're doing is complicated and long running, only for AI to come along and suddenly LoC, Nx multipliers, tickets / week etc are held up as useful if not objective measurements.
The reasons we rejected LoC and other measurements have not changed (broadly: code output isn't important, quality output is). AI has all the same problems people do. But for whatever reason we are throwing what we've learnt away. It's kind of embarrassing.
The non-technical people are in charge and they're not tethered to reality in the same way that engineers are. Objective reality will win in the end, but that doesn't prevent damage being done in the short term.
IDK, I do think a lot of it is LLMs enable people who were not in our community to come into it (in an eternal september kind of way) and they are going through all this from first principals and ignoring their elders, but I've also seen technical people suddenly measuring themselves this way. The most optimistic read of this is that they _feel_ productive, and that feels nice, and they want to share how that feels, and so they are reaching for these garbage metrics because they have nothing else.
> The most optimistic read of this is that they _feel_ productive
In addition to "feel productive", two other feels I think are flying under the radar:
1. You get a parasocial relationship with a "friend" (or at least conversation partner) who seems to "understand" you.
2. You get some form of gambling entertainment when you pull the lever and the output keeps landing on different sides of the jackpot you want.
While #2 has some overlap with classic creative struggle, I think it can at least be seen as a kind of junk-food verson, where the frequency is different and the health-promoting parts aren't present.
Maybe a particular group of software engineer cultivated the need for careful measures. But the programming field never escaped the idea of simple metrics.
That's because you would always have loosely involved but aggressive and demanding bosses (there is unfortunately an economic value to the boss whose primary task is forcing more effort out of the employee and who doesn't help coordination or anything else). So at best you had two intersecting clouds of approaches with actual accomplishment intersecting with LoC and related measurements.
The thing AI is that it provides all the tools to satisfy that loosely involved but demanding boss. So suddenly you are going to have a larger demographic of people who like LoC and feature-additions as metrics 'cause now they are easy.
>we as a community spent decades trying to make it clear that our productivity is not easily measured
Did we? All I saw the last decade was increasing worship of the Github activity grid, from both engineers and non-engineers. IMHO the bazaar had already lost its way before this.
LLMs should be treated as untrusted. At all times.
The mind boggles at the attitudes that seem to have have led to LLMs being an excuse to throw any of the "science" in computer science we've managed to get into production out the window and go elbow deep into treating computers like mystical alchemy.
This is perhaps a very American-centric article? I realise that ZIRP was near-global, but "When banks hiked interest rates, almost every tech company immediately laid off 5-20% of their engineers." does not track with my or my friends' experiences.
And, fundamentally, in countries with employee rights, as an employee I do not give two shits about interest rates the company I work at borrows on. My philosophy on software design does not change. You can argue that the company might pick and choose who it makes redundant, and they might value people who produce "more product", but companies have always valued that visibility. It's your responsibility, if you care, to sell your actions in a commercial context. I don't think ZIRP changes that, and I have not personally noticed a change there.
So currently there are people who are buying grey market peptides[1], marked "not for human consumption" and injecting themselves with them based on dubious anecdotes and vibes, to make their skin clearer, build muscle mass, and so on.
Are they are all suddenly turning into zombies? No. Do they have any real idea what that is going to do to their body a few years down the line? Also no. Could it be catastrophic? Maybe!
I think about this when I think about how violently much of the industry has pivoted into AI being the primary generator of code in the last 6ish months. AI is the peptide, your codebase[2] is the body. Literally no one knows how maintainable this approach is, because there simply hasn't been enough time to find out. It could be fine. It could be a complete mess, with your entire engineering team falling asleep at the wheel, lulled into thinking they understand what is being built when they don't, completely impotent to fix or maintain it once the LLM is no longer able to.
I've been thinking the same: the smaller the codebase, the better AI performs. So a way to scale AI is to modularize your architecture to maximize the number of leaf nodes in the dependency tree, and split out separate libraries where it makes sense.
It is huge for token usage also, Claude grepping the codebase for context it doesn't have is the main consumer of input tokens from what I can see.
The whole AI powered utopia is a bet on two possible outcomes:
- humans and companies somehow stop being greedy, selfish and cutting corners to optimize for revenue and time-to-market
- LLMs are the path to artificial superintelligences that will be able to deal with the exponential increase in tech debt from throwing AI slop at the wall (vibecoding) because no one has time to do things “the proper way”
The former is impossible. The latter is extremely unlikely and an existential threat to humanity.
The so called Luddites are the only ones to have even engaged at all with these concerns. Everybody else is just focused on the selfish game (see bet #1) of staying afloat in a rapidly changing ecosystem.
reply