Comment by musebox35 | Hacker News Reader

Comment by musebox35 | Hacker News Reader

Parent Full thread

> Some things you need to understand-others, not so much.

This is the core of the matter though, knowing what you need to understand and what you can ignore is the actual programmer's skill. It requires you to have a clear mental picture of both what you are trying to build and what the underlying machine will do when you are finished.

You need to understand the abstractions, but also where they leak, when they won't match reality, and how. This is why knowing computer architecture and assembly helps you to optimize your code even if you are coding in a high level language.

The problem with coding agents is that they are tuned to work on all contexts so they always fill an underspecified request by optimizing the average case and often without stating all the assumptions that they make. So you still need to understand what you specified and what got filled in automagically by the agent. My experience is that they (even the paid frontier models) are poor judges of the most important assumptions they make, which will might be corrected by a prompt or a tool output in which case it is fine. Otherwise it will be ignored and steer the model into a weird loop. It then tries to fix things but can not do so since its mental model is totally broken now.

Do not get me wrong, I am so happy to let the agent handle tool building (especially those that involve a web UI) and fill in the CLI command line argument parser. But every time I trust the agent by relying on it to drive the mental model of what we are doing, I got seriously bitten. Well, maybe that should not be surprise me, but I can understand the confusion of less experienced programmers and non-coders. It must really be frustrating to be able to build so much, but also not to be able to fix seemingly small issues.

That's just it. you didn't "build so much", you didn't build anything. You asked someone (or something) to build it for you.

How can people look at LLM-generated code and think "this is mine, I made this" is beyond me.

I’m in two minds about this, in some sense they did and it’s the same way in which the C code I write is mine, but the assembly underneath is an artifact of my intent, but I owe the compiler authors for it. On the other hand the cognitive distance between my C and the assembly is likely lower, but that’s because I’ve spent time staring at what was generated in order to figure out why my code was misbehaving. Which is itself not that dissimilar to figuring out how to get better at writing code with llms.

I think the difference involves how many layers of stuff someone claims is "theirs" and whether that claim of credit and expertise is valid.

Imagine a coworker writes some decent C code, but then at a meeting they start taking credit for the bytecode and the default optimizations done by the compiler.

That's analogous to people who write LLM prompts and then claim the same level of authorship over the code which was all generated and edited on an indirect level.

If you ask LLM to code something for you, and you then work on the code, then yes, there is partial ownership. Just like if you had asked another, maybe junior, developer to write a piece of code, and then you helped them make it better.

Agree wholeheartedly.

I'd like to add: we can't know a priori what will be needed to be known and what can safely remain behind an abstraction you just use.

That is revealed when our mental models grind against reality. Avoiding that friction at all costs is a problem because it will happen and you'll be unprepared when it becomes unavoidable.

Trusting some abstractions that have earned it but not all is how we deal with it. Limit your focus, and adapt. If you just trust all abstractions thrown in front of you until something breaks irreparably, you will be (person or organization) between a rock and a hard place and without any knowledge or skill on how to get out of that predicament.

That to me is the biggest risk in accepting the fallacy of general automation.

Fixing stuff by driving an LLM to do it seems like a distinct skill unto itself. It’s kind of this blend of your normal debugging skills, carefully managing what goes into the LLM and carefully constructing your requests.

For me at least it’s the one thing that feels like a novel new skill to learn more than anything else. Normal LLM prompting feels like just an extension of the mental process I’d use when coding and designing in a way that trying to get the LLM to fix things kind of doesn’t.

I agree that it is a bit weird, kind of coding in natural language but also not exactly like that. Maybe as the agents stabilize and there are proper new tools for this new process we can relax a bit and it will become the new normal. For now it feels like surfing over an ever changing seascape, exciting but tiring at the same time.

Reply on news.ycombinator.com