> It's asking somebody who writes code to now read and debug others code.

This has been a big part of the job for anyone on a team for at least 20 years. I do agree that it’s the hardest and worst part of the job, and has now become the majority of the job for anyone who isn’t vibe coding. So, that sucks.

> It's asking somebody who writes code to now read and debug others code.

That's exactly right. Open source projects are currently drowning under LLM generated PRs, where those who used to write code are simply punting that work to AI, but still expecting others to review it. It's not okay to expect such a free lunch. If you moved the labour of writing code one step away, then you are yourself the first line of defence now, so you better start reviewing code that you claim to be yours.

I agree. When you write your own code, you know what your intention was when writing it. Furthermore, as you gain experience and mature you know in the back of your mind that every mistake during code writing costs disproportionately more to fix later on. You only get that feeling by owning the code. AI cannot do that. It can't have skin in the game in that way.

> It's asking somebody who writes code to now read and debug others code.

Writing code has always involved reading and debugging your own code, at an absolute minimum, even if you did everything solo. In any remotely serious collaborative effort, it also involved code review and collaborative debugging; people use issue trackers and assign themselves and each other "tickets", which often involve fixing issues that are ultimately caused by someone else's code.

> It can actually be harder to find the the bug in a tricky piece of code than it can be to write your own correct code from scratch.

Part of the point is to reject tricky code exactly because it is tricky (as this is rarely actually necessary).

If you can explain how to reproduce a bug, you can ask the AI to debug the code and it usually works, in my experience. If not, you can ask it to add logging or other tools for better observability.

> With AI, everyone’s output looks like a Ferrari, so it is hard to know what the internals are like.

Based on my experience, this is a significant issue with AI generated code. You wouldn't expect a real Ferrari supercar to have random internal mechanical components that are, for no reason, completely inappropriate for a high-speed car design. With AI generated code, such inappropriate components can appear randomly at any point in the implementation stack. And very often, they are deeply buried under non-trivial algorithms and are thus not easy to spot.

And why wouldn’t writing software be a skill issue? Yes, it’s an annoying meme, but we should expect that there are better and worse ways to write software. It would be weird if everyone got the same results regardless of experience.

I’m doubtful that the author’s recommendation always work, but I do some similar things and they do seem to help.

In a way it reminds me of the good old "if agile doesn't work for you, you're not doing agile right".

It actually is though?

Though arguably more of a process and judgement issue than skill.

What makes LLM-generated code a bit special there is that misjudging how to deal with it seems to be what most people do. So the default is broken.

Whereas in prior iterations of "skill issue", the default was working.

What's a crash going to do? The internet didn't disappear after the dot com bubble popped.

I think the point is just it doesn’t have to get worse, so there are things you can do to prevent / change it if it is deteriorating.

The issue is that in order to have the agent write good code, you need to implement standard SWE best practices. But that also means a lot of manual intervention in terms of writing specs, checking acceptance criteria, and reviewing code. So you end up spending a lot of time on managing your agent, which means you won't get a 1000% productivity gain, you get maybe 50 or 100, possible less in some areas and with some issues.

I'm curious as to what guardrails you've tried.

This is something I have been trying to get right as well. I've attempted to use lots of linting and things like strong typing, duplicate checks, cyclomatic complexity, and robust tests. However, I still happen to find issues, which requires me to look at the code (at least at a high level)

For example, I can say "Don't repeat yourself, and don't re-write helper functions" and I will even have a duplicate linter check, but inevitably the LLM will always want to re-write a similar yet slightly different helper function. Like it will always want to re-write something small like a trim() or a toString() function in every file.

I would say that it is like gardening. If you let them go havoc from the start, the weed will take over. If you keep focusing on removing the weed and enforce specific standards and practices over the code base and it keeps growing, over time LLMs start to suddenly follow that and they don't make so much slop anymore. At least that is my experience. But I force specific audit agent after every added feature which says them to force compliance with AGENTS.md and check the consistency with the code base.

My experience as well, working on very large-scale C++ code.

Thanks for adding such a thoughtful and level-headed comment to the discussion.

>most of the time there are few issues to correct.

Kindly share the metrics by which you evaluate the changes.