Comment by hibikir | Hacker News Reader

Comment by hibikir | Hacker News Reader

Highlighting this as a good thing is just... not great

> Code you did not write is code you do not understand > You cannot maintain code you do not understand

We need no AI for this one: If I could only maintain code I wrote, I'd have to work alone. Whether I am reviewing code written by AI or by a human is irrelevant here. The rest of the comments on the human we know having more trust is in itself a smell on your development process: This is how we get cliques, and people considering repos hostile, because there's clear differences in behavior for well known contributors, who are just as capable of writing something bad as anyone else. If there's anything I have seen in code review processes, regardless of where I've worked for the last couple of decades, is that visual inspections rarely get us anywhere, and no organization is willing to dedicate the time to double check anything. Bugs that happily go through inspection come in too even when the organization commits to extreme programming: Full time TDD and full pairing.

There is a question on how fast we can merge code in a project safely, regardless of the identity of the author of the PRs. A systematic approach to credible, reliable development. But the answer here has very little to do with what the article's author is saying, and has nothing to do with whether a contribution was made by an AI, a human, or a golden retriever with access to a keyboard and a lot of hope.

> If I could only maintain code I wrote, I'd have to work alone.

I don't think that "Code you did not write is code you do not understand" implies that the only way to understand code is to write it. I can read code, run it, debug it and figure out how it works.

It's true that all of that is possible with AI generated code. But the thing is, is it worth for me spending time understanding that PR, when I can make the change or launch my own agent to prompt it myself? At least with my own prompt I know exactly what I want it to be.

Exactly. If the only effort of coding was in the writing, we would have much more code, applications, etc.

The real effort of coding is understanding it, reviewing it, improving it, making it work, and work well and durably. All of this requires thinking.

It does imply that. It directly says, if you didn't write the code, then you don't understand it.

It says if you didn't write the code and you read it then you don't understand it.

It says if you didn't write the code and you debugged it then you don't understand it.

It's wrong, obviously.

If code reviews don't work, pair programming doesn't work and TDD doesn't work either, then what would work?

> We need no AI for this one: If I could only maintain code I wrote, I'd have to work alone.

I think you missed the whole point. This is not about you understanding a particular change. This is about the person behind the code change not understanding the software they are tasked to maintain. It's a kin to the discussion about the fundamental differences between script kiddies vs hackers.

With LLMs and coding agents, there is a clear pressure to turn developers into prompt kiddies: someone who is able to deliver results when the problem is bounded, but is fundamentally unable to understand what he did or the whole system being used.

This is not about sudden onsets of incompetence. This is about a radical change in workflows that no longer favor or allow research to familiarize with projects. You no longer need to pick through a directory tree to know where things are, or nagivate through code to check where a function is called or what component is related to which component. Having to manually open a file to read or write to it represents a learning moment that allows you to recall and understand how and why things are done. With LLMs you don't even understand what is there.

Thus developers who lean heavily on LLMs don't get to learn what's happening. Everyone can treat the project as a black box, and focus on observable changes to the project's behavior.

> Everyone can treat the project as a black box, and focus on observable changes to the project's behavior.

This is a good thing. I don’t need to focus on oil refineries when I fill my car with gas. I don’t know how to run a refinery, and don’t need to know.

Someone somewhere knows though.

> This is a good thing. I don’t need to focus on oil refineries when I fill my car with gas. I don’t know how to run a refinery, and don’t need to know.

No, it isn't. If you do not know what the project does, you are unable to even review the changes proposed by a coding agent.

Consequently, we already have a long track record of LLMs introducing vulnerabilities.

LLMs are great at speeding up small tasks but the trade-off is that developers become progressively clueless.

Reply on news.ycombinator.com