Honestly - the video barely touches on this at all, despite making it the "hook".
I was pretty disappointed that he doesn't discuss the EMAS mechanics, structure, actual stopping distance, or impact to the plane in nearly any real way.
He does show a LOT of animation of layered runways, which are mostly not that informative.
There is some decent discussion around maintenance and material choice, and some very basic discussion of infrastructure requirements outside of the runways themselves that's... ok.
Overall... I thought this was a solid C+ video. It shows planes plowing into an EMAS, then does jack all to discuss that, while bringing up a lot of less interesting discussion of runway building (which despite the claims in the video, do actually correspond very highly to how we build highways, just with different weight/maintenance requirements.)
I don’t think anything you said is wrong, but I do think you’re misreading the intent of the channel.
Practical Engineering is very deliberately framed as edutainment. The animations, pacing, and level of depth are conscious choices meant to keep non-specialists engaged rather than to maximize technical rigor.
In that sense, it belongs alongside other popular "science-y" channels like Kurzgesagt, Vsauce, and Technology Connections: content that prioritizes narrative and engagement over completeness or instruction.
The target audience is the broad middle of the technical bell curve. Animations of runway layers may make the video less appealing to you, but more accessible to a much larger, less technical audience.
Different goals imply different success criteria. If the goal is reach rather than comprehensive education, a million views in seven days looks like success.
Enough energy to run that thing for an entire year in under 1/2 a gallon of gasoline.
When you can pretty easily offset the entire yearly energy use by skipping a mow of your yard once, or even just driving slightly more conservatively for a few days... I'm not so worried about the power use.
In my region - it's about $3.50 in yearly power costs.
I have a wonderful cargo bike (urban arrow - splurge purchase for my 35th birthday and second kid) - I use it for most in-city transportation tasks, including picking up kids from daycare/school, groceries, trips to restaurants, etc.
I also have a 2011 truck with ~200k miles on it. It's well take care of, and shows no signs of stopping any time soon. It hauls stuff from home improvement stores, help family move, and takes us on vacation.
I've been debating getting bumper stickers for each of them along the lines of:
Not typing every line of code myself doesn't divorce me from the construction.
I frequently find that the code I write using agents is better code, because small improvements no longer cost me velocity or time. If I think "huh, I should really have used a different pattern for that but it's already in 100+ places around the codebase" fixing it used to be a big decision... now it's a prompt.
None of my APIs lack interactive debugging tools any more. Everything that needs documentation is documented. I'm much less likely to take on technical debt - you take that on when fixing it would cost more time than you have available, but those constraints have changed for me.
But... that's exactly the kind of thing I'm referring to.
You're blanket replacing chunks of code without actually considering the context of each one.
Personally - I still have mixed feelings about it. The Hyatt Regency walkway was literally one of the examples brought up in my engineering classes about the risks of doing "simple pattern changes". I'm not referencing it out of thin air...
---
Havens Steel Company had manufactured the rods, and the company objected that the whole rod below the fourth floor would have to be threaded in order to screw on the nuts to hold the fourth-floor walkway in place. These threads would be subject to damage as the fourth-floor structure was hoisted into place. Havens Steel proposed that two separate and offset sets of rods be used: the first set suspending the fourth-floor walkway from the ceiling, and the second set suspending the second-floor walkway from the fourth-floor walkway.[22]
This design change would be fatal. In the original design, the beams of the fourth-floor walkway had to support the weight of the fourth-floor walkway, with the weight of the second-floor walkway supported completely by the rods. In the revised design, however, the fourth-floor beams supported both the fourth- and second-floor walkways, but were strong enough for 30% of that load.
---
Just use a different pattern? In this case, the steel company also believed it was a quick pattern improvement... they avoided a complex installation issue with threaded rods. Too bad it killed some 114 people.
But I am considering the context of each one. It's just quicker not to modify the code by hand.
I'm going to use a human comparison here, even though I try to avoid them. It's like having a team of interns who you explain the refactoring to, send them off to help get it done and review their work at the end.
If the interns are screwing it up you notice and update your instructions to them so they can try again.
I guess. And I don't mean that as a jab at you, I read a lot of your content and agree with quite a bit of it - I'm just personally conflicted here still.
I've worked in a couple positions where the software I've written does actually deal directly with the physical safety of people (medical, aviation, defense) - which I know is rare for a lot of folks here.
Applying that line of thinking to those positions... I find it makes me a tad itchy.
I think there's a lot of software where I don't really mind much (ex - almost every SaaS service under the sun, most consumer grade software, etc).
And I'm absolutely using these tools in those positions - so I'm not really judging that. I'm just wondering if there's a line we should be considering somewhere here.
I've avoided working directly on safety critical software throughout my career because the idea that my mistakes could hurt people frightens me.
I genuinely feel less nervous about working on those categories of software if I can bring coding agents along for the ride, because I'm confident I can use those tools to help me write software that's safer and less likely to have critical bugs.
Armed with coding agents I can get to 100% test coverage, and perform things like fuzz testing, and get second and third opinions on designs, and have conversations about failure patterns that I may not personally have considered.
For me, coding agents represent the ability for me to use techniques that were previously constrained by my time. I get more time now.
I share your concern. I'm flummoxed by the prevalent sentiment that code is the nasty underbelly of software. To me, a programming language is a medium both for precisely directing a computer's behavior and for precisely communicating a process to fellow programmers (cue the Alan Perlis quote [1].)
I will concede that mainstream code is often characterized by excessive verbosity and boilerplate. This I attribute to the immaturity of today's crop of programming languages. Techniques like language-oriented-programming [2] hint at a path I find appealing: DSLs that are tailored to the problem while promising more precision than a natural language specification could.
To speculate, I could see LLMs helping during the creation of a DSL (surfacing limitations in the DSL's design) and when adding features to a DSL, to help migrate code written in the old version to the new one.
Perhaps DSLs aren't the future. However will there be as much interest in designing new and superior programming languages now that code is seen as little more than assembly language?
No, I don't think so. But my context is different as is anyone's reply about their LLM usage.
I'm still creating software but with English that's compiled down to some other language.
I'm personally comfortable reading code in many languages. That means I'm able (hopefully!) to spot something that doesn't look quite right. I don't have to be the one pressing keys on the keyboard but I'm still accountable for the code i compile and submit.
Yeah, but he can't use his $200 subscription for the API.
That's limited to accessing the models through code/desktop/mobile.
And while I'm also using their subscriptions because of the cost savings vs direct access, having the subscription be considerably cheaper than the usage billing rings all sorts of alarm bells that it won't last.
It sounds like they're trying to extract as much money as possible from a SaaS subscription service that's no longer actually paying any devs.
From my perspective as a one-time (but no longer) paying user of evernote - WTF am I paying for monthly if not to support a dev team?
Seriously - I get that there are infra costs for some of the services, and I wouldn't mind paying those costs plus a reasonable upcharge, but I'm sure as fuck not going to pay a company $100+ a year subscription to store under a GB of data.
So now I host bookstack and I pay backblaze ~$0.22/m to back up all my notes, which is much closer to real costs for these services if they're not under development.
Genuine question, why not use a free Git service or something
I pay for Sourcehut now, but until recently I was using a free private GitHub account to sync my notes in Obsidian. It works fine and cost me nothing (at least nominally).
The honest answer is because I backup a large number of other things to backblaze anyways.
I went on a mission about 5 years ago to essentially stop paying for SaaS services if there was an opensource alternative available that I could self host.
I have old machines lying around anyways since I was upgrading about every 5 years for gaming. So I have a 5 node k8s cluster in my basement serving about 20 different services that I use, and I no longer pay for basically any subscription software.
Git is fine for text content, (hell, I have about 25 personal repos on github anyways, although speaking of... most are mirrored to a local gitea instance) but it's not a great solution for backing up DBs, binary data, media, photos, etc...
Eventually - I'll likely replace backblaze with a NAS at a family member's house, but for now - it's very cheap and the billing is fair (usage based billing, not the exorbitant monthly fees most SaaS services charge).
---
Plus - I really like the flexibility of web based services. I don't have to remember to sync anything with bookstack, I just hit 'https://bookstack.[mydomain]' in a browser from any machine I want - Friends house? works. Public library? works. Wife's phone? works. Work laptop? works. etc... you get the idea.
Even after accounting for the initial outlay for a large NAS and my extra power consumption - I broke even in just under 3 years self hosting. Turns out SaaS is sorta a scam if you're technically capable.
And absolutely more power to ya for finding your own alternative solution!
Your linked page doesn't actually appear to render any sort of compelling argument for this.
In fact - the entire argument seems to more accurately hinge the conditional left off the main saying, so the full description is:
"Bad money drives out good if they exchange for the same price."
But that requires a legal structure that enforces the disparity, and the summary of the whole thing basically boils down to:
---
If given the choice of what money to accept, people will accept the money they believe to be of highest long-term value and not accept what they believe to be of low long-term value. If not given the choice and required to accept all money, good and bad, they will tend to keep the money of greater perceived value in their own possession and pass the bad money to others.
---
But if anything - this is exactly an argument for the value of soft power to the US, because we can't enforce how other nations transact, except through soft power.
In practice, everyone wants to spend their dollars, not their gold, or their bitcoin, or their Euros, and so dollars it will be. What else is there that anyone both with pay with and will be accepted by the other party?
Again - you skip the full statement of the economic principle at hand.
No one cares that everyone wants to spend their dollars. They care whether the seller takes them, and is forced to take them at the same value as more cherished coin.
There is no functional mechanism to enforce this internationally - we already see the value of the dollar declining.
It's entrenched, so I expect the withdrawal to be relatively slow for the same reason you don't rip the bandaid off - you avoid a lot of pain. But there is nothing stopping the bandaid from coming off.
> you skip the full statement of the economic principle at hand.
Hence "In practice".
To the meat of your argument: sure, there's no mechanism to coerce it internationally, but it's self-perpetuating. Everybody could quit using dollars tomorrow. But they won't.
> we already see the value of the dollar declining.
This is not clearly the case. Its value relative to other currencies (as of this month), while subject to cyclical fluctuations, is on par for the post-Covid cycles and higher than pre-2020 levels [0].
Soon dollars might not be accepted if US companies wants to buy things in the EU, they will have to pay in euros (part of the anti coercion instrument that Macron and others have been talking about the last couple of days)
I don't think it will happen. 10% of EU bank loans that are dollar-denominated [0]. If they cut the flow of dollars into the EU, the debtors of those loans would wind up offering a premium for their goods and services to non-US companies, making them uncompetitive. It would be a roundabout tariff that would hurt the EU countries too much.
I'm struggling to see how this resolves the problem the author has. I still think there's value in this approach, but it feels to be in the same thrust as the built in controls that already exist in claude code.
The problem with this approach (unless I'm misunderstanding - entirely possible!) is that it still blocks the agent on the first need for approval.
What I think most folks actually want (or at least what I want) is to allow the agent to explore a space, including exploring possible dead ends that require permissions/access, without stopping until the task is finished.
So if the agent is trying to "fix a server" it might suggest installing or removing a package. That suggestion blocks future progress.
Until a human comes in and says "yes - do it" or "no - try X instead" it will sit there doing nothing.
If instead it can just proceed, observe that the package doesn't resolve the issue, and continue exploring other solutions immediately, you save a whole lot of time.
You're right that blocking on every operation would defeat the purpose! Shannot is able to auto-approve safe operations for this reason (e.g. read-only, immutable)
So the agent can freely explore, check logs, list files, inspect service status. It only blocks when it wants to change something (install a package, write a config, restart a service).
Also worth noting: Shannot operates on entire scripts, not individual commands. The agent writes a complete program, the sandbox captures everything it wants to do during a dry run, then you review the whole batch at once. Claude Code's built-in controls interrupt at each command whereas Shannot interrupts once per script with a full picture of intent.
That said, you're pointing at a real limitation: if the fix genuinely requires a write to test a hypothesis, you're back to blocking. The agent can't speculatively install a package, observe it didn't help, and roll back autonomously.
For that use case, the OP's VM approach is probably better. Shannot is more suited to cases where you want changes applied to the real system but reviewed first.
Definitely food for thought though. A combined approach might be the right answer. VM/scratch space where the agent can freely test hypotheses, then human-in-the-loop to apply those conclusions to production systems.
yeah, I think the combo approach definitely has the most appeal:
- Spin up a vm with an image of the real target device.
- Let the agent act freely in the vm until the task is resolved, but capture and record all dangerous actions
- Review & replay those actions on the real machine
My issue is that for any real task, an agent without feedback mechanisms is essentially worthless. You have to have some sort of structured "this is what success looks like, here's how you check" target for it. A human in the loop can act as that feedback, which is in line with how claude code works by default (you define success by approving actions and giving feedback on status), but requiring a human in the loop also slows it down a bunch - you can end up ping-ponging between terminals trying to approve actions and review the current status.
Mmm, as someone forced to write a lot of last minute demos for a startup right out of school that ended up raising ~100MM, there's a fair bit of wiggle room in "Functional".
Not that I would excuse Cursor if they're fudging this either - My opinion is that a large part of the growing skepticism and general disillusionment that permeates among engineers in the industry (ex - the jokes about exiting tech to be a farmer or carpenter, or things like https://imgur.com/6wbgy2L) comes from seeing first hand that being misleading, abusive, or outright lying are often rewarded quite well, and it's not a particularly new phenomenon.
The worst of them are literal mockups of a feature in the same vein as figma... a screenshot with a hotzone that when clicked shows another screenshot that implies a thing was done, when no such thing was done.
I'm one of those people - I find any "in-ear" headphone/earbud to be outrageously uncomfortable.
Great news - there are a TON of alternatives! You're still an asshat if you play loud music without regard for your surroundings.
My personal pick? Get a bone conduction headset (ex: Shokz or cheaper alternative). Comfortable, lightweight, waterproof, you can still hear your surroundings.
Same problem with anything in-ear. I have two pairs of Shokz that I use for work (OpenComm) and play (OpenRun). I thought they would be a gimmick, but 3 years later, I love them and use them daily.
Fun hack: when I travel I prefer my over-ear noise cancelling Ankers, but they're bulky. So, for traveling light, I use Shockz and then silicone ear plugs to block out external sound on e.g. the airplane. Creates a little bit of a "swimming pool" effect acoustically, but works well and is tiny to carry.
I have a Shokz brand two-piece headset (the OpenFit 2+ i think?) that just wraps around the outside of the ear, with the actual speaker part held just outside the ear canal. I can't do in-ear buds either, but these just work for me. Doesn't even feel like anything's there.
I did try their bone-conduction headphones, but the quality was slightly worse and they didn't feel as nonexistent to wear.
I've been using a Shokz pair of headphones off and on for around 5 years and while they're great indoors I wouldn't really recommend them outside. Due to the city noise you'll probably tend to crank the volume pretty high (without realizing) and give yourself hearing damage over time.
I was pretty disappointed that he doesn't discuss the EMAS mechanics, structure, actual stopping distance, or impact to the plane in nearly any real way.
He does show a LOT of animation of layered runways, which are mostly not that informative.
There is some decent discussion around maintenance and material choice, and some very basic discussion of infrastructure requirements outside of the runways themselves that's... ok.
Overall... I thought this was a solid C+ video. It shows planes plowing into an EMAS, then does jack all to discuss that, while bringing up a lot of less interesting discussion of runway building (which despite the claims in the video, do actually correspond very highly to how we build highways, just with different weight/maintenance requirements.)
reply