AI ships code remarkably fast, and if you set up the right system, you will technically end up with tonnes of pull requests (PRs) awaiting review. With this new capability, you can now build far more features than your customers ever asked for.

So when shipping code becomes this easy, where do you think the bottleneck moves to? Testing. Because of the large volume of PRs, there is every chance you spend very little time actually understanding the code.

One thing we tend to overlook in this era of AI coding is that, when we write code ourselves, we are testing it in our heads as we go. That process forces us to justify why we chose a particular logic or made a given decision. With AI, unless you instruct it to write plenty of comments (which it does very well), you will not know why it made a decision. On top of that, AI output tends to be rather verbose.

It is no surprise, then, that you end up spending a great deal of time on testing nuances and edge cases, and this is exactly where the Quality Assurance (QA) team comes in. In the end, we will all have to up our QA game.

When you ship 100 features your customers never requested, you still have to test every one of them, as one feature might break another core feature customers love dearly, and you do not want that to happen. There is going to be a lot of good-looking software that gets abandoned simply because it has far more features than anyone needs. This then opens up a new approach: allow customers to customise your application to what they need, and hide the features that are not necessary for them right away.

In all of this, you still need to do customer research, understand what your customers actually want, and use AI to drive development. But spend enough time testing, because you do not want your customers blindly relying on AI-generated software.