Matt Compton

Last week I was talking to an entrepreneur who shared that, prior to AI software development tools getting so good, his team followed the standard two-week product sprint. Every two weeks, they would sit down, map out the features, bug fixes, and roadmap priorities, and then the team would go off and do the work. They would write code, write tests, run everything through their internal processes, and then come back two weeks later to review what went well, what didn’t, where the different initiatives stood, and what should happen in the next sprint. This type of two-week sprint is pretty common in the software development world. Only now, with the advent of amazing tools like OpenAI’s Codex, SpaceX’s Cursor, and Anthropic’s Claude Code, the productivity of software developers has jumped dramatically. So much code is being written, so many tests are being created, so many features are being enhanced, and so many bugs are being solved that the head of product now does a daily stand-up with the head of engineering and the engineering managers every single workday. Before, software engineers had to map things out, work through the code changes, write code, edit code, and test everything themselves. Now, much of that work is actually being done by AI. The software engineers are coaching the AI, providing feedback on what it writes, thinking through its recommendations on architectural changes, reviewing the code it produces, and orchestrating the different agents doing the work. Of course, AI can write code much faster than a human. Software engineering is becoming much more about orchestrating agents than writing syntax in a particular language. As AI coding continues to increase the pace of development, the biggest issue becomes curating what should actually be done. When there are big initiatives underway, this is less of an issue. But when tweaking features and polishing different modules, it becomes easy to run fast and build things that might not be needed, don’t fit the overall vision, or are simply built because they are easy to build. That makes staying close to the customer even more important. Teams need to understand the customer’s needs, how customers work today, and how they want to work in the future. With two-week sprints, there was more time to gather feedback directly from customers, through customer advisory panels, customer success calls, or other channels. Now, if the product is changing on a daily basis, the customer feedback loop and the company’s opinionated vision of the future both have to evolve as well. Ultimately, this all bodes well for startups delivering better products and customers getting more of what they need faster. Entrepreneurs would do well to consider shrinking the cycle time of their sprints from two weeks to one workday, or some similarly short interval. But at the same time, they should dramatically increase the frequency and scalability of customer feedback so the team continues working on the most important things instead of adding more functionality simply because it is easy to do so. We’re in a new age of software development. The startups that adapt best will balance dramatically faster innovation with equally fast customer feedback.