The code compiled The tests passed The PR was green So I merged it.
Days later I was looking at something completely unrelated when I noticed it: ...
For further actions, you may consider blocking this person and/or reporting abuse
Nothing in that diff would have shown it, so a more careful reviewer would have missed it too. The bugs that cost me live in the use case nobody scoped or the scale the thing falls over at, and neither is in the lines you are reading.
Better questions at review time still only cover the scope you already have. The ones I find, I find by running the thing somewhere it was not designed for.
Thanks Aliaksei this is a really good distinction. A careful diff review can still miss a problem when the failure lives outside the code's intended scope. I especially like the idea of running it somewhere it wasn't designed for that can expose assumptions that neither the tests nor the review ever made explicit.
Great that you didn't just signal the problem, but also added actionable advice!
Tests remain a great (essential, even) tool, but the challenge has always been in answering the question what to test ...
Thanks Lob Exactly I think what to test is often where the real engineering judgment lives. AI can help generate tests, but if we give it the wrong target, it can give us a very complete answer to the wrong question. That’s why I like using AI to challenge my assumptions, not define them.
This:
"That’s why I like using AI to challenge my assumptions, not define them"
That seems a great approach/attitude ...
Thanks Leob That’s exactly the mindset I’m trying to build around AI-assisted development use it to pressure-test the reasoning, not outsource the reasoning.
One thought on the status and permissions example: if those two fields can only change through a single transition function, the AI can't update one without the other, and no test has to remember they're linked. Pushing the invariant into the data model seems cheaper than hoping every reviewer spots it.
That's a great point. Making the invariant structural is much stronger than relying on every caller, test, or reviewer to remember it. If two fields must always move together, the data model or transition API should make the invalid state hard to represent in the first place.
the 'tests verify behavior you thought to check' framing is the exact gap. the dangerous pattern i keep seeing is AI code that threads correctly through your existing tests because it was trained to produce code that looks like code that would pass — it's not gaming the tests, it's just good at reading the test patterns and satisfying them.
the cross state invariant case is the one we burned ourselves on too. function was correct, neighboring state update was missing, every test was green because we'd never written the invariant as an assertion. only a full integration trace caught it.
do you run property based testing to surface invariants you never thought to assert explicitly?
That’s a great distinction I like the not gaming the tests, just satisfying the patterns they encode framing. And yes property-based testing is something I’ve found useful for this exact problem especially when the invariant is easier to describe as a property than a list of examples. I still think the hard part is discovering the right property in the first place. That’s where I’d want AI to help me generate counterexamples and challenge the invariant, rather than decide what the invariant should be.
The better results is in the better understanding of the problem. I couldn't help but react. Even the best programmers make mistakes but being able to "reevaluate" when you think everything is perfect is priceless 🙌
Thanks Ekong Absolutely Re-evaluate is the part that’s easy to skip when everything looks green. Even when the code, tests, and review all look right, stepping back and questioning the original assumption can reveal what the checks never covered.
Bro exactly seeing all tests passed gives you way too much confidence… and that’s sometimes where the problem starts.