Much less money lost, but Amazon is notorious for not providing free game codes that are supposed to be included with GPU purchases. The customer rep at first apologized and offered a small refund (less than the cost of the game). A later rep started implying I was trying to defraud Amazon.
Many people online share similar experiences. Wonder how much money this wide-scale fraud saves them.
Amazon doing dodgy things with PC parts is why I will no longer purchase them from there - I'll happily take the extra £10-20 hit to buy it from another "proper" retailer (ie, Scan or Overclockers here in the UK), knowing that issues can be resolved more easily
I don’t think I’ve ever seen someone seriously argue that personal throwaway projects need thorough code reviews of their vibe code. The problem comes in when I’m maintaining a 20 year old code base used by anywhere from 1M to 1B users.
In other words you can’t vibe code in an environment where evaluating “does this code work” is an existential question. This is the case where 7k LOC/day becomes terrifying.
Until we get much better at automatically proving correctness of programs we will need review.
My point about my experience with this plugin isn’t that it’s a throwaway or meaningless project. My point is that it might be enough in some cases to verify output without verifying code. Another example: I had to import tens of thousands of records of relational data. I got AI to write the code for the import. All I verified was that the data was imported correctly. I didn’t even look at the code.
In this context I meant throwaway as "low stakes" not "meaningless". Again, evaluating the output of a database import like that could be existensial for your company given the context. Not to mention there's many cases where evaluating the output isn't feasible for a human.
Human code review does not prove correctness. Almost every software service out there contains bugs. Humans have struggled for decades to reliably produce correct software at scale and speed. Overall, humans have a pretty terrible track record of producing bug-free correct code no matter how much they double-check and review their code along the way.
So the solution is to stop doing code reviews and just YOLO-merge everything? After all, everything is fucked already, how much worse could it get?
For the record, there are examples where human code review and design guidelines can lead to very low-bug code. NASA published their internal guidelines for producing safety-critical code[1]. The problem is that the development cost of software when using such processes is too high for most companies, and most companies don't actually produce safety-critical software.
My experience with the vast majority of LLM code submitted to projects I maintain is that it has subtle bugs that I managed to find through fairly cursory human review. The copilot code review feature on GitHub also tends to miss actual bugs and report nonexistent bugs, making it worse than useless. So in my view, the death of the benefits of human code review have been wildly exaggerated.
No, that's not what I wrote, and it's not the correct conclusion. What I wrote (and what you, in fact, also wrote) is that in reality we generally do not actually need provably correct software except in rare cases (e.g., safety-critical applications). Suggesting that human review cannot be reduced or phased out at all until we can automatically prove correctness is wrong, because fully 100% correct and bug-free software is not needed for the vast majority of code being produced. That does not mean we immediately throw out all human review, but the bar for making changes for how we review code is certainly much lower than the above poster suggested.
I don't really buy your premise. What you're suggesting is that all code has bugs, and those bugs have equal severity and distribution regardless of any forethought or rigor put into the code.
You're right, human review and thorough design are a poor approximation of proving assumptions about your code. Yes bugs still exist. No you won't be able to prove the correctness of your code.
However, I can pretty confidently assume that malloc will work when I call it. I can pretty confidently assume that my thoroughly tested linked list will work when I call it. I can pretty confidently assume that following RAII will avoid most memory leaks.
Not all software needs meticulous careful human review. But I believe that the compounding cost of abstractions being lost and invariants being given up can be massive. I don't see any other way to attempt to maintain those other than human review or proven correctness.
I did suggest all code has bugs (up to some limit -- while I wasn't careful to specify this, as discussed above, there does exist an extraordinary level of caution and review that if used can approximate perfect bug-free code, as in your malloc example and in the example of NASA, but that standard is not currently applied to 99.9% of human-generated and human-reviewed code, and it doesn't need to be). I did not suggest anything else you said I suggested, so I'm not sure why you made those parts up.
"Not all software needs meticulous careful human review" is exactly the point. The question of exactly what software needs that kind of review is one whose answer I expect to change over the next 5-10 years. We are already at the point where it's so easy to produce small but highly non-trivial one-off applications that one needn't examine the code at all -- I completely agree with the above poster that we're rapidly discovering new examples of software development where output-verification is all you need, just like right now you don't hand-inspect the machine code generated by your compiler. The question is how far that will be able to go, and I don't think anybody really knows right now, except that we are not yet at the threshold. You keep bringing up examples where the stakes are "existential", but you're underestimating how much software development does not have anything close to existential stakes.
Does Taiwan not have healthcare? Verbatim from Wikipedia:
> According to the Numbeo Health Care Index in 2025, Taiwan has the best healthcare system in the world, scoring 86.5 out of 100,[6] a slight increase from 86 the previous year.[7] This marked the seventh consecutive year that Taiwan has ranked first in the Numbeo Health Care Index.[8]
It really depends on the engineer. I've seen some engineers in that exact position you describe, their job description says they influence the org broadly so that's what they set out to do. They struggle against a political and technical machine, vying for power, and trying to build a fiefdom.
Other engineers I've seen (a smaller sunset) have that job description more as an observation of their skills and influence. Their mandate isn't to influence, they just do. They are respected for their vast knowledge, historical success, and insight. So they naturally are heeded by most, and consequently they broadly influence the org.
Both cases sound miserable in their own way, but if I had to choose I'd much rather land in the latter. The latter still involves some politics, but at least it sounds like you're not wasting your life playing stupid games.
I actually don't mind that some people are good at influencing others, through well earned respect, good communication skills and technical chops.
I resent it when it becomes a mandate and some official "badge" in the career ladder. I'm suspicious of these principal/architect types who "parachute" out of nowhere into teams and projects, because it's "their mandate", ask lots of questions, mess with stuff, and then leave and don't take responsibility because "the team owns the project, not them". I've seldom seen this work well. A lot of teams end up politely ignoring what these types say, because they know if you're not a true stakeholder, what you're saying doesn't matter.
Aren't you effectively saying that no one will understand the code they're actually deploying? That's always true to an extent, but at least today you mostly understand the code in your sub area. If we're saying the future is AI + careful review, how am I going to have enough context to even do that review?
I expect that in most cases you'll review "hot spots" that AI itself identifies while trusting AI review for the majority of code. When you need to go deeper, I expect you'll have to essentially learn the code to fix it, in roughly the same way people will occasionally need to look at the compiler output to hunt down bugs.
Human trust has to be earned, why should AI trust be any different? If I’m supposed to yolo-approve any random code a machine spits out, it had better prove to me it’s nearly flawless, otherwise I’m applying the same review regiment I apply to any other code. To do otherwise is to shame the word “engineering” and the field thereof.
Engineering is a game of tradeoffs. Time is one of the things you have to trade off, given your strong opinions I expect this is something you've been in the industry long enough to understand intuitively.
Regarding proof, if you have contracts for your software write them up. Gherkin specs, api contracts, unit tests, etc. If you care about performance, add stress tests with SLOs. If you care about code organization create custom lint rules. There are so many ways to take yourself out of the loop rigorously so you can spend your time more efficiently.
This isn't really porn adopting ChatGPT, it's OpenAI allowing porn. There was nothing stopping Pornhub from releasing their own LLM. If porn became a feature gated behind YouTube Premium I would probably say "wow they really need customers huh".
I mean, there's very specific reasons either color gets support from their voters. I wouldn't say all of those reasons warrant the same amount of fervor, passion, and loyalty that they do. But "blind support" is a bit reductive when for some people it literally means their rights being stripped away.
What appears to be "blind support" is people desperately clinging onto what tiny bit of representation they have. It's sad for both sides. It's Stockholm syndrome mixed with political pragmatism. It sucks, but the current political landscape in the US has entrenched itself so deeply in a local minima that people feel like they have to work backwards to make progress. Just see how any discussion of a third party is seen as a psyop to get that side to have a spoiler effect.
As someone who typically supports a lot of third parties at the ballot box, I have to say that our problem is actually not people seeing us as a psy-op.
It's people seeing us as, at best, irrelevant; and at worst, a joke.
I've been voting since the late eighties, and have come to realize it is our lack of organization and, at times, our policies. Which in all honesty can be at once, foolish and bizarre.
It's difficult to bring the platforms of any new party in hand precisely because they are attracting people whose ideas are maybe not very popular in the mainstream parties. The mainstream parties have bizarre and foolish policies as well, but they've had 40 years to brainwash their voters. It's hard to have the same effect in, say, 2 or 4 years.
So you have to have a pristine platform and stick to it.
This is where as independents and third party supporters, we've repeatedly failed.
Voting third party in a first-past-the-post electoral system is a coordination problem. If I, as an individual, have some grab-bag of political stances, with varying weights of importance to me, it is likely that some issues will become a matter of "I am willing to cast my vote in any direction that minimizes the chances that someone with the opposing view does not take power". For example, for people who strongly oppose a backslide into Facism in the US, the only real choice in the last presidential election was voting Democrat, because while there might have been third party candidates that would have been better, the Dems were the most likely opposition to that to win. Absent extremely effective widespread coordination, a vote for a third party increases the probability of an unacceptable outcome.
Many people online share similar experiences. Wonder how much money this wide-scale fraud saves them.
reply