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.

▲

holistio 2 hours ago | parent | next [-]

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.

	▲	reconnecting an hour ago \| parent \| next [-]
		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.
	▲	habinero an hour ago \| parent \| prev [-]
		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.

▲

hluska an hour ago | parent | prev [-]

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