|
The feature? Distinguishing between a PiP video close vs. pause in my timer app on iPhone. We had a random 250ms delay to differentiate the two, and removing it broke some behavior. Except the delay wasn't necessary, and the feature was fine before the agents touched it. This kept happening over the last 7 days while I was at the beach. Agents would fix one bug and break something else. Agents can write code quickly, but they easily break working features. This gets worse with less popular Apple APIs, where there's less sample code and agents have a weaker understanding. Even if you have tons of unit or UI tests, agents can still cause problem. You need to protect your working code from your agents. Here are 5 tactics that have helped me. #1 Focus For less common APIs or languages, go slower. This week I delegated too many tasks at once and ended up with broken, non-functional code I couldn't merge. Each time I tested the features with TestFlight builds, there were either unrelated bugs or the feature didn't actually work. It was frustrating, because now I had so many new fires. You can feel like you're making more progress, but when the agents start breaking unrelated features, it makes managing multiple agents a nightmare. Use one thread, fully define the task using plan mode, Grill with Docs, or BMAD. #2 Documentation Remember the agent that said my feature was impossible? The next day, I had agents do documentation research before touching code. THe new agent realized it was a bug the agents introduced, not the documented API. Any time agents use their own knowledge and hallucinate how something works, you end up with spaghetti code that doesn't work right, or is brittle. #3 E2E Tests Agents will happily create unit and UI tests. That's great for coverage numbers, but many times these tests are very focused and lack end-to-end (E2E) testing. The test will work great with the mocks, but the lack of understanding at the API level leaves you with broken app logic. I had PiP (Picture-in-Picture) unit and UI tests, and they still don't properly cover the behavior, mainly because PiP only works on the iPad Simulator, not iPhone. It's very easy for agents to break this feature, and I've had to fix it 3+ times at this point. #4 Centralize Logic Ask an agent to add another button and it'll gladly create a new function to power that button. The problem with that is it creates multiple places that all do similar work. So you might fix a bug for the "Reset" button, but there are three other entry points (keyboard shortcut, menu item, and after onboarding). Make sure your business logic lives in one spot, and that agents have docs that guide them where to look, so they don't create brittle entry points that make bug fixes whack-a-mole. #5 Be Careful with Code Review Agents My bug fix for play/pause in PiP mode turned into a 77 file PR, which I still don't fully understand. Lots of unrelated code changes (multiple days at this point). It's working, and there are lots of new tests, but I don't have time to review all of the changes on vacation. One small fix exploded in complexity. Agents will easily work on unrelated things, or think they're fixing or cleaning up something else without enough focus. Be more articulate with Sol 5.6, because it seems to have a tendency to try to fix everything, yet it will break other features in the process. This is where regression testing is important. Try it on TestFlight Grab the latest TestFlight beta of Super Easy Timer on iPhone or Mac. We're just getting home, so I'll have a new beta this week with Dynamic Island and Live Activities. Talk soon, P.S. If your agents keep breaking your app and you want a second set of eyes on your workflow, I do 1:1 App Strategy Sessions. We'll look at your app and figure out where you should focus. Book a session here.
|