All that said, skill atrophy is real. Thinking about getting back on the interview circuit is p scary because of it. I dunno wtf is gonna happen.
It is also both a choice and avoidable.
Atrophy happens when you trade understanding for productivity. Productivity benefits your employer and your KPIs, but not your understanding and your opportunities going forward.
Understanding used to be an unavoidable of the exploration process, and writing documentation used to be the thing that never got done. Now, writing documentation is automatic, but reading it still isn't.
I've been managing a team of interns at my last job, and as they were all equipped with coding agents, they'd deliver complete solutions to problems once or several times per day that would normally take days, or weeks if you factor in necessary learning.
As review of their understanding, and for the sake of my own cognitive debt, I would first ask them the question "How does it work?" and they usually couldn't answer. After a handful of tasks, they started preparing answers. This forth-and-back is still more shallow than getting the deep knowledge chiseled through hours of trial and error, debugging and wrong directions. Spending two hours to find a problem to realize you forgot to save or upload a file, or had an x instead of a y. I look back with nostalgia, and I wonder if there weren't always better ways, and we just get to pick them now. I can literally convert any task, solved or not, into a quiz that brings me towards understanding, in rainbow-colored pig latin.
I think a lot of this skill atrophy talk is over-blown. It definitely happens, I experienced it some, but as long as you slow down a bit, and clean up and understand your code, your skills won't atrophy. Actually, AI provides a great opportunity to learn at an even faster rate by using AI to help explain complex topics.
Skill atrophy is when you're good at something, and because you don't practice it regularly, it gradually wanes over years, like when my former CEO said "I used to be good at programming" because he made a tiny chess computer and sold millions of copies, and now he... just doesn't code, and hasn't for decades.
Skill atrophy would be if I opened my text editor and I wasn't able to code after two years. Being a polyglot, there's always some language that feels rusty. And now they all do. But it hasn't been long enough to feel the atrophy.
What I'm describing is laziness to understand a problem domain.
> I couldn't imagine submitting a PR for code that I didn't understand and couldn't explain.
I could. I do it constantly for projects where that premise is acceptable. And I've worked on projects where many people merge to main once an established set of steps has completed. "How does it work?" and "Show me the thing working." are good gates. Understanding (or even reading) the code is not a mandated prerequisite.
As an Open Source contributor? No way. Exactly because I'm contributing to projects where people don't share basic premises. Some people code by hand, others use coding agents. If I were compiling stuff and everyone else was hand-writing their assembly, I'd read and tidy up my generated assembly, too.
> AI provides a great opportunity to learn at an even faster rate by using AI to help explain complex topics.
Totally. Better solutions come through those explainer sessions.
I’m on the camp of using agents as much as you can, but make sure to understand what they did. However, it will still atrophy your skills, no matter what. It’s just different times now, as on the job you’re expected to deliver faster. And obviously that means less time spending on your craft, honing your skills and etc.
It is far more often the case that you will spend more time getting the answer out of the LLM than you would've gotten yourself. They suck ass at troubleshooting systems, very frequently jumping to completely implausible scenarios that no human would think of as the first thing to try, and almost never asking questions to clarify the situation the way a human does.
Given the right tools and instructions I find them to be consistently superhuman. It's unreal.
I have an automated system responding to issues occurring on oceanconnect.ca, and every single diagnosis has been correct for months. Of course I still verify, I tune solutions, I review everything. But it's right. It's not a trivial system. It has a fairly large frontend, a large-scale model processing pipeline on the backend, a fairly complex database, and a queue for getting new data into the system. Claude does a stellar job of navigating and understanding problems, even when they're not 'real' or as they initially appear to be; things like quirks in old versions of Safari, or the model pipeline fails due to data integrity issues from the providers.
I've rarely encountered cases where I need to steer a frontier LLM much when troubleshooting. They're exceptional.
What you're describing sounds more like what would happen if you gave a chatbot without access to the repo as little context as possible and asked it to come up with a solution, blind.
Let’s say you have an incident, and you need a resolution. Do you spend 5 minutes tinking, then solving the problem or send out the AI for the hunt and spend 30 minutes grappling with hallucinations and non-sensical output?
The 5 minutes I’ve seen is usually by someone that will send the complete output to someone else to decipher, while saying they have figured it out. Then they’ll turn into a meat proxy between the team and the agent.
In real life, for systems where incidents that require such rapid responses, you usually have fail-safes an killswitches. When you were designing your system, did you put in place alerts and monitoring to mitigate risks?
I think people indeed need to constantly practice our low level skills, otherwise they will atrophy.
To say nothing of being bold enough to run systems like that in the first place. I know some of engineers that are still folding their arms and refusing to engage with AI!
SRE here, spotting the hallucinations requires you to have the knowledge to know when it's wrong. Best way to gain knowledge on systems is actually working on them. If AI do all the work, then you don't get the knowledge.
If you don't ride your bicycle for years and years because you can just write "drive yourself"
Then your skills are atrophying. Typing isn't a skill
We’ve known that one important component for learning (not the only thing that matters, but an important one) is the memorization of facts.
There seems to be a big urge to pretend that’s not true. E.g. you can learn arithmetic without memorizing your multiplication tables, literature without engaging with the canon, and now apparently coding without even having coded.
The idea is if we start with a top-down conceptual approach we will eventually vibe our way into knowledge acquisition. Which does sort of work.
However, sorry to be a curmudgeon, but the people who just “do the work” and actually spend time on task to learn a bunch of stuff … are actually more knowledgeable on average.
It's an established fact by now that if you know coding then you can get better output from Sonnet than vibe coders can from Opus
This is both like forcing all IC to develop management skills but its also like the shift to cloud infrastructure or 4GL languages - we are never going back to the old ways and will be building everything at a different level of abstraction with a different span of control.
The bad ones get promoted for spending the time instead playing politics.
Just under the surface of human consciousness, we are constantly hallucinating and predicting what we may occur next. We are good at discarding what doesn't align with our working model of the world before reaching awareness and taking action. It's our attempt to conceptualize reality. Considering how un-grounded from reality humans are becoming, the fact we have to balance our nervous systems, the mistakes we do make day-to-day, and how minor physiological changes (from poison to injury to drugs to random chance) can disrupt the process, it doesn't take much for humans to make a major mistake or enter a psychotic state.
It wouldn't surprise me if a systematic approach to solve these problems with LLMs could be applied to human/hybrid teams.
Agents fail randomly. One day a stellar dev and next a bs artist.
So this idea that LLM hallucination is not unlike human failings is without merit.
Last Claude major version they released a blog post basically telling you to chuck away your Claude.md file and start again.
It was only 18 months ago when people were telling you to use ultrathink:
https://news.ycombinator.com/item?id=43739997
And then that went away about a year ago, and now it’s sort of back again but not quite as it was.
We are using quite a big list of rules and the output is significantly more aligned with what we interpret as “good” code.
of course. who needs to walk when we have cars
People cannot deny that cars have made our physical bodies atrophy. Not all of us, maybe, but many people are way worse off physically than they would have been without cars
There's an analogy in there but I can't think of it. Maybe I'll ask Claude if it can explain it
This is an amazing use of LLMs, contrary to offloading your thinking to it during implementation (which does not mean not using to write code but to actually understand the systems you are creating with it, and all their edge cases, inner workings etc.)
Are you sure that it's superhuman; and not super -you- man?
me either but i do know it will happen sooner than i expect
And I am not just trying to platitude you here. Without that basic confidence everything ends up just eventually being harder with the AI, even if maybe the feedback and loop of it all feels faster.
I’m being asked very open ended scenario-based questions, I’m answering honestly, and it seems to be going well (i’m moving through the interview funnel).
I’m not getting asked deeply technical questions. No weird obscure trivia. No stack-specific things. No linux internals. No weird networking trap questions. Coding part is essentially gone.
My interviewers so far have mostly been other senior SREs.
It looks like a market where a senior sre can recognise another senior sre. Some kind of closed circle.
So weird, so so weird.
There is no understanding with AI-generated applications, full stop.
Companies loves to have "specialized experts" who skilled up in one afternoon in their field. It might be different in startup, but in consulting world in relatively large enterprises, it's just a fucking joke.
They wouldn't be able to draw it all onto a whiteboard from memory. But give them a half day and they will have mapped out the data flow
This just sounds like convoluted way of saying you understanding much less than you would otherwise.
You can always know more but at a certain point, after you’ve built enough validation and safe guards, you find it’s not the best use of your time and the things you can make beyond your specialization is quite remarkable.
Also, I think the toothpaste isn’t going back in the tube with this
The internet is full of people doing the “AI = compiler” comparison and it’s just wrong.
Maybe on a really small scale they can resemble a compiler because the number of possible outcomes is so small that it’s nearly deterministic.
But at any larger scale AI will not be deterministic anymore and at that point it will be relevant what the resulting code looks like. Because it can and will be slightly or very much off from your instruction.
But the direction is reversed.
I figure out how to do something, wrap it in a bunch of functions, and then kinda just use it. If it just keeps doing what it should, I may kinda forget how it works. But I don't forget that I made it, and that I understood it, that will never not have happened. So in a way, I am able to "forget" some things because I still know I knew them. And I trust that programmers who write programs that I dream about writing also know what they're doing.
With LLM, you accumulate stuff with from knows where, ultimately fished from a vast ocean named question mark, by whatever turns of phrase you and involved agents happened to use, and what the temperature was at that moment. Which is of course where all the harnessing and looping and running code on the output comes in, but still, ultimately you have no idea. Which is fine for prototypes, but long term? Good luck.
I've thought a lot about this quote, and the best abstractions I use are absolutely this. I love array indexing as an abstraction, but in the back of my head I have pointer + index * size. I like having the kernel do memory mapping, but I know there's a buddy allocator and TLB cache there.
Understanding should come in different levels abstraction of what you are building,and managing.
There are different levels SREs, from beginner to say Fellow level.
Do you expect the Fellow level to understand nitty gritty details of each component his apps or services are interacting with and how each of them start? No. Especially when they have to deal with hundres or thousands of services each of them hosted by different teams, orgs, or different companies.
junior SREs, yeah probably got their hands dirty with those nitty gritty details you listed because they tend to deal with smaller or lower levels of components
So my point is, I agree withyour "Understanding" but not specific details as they differ per one's level of experience
While the SRE will follow the problem to the next layer or component and try understand what is going wrong there even though they never heard of the system 10 minutes ago.
[1] "I know I'm on call for this team but the guy who sits next to me wrote that code" is something I've heard way too many times.
If AI can handle it, great! We have a new tool -- let's make the tool better.
Let's figure out how to use AI to make us detect and resolve issues faster, and even better, prevent issues. I've always said we can't consistently hit 5 9's without automatic detection and remediation. We are there now.
Let's get everyone to 5 9s with AI!
Actually... yeah, I'd totally say that. Some SREs in my company never wrote a single line of HCL that wasn't a call to a in-house, pre-approved module. They think they know Terraform - they don't, and they don't know what's under these modules either.
I'm using something different myself: a Docker Compose + reverse proxy config + some other support files, pushed to a private GitHub repo, which then triggers a GitHub Actions workflow that leads to the repository being pulled on the VPS and the infrastructure to be "rebuilt" (docker compose up, reverse proxy graceful restart).
Conversely, there are lots of folks who love ops type problems and are not well suited to building apps. So, it makes sense to put them on separate teams where they can each do the thing that they're best at, rather than fumble through the parts of the jobs they hate. But yes, at this point it's not really DevOps anymore, it's just ops.
Having the maintenance/ops requirements directly feed back into the design and engineering of the product is genuinely powerful. Especially for certain kinds of products, if executed with discipline you can get really good engineering reaction time with no degradation of quality, and often with much cheaper infra costs.
The problem is what you said though. People with both skillsets are rare, and combining them is legitimately a third skill on its own. And even "both" skillsets is a simplification once you start accounting for data, security, compliance, large scaling DB work etc.
It was mostly a dead end for these reasons but it was worth exploring for its potential. And some genuinely good engineering techniques went mainstream out of it, not a total waste.
You’re so right. This is the key, whether a team is doing devops or not.
One of my major contributions when I took on a CTO role was getting dev, ops, and support teams to talk about the pain points. There were so many easy wins to make things run better because the teams didn’t understand the difficulties the other teams were going through.
I've found that "ops" has become far too overabstracted and jargony. Their moat is endless "certifications". Their "experts" are the dogmatic personality types who try everything in their power to prevent their feet from ever touching the ground like it's lava. They lack the kind of dev or sysadmin experience where you have to stand under your own constructions like a Roman engineer.
Any formerly-known-as "full stack" dev who kept at it for the last decade and a half would run circles around anyone in ops. That's every senior dev working right now who doesn't like to manage people.
It used to be that the ones who went SRE just wanted a pay bump for a bullshit job of relatively light coding puzzles and parroting stuff in meetings, but I guess that well has dried up with "AI".
It turns out about as well as if you set the Ops team to shipping features.
Eg I’ve seen more than one full stack dev team build a synchronous RPC-over-message-bus framework because they can’t figure out how to make HTTP or actual RPC calls reliable. It is hands down the most poorly and overengineered thing I have ever seen on a service that takes single digit qps.
The ops teams fight that shit tooth and nail because if it blows up, they’re the ones who get called. And it is 100% too late to fix it by then. Ripping it out will take months, and the dev team will say they’ll do it, but they never will because the VP is leaning on them about some feature.
You either say no early, or you are forever on the hook for whatever abomination the intern has cooked up.
But if you have the budget and connections to hire a department of people with these skills and experience, and a problem interesting enough to keep them engaged in the day to day building, and a leader capable and charismatic enough to align them all into the business's goals... you should do that.
Exactly this was the idea: persons in a DevOps role have skills in both areas, i.e. are very wide skill set, so that one can assign them to very diverse tasks for more flexibility. Additionally, these persons can implement synergies to make things more efficient in areas that intersect both development and operation.
Some places do have really well built out platforms where logging, instrumentation, databases, deployment methodologies, IaC, etc have well-built happy paths that exclude a bunch of accidental complexity.
I think a lot of other places are either too small or grow too quickly with the wrong set of values and admit too much into their "platform" which had very little design to begin with.
Where it worked well is the "devops" or sre/sysadmin would sit in the same team and take away the rough edges of the infra.
conversly they would also keep an eye on the web people and see what they are doing and why, learning the tooling they use and try and rationalise it so they don't install 50 messaging queues.
In the early days of devops it was primarily focused on supporting developer productivity (CI/CD) but quickly morphed into sysadmin once cloud computing took off.
Your comparison might work better for a dev with no testing experience. Write the code and throw it over the wall. But I fail to see how an application engineer should need to worry about the intricacies of, say, setting up virtual private gateways.
To my understanding, this _is_ DevOps in the original sense of the word, and the version where they are a separate team is an offshoot bastardization.
At my last job, it was somewhere in-between where we had DevOps specialists who were regular software engineers who allocated the bulk of their time to building / running infra via Real Code (Pulumi vs. TF, minimal YAML wrangling etc) and built paths for app devs to self-service as much as they could. That, I felt, was a really excellent setup.
When these problems because largely solved with off-the-shelf software SRE became either a bureaucracy (ensuring reliability through policy and enforcement) or just deploying other people's code and holding the pager.
But I really do need the company to have a competent plan for handling issues that isn't just, "call the developer." It's amazing how much it makes them care about proper support and testing when the alternative isn't exploiting a developer, but is a customer outage.
Realistically nothing is perfect, there will be cases where something randomly breaks and will need attention after hours. Responding to a call for this should get you double pay for your time. Plumbers and electricians work this way, why not software folks?
If it absolutely has to get fixed, the company will pay the cost. If it can wait until Monday morning, they can save that cost.
Machines (esp. Virtual Machines) are ultimately predictable and crashes don't "just randomly happen". But it's what this entire "enterprise cloud" culture has brought in, the idea that it's impossible to simulate all possible failure conditions of a cluster locally and therefore we shouldn't even try doing it. Maybe that's true at Google scale, but most companies are simply not, not, not Google-scale.
As a counter-example, I recently built a simple "cloud storage" system with a minimal Linux ISO: everything is stripped down to the absolute minimum to just boot, start a minimal S3 server and pull (encrypted and signed) update commands from an SQL "control plane" database. The entire userspace is ~50k lines of Rust (minus 10k init system) and I can simulate the entire VM locally and play with the "cluster" of VMs locally. The ISO is ~20 megabytes large and I can simulate entire datacenters "burning down", virtually, locally, before it happens for real. I can simulate everything: network failures, disk failures, slowdowns, latency, try getting Fable to hack it, etc.
But in the kubernetes "enterprise" world, I can't do any of this. First I need 10.000 values.yaml files, 10 add-ons for logging and metrics (because pushing metrics to some collection endpoint over HTTP is clearly PhD level complexity) and on top you need a service mesh to restrict random containers talking to each other because nobody knows anymore what services can talk to which other services. The results are constant outages because of misconfigurations and someone having to be on-call at all time.
Needing on-call at all (except for maybe security alerts, but those are usually not part of DevOps) is the result of this Google-influenced "crashes just happen" nonsense where "manager" culture is preferred over results (aka uptime).
Uh, I can literally see thousands of crashes happening all the time. You think there isn't a .01% chance of hardware going bad or hitting kernel bugs?
If I count my test suite for the ISO, I have ~2500 unit tests (placement groups tests, Raft behaviour tests, disk perf tests, SigV4 crypto tests, DHCP tests, kernel rollback tests), ~110 fault-injection tests (latency, network, RAM), ~60 block-store failure tests (e.g. network interrupt while two disks try to sync), "chaos tests" (generating random event scenarios for an hour), bit flip tests, "fsync lies to me" tests, power cut tests, round-trip tests, "power cut while in the middle of sync between datacenters", SMART degradation tests, load tests, memory pressure tests, file descriptor resource starvation, NTP drift tests, metadata DB loss tests, DNS failover, ....
Then for security everything is turned off, kernel modules are off, eBPF is off, io_uring is off (lots of CVEs), user namespaces are off, most network and file drivers are off, /bin/sh is off, S3 endpoint is minimal, etc.
Most rules from aerospace are said to be "written with blood", some crash caused this rule to be legalized. But with ~40k lines you can go through each line and say "what if this fails". With a kubernetes cluster it's more or less based on hope and happy-path testing.
I also scraped other competitors for user complaints, esp. about data loss / sync engine bugs and in total I now have about 4000 tests for 40k lines of backend code and another ~1000 tests for the 15k lines for the sync engine code (about 1 test for every 15 lines).
I'm still not entirely confident (still need lots of beta testing), but a chance of data loss of .01% would be pretty high. It really depends on the amount of testing whether you need an on-call person at all and most orgs are more engineered towards "just hire someone to be on-call" rather than doing proper testing.
Yes! This is devops, thank you for coming to my ted talk.
Coincidentally I’ve found putting engineers oncall for their stuff really does wonders to ensure they check their AI agents’ code and know how it works.
Code of Hammurabi's Law 229: "If a carpenter has erected a poorly constructed house, so that the walls cave in and kill the homeowner, that carpenter shall be executed."
That’s what DevOps meant where I worked.
I remember the separation of developers from deployment being one of the things DevOps pushers wanted to reduce.
In fact it was the beginning of my career when the older senior people were already trying to get away from the assembly line style of software where each person worked on their part and then tossed it over to someone else to become their problem.
SRE just came from the big guys calling their sysadmins SRE
You're conflating a whole lot of different models here. In fact, "developers should be on call for the systems they build" is a principle that most schools of DevOps thought emphatically subscribe to.
The point of SRE is to have a team dedicated to scaling/resilience to balance the tension between product pushing to ship features.
If SRE cannot throttle the release cadence or fix bugs or change architecture in binaries, it's not really SRE.
> The point of SRE is to have a team dedicated to scaling/resilience to balance the tension between product pushing to ship features.
Sounds like a cultural issue. Google should look into that.
You didn't look around very hard then. I acknowledge that certain areas of the company can consistently use subsets of a role, so you may not have encountered it personally, but your view is definitely wrong about the role in the company as a whole.
Easier to shit on people and things with hot take then actually have a grounded and coherent argument or realise that different companies/teams have different constraints, problems and environments they operate as well as different solutions.
It's still something everyone can theoretically learn, of course, and someone who works in that role is most effective by instilling those disciplines in others as they go, and making everyone successful.
This caused a lot of money to be poured into all kinds of projects, not all of which had a positive return on investment.
Give literal zero interest loans from a state bank based on social value and economic priorities, just like they do in China. And set up an extreme progressive tax (90% top bracket) on returns that are paid out to owners to make sure everything gets invested back into production.
More investment is the driver of economic growth. All the bad parts of ZIRP came from letting companies use the money for unproductive activity. If it's used efficiently the downward pressure from higher product supply will be stronger than inflation from more money in the system. And you get more demand in the labor market leading to higher wages.
I don't think that's a bad thing, it makes infrastructure more consistent and less weird (assuming you understand k8s) but it is a very high level of abstraction and for a bunch of people is just a black box.
If you build tools with that context, they’ll have to replace you with someone that has that context. There’s few of them, and they’re expensive.
It’s easier to hire folks that should be interns or juniors that know that one tool, and then replace the whole department every decade.
It’s why everything is YAML now, despite it being horribly verbose and clunky. Can’t have our people needing to know how load balancing works, just add another 95 lines of YAML boilerplate so they don’t need to learn 5 lines of nginx config.
If you run simple workloads, it’s probably not necessary but then you’ll probably be paid for that. Your company can also choose to outsource complexity to the cloud, and you’ll just be writing YAML. Then there’s also companies where you host everything yourself AND you have large/high workloads, then you still need people with understanding.
With your type of comments, it feels like you’re pretending a developer who writes WordPress websites does the same work as someone doing Erlang for instance. You’ll have different skill sets for every type of engineer, and they’ll all be necessary.
I think you’d be surprised if you look at the younger (post-2000-ish) companies. Specifically about this part:
> If you run simple workloads, it’s probably not necessary but then you’ll probably be paid for that.
You would be surprised how many workloads either are simple, or can be ham-fistedly shoved into a “simple” architecture.
Eg I’ve seen a lot of Postgres-on-k8s solutions that are basically just Postgres on bare metal with a bunch of useless abstractions. It writes to local disk, moving the pod to a new host is basically restoring from backup. Wrap it in some tool that ingests YAML and call it a day.
k8s is sort of the king of this. I hear people say they understand k8s and I can’t help but furrow my eyebrows. I don’t even pretend to, there are so many insanely complicated edge cases.
Eg if I’m sending UDP packets to a service and scale the deployment from 2 pods to 4 and the host for one of the new pods crashes and comes back up with a bad iptables rule, what are the range of potential behaviors k8s would show? What’s the difference between blocking say all traffic vs only traffic to one or two of the etcd instances? What if it’s blocking half the hosts in the cluster?
Storage has its own weird vagaries around single vs multi mounts and race conditions therein.
k8s is the king of “I don’t have to know that, the platform will do it”. I’m not sure I’ve ever heard anyone outside networking talk about whether a pod will saturate a NIC. Just chuck it in the cloud and let it figure itself out.
Another oft-cited article here is William Langewiesche's article on the AF447 crash (https://archive.vanityfair.com/article/2014/10/the-human-fac...):
> To put it briefly, automation has made it more and more unlikely that ordinary airline pilots will ever have to face a raw crisis in flight—but also more and more unlikely that they will be able to cope with such a crisis if one arises. Moreover, it is not clear that there is a way to resolve this paradox.
One of the things from the book was how Sully spent a lot of time investigating other pilots' accidents: 'was there anything that pilot could have done to have survived?' When he got to his own emergency situation over the Hudson, time slowed down and he decided over the course of a few seconds that ditching in the river was their only option.
"One way of looking at this might be that for 42 years, I've been making small, regular deposits in this bank of experience, education and training. And on January 15, the balance was sufficient so that I could make a very large withdrawal." https://en.wikipedia.org/wiki/Sully_Sullenberger
It can certainly get closer but unless your tech stack is a webserver and an application it can get complicated.
When they imagine someone using AI (except for themself), they imagine the least curious, least inquisitive vibe-coder. And they invent the idea that the only way to be someone who asks questions or remains curious is to have paid the dues that they see themself as having paid. Therefore the world must always need them.
Well, all you have to do now is imagine the vibe-coder who has the same curiosity and inquisitiveness that you had especially when you were starting out and weren't yet a professional programmer. The only difference is that now you don't have to bootstrap a whole software career to understand how things work; you can skip that and merely ask.
We're required to imagine them because they don't seem to exist in the real world. The vibe-coders seem almost entirely composed of the "I commit 20 kLOC a week without reading a single line, lol" or the "LLMs are like calculators/basic arithmetic skills are obsolete" lunatics.
It's so depressing a thought that if I continue on this path, in a few years, let alone a decade, I'll be utterly unable to produce or even understand code. I realize the skill may not be very economically useful, but losing it is still a depressing outcome that's preventable in theory. At the same time I'm feeling a deep apathy towards building anything. Playing a Zachtronics game is the farthest my internal motivation can push me towards...
I'd love to hear what others are thinking/doing.
I use my agent to prototype a rough version that mostly works, and then I iterate through (with or without my LLM) to clean it up. Then back to the top with a new feature until I’m satisfied with the project and code.
I do tend to like it. My real selling point is that I’m not “locked in” to any choices until I’m happy with how it looks. I used to have to build the thing to see how it looks and acts, and going back on those choices was painful.
I do think there will be value in it, but I’ve been wrong before. My agent occasionally makes stupid choices that make every prompt after that 4x as hard to fix. Like I screwed up a pydantic model in an unreleased library and it supported a “legacy” path no one would ever use for like the next 5k LoC. By the time I noticed, legacy handlers were like 25% of the codebase.
That’s gonna burn a looot of tokens if you scale it up to a million line of code app.
I'm more worried about people that did never program and started directly with LLM support...
I'll probably get downvoted for this but: At 15 YoE, hell no.
Day-to-day coding lost it's allure to me about 3-4 years ago; it's just a means to an end. I think AI came at the right time for me.
Plus, some people enjoy the rigors of solving in-the-weeds code problems and others enjoy building systems-level designs. This was always true.
Do you need good quality code to do that? Sure, but that's just another line-item on the laundry list of things to make it happen.
I personally have a project that have been spending 2 months now making the specs and blueprint, more than 1000 files defining every bit including the future features too, and not a single code has been written yet, later, an agent will use this to produce the syntax and all the needed tests to have exactly what’s been needed.
The biggest problem I see with AI isn't deskilling. It's the same dopamine hit one gets from social media but for their profession.
One of these orgs had basically all of the noisy pages under control through automated remediation and a culture that pushed towards aggressive automation of pages that had the same root causes. Almost everything I was paged for was some novel or uncommon fault condition. Developing an intuition about how the system worked (well, more specifically, how the system failed) took a lot longer because most things I had to look at were some edge case failure.
> But here’s the catch.
> If human SREs (okay, now we have to use adjectives like human ) only engage with Tier 3 incidents, i.e. the novel, never-before-seen outages, where do they build the intuition to handle them?
How did they do this before AI? I have done a bunch of complex production level debugging and these Tier 3 incidents are always "starting from scratch" never seen before issues. The main "intuition" I built is persistence and verifying/refuting random hypothesis. In other words, I think we can build an intuition for Tier 3 issues only by engaging with Tier 3 issues.
Although, psychologically, some success in T1 and T2 issues is what gives us the confidence to even approach the T3 issues.
Now if only companies wanted to hire people that still have skills and aren't just prompt engineers.
I work in an AI sceptical organization, it's not that we don't use AI agent or consult chat bots, but they are kept a good distance from production. Talking to other SREs in AI heavy and AI first companies I don't see that ending well. SREs struggled with operating applications from developers who cannot or will not understand how computers and the internet work. Now many of the junior developers are even worse and some of them are given the title of "DevOps" and they are using AI to create some of the most broken ass Terraform code and bastard Helm charts to run their broken code. Some SREs are spending more time fighting agents and agent written infrastructure code than they would have, had they been allowed to write it themselves.
If tokens becomes to expensive, we're left with a ton of broken code and infrastructure that can only be managed at an inflated cost. There will be good money to be made consulting and cleaning up the mess of AI boom.
The take where in a couple years there will be a massive revert or that anyone cares about terraform indentation or a shitty yaml template is wildly optimistic.
I do hope you're right though, but I'm not seeing it from my side of the fence.
It's mildly orthogonal, but I think the metaphor is really quite apropos.
SREs are about super-thinking, context switching, recognize patters and workflows, data movements, etc..
My original career/learning path was for a traditional kind of SysAdmin role, because that's what I like. Doing Linux administration and such. Then our whole stack went AWS/cloud-native, so, ok. Seems like no one cares about someone who can actually SSH into a Linux server and figure out what the problem is--they want everything to be built into CloudFormation so that when a server is misbehaving you pull a switch to trapdoor it into oblivion and drop an identical one into its place, in the hope that this one works. I didn't relish the idea of moving away to the increasingly abstract, but alright, I can deal. Reformulating my learning path into being a Certified AWS Full-Stack Engineer or whatever.
As that was in progress, my company drank the AI kool-aid and went all in on AI. Now I honestly don't know what I should be training for. They've been pretty consistent on "No new staff, just AI", "You don't need X, you just need AI"--so I am honestly not even sure at this point if my company even wants me spending time diving more into the AWS stack, or if their attitude is "The AI knows everything--put all of your time into AI prompt engineering and just push whatever buttons the AI tells you to do."
The desired company skills continue to drift from my "personal" desired skills, but if this is an industry trend I'm not sure I have much of a choice, because I need my job.
AI is already pretty good at this in "SRE" workflows.
> AI-driven change risk assessment
And half decent at this.
* AI-resistant organizations led by graybeards who refuse to send telemetry off-prem (to either observability vendors or to inference providers) and will be dragged, kicking and screaming, into the future, over their cold, dead bodies. There's a lot of large, conservative organizations in this category like banks and governments, where budgets are rubber-stamped and Don't Break It If It Ain't Broken attitudes are tacitly approved of.
* AI-accepting organizations where Ops will go through the same great narrowing that Dev is going through now - build the dark factory and let it run. You do still need people who know what good architecture looks like and to shepherd changes to improve the overall system to make it more observable, scalable, and maintainable. You do still need Non-Functional Software Engineers who don't answer to Product, for the sheer political reason that you need people who have a long-term perspective, compared to Product that has a short-term perspective. The business will make decisions like "Vendor X is too expensive so we're migrating to Vendor Y" and you will need somebody to drive the agents to make that happen in a way that respects availability and compliance requirements. You probably don't need, in the long-term, a whole team of people to handle it, let alone a whole group or a whole division.
At the end of the day... focus on being a strong engineer. Somebody will always be needed to take care of the trees.
> Alert noise reduction and intelligent grouping, runbook execution for known issues, log pattern detection and anomaly flagging, and basic root-cause suggestions from historical incident data, and auto-remediation for well-understood failure modes like restarting a crashed pod or scaling up a service that’s running hot, are all fairly automated today.
Let’s stop here and ask, why do we not fix the underlying issue? Alert noise? Design better alerts. Runbook execution? Make it a cronjob. Known issues? Why aren’t people fixing these known issues? Root cause suggestion from historical data? Sorry if root cause A is in the historical data you expect problem A is fully solved so it wouldn’t appear again in the next incident. Restarting things? Why doesn’t your health monitor restart things automatically?
SREs also need to climb up the abstraction ladder. Instead of using AI to assist with grunt work, use AI or human thinking to build more reliable systems with fewer incidents. Every incident should be novel.
Most of us, however, do not.
Fly the plane, not the automation.
Also, skills can be re-acquired, if needed. People are acting like it's the end of the world for them, like their knowledge will become impossible to understand anymore. I'm not as fast at solving equations as I was in high school, but I still understand the logic behind it.
We will adapt just fine, like we did before.
I feel like I've been going insane as people have ignored this for short-term gains.
Yall this was always just a money making scheme.
Never was it meant to carry humanity into the future.
Clearly the "author" didn't even put in the effort necessary to make a real title. Not "SRE persists but a skill crisis looms" not "SRE careers remain but competency lowers in spite of AI" not "AI lowers SRE skill but demand is steady". Moreover, hasn't this type of insufferability been dramatically reduced in recent models? It screams that in addition to being slop, it's outdated.
Why would anyone take this at face value?
Do LLMs “deskill” us in general? I suspect we are just replacing old skills with new skills.
Site reliability engineering (SRE) is a discipline in the field of software engineering and IT infrastructure support that monitors and improves the availability and performance of deployed software systems and large software services (which are expected to deliver reliable response times across events such as new software deployments, hardware failures, and cybersecurity attacks).[1] There is typically a focus on automation and an infrastructure as code methodology. SRE uses elements of software engineering, IT infrastructure, web development, and operations[2] to assist with reliability. It is similar to DevOps as they both aim to improve the reliability and availability of deployed software systems.
At some point (we might already be there) someone insisting on doing everything manually will be seen like a carpenter who does traditional joinery. They might exist, but they're never going to be a significant percentage of the market compared to 4 guys with nail guns knocking walls together in hours.
Because for the vast majority of cases, "good enough" is good enough.
The Calculator!
Calculators deskilled long division!
Thing is though: who gives a damn about long division? The real task is your taxes or making a massive BI report for your presentation tomorrow.
AI makes stuff that was hard - someone's bread and butter - possible to ask for and have done for you. Why bother staying skilled at those things when you can broaden? It clears the way for tasks that used to take forever to become something to steamroll through on your way to a much greater outcome. It's the micro way that, in the macro, humanity becomes far more capable as a species. The gates are being flung wide open and the gatekeepers are being lapped and they have blogs!
It's not a tragedy, it's universal access to leverage.
> The Calculator!
Well, I'm sorry to hear that. I have a calculator and some pretty neat computing hardware. If I go into the attic and search long enough I can probably find my old sliderule. I can also do long division, as can all of my kids. I think it is an essential skill to understand all basic mathematical operations, and to be able to use them on small data sets. If I didn't know how to do division without a calculator I would consider that a failure of my basic education.
Edit: "HackerNews" and people can't do long division??
As we're only imagining anyway, let's ignore the genie for a moment. If we did lose our sense of basic arithmetic all of a sudden what would life at its core even be like? If there were two apples on a table you wouldn't be able to comprehend what happens if you took one. Would we even be able to function like that?
Perhaps there is a limit, sure, but I suppose that's where you lead with a concrete example to explain where that line is.
Not humanity, a small number of people in this planet, will benefit about this, because now they no longer have to depend on under payed workers to do the job, and will use AI to make the lives of all other human being poorer.
I think that we need to oppose this tech dictatorship, first thing stopping using AI and thus stop depending on an handful of companies that are able to provide it, that while they gain more and more power we all gets poorer.
What was wrong in using our brain, in the end? I still use my brain on my job and I always will, maybe one day they will say that there is no more need of computer experts because AI can do everything (still people bring me their laptop to reinstall Windows, something I've done for 20 years and that AI didn't change), I will just find another job but I will refuse to use this AI shit.
Where're you doing your debugging? The tundra??
(It was a full 250g of this fantastical kempy Herdwick, absolutely unlike anything you can get commercially, and I'm honestly more proud of it than of anything I built in six years working at NVIDIA.)
I feel there is a potential to "distill" the frontier models into useful tools that can run on smaller hardware. Or distill that knowledge to produce hardware, compute or otherwise. Iff one day the frontier model become inaccessible, the tools that were carved with them may remain valuable.
They will remain most valuable if they are designed in a way that is maintainable even without LLMs. If not, they can be studied as artifacts, or reference designs and then recreated using human intelligence.
The analog I'm playing with:
You can rent time at a high end machine shop and use the best CNC machines to produce extremely valuable tools. Once you leave, you don't have access to those tools, so it is advantageous to produce durable artifacts that are valuable on their own — on a different frontier.
Imagine you're going beyond the frontier physically, exploring new parts of the earth or space. You can't bring the giant machine shop, let alone the machinery of society, the entire economy etc. What do you bring? What do you build now while you have access to the best machines to take with you?
Planning for mitigation before resolution lets a team address production issues at leisure (because the customer impact is mitigated)
All this knowledge is in your agent - ask it for ideas!
You can type the same long division problem into a calculator 65,000 times and you will get the right answer 65,000 times.
Can AI get even CLOSE to that?
We're on to the next frontier, and it's a bit weird. Jagged frontier and all. But it's opening up new worlds.
Luckily loads of problems are amenable to a non-deterministic approach - even better, many have lots of solutions. SRE is in that bucket. There are as many ways to SRE as there are SREs
(source: one of the first SREs at Uber, co-invented Chaos Engineering as a sub-branch of SRE, hosted first chaos eng conf at Uber, played a key role in Uber's global SRE and incident response "Ring0" initiative, managed many SRE teams over a period of roughly 7 years before a career pivot. You could say I know a thing or two about SRE.)
To SRE well you look at the situation and pull from a huge range of tools. With such a broad range of solves, you're better to focus on the outcome: did we achieve our SLOs? Are they aligned with customer expectations? Focus on defining that and providing the right support for it to be achieved and you'll be fine - you might even get a surprise.
Ah, that bullshit reasoning again. No, if you build something that "supercharges SRE", someone will be made obsolete.
I'm geniuinely sick of this framing, seeing people at my company building company-wide skill repositories and shoving contents of their brains into slick Markdown documents. Well thanks, now our AI knows everything, good luck with your future career (if there is any left).
At least part of it is that I waste less time debugging and testing, and now I have more time to learn new skills and technologies (faster).
- if writing code was that easy, i request you to come and write call of duty modern warfare 5 from scratch without a game engine in c++
You guys are still doing things, correct? Is my experience so outside the norm, or is stuff still challenging?
But how do you make Senior+ SWEs? By having a pipeline of juniors who get trained and mentored. That pipeline is cooked now.
There is going to be a brief period where some like Staff+ SWEs are going to make a lot of money by being AI specialists. But the flood waters are rising for everyone. Those opportunities are going to shrink.
It's eventually going to be a problem that the ecosystem has died because there's no new blood and the people there lack the experience and critical thinking to understand what's being done.
I can use AI on topics I know because I can spot the errors. LLMs lie a lot and get things wrong a lot. What happens when nobody can check the output?
Ime this doesn't happen or reflect the reality of work. I had one mythical job where I wasn't directly on call and only received escalations and didn't have a problem with debugging whole system issues. I still worked on the whole system day to day.
Also I feel like this post is also my frustration with sre. In people's minds it's just the job that deals with issues pumped out by swes and they have to work magic because no one else can be bothered to try at their job. This just reinforces that idea.
For Claude it took 10 minutes to solve it.
If Claude goes down or stops existing when we go down, we're fucked.
I'm not lamenting the days when you needed to pull a seasoned (read: exquisitely expensive) COVOL developer out of retirement to make a change. Now AI can figure it out well enough, I just need to know how the basic concepts work.
Every person on my team is capable of networking, product engineering, database, job processing and we have command of the entire stack. We will push updates for CVEs with stuff we manually compiled. We own the build system and have the ability to change product as needed. We all have experience in product and we're all capable of pushing fixes as needed. Frankly the SRE team is by far the smartest team I have ever worked with at any company I've ever worked at.
Just a matter of curiosity for me as my career progresses, where I think that is the ideal, but I don't work in a heavily privatized nor regulated space at the moment of posting.
I did read your latest blog post looking for an answer, but it wasn't clear to me from that reading.
We have many packages internally so inevitably we need to build them which necessitates an entire build matrix on it's own. But once you have your own build matrix adding a new package is trivial and most build in under 10 minutes in github actions. One issue is we don't want to use Canonical's default gcc flags so like Gentoo I setup a make.conf that is specific to the suite (22.04, 24.04, etc). This has allowed me to target a higher tier instruction set which is it's own micro optimization. Folks that upgrade blindly from 22.04 to 24.04 will see their performance drop from gcc compile flags alone. Also we have people who have access to CVE fixes before they are generally available so that's also another important reason. Anyway we DO use upstream most of the time for setting up a project folder or normalizing it against a new suite but then building it is using different gcc flags and might be pulling in our version of curl or something.
IaC codebases, configs, utility scripts are relatively tiny, and fit into context windows whole. Models are eating them for breakfast.
They're really good at incident response. Sadly, much better than our dedicated colleagues from <location> ever will be. They'll chew through cloud service logs, application logs, application code, iac code and config, CI output, etc. to get whatever is needed, cause wide knowledge is no issue. Even disassembling stuff is no barrier, tracing things down from app level, to runtime level (e.g. JVM), to native calls.
They're really good at handling deployments, end to end infra setup and migrations, following checklists. Hell, they don't even really need checklists. Something that cannot be said about other dedicated colleagues from <location>, who cannot breathe without a checklist, will skip over steps, or otherwise very creatively misinterpret them or improvise something wicked.
They're really good at spinning up mad nice dashboards, and keeping business types happy with impressive looking write-ups they'll never read. It's really refreshing to not have to write those write-ups anymore (or the aforementioned checklists).
It's straight up both not looking good and looking better than ever. Having it be fully hands off remains an issue though.
They also have a propensity to try to rewrite gigantic amounts of code in one go making changes riskier and harder to scrutinize... without using more LLMs.
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.
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.
That's just not true.
Real customers. Real revenue. Many industries. All written with AI.
It hardly meets the bar of a mission critical product like an ERP or payment processor layer where introducing random billing errors in customer data could be fatal to a B2B company's viability.
I guess we are not serious engineers making a serious product for serious business. I'll make sure to let our customers know.
Most businesses aren't in that category, that doesn't mean they aren't able to provide useful services and make money. But your company does not seem like it meets that bar.
Expanding the group to "any money making SaaS" would be moving the goalposts for the point OP was clearly making from the beginning.
Sorry for being a bit dismissive in my previous comment but it was fairly jarring clicking your link expecting a more responsive counter example to their argument, and then left a further bad taste after realizing from your bio that it was self-promotion.
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.
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.
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.
Defense in depth is the idea. Swiss cheese model of failure.
"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
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.
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.”
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.
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.
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.
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.
"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.
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.
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.
(And you can also tell whose mind is stuck in the old world, too.)
There is no guarantee we'll ever reach perfection.
Sometimes they close down airports, that’s risk management not complete risk avoidance.
https://how.complexsystems.fail/
You might be, and your customers may not! And your competitor could be more than happy to offer a more reliable service.
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.
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?
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.
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.
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.
That 2nd pilot makes up for lot's of impossible branches in the fault tree.
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.
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.
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.
In other words, we might need to find some hobbies.
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.
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.
In general, it is of high quality.