I made a mistake, and this is the question I was asked.
The old one works, why revert this?
Actually this case should be able to check from the test case.
My first production went wrong after it launched. Yes, I have been writing code and doing some tech research projects. But handling production is another story.
With careful crafting and checking through the pipeline, that new branch was designed, discussed, and checked through the whole pipeline. From PM, UX to implementation to QA, with AI code review, PR review, then merged. Then boom.
The path I never checked haunted me and cost me an overtime, stressful weekend. The bug we had already fixed happened again with my new change. All from one path that had never been checked.
After reflecting on myself, I did everything to make sure it would work, and every test case guaranteed that it would. However, the world is not perfect. The AI engine in the pipeline can miss something and hallucinate something.
To prevent this, it's not about how it works. It's about how it's gonna break. Running tests is not just about running the command. It is trying to "break" the program and making sure that even if we try to break it, it still works.
Top comments (0)