AI and developer skills

I’ll try to be brief rather than expository. There are plenty of longer posts saying all this in various amounts of detail, some of which I have linked below.

So, briefly:

If your project had weak quality processes, it may somehow limp along when development was at human speed. But when your developers start using AI, it will fail pretty quickly. (Actually, maybe I should count this as a plus point for AI!)
- Didn’t we have quality problems before AI? Yes we did. But it’s the speed that is the problem. Now the team leads don’t have enough time to review and fix/reject things before they roll into production.
- Before LLMs, a bad developer was limited by how fast he could type. Now he can churn out 10kloc of junk while he’s having a tea break.
- In short, Bad stuff happens faster than you can fix it.
AI generated code will look like it works. Until it doesn’t. And then AI will only make things worse, carrying you further and further away from any hope of understanding what is inside your own project.

One objection to my no-AI stance I heard from a young man was “we moved from assembly to C, C to Java, [etc]; this is just another step in that evolution”.

No it is not.

Assembly and compilation are deterministic transformations from one “language” to another, with very precise definitions of what they will do.
- Take a look at the C++ language reference, the Go language specification, the Rust language specification and see the depth of detail and specificity they have. Not only their output, but your input also has a specific syntax you need to be aware of.
LLMs are very, very, far from that. They are not even deterministic; in fact the same LLM when asked the same question twice may not return the same answer!
- And their inputs are in the most imprecise language in the world compared to C/Java/Go/Rust etc – English :-)
Compilers also do not change the semantics of what you want the program to do; you are in charge.
- In contrast, an LLM is making decisions of all kinds that affect the software far into the future, decisions you did not initiate, and probably don’t even understand.

Some links from my collection:

2026-07-16 – https://raymyers.org/post/zig-creator-calls-spade-a-spade/ – “Zig Creator Calls Spade a Spade, Anthropic Blows Smoke”
- excellent blog post on how Anthropic is trying to kill software engineering
- My interest here is in public literacy about AI in software
- some really great quotes there, far too many to list here, all presented in a mildly snarky tone that I love!
2026-05-30 – https://mastodon.social/@Ferdi_Scholten/116656414698174544 – rsync and AI slop – “Some of these commits are repairing defective generated code with other generated code…..”
2026-05-09 – https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/ – someone who realised LLMs don’t write good code in the long run

tl;dr: AI writes features, not architecture. The longer you let it drive without constraints, the worse the wreckage gets. The velocity makes you think you’re winning right up until the moment everything collapses simultaneously.
2026-04-27 – https://x.com/lifeof_jer/status/2048103471019434248 – An AI Agent Just Destroyed Our Production Data. It Confessed in Writing. – chilling story about morons who think AI can be trusted to do something important :( As this says:

Agreed. The post reflects that they were running an AI agent in YOLO mode in an unsandboxed environment with access to production credentials.

It doesn’t even seem to have crossed their minds that this behaviour is the real root cause. It’s everybody else’s fault.

The real takeaway is “the more AI you have, the more safety nets and guardrails you need”. A long time ago, someone said, “To err is human, but to really foul things up you need a computer”. Looks like that proverb needs an upgrade.