Hacker News Reader

Comment by pegasus | Hacker News Reader

When coding the old-fashioned way, you were using automation as well, one example being the compiler. Still, if one is not even scanning the diffs anymore, I'm OK with not calling it "coding" anymore. We could call it "vibing" instead. But that's just words, the underlying activity is the same: creating and evolving software. That still takes skill, it's just at another level, and it's all about knowing how to use these... tools. This is what they are. A naive vibe coder is just (still) unskilled at using them and the results will be correspondingly limited.

View on HN

I think that's the next layer of conversation. The first is that Rich is saying, if we think of everything that a human uses for any purpose as a tool, it's not very useful to reason about.

When a definition explains everything, it explains nothing. So he goes on to setup some boundaries and describe some narrower qualities to try and help us reason about the nature of those things.

The only similarity between your keyboard and an AI agent is that they both have utility. You might say: "I used AI to write my essay" or "I used my keyboard to write my essay". It's very deceptive and easy to get trapped in thinking, these are the same, in both cases you just used a tool to write an essay with? AI is just a tool, like a keyboard. What Rich is trying to bring about is that there's actually a world of difference here. And if you keep thinking of a AI as "just a tool", you're missing that entire world of difference. It becomes much better to think of AI as automation and leave the tool definition to the keyboard. Now instead of saying "I used AI to write my essay" say "I automated the writing of my essay, I did not write the essay, AI did". That latter framing is so much more accurate, and changing that framing and perspective is going to give you a much deeper understanding of the impact, trade-offs, consequences, etc.

I agree that that's a useful distinction to make. Which is why code generated by the model should be marked thus in the repository, for example. Just like someone shouldn't check in assembly code as source code when it's actually a build artifact. So it all depends on the abstraction level one is discussing from, again, just like it is for a compiler. Ultimately, I would say automation is a type of tool. A human OTOH, is not.

I also think it means you have to operate very differently around it, it's about guardrails, quality assurance, funneling context, keeping output in check, emphasizing what matters and doesn't, etc.

It's less about code structure, maintainability, readability, algos, class/function abstractions, etc.

And to Rich's point, you're not getting to experience the process of coding anymore, what you'd have learned by doing it, about the domain, about logic, about structure, you're missing on that. You're likely learning something else though, at a higher plane, and maybe about managing autonomous agents, and so on.

Reply on news.ycombinator.com