Fundamentally, unit tests are using the same system to write your invariants twice, it just so happens that they're different enough that failure in one tends to reveal a bug in another.
You can't reasonably state this won't be the case with tools built for code review until the failure cases are examined.
Furthermore a simple way to help get around this is by writing code with one product while reviewing the code with another.
> unit tests are using the same system to write your invariants twice
For unit tests, the parts of the system that are the same are not under test, while the parts that are different are under test.
The problem with using AI to review AI is that what you're checking is the same as what you're checking it with. Checking the output of one LLM with another brand probably helps, but they may also have a lot of similarities, so it's not clear how much.
> The problem with using AI to review AI is that what you're checking is the same as what you're checking it with.
This isn't true. Every instantiation of the LLM is different. Oversimplifying a little, but hallucination emerges when low-probability next words are selected. True explanations, on the other hand, act as attractors in state-space. Once stumbled upon, they are consistently preserved.
So run a bunch of LLM instances in parallel with the same prompt. The built-in randomness & temperature settings will ensure you get many different answers, some quite crazy. Evaluate them in new LLM instances with fresh context. In just 1-2 iterations you will hone in on state-space attractors, which are chains of reasoning well supported by the training set.
What if you use a different AI model? Sometimes just a different seed generates a different result. I notice there is a benefit to seeing and contrasting the different answers. The improvement is gradual, it’s not a binary.
> why did people cover up their beautiful wooden flooring with carpets
For a minute there i thought you were talking about the 70s.
Considering the Greek's love of what modern people consider garishly colored statues, my first instinct would have been that it's for decorative reasons.
Plenty of people I know believe illegal immigrants should be deported. The difference between them and people accused of being a Nazi is they don't go around calling them all rapists and murderers.
The problem isn't the claimed actions they want to take, its the dehumanization being resorted to.
You’re exaggerating greatly, of course. Among those deported are rapists and murderers, naturally, and no one has stated that everyone being deported or even targeted is one (the recent Hyundai bust comes to mind). I challenge you to find that quote.
I'm old enough to recall MSNBC in 2011 cropping video footage of an Obama townhall protestor to only show his long-sleeve shirted back with slung open-carry rifle. They used it to immediately launch into a pundit discussion claiming that the protestors were motivated by racial animus. Turned out the protestor was black.
News manipulating footage to cast aspersions to historical boogeymen is routine. All it takes is one pundit mentioning an imagined similarity to play the edited B-roll.
Any system, program, or social group involving tens of thousands of people is going to have issues. But if you systematize it you can work to address them rather than ignoring them in search of the perfect system (which doesn't exist).
Basically when you read code you're mentally doing the same thing as when you write code. But your mental model is more likely to be wrong when you're reading rather than producing the code.
Cutting corners here is one of the worst decisions you can make. Especially in an environment where you don't know your end product and you're likely to rework your code over and over and over again.
Piling shit on top of shit only pays off on very short time scales - like a month or two. Because once you revisit that shit code all your time savings are out the window. If you have to revisit it more than once you probably slowed yourself down already.
And you can add an AI code agent (Copilot, Opencode, Claude) to the workflow just to deal with failing tests, automatically create PRs to fix the issues. It may boost the productivity a lot doing housekeeping while coding manually.
We call attention to problems with new tech because there's a window of opportunity to fix them before people become too passive to do anything about them because that's how it's always been.
Tv ratings, seatbelts, car seats, and crash safety regulations exist. Also books may give you an idea but they cannot interact with you in real time. Suggesting it is the same is disingenuous.
Fair use isn't about how you access the material, its about what you can do with it after you legally access it. If you don't legally access it, the question of fair use is moot.
Yes. Great recession was its death throes. It would have fallen by now if it wasn't the only economy not damaged by Second World War and as a result economy that put its currency as currency of global trade. Since then it's mostly sustained by selling freshly printed paper and bullying everyone around with IP laws.
With respect to the IP protected under the Constitution of the United States, unquestionably and absolutely. The past 50 years of macroeconomic activity is basically a warning sign that says "your IP is basically worthless" in big red flashing letters. China mass-manufactures ARM chips and turbojet engines using unlicensed stolen schematics - Russia endlessly pirates foreign entertainment with impunity. These are entire nations of people who benefit from American financial assets without paying us a dime for them.
In case you missed it, the other day China showed off their F-35 clone for the PRC military parade. Your constitution can say pigs fly for all George Washington cares, trusting absolutely in IP protection is a game for butthurt chumps.
Look into how the US industrial economy started. It was "stealing IP" from the english and not respecting copyright. Would be interested if there are any cases in history of rising economies respecting IP and succeeding because in every case I know about they flagrantly disregard it while developing
Fundamentally, unit tests are using the same system to write your invariants twice, it just so happens that they're different enough that failure in one tends to reveal a bug in another.
You can't reasonably state this won't be the case with tools built for code review until the failure cases are examined.
Furthermore a simple way to help get around this is by writing code with one product while reviewing the code with another.
reply