I hear this a lot as a reason to accept that only the robots have read the code: "but it's too much code for one person to understand."

Yes, but it's not ever too much code for a team to understand, or a community. The question is whether you can build a team or community with enough trust and integrity that two things are always true:

1. Alice understands the fluxtron renoberator module she wrote.

2. Bob can also shift his attention there and understand it if necessary, because Alice writes clean code that was reviewed by John and Sally.

You can have Alice, Bob, John and Sally all be robots, and you can decide to trust the robots, but (so far anyway) it's a choice, not an inevitability.

▲

TeMPOraL an hour ago | parent [-]

But 1 and 2 were rarely true pre-LLMs, not in any code that has substantial active development. Because 3 months later, the fluxtron renoberator module has been modified, fixed and refactored by 5 other people and looks little like Alice remembers it, and Bob, well, he could never shift attention and actually understand it, nor could anyone else, because that's just a nice story we told ourselves that never worked in practice.

	▲	jghn 4 minutes ago \| parent \| next [-]
		> But 1 and 2 were rarely true pre-LLMs, not in any code that has substantial active development. Every large project I ever worked on worked exactly this way. What do you mean it was rare?
	▲	skydhash 12 minutes ago \| parent \| prev [-]
		> But 1 and 2 were rarely true pre-LLMs, not in any code that has substantial active development. I'm ready to bet that is untrue. Sure, no one can recite the code, but people can quickly scan the module and refresh their memory as well as understanding the new changes, even after a while. If not, collaboration would have been impossible. > Because 3 months later, the fluxtron renoberator module has been modified, fixed and refactored by 5 other people and looks little like Alice remembers it I don't know for which type of projects those things happen, but good design can have a long staying power. Drastic refactoring in a short period is a clear sign of bad engineering. > and Bob, well, he could never shift attention and actually understand it, nor could anyone else, because that's just a nice story we told ourselves that never worked in practice. A lot of OpenSource projects are decades old, and while some core maintainers can stay for the lifetime of the project, new contributors came, understood the code, made changes, then left. Same for hires in companies.