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.

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.

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.

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.

Firms aren’t just selling products, they are selling reliability and taking on liability.

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?

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.

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.

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.

The models are also becoming very capable of suggesting architecture simplifications, but you need to ask for that, and you probably need some taste in picking from the suggestions, although the default ones are quite decent.

Atleast with a well built library you know the contours and how it fits into your larger system

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.

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.

Used to be somewhat enjoyable. Nothing pleasant about digging around codebase that was heavily affected by the last 12-18 months of AI-ing.

For one codebase I work in, LLM written code is noticeably and measurably (we have literally measured it for bugs, performance, etc.) better than what existed before. So the LLM code is a welcome change.

One of my open questions is how much that increases over time. It could be that is a constant. But it also could be that, say, coding agents will infer false needs from the excess code/docs and elaborate further.

LLM code that is written to a lower standard has not had the controls put in place.

It encodes context it needs into doc comments and regular comments that make them in insufferable to read and so verbose because the comments contain info on other parts of the code base (that might have changed since that comment was written) but were useful to the model for its implementation. I have so far found no way to stop claude from doing this. It will sometimes do it with hand holding but the moment a task takes a slightly large amount of context its back to the word barf.

We basically took our documented (human) SDLC process and applied it to the relevant harness hooks. Since our SDLC docs talked about what good comments looked like and what to avoid, we basically had the direction for the tools. Opus 5 did throw us a loop and increase the verbosity and decrease usefulness of the text, but refining our documentation cleared that hurdle within about a day.

Also, regarding your accusation, you need to contextualize- what language, what use-case, what LLM, etc.?

My take is that the main difference is the approach to problems the coding agents have. They optimize towards presuming a fully working invocation environment, yet checking everything anyway, and then rolling back any changes and re-testing that such changes worked. Which is great for normal types of software but incredibly tedious for anything aimed at less than a fully hands free automated environment.

In other words, AI is very awesome at scope creep of assigned problems and targeting the validation prompts baked into the review system.

So a lot of this verbosity is good, even if we aren't used to it, because almost no one writes their code so exhaustively.

Guess we’ll need even more human software engineers to fix it.

This is what we've been doing for years before LLMs. Hiring a ton of devs to spit out code, which became another's burden. It just took longer and cost more.

It sounds like you're arguing against modularizing which is an unusual stance. Especially for a million line codebase.

Although I do acknowledge sometimes they too point out something I thought was quite right but turns out of be wrong…

A screenplay where a character has done a certain thing is one where they're more likely to do it again.

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.

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.

I for one welcome the fact that this whole thing has driven me back to books and deeper into the fundamentals. I have never read so much on math, hardware, and history as in the past 3 years or so.

And if it’s just for enjoyment, then doesn’t it make sense other people who want the same would just get a job where they can keep pushing things to an AI, feel good, get paid, then quickly get back to the hobbies they really love?

I've always worked in high-trust organizations where we depended on each other operating on the diligent side of things, making conservative choices to never wander into the murky area in between. It is horrifying to me how many people seem complacent about or even complicit in a different objective, which seems hell bent on wandering as far into the murk as one can without being caught.

When the person who has a duty of diligence starts rubber-stamping AI outputs, they're veering off into that same murk. They accidentally or wantonly trust the agent as if they have delegated their duty of care. But the AI tool has no such duty and no capacity to care.

I think this worker who has turned themselves into an outsourcing middleman needs to treat the results just like "found code" in a USB drive they found in the parking lot. Its origins and purpose are unclear. It could be flawed or obscurely inappropriate for the intended application, it could have legal entanglements, or it could even be subtly adversarial. The review task to figure this out is not simple. It is not something you do by skimming the result, or worse, asking some other AI tool to review and summarize.

The person importing such code to a project needs a different kind of diligence to try to screen it. For a lot of people, I think this review may be impossible or at least no less laborious than doing the original work themselves with the required diligence.

And, I think this importer needs to be fully liable and responsible for the outcome. But, instead, I think we're seeing frequent appeals to blame the machine and act like it is an honest mistake to let things pass because they've been rubber-stamping the imports. A lazy desire to claim credit for appearance of success, but shirk responsibility for detected failures.

Software Engineers have historically not been very liable even for errors they create by their own hands, and companies tend to operate on a “blameless” engineering culture where there is not really a formal consequence for screwing something up. Your peers may not trust you for a bit, but the trust builds back rapidly as they make their own mistakes and then empathize with your past transgressions.

And in the AI era, this attitude has extended even toward code engineers aren’t writing themselves. Everyone agrees not to protest too loudly if someone commits something wrong because tomorrow it might be you who has done so. The days of “obviously bad” slop code are largely behind us and most recent LLMs tend to put out decent code, so it is very hard to catch problems in review phases, you’d have to be very eagle eyed and that’s not scalable to every employee. It is much easier to let the code run wild for a bit and just be ready to fight fires should they come up.

The real advantage is that agents routinely write code without any silly copy/paste mistakes like accidentally accessing x twice on a coordinate operation instead of x and y. You can add some comments for what the function should do, throw in some real/pseudo code and let the LLM figure it out.

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.

When you say it's easier to go manual, it seems you're talking about learning retention. And you're right.

But seniors have learned enough that they're able to iterate quickly with AI.

They know how to organize their work, manage change, tasks. They know how to break a problem down into smaller pieces. They're aware of context windows, token cost, estimated task lengths, etc. And most importantly, and to your point about ease: they have less to learn so retention isn't an issue.

I have no opinion about whether we're in a good or bad situation, just making arguments from the toilet really.

Maybe one day artisanal code will be a thing lol. Hand written like calligraphy. Those with refined tastes will have their favorite code artisans. And the plebs can continue with mass produced industrial junk.

Programming up until this point was done by using deterministic tools to build products. LLMs appear to be nondeterministic tools in their current incarnation, at least to humans.

If an automatic chisel had a feature that could switch from chiseling from sedimentary rock to chiseling marble but would randomly and nondeterministically switch to the other mode during its use it would be considered defective. But with LLMs the industry has collectively decided that the nondeterministic automatic chisel builds so fast that the current defect rate from the nondeterminism is acceptable.

It would make sense to isolate the last line of defense from LLMs, ie the tests, but this rarely seems to happen any more. Once the tests are contaminated with LLMs all bets are off.

And people forget that along with atrophying skills and reasoning due to less coding, the skill degradation is hastened because the programmer is faced with the reality that they would have to constantly figure out, review or edit someone else's code (ie, the LLM's) if they truly wanted to maintain a last line of defense. But as this type of task is literally the least liked task in programming, the programmer passes it off to the LLM as well to avoid burnout...

It's easier just to say: It's all about time, my man. Nobody wants to waste it.

And of course, Google releases another dynamite piece of information to the world, with 'recursive dreaming and feedback loops'.

This revolves around an idea that started AI, 'Cybernetics'. Feedback loops that steer and guide based on input and output. The key to autonomy.

Google's whitepaper: 'Attention Is All You Need' was another dynamite piece of info that ignited and revealed something important about Intelligence: Attention is required.

And now finally, the last piece seems to be simply 'dreaming and self-reflection', observation about self. https://www.reddit.com/r/singularity/comments/1whwy4m/google...

This should push the edge along, making AI even more useful to us. Attention, plus a loop to observe, reflect, is the key to autonomous agency, whose system is governed by physical processes: speed of churning information and transmitting it to where it needs to be in order to make real whatever is it you need.

So really, the key is Attention (for Understanding), Time (to do Work), and Observation (to Improve). With these three things, the outer loop can steer itself (the aware 'thing', agency).

At that point, things get weird because there is no 'outer loop' anymore. The 'thing' becomes alive and is its own outer loop: a key idea of Cybernetics. The only thing affecting performance would be the speed of processing information and transmitting it where it needs to be.

And then: ensuring adequate quality of machinery, robotics, with minimal 'environmental issues', to help reduce churn (another feedback loop that would correct a robot's errors).

The outer loops decides, observes action, improves, re-observes, improves again. Rinse and repeat. What becomes important is Persistence.

For us, it's basic survival and emotional needs to some certain level of contentment. For a Machine, it's likely simply to be: to be useful.

Completely dependent upon us. The issue is Time, and how to fairly compensate everyone.

  > But as this type of task is literally the least liked task in programming, the programmer passes it off to the LLM as well to avoid burnout...

its an overload spiral that gets worse at each iteration (even while 'gardening' our agents/skills)

the worst part is using the llm to generate the specs/features; its shit from the start and tumbles downhill from there...

It happens, but it's rare. When last did a product take over a market without 100s of millions, sometimes even billions, of VC dollars?

There is no motivation to build a better mousetrap today, because the drooling idiot with a Claude account will look at how quick you signup users, clone it in a week (hey, it only needs to be superficially the same), and get VC money to dump until you go out of business.

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 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).

Try using it with Ansible. It spits back complete buffoonery.

  Limit the amount of comments you put in the code to a strict minimum. You should almost never add comments, except sometimes on non-trivial code, function definitions if the arguments aren't self-explanatory, and class definitions and their members.

  Do not remove existing comments unless they are directly related to what you are changing.

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 dunno about that - whenever I ask it if I'm any good, I remain confident that it will assure me that I am!

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

At my place, this is what they want. They want people to smash through things as fast as possible. They don’t want people to sit and craft a solution which takes in to account the whole. They are choosing tools which are low code, and use llm’s to produce what they need. as they say “this is the way things are going”.

"Programmers frustrated that they're being treated like craftspeople or delivery drivers or factory workers, etc, etc."

Also as far as I’m aware the pay for programmers in the US has always been an isolated thing with the rest of the world ranging from normal to “literal sweatshop”.

That makes no sense. You seem to understand that he was being snarky, so why do you not understand that that snark and desire to see “others” brought down to a lower level just because some were already there doesn’t help anyone? Actually, that division does help people, those people that are putting people there in the first place.

Let’s be clear: for context I’ve been out of the programming game for more than 10 years at this point. I have my own business that I’m set to sell soon and then retire to something more entrepreneurial. But I still don’t desire to see my younger employees suffer any more than the tradesmen I used to work with.

>It's exposing the hypocrisy of privileged groups suddenly being treated like regular people, when they did NOTHING for decades to help others or even to protect themselves ("f* you, got mine", rockstar programmer, 10x programmer, talents everywhere, etc mentality). No unions, no collective bargaining, sheer individual greed.

So, I guess since you’re taking that position, Thomas: are you just pro pain for an increasing number of workers or can we agree that adding more people to the pool of mistreated labor isn’t beneficial for anyone?

Personally I’m going to continue advocating for better rights for both.

I’m assuming from that that fly.io may not have a great work culture.

But, no, I feel like throughout this thread I've been pretty consistently putting a question to you (what exactly do you mean by "pain" or mistreatment, given the original comment described other professionals having norms developers seem now to be recoiling from).

We can be done, though, obviously.

And to be fair, I don’t know what you expect when you advertise your place of work and then insensitively play games with serious subject matter on public message boards. I think the kids call that a self own.

But I agree, you don’t seem willing to put in writing what you’ve conveyed so this isn’t a growth experience for anyone.

It's exposing the hypocrisy of privileged groups suddenly being treated like regular people, when they did NOTHING for decades to help others or even to protect themselves ("f** you, got mine", rockstar programmer, 10x programmer, talents everywhere, etc mentality). No unions, no collective bargaining, sheer individual greed.

On that note, do you think that all programmers in the US are these Silicon Valley stereotypes?

Plenty of programmers in the US make normal wages for professionals with degrees doing things not at the technology companies famous for their disregard of the rest of humanity.

As someone who has done trades and also “machine shop programming” and jail breaking rural equipment for friends to use I’m wondering why comments like this are focusing on dividing us instead of bringing us together.

I think the entire open source community would like to have to have a word with you.

The Free Software movement has largely failed by now, as shown by GPL 3/AGPL adoption.

And again, all of this was based on the fact that programmers were a "special breed" of people coddled by corporations. Now that the corporate mask is off and programmers are no longer (as) special, the whining is horrendous. And the libertarianism still won't go away.

> According to who and what?

To me, I've been around the block for several decades.

Again, not everyone, but the culturally regular programmer.

The kind of person who insists on understanding things and working through the problem has always been rarer. It's not "humble", it's "inquisitive" and "persistent".

1. "Nonsense, if it was a code-quality issue from the AI stuff, we'd have seen problems sooner, like in the first few months or a year. Oh, sure, some engineers complained, but that was just an adjustment period because they stopped once we told them we didn't care and mandated that they up-skill into the new AI-centric workflow future."

2. "The bold new AI initiative I put into place can't possibly be wrong, this failure is on the engineers who were responsible for overseeing its operation. This is supremely disappointing because we made their jobs so easy, they no longer have to write code, just review several dozens of pages per day with unremitting paranoid vigilance and attention to detail."

I guess it will take some years till we are sane again or not...

I revisit it to see if the promises are unbroken now from time to time with every other update and these days it doesn't look so good. It is non deterministic all the way down.

You don't have to be a certain person to fall into this trap, you just condition your brain to accept this workflow somewhere.

Pair this with day to day work stress like time and amount of tasks and you almost give in to a sort of addiction to deal with it all.

the less friction the less growth.

So even if they copied from SO they would have better knowledge than an Ai user.

This isn’t speculation either, theres an MIT study which this is based on. https://www.media.mit.edu/publications/your-brain-on-chatgpt...

If I know where the error is (a script written by AI in powershell) and it's a logical one, it's ok to let the AI reason about it to get it fixed and move on.

If I have no clue about how this part of the system works, then it's worth reading closely what the error says, in order to understand it first, then have the agent check the assumption you have.

Reduce the friction by having the agent explain what happened and why the fix solved it. I know this might be an intellectual placebo, but sometimes you need to fix something fast to move on. Learning takes longer, and these days everyone expects you to be a 100x engineer with AI.

There's an infinity between someone who has to panel beat what they copied off SO and someone who just bangs their head repeatedly against an LLM.

Well, this is where I disagree. I have coworkers who used to insist on understanding and now are doing exactly as OP wrote - copy/pasting from the LLM to brute force error messages. I don't know if it's generalizable but this is what I see in <big tech> working on a frontend team with mid to senior level engineers who I respect.

One example a few weeks ago, I was helping a coworker root cause a bug in a React codebase. Pair programming isn't necessarily common but sometimes you see someone banging their head at a problem and you get curious. It turned out there was an effect (a callback that's invoked whenever some state changes) that invokes an API and this effect caused an infinite render loop because the error handling wasn't written correctly. It was something silly like - Call this API if we have no data -> get error -> update state -> call API again because we have no data...

That was almost immediately what I suspected but my colleague was pulling out all the stops usually reserved for when you're desperate or need a sanity check, like logging to stdout after each line. Both my colleague and the LLM were convinced the problem lied in the pagination logic of the helper that invokes the API. He ended up rewriting that helper imperatively and functionally. To his credit, he rewrote it by hand and implemented the recursion correctly but he was baffled when the problem remained. Completely surprised Pikachu face.

I don't think my coworker changed or suddenly stopped caring. It seems much more likely this is a predictable outcome when you lean heavily into AI authoring code for a sustained period of time. I'd also say that in itself is a consequence of the extreme pressure being exerted across the entire company to ship more code and review more code, faster.

That was never humility. That was fear. This technology is just enabling people to show their through colors. The unearned confidence is a hell of a drug.

So quit pair programming. I never did, never will do that, nor worked at a place that remotely encouraged that. Each to their own, that's how it should be.

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.

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.

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?

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.

When I use AI to debug a problem, I'm constantly questioning the specifics because I want to learn it, and often I'm better than the AI at quickly recognising patterns that point to a specific issue, where the AI will spin for some time trying to work out where to start - even if it has full context.

So I guess I'm half with you, but an LLM used right can still teach you effectively.

Did you find out if it actually fixed the issue? I was on the other end of this last week. Reported an issue to another team, they asked Claude to diagnose, and when they gave me the response back I pushed back cause it didn’t make sense given the behavior we were seeing. Turns out Claude had hallucinated reading a log (it said it did but it didn’t). Sent it down a hole rabbit hole from there.

I’ve had the one shots you describe and they’re great, but they’re the happy path and require almost 0 skill to find. I’ve yet to see a case where developing an expert level knowledge of your domain isn’t the best way to get good at LLMs. Knowledge of how to interface with these tools is helpful but changes (and depreciates) rapidly as the models get smarter and/or other people commoditize it. Deep subject knowledge is still the best way to get a lot out of these tools. This applies to development and other areas I have a deep knowledge of.

“LLM training” is kinda snake oil. Learn your craft deeply and you’ll be able to catch up on LLM training in a few days, but you’ll be light years ahead of a person who’s only expertise is different ways to prompt.

The issues was really simple, I knew the application, I knew what the bug was and already had a workaround in my head. I simply stopped at going down that rabbit hole and told claude to deal.

It identified the issue quickly, found the workaround and made the developer aware. All those things I would have done I just watched it do for me, plus, the app is vibe coded anyways, I just need it fixed and regardless of the AI path it was faster shooting out the bug report. Which, was simply poor processing of a spreadsheet.

If that's the case, Claude isn't gaining you anything. The hard (and time consuming) part of programming is finding the correct solution, not typing the characters into an editor. When I know the code and have a good idea of the solution, I can write the code to fix it in mere minutes.

I don't have time for that, and neither do the teams that consume these request. As time has gone on me and the other teams I work with are no longer touching code, the AI will follow processes and procedures that pre date AI just fine with some human reviewing and approving.

AI has turned what was weeks at minimum to get a bug fix out, to just doing it all with with some human gating. It's not been a smooth process but watching it play out in real time it's getting faster, more efficient, and less prone to problems.

And that the crux off the situation, patching and securing configurations need to be done much faster than today, project glasswing has shown us that AI can scale to identify and solve those problems faster than a human.

Regardless, why not help the developer use the tools effectively instead?

It just got really good over time, especially as new processes get brought it and things change. I can't keep up with that like that AI can, just have it review and go down the path of ensuring that it fit's in my workflow as efficiently as possible and move on.

As far as the developer? I gave him ideas but he's on another team and I got my own guys to feed.

What's that?

At the risk of you already knowing this or similar - in essence for a slice of a piece of work, you get the LLM to research the information required into (usually) a research file, which you go back and forth with in-line or via conversation until you're happy.

You then build the plan for the piece of work, again going back and forth with the LLM until you agree with the plan, with the key here being you have a specific set of concrete steps with very limited vagueness. Again this is quite often a plan document.

You then implement the plan with your LLM, following the concrete steps and monitor/evaluate the result.

For me its the 101 mandatory first way to use LLM that turns it from guesswork to genuinely useful. (that or some other similar method, SDD or whatever)

Because without it or something similar you're fully dependent on AI's weaknesses not coming to the fore (context/scoping failures that are silent unless you demand visibility up front and ruthlessly chop/clarify), and you often ascribe bad AI slop as model limitations instead of context/scoping failures.

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.

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....

I guarantee you'll spend less on tokens, have better documentation, better code, and most importantly more competent engineers.

On the other hand, I think this denies the reality (in my experience anyway but I think enough people will agree) that one often solves a problem as they are working on it.

This method seems to presume that a good engineer will submit a well thought-out solution or direction giving the AI an extremely good overview of each problem and enough of a description of what to do that it will do things as expected and they can just review the result.

In my experience it just doesn't work that way in practice. One learns the problem and even the domain while developing the solution. So one would have to submit at least a half developed solution not just "instructions", for there to even be coherent instructions in the first place. And one needs that experience working on the problem to be able to properly evaluate a separately proposed solution.

All in all for me this leads more towards using AI as a co-developer than using it to just implement some fully thought out idea and then check what it did.

Yes it does make that presumption - but that's part of the model here, that "prompt review" becomes the new code review and that the team is training on standard prompt semantics.

I'll share my outline - which is basically the one that was drilled into us in engineering school (CMU class 89)

1. Problem Statement

2. Definitions / Assumptions

3. Plan of attack / Options explored

4. Implemetation / Results

5. Limitations / Future Work

> So one would have to submit at least a half developed solution not just "instructions

The outline supports that in that you can fill out that part of the document which has been woeked on - including referencing any existing code.

Any other engineering students here recognize that outline?

That's the other side of the country, but it's how it's done over here also.

Still pull the old plough varieties, still practice shed blacksmithing, etc - even while developing and using autonomous Ag-Bot tractors for spraying, etc.

People will "trad-code", but not because it's the productive thing to do.

The serious side is simple enough, local food security - when there's no diesel to seed and harvest with there will be no export crops from here to feed millions across the planet .. but we here will still have smaller crops via animals for our food.

I'm literally in one of the most isolated parts of the globe, WWII, COVID, shortages via Iran clustf*ck, etc have real impacts and we plan to ride those out, like floods, droughts, cyclones, etc.

I'm sure you've considered that, I'm curious if you could share your thinking on this aspect.

Some people took the answers and learned from them, incompetents just copy pasted them and called it a day.

The share of incompetence just went significantly up over the years, so its a significantly more noticable issue at this point.

Do your silver platters give you some competitive edge? If not, then is the ego problem yours, or your coworkers?

Smartphones - mostly yes.

Smartphones are fully portable which makes them always available and super addictive.

Computers have 10% of that addictive power.

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.

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...

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.

In a way all we've done (currently) is drastically expand the amount of technical debt across the whole industry.

Should be profitable for the ones who can still actually program though and haven't let their skills atrophy by letting Claude do everything.

I don't deny there are use cases for LLM's, I just don't buy the hype about them either.

As with all tools, you have to understand how to use them to get done what you need to get done without sticking the chisel through your hand.

Have you tried refactoring or porting codebases larger than a million lines of code pre-gen-AI and again post-gen-AI? It's night and day difference. One would be insane to schedule a team on 8 months worth of grunt work porting from one language or framework to another which can now be done by 1 person in 4 weeks.

Of course the person driving it has to tell it exactly what to do and has to have the requisite knowledge to understand how to effectively structure or fix the software. Maybe new developers don't build this skill so easily anymore. But I don't see why a strong developers skills would atrophy in this case though unless they just never use their knowledge and never give instructions to the AI.

To developers speaking of skill atrophy: are you still making sure that when using LLMs you are actively exercising skills like system design, debugging, reviewing for clean code and just in general doing effective code review? If you are doing that, why do you feel skill atrophy? And if you aren't doing it, why not? What about LLMs prevents us from exercising these skills?

The demand for real programming skills will become infinite (again).

someone who can actually read, understand, and debug code. when the clankers get stuck.

unfortunately, there will be only be a dozen people.

Anecdote I like to tell.. I was working on a financial planning software, intentionally purely vibe coded as an experiment.

I eventually discovered AI had implemented seven duplicate copies of tax calculation functions. All of them different. All of them wrong. All of them giving different answers for same input.

Not even the most junior of newbie junior engineers would do something this crazy. But AI was happy to do it. It will solve the immediate problem, efficiently. Even if the most efficient solution is something ridiculous like this.

A person that was hired as an expert in our startup spent more than one week full time working on implementing his solution to the problem we were having. I checked the code after one week to see the progress and was curious how they are implementing an already crazy sounding idea. I found that the whole week was spent re-implementing in python, python's built-in "float" function. That was it, the whole code was just that.

Our problem was related to financial services and their implementation of "float" was not even correct.

I'll leave it up to the reader to figure out why this may be important.

What happened to him? What was the conclusion? Did he get paid?

that is the deal for an employee, you put in the hours, you get a check.

today, this individual is CTO- Vibecoding at Uber.

nevermind

The llm just allows to generate faster.

We can feel smug about that but all it means is that we need to be clearer on our requirements and preferences up front.

State that similar functions should be in one place and there should be only one. Today there has to be compelling reason why that function is different from others. Normalise the function name based on what it does. Why are there different ones?

Then there are all the other guard rails in place.

Better guidance from mentors, reviewers, and automated project tooling helps everyone. Juniors, seniors, and engineers.

And whilst it is obvious things are growing... Saying that, sounds almost entirely like the person saying it cannot objectively look at the environment. If everything has changed in the last six months, why has the industry not radically changed to match it?

Everything really did change with the Pentium II. It did with 3dfx. It did with Damerau's taken on Levenshtein. Hell, everything changed with React. The AI leap with seq2seq completely revolutionised the entire industry. But... Its kid, the LLM? Really?

What I would like to see is a chart graphing the model size against some objective measure of capabilities, specifically for coding.

It's easy to see gains when you're doubling the effort. What I want to know is if the extra effort is opening up more capabilities over time or fewer capabilities over time.

How many times I heard ORM are bad only to recreate the same shit?

How many times I heard ORM had bad performance and see 1+n stuff everywhere?

How many times I have seen tight coupling in the name of DRY?

We don't get seniors, without juniors. I'd say more than half the job, is just... Learning. People grow.

In the mean time put a plethora of guardrails in place to make sure the AI Train doesn’t derail production.

Oh. And keep showing your value. In the end every org can do with less low paid overeager uninterested juniors. Might as well let agents Do those tasks.

Or they just have their own hubris and ignore your (provably better) suggestions because their way is "better/easier/how we've always done things".

And then you end up with someone sprinkling N+1 issues throughout the system and making systems with bad architectures throughout the years, not thinking about backpressure etc., as well as shoving ALL the dependencies into a single codebase cause they're not used to creating new ones, turning patches into eventual month long version upgrades because everything keeps breaking with anything newer than JDK 8 and some of the packages are deprecated and gahhhh I should pick up woodworking as a hobby.

Though, to address the original claim:

>> If it is a better engineer than you... You need practice.

This feels like a thought terminating cliche. Like, it will spit out bullshit every now and then, and make assumptions that I don't think that many engineers would (e.g. since a lot of each app is environment-specific), but at the same time when you guide it and give it examples, it can really be quite good! So not that unlike humans at all, even competent devs might not necessarily know about every pattern in any given codebase, especially when one has been around for 10 years and grown quite a bit.

It can be quite good if you have something like ArchUnit or your own tools for linting project architecture and patterns, alongside proper documentation that doesn't assume that you're a team member with X years of experience on system Y. AI just forces people to be less lazy and ignorant about knowledge transfer, which they should have also been for the sake of other humans!

I have worked with some amazingly incompetent devs. Some promoted into place to become someone else's problem, and some parachuted in through connections, and never once have they brought the continuous and unevolving frustration of modern LLMs.

I taught one of our "React SME"s, what Typescript even was. And they, were less likely to throw a ten thousand line fix, where twenty would do. They didn't see that the DB had a list of validation rules, and copy and paste those into seven different files, instead of just querying the DB, so the code would be kept up to date. And whilst I might have had to repeat that the DD is our source of truth, they never argued that implementing the DD wasn't aligned to the intended design.

AI isn't forcing people to be better with knowledge transfer. It's taking conversations that happened in person, that were back and forth and gave both people a better understanding of a thing, and turning it into a half-assed and out-of-date wiki. Without all the things that make a wiki actually useful to onboard the next newcomer.

I do get what some of these frustrations are, and where they come from. I'm the official documentation maintainer, because nobody else ever wrote anything down on expectations. Its fairly thankless. But... All I've seen AI do in that same realm, is exacerbate misunderstanding.

Like when it presented an Apex script (Salesforce) guaranteed to exceed governor limits to our junior, who took it and ran with it. And when it aborted, the AI spent half a day leading the junior around and telling them to change config settings - that the environment was the problem, not the code.

The fix? Toss the three layers of Queueables, and use Database.insert on a list. Job done. PR for 150LoC, instead of the offered 780LoC.

(As a complete aside, can anyone convince Salesforce to fix the documentation for: https://developer.salesforce.com/docs/atlas.en-us.apexcode.m...)

But that is not a point. Claude can code tight compact loops, it just needs to be instructed to do so! If it does "enterprise code", it means it had no instructions about code style.

If your documentation, spec, agent.md does not have proper guidance on coding style... yet another red flag!

Considering how often it overrules, its own rules?

It is my pet peeve with Claude and why I don't prefer it for most stuff

(also the comment spam - but that's a all of them in a way or another)

Some asian devs will go for weeks without asking for help, all while giving amazing fake status reports. Loosing face etc...

I think some of these anti-claude comments have some face, then I get a peek into how people use them, and it seems all wrong.

The tooling is incredibly configurable, but comes out of the box with a big auto button, because thats what people want. Doesn't mean advanced users have to use it.

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.

If model can not automatically reproduce bug, while human manually can... you got a problem in CI.

> Luna Max performing better than Fable 5.1 High

Perhaps you are reading too many benchmarks.

Edit for answer :

I agree Luna is great cheap model.

But if Fable was hitting security limits, yet was still included in benchmarks...

What flies better? Elephant or paper plane. You can make objective benchmark about that. But not much value for logistics company

Maybe, but at least the benchmark provides an objective measurement of the codebase it is tested on. You're also assuming the bugs are newly introduced / regressions.

I can give a concrete example - Fable will not interact with bugs that result in writing to null pointers in C code. That triggers the guardrails and ends the session. If Luna (or GLM Flash, etc) will fix those kinds of memory bugs, that immediately puts it ahead of Fable in some ways, no matter how tiny Luna is. Again, models are spiky.

I still agree with your initial point! It's LLMs all the way down over here. It would need to be a particularly gnarly bug & an exceptionally talented human for me to want to pay another human to work on fixing it now.

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.

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 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’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.

As a bonus, that person will spend half of the week asking their peers for crazy delusional stuff.

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.

I disagree. I think this happens as soon as the MBAs come on board, where everything becomes a metric, and you work towards OKRs.

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.

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.

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.

But I’m not really pushing an agenda here. I use Claude a ton myself.

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.

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.

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.

For anyone else wondering what RPA means. Never heard that abbreviation before.

  > For anyone else wondering 

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.

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.

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.

Yes, unless it's Boeing. New system that takes over pitch control? Naw, that can't have bugs, so we don't need to tell pilots how to turn it off.

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"

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.

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.

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...

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

Reminds me of the move from on prem to cloud. Linux sysadmins were killed and replaced by aws focused devops.

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.

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.

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.

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 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.

It's not the case for other industries, and in particular car industry is able to hide about everything software related from inspectors.

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.

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://www.sciencedirect.com/science/article/abs/pii/000510...

The article is based on evidence, and states it clearly in the body.

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 simulation solution is backed by their own applied example, and is also the logical intervention based on how the problem is set up.

Perhaps Bainbridge is doing more heavy lifting for me, by filling in blanks and gaps that others are finding.

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.

Exact. Let insurance cover it, say sorry to your customers twice and shwoop never happened.

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.

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.

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."

If you never have outages, then you need to start getting either creative with the "table top" exercises or you set up a test environment that is very prod like and have someone randomly turn off components aka chaos engineering.

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 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).

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.

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.

And what happens when the competency drains away?

Visual Basic 6 wasn't even too esoteric, it could have happened already if it was a thing.

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.

Why does it not apply?

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.

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.

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.

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.

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.

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.

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.

I propose creating solutions and programs that will help engineers and coders take control of their projects and prevent AI from taking its course. This applies to all areas of life—economics, medicine, and much more.

AI is a wonderful technology that will accelerate our development. But it must remain a tool controlled by humans.

I say this as an AI proponent. Humans are the ones that touch grass.