I am currently making a fair amount of my living helping out CEOs like this. The quick-sand that LLMs let non-engineers build overtime is pretty remarkable.
A project usually starts with a list of basic looking cosmetic bugs that the stakeholder is having a hard time getting Claude to fix. Literally every bug unearths a heap of other bugs or architectural problems.
As an example yesterday I was looking at a basic, “record XYZ not appearing on list view” bug. Turned out that Claude had built the list view (which should have been backed by thousands of records) to only ever load the first 100, and then do all organization, counts, sorting and filtering on the frontend on that dataset.
Also found a query that was taking ~18 seconds to query 1 record from a set of ~60.
These are very interesting anecdotes. The feeling I've been getting is that the inherent complexity in software hits people at prompt-time because they simply don't have the words to express what is needed. (edit: or don't have the knowledge/patience to interpret what the LLM spits out)
For most apps, delivery has been some equivalent of “git push heroku main” and setting a DNS record for like 15 years. That’s especially true for most of the apps being vibe coded today.
The fact that “cloud engineer” is still a job suggests that the simple case is not the one driving employment. There are definitely more devops/sre/cloud engineer roles today than there were in 2009 (and I’d be willing to wager you if you included pre-devops sysadmins in that count, there’d still be more total roles today).
I thought most modern Bluetooth devices essentially randomize the Bluetooth MAC address periodically, specifically to prevent this sort of tracking? And random MAC addresses too on WiFi.
If someone has a half dozen BT devices on their person/in their car and they randomize MACs hourly (but not all at once) I bet you could still track people pretty accurately.
I wonder how much that actually helps. A license plate scanner and a camera can easily identify me in my car. What tracking advantage does “there are three (probably) Apple devices” in the car as well confer.
If I’m away from my car later, I’m just a guy walking around with 3 Apple devices (or two if I forget my phone in the car).
> A license plate scanner and a camera can easily identify me in my car.
Sure, but now you can track someone from their car through public transport, shops and god knows wherever else someone placed a sniffer.
And no, randomization doesn't help, because in the end the Find My beacons have to resolve down to some common identifier otherwise the "an unknown device has been following you for 2 hours" warning would not work.
> in the end the Find My beacons have to resolve down to some common identifier otherwise the "an unknown device has been following you for 2 hours" warning would not work.
Not really, this is actually pretty easy. If such a device beacons and a trusted device is within range the trusted device can respond to the beacon and let it know it's nearby, then it just counts up if not. X number of beacons with no response, set the "not near my trusted device" flag. Some other device sees X number of beacons with that flag set while moving around, send alert to the user.
Doesn’t the Find My stalking tracking work by connecting the the randomized id back to a unique device on Apple’s servers?
So yeah, if they subponea/coerce Apple (or Apple signs up willingly) they could track people individually.
But at that point we’re no longer talking about large scale tracking by an untrusted third party. Apple and my phone company have always been able to track me without getting license plate scanners involved.
So that they can identify you and your friend ride together frequently and they need to make sure they can link you if you decide not to bring your work cell and AirPods to the “illegal” protest you rode with your friend to as part of your “domestic terror organization” since you and your friend also happened to go shooting at that gun range that one time for his birthday, and you were once in a Walmart with some other “co-conspirator”. The types of allegations that have already been used to smear citizens and officials alike. So yes, it is very helpful…to the “them”, not the “us”.
And all along, the people will say they had no idea what was really happening that they kept voting for, while deep down, they knew exactly what they were voting for and why. And that description doesn’t apply to a single party. If you disagree with either sides totalitarianism and their march toward it, you will eventually be branded and potentially arrested on whatever charge will prevent you from voting in the future. Or at least that’s how it goes any/everywhere else that has gone down that path. Hopefully cooler heads in both parties prevail. It always saddens me that the non-“decision makers” of both parties don’t just band together to get things done they both can agree on (which is a lot). There is a lot more people at the bottom than the top in those houses, yet they both willingly kiss the ring of their leaders.
> This is domain expertise - software engineers are not needed for that.
I want to work with the business domain experts you work with. The ones I’ve worked with are experts in their domain, not modeling that domain in software.
Left to their own devices with Claude Code, they produce some great POCs. Then those POCs buckle under their own weight they pile on contradicting requirements and have opus spinning to fix bugs.
Maybe the models will get good enough to solve for this, but they’re not there yet.
As in my reply to the sibling comment, I am not disputing that engineer expertise remains important; I'm saying the nature of it is now different and will continue to rapidly change in its place in the business stack.
Kind of interesting that LLMs are basically being sold as having “human-like” reasoning capabilities, but in this case when “obamawhitehouse” asked to have it’s password reset sent to bob12345667@gmail.com the LLM didn’t question it and just triggered the process that happened to have a bug.
Humans support agents certainly fall prey to social engineering all the time, but I can’t think of a case where it was done on this scale so easily.
> The One Big Beautiful Bill Act introduces Section 174A, which restores immediate deduction of domestic research and experimental expenditures starting in tax years beginning after December 31, 2024, reversing the controversial five-year amortization requirement that took effect in 2022.
> a flight attendant told passengers over the PA system that they "must turn off Bluetooth immediately," or else the aircraft would have to turn around.
So if the person just takes back their bomb threat everything is ok? Or did they think the terrorist labeled their Bluetooth bomb “bomb” and this would disable it?
4. A normal level of risk aversion in one of the most risk averse industries
If airlines ignored every threat that was “probably not” a real threat, they’d ignore all of them. It’s better to inconvenience a few thousand passengers than it is to kill a few hundred.
How many threats did actually turn out to be real to date? I couldn't find this being published. But how many threats did happen without any indication (only after the perpetrators tell). I can easily recalled maybe 3-4 incidents. So the issue here is do knowing threats really help?
You only hear the edge cases in the news. There are tens of thousands of incidents of unruly passengers some of which are just threats and some are actual violence.
But also, just because someone is making what could be perceived as a threat doesn’t mean it won’t escalate, which is why threats are taken seriously even if we don’t know whether something is guaranteed to go wrong. You don’t want a crazy person making bomb threats on a flight even if they don’t have a bomb, because they can inflict other issues while trapped in a metal tube at cruising altitude.
For example, there are many pieces of equipment that can be broken and they’ll still fly, because it’s not essential or there’s enough redundancy.
Child safety seats are not required even though they’d save lives, because the extra hassle and expense would cause some parents to drive instead, which is much more dangerous, leading to more overall deaths.
Normally the decisions are quite sensible. But the moment any “terrorism” enters the picture it all goes out the window.
No they wouldn't. A fundamental part of a threat is to make it very clear that there's a threat. The reason you threaten is to get some concession, otherwise you wouldn't bother threatening.
This is at odds with basically every major security incident postmortem in recent history.
Most security failures happen when people wait to take something seriously until it is “very clear” that something is wrong.
We have the luxury of hindsight while reading this article but listen to the tapes of any security failures and you’ll find it painfully obvious that the most common issue is that people don’t do anything until it’s too late.
The definition of threat that the rest of us are using, and the one that is relevant to airline security is:
"An indication of impending danger or harm."
Not "An expression of an intention to inflict pain, harm, or punishment."
Using the second definition in this context is absolutely bonkers -- a threat actor doesn't have to make a first-person expression of threat to be a threat.
A "security threat" refers to the former -- the situation.
It's also important to note that the situation was not taken seriously just because of the bluetooth device name -- but because it was not turned off even after all of the passengers were instructed to turn off all of their bluetooth devices. They were well aware that people are just stupid sometimes, but didn't take it seriously until it was done in defiance of crew commands.
In the simplest possible terms: this is total bullshit security theatre. At no point has there ever been a bomb or even a bomb threat carried out via usb device names. There is absolutely no reason to even look at the names of Bluetooth devices on a flight.
Without testing the null hypothesis that is not possible to determine. There doesn’t have to be an actual bomb for an unruly passenger to inflict injuries or death.
Why are people not reading the article!!!! It was a Fitbit. Best not to get news based on Reddit conjecture. It's wild how many people are running with the speaker thing.
Was wondering the same thing. Maybe there's some regulation about this, but the flight crew wanted to bend the rule to keep the plane going, figuring it was just a poorly named device.
This is wildly inaccurate to the point of being dangerous advice. The goal during a bomb threat call is generally not to challenge, mock, or provoke the caller into a reaction. It is to keep the caller talking for as long as possible and gather information that could help assess the threat and assist law enforcement or security. There is no reliable rule that says a "real terrorist" will hang up if laughed at or that a hoax caller will stay on the line. People making threats behave in many different ways and simplistic tests like this are not a dependable way to determine whether a threat is real.
I was talking about this with someone the other day… How many real terrorism threats have been preceded by the terrorist telegraphing their intentions with a phone call beforehand? My prior is that this number is essentially 0 and we should ignore bomb threats as a society.
Probably not super common but it does happen from time to time.
And imagine ignoring a bomb threat and then it's real, you probably would not want to be responsible for that.
The Weather Underground often warned the targets of their bombings via phone call. (I guess their goal was to attack gov't institutions and make a political statement, not to kill lots of people.) This was in the late '60s-'70s.
The IRA (Irish terrorists, for Americans confused at the acronym, or maybe confused at what the IRA did) did occasionally phone warnings and occasionally the information was accurate. Code words were used to authenticate the threat.
The PIRA actually do seem to have intended to give accurate warnings when they planted bombs, in Belfast at least. There were inevitably cases when the information was garbled or misunderstood but the use of codewords & the practice of delivering the warnings to a known set of media outlets was at least an attempt to minimise these.
The downside was that the vast majority of warnings were hoaxes - bomb scares were dozens of times more common than actual bombs.
The other main groups - INLA, UVF, and UFF/UDA also got in on the hoax game, but didn't often do real bombs (and didn't always give proper warnings when they did - see the UVF's Dublin & Monaghan bombings for a particularly grim example).
But real bombs were just common enough that the hoaxes from whatever source had to be taken seriously and so they caused huge amounts of disruption, probably more than anything that actually exploded.
Logically that probably makes sense, but it would require everyone in the chain of command agreeing to that policy, and there’s no way that would ever happen from a liability standpoint.
It sounds like you have tailscale setup in the container with userspace networking — which works smoothly for incoming traffic, but for outgoing traffic to use the container’s tailscale device it has to be routed through a proxy that tailscaled runs, otherwise it goes over the host’s network.
I haven’t tried with orbstack, but it is possible to setup containers to use tailscale with kernel networking by mounting /dev/net/tun into the container. With that setup outgoing traffic will automatically route to the tailnet as the container’s device (and you don’t need tailscale on the host at all).
SVB didn't get bailed out, their investors and creditors were wiped out. You could argue depositors were bailed out -- as they took the undue risk of keeping more than $250k in a single bank (though as part of a requirement for getting a loan from SVB, you had to have your operating accounts with them. So lots of companies had no choice, as SVB was one of the few banks that would lend to them).
Arguably, the main impact of securing SVB depositors above the $250k limit is that it prevented thousands of people from being laid off that week, as their employers wouldn't have had the money to make payroll the following Wednesday.
Thank you for saying this. Continuing to point at SVB as a bailout is annoying. They were not bailed out. Anyone with deposits in an accredited bank should be made whole - always. Without trusted banking we have no economy.
> Anyone with deposits in an accredited bank should be made whole - always
Sure, but is that the case now? Is everyone made whole when a bank fails and they have more deposits than the insurance limits? Or only when it's the well-connected / too-big-to-fail?
So I don't think it's unreasonable to describe SVB as a bailout. Not for the investors, but for the depositors. Has anything changed to reduce the moral hazard / make it less likely to recur?
So we all now know that a bailout DID occur with the SVB depositors who had all their money in the bank and most deposits were over the FDIC insurance limit. The FDIC insurance rules somehow didn't apply here because there was too much money at risk. (And too big to fail).
But if there was a bank failure at a regionally smaller bank with a regular customer or startup depositing the same amount of money over the insurance limit, their money is gone.
Just like Intel got a "bailout" from investment as chosen by the US government, AI will eventually have a very similar story.
In early 2023, within the span of two months, the United States
experienced three out of the four largest commercial bank failures in
U.S. history, as Signature Bank, Silicon Valley Bank, and First Republic
Bank all toppled.1 Yet, despite these banks having roughly $300 billion in
uninsured deposits at the time of their failures2 and despite the failures
costing the Deposit Insurance Fund (DIF) of the Federal Deposit
Insurance Corporation (FDIC) an estimated $38 billion, uninsured
depositors took no losses in any of the failures.3 While these results were
striking, they were far from unusual. Since 2008, uninsured depositors
have experienced losses in only 6% of total U.S. bank failures.
...
Formally,
the United States caps deposit insurance at $250,000 per account,6 but,
in reality, the post-2008 financial system comes close to providing de
facto total deposit insurance covering all amounts in all accounts.
A project usually starts with a list of basic looking cosmetic bugs that the stakeholder is having a hard time getting Claude to fix. Literally every bug unearths a heap of other bugs or architectural problems.
As an example yesterday I was looking at a basic, “record XYZ not appearing on list view” bug. Turned out that Claude had built the list view (which should have been backed by thousands of records) to only ever load the first 100, and then do all organization, counts, sorting and filtering on the frontend on that dataset.
Also found a query that was taking ~18 seconds to query 1 record from a set of ~60.
reply