I spent this summer building computer vision-models after years of shipping mobile, web, and desktop apps. The speed gap was stark and I wanted to unpack the development speed difference in SWE and ML, and what it could mean for the future of computing.
Traditional software runs on a predictable cycle where features can be planned, estimated, and delivered within established timeframes. One major aspect of this is that the turnaround time is fast. You can edit an Android Jetpack Compose view and see it hot reload within 5 seconds most of the time and can edit and push database schemas to production within a few days.
Before ML, I assumed that this was the same for building models, but I realized the inherent experimental and unpredictable nature makes this not the case. Before building a modest model, you have to spend weeks getting data and cleaning before training it. Feature/model work and testing also take time. A slight change could take days to investigate, leading to a high turnaround time.
Several areas show promise for reducing ML development cycles, and builders have stepped up to handle this: automated data pipeline tools that handle cleaning and feature engineering, experiment orchestrators that parallelize hyperparameter searches, and cloud-native ML platforms that eliminate environment setup overhead. Companies like Weights & Biases are already building infrastructure to make model iteration faster, while Cursor and Warp are building tools to make code iteration faster.
Another improvement vector is reducing feedback loop through better simulation and synthetic data generation. Instead of waiting weeks for real-world data collection, teams could train on high-quality synthetic datasets that capture the essential patterns. Advanced techniques like differentiable programming and neural architecture search could also automate much of the manual model design process.
The most transformative approach might be treating ML development more like traditional software - with standardized libraries, reusable components, and established design patterns. Just as web developers don't rebuild HTTP protocols from scratch, ML builders shouldn't re-invent preprocessing each project. I know we already have some of this in place but I believe more work can be done. Rather than relying on faster hardware, we need a fundamental reimagining of ML development workflows. Doing so will free up more cognitive space that can be applied towards generating new ideas. The companies and teams that solve this infrastructure challenge will have a massive competitive advantage in building AI-powered products.
(I understand I simplified the two roles, quite a bit, but the point still stands)