When Photify AI was removed from the App Store, our team had about two weeks to preserve one of its core capabilities: AI-powered photo and video generation. The fastest path was to rebuild that functionality for the web inside Botify AI, a product built on a technology stack I had never worked with before. There was little time to learn the stack from scratch, yet the feature still had to meet production standards. Claude Code became an important part of that process. It accelerated my understanding of an unfamiliar codebase, generated working implementations and helped resolve issues that would otherwise have taken much longer to investigate. However, writing code turned out to be the easy part. The real challenge was deciding what the generated code should and shouldn’t become. AI could produce code that compiled, but it couldn’t judge whether it matched the existing system’s architecture, respected established patterns or introduced risks that would surface later in production. E...
A back-end team extracted notification delivery from a large Ruby monolith into a centralized Go service, only to discover that their shared RabbitMQ cluster could not reliably support the new workload. Here’s how they solved the problem using MongoDB as a polling queue and the trade-offs that came with it. The Scaling Problem Inside the Monolith Back in 2019, the engineering team at Wheely, a popular ride-hailing platform, had a coordination problem that emerged with the product. User-facing notifications such as push alerts, SMS confirmations and status updates were scattered around the large Ruby monolith. Various parts of the codebase made direct attempts to send messages without a shared logic, unified retry strategy and consistent way to track delivery outcomes. As the system continued to grow, new back-end microservices were introduced, with each one requiring its own path to the user’s device. Push campaigns made things worse. Sending thousands of notifications at...