The frustration is familiar to anyone who has tried to build real understanding from open-source machine learning repositories. The user is right: most projects ship weights and a thin layer of inference code, then call it done. Missing hyperparameters, undocumented preprocessing, abandoned configuration files, and tutorials that never mention the six hours of debugging a silent shape mismatch. This is not open science. It is a gallery of half-finished work, and the community has normalized it to the point where a clean repository like Karpathy's feels like an exception rather than a baseline.
What strikes us is not the gap itself but the user's deeper desire. They do not just want a script that runs. They want the reasoning behind the choices: why batch size 64 and not 128, why that learning rate schedule, what failed first. That is the difference between copying code and building competence. In practice, this means that anyone trying to move beyond tutorial-level work is forced to reverse-engineer intent from incomplete artifacts. You spend hours guessing whether a particular trick was deliberate or accidental. You pick through commit histories hoping for a comment. The cost is not just time, it is confidence. When you cannot trust that a repository actually does what it claims, the entire field feels less reliable.
The reasons are practical, not malicious. Researchers are measured by papers and citations, not by the cleanliness of their GitHub. Deadlines push toward "works on my machine" and move on. Companies have genuine competitive reasons to keep training recipes vague. And yes, thorough documentation is expensive. But the user's post points to a cultural choice that the community keeps making: we reward novelty over reproducibility, and we treat "open source" as a checkbox rather than a standard. The result is that a motivated learner spends more time filling in missing pieces than learning new ideas.
This matters because it slows down the entire field. Every person who gives up on reproducing a paper because the repository is a mess is a person who might have contributed something later. The fix is not complicated: treat the code and the reasoning as part of the contribution, not an afterthought. Write the README as if someone who respects your work will read it tomorrow. List the failed experiments. Explain the one hyperparameter that took two weeks to tune. That is the difference between handing someone a tool and teaching them how to build one.