Well that depends on how quickly you believe that engineering skills atrophy without use.

Though, I’d argue programming is like riding a bike. Even after a long break, it’s not difficult to get back into it, as the fundamentals for programming haven’t changed.

Could you qualify what you mean by “idiots”? The author and the examples he gives - Kent Beck, David Heinemeier Hansson, and Garry Tan - are all very experienced software engineers.

Funnily enough, Lemmy does allow AI-assisted code contributions, though they’re not encouraged. This is mentioned in the code of conduct:

Use of so-called Artificial Intelligence (AI) is allowed only if it is explicitly mentioned. Additionally all LLM-generated text or code must be manually reviewed by the author before submission (no vibe coding allowed).

I 100% agree! Lots of open source projects have a similar policy, where AI coding tools are allowed as long as you disclose their use, and can explain every line of the code. Projects with this policy include:

• Ghostty
• Lemmy
• Mastodon

This article is not advocating AI driven development. It’s arguing a human understanding the problem, and how best to solve it, is the most important work.

I’m not anti-spec. Far from it. I think rigorous, well-structured specs are about to be the single most important artifact in software. Read the book. Adopt the format. Use the tools. The mechanics matter and I’m not waving them away.

But the spec is a vessel. The recipe is not the cooking. If we pour mediocre understanding into a perfectly-formatted spec, we get perfectly-formatted slop, faster and at scale. The format is necessary. It is nowhere near sufficient.

The real work - the part no tool will do for you - is the human work of digging in. Of actually understanding the problem and the person you’re solving it for, deeply enough to have an opinion about what right feels like. Of capturing not just the requirements but the taste. The why. The elegance. The exact sweet spot of how it should work.

I agree but those principles aren’t always applied to local development. For example when creating a GitHub personal access token, devs might give it all the privileges, instead of just the ones it needs.

By using such a formulaic reply, as an LLM would, I’m emphasising your point. 🤣

My point, and that of the author of the article is not to defend AI slop, rather it’s to offer real criticism, instead of making the accusation that something is AI generated:

That isn’t criticism. It gives the author nothing to fix. No sentence. No claim. No result. Just a little accusation dropped in the middle of the room. Just sending bad vibes for no reason

And it is rude to expect people to proofread your slop.

The author isn’t defending slop, in fact they hate it too:

I utterly hate AI-generated content. I don’t want machines to replace personal writing with synthetic filler.

What they are arguing for is AI assisted proof reading tools, particularly if English isn’t your native tongue:

But a spell checker doesn’t make a post fake. Grammarly didn’t make old posts fake. A machine helping a non-native speaker write more readable English doesn’t make the work fake.

Would you like to share any other social insights to continue this line of thought or would you like to find other places to share this thought so others can benefit from it?

Could you please explain what you’re trying to say? Are you saying that a programming community on the topic of AI, is not an appropriate place to share this article?

I agree that the AI generated image is trashy, however the article is a cautionary tale about the pitfalls of relying on agentic coding, instead of collaborating with other developers.

But there is always a ceiling on how far a single-player game can take you, even with agents. Software that lasts, software that grows, software that people can actually depend on – that is built by groups of people exercising judgment together over time. By teams developing shared taste, shared mental models, shared sense of what their product should be. None of that happens through individual prompting, no matter how clever the prompts.

Are you implying that Wes McKinney is also stupid, despite his open-source contributions?

Agile came from toyota?

My understanding is that Kanban came from Toyota, which is an agile way of working.

This is a fascinating article about the history of software development. For me the key quotes are:

The thing that killed Waterfall was that discovering your spec was wrong months later, after lots of code had been written - and fixing it cost a fortune because writing code was the most expensive part of the process.

The key reason Agile was invented was to account for the high cost of writing code, so yes, that part of the Agile value proposition is no more.

The risk isn’t that AI development is inherently Waterfall. The risk is that organizations with latent Waterfall instincts will use spec-generation as license to do the bad thing they always wanted to do — front-load requirements, skip customer validation, equate a fancier document with a better outcome, and ship one massive thing every quarter.

This quote from the article really sums it up:

And to be clear, I don’t care whether you typed the code yourself. I care whether you understood it before you shipped it. I care whether you can explain why the bug happened, why this fix is the right fix, what the model might have missed, and what would make you roll it back.

Could you elaborate on this?

Thank you! I’ve updated the post with the TL;DR from the article.

An acronym for domain-driven design.

This behaviour sounds a lot like addiction. It has been argued that AI coding tools may be triggering the same dopamine loops as slot machines.

Depending on your level of programming experience, you might find the exercises at Exercism quite useful.

In case anyone is curious, this is the original post on X.