I'm just talking about statistical patterns. I know little about Microsoft patches. I abandoned Windows in 2001, right around the time XP was released, and have never looked back.

Not remotely similar to my experience. Granted I'm writing Rust, and the Rust compiler is *really* picky, so by the time the agent gets something that compiles it's a lot closer to correct than in other languages. Particularly if you know how to use the type system to enforce correctness.

Yes, you have to know how to write tests. A few decades of experience helps a lot. I find I actually spend a lot more time focused on the details of APIs and data structures than the details of tests, though. Getting APIs or data structures wrong will cost you down the road.

Also, I suppose it helps a bit that my work is in cryptography (protocols, not algorithms). The great thing about crypto code is that if you get a single bit wrong, it doesn't work at all. If you screw up the business logic just a little bit, you get completely wrong answers. The terrible thing is that if you get a single bit wrong, it doesn't work at all and gives you no clue where your problem might be.

Of course that's just functional correctness. With cryptography, the really hard part is making sure that the implementation is actually secure. The AI can't help much with that. That requires lots of knowledge and lots of experience.

Deep experience is absolutely required. My antennas are quite good after 40 years.

You really have to know what questions to ask, and what answers not to accept. It also helps to know what kinds of errors the LLM makes. It never outright lies, but it will guess rather than look, so you have to know when and how to push it, and how to manage its context window. When stuff starts falling out of the context window the machine starts guessing, approximating, justifying. Sometimes this means you need to make it spawn a bunch of focused subagents each responsible for a small piece of the problem. There are a lot of techniques to learn to maximize the benefit and minimize the errors.

Yeah, I am definitely not doing UI work.

Speak for yourself. I wrote Android's Keymaster implementation in less than a month, and it was about that size, and then re-wrote most of it in a week when it turned out I'd made some core assumptions that Qualcomm couldn't match in their implementation. It was relatively bug-free for a decade -- even when a third-party security research lab spent a month scrutinizing it. They found a handful of things, but nothing serious. I was amazed, especially since I'd seen the reports they turned in on some other code.

That's just one example. In my nearly 40-year career I've had a half dozen crazy-productive weeks like that, and usually when working on particularly-complex bits. If you haven't had that experience, that's unfortunate. It's not something I could do frequently (or would want to), but it's a glorious feeling when you're that deep in the zone.

Thus practice may be very bad for your health. Not that these "executives" care, but you should.

Yes. And that is how AWS got their 13 hour (?) outage. That outage was probably more expensive than what they can save in cost over a year or several by using LLMs as surrogate coders.

Why stop there? Make it part of the start-up message and if there is none, add one!

Well, the routinely clueless economics graduates certainly think so. My take is that in a few years actually competent coders will be in high demand to fix the mess and out out a lot of fires. When that happens and if you are inclined to participate, make them pay through the nose.

Sounds like very risky behavior. But some people are simply not smart...

A year? I've regularly written that much in a month, and sometimes in a week. And, counter-intuitively, its during those sprints when I'm pumping out thousands of lines per day that I write the code that turns out to be the highest quality, requiring the fewest number of bugfixes later. I think it's because that very high productivity level can only happen when you're really in the zone, with the whole system held in your head. And when you have that full context, you make fewer mistakes, because mistakes mostly derive from not understanding the other pieces your code is interacting with.

Of course, that kind of focus is exhausting, and you can't do it long term.

By focusing on the structure, not the details. The LLM and the compiler and the formatter will get the low-level details right. Your job is to make sure the structure is correct and maintainable, and that the test suites cover all the bases, and then to scan the code for anomalies that make your antennas twitch, then dig into those and start asking questions -- not of product managers and developers, usually, but of the LLM!

But, yeah, it is challenging -- and also strangely addictive. I haven't worked more than 8 hours per day for years, but I find myself working 10+ hours per day on a regular basis, and then pulling out the laptop in bed at 11 PM to check on the last thing I told the AI to do, mostly because it's exhilarating to be able to get so much done, at such high quality, so quickly.

Will probably not take long.

I have no idea what graduates you look at, but this is not the case here (Europe).

Pretty much this. LLMs can be convenient, but they are not magic and that they make competent coders slower is pretty well established by now.

The problem with that is that external pressure to get better is raising, both from reliability requirements and from security requirements. In this case, stagnation means getting worse and worse.

Well, that is certainly what they are planning. Just one problem: The evidence is mounting that LLMs cannot replace competent engineers.

No surprise this idiocy is happening in other areas too. There is a special kind of mental disability you need to have (or acquire) to be an economics graduate: A total inability to see more than a few months into the future and a total inability to do any kind of risk management. It worked? Everything must be more than fine and surely we can do it cheaper, right?

That is why people with critical institutional and technological skills are not treated even remotely at their value, let alone critical for organizational survival. Tech history is full of big names that are not around anymore or only in massively reduced forms. And in most cases, it is because some "managers" did not manage to think.