What Changed
Let’s explore what changed, and what didn’t, before we get into how to adapt to the changes.
To Do What?
When I started my career in the 90's, anything we asked technology to do had to be very specifically defined. The methods of defining it evolved over time, from waterfall requirements to Agile frameworks or some hybrid, but the outcome was the same: computers required specific instructions, so the business had to eventually define exactly what should happen.
Getting those requirements right was critical and hard to do. Failing to do so was the root cause of many disappointments and real tension between the business and IT sides of organizations.
The move to Agile changed both the method and the emphasis. The focus shifted from up front development of detailed technical requirements to using iterations of working software to help discover what the functional requirements truly were.
This eliminated the need for lengthy requirements at the beginning, but doing it right still required clarity about the desired outcomes: defining the business results to be accomplished and how they'd be measured, then iteratively developing software to achieve part of those results.
With generative AI, the principles that drove the shift toward Agile apply more than ever. Agile works well when building a prototype and then changing it is fast compared to debating detailed requirements up front, and generative AI makes that kind of rapid prototyping faster still.
Doing it well, though, still requires clarity about the desired business outcomes. What really changes is the breadth of potential use cases. We're no longer limited to those that can be defined in completely deterministic code. This opens the door to automating processes that were too complicated to be realistic candidates before.
How Well?
Because the only processes that could be automated in the past were ones that could be precisely defined, the final product was expected to be executed with very high reliability. Targets were often six-sigma or better: three defects per million or getting it right 99.9997% of the time. Everything that couldn't be defined so carefully remained a manual process.
Now that we can automate processes that would have otherwise stayed manual, we need to think about quality differently. If a manual process is done right 80% of the time, an AI-enabled solution getting it right 95% of the time is a huge improvement, even while falling short of the reliability we expect from traditional automation.
It's therefore critical that the "How well?" measurements applied to an AI solution be the same ones used to judge the manual process it replaces. In some cases, AI even enables quality metrics that didn't exist before. When it does, apply the new metric to both the AI solution and the manual process.
For example, few lenders today comprehensively measure how well their agents read the attachments borrowers submit in credit bureau disputes. AI may let a lender identify that information with far greater consistency than a manual process and measure the difference. Relevant accuracy of metrics will therefore mix percentages, which we're used to doing for technology, and percentiles, which we historically haven't used much.
Imagine a process where the AI solution is right 87% of the time, but that performance sits in the 97th percentile compared to manual work. Being right 87% of the time would have been unacceptable in prior use cases, but if the process is challenging enough that this beats 97% of manual results, it's a major upgrade.
Knowing both numbers matters: leadership can be confident that average quality will improve, while the combination also reveals opportunities to route certain characteristics for manual review and to keep pushing that 87% higher.
