The old copy/paste from StackOverflow was essentially vibe coding, it just took a bit more effort. I saw plenty of people Google their way to code that technically worked, without having any idea how or why.
If someone has been doing that for 10 years and learning nothing, that would be a huge red flag. One that will likely become more common has LLM usage increases.
> Do you really need to go to the ER because you stubbed your toe?
Where else are some people supposed to go? Maybe that toe is starting to change colors… is it broken? Do I need to have it set? Is that possible for toes?
People have valid medical questions and don’t want to wait weeks to see their primary care. They might not live near an urgent care. The urgent care may have terrible hours, or they made the mistake of mentioning chest pain for their heartburn incident and now they are forced to the ER.
It’s a chicken and egg problem. Faster medical answers will lead to reduced ER wait times. Reducing ER wait times lead to faster medical answers.
Code reviews are a volunteer’s dilemma. Nobody is showered with accolades by putting “reviewed a bunch of PRs” on their performance review by comparison with “shipped a bunch of features.” The two go hand-in-hand, but rewards follow marks of authorship despite how much reviewers influence what actually landed in production.
Consequently, people tend to become invested in reviewing work only once it’s blocking their work. Usually, that’s work that they need to do in the future that depends on your changes. However, that can also be work they’re doing concurrently that now has a bunch of merge conflicts because your change landed first. The latter reviewers, unfortunately, won’t have an opinion until it’s too late.
Fortunately, code is fairly malleable. These “reviewers” can submit their own changes. If your process has a bias towards merging sooner, you may merge suboptimal changes. However, it will converge on a better solution more quickly than if your changes live in a vacuum for months on a feature branch passing through the gauntlet of a Byzantine review and CI process.
Or the reviewer feels responsible for the output of the code from the person they are reviewing or the code they are modifying. For instance a lead on the team gets credit for the output of the team
Also, wanting to catch bugs on review before they make your on call painful can be a large motivation.
I've always encouraged everyone more junior to review everything regardless of who signs off, and even if you don't understand what's going on/why something was done in a particular way, to not be shy to leave comments asking for clarification. Reviewing others' work is a fantastic way to learn. At a lower level, do it selfishly.
If you're aiming for a higher level, you also need to review work. If you're leading a team or above (or want to be), I assume you'll be doing a lot of reviewing of code, design docs, etc. If you're judged on the effectiveness of the team, reviews are maybe not an explicit part of some ladder doc, but they're going to be part of boosting that effectiveness.
It’s the lack of transparency that is the problem. There should be a clear labor exchange disclaimer: “we are asking you to do X minutes of AI training for one unit of in-game reward.” What people take issue with is Tom Sawyer tricking people into whitewashing a fence.
> Despite efforts to enforce clean energy, the bill died in committee
I wish it was easy to force issues like this into ballot measures. The citizenry should be able to rip control out of the hands of their representatives when so motivated.
There’s something to be said about the visibility of gambling as a signal to people that someone may have a problem. Gambling on your phone just looks like being on your phone. It even improves access to the addiction. Needing to go to a casino looks a lot different, provides some friction, and could spur intervention. The same could be said about loot boxes vs buying Pokemon cards in a store.
It continually amazes me how averse people are to just explaining why a commit exists in the body of the commit. Is all this tagging actually easier to read than written prose? You don’t even have to write it anymore if the sight of your editor opening upon `git commit` causes some instinctual revulsion.
The problem is that usually we don't write the WHY in the commits... We tend to always capture the WHAT in the form of prose. And for agents, this is just more noise, since all they need is just the diff to reconstruct the WHAT.
I've never seen someone write decisions or the intent they started with in commit messages. Even the solutions today that auto-generate commit messages just summarise the diff.
This was helpful when humans were the only ones reading the history. But for agents its useless.
A proper email is like an email. You have the first line as the subject and it may be enough to explain the intent of the diff. But sometimes it’s not enough and you add more details in the body. I strongly believe that people who write the WHAT again don’t know that there’s a diff attached to the commit and think of them a separatete objects. GitHub and VSCode do not really help in that regard.
Obviously projects have their own standards around comments, but as the why is apparently important and non-obvious, would it be even better for the ‘why’ to be a code comment in order to understand why code exists without looking through the git history for each line?
When you think of the patch as an unit of idea and the commit as the means to convey that idea, it takes the same amount of effort to write an email message.
BTW you do not have to write those for every single commit. You can always rebase interactively and create a final set of commits for sharing. No one cares about what’s in your local copy of the repo.
I think this requires discipline. The good thing is that we have coding agents, but again, you need a standard to tell the agent what to always look for, how to find it, and to describe your modules properly (even Claude Opus 4.6 makes mistakes when doing hops when tracing code spanning files). Btw, there is also a paper on this issue, Google released it recently
Because commit history is here to explain WHAT and not WHY. "Why" is explained by a decision log such as ADR which can be store in the same repo and can be mutated in the same commit that has WHAT in its commit body.
But also, if you look at large projects like Linux or FreeBSD, commits there explain why as well.
> Because commit history is here to explain WHAT and not WHY.
When that commit gets implicated by `git bisect` and all you see in the message is exactly what you’d see by reading the patch anyway, you’ll wish the author answered why they did what they did. This, especially, when the author is no longer at the company.
The WHY in the commit should just be a ticket ID or reference, at the beginning of the commit.
And IMHO in the first place the code is meant to be for humans, not machines/programs. Rhetorical question : If the LLMs are so great, why don't they just generate bytecode for binaries directly ?
The law should be updated to limit clean room reimplementation to a strictly human endeavor. Person, in a faraday cage room, with a machine that is too underpowered to run local LLMs. Reference material (stack overflow archives, language docs, specs, etc) are permitted.
> I worry that everything in society will become uniform
That’s why “slop” is so appropriate. It’s the runoff from the taps poured into a glass. Tastes like everything, nothing, definitely not pleasing, probably cheap, still effective at getting you inebriated.
reply