Why engineering judgement—not just technical correctness—is becoming the defining factor in software quality.
AI has fundamentally changed how we build software. We can generate code faster, automate testing, identify defects and produce working functionality in a fraction of the time previously required.
But there is a question that I believe deserves far more attention:
Just because we can build something correctly, does that mean we should build it at all?
This distinction is becoming increasingly important as AI takes on more of the technical execution involved in software engineering.
We are becoming exceptionally good at producing code. What we must not lose is our ability to determine whether that code represents the right solution.
1. Code Quality Is Not the Same as Product Quality
Consider a feature that has been implemented beautifully.
The code is clean, efficient, maintainable and secure. Unit tests pass. Integration tests pass. The implementation meets the documented requirements.
From a technical perspective, everything looks excellent.
But what if the feature introduces unnecessary complexity? What if users don't need it? What if it solves a problem that was misunderstood in the first place?
The implementation may be technically correct while the product decision is fundamentally wrong.
This is where engineering judgement becomes essential.
Quality cannot be measured solely by the absence of defects. It must also consider whether the functionality is appropriate, valuable and aligned with the product's intended purpose.
A perfectly implemented feature can still be a poor-quality product decision.
2. Functional Correctness Depends on Context
Traditional software testing often begins with a relatively straightforward question:
Does the system behave according to its requirements?
That question remains important. But it assumes that the requirements themselves are correct.
AI can generate code that satisfies a specification. It can also generate tests that confirm the implementation behaves according to that same specification.
The problem is that both may share the same incorrect assumption.
An experienced engineer, tester or product specialist can challenge the premise.
- Is this the behaviour the user actually needs?
- Does it make sense within the wider product?
- What happens when this functionality interacts with existing features?
- Are we introducing complexity or risk that outweighs its benefits?
- Is there a simpler or more appropriate solution?
These are not merely coding questions. They require an understanding of the product, its users, its operating environment and its constraints.
Functional correctness is not simply about doing something right. It is about doing the right thing in the right context.
3. Quality Is a Series of Decisions
I have always viewed software quality as something broader than testing.
Testing provides evidence. Quality depends on the decisions made throughout the product lifecycle.
Those decisions influence different dimensions of quality.
DecisionQuality impactWhat should we build?Relevance, usefulness and product valueHow should it behave?Functional suitability and usabilityWhat should we avoid building?Simplicity, maintainability and risk reductionHow should it be implemented?Reliability, security and technical sustainabilityHow much testing is enough?Confidence, risk exposure and release readinessWhen should we release?Operational safety, business value and customer impact
These decisions are connected.
A technically excellent implementation of an unnecessary feature still consumes resources, increases the maintenance burden and potentially introduces new failure points.
Sometimes the highest-quality engineering decision is to remove functionality, simplify a workflow or decide not to build something at all.
4. AI Makes Experience More Valuable, Not Less
There is a growing assumption that as AI becomes better at writing code, the need for experienced engineers will diminish.
I think that overlooks an important distinction.
The ability to produce code is only one component of engineering expertise.
Experienced professionals recognise patterns, understand consequences, challenge assumptions and identify problems that are not immediately visible in a specification.
They know when a technically possible solution is inappropriate.
They understand when a requirement conflicts with an established product behaviour.
They can distinguish between a defect that matters and an imperfection that has little practical consequence.
Most importantly, they can give AI meaningful direction.
An experienced engineer using AI effectively is not simply asking it to produce code.
They are defining the problem, establishing constraints, evaluating alternatives and determining what an acceptable outcome looks like.
AI may accelerate the execution, but engineering judgement establishes the direction.
5. How Do We Determine What Is Important?
This is perhaps the most significant question in modern quality engineering.
Not every defect matters equally. Not every feature delivers meaningful value. Not every technical improvement justifies its cost.
Determining importance requires evaluating several factors together.
User impact: Does the functionality solve a genuine problem? Does it improve the user's experience or create unnecessary friction?
Business value: Does it support the organisation's objectives, or is it functionality being developed simply because it is technically achievable?
Risk: What happens if the feature behaves incorrectly? Could it compromise security, privacy, reliability or user trust?
Product coherence: Does the functionality belong within the product? Is it consistent with existing workflows, expectations and design principles?
Cost of complexity: What additional maintenance, dependencies and operational responsibilities does it introduce?
Evidence: What do research, user behaviour, testing results and production observations tell us about its actual value?
The importance of each factor changes with context.
A minor visual inconsistency in an internal application may have little consequence. The same inconsistency in a safety-critical workflow could create confusion with serious implications.
Quality is therefore not a fixed checklist. It is a contextual judgement informed by evidence.
6. The New Quality Bottleneck Is Judgement
As AI accelerates code generation, organisations may find themselves producing functionality faster than they can meaningfully evaluate it.
More code means more decisions, more dependencies and potentially more risk.
The bottleneck shifts from producing an implementation to understanding and validating its consequences.
This changes the questions quality professionals need to ask.
Instead of focusing exclusively on whether the code works, we must also ask whether the functionality is necessary, whether its behaviour is appropriate and whether the evidence is sufficient to justify releasing it.
AI can assist with all these activities. It can analyse alternatives, identify inconsistencies and support risk assessment.
But AI-generated assessments still require scrutiny. They are not independent proof that the original assumptions were correct.
7. Engineering Judgement Must Be Deliberate
Human expertise should not become an informal approval step at the end of an AI-generated development process.
It needs to be embedded throughout delivery.
That means establishing product intent before implementation, defining meaningful acceptance criteria, challenging unnecessary complexity, applying risk-based testing and reviewing outcomes against actual user and business needs.
It also means recognising that seniority alone does not guarantee good judgement. Effective judgement depends on experience, domain understanding, evidence, constructive challenge and accountability.
The goal is not to have humans review every line of AI-generated code manually.
The goal is to ensure that consequential decisions receive the right level of scrutiny.
Final Thought: Quality Begins Before the Code
AI is changing how software is produced, and that creates enormous opportunities.
But speed is not the same as value. Technical correctness is not the same as functional appropriateness. And passing tests is not the same as demonstrating that a product meets a genuine need.
The future of quality engineering is not simply about testing more code, faster.
It is about becoming better at determining what matters.
AI can help us build almost anything. Engineering judgement helps us decide what is worth building.
And increasingly, that distinction is where real software quality begins.
Unicorn Inspira | Strategy Meets Quality
Perspectives on product strategy, engineering judgement, quality governance and AI-enabled delivery.