I started building an engineering quality harness because I wanted real evidence about the quality of AI-written code. A working-looking app and a confident explanation leave a lot unanswered. I wanted a way to check the software itself.
The harness grew from there. Bug detection. Mapping features and screens. Tracking how many clicks it takes to get somewhere. That last part interests me because it gets closer to what someone actually does with an app. A feature can exist and still be a pain to reach.
Eventually I had to question how much complexity I was adding around the work of shipping. The harness was becoming another project to maintain. Each addition had a reason behind it, but I still needed to look at what all of those additions cost together.
I want useful, ordinary tests. If I change something, I want checks that cover the behavior I touched and the parts it could reasonably affect. A small hotfix needs a path that fits the change. A larger release needs broader checks. I want that difference to be clear enough that I can use it while building.
I also want one canonical repository, with branches and commits that make it clear which version of the code is being tested. Keeping extra copies and recovery builds around can make that answer harder to follow. I want to be able to get back to a known commit and understand how the current work got there.
Test counts give me very little to go on by themselves. I care about evidence that a person can move through the app and finish the job they came to do. That means looking at the screens, the clicks between them, and the result at the end. I want those journeys to guide what I test.
I’m still sorting out which parts of the harness are worth keeping. Bug detection and seeing the path through an app are useful. I don’t need every useful idea to become another release requirement.