Hacker News new | ask | show | jobs
by Xirdus 18 days ago
The biggest obstacle to huge refactoring has always been minimizing the risk of bugs, not losing any features, and ensuring compatibility with the existing ecosystem. The reason it's become easier in the age of AI is because we stopped caring about these things.
2 comments

Yep. That’s what people are forgetting. If you have an application that many people depend on to do real work, to make money, you won’t survive if you allow AI to constantly make huge changes.

Your test suite doesn’t cover all workflows. It doesn’t cover every combination of actions a user can take. So every big AI refactor while change some of those.

If this is happening frequently, your software will feel like a janky piece of unusable crap.

Actually now we care even more. The reason people didn't write extensive test suites was was because it's super fucking boring to do so.

AIs don't care, they'll happily write 50 unit tests with slight variations and pair them with a full dockerized end to end test suite.

Now we have at least SOME tests. Are they good? Maybe, maybe not - but we have them. If one of them fails later on, we can check if it's an actual issue or the test being bad.

Which is infinitely better than having no tests because nobody can be arsed to write them or the customer isn't paying for the extra hours needed for a proper test suite.

People didn't write tests not because it was boring, but because they didn't have time to do it because implementation is more important. That problem didn't go away - it's just instead of not having time to do tests, now we don't have time to review whether the AI wrote tests that make sense. And most of the time it doesn't. They're running the code but not asserting anything. Or they're asserting test inputs instead of implementation outputs. Or outright swallowing errors to make tests pass.

Having such tests is, in fact, worse than not having tests at all. Non-existent tests are just as useful as bad tests, and are much cheaper to maintain.

Having slop tests instead of no tests is definitely not the same thing as actually caring about avoiding bugs.
This is not about caring. This is about the real world where actual human programmers usually don't want to spend any extra time writing test suites or management doesn't give them the time to do so.

So if the starting point is "no tests", having a bunch of "slop tests" is better, right?