This is a great example. Aviation is a perfect industry to learn from, they figured out a lot of things about how to keep humans from making mistakes. While complexity increases and automation takes away more and more tasks.
The same way erlang is good example of how to run a highly available system with hot reload and observability and stuff. There is cost for that too.
Maybe not all of the projects need the same properties. I'm fine if some of the stuff is having scheduled or unscheduled maintenance. Some kind of government portal that I use once a year had my permission to be offline between 0300 and 0500 and then again after 1200.
Being able to ensure all of the test run freakishly fast async is a huge win too.
The BEAM runtime is the real win. Your options are Erlang, Elixir and Gleam to get the BEAM.
Out of the 3, I prefer Elixir and Jose is a brilliant leader for it.
The combination of lightweight processes with their own HEAP and the preemptive scheduler means that millions of processes can run on the same machine with consistent execution time, no GC pause, and no worry that a single resource heavy process is going to slow down everything else.
The balance tradeoffs allows you to do a lot of things that would otherwise be poor architectural choices.
LiveView is just one example, where you’re able to completely forgo the need for a frontend framework but get all of the same benefits with lightning fast execution times.
There’s a lot of wins that come from it.
From a AI standpoint, functional code is simpler to trace and maintain because the AI doesn’t have to worry about side effects.
The HA perks are a bonus.
"Security is for losers"
> Andy Yen, the CEO of Proton, had a message for an employee in the company’s security Slack channel who urged the company to at least take a few days to pentest newly written code before pushing it live. “That’s bullshit and loser thinking. Of course it’s possible to be fast and secure,” Yen wrote in the channel at the end of August. “Stop thinking always of how to be slower, and focus more on how to be faster.” In a follow-up message, Yen reiterated his point: “only losers think like that.” His ultimate message for the team was to “stop lovingly handcrafting all our code and use AI more.”
Proton CEO Andy Yen: "This will be the last year that we hire engineers." - https://news.ycombinator.com/item?id=50295112 - October 2026
Manifestos, Fear, and 'Loser Thinking': Inside Proton's AI Reckoning - https://news.ycombinator.com/item?id=50289692 - October 2026
Good luck.
Edit: There appears to be some consequences for acting like this and those actions being made public.
Proton's CEO Cancels AI 'Re-Interviews' - https://news.ycombinator.com/item?id=50307183 - October 2026
Charlie Munger once said, "Show me the incentives, and I'll show you the outcomes." There are very, very, very few actual incentives to operate a real infosec effort at most companies. Think about it: how many companies have you heard of going out-of-business because of breaches? If you're like most Americans, you've probably received at least one letter from some company you did business with telling you that their systems were compromised and your data may or may not have been stolen as a result. They'll usually close out the letter with an offer of free credit monitoring for some finite length of time. Since that's useless and a lawsuit is a pain in the ass with no guarantee of benefit, the vast majority of people simply sigh and toss the letter in the trash.
There's no real way to pin identity theft or other consequences on a given data breach, so it's hard to make any sort of claim that way.
At the end of the day, the company has saved money by not instituting best InfoSec practices and red-teaming their software on a routine basis. There are no civil or criminal penalties for them not doing so.
So they don't.
Now in some countries those with data security office role have more to worry about than only losing their job, if they sign off on something that isn't qualified to be out there in first place.
https://germancomplianceinstitute.com/blogs/news/personal-li...
Homer: “There’s three ways to do things. The right way, the wrong way, and the Max Power way!
Lisa: "Isn’t that also the wrong way?"
Homer: "Yeah, but... faster.”
Says who? For what purpose? To whose benefit?
I want my encrypted email company to move slow, deliberately, and very carefully.
I'd like most software in general to move slower. Some, I'd like to not move at all. I hate churn for churn's sake, or piling useless features just so you pretend you did something to justify your subscription pricing, both of which were already the norm before AI and are worse now.
To speak in Apple terms, we don't miss more and faster crap novelties. We miss the Snow Leopard releases.
The trouble is that executives are bonused on much shorter time scales, and they run the company.
No, not necessarily. Sometimes, yes. For anything important, the last thing I want is a company that's moving too fast.
An email company? The base protocol RFC was written in the 70s. It's as mature as computer technology gets. There is zero value in moving fast here, all the value is in building an absolutely rock solid and secure solution.
The very opposite of move fast and break things.
Tone deaf award of the decade surely goes to that guy.
If it were some social game app or something, I guess it wouldn't be as tragic, but for a company whose sole reason to exist is to provide security... wow. Goodbye any trust ever again.
Either he's been like this the entire time, trying to crack the whip and failing, and thus a bad leader who has repeatedly failed to get results, or he's (as his employees have said) very deep in AI Psychosis and completely abandoned his principles.
It doesn't matter which it is, they're both extremely damning for the company and his leadership.
As if that's a problem? I want them to be my fucking encrypted email. Not a calendar. Not a backup. Not a VPN. And they've already stretched to all kinds of shit.
My point is they announced they’d ship a calendar in 2019 and it took 2 years to ship a full release and 3 to ship an iOS app.
It also sort of sucks, and in 2024 (year 5) they announced they’re rebuilding it. The rebuild partially shipped in 2026.
For a guy suddenly obsessed with speed these timelines are even more absurd.
"Any man who must say 'I am the king' is no true king." The measure is not who you can bully and denigrate successfully, but who will follow you to hell.
And whose idea of a strong man is this? I don't think many people would follow Putin to hell willingly, or that he accepts any criticism, or accept being challenged on his ideas. But he could be called a "strong man", at least the kind of "strong man" some people aspire to be.
Patrick Stewart taught us what good men do with power - https://news.ycombinator.com/item?id=50327650 - November 2026
You can also read about people talking about this in the super-early computer user communities. When you had to be a bit crazy to even be interested in computers you ended up with people who were outliers in a lot of other ways too. As more people came in to the space it would regress to the mean... this is one of the things that "regression to the mean" can be regressing from.
Social contagion [0] (not to be confused for memetics [1]) involves behaviour, emotions, or conditions spreading spontaneously through a group or network. [...] Throughout history all social contagions have had a single thing in common: the people who follow them genuinely believe their group is only doing positive effects, and cannot rationalize negative effects from within their group.
Tech executives are a group (and a network), its not some "regression to the mean" its common human social behaviour within group dynamics. It's not just those two there has been a progressive slide of executives joining the 'tech-bro' subgroup.
I'd also suggest that companies being so blasé is a direct result of lacking regulation. If there was no laws about aviation safety I bet we'd have more airlines with lax safety standards and more accidents.
Because humans were, loosely speaking, careful about not making egregious security mistakes, most security vulnerabilities turned out to be either harmless or the result of a programming language allowing the type of exploit to begin with.
But now we have code from non-people ordered by people who both don't care about security at all.
That means you will get maximally bad security outcomes which in turn will make governments consider regulating the software development industry. They are speed running their own demise.
Mmmmm... I think I may have to score this particular point for the CEO. Lovingly handcrafted code has been many things over the past 30 years, but "secure" is not one of the adjectives I'd apply to it. Anyone who thinks that the lovingly handcrafted code has always just been wonderfully secure needs to check the tint on their glasses.
A proper AI setup probably can produce more secure code more quickly than conventional development processes... however one of the keys will be to understand that yes, that will still be slower than writing code that is not rather carefully analyzed for security and a company like Proton had better have a strong commitment to never, ever skipping that step because it's slowing them down or it got expensive. "Proper" in "proper AI setup" is the most important word.
But that's not to say that I'm endorsing everything else he said. Even if it is true that companies will be able to stop hiring engineers, which at the moment I seriously doubt [1], a company like Proton should expect to be one of the last companies who can do that, not be getting publicly excited about it first. Hey we dumped all our engineers because our managers can just prompt our AIs just as well here in October 2026 would definitely be a "instantly cancel any Proton services I had" signal for me.
[1]: One of the things I don't expect to change is that there are plenty of people I would describe my actual day-to-day work to and they would consider it a living hell if they had to do it. I still quite enjoy it overall. And there are plenty of jobs that other people love and I would consider a living hell. Even in 25 years that's going to be the case. There will be people willing to put up with the process of working with the system to create this stuff... but the people who are willing to be professional about this, do the QA, do the work beyond the first fun prompts, is going to be a minority, and an even smaller minority who take the time to get good at it. There will always be people who are better and people who are worse.
Of course, AI reviewers and security tools will catch some security errors, but this should come as an addition to a proper security design, not instead of it.
Lol, brave words in an age of $6B heists and major CVEs every week.
Jokes aside, you can’t get anywhere near zero fault unless to impose strict operating regulations , requirements and procedures and regular checks… just like in aviation.
And even there, boeing manages to fuck it up somehow.
At the appropriate and necessary cost.
A less costly new engine design or less costly engine swap procedure that fails is worse than no airplane at all. If it's cheaper and fails, we don't want it. It wasn't cheaper, it was even worse than expensive.
It's not hyperbolic all or nothing. Sure infinite cost is just as useless as infinite failure, but there is no reason to talk about infinite.
At what cost? Some. At some cost.
This doesn't address how the cost of safety related procedures versus the cost of risks mitigated is calculated (which is way harder than saying "some") so that the buyer can actually know what "some" cost is.
It's also not addressing the parent comment's point: the bad outcomes in aviation tend to be very impactful (both in human safety and financially), so the tolerance for mistakes is way lower.
Compared to cybersecurity for a brochureware website, where it takes a far larger stretch to go from "security incident" to "someone's dead". (Also, people in cybersecurity aren't going to accept "it has some cost, and you might buy it if it's not too expensive".)
You could ask: is it _worth_ making it that safe? But we don't ask that. We just make it that safe.
I think there is a good point to be made that this level of safety (it costs what it costs) is probably not worth it for cybersecurity, in general, even if it's largely considered worth it for commercial aviation.
The only real question is how much damage will be caused before that happens.
It's fine for cheap pans to exist because any user of one can see what it is and make an informed choice to use the junk one or the good one.
Probably not all of software, but basically all of our financial infrastructure, operational infrastructure and communications infrastructure is either already critically dependent on software, or heading that way.
I think that the EU's DORA act is probably the way things will head. We'll regulate the outcomes and ensure that these services can be maintained.
Honestly, the only reason that this hasn't already happened is that the US government is wildly against basically all regulation of software. I figure that if we end up in some kind of cybersecurity crash (likely, given the current trajectory) that we'll get lots and lots of regulation.
And to be honest, this will be for the better in the long term, but it'll probably suck for all of us in the short term (but at least there'll be jobs).
https://assets.performance.gov/APG/files/2023/june/FY2023_Ju... states on page 5 that they're aiming to cut fatalities in half from 8.9 per 100M passengers in FY 2009 to 4.4 fatalities per 100M passengers in FY 2025. (It looks like they were doing way better than that goal.) "As low as reasonably practical" (ALARP) seems to be the term for aviation, which is very clearly not a zero fatalities goal.
> You could ask: is it _worth_ making it that safe? But we don't ask that. We just make it that safe.
They... Don't? Aviation accidents continue to happen and they will continue to happen. They've decided that a positive number of fatalities is worth it not because they want anyone to die, but because they know that perfection is impossible. You can't achieve it, and you can't know that you've achieved it.
Defense in depth is the idea. Swiss cheese model of failure.
There is no guarantee we'll ever reach perfection.
Sometimes they close down airports, that’s risk management not complete risk avoidance.
You might be, and your customers may not! And your competitor could be more than happy to offer a more reliable service.
(And you can also tell whose mind is stuck in the old world, too.)
You only need a handful of occasions of creating massive billing errors for your customer's customers before they will slag you to all their CTO friends and pull the plug. Imagine Stripe began double-charging every third transaction once a week, and couldn't fix it after two months of thrashing because no one there has any understanding of how anything works anymore. They are simply done at that point, all the value of their brand lost.
having seen both (a) mission-critical human-built systems become nightmares for maintainability and extensibility and (b) bleeding-edge ai coding agents confidently and quickly fix a wrong problem in the face of an issue (or fix it in a slightly wrong way), I remain skeptical that this great de-skilling will all be perfectly fine.
of course, if you aren't looking at the code you won't fucking know until someone yells...
>concerning for money-handling firms
The real world is robust. It's okay for money handling code to have bugs. It's not the end of the world and AI will be able to have a lower bug rate than humans.
This is true. The world will go on. But your business will lose more money than it gained by not paying attention to the code. It will lose money because it will have to compensate customers or lose customers. That's how the world maintains it's robustness.
That's just not true.
Yes, there are responsible engineers using AI in innovate ways and making things both more productive and better. But there are A LOT of lazy executives, and lazy developers who are spewing a lot of slop all over the place.
the former is demonstrably untrue (and wildly so), and the latter is just an egocentric/anthropocentric "the genie in a bottle only answered my wishes, it didn't tell me what to wish for". buried in that statement is the presupposition that humans being able to understand that something is actually Important; short of religious/faith-based reasons I don't see the justification for the primacy of human understanding when it comes to the determination of Truth. if anything, being "understandable" to humans strikes me as an anti-goal. are we really to believe that human comprehension is the limiting factor keeping society from degrading into "decoherence"? how well is that going for us? the reason humanity places such a premium on identifying "The Truth" is precisely because of how illusory it is for our fallible minds. LLMs struggle with many things, but coherence is least among them. that is why "slop" works so well-- if it wasn't at least mildly coherent, it would be easy to discriminate.
> there are A LOT of lazy executives, and lazy developers who are spewing a lot of slop all over the place and there are even more lazy humans who are happy to ascribe this to a shortcoming of the technology and not of humanity itself.
insofar as we are descending further into post-truth, it isn't because of AI slop blurring the lines between fiction and reality; it is because we are all collectively realizing that Truth isn't all it's cracked up to be. LLMs are forcing us to take a long hard look into the mirror and we don't necessarily like what we see.
Business and people that I once though competent I trust no longer.
I'm watching leaders I thought had vision throw the future away for the shortest-term gains.
What have we become?
Perhaps it reveals something deeper about about differing personality traits, about people who like programming as a discipline and like understanding code, vs people who view at as a means to an end.
Even before AI most software that ran “mission-critical” systems was kind of bad. I mean huge enterprises got routinely hacked bc of some owasp top 10 shit. And this happened many many times across all industries.
It’s not like before AI everyone was writing well-tested and reviewed secure super brain code
Definitely not all projects need the same level of quality.
But per the thread, if you allow the skills of all the engineers in your company to rot, what happens when there is a system that needs the higher level of quality?
Modern companies generally do not have the same incentive to keep their SRE (or engineers in general) upskilled. Cutting SRE because "we don't really have incidents, why do we keep paying them? If we need to do layoffs I would rather keep a product engineer" will always* (okay, _generally_) be the direction that organizations go without external influence or requirements.
Now I am sure there are some companies or industries where this is required (for example, I would not be surprised if certain military software/services contracts had requirements for support staff with X hours or training/etc), but that is not consistent everywhere.
If we want something that is "money-losing" in the short/medium term to be consistently applied, it unfortunately needs to be (uniformly) regulated.
I will say, I'd always been skeptical that AI could be better at incident management than an experienced engineer with deep domain / institutional knowledge, but I was recently proven wrong: Claude root-caused and helped resolve a Postgres lock queue pileup that I believe would have taken me much longer to fix.
Re: aviation being a perfect industry to learn from, I think https://m.youtube.com/watch?v=5ESJH1NLMLs might be a good watch. I was introduced to this at a Wheel of Misfortune around 5 years ago, so it's interesting watching it today when AI is encroaching upon everything.
The plane lands in the same amount of time whether an autopilot lands it or a human, so there's no incidental cost.
If you let a human SRE handle a problem completely, not only will it likely take longer than an AI, but since that SRE is now deskilled, it may take FAR longer. And that's a cost. Who's going to pay it?
Yes, a mistake can lead to a go-around, which at a busy airport can easily add an extra 10 to 20 minutes of flight time. But as long as no such mistake is made, a hand-flown visual approach can actually be quite a lot faster.
But first, we have to clarify the terminology. On most instrument approaches, the autopilot only flies the beginning of the approach, until the pilot flying decides to disconnect and lands the plane manually (somewhere between the final approach fix and minimums, depends on visibility and crew preference). So the most common way of flying an approach is neither fully automated nor fully manual.
Autolands are only done rarely, like in low visibility or periodically for pilots and aircraft to stay current. Visual approaches, on the other hand, are more common (though it depends on the region, controllers in the US hand out more visual approach clearances than controllers in Europe for instance). But even on a visual approach, crews often keep the autopilot engaged until very late in the approach or at least use the ILS as an aid while flying manually. That makes it tricky to do a comparison.
All external conditions being equal, I'd assume that an autoland is indeed less likely to lead to a go-around than a hand-flown visual approach. This is mainly because autolands, like other instrument approaches, are typically set up with a long final and earlier stable gate (typically 1000ft). A lot of go-arounds happen due to being unstable at the gate (too high, too fast, not configured, etc.) - that's less likely with an autoland which forces you to be stable much further out. Additionally, an autoland has a very low decision height leading to fewer go-arounds in marginal weather (though in such cases a visual approach most likely wouldn't be attempted in the first place). On the other hand, an autoland has stricter crosswind and maybe also tailwind limits, could be subject to ILS signal interference, and usually requires two or three autopilots to be fully functional. Still, the first argument has more weight to it I think.
But assuming no go-around, a hand-flown visual approach can be quite a lot faster than an autoland! As I already mentioned, autolands need a long final to establish early to give the airplane time to stabilize (often crews are looking to establish well prior to the FAF). A visual approach, on the other hand, allows tight turns onto final, slowing down and configuring the airplane much later, etc. The aircraft needs to be stable at the gate, but when flying visually that's typically 500ft AGL, so short final basically. Visual approaches also give controllers more freedom to give vectors with fewer track miles, and visual separation allows for reduced spacing.
Overall, I think that hand-flown visual approaches often save time compared to autolands, and possibly over other instrument approaches as well. And even if the probability of a go-around is slightly higher (assuming equal weather conditions), a go-around is still so rare that despite being a significant outlier in flight time, I wouldn't think it moves the average up much.
But maybe the comparison just doesn't make much sense to begin with. An airplane is flown by pilots and computer systems together. Pilots can choose between different levels of automation, but both extremes of the automation spectrum (on the one hand: fully hand-flown visual approaches without even the ILS frequency or any navaids tuned in; on the other hand: full CAT III autoland) are quite rare for airliners. Most approaches fall somewhere in the middle on that automation spectrum. Is that the safest and quickest way to do it? I don't know. But I assume the industry has converged on it for good reasons.
I noticed this constraint a few years ago when the SRE/DevOps hiring market was really tight, but no one was investing in non-senior talent. I ended up founding a startup that tried to address this by supplying training via simulated outages. Maybe we were too early.
Aviation is used to paying through the nose for stuff. For developers, employers want to pay as little money as possible.
Cut dev salaries by a factor of 3, and then it would be normal.
I don't see any reason whatsoever why "AI regulations" would become antifragile from their having been "written in blood" in the way that aviation regulations have been; if anything, our inevitable present and future AI crises will each be exponentially more devastating than the last. Modern aviation is a triumph because of how fallible humans are-- that's why we delegate control of aircraft mostly to machines. The shape of AI disruption isn't "the computers aren't following the rules", it's that even by our own rules of rationality our world is terribly underspecified-- we have computer security that isn't secure, subjective rules of ethics/fairness/judgment that defy straightforward explication, "knowledge work" that is actually neither "knowledge" nor "work"... the whole situation is much closer to the human domestication of the dog (letting a potential threat into one's home) than any traditional story of humans coming to terms with their own technological innovations. human behavior is FAR easier to predict than un-aligned AI behavior-- that is why it is such a singular moment in human history.
Those will be fun times.
Not too surprised to see pressure to reduce the number of pilots.
Aviation safety discussions on hacker news have barely more more depth than biotech and healthcare discussions here. It's extremely ironic because a tremendous number of pilots are engineers, and especially software engineers. It's not exactly a cheap hobby. But you don't see massive numbers of English majors come crawling out of the woodwork to join a discussion on the safety of C++ vs Rust, but tech bros flock to worshipping aviation as a platonic safety idol like moths to a flame.
Any books you'd recommend or journalists to follow that cover this beat?
On the engineering side you can look up ETOPS and the various ICAO and FAA and EASA standards for airliner class aerospace engineering https://en.wikipedia.org/wiki/ETOPS
Trust me, y'all think airplanes are "safe" because of some sort of magical protocol. No single protocol actually works. It's mostly lots of layers that are stacked on top of each. It's why in aviation, catastrophic failure modeling uses something called the Swiss Cheese model; you need every single hole (error or failure) to line up to generally trigger a complete breakdown in safety. It may sound counter intuitive, but by aviation safety philosophy, a canvas and wooden frame plane operated under commercial standards and kept to a strict inspection schedule is "safer" than e.g. a privately operated 737 that doesn't follow manufacturer maintenance standards.
NASA has plenty of guidelines for writing "safe" aviation software. I doubt any software engineer will be willing to entertain the level of effort and certification needed to comply with those for e.g. their Django side project.
Also, "fear of heights" is a totally valid excuse. Fear is a gut reaction and may have nothing to do with one's justified true beliefs. Eg., I know spiders on probability won't harm me but there simply won't be any amicable co-existence between me and any arachnid.
Yes? In practice once you convince them to get into the plane the only real issue in the air for those new to flying is air sickness.
Also fun fact a good number of pilots claim to have a fear of heights (never met one irl except online in aviation forums).
If you are in aviation/aerospace, don't be afraid to share the joy of flying. There's nothing quite like cruising at 90-100 knots @ 3000-4000ft AGL on a nice clear day.
That 2nd pilot makes up for lot's of impossible branches in the fault tree.
In other words, we might need to find some hobbies.
In general, it is of high quality.
I am not convinced humans can do much better in "disasters" than Autopilot, despite the emotional stories to the contrary (survivorship bias is one hell of a drug).
The autopilot does not do "almost all critical work", not even close. It only does some of the routine work (definitely not all of it). But the real critical work is when stuff goes wrong, dealing with emergencies.
The inherent complexity of aviation means that there are so many different failure modes and combinations thereof that no traditional system could ever handle all possibilities and edge cases.
I'm not going to claim that an AI could never do it. But as of right now, with current technology, well-trained pilots are absolutely critical to safety in even the most advanced airliners.
Also, the survivorship bias argument runs against you. Most events where pilots save the day are completely invisible. Like catching an incorrect clearance, a misconfigured approach, dealing with a technical malfunction, etc.
And even when disasters happen, it is very rare that simply engaging the autopilot would have saved the day. In fact, there are plenty of examples where the opposite is the case, and dropping to a lower level of automation would, in hindsight, have been better.
Note that I never claimed aviation relies on AI right now, most of the Autopilot systems are deterministic automation systems, but the original point stands regardless.
You should perhaps look at all the crashes where the autopilot stalled the aircraft on approach due to incorrect settings.
I didn't say that an autonomous airliner could never be built. With more technological progress it might become feasible at some point despite the immense complexity.
It's genuinely worrying to me to see statements like this. As engineers, we of all people should know that there's 1 billion variables that could go wrong and another 1 billion we aren't even aware of yet...
Instead, they are the weakest part on that market.