It's pretty trivial to remove the Claude attribution from Git commits.
tatterdemalion
joined 3 years ago
That definitely increases the challenge of writing tests or trusting that they are faithfully representing your production environment.
I could abstract out the reading of the data
I was going to suggest this, and it sounds like that ends up being expensive. It seems like you need some kind of test harness that's able to emulate your specific hardware while still allowing for testing hooks that don't impede the tight clock scheduling.
he is comparing a deterministic tool with a non-deterministic tool
Yes, but that's not the argument Mikina was stating. Linus was never advocating for reading assembly line by line. Linus was using that as a satirical example, not suggesting anyone should actually do that.
That you should also not trust every line of the compiled assembly after you wrote the code, and check it lime by line, is an extremely stupid argument.
I guess it's good that no one is making that argument then.
high performance embedded systems that are difficult/nearly impossible to unit test
Sort of a change in topic, but I'm curious why that would be so difficult to test.
Competent developers make mistakes too. I think it's worth at least skimming every line in a PR. Things like indexing out of bounds should probably be handled by testing or using a memory safe language.
I don't think code review is the place where you should be trying to catch bugs in the minutia of the code. You should be assessing readability/maintainability, architectural decisions, risk, and testing strategy. That does involve reading all of the code, even if only by skimming.
where you have to focus and review everything line-by-line
Do you not think all code deserves this level of focus?
Assuming you didn't know what tools were used to write the code that you are reviewing, how would reviewing it be any different? You would still ask the human author questions about intent if that were not clear. The quality of their responses may or may not be impacted by their use of LLMs, but that is up for you to reason about as the reviewer, and it's perfectly fine to tell someone they are being a jackass for only sending slop to you.
Just show that in your presentation and make them all wait for however long it takes.
As I witnessed today, even just stating that you are opting out is not enough. You must ensure, of your own accord, that the camera is not directed at you when you approach the TSA agent, or else it will automatically photograph you.
I've also had a TSA agent tell me that I need to tell them I opt out before handing them my ID. This is obviously problematic but that's just how this shit works today.
I agree that we should be careful about how we use passkeys, but I don't think "do not use them" is valid advice.
This article only convinces me that a company like Netflix could support passkeys in a non-restrictive form (unattested, copyable, etc) and then ratchet up restrictions slowly as adoption increases. But this is really the same game we play with all other dark patterns like price hikes, pay-to-still-watch-ads, user tracking, etc. The savvy will realize quickly that enshittification is happening, and they will seek alternatives.
To me, this is not adequate justification for boycotting the entire passkey technology. I find them convenient, and I use them in my own homelab identity provider. Only a handful of the services I use even support them properly yet, but I wish more did.
From DHH's long-winded keynote at Rails World 2026. He was bragging that Hey's backend is so efficient because it's written in Rust (which he hates and refuses to read).
view more: next ›
So you're saying we need to embargo ourselves.