undefined | Better HN

0 pointsreconnecting3mo ago0 comments

OK, let's say there are two categories of software now.

One is where the human has a complete mental map of the product, and even if they use some code generating tools, they fully take responsibility for the related matters.

And there is another, emerging category, where developers don't have a full mental map as it was created by an LLM, and no one actually understands how it works and what does not.

I believe these are two categories that are currently merged in one Show HN, and if in the first category I can be curious about the decisions people made and the solutions they chose, I don't give a flying fork about what an LLM generated.

If you have a 'fog of war' in your codebase, well, you don't own your software, and there's no need to show it as yours. Same way, if you had used autocomplete, or a typewriter in the time of handwriting, and the thinking is yours, an LLM shouldn't be a problem.

0 comments

slibhb3mo ago

> And there is another, emerging category, where developers don't have a full mental map as it was created by an LLM, and no one actually understands how it works and what does not.

I work with a large number of programmers who don't use AI and don't have an accurate mental map for the codebases they work in...

I don't think AI will make these folks more destructive. If anything, it will improve their contributions because AI will be better at understanding the codebase than them.

Good programmers will use AI like a tool. Bad programmers will use AI in lieu of understanding what's going on. It's a win in both cases.

seanmcdirmid3mo ago

> And there is another, emerging category, where developers don't have a full mental map as it was created by an LLM, and no one actually understands how it works and what does not.

Are the tokens to write out design documentation and lots of comments too expensive or something? I’m trying to figure out how an LLM will even understand what they wrote when they come back to it, let alone a human.

You have to reify mental maps if you have LLM do significant amounts of coding, there really isn’t any other option here.

hluska3mo ago

That sounds exactly like using a new library. The absolutists miss so much and contribute so little.

holistio3mo ago

We never really have a complete mental map.

"Oh, this library just released a new major version? What a pity, I used to know v n deeply, but v n+1 has this nifty feature that I like"

It happened all the time even as a solo dev. In teams, it's the rule, not the exception.

Vibing is just a different obfuscation here.

habinero3mo ago

No. I see this mistake everywhere. You're confusing "knowing everything" or "making assumptions" with "mental maps". They are not at all the same thing.

The benefit of libraries is it's an abstraction and compartmentalization layer. You don't have to use REST calls to talk to AWS, you can use boto and move s3 files around in your code without cluttering it up.

Yeah, sometimes the abstraction breaks or fails, but generally that's rare unless the library really sucks, or you get a leftpad situation.

Having a mental map of your code doesn't mean you know everything, it means you understand how your code works, what it is responsible for, and how it interacts with or delegates to other things.

Part of being a good software engineer is managing complexity like that.

reconnectingOP3mo ago

There's a difference between not knowing the internals of a dependency you chose deliberately and not understanding the logic of your own product.

When you upgrade a library, you made that decision — you know why, you know what it does for you, and you can evaluate the trade-offs before proceeding (unless you're a react developer).

That's not a fog of war, that's delegation.

When an LLM generates your core logic and you can't explain why it works, that's a fundamentally different situation. You're not delegating — you're outsourcing the understanding, and that makes the result not yours.

j / k navigate · click thread line to collapse

0 comments

slibhb3mo ago

> And there is another, emerging category, where developers don't have a full mental map as it was created by an LLM, and no one actually understands how it works and what does not.

I work with a large number of programmers who don't use AI and don't have an accurate mental map for the codebases they work in...

I don't think AI will make these folks more destructive. If anything, it will improve their contributions because AI will be better at understanding the codebase than them.

Good programmers will use AI like a tool. Bad programmers will use AI in lieu of understanding what's going on. It's a win in both cases.

seanmcdirmid3mo ago

> And there is another, emerging category, where developers don't have a full mental map as it was created by an LLM, and no one actually understands how it works and what does not.

You have to reify mental maps if you have LLM do significant amounts of coding, there really isn’t any other option here.

hluska3mo ago

That sounds exactly like using a new library. The absolutists miss so much and contribute so little.

holistio3mo ago

We never really have a complete mental map.

"Oh, this library just released a new major version? What a pity, I used to know v n deeply, but v n+1 has this nifty feature that I like"

It happened all the time even as a solo dev. In teams, it's the rule, not the exception.

Vibing is just a different obfuscation here.

habinero3mo ago

No. I see this mistake everywhere. You're confusing "knowing everything" or "making assumptions" with "mental maps". They are not at all the same thing.

Yeah, sometimes the abstraction breaks or fails, but generally that's rare unless the library really sucks, or you get a leftpad situation.

Having a mental map of your code doesn't mean you know everything, it means you understand how your code works, what it is responsible for, and how it interacts with or delegates to other things.

Part of being a good software engineer is managing complexity like that.

reconnectingOP3mo ago

There's a difference between not knowing the internals of a dependency you chose deliberately and not understanding the logic of your own product.

When you upgrade a library, you made that decision — you know why, you know what it does for you, and you can evaluate the trade-offs before proceeding (unless you're a react developer).

That's not a fog of war, that's delegation.

j / k navigate · click thread line to collapse