Your Problem Is Not “Pressure to Implement AI”, It’s Lack of Quality

AI is neither a process nor a solution; it is merely a tool. And when a need for AI is expressed, it is necessarily linked to an underlying pain that must be addressed: low productivity, excessive rework, poor reputation, high churn, and low NPS are examples of the real problems that often lead stakeholders to go around “demanding” AI. It is not that AI cannot help — “just” that the real problem lies deeper (and is usually a Quality Assurance problem).

Software development is an engineering activity, and it requires both ingenuity and craft; one of the most complex activities in this profession is mapping the true need of the client/stakeholder (who often even needs support to understand what they themselves want). This also applies to the “pains” or “problems” that we, software engineers, identify when dissecting the requirements of a potential new project. This investigative activity — which bears an important resemblance to one of the pillars of Quality Assurance, root cause analysis — must always be performed.

Therefore, when you hear “we need to implement AI,” ask: why? What is happening in the “real world” that led the stakeholder/client to seek the “silver bullet” of artificial intelligence? Ask about defect densities, about recurring production issues, about missed milestones; challenge the stakeholder on the sizing of their Quality Assurance team, on the risk mapping that justifies functional test coverage (and which they probably do not have). Check whether there is a lack of regulatory, normative, and legal compliance, or simply a lack of persistence of business rules. Very likely, it is in these points that the “true” problem will be found.

Not that, to address these problems, we cannot rely on AI’s support — but that is all it will be: support. To improve defect rates, AI can be used to assist in root cause analysis processes for batches of defects (but first we need to define the root cause analysis process); for recurring production problems, AI can be used to assist in a severity-based defect routing process (but first we need to define the defect management process); for sizing Quality Assurance teams, we can use AI to infer, from historical data, the profile of engineers needed (but first we need to define a structured process for collecting historical data). The solution is process- and domain-knowledge–driven, and AI may (or may not) come in as support.

The “demand” for using AI is a symptom of a problem, not its cause. Projects face the same process challenges they did before 2022; in the past, the “demand” was test automation (which is also nothing more than the use of tools to solve/accelerate processes).

The great challenge is to make senior management aware of the need to separate cause from symptom before jumping to the use of a tool. This requires end-to-end software engineering knowledge: from pre-sales, through proposal shaping, to implementation and project management. It takes firmness and technical robustness not to yield to the “easy” answer that implementing an artificial intelligence tool will solve engineering problems.