If you derive tests from your implementation, you can't apply the Beyonce rule. What if the code is wrong and that wasn't the programmer's intent? We'll never know. The bug now exists in both places.

Swizec's platform provides resources for developers, covering a diverse range of topics such as programming languages, web development frameworks, data visualization techniques, and software engineering best practices. Through tutorials, guides, and coding challenges, Swizec offers hands-on learning experiences and practical insights for developers at all skill levels. Readers can explore  technologies, industry trends, and software development methodologies to enhance their technical proficiency and advance their careers in the tech industry. Additionally, Swizec shares personal anecdotes, career advice, and productivity tips to inspire and motivate aspiring developers on their journey of continuous learning and professional growth.

swizec.com

The post discusses the reasons why using AI to write tests may not be valuable. It explores the benefits of different types of tests, such as unit tests, integration tests, and end-to-end tests. It also presents ideas for using AI in test writing, including fuzzing the app, translating acceptance criteria into tests, and letting AI generate code based on tests.

Why you shouldn't use AI to write your tests

Learned something new? Read more Software Engineering Lessons from Production

Article is wrong on many levels. But to stick with the title, don’t let AI write tests, but let’s let it write production code? Umm. No.
Also, “vertical ownership” is a seriously bad idea. What happens when a bug is found in production and the one guy that knows the code is out of the country with no access?
Finally, as for tests finding bugs before they’re in production… yes, I’ve had it happen myself. And sure, I’ve also had bugs make it to production that could have been caught by “a test” or even “a better test.” But to act like tests never “catch bugs before production” is just naive.