A natural evolution of engineers losing touch with the customers and users.
I'm noticing some of the concern play out regarding AI weakening the capabilities of software people.
I gave the team an exact solution on a silver platter and they still failed to identify how to go about it after 3 days slamming it into Claude. The resolution is literally 1 line of code that could be arrived at in about 30 minutes of patient, old school troubleshooting.
I think what's happening is the AI system draws poorly aligned and led engineers into this ego inflation feedback loop where they are completely detached from reality because these tools can simulate a better one.
> 30 minutes of patient, old school troubleshooting
This is also the best way to understand a codebase, and it's quite enjoyable.
I think the models are getting too egotistical. They're so confident of their fixes they won't bother suggesting basic techniques like isolation of the problem by disabling code paths, for example. They'll keep shotgunning less-and-less likely fixes with undiminishing confidence until the code is full of fixes that do nothing. Then they'll double down on why these should be kept.
I have no evidence at all, but could it be that repeating the same thing over and over again in the context makes models latch on to it wrongly and gives them more confidence despite it being wrong? Kind of like a sunk cost fallacy…
Although I do acknowledge sometimes they too point out something I thought was quite right but turns out of be wrong…
It's the uncanny valley of AI. It's still not quite good enough yet that you can trust it blindly on a big codebase, so you still have to read and understand everything - which is often harder than just writing it up yourself.
EDIT: don’t get me wrong. I still think AI is incredibly useful for a lot of tasks! But when implementing an architecturally hairy thing, I find it less stressful and equally quick to jump down to the editor level and use AI just for code completion.
Pretty much, The one thing I use it for is as a sanity check, pretty much "Look at <SomeFile>, point out issues you see, summarise them tersely" and it'll spot stuff a code review by a human might have spotted (in the mythical land where people actually do code reviews properly and don't just flag a spelling mistake to "show they looked at it").
Beyond that I don't trust it at all and I still write all my code the meat sack way.
Trust is earned not given and it hasn't earned it yet.
> It's the uncanny valley of AI. It's still not quite good enough yet that you can trust it blindly on a big codebase, so you still have to read and understand everything - which is often harder than just writing it up yourself.
You might as well have left it with: "It's still not quite good enough yet that you can trust it". That's the core of the issue. It doesn't matter what you ask it to do, it can't be trusted. Some things are just easier to verify and correct than others.
I think what's missing is fundamental. I think the reason it sucks so much to work with LLM-generated code is that LLMs will never "know" what it's like to be human. They don't "understand" our frustrations and motivations, and they're missing the vast array of useful mental tactics we've evolved to cope with corporal existence.
At this point I think progress towards a good colleague bot would require a new architecture which allows continuous leaning, and for the LLM to be raised as a human child (maybe in a simulation at 1000x speed or something).
I think the speed/context size of the large models is a threshold. I've been using a local model and watching it do killer stuff, and also shit out useless things; all in real time, requiring active steering.
Your assumption is that LLMs will ever leave this uncanny valley.
Maybe unforeseen breakthroughs and different architectures are achieved. Given LLM fundamental shortcomings grounded in mathematics and information theory, I highly doubt they will and we will always need to deal with these issues in some capacity.
I'm seeing this happen in the security space right now. Someone on my team I was helping train and bring along is all of sudden regressing in their understanding of the issues we're working on, and instead focusing on AI tool outputs to do their job for them.
Usually, I take my time to understand each keyword of the code I'm looking at, especially if it is new to me, like terraform.
I work in a team/with one architect, who only did the DevOps/Infra stuff for the past years and I had the expectation he knows what he is doing and talking about.
At around 2 weeks, I noticed how his knowledge has severe gaps and how he takes things at face value or uses terminology interchangably, which confuses me. It sounds plausible, but it does not actually translate into a working system or shared understanding.
Then one day I did some pair programming with him and whenever there was an error or a resource missing, he would type it into the LLM, copy paste it out of it and then brute force error messages. He did not even wait a second to think or reconcile whats happening on the screen or what the exact requirement is. Never taking one step back and questioning any assumption.
Now that the timeline is shifting and everyone starts to be stressed, he continues to vibe code through me and it is so tiring, there is no higher level planning or architecture, its just a reactive type of trial and error to be faster.
It feels like these people are so used to talking to bots, that they treat you like an agent they can chat to or talk through monologs with.
It is quite shocking how people went from being humble (learn the basics or close the gaps in understanding) to full on authority on everything and berating people 24/7...
So right now I'm considering quitting IT for a couple of years until people calm down, but I think its pretty futile
I saw this the past year - new employees would put problems into Claude first instead of debugging. A year back I was debug manually first, now I do the same.
The speed AI debugs at is incredible and yes, we lose touch the more we use it like any manager feet up barking orders to their underlings to get things done.
To be fair the cyclical nature of funding and defunding security teams which causes scaling up and scaling down, has always left a race to the bottom in security.
Any CISO or head of security loves the ideal of completely using AI to handle incidents, tune detections, implement mitigations, track vulnerabilities, pen testing, etc. This feels like it driving security teams to have less critical thinking.
What is your relationship to this team? Their manager? A senior colleague? Something about this sounds like a failure of communication or leadership. Why are you stand offish from them? Why are you treating them like children? If they don't know what they're doing why did you hire them? Now that you did why are you treating them like a burden and not an opportunity to mentor, teach, and uplift?
You can't force someone to improve themselves. AI-fueled ego trips are really difficult to sublimate. The only viable solution in this case is to overwhelm the pupil with mastery. Demonstrate that even without AI assistance that you can run circles around their solutions. If someone actually came to me and asked for advice on something, I cannot imagine I would turn it down. Many developers are absolute monsters. Pretending like that is not the case only makes the whole thing worse.
I also read that comment as an adversarial situation at work.
It used to be that when someone else at your company was asking for something that wasn't a priority, you would erect bureaucratic roadblocks to protect your time. Now, the new normal is to just forward their questions to AI and sling the slop back over to them.
When I hear this I do wonder to myself how they're using AI.
For me, as long as I'm properly RPI looping it and not blindly pressing "yes" then it will nearly always reach the solution, usually a fair bit quicker, because it effectively becomes an ideation machine that can keep more thoughts and knowledge in it than my brain can.
However, I'm using it through giving it the context, it has access to the repos, access to the sytems, I'm telling it where the logs are, I have docs to show it what each part of the system is for.
Along with that, it does depend on my own instincts/knowledge for me to read its response and for me to say "no, you've over-thought/engineered this and this is actually the better solution", but its very are nowadays for me that it can't find the 1 liner, as long as I've fed in the right context, mostly pre-done because I've spent a bit of time building out the context tree for the repos/systems in a way that allows it to know what it needs to know.
I'm not doubting that people spin their wheels and couldn't find the one liner, but if its as simple as you say, that does seem like people who aren't great at LLMs along with a lack of instinct/experience.
I guess in essence, I think you can use LLMs in an old school troubleshooting way, and I find it still speeds that up the majority of the time. Its basically how I use it most of the time. And like old-school troubleshooting, if you build out the LLMs context over time, it also grows in capability, as long as its being used as a tool and not blindly trusted.
Should I not assume that most senior developers who are serious about LLMs do this?
In my experience at a large bank with unlimited AI, my spend is in the top 5% and I'm leveraging AI just like you.
I was in a meeting with someone who had a bug in an application that I don't own myself on Friday so I told claude,
"I need you to find this bug the user is experiencing, find out if it's user error or a bug, let the user know and tell the developer what needs to be fixed if needed"
15 minutes later the developer ask me if I want it fixed today or Tuesday.
That user could have done the same thing as me, had access to all the same systems and tools as I have, and also received the same AI training I had. The difference is that some users are just not, for lack of better words, AI native.
I've felt that AI can figure out and fix 90% issues, but it rarely does minimal, non invasive fixes. That still requires manual effort. But going from a broad to minimal fix is still a different skillset from actual debugging, so in the the end it does lead to skill atrophy.
I it usually doesn't get me in this weird state of mind, but I once spent 6 months (all-in) building a thing that I, once finished, just left alone completely (on disk gathering dust). Weird experience. So I'd say AI physchosis is real.
But was this team capable of patient, old school troubleshooting before they used AI? I’ve seen someone paid as a senior engineer define the root cause of an outage as “that code was written before our team started here”. (I spent half an hour arguing with him and then ended the RCA).
> The resolution is literally 1 line of code that could be arrived at in about 30 minutes of patient, old school troubleshooting.
This critique (if it can be termed such) admits that the code itself has little value especially compared to the work of “30 minutes of patient, old school troubleshooting”.
In my past experience, developers who critique more-junior colleagues in this way work better in isolation than as part of a team because working as part of a team would require mentoring colleagues through the often difficult process of troubleshooting.
Giving “the team an exact solution on a silver platter” may not be helpful if implementation depends on knowledge withheld because one does not have the resources, ability, or motivation to mentor.
Something about giving a fish rather than teaching to fish comes to mind.
I think LLMs have some of the same risks and benefits of stimulant drugs. They can make you more productive if used effectively as a tool, but they can also delude you into thinking you are better than you are and create a dependence such that you aren't just less productive without the LLM/drug, you fail to be productive at all because you don't know how to function without it.
So how do you build competence in a world where AI is preached to be the most reasonable way to solve problems because it's supposed to be faster than humans?
Are your silver platters producing something faster, better, or cheaper?
Do your silver platters give you some competitive edge? If not, then is the ego problem yours, or your coworkers?
Having said all that, I'm aware of the intoxicating effects of feeling empowered from knowledge. There's an old saying: a little learning can be dangerous....
> “A natural evolution of engineers losing touch with the customers and users”
I’m a neophyte to software teams. I work at an accounting consultancy and deal with lots of SaaS platforms. I’m pissing in the wind about this or that product quality issue through the support queue on a weekly basis. There’s prolly an XKCD comic about it.
It’s a rare company that responds to the issues raised through support. Anything that could make engineering more responsive without degrading the product quality would be welcome to us.
That happens all the damn time... Some otherwise competent developer decides to use AI, and falls into the pattern where AI will pretend to solve their problem for a week, while if they would have to think about it for an entire long hour to discover how to solve it by themselves.
As a bonus, that person will spend half of the week asking their peers for crazy delusional stuff.
I think there are many cases where it was the tech workers themselves who argued for isolation from the customer so that they may focus harder on whatever tasks. I used to be one of these workers. I argued very hard for it. I regret that today.
On the surface it seems rational, but it quickly turns into a system of perverse incentives because now the development team must maintain an illusion that they are constantly overwhelmed with tasks and could never hope to spare a microsecond to assist the customer. This misalignment is how you wind up building your own web frameworks and databases from scratch. It turns into a self serving monster that eventually dominates the entire business. From the perspective of the business, many of these development teams look like they're behind some modern day iron curtain.
If the solution is so simple, why claude did not found it? At this point we can assume, it is better than 90% of engineers (including me).
After three decades of outsourcing to lowest bidder, I do not buy that humans are somehow better!
> patient, old school troubleshooting
I usually see similar arguments around systems with major red flags (no docs, poor CI, decade ago no CVS...). And engineers with private stash of workarounds for job security!
Claude does not do anything special.
Or perhaps claude was misconfigured, it had no access to relevant part of system, and it tryied to work within its limitation. Often it means decompiling binaries in desperate loop...
So after 30 years of outsourcing to the bottom 10%, you think Claude is better than the bottom 90% even though it’s so stupid that it doesn’t even know it should ask for advice or more information when it’s stuck?
Because simplicity is hard and often the result of careful thought. Anybody can keep piling pile of shit on top of pile of shit which is why that sort of code is so common in our industry.
While I actually agree with you (though, outsourcing to lowest bidder would account for much of what you're seeing with humans), I just saw Bug Hunt Bench scores that gave me some pause:
Claude Opus 4.8 ranks near last on this Bug Hunt benchmark, and missed 96% of the deliberately introduced bugs. If you're a developer who has been falling back to Opus 4.8 because of how Opus 5 talks, and Fable 5 being so expensive that it needs to be rationed... well, turns out Opus 4.8 can actually be quite poor for finding bugs.
(Which feels weird to me, because Opus 4.6 fixed a bug that myself and a group of humans had been hunting down for over a decade. Models are spiky.)
Also surprising to me: Luna Max performing better than Fable 5.1 High, at least on this benchmark. But Astra 6 & Fable 5.1 on Max both perform at the top as you would expect.
> At this point we can assume, it is better than 90% of engineers (including me).
Hard disagree. We absolutely cannot assume that. You can posit it, and we can have an informed debate about it. This is what irks me the most about LLM fans: they constantly try to reframe the debate to have their worldview as the agreed-upon starting point.
Author has a good head on their shoulders, but few if any companies are going to spend time on incident simulations for their SREs.
Why not? Because even pre-AI, very few companies spend time practicing restoring their backups, or disaster recovery, or picking infrequently-used runbooks to practice, or seeing whether they can easily rotate secrets without downtime, or trying to redploy the system onto another vendor's cloud/platform, or, or, or... It is the least-sexy operations work that exists. No executive cares about this. Ops organizations push for flashy work, same as everybody else: new infrastructure for new projects, cool chatbots, new flashy dashboards, make charts go up and to the right, etc.
Airline pilots go through disaster simulation training because the government mandates that training. If it wasn't a condition of holding a pilot's license, no company would pay for it.
Want SREs to spend time training for disasters? Take a step back. Support professional licensure. Make it a condition of holding a license. You won't get industry-wide professional behavior until you professionalize the work. It won't happen without licensing because every corner cut that is not immediately visible to consumers translates to additional profit, and increasing competition eventually requires these corners to be cut in order to keep up with competition and stay in business. Forcing all players to submit to licensing requires all players to pay these costs and thus forbids them from cutting them to become more competitive.
I was the head of a global SRE team at a top tier hedge fund.
We started doing a weekly meeting where whoever was on call would do a table top exercise of an outage that happened the prior week.
The idea was to have someone else be the simulated person on call while the SRE from last week's oncall would talk them through the symptoms, what happened and where to look.
The idea was to spread knowledge around how incidents looked, what tools were used, what could have been done differently etc.
This was largely inspired by the following quote:
"Drills are for working on the infrequent actions that lead to big outcomes. A good example is heaving the ball from half court in basketball when the game is close. You can't control who will have the ball in that situation but you want everyone on the team familiar with what to do and how to do it."
How often are there outages? Is there a significant outage every week to do simulations for? The problem with our organization is that outages are so rare that weekly we have nothing to discuss.
Hmm that’s strange, in my experience it is the other way around - Claude is super diligent with infra and will _insist_ on double checking and trying everything for real before committing.
When I was doing this myself I would read the docs and just implement them - claud is going about doing real software archeology to figure if what is said is actually the truth or it’s stale/inaccurate/buggy.
I’ve become 10 times more diligent because it is a lot easier to do. It’s no longer Urgh it’s good enough let’s ship it, now it’s “sure put a leg on it to figure it out and double check it”.
Backups are _tested regularly_ now because LLMs make it cheap to do so.
The only problem is when new engineers who haven’t learned these things Pre-ai now don’t really get why it is needed in the first place and will often lead the agent astray.
I think to address this we need to change or improve our training routines in general for humans. I think a lot of companies nowadays just skip that and deploy a company wide skill/policy for the agents, but don’t transfer the underlying skills to the devs themselves.
> Backups are _tested regularly_ now because LLMs make it cheap to do so.
sighs heavily in 90's sysadmin
Testing backups is not just a question of whether or not the restore command works. Go back and read the Tao of Backup: http://www.taobackup.com/history.html . The application itself (in its current version, with its current features) needs to work with the backed-up data, and the only way to verify this is to attempt to actually work with the data.
If you don't trust your agent to ship to production without manually reviewing the output (in some way), you have no business trusting your agent managing your backups. The agent writing some tests doesn't mean that the tests adequately handle all of your actual scenarios, let alone that your system will adequately handle data that is missing since the last backup.
>Why not? Because even pre-AI, very few companies spend time practicing restoring their backups, or disaster recovery, or picking infrequently-used runbooks to practice, or seeing whether they can easily rotate secrets without downtime, or trying to redploy the system onto another vendor's cloud/platform, or, or, or...
Exact. Let insurance cover it, say sorry to your customers twice and shwoop never happened.
The more I use it, the more I have to rely on it to make changes/ fix things in the same system. In the end, I come out feeling empty; no intuitive knowledge of the system "I" built or fixed.
Code review is important but it does not replace the mental model I am able to build when I do all the steps of software development manually without AI.
No worries, at some point your hit the wall with it and the reality will force you to look at the code. It won't be nice, but until that point delulu land is sustainable enough to fall forward
It's the uncanny valley of AI. It's still not quite good enough yet that you can trust it blindly on a big codebase, so you still have to read and understand everything - which is often harder than just writing it up yourself.
I doubt AI will be good enough to _scale_ many things because human language isn't sufficient to explain it (especially when not understanding what is being built). Humans invented more concise languages (math, C++) to pair with their intellectual acuity. [1]
In one extreme, we have art, which cannot be accurately reproduced or explained in any language (unless a concise language was used to create it, like math or CS art).
At the other end: 1 + 1 = 2 and PI = 3.14...
[1] It seems any language that has a binary outcome (correct/wrong) helps the AI tremendously, however when e.g. creating software, that software is not functioning in isolation. The software is an attempt to codify a fuzzy human system or need, and that information only flows in one direction: human to machine.
I put on AGENTS.MD a prompt that says: teach me something small something about the changes you did if the changes were < 3 tokens if it was more than that teach me more. That's helped me somwhat. So now everytime it changes something it teaches me something about the codebase
i literally tell it "explain it like a 5 year old can understand" and "keep it under 100 characters".. helps somewhat (its still an llm so caveat emptor)
I find that it helps a little to maintain an iron grip on the design. Take the time for really detailed change planning. Be pedantic and push back against every little thing that seems wrong or even a little odd in any plan document the LLM spews out. Likewise, watch for the for the moment when the LLM eventually stumbles and starts to make excuses for deviations from the plan. Interrupt immediately and force it back onto the plan (or your vision), potentially with pointers to resolve immediate problems. Completely unattended agents just don't work for important code.
>The more I use it, the more I have to rely on it to make changes/ fix things in the same system. In the end, I come out feeling empty; no intuitive knowledge of the system "I" built or fixed.
Most of us build a system to deliver a product to make money. We don't feel empty for not knowing how the system works, since we don't really care: it's just a means to an end.
> Most of us build a system to deliver a product to make money
Shouldn’t it be to deliver a system that is sold as a product? And even then that product is sold to consumers to solve their problems. Not knowing how it works means you don’t know what solution you’re selling.
You can see that in a lot of product announcement where the focus is on what they’re building, but not on how it solves some problem. The consumer is absent from the design process.
The more code writes autonomously, the less intuition the human owners have about that code. Loss of intuition is a seed of technical debt that grows with time. Over a long enough horizon, it can make looking at your own codebase feel like the first day on the job (sometimes at a company you started).
Luckily, there are ways to mitigate this and essentially translate those human intuition of how the codebase “should” be into guardrails for the agents. But without that, your setting your sails in a stochastic sea where each wave looks nothing like the last.
I think this has as much to do with how hard software became to understand as with the new shortcut to refusing to understand it and the shortsightedness in willing to take it.
We lost a lot of traction in the name of ease of staffing and speed. Using LLMs to generate more code that is harder to understand it catalyzes it but the root of the problem, in my opinion, was letting go of great design and deep understanding for short term profit.
I've been thinking about this lately - is it like using 3rd party libs to achieve stuff faster? As much as I would lovr to hand craft the datetime logic in my app, I might as well use luxon and invest this time somewhere else. Only now with llms, you get virtually infinite 3rd party libs you can use, you create them on the fly. So if you have strong engineering values, I would say simply it boils down to "contracts over programs", you can still be in touch with the logic that glues it all together and treat some logic as a blackbox the same way we do with 3rd party libs?
It's not just about it feeling like a 3rd party library but it's a library that's at risk of changing significantly after every 'update' without warning.
Atleast with a well built library you know the contours and how it fits into your larger system
It's not because with libraries you have a boundary somewhere and can decide to not care what's inside as long as the interface is stable and well designed. The problem of course you need to prioritise building well designed interfaces and decouple components from each other, and that's a skill most developers aren't good at.
Considering how many compromises and problems third party libraries have caused recently, I would say the comparison is apt - if you don't know what you're shipping one day it might explode on you
I see aviation sentiment raised from time to time. In aviation failure is catastrophic, and systems you operate do not change on the fly (pun intended).
You can probably drill SREs that way but you are only teaching them how to _react_ efficiently, not how to _fix_ unique unicorn root causes of these failures. Aviation analogy would be an airplane engineer that tries to drill himself for in-flight engine failures AND engine debugging / engine redesign both at the same time.
It never made sense in software engineering, and never will. Minute spent on drills is a minute better spent on reworking codebase to reduce changes of future incidents. This post is very SRE centric.
Pilots aren't expected to be design engineers and SREs aren't expected to be software developers.
At least in my experience, operators and on-call engineers aren't necessarily responsible for remediation and validation.
Before you take me too literally, there is, of course, an overlap of skill and trade, but I believe the pilot analogy is more apt than you argue. I do agree that the difference in consequence and stakes is meaningfully important, however.
I've seen a variation of this where random engineers are pulled into production incident calls and engineers are not expected to be familiar with the system.
They were asked to "just use AI" and understand the component, triage the issue, build a fix etc. The engineer was forced to choose between accepting a potentially mediocre fix AI has suggested or risk being coming across as an incompetent resource who doesn't know how to leverage AI.
You can guess what the engineer chose. The fix wasn't bad but it was suboptimal for some edge cases. We had to later revise it. Have enough of these situations, engineers will eventually definitely give up understanding the system in detail.
I work with programmers and it's not uncommon that they can remember with shocking detail about code they've written in the past.
Someone might mention an issue that has cropped up and they'll stare off into space for a few moments and actually remember where that issue stems from in the code, because they remember writing it like 8 months ago.
This skill will be lost when AI is generating all code, we'll be stuck in a perpetual loop of having AI keep track of the state of the code in order for AI to extend and maintain it.
I mean I think this is just how AI already operates. I’ve seen multiple models go digging in the git blame or past PRs, and even unmerged PRs. When agents work on a project that has well-defined in-repo docs, agents normally update them without prompting. So I doubt this will be a big issue for AI, but agreed we’re losing a skill
If capability increase continues as it has, then an incident that cannot be resolved by AI will stump humans no matter the practice.
I like the plane example from the article,but I think in reality it will be like code. 1.5 years ago engineers would routinely say that they still write code by hand here or there to keep their skills sharp, and that's just not something you hear much if at all.
If an SRE is faced with a situation an AI can't solve, then said SRE will use the AI systems to triage further, point it to different places and so on.
This works for SREs with pre-AI experience and intuition, possibly less so with new recruits coming in post-AI. I don't know what the solution to this is, maybe practice drills is it, but I have a hunch the entire field will be subsumed, same as many other engineering fields.
There is only so much need for taste and judgement, before even that has been incorporated into the models.
It’s tough. The models can at this point very quickly identify issues in a Kubernetes cluster, for example. This because these systems give you a TON of observability, and it can easily see all the different moving parts.
That doesn’t mean the proposed solution is always right, but it is absolutely landing on the root issue faster than most humans would be able to, even pre-AI. Just because it can remember and run through a bunch of commands more quickly that I can.
There are lots of incidents where the symptom doesn’t always clearly point to the issue, so having something that can fairly exhaustively check a lot of different things very quickly is pretty useful!
But I at least partly agree, I think the more complicated and obtuse a system is, the harder it is for AI to do this. But we’ve invested time in making systems much more straightforward to understand and operate from one place (Kubernetes in general), and AI thrives on that.
And yeah, it means your debugging skills wane a bit because, yeah, if the bot can diagnose the issue in 5 minutes, it’d be irresponsible to not use it.
And I’m not really happy about it, and personally I’ve always been able to figure out a tricky bug given enough time. I don’t want to loose that skill. But everyone is under a lot of time pressure these days.
Like the fact that software "engineering" is mostly nothing like real engineering (and it’s further regressing now due to LLM coding!), the general lack of drilling is again one of the things that make software-related stuff look really naive and amateurish from the perspective of those dealing with the real world. Imagine if the military, police, fire service, and so on did not drill and rehearse incident response?
There are drills, tho. It's just that usually they're only done above a certain level. Small companies, "lean" teams and so on don't have (or didn't have) the capacity to implement all those things. Maybe with the exception of netflix and their chaos thing (bring down systems regularly to make sure the whole still works).
But that's also likely to change with AI assistance. Even an "average" system is better than none. So now teams will have the capacity to bring that in to their systems. Backups / recovery drills that are actually tested (either because they're implementing testing or because the AI screws something up and they need to recover). Either way, it'll be included. Same for security ops. And devops.
I still strongly believe that AI assistance is a catalyst / accelerator, and that the "floor" will rise in most domains. So a small team that only had bandwidth to deal with the happy path previously, will now be able to start incorporating processes and procedures that were historically only done at corporate level. And that's a good thing. Even if it won't look like that in the beginning. But we'll get there, eventually.
> If capability increase continues as it has, then an incident that cannot be resolved by AI will stump humans no matter the practice.
I disagree with this. Whatever the AI produces must be embodied in some kind of information system. The moment the output is on disk, it's fish in a barrel for any competent operator.
I've worked in environments that are beyond the pale with regard to complexity. It will take AI another 10 years to product something as complicated and coherent as a semiconductor manufacturing operating system, which is clearly feasible for humans to manage today.
If you are in a situation where you dont know what happened when something goes wrong, the business incentives will not accept “its too complex” as an answer.
Firms aren’t just selling products, they are selling reliability and taking on liability.
Nah, LLM models are already the new compilers. A commodity only engineers know how to use (in the context of software engineering in production environments)
Out of context, but to address "AI will replace engineers".
Recently discussed something about economy/investing with a friend while at work at a slaughterhouse. I really didn't want him to get scammed buying crypto.
So, used ChatGPT to find some sources in Somali, a 3 videos with short description why it's worth watching. Intro into investing, intro about cryptocurrencies and about buying them. Had the text shortened down to 3 pretty short paragraphs, not more than twice this post.
He's a smart guy, but only went to primary Qur'an school. Doesn't read or such, mostly consumes internet in form of video/media. He couldn't read those 3 paragraphs, it was too long. Or rather, it wasn't just 3 paragraphs, it was a lot to read.
Maybe we're already dividing into murlocs and the surface dwellers?
Despite not having written code for about 6 months due to using Claude etc, I've surprised myself with how much the "muscle memory" of leetcode etc has come back to me.
I say this b/c I think the veterans with years of coding, debugging etc experience can just pick back up the skills they need even if they're a bit rusty.
The junior folks on the other hand, I'm not so sure. Friends of mine that hire straight out of college are saying that a combination of going to college during COVID + LLMs + "cloud is all you need" has resulted in juniors who don't know how to solve problems nor architect basic software.
I guess we are all on some kind of chart where the slope of losing the experienced people who know what's going on and AI getting so good we don't need people are going to intersect at some point. And that intersection may be later than is good for society and engineering overall.
This is why the paradigm for AI use should not be automation but rather the cyborg. Under automation, people are less active and engaged and become mere operators of automated processes. They become slaves of the machines. Under the cyborg model, they arrange the machines in a way to make people masters of a universe that includes the machines helping them be that.
Anyone who's worked in tech in a large company will probably have experienced having an ops team who use RPA tools to do repetitive tasks that tech teams get the blame for when things break. AI will make this so much worse. Things will break, everyone will assume 'tech knows the system', but really it's a new process outside of the tech teams that someone vibe coded but got it wrong.
Audit trails, logs, and tight data governance where things can only be accessed with proper roles is the only possible solution.
If an RPA team ever gets direct access to a production database in your company, look for a new job.
> Robotic process automation is a type of business process automation that automates tasks within business and IT processes using scripts that mimic human interaction with application user interfaces.
For anyone else wondering what RPA means. Never heard that abbreviation before.
In practice, it is screen-scraping on meth. Horrible stuff. I understand that it's the only option available for some systems, but any client who asks for RPA support when APIs exist for the same data ought to be fired, or at least given a very stern "No."
This is the same problem as the "AI drives the car until it can't" situation. Feel free to doze off so long as you can wake up and instantly have world class racecar "save the situation" reflexes. Hope isn't a strategy but that's what all of this feels like.
There's an interesting dynamic, too. Even if an engineer reads the output of the AI and understands the root cause of the problems and how to diagnose the incident, somehow it's hard for them to internalize the learning and apply it next time to a new incident. As a result, the engineer loses touch with the system anyway.
It looks like our brains somehow have to experience the failures during a diagnosis and in gemerak perform this kind of pathfinding by themselves to truly understand the system. I don't know if this has to do with how our brains actually learn.
So looks like you pay AI to resolve incidents and then pay money and time for engineers to get training on synthetic incident resolutions.
The comparison with Pilots is bit disjoint one cause the domain varies a lot for every company and product. Coming up with synthetic simulations within every domain is like paying money twice for the same thing, why not let the engineers to handle the real incidents in the first place itself. In fact why not spend some more thought into building better systems.
This is the same challenge aviation had with an over-reliance on automation. You end up with pilots that can’t fly the plane when it really matters. Look up the Asiana crash at SFO which is a lesson in what will happen to engineering orgs that over-rely on AI.
Isn't there anywhere to "go" from here? In the last decades, introducing new high level abstractions on top of existing paradigms naturally had everyone move up the ladder and work at the next higher level, why should this be different these days? Do we think AI will reach the top of the abstraction ceiling, so there's no where to go from here?
This isn't abstraction though. Outsourcing is a better term.
If things continue moving up that latter, you will see that your agent/agency will pass the buck too. But there should always be some last turtle. Maybe that turtle will be the human that thought he was climbing the latter, who knows.
Coding via LLM is not similar to using an abstraction. Imagine a car. The controls like steering wheel, the pedals, the gear levers. Those are abstractions.
But using LLMs are like driving using a remote control that has probabilistic behavior. You just loss what it feels to be in a car and you fail to improve as a driver because of the erratic remote control.
Meta: The blinking cursor of the "logo" of the blog being sticky in the top left corner makes it impossible for me to read the text. It constantly fires interrupts at me.
Depending on what your goals as the author are, you may or may not want that.
Being able to scroll it out of view might be enough to achieve the aesthetics goal, and the goal of people actually listening to you.
The internet for me (and increasingly non-internet programs) is unusable at this point without excessive modifications. It's hard to imagine what it's like being unbothered by it all.
One time I had to do a system optimisation to increase the throughput of messages and was using Claude with Datadog and Couldwatch MCPs to figure out the bottlenecks by running load tests. it was Opus 4.8 and one of the most frustrating interactions with Claude I ever had.
It was just making up random stuff about AWS and system resource limitations and when I was asking for the source like from where it got that info, it was like, “I’m sorry I prematurely concluded that without checking sources”.
I would never trust an Agent to resolve incidents ever
I agree with the sentiment but unless it leads to better financial outcomes for them to A) have engineers on staff and B) have them know their systems then enterprise will continue looking for reasons to shed all the engineers and just leave everything to AI. Anecdotally I think most companies are still looking for ways for AI to help them shed headcount so raising this alarm doesn't mean anything to the decision makers at the top.
This has already happened in other areas. I'm old enough to remember when customer service people spent all day handling customer problems themselves, which gave them the understanding needed to solve more unusual problems.
These days they do what the computer tells them. Even if they could solve the problem they don't have the agency. They can only select from the options they are given.
In software we still have the agency but we are giving away the understanding. The agency will follow.
You’d hope these AI incident responders have very constrained production tools to fix things. You’d hope the humans remain familiar with those tools and they are incredibly well documented.
I think the biggest loss is now not knowing if what the agent is claiming was actually done:) but yes, right tools are necessary, adding a boundary will change the position, being out of touch will be recoverable. Otherwise one bad call might be unrecoverable and no amount of familiarity will save you
I like the idea of simulations - maybe not in the flight simulator sense of a fixed rhythm, but more in the training in using the tools quickly sense, like a chaos monkey in your log search. My most memorable exam was Certified Kubernetes Administrator (CKA), the hands-on simulation part was exhilarating.
When someone else -whether AI agent or a human- solves the recurring minor problems for you, those problems become non-issue, get swept under the rug, just to accumulate more dust.
One day, those may become bigger as they are forgotten, causing havoc. The standard root-cause-analysis depending on systems having certain retention period, which may be expired at that time.
It is important to get real hold of one's systems from end-to-end aspect, which holds true for both AI and human operators...
I’m not sure who will be solving these incidents if 99% of incidents will be “solved” by LLMs. If I’m called once a year my daily rate will be my yearly rate?
We’re entering a new phase of software development, and with every phase there are new challenges.
Some questions the author might want to first answer:
1. If AI is constantly reacting to smaller incidents, is it surfacing larger issues in your codebase and architecture?
2. What kind of new telemetry do we have to build?
3. How do we build new deployment systems that help us validate fixes without requiring hours to go through traditional CI/CD systems
I’m old enough to remember the days when engineers would monkey patch their code on live servers with additional logging and metrics to learn about failure modes during incidents.
Wasn't that the idea? Withe cars on roads, didn't we literally lose the touch with the ground? I guess the desire was to "lose" touch with all dirty and hard work areas.
That's what the linked article is talking about. Training for extreme failure.
Sure you have self driving cars and everything that make you more and more disconnected, but still highways more dangerous to drive whenever there is a storm or ice on the road. For the same reason, driving tests are harder in the north.
"On a silver platter" lol The old phenomenon: give the cashier at the convenience store exact change and they will be like, d-uh. Because automated cashiering.
This article leads up to a hypothesis presented without evidence.
Yes, it's clear that if AI agents handle routine issues then only the most complex issues will be handled by humans. In no way does it follow that humans will be less prepared to handle those incidents than they are now; by definition, this class of problems have no rote solutions. Each issue of this type already requires deep system knowledge to remediate, and still will. Software is not aviation.
What we are seeing here is an instance of the more general trend where experts are still required to operate complex systems, but AI is destroying the career path that creates those experts. That's what we should be worrying about, not that people are going to be spending less time rebooting boxes. This isn't something you can fix with a "simulator."
I read the article before commenting, as is my habit. A disagreement is not always a failure to process.
To be very explicit, my problem is that the article argues that simulation will be a suitable substitute in the software space, as it is in the aviation space. I see no evidence for that; it's pure hypothesis taken as fact.
The article does not get the point. What aircraft companies did was separate training and work, and SRE/IT typically does not.
An AI can handle routine incidents and then present learning cases from that routine work for training, because the skill in SRE is not the mechanical log grepping, grafana dashboard browsing etc but forming the hypothesis. AI incident reports can create training cases that are a much better training for hypothesis forming and testing than the work itself can.
I feel a lot of comments here are missing the forest for the trees.
We do not yet have the next generation systems that will manage AI creation and maintenance of systems.
Humans have been making spaghetti code systems and maintaining them poorly for years. Best practices developed… eventually. But certainly not in the 70s and 80s. Spaghetti was the norm for quite some time.
The development paradigm has changed. Forever. You can’t expect yesterday’s tools for managing software development to succeed at this point. We’re still roughly on year one of this transformation.
The new bottlenecks are creating and enforcing boundaries in the code, identifying level of risk within a boundary, subjecting high risk areas to more intense human review and architecture reworks, and so so much more manual testing.
We need a new language for high level development that focuses on architectural constraints. We need analysis software that helps draw boundaries, identify what needs extended human attention, and helps us map and understand a rapidly developing code base. We need to standardize on the use of frameworks and languages like we have on assembly variants.
I’ll bring up a hacker news trope here. NaughtyDog’s GOAL was an amazing system that was a product of an underdeveloped ecosystem for game development at the time. They used lisp and assembly because you still had to write assembly for performance reasons then.
We are in a very similar period. The ecosystem is underdeveloped. We should be looking for new languages and tools to manage this.
CNC machines used to run from punch cards and then hand written NC code. Now we have advanced CAM software. (Which innovative people are actually running with LLMs!)
Some already developed even earlier and most ideas were already there in the 80s. The problem was just that the field was growing so fast that it was filled with people without formal training or fresh out of university. That way the knowledge did not spread.
For instance the 1986 paper „no silver bullet“ already described the need for iterative approaches later described as agile.
> We’re still roughly on year one of this transformation.
OpenAI Codex was released in 2021. Artificially compressing what we see now to one year of growth is an example of why it's very hard to trust anything AI proponents say.
Ironies of Automation is front and center in this article which is awesome. Many of the conversations on AI automation are describing or rediscovering the insights the paper covered.
I recently had some issues with a game not working well on my Intel Arc B580. OpenAI (Anthropic's models definitely could too) ran some profiling inside of Windows, captured a few GB of data, sifted through it, identified the guilty .dll's and approximately where the issue was and traced it down to a single user-toggelable Unreal Engine 5 launch flag, which resolved it.
I feel like AI could easily do the same for servers and various software, BUT you gotta ground it in actual data so it can't make the shit up and just spew out garbage (if you tell it to come up with a potential answer it will even if it doesn't have the proper data to be "sure" of it).
I don’t find this to be the case. I use AI to help investigate and gather evidence much more efficiently than I could ever do manually. Then, I work through the evidence and possible failure modes given the observations with AI. It’s the exact same process I’d follow with a talented co-worker. Does it matter they are driving?
My intuition and instincts have been honed from years of troubleshooting complex systems so I find it refreshing not having to write probe scripts, queries or code under pressure. I can have a theory and test it very quickly and if it’s not the problem, I can quickly try something else. This greatly improves the time it takes to find the real root cause. Once found, I can do more elaborate testing that I might have skipped before due to complexity or time constraints to really have higher certainty.
If there is ever a time where the model does something I don’t understand, I ask it to explain it to me and I increase my knowledge of the system accordingly. It’s always patient and explains things in such depth without any sighs, patronizing, sarcasm, juxtaposition, etc. So refreshing!
I much prefer working with AI than any co-worker and I find I’m far more productive and efficient, especially with bugs and dealing with incidents. There’s no one to convince or argue with, no ego’s to trip over. It’s lovely.
Prediction: this won’t happen. The abstraction will be good enough and people will need to know only as much as they need to know- things will stabilise at the equilibrium.
Good article and I like the callouts to the aviation industry. For me what's missing is the author should also have touched on CRM and SRM.
Also, that paper "The Ironies of Automation" is one that everyone should read. It's fairly short.
There is a related problem in terms of these situations where the computer system is handing off to the human. It's called "the bumpy transfer of control." Very fascinating concept.
The way forward is clear. Improve the AI such that the hardest incidents can be handled by AI alone. Whether we want this or not is independent of the trendline which points to this future regardless.
Imagine a future where humanity understands none of the underlying technology and AI just babysits us on a daily basis. Wall-e.
Programming will devolve into unintelligible anti patterns and will be written in convoluted languages humanity doesn’t understand. But none of this matters because AI will be handling all of it.
I run an IR company focused on specific security response emergencies.
AI use across my company is variable and I don’t allow any enforcement of mandatory using or not using of it.
I view and tell my employees to view their skills as that of a high-performing athlete. Consistent training of the basics, rapid fire what-if testing, weekly scenarios are all part of the upkeep.
In short, this is what it takes to keep up the skills no matter if you do or don’t use AI and I can imagine the degradation is much faster if you don’t train AND delegate all of your activity to AI.
You rather generously assume engineers are in touch with their systems.
Even before layoffs many teams just maintained things org has long lost coherent knowledge of
After layoffs and typical org knowledge churn - you can either rewrite it (but how? Product team responsible for original implement requirements is long gone too) or recoup (reverse document) some of that lost knowledge with AI and actually learn
I am exceedingly tired of poor metaphors that are popping up since AI has taken over writing.
No, operating software is not like operating a plane. Not at all in fact. The people operating the software and resolving incidents are the same people who created the software in the first place, and continue to work on it day to day. Pilots have not and don't.
I'm not sure if I agree with the plane analogy either. Aren't planes supposed to have exceptionally stable hardware and software platform? Does that not significantly reduce failure modes? Most production software by comparison is constantly evolving. Unless you design very simple or basic training examples, most of it's going to be out of date soon.
The former CTO of a large MSP software company once told me on a call the reason their product had so many features removed with price increases was "you can't maintain a plane while it's in the air"
The immediate response was "We don't, your updates bring the on prem RMM down for hours at a time, the plane is grounded for maintenence regularly"
A natural evolution of engineers losing touch with the customers and users.
I'm noticing some of the concern play out regarding AI weakening the capabilities of software people.
I gave the team an exact solution on a silver platter and they still failed to identify how to go about it after 3 days slamming it into Claude. The resolution is literally 1 line of code that could be arrived at in about 30 minutes of patient, old school troubleshooting.
I think what's happening is the AI system draws poorly aligned and led engineers into this ego inflation feedback loop where they are completely detached from reality because these tools can simulate a better one.
> 30 minutes of patient, old school troubleshooting
This is also the best way to understand a codebase, and it's quite enjoyable.
I think the models are getting too egotistical. They're so confident of their fixes they won't bother suggesting basic techniques like isolation of the problem by disabling code paths, for example. They'll keep shotgunning less-and-less likely fixes with undiminishing confidence until the code is full of fixes that do nothing. Then they'll double down on why these should be kept.
> and it's quite enjoyable
Used to be somewhat enjoyable. Nothing pleasant about digging around codebase that was heavily affected by the last 12-18 months of AI-ing.
32 replies →
I have no evidence at all, but could it be that repeating the same thing over and over again in the context makes models latch on to it wrongly and gives them more confidence despite it being wrong? Kind of like a sunk cost fallacy…
Although I do acknowledge sometimes they too point out something I thought was quite right but turns out of be wrong…
1 reply →
It's the uncanny valley of AI. It's still not quite good enough yet that you can trust it blindly on a big codebase, so you still have to read and understand everything - which is often harder than just writing it up yourself.
EDIT: don’t get me wrong. I still think AI is incredibly useful for a lot of tasks! But when implementing an architecturally hairy thing, I find it less stressful and equally quick to jump down to the editor level and use AI just for code completion.
Pretty much, The one thing I use it for is as a sanity check, pretty much "Look at <SomeFile>, point out issues you see, summarise them tersely" and it'll spot stuff a code review by a human might have spotted (in the mythical land where people actually do code reviews properly and don't just flag a spelling mistake to "show they looked at it").
Beyond that I don't trust it at all and I still write all my code the meat sack way.
Trust is earned not given and it hasn't earned it yet.
9 replies →
> It's the uncanny valley of AI. It's still not quite good enough yet that you can trust it blindly on a big codebase, so you still have to read and understand everything - which is often harder than just writing it up yourself.
You might as well have left it with: "It's still not quite good enough yet that you can trust it". That's the core of the issue. It doesn't matter what you ask it to do, it can't be trusted. Some things are just easier to verify and correct than others.
1 reply →
Nah, It's not even good for small code changes.
Try using it with Ansible. It spits back complete buffoonery.
7 replies →
I agree, except for the use of the word "yet" .
I think what's missing is fundamental. I think the reason it sucks so much to work with LLM-generated code is that LLMs will never "know" what it's like to be human. They don't "understand" our frustrations and motivations, and they're missing the vast array of useful mental tactics we've evolved to cope with corporal existence.
At this point I think progress towards a good colleague bot would require a new architecture which allows continuous leaning, and for the LLM to be raised as a human child (maybe in a simulation at 1000x speed or something).
I'd say it's more about learning how to organize your work more efficiently.
If you think about a product like marble: it's something that most be chiseled out of time.
Some people can chisel better products: the AI is just a better chisel.
Sometime still has to guide the chisel and judge the art/product.
In our cases, the market judges products.
9 replies →
I think the speed/context size of the large models is a threshold. I've been using a local model and watching it do killer stuff, and also shit out useless things; all in real time, requiring active steering.
Your assumption is that LLMs will ever leave this uncanny valley.
Maybe unforeseen breakthroughs and different architectures are achieved. Given LLM fundamental shortcomings grounded in mathematics and information theory, I highly doubt they will and we will always need to deal with these issues in some capacity.
3 replies →
I'm seeing this happen in the security space right now. Someone on my team I was helping train and bring along is all of sudden regressing in their understanding of the issues we're working on, and instead focusing on AI tool outputs to do their job for them.
I can share a weird story:
Usually, I take my time to understand each keyword of the code I'm looking at, especially if it is new to me, like terraform.
I work in a team/with one architect, who only did the DevOps/Infra stuff for the past years and I had the expectation he knows what he is doing and talking about.
At around 2 weeks, I noticed how his knowledge has severe gaps and how he takes things at face value or uses terminology interchangably, which confuses me. It sounds plausible, but it does not actually translate into a working system or shared understanding.
Then one day I did some pair programming with him and whenever there was an error or a resource missing, he would type it into the LLM, copy paste it out of it and then brute force error messages. He did not even wait a second to think or reconcile whats happening on the screen or what the exact requirement is. Never taking one step back and questioning any assumption.
Now that the timeline is shifting and everyone starts to be stressed, he continues to vibe code through me and it is so tiring, there is no higher level planning or architecture, its just a reactive type of trial and error to be faster. It feels like these people are so used to talking to bots, that they treat you like an agent they can chat to or talk through monologs with.
It is quite shocking how people went from being humble (learn the basics or close the gaps in understanding) to full on authority on everything and berating people 24/7...
So right now I'm considering quitting IT for a couple of years until people calm down, but I think its pretty futile
45 replies →
In my mind, this, not copyright or water use, is the best reason to boycott AI. It'll make you incompetent.
I saw this the past year - new employees would put problems into Claude first instead of debugging. A year back I was debug manually first, now I do the same.
The speed AI debugs at is incredible and yes, we lose touch the more we use it like any manager feet up barking orders to their underlings to get things done.
At least at my company the OKRs are quite clear and demand heavy AI utilization above all else
To be fair the cyclical nature of funding and defunding security teams which causes scaling up and scaling down, has always left a race to the bottom in security.
Any CISO or head of security loves the ideal of completely using AI to handle incidents, tune detections, implement mitigations, track vulnerabilities, pen testing, etc. This feels like it driving security teams to have less critical thinking.
What is your relationship to this team? Their manager? A senior colleague? Something about this sounds like a failure of communication or leadership. Why are you stand offish from them? Why are you treating them like children? If they don't know what they're doing why did you hire them? Now that you did why are you treating them like a burden and not an opportunity to mentor, teach, and uplift?
You can't force someone to improve themselves. AI-fueled ego trips are really difficult to sublimate. The only viable solution in this case is to overwhelm the pupil with mastery. Demonstrate that even without AI assistance that you can run circles around their solutions. If someone actually came to me and asked for advice on something, I cannot imagine I would turn it down. Many developers are absolute monsters. Pretending like that is not the case only makes the whole thing worse.
I also read that comment as an adversarial situation at work.
It used to be that when someone else at your company was asking for something that wasn't a priority, you would erect bureaucratic roadblocks to protect your time. Now, the new normal is to just forward their questions to AI and sling the slop back over to them.
2 replies →
When I hear this I do wonder to myself how they're using AI.
For me, as long as I'm properly RPI looping it and not blindly pressing "yes" then it will nearly always reach the solution, usually a fair bit quicker, because it effectively becomes an ideation machine that can keep more thoughts and knowledge in it than my brain can.
However, I'm using it through giving it the context, it has access to the repos, access to the sytems, I'm telling it where the logs are, I have docs to show it what each part of the system is for.
Along with that, it does depend on my own instincts/knowledge for me to read its response and for me to say "no, you've over-thought/engineered this and this is actually the better solution", but its very are nowadays for me that it can't find the 1 liner, as long as I've fed in the right context, mostly pre-done because I've spent a bit of time building out the context tree for the repos/systems in a way that allows it to know what it needs to know.
I'm not doubting that people spin their wheels and couldn't find the one liner, but if its as simple as you say, that does seem like people who aren't great at LLMs along with a lack of instinct/experience.
I guess in essence, I think you can use LLMs in an old school troubleshooting way, and I find it still speeds that up the majority of the time. Its basically how I use it most of the time. And like old-school troubleshooting, if you build out the LLMs context over time, it also grows in capability, as long as its being used as a tool and not blindly trusted.
Should I not assume that most senior developers who are serious about LLMs do this?
In my experience at a large bank with unlimited AI, my spend is in the top 5% and I'm leveraging AI just like you.
I was in a meeting with someone who had a bug in an application that I don't own myself on Friday so I told claude,
"I need you to find this bug the user is experiencing, find out if it's user error or a bug, let the user know and tell the developer what needs to be fixed if needed"
15 minutes later the developer ask me if I want it fixed today or Tuesday.
That user could have done the same thing as me, had access to all the same systems and tools as I have, and also received the same AI training I had. The difference is that some users are just not, for lack of better words, AI native.
10 replies →
> RPI loop
What's that?
3 replies →
I gave the team an exact solution on a silver platter and they still failed to identify how to go about it
I think what's happening is ... poorly aligned and led engineers [in] this ego inflation feedback loop where they are completely detached from reality
A story about a team of humans with some very human problems.
I've felt that AI can figure out and fix 90% issues, but it rarely does minimal, non invasive fixes. That still requires manual effort. But going from a broad to minimal fix is still a different skillset from actual debugging, so in the the end it does lead to skill atrophy.
I it usually doesn't get me in this weird state of mind, but I once spent 6 months (all-in) building a thing that I, once finished, just left alone completely (on disk gathering dust). Weird experience. So I'd say AI physchosis is real.
But was this team capable of patient, old school troubleshooting before they used AI? I’ve seen someone paid as a senior engineer define the root cause of an outage as “that code was written before our team started here”. (I spent half an hour arguing with him and then ended the RCA).
> A natural evolution of engineers losing touch with the customers and users.
I disagree. I think this happens as soon as the MBAs come on board, where everything becomes a metric, and you work towards OKRs.
It's okay, they'll fix it by asking AI to design their training courses for them. That'll fix everything, right?
> The resolution is literally 1 line of code that could be arrived at in about 30 minutes of patient, old school troubleshooting.
This critique (if it can be termed such) admits that the code itself has little value especially compared to the work of “30 minutes of patient, old school troubleshooting”.
In my past experience, developers who critique more-junior colleagues in this way work better in isolation than as part of a team because working as part of a team would require mentoring colleagues through the often difficult process of troubleshooting.
Giving “the team an exact solution on a silver platter” may not be helpful if implementation depends on knowledge withheld because one does not have the resources, ability, or motivation to mentor.
Something about giving a fish rather than teaching to fish comes to mind.
Are your silver platters producing something faster, better, or cheaper?
Do your silver platters give you some competitive edge? If not, then is the ego problem yours, or your coworkers?
I think LLMs have some of the same risks and benefits of stimulant drugs. They can make you more productive if used effectively as a tool, but they can also delude you into thinking you are better than you are and create a dependence such that you aren't just less productive without the LLM/drug, you fail to be productive at all because you don't know how to function without it.
That sounds somewhat applicable to many tools. Like Vim/Emacs, for example. Or computers and smart phones in general.
5 replies →
Sincerely , I think you're blaming the AI incorrectly there. You just got incompetents on your payroll.
So how do you build competence in a world where AI is preached to be the most reasonable way to solve problems because it's supposed to be faster than humans?
8 replies →
Incompetence is implied by slop usage.
incompetent people, surely?
Are your silver platters producing something faster, better, or cheaper?
Do your silver platters give you some competitive edge? If not, then is the ego problem yours, or your coworkers?
Having said all that, I'm aware of the intoxicating effects of feeling empowered from knowledge. There's an old saying: a little learning can be dangerous....
> “A natural evolution of engineers losing touch with the customers and users”
I’m a neophyte to software teams. I work at an accounting consultancy and deal with lots of SaaS platforms. I’m pissing in the wind about this or that product quality issue through the support queue on a weekly basis. There’s prolly an XKCD comic about it.
It’s a rare company that responds to the issues raised through support. Anything that could make engineering more responsive without degrading the product quality would be welcome to us.
That happens all the damn time... Some otherwise competent developer decides to use AI, and falls into the pattern where AI will pretend to solve their problem for a week, while if they would have to think about it for an entire long hour to discover how to solve it by themselves.
As a bonus, that person will spend half of the week asking their peers for crazy delusional stuff.
I think I've heard late-career engineers from the past century say similar things, although I can't remember exactly quotes.
I wonder if every generation of engineers ends up with such hand-wringing about the next.
I'm also genuinely curious what fraction of the time they were right to worry.
I don't think it's engineers, it's the rest of the org insulating the tech workers from every side of the business
I think there are many cases where it was the tech workers themselves who argued for isolation from the customer so that they may focus harder on whatever tasks. I used to be one of these workers. I argued very hard for it. I regret that today.
On the surface it seems rational, but it quickly turns into a system of perverse incentives because now the development team must maintain an illusion that they are constantly overwhelmed with tasks and could never hope to spare a microsecond to assist the customer. This misalignment is how you wind up building your own web frameworks and databases from scratch. It turns into a self serving monster that eventually dominates the entire business. From the perspective of the business, many of these development teams look like they're behind some modern day iron curtain.
If the solution is so simple, why claude did not found it? At this point we can assume, it is better than 90% of engineers (including me).
After three decades of outsourcing to lowest bidder, I do not buy that humans are somehow better!
> patient, old school troubleshooting
I usually see similar arguments around systems with major red flags (no docs, poor CI, decade ago no CVS...). And engineers with private stash of workarounds for job security!
Claude does not do anything special.
Or perhaps claude was misconfigured, it had no access to relevant part of system, and it tryied to work within its limitation. Often it means decompiling binaries in desperate loop...
Claude regular spits out six helper functions instead of... A twenty line for loop. It overengineers most things.
Overabstracting, deduplicating things that don't need to be. Building metaclasses because it saw a single orchestrator in the whole codebase.
If it is a better engineer than you... You need practice.
25 replies →
So after 30 years of outsourcing to the bottom 10%, you think Claude is better than the bottom 90% even though it’s so stupid that it doesn’t even know it should ask for advice or more information when it’s stuck?
4 replies →
Because simplicity is hard and often the result of careful thought. Anybody can keep piling pile of shit on top of pile of shit which is why that sort of code is so common in our industry.
While I actually agree with you (though, outsourcing to lowest bidder would account for much of what you're seeing with humans), I just saw Bug Hunt Bench scores that gave me some pause:
https://x.com/PawelHuryn/status/2095982259761475945
https://bughunt.productcompass.pm/?preset=all
Claude Opus 4.8 ranks near last on this Bug Hunt benchmark, and missed 96% of the deliberately introduced bugs. If you're a developer who has been falling back to Opus 4.8 because of how Opus 5 talks, and Fable 5 being so expensive that it needs to be rationed... well, turns out Opus 4.8 can actually be quite poor for finding bugs.
(Which feels weird to me, because Opus 4.6 fixed a bug that myself and a group of humans had been hunting down for over a decade. Models are spiky.)
Also surprising to me: Luna Max performing better than Fable 5.1 High, at least on this benchmark. But Astra 6 & Fable 5.1 on Max both perform at the top as you would expect.
2 replies →
> At this point we can assume, it is better than 90% of engineers (including me).
Hard disagree. We absolutely cannot assume that. You can posit it, and we can have an informed debate about it. This is what irks me the most about LLM fans: they constantly try to reframe the debate to have their worldview as the agreed-upon starting point.
That final 10% is the hard part. 90% is easy.
1 reply →
Author has a good head on their shoulders, but few if any companies are going to spend time on incident simulations for their SREs.
Why not? Because even pre-AI, very few companies spend time practicing restoring their backups, or disaster recovery, or picking infrequently-used runbooks to practice, or seeing whether they can easily rotate secrets without downtime, or trying to redploy the system onto another vendor's cloud/platform, or, or, or... It is the least-sexy operations work that exists. No executive cares about this. Ops organizations push for flashy work, same as everybody else: new infrastructure for new projects, cool chatbots, new flashy dashboards, make charts go up and to the right, etc.
Airline pilots go through disaster simulation training because the government mandates that training. If it wasn't a condition of holding a pilot's license, no company would pay for it.
Want SREs to spend time training for disasters? Take a step back. Support professional licensure. Make it a condition of holding a license. You won't get industry-wide professional behavior until you professionalize the work. It won't happen without licensing because every corner cut that is not immediately visible to consumers translates to additional profit, and increasing competition eventually requires these corners to be cut in order to keep up with competition and stay in business. Forcing all players to submit to licensing requires all players to pay these costs and thus forbids them from cutting them to become more competitive.
I was the head of a global SRE team at a top tier hedge fund.
We started doing a weekly meeting where whoever was on call would do a table top exercise of an outage that happened the prior week.
The idea was to have someone else be the simulated person on call while the SRE from last week's oncall would talk them through the symptoms, what happened and where to look.
The idea was to spread knowledge around how incidents looked, what tools were used, what could have been done differently etc.
This was largely inspired by the following quote:
"Drills are for working on the infrequent actions that lead to big outcomes. A good example is heaving the ball from half court in basketball when the game is close. You can't control who will have the ball in that situation but you want everyone on the team familiar with what to do and how to do it."
How often are there outages? Is there a significant outage every week to do simulations for? The problem with our organization is that outages are so rare that weekly we have nothing to discuss.
Hmm that’s strange, in my experience it is the other way around - Claude is super diligent with infra and will _insist_ on double checking and trying everything for real before committing.
When I was doing this myself I would read the docs and just implement them - claud is going about doing real software archeology to figure if what is said is actually the truth or it’s stale/inaccurate/buggy.
I’ve become 10 times more diligent because it is a lot easier to do. It’s no longer Urgh it’s good enough let’s ship it, now it’s “sure put a leg on it to figure it out and double check it”.
Backups are _tested regularly_ now because LLMs make it cheap to do so.
The only problem is when new engineers who haven’t learned these things Pre-ai now don’t really get why it is needed in the first place and will often lead the agent astray.
I think to address this we need to change or improve our training routines in general for humans. I think a lot of companies nowadays just skip that and deploy a company wide skill/policy for the agents, but don’t transfer the underlying skills to the devs themselves.
> Backups are _tested regularly_ now because LLMs make it cheap to do so.
sighs heavily in 90's sysadmin
Testing backups is not just a question of whether or not the restore command works. Go back and read the Tao of Backup: http://www.taobackup.com/history.html . The application itself (in its current version, with its current features) needs to work with the backed-up data, and the only way to verify this is to attempt to actually work with the data.
If you don't trust your agent to ship to production without manually reviewing the output (in some way), you have no business trusting your agent managing your backups. The agent writing some tests doesn't mean that the tests adequately handle all of your actual scenarios, let alone that your system will adequately handle data that is missing since the last backup.
1 reply →
>Why not? Because even pre-AI, very few companies spend time practicing restoring their backups, or disaster recovery, or picking infrequently-used runbooks to practice, or seeing whether they can easily rotate secrets without downtime, or trying to redploy the system onto another vendor's cloud/platform, or, or, or...
Exact. Let insurance cover it, say sorry to your customers twice and shwoop never happened.
I find the use of AI like quicksand.
The more I use it, the more I have to rely on it to make changes/ fix things in the same system. In the end, I come out feeling empty; no intuitive knowledge of the system "I" built or fixed.
Code review is important but it does not replace the mental model I am able to build when I do all the steps of software development manually without AI.
No worries, at some point your hit the wall with it and the reality will force you to look at the code. It won't be nice, but until that point delulu land is sustainable enough to fall forward
It's the uncanny valley of AI. It's still not quite good enough yet that you can trust it blindly on a big codebase, so you still have to read and understand everything - which is often harder than just writing it up yourself.
I doubt AI will be good enough to _scale_ many things because human language isn't sufficient to explain it (especially when not understanding what is being built). Humans invented more concise languages (math, C++) to pair with their intellectual acuity. [1]
In one extreme, we have art, which cannot be accurately reproduced or explained in any language (unless a concise language was used to create it, like math or CS art).
At the other end: 1 + 1 = 2 and PI = 3.14...
[1] It seems any language that has a binary outcome (correct/wrong) helps the AI tremendously, however when e.g. creating software, that software is not functioning in isolation. The software is an attempt to codify a fuzzy human system or need, and that information only flows in one direction: human to machine.
You don’t need to copy-paste the same comment in every reply. It seems like agenda pushing more than contributing.
1 reply →
I put on AGENTS.MD a prompt that says: teach me something small something about the changes you did if the changes were < 3 tokens if it was more than that teach me more. That's helped me somwhat. So now everytime it changes something it teaches me something about the codebase
i literally tell it "explain it like a 5 year old can understand" and "keep it under 100 characters".. helps somewhat (its still an llm so caveat emptor)
I find that it helps a little to maintain an iron grip on the design. Take the time for really detailed change planning. Be pedantic and push back against every little thing that seems wrong or even a little odd in any plan document the LLM spews out. Likewise, watch for the for the moment when the LLM eventually stumbles and starts to make excuses for deviations from the plan. Interrupt immediately and force it back onto the plan (or your vision), potentially with pointers to resolve immediate problems. Completely unattended agents just don't work for important code.
[dead]
[dead]
>The more I use it, the more I have to rely on it to make changes/ fix things in the same system. In the end, I come out feeling empty; no intuitive knowledge of the system "I" built or fixed.
Most of us build a system to deliver a product to make money. We don't feel empty for not knowing how the system works, since we don't really care: it's just a means to an end.
Yeah, well, some of us aren’t uninterested, cynical losers only in it for the money.
> Most of us build a system to deliver a product to make money
Shouldn’t it be to deliver a system that is sold as a product? And even then that product is sold to consumers to solve their problems. Not knowing how it works means you don’t know what solution you’re selling.
You can see that in a lot of product announcement where the focus is on what they’re building, but not on how it solves some problem. The consumer is absent from the design process.
[dead]
The more code writes autonomously, the less intuition the human owners have about that code. Loss of intuition is a seed of technical debt that grows with time. Over a long enough horizon, it can make looking at your own codebase feel like the first day on the job (sometimes at a company you started).
Luckily, there are ways to mitigate this and essentially translate those human intuition of how the codebase “should” be into guardrails for the agents. But without that, your setting your sails in a stochastic sea where each wave looks nothing like the last.
I think this has as much to do with how hard software became to understand as with the new shortcut to refusing to understand it and the shortsightedness in willing to take it.
We lost a lot of traction in the name of ease of staffing and speed. Using LLMs to generate more code that is harder to understand it catalyzes it but the root of the problem, in my opinion, was letting go of great design and deep understanding for short term profit.
I've been thinking about this lately - is it like using 3rd party libs to achieve stuff faster? As much as I would lovr to hand craft the datetime logic in my app, I might as well use luxon and invest this time somewhere else. Only now with llms, you get virtually infinite 3rd party libs you can use, you create them on the fly. So if you have strong engineering values, I would say simply it boils down to "contracts over programs", you can still be in touch with the logic that glues it all together and treat some logic as a blackbox the same way we do with 3rd party libs?
It's not just about it feeling like a 3rd party library but it's a library that's at risk of changing significantly after every 'update' without warning.
Atleast with a well built library you know the contours and how it fits into your larger system
It's not because with libraries you have a boundary somewhere and can decide to not care what's inside as long as the interface is stable and well designed. The problem of course you need to prioritise building well designed interfaces and decouple components from each other, and that's a skill most developers aren't good at.
1 reply →
Considering how many compromises and problems third party libraries have caused recently, I would say the comparison is apt - if you don't know what you're shipping one day it might explode on you
I see aviation sentiment raised from time to time. In aviation failure is catastrophic, and systems you operate do not change on the fly (pun intended).
You can probably drill SREs that way but you are only teaching them how to _react_ efficiently, not how to _fix_ unique unicorn root causes of these failures. Aviation analogy would be an airplane engineer that tries to drill himself for in-flight engine failures AND engine debugging / engine redesign both at the same time.
It never made sense in software engineering, and never will. Minute spent on drills is a minute better spent on reworking codebase to reduce changes of future incidents. This post is very SRE centric.
In aviation all code and doc are available to inspectors when a catastrophic failure or near miss happens.
It's not the case for other industries, and in particular car industry is able to hide about everything software related from inspectors.
Pilots aren't expected to be design engineers and SREs aren't expected to be software developers.
At least in my experience, operators and on-call engineers aren't necessarily responsible for remediation and validation.
Before you take me too literally, there is, of course, an overlap of skill and trade, but I believe the pilot analogy is more apt than you argue. I do agree that the difference in consequence and stakes is meaningfully important, however.
I've seen a variation of this where random engineers are pulled into production incident calls and engineers are not expected to be familiar with the system.
They were asked to "just use AI" and understand the component, triage the issue, build a fix etc. The engineer was forced to choose between accepting a potentially mediocre fix AI has suggested or risk being coming across as an incompetent resource who doesn't know how to leverage AI.
You can guess what the engineer chose. The fix wasn't bad but it was suboptimal for some edge cases. We had to later revise it. Have enough of these situations, engineers will eventually definitely give up understanding the system in detail.
Code too.
I work with programmers and it's not uncommon that they can remember with shocking detail about code they've written in the past.
Someone might mention an issue that has cropped up and they'll stare off into space for a few moments and actually remember where that issue stems from in the code, because they remember writing it like 8 months ago.
This skill will be lost when AI is generating all code, we'll be stuck in a perpetual loop of having AI keep track of the state of the code in order for AI to extend and maintain it.
Will AI remember ? Or rather how will we make AI remember ?
I mean I think this is just how AI already operates. I’ve seen multiple models go digging in the git blame or past PRs, and even unmerged PRs. When agents work on a project that has well-defined in-repo docs, agents normally update them without prompting. So I doubt this will be a big issue for AI, but agreed we’re losing a skill
[dead]
If capability increase continues as it has, then an incident that cannot be resolved by AI will stump humans no matter the practice.
I like the plane example from the article,but I think in reality it will be like code. 1.5 years ago engineers would routinely say that they still write code by hand here or there to keep their skills sharp, and that's just not something you hear much if at all.
If an SRE is faced with a situation an AI can't solve, then said SRE will use the AI systems to triage further, point it to different places and so on.
This works for SREs with pre-AI experience and intuition, possibly less so with new recruits coming in post-AI. I don't know what the solution to this is, maybe practice drills is it, but I have a hunch the entire field will be subsumed, same as many other engineering fields.
There is only so much need for taste and judgement, before even that has been incorporated into the models.
It’s tough. The models can at this point very quickly identify issues in a Kubernetes cluster, for example. This because these systems give you a TON of observability, and it can easily see all the different moving parts.
That doesn’t mean the proposed solution is always right, but it is absolutely landing on the root issue faster than most humans would be able to, even pre-AI. Just because it can remember and run through a bunch of commands more quickly that I can.
There are lots of incidents where the symptom doesn’t always clearly point to the issue, so having something that can fairly exhaustively check a lot of different things very quickly is pretty useful!
But I at least partly agree, I think the more complicated and obtuse a system is, the harder it is for AI to do this. But we’ve invested time in making systems much more straightforward to understand and operate from one place (Kubernetes in general), and AI thrives on that.
And yeah, it means your debugging skills wane a bit because, yeah, if the bot can diagnose the issue in 5 minutes, it’d be irresponsible to not use it.
And I’m not really happy about it, and personally I’ve always been able to figure out a tricky bug given enough time. I don’t want to loose that skill. But everyone is under a lot of time pressure these days.
Like the fact that software "engineering" is mostly nothing like real engineering (and it’s further regressing now due to LLM coding!), the general lack of drilling is again one of the things that make software-related stuff look really naive and amateurish from the perspective of those dealing with the real world. Imagine if the military, police, fire service, and so on did not drill and rehearse incident response?
There are drills, tho. It's just that usually they're only done above a certain level. Small companies, "lean" teams and so on don't have (or didn't have) the capacity to implement all those things. Maybe with the exception of netflix and their chaos thing (bring down systems regularly to make sure the whole still works).
But that's also likely to change with AI assistance. Even an "average" system is better than none. So now teams will have the capacity to bring that in to their systems. Backups / recovery drills that are actually tested (either because they're implementing testing or because the AI screws something up and they need to recover). Either way, it'll be included. Same for security ops. And devops.
I still strongly believe that AI assistance is a catalyst / accelerator, and that the "floor" will rise in most domains. So a small team that only had bandwidth to deal with the happy path previously, will now be able to start incorporating processes and procedures that were historically only done at corporate level. And that's a good thing. Even if it won't look like that in the beginning. But we'll get there, eventually.
Netflix's chaos monkey was this, in a way.
> If capability increase continues as it has, then an incident that cannot be resolved by AI will stump humans no matter the practice.
I disagree with this. Whatever the AI produces must be embodied in some kind of information system. The moment the output is on disk, it's fish in a barrel for any competent operator.
I've worked in environments that are beyond the pale with regard to complexity. It will take AI another 10 years to product something as complicated and coherent as a semiconductor manufacturing operating system, which is clearly feasible for humans to manage today.
If you are in a situation where you dont know what happened when something goes wrong, the business incentives will not accept “its too complex” as an answer.
Firms aren’t just selling products, they are selling reliability and taking on liability.
Nah, LLM models are already the new compilers. A commodity only engineers know how to use (in the context of software engineering in production environments)
Out of context, but to address "AI will replace engineers".
Recently discussed something about economy/investing with a friend while at work at a slaughterhouse. I really didn't want him to get scammed buying crypto. So, used ChatGPT to find some sources in Somali, a 3 videos with short description why it's worth watching. Intro into investing, intro about cryptocurrencies and about buying them. Had the text shortened down to 3 pretty short paragraphs, not more than twice this post.
He's a smart guy, but only went to primary Qur'an school. Doesn't read or such, mostly consumes internet in form of video/media. He couldn't read those 3 paragraphs, it was too long. Or rather, it wasn't just 3 paragraphs, it was a lot to read.
Maybe we're already dividing into murlocs and the surface dwellers?
Been doing a lot of interviewing lately.
Despite not having written code for about 6 months due to using Claude etc, I've surprised myself with how much the "muscle memory" of leetcode etc has come back to me.
I say this b/c I think the veterans with years of coding, debugging etc experience can just pick back up the skills they need even if they're a bit rusty.
The junior folks on the other hand, I'm not so sure. Friends of mine that hire straight out of college are saying that a combination of going to college during COVID + LLMs + "cloud is all you need" has resulted in juniors who don't know how to solve problems nor architect basic software.
I guess we are all on some kind of chart where the slope of losing the experienced people who know what's going on and AI getting so good we don't need people are going to intersect at some point. And that intersection may be later than is good for society and engineering overall.
As societies evolve people lose touch with nature —growing food, hunting, building shelter, and making clothing.
Progress usually means adding levels of abstraction so that more can be done with less effort and needing to worry about lower levels.
AI isn’t all that different.
This is why the paradigm for AI use should not be automation but rather the cyborg. Under automation, people are less active and engaged and become mere operators of automated processes. They become slaves of the machines. Under the cyborg model, they arrange the machines in a way to make people masters of a universe that includes the machines helping them be that.
For more in this vein, look up "Automation should be like Iron Man, not like Ultron". Sad to see so many people let go of their agency.
without Iron Man's plot armor, Ultron would have won
Anyone who's worked in tech in a large company will probably have experienced having an ops team who use RPA tools to do repetitive tasks that tech teams get the blame for when things break. AI will make this so much worse. Things will break, everyone will assume 'tech knows the system', but really it's a new process outside of the tech teams that someone vibe coded but got it wrong.
Audit trails, logs, and tight data governance where things can only be accessed with proper roles is the only possible solution.
If an RPA team ever gets direct access to a production database in your company, look for a new job.
> Robotic process automation is a type of business process automation that automates tasks within business and IT processes using scripts that mimic human interaction with application user interfaces.
For anyone else wondering what RPA means. Never heard that abbreviation before.
In practice, it is screen-scraping on meth. Horrible stuff. I understand that it's the only option available for some systems, but any client who asks for RPA support when APIs exist for the same data ought to be fired, or at least given a very stern "No."
Me! Thanks for the explanations!
That makes more sense than Rocket Propelled Automation that was my hallucination.
Its true we will lose the skills, but so far the LLMs are more than picking up the slack when wielded competently.
They _regularly_ go above and beyond when troubleshooting and frequently in 1/2 - 1/1000th of the time.
I remember spending entire days troubleshooting in the before times. Now it's like 30 minutes, tops, on literally any issue.
This is what progress looks like. We used to do a thing and now we don't.
> when wielded competently.
And what happens when the competency drains away?
That's what everyone's learning to do now, that is the skill that people will be improving.
1 reply →
Who is going to teach programmers to wield AI competently?
That's what everyone's learning to do now, that is the skill that people will be improving.
This is the same problem as the "AI drives the car until it can't" situation. Feel free to doze off so long as you can wake up and instantly have world class racecar "save the situation" reflexes. Hope isn't a strategy but that's what all of this feels like.
There's an interesting dynamic, too. Even if an engineer reads the output of the AI and understands the root cause of the problems and how to diagnose the incident, somehow it's hard for them to internalize the learning and apply it next time to a new incident. As a result, the engineer loses touch with the system anyway.
It looks like our brains somehow have to experience the failures during a diagnosis and in gemerak perform this kind of pathfinding by themselves to truly understand the system. I don't know if this has to do with how our brains actually learn.
So looks like you pay AI to resolve incidents and then pay money and time for engineers to get training on synthetic incident resolutions.
The comparison with Pilots is bit disjoint one cause the domain varies a lot for every company and product. Coming up with synthetic simulations within every domain is like paying money twice for the same thing, why not let the engineers to handle the real incidents in the first place itself. In fact why not spend some more thought into building better systems.
This is the same challenge aviation had with an over-reliance on automation. You end up with pilots that can’t fly the plane when it really matters. Look up the Asiana crash at SFO which is a lesson in what will happen to engineering orgs that over-rely on AI.
We have been running Agents on infrastructure and letting to create resources, scale up and down, security scans etc.
I agree with premise of thr blog. The question i have been asking internal does knowing your system really matter if you can recreate it in minutes.
We recently had a situation, where in with our internal platform and claude we recreated everything in minutes.
Management in the end cares about the outcome and not how the meat is made.
Isn't there anywhere to "go" from here? In the last decades, introducing new high level abstractions on top of existing paradigms naturally had everyone move up the ladder and work at the next higher level, why should this be different these days? Do we think AI will reach the top of the abstraction ceiling, so there's no where to go from here?
This isn't abstraction though. Outsourcing is a better term. If things continue moving up that latter, you will see that your agent/agency will pass the buck too. But there should always be some last turtle. Maybe that turtle will be the human that thought he was climbing the latter, who knows.
>introducing new high level abstractions...
Coding via LLM is not similar to using an abstraction. Imagine a car. The controls like steering wheel, the pedals, the gear levers. Those are abstractions.
But using LLMs are like driving using a remote control that has probabilistic behavior. You just loss what it feels to be in a car and you fail to improve as a driver because of the erratic remote control.
That’s the big question for sure
Meta: The blinking cursor of the "logo" of the blog being sticky in the top left corner makes it impossible for me to read the text. It constantly fires interrupts at me.
Depending on what your goals as the author are, you may or may not want that.
Being able to scroll it out of view might be enough to achieve the aesthetics goal, and the goal of people actually listening to you.
If you have something like ublock origin use the block element functionality to target the blinking cursor. It's gone on my end :)
After 2 minutes of reading that article, I inspected and deleted the node. Very annoying.
Not just you. Must be nice being fully neurotypical and „not seeing“ all of this kind of stuff.
The internet for me (and increasingly non-internet programs) is unusable at this point without excessive modifications. It's hard to imagine what it's like being unbothered by it all.
I mean seeing this stuff pays the bills and does so quite well, so..
One time I had to do a system optimisation to increase the throughput of messages and was using Claude with Datadog and Couldwatch MCPs to figure out the bottlenecks by running load tests. it was Opus 4.8 and one of the most frustrating interactions with Claude I ever had.
It was just making up random stuff about AWS and system resource limitations and when I was asking for the source like from where it got that info, it was like, “I’m sorry I prematurely concluded that without checking sources”.
I would never trust an Agent to resolve incidents ever
You would need to give it AWS credentials and MCPs for that. I’ve been sending agents into prod env for over a year now.
I was was doing it in a separate load testing env. None of the agents have access to prod env.
I agree with the sentiment but unless it leads to better financial outcomes for them to A) have engineers on staff and B) have them know their systems then enterprise will continue looking for reasons to shed all the engineers and just leave everything to AI. Anecdotally I think most companies are still looking for ways for AI to help them shed headcount so raising this alarm doesn't mean anything to the decision makers at the top.
This has already happened in other areas. I'm old enough to remember when customer service people spent all day handling customer problems themselves, which gave them the understanding needed to solve more unusual problems.
These days they do what the computer tells them. Even if they could solve the problem they don't have the agency. They can only select from the options they are given.
In software we still have the agency but we are giving away the understanding. The agency will follow.
You’d hope these AI incident responders have very constrained production tools to fix things. You’d hope the humans remain familiar with those tools and they are incredibly well documented.
I think the biggest loss is now not knowing if what the agent is claiming was actually done:) but yes, right tools are necessary, adding a boundary will change the position, being out of touch will be recoverable. Otherwise one bad call might be unrecoverable and no amount of familiarity will save you
I like the idea of simulations - maybe not in the flight simulator sense of a fixed rhythm, but more in the training in using the tools quickly sense, like a chaos monkey in your log search. My most memorable exam was Certified Kubernetes Administrator (CKA), the hands-on simulation part was exhilarating.
When someone else -whether AI agent or a human- solves the recurring minor problems for you, those problems become non-issue, get swept under the rug, just to accumulate more dust.
One day, those may become bigger as they are forgotten, causing havoc. The standard root-cause-analysis depending on systems having certain retention period, which may be expired at that time.
It is important to get real hold of one's systems from end-to-end aspect, which holds true for both AI and human operators...
I’m not sure who will be solving these incidents if 99% of incidents will be “solved” by LLMs. If I’m called once a year my daily rate will be my yearly rate?
I still use LLMs, but strictly for sanity checks or quick summaries. Trusting them blindly to debug complex systems often leads to a rabbit hole.
I detest these doom and gloom articles.
We’re entering a new phase of software development, and with every phase there are new challenges.
Some questions the author might want to first answer: 1. If AI is constantly reacting to smaller incidents, is it surfacing larger issues in your codebase and architecture? 2. What kind of new telemetry do we have to build? 3. How do we build new deployment systems that help us validate fixes without requiring hours to go through traditional CI/CD systems
I’m old enough to remember the days when engineers would monkey patch their code on live servers with additional logging and metrics to learn about failure modes during incidents.
Wasn't that the idea? Withe cars on roads, didn't we literally lose the touch with the ground? I guess the desire was to "lose" touch with all dirty and hard work areas.
That's what the linked article is talking about. Training for extreme failure.
Sure you have self driving cars and everything that make you more and more disconnected, but still highways more dangerous to drive whenever there is a storm or ice on the road. For the same reason, driving tests are harder in the north.
The only plan was to make making cheaper. There wasn't a plan for the people afterwards.
"On a silver platter" lol The old phenomenon: give the cashier at the convenience store exact change and they will be like, d-uh. Because automated cashiering.
This article leads up to a hypothesis presented without evidence.
Yes, it's clear that if AI agents handle routine issues then only the most complex issues will be handled by humans. In no way does it follow that humans will be less prepared to handle those incidents than they are now; by definition, this class of problems have no rote solutions. Each issue of this type already requires deep system knowledge to remediate, and still will. Software is not aviation.
What we are seeing here is an instance of the more general trend where experts are still required to operate complex systems, but AI is destroying the career path that creates those experts. That's what we should be worrying about, not that people are going to be spending less time rebooting boxes. This isn't something you can fix with a "simulator."
https://en.wikipedia.org/wiki/Ironies_of_Automation
https://www.sciencedirect.com/science/article/abs/pii/000510...
The article is based on evidence, and states it clearly in the body.
I read the article before commenting, as is my habit. A disagreement is not always a failure to process.
To be very explicit, my problem is that the article argues that simulation will be a suitable substitute in the software space, as it is in the aviation space. I see no evidence for that; it's pure hypothesis taken as fact.
3 replies →
Reminds me of a story about Ericsson engineers missing vital troubleshooting practice when Erlang turned out to be too reliable.
Suppose "Reflections on Trusting Trust" is not the naive rantings of some obsolete dinosaur.
Why does it not apply?
This sounds like the next iteration of "nobody understands their runtime environment these days", which I've been saying for many years.
The article does not get the point. What aircraft companies did was separate training and work, and SRE/IT typically does not.
An AI can handle routine incidents and then present learning cases from that routine work for training, because the skill in SRE is not the mechanical log grepping, grafana dashboard browsing etc but forming the hypothesis. AI incident reports can create training cases that are a much better training for hypothesis forming and testing than the work itself can.
I feel a lot of comments here are missing the forest for the trees.
We do not yet have the next generation systems that will manage AI creation and maintenance of systems.
Humans have been making spaghetti code systems and maintaining them poorly for years. Best practices developed… eventually. But certainly not in the 70s and 80s. Spaghetti was the norm for quite some time.
The development paradigm has changed. Forever. You can’t expect yesterday’s tools for managing software development to succeed at this point. We’re still roughly on year one of this transformation.
The new bottlenecks are creating and enforcing boundaries in the code, identifying level of risk within a boundary, subjecting high risk areas to more intense human review and architecture reworks, and so so much more manual testing.
We need a new language for high level development that focuses on architectural constraints. We need analysis software that helps draw boundaries, identify what needs extended human attention, and helps us map and understand a rapidly developing code base. We need to standardize on the use of frameworks and languages like we have on assembly variants.
I’ll bring up a hacker news trope here. NaughtyDog’s GOAL was an amazing system that was a product of an underdeveloped ecosystem for game development at the time. They used lisp and assembly because you still had to write assembly for performance reasons then.
We are in a very similar period. The ecosystem is underdeveloped. We should be looking for new languages and tools to manage this.
CNC machines used to run from punch cards and then hand written NC code. Now we have advanced CAM software. (Which innovative people are actually running with LLMs!)
> But certainly not in the 70s and 80s.
Some already developed even earlier and most ideas were already there in the 80s. The problem was just that the field was growing so fast that it was filled with people without formal training or fresh out of university. That way the knowledge did not spread.
For instance the 1986 paper „no silver bullet“ already described the need for iterative approaches later described as agile.
That’s a fair point. Practically, we need to adopt new practices and systems in the field. They may already exist in many cases.
> We’re still roughly on year one of this transformation.
OpenAI Codex was released in 2021. Artificially compressing what we see now to one year of growth is an example of why it's very hard to trust anything AI proponents say.
Codex the agent app/tui was not released in 2021. What was released in 2021 was simply a fine-tuned model.
[dead]
Detection rots first when an agent owns the runbook...you lose the skepticism, not the fix-velocity.
Ironies of Automation is front and center in this article which is awesome. Many of the conversations on AI automation are describing or rediscovering the insights the paper covered.
same irony hits agentic remediation. ai clears routine incidents, humans inherit the sev0 with zero reps. shadow mode is the simulator.
I recently had some issues with a game not working well on my Intel Arc B580. OpenAI (Anthropic's models definitely could too) ran some profiling inside of Windows, captured a few GB of data, sifted through it, identified the guilty .dll's and approximately where the issue was and traced it down to a single user-toggelable Unreal Engine 5 launch flag, which resolved it.
I feel like AI could easily do the same for servers and various software, BUT you gotta ground it in actual data so it can't make the shit up and just spew out garbage (if you tell it to come up with a potential answer it will even if it doesn't have the proper data to be "sure" of it).
I don’t find this to be the case. I use AI to help investigate and gather evidence much more efficiently than I could ever do manually. Then, I work through the evidence and possible failure modes given the observations with AI. It’s the exact same process I’d follow with a talented co-worker. Does it matter they are driving?
My intuition and instincts have been honed from years of troubleshooting complex systems so I find it refreshing not having to write probe scripts, queries or code under pressure. I can have a theory and test it very quickly and if it’s not the problem, I can quickly try something else. This greatly improves the time it takes to find the real root cause. Once found, I can do more elaborate testing that I might have skipped before due to complexity or time constraints to really have higher certainty.
If there is ever a time where the model does something I don’t understand, I ask it to explain it to me and I increase my knowledge of the system accordingly. It’s always patient and explains things in such depth without any sighs, patronizing, sarcasm, juxtaposition, etc. So refreshing!
I much prefer working with AI than any co-worker and I find I’m far more productive and efficient, especially with bugs and dealing with incidents. There’s no one to convince or argue with, no ego’s to trip over. It’s lovely.
Prediction: this won’t happen. The abstraction will be good enough and people will need to know only as much as they need to know- things will stabilise at the equilibrium.
We already know this happens though, Bainbridge’s paper came out in 1983.
Good article and I like the callouts to the aviation industry. For me what's missing is the author should also have touched on CRM and SRM.
Also, that paper "The Ironies of Automation" is one that everyone should read. It's fairly short.
There is a related problem in terms of these situations where the computer system is handing off to the human. It's called "the bumpy transfer of control." Very fascinating concept.
The way forward is clear. Improve the AI such that the hardest incidents can be handled by AI alone. Whether we want this or not is independent of the trendline which points to this future regardless.
Imagine a future where humanity understands none of the underlying technology and AI just babysits us on a daily basis. Wall-e.
Programming will devolve into unintelligible anti patterns and will be written in convoluted languages humanity doesn’t understand. But none of this matters because AI will be handling all of it.
I run an IR company focused on specific security response emergencies.
AI use across my company is variable and I don’t allow any enforcement of mandatory using or not using of it.
I view and tell my employees to view their skills as that of a high-performing athlete. Consistent training of the basics, rapid fire what-if testing, weekly scenarios are all part of the upkeep.
In short, this is what it takes to keep up the skills no matter if you do or don’t use AI and I can imagine the degradation is much faster if you don’t train AND delegate all of your activity to AI.
I just can’t believe we’re still paying engineers to be Claude wrappers. This is ending soon, right?
Nope, because as I’ve seen first hand most people are too incompetent to use an LLM effectively, as easy as it is.
You rather generously assume engineers are in touch with their systems.
Even before layoffs many teams just maintained things org has long lost coherent knowledge of
After layoffs and typical org knowledge churn - you can either rewrite it (but how? Product team responsible for original implement requirements is long gone too) or recoup (reverse document) some of that lost knowledge with AI and actually learn
"Middle devs take care of incidents, senior devs lose touch with their systems"
1980's .. compilers handle assembly, engineers loos touch with their code ...
I am exceedingly tired of poor metaphors that are popping up since AI has taken over writing.
No, operating software is not like operating a plane. Not at all in fact. The people operating the software and resolving incidents are the same people who created the software in the first place, and continue to work on it day to day. Pilots have not and don't.
I'm not sure if I agree with the plane analogy either. Aren't planes supposed to have exceptionally stable hardware and software platform? Does that not significantly reduce failure modes? Most production software by comparison is constantly evolving. Unless you design very simple or basic training examples, most of it's going to be out of date soon.
The former CTO of a large MSP software company once told me on a call the reason their product had so many features removed with price increases was "you can't maintain a plane while it's in the air"
The immediate response was "We don't, your updates bring the on prem RMM down for hours at a time, the plane is grounded for maintenence regularly"
"THIS IS NOT A DRILL"
It's just a picture of a drill! Thanks, Magritte.
That‘s the goal of the AI tech bro world: get us dependant on their tech, ruin our native/raw skills, lock us into their proprietary skills.
Reminds me of the move from on prem to cloud. Linux sysadmins were killed and replaced by aws focused devops.
[dead]
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[dead]