Having had Claude Code jump to inserting juvenile and all-filtering regex to (attempt to) solve open-ended semantic natural language problems (-sigh- there's 12 hours of my life I'll never get back), I can absolutely imagine that this was someone trying to code up a "defense in depth" mechanic that was explosively insufficient after Claude Code (even Opus 4.6) made a series of faulty assumptions.
This one feels like prime space for Hanlon's razor: "Never attribute to malice that which is adequately explained by stupidity."
The hassle with the performance of these systems is that they're ~70% of the way to awesome. For advanced prototyping (my current job description), a fast 60% of awesome is groundbreaking and game-changing. For production and real businesses, that last 30% is a really, really important thing to figure out.
I was under the impression that insider influence was the point of these systems? Want something to happen? Bet a lot of money that it won't, pulling the market forces towards the action you want.
It goes from "taking out a hit" to "betting that someone will live to next Thursday". It's such an obvious outcome of these systems that I was operating on the assumption that it was the actual point.
So maybe the thing this guy did wrong was to be so face-palmingly pants-on-head obvious about it that they had to shut it down?
Which is also horrifying if you think about it for more than a second.
"Want something to happen? Bet a lot of money that it won't" goes both ways. "Want to make money and have power over missile systems? Bet, and then make something happen."
“Super markets trade money for food. An obvious outcome is that someone without money will shoot the employees to steal food. Therefore the purpose of supermarkets is to facilitate murder”
Less so "supermarkets" specifically and moreso "capitalism" and the answers to your conclusion is obviously, yes.
This is why welfare systems exist. Because otherwise the system will push people to crime, especially so in our current implementation of Capitalism where it is possible to become unemployed/unemployable through no fault of one's own.
I think this is, more often, that we are spending too much time pretending to communicate. Far too often I've found myself in a meeting that doesn't have a quorum, but people try to have the meeting anyway. Even more often than that, I've found myself in a meeting that doesn't have the sufficient pre-requisites to be useful. It will just be some AI slop document dropped in front of folks, with little to no regard for coherent thought or responsibility. It's 30 minutes of gaslighting the readers, trying to make them feel stupid for "not getting it", followed by 10 minutes of "this meeting was a waste of time" course-correction (we read our docs in the beginning of meetings).
And the problem is that the communication (or alignment) is the thing that the meeting is supposed to be about, sharing well-considered thoughts and cohesive direction, soliciting meaningful feedback against clearly-articulated assertions. Instead, we're all-to-often addressing someone's attempt to turn their job into a group project, the stone soup of the modern business world. You can lay this bare by asking "what is the aim of this meeting?" early on, to level-set that the meeting owner isn't just setting up a study group.
Birds-eye-view-only managers only see work get done in meetings, so they assume that the meeting is where the work gets done. They don't understand all of the work that went into what came before the meeting to make it a successful one. If you rush the "communication" before you've found the clarity of thought, your meeting is just noise.
There's a simple but powerful response to this sort of persistent malaise, one that strikes fear in the hearts of the secretly inept: "I don't know, but let's figure it out right now."
When it's time to slow down and walk through the problem, I hold folks to an ordering of dependency: Why, What, How, Who, When... If you don't know all of the things before (e.g., Why, What, How - if you're trying to figure out Who), you cannot proceed. I don't care if you're an intern or a VP. No short-cuts to bullshit hand-wavy answers.
Decompose the problem, do the thinking, reason through it right there, and, if the team doesn't change its behavior, find another team. In the right environment, some folks are willing and able to step up to the plate and act like grown-ups working together to craft something better. Sadly, quite a few can't (or won't) answer the call to be responsible adults.
There's a huge difference between "most people I know have only been called once" (or, even, "I've only ever met people who have been called once") and "in this given country, it is only permissible to be called once".
Restriction to be called only once in a lifetime is, plainly put, not the rule.
Not quite. It's basically a combined mantissa and exponent test, so it can be thought of as functionally equivalent to scaling epsilon by a power of two (the shared exponent of the nearly equal floating point values) and then using that epsilon.
I think I'll just use scaled epsilon... though I've gotten lots of performance wins out of direct bitwise trickery with floats (e.g., fast rounding with mantissa normalization and casting).
The executive has the veto and a willingness to leave the government non-functional (funny how anti-government types are often okay with kneecapping government). They're not powerless.
From my experience with modern software and services, the actual practice of QA has plainly atrophied.
In my first gig (~30 years ago), QA could hold up a release even if our CTO and President were breathing down their necks, and every SDE bug-hunted hard throughout the programs.
Now QA (if they even exist) are forced to punt thousands of issues and live with inertial debt. Devs are hostile to QA and reject responsibility constantly.
Back to the OP, these things aren't calculable, but they'll kill businesses every time.
that's not the role of QA to be a gatekeeper, they give the CTO and President information on the bugs and testing but it's a business decision to ship or not
I’m not a native English speaker, but isn’t gatekeeping exactly that? Blocking suspicious entities unless they’re allowed through by someone higher in the hierarchy?
Shooting down ideas is absolutely a skill, and it's essential to driving out the mountains of slop people throw out these days.
However, the essential thing to do is to make sure that you're not shooting down the person. Better still, if you can socratically get them to the point of understanding why their idea won't work, that will have them own the shoot-down, and it may lead to a better idea that addresses the actual problem set more effectively.
When you know why something won't work, get other people there, but do it without being a jerk or crushing in inventive spirit.
I've been leading advanced development and applied science teams for decades. There aren't enough hours in the week to give every idea someone brings to me a full watch-them-realize shake, but I can (and do) take the time to make sure that the next time they have an interesting idea, they still want to bring it up.
Shooting down ideas is absolutely a skill; one that every innovator needs to have for their own ideas and the ideas of their collaborators. The way I learned it was to have others shoot my ideas down, and that's the way I teach it.
I like that angle a lot, and this very thoughtful comment. Distinguishing between the idea and the person is a good way to think about it. I think sometimes people cross that line without realizing it. Your point about making sure people still want to bring ideas next time is really what it comes down to.
I've joked that the 16oz US pint was a long-play metric-system scheme to drive adoption of 500ml (~16.9oz) as a measure, a Pavlovian mechanic to trick beer-drinking Americans that the metric system is actually better because it results in more beer. The joke's on them. We're all about 12oz cans! 33cl? pfft...
Germans have it nailed down with the Kölsch Stange, a 200ml glass that so readily disappears that it stays cold and you just get another from the Kranz.
Nerds solving interesting problems find a way. Folks (myself included) worked on Privacy Pass for verifiable ad attestation, but the power of blinded attestation is meaningful in ways beyond advertising authenticity validation.
For folks at the implementation level, the problem is often the prize. I just need to get paid enough to not care about how much I get paid. And implicitly contributing to social good is a form of gamification that works well. I've encountered lots of folks who operate in the same way. Yes, we're paying a bit more of a "feed the beast" tax than the good old days, but we're still able to operate with a remarkable degree of latitude.
This one feels like prime space for Hanlon's razor: "Never attribute to malice that which is adequately explained by stupidity."
The hassle with the performance of these systems is that they're ~70% of the way to awesome. For advanced prototyping (my current job description), a fast 60% of awesome is groundbreaking and game-changing. For production and real businesses, that last 30% is a really, really important thing to figure out.
reply