Digital product quality is a differentiator. That belief guides how I approach development, whether I am examining a product, challenging a testing strategy, or deciding how much work to give an agent. Working with newer state-of-the-art models has made those decisions more interesting. With suitable tools, context, and instructions, an agent can take on substantial implementation and unit-test work, investigate failures, and propose ways forward. I can spend more of my attention on the direction of the work and the evidence behind it. But the familiar problems of software development are still there: unclear priorities, needless duplication, assumptions that survive unchallenged, and effort spent improving something that was misunderstood in the first place. My experience as a quality specialist helps me recognize those patterns. Increasingly, I want to use that experience to improve the workflow through which the agent produces its work, including the moments when I step in to question it.
Quality Is a Product Decision
In Rethinking Pyramids, I questioned how familiar testing models direct attention towards different kinds of value, cost, and risk. Agentic development gives me another reason to revisit that question. A request to improve quality can easily become a request for more tests or a higher coverage figure, even though the things people value about a product are much wider. They need to find the right information, understand their choices, complete their tasks, and trust what happens afterwards. Usability, accessibility, reliability, performance, security, and maintainability describe different parts of that experience and the conditions that sustain it. Their importance depends on the product and its users. Quality has to mean something to the person using the product. Before asking an agent to optimize anything, I want to understand which of those qualities matter here, what currently gets in the way, and how an improvement would become visible.
Consider an agent asked to simplify a workflow. Removing controls and reducing the number of steps may produce a cleaner interface, yet one of those steps might have helped someone understand an important decision. A familiar design pattern can improve consistency while obscuring a distinction that matters in this particular product. I want to understand what the proposed improvement preserves and what it quietly removes. A technically sound change can still weaken the product. I want the agent to explain the tradeoff, expose the assumptions behind its recommendation, and help me examine alternatives. Product character and established ways of working deserve consideration, but they also need to serve the people using the software. A preferred style or an elegant implementation is a poor reason to make a task harder, create discomfort, or exclude someone.
That makes defining quality part of product direction. Different expectations can pull a decision in different directions, and somebody needs to decide which constraints are essential and where an experiment is acceptable. My role is to make those choices clear enough to guide implementation and meaningful enough to review. A requirement for performance needs a relevant workload and an acceptable result. An accessibility expectation needs to survive the actual interaction, including ways of using the product that a convenient demonstration may leave out. Maintainability includes the effort required to understand and safely change the system later. An agent can help investigate all of these concerns, but an open-ended instruction to make things better leaves too much of the decision implicit. I get a more useful collaboration when the intended outcome, the important risks, and the boundaries of the change are available from the beginning.
Every Check Has a Cost
Once those expectations are clearer, I can ask what evidence would help me assess them. This is where I often recognize testing antipatterns, particularly needless duplication. It is tempting to run the same broad suite in every available environment or to protect the same implementation detail at several levels simply because generating the checks is easy. Each addition still creates something that has to be maintained, interpreted, and investigated when it fails. Every extra check should answer a useful question. A focused unit test can provide fast evidence about a stable rule, while a broader journey may be necessary to understand an integration or a user-facing failure. The value comes from what the check can reveal and the decision it supports. This is part of the cost of poor digital quality: friction in development and maintenance affects how much useful work remains possible over the life of a product.
Generating tests also requires scrutiny of where their expectations came from. An agent can inspect an implementation and produce tests that accurately describe its current behavior. Those tests may protect useful behavior, or they may preserve an assumption that should have been challenged. I want to know what would make the test fail, why that failure would matter, and how the expected result relates to the intended product. Agreement between generated code and generated tests gives me limited confidence if both inherited the same misunderstanding. A testing mindset helps turn that agreement into a question that can be investigated. It brings requirements, user expectations, known failures, and different ways of using the system into the discussion. This gives an agent something more valuable to work with than a target number of tests, and it gives me a clearer basis for trusting the work it produces.
The conditions under which a check runs deserve the same attention. A successful result against the wrong build says little about the change being reviewed. A local environment may leave out an important part of the deployed behavior. Conversely, an environment failure can prevent a check from reaching the behavior it was supposed to examine. When a failure appears, I want to establish what was actually exercised before deciding what to fix. The useful response may be a product change, a correction to the test's expectation, or a repair to the conditions under which it runs. An agent can help follow that evidence through the surrounding system, provided the workflow preserves the original failure and the identity of what was tested. Treating a passing retry as if the earlier failure had never happened would lose information I need for the decision.
Measurements bring another version of the same problem. A perfect score can be an attractive target, yet reaching it may require additional complexity or repeated runs that contribute little to the experience of using the product. Perfect scores still need judgment. If I ask an agent to keep improving until everything is perfect, I have given it a reason to continue. I need to define success and an acceptable amount of effort for the task. Some requirements must remain firm, and an inconvenient failure is not a reason to quietly lower an agreed standard. Where there is room for tradeoff, the decision should be explicit and the evidence should remain visible. That includes understanding measurement variation before attributing every lower result to the product or dismissing it as environmental noise. Choosing enough evidence requires the same care as choosing more evidence; it is a decision about risk and value, with consequences for the development experience as well as the product.
Bring Judgment Into the Loop
The way I give an agent context is part of this quality work. An immediate prompt describes the task, while product decisions, repository guidance, and reusable skills can carry expectations that apply across several iterations. A testing-oriented skill, for example, can ask the agent to identify the claim being tested, look for evidence that would contradict it, and question whether another check is worth its cost. I have found that kind of guidance useful when giving newer models room to handle implementation work. As I see an agent follow the intended constraints and raise relevant questions, I become more comfortable leaving code and unit tests to it without interrupting every step. That confidence comes from the behavior I can observe. A skill file being present is only a starting point; I still need to assess how the instructions, available context, tools, and model combine in the actual work.
When something goes wrong, I want the correction to improve the conditions for the next iteration. Sometimes that means adding a focused regression check. Sometimes the more useful change is to clarify a requirement, correct misleading context, or make a missing constraint explicit. A safeguard that verifies the version being tested can prevent a whole set of misleading results, while a narrow instruction can help the agent recognize when it needs a product decision before proceeding. A useful correction should outlive the conversation. That does not mean turning every observation into another permanent rule. Instructions and checks also accumulate maintenance cost, and guidance that was useful under one set of conditions can become unnecessary or misleading later. I want the workflow to retain the learning while keeping the resulting machinery open to review, especially as models, tools, and the product change.
This leads me to a working state I want to make more explicit in agentic development: good enough for review.
For an early interface change, it could mean a working candidate that makes the direction inspectable, has the relevant quick checks behind it, and identifies the questions that still need judgment. For a behavior change, the useful review point might be a small implementation with evidence about the important contract and its unresolved edges. The purpose is to bring a concrete result into the conversation while there is still room to shape it. Release readiness remains a separate decision, with the required validation and authorization. Some changes need substantial evidence before even that early review, particularly when an experiment could affect real data or have consequences that are difficult to reverse. The point is to choose the review moment deliberately, according to what the next decision needs.
I would pair that review point with an explicit limit on the effort available for the loop. The agent should understand which outcome it is pursuing, when to return with a reviewable candidate, and what to preserve if the limit is reached with questions still open. The budget belongs to the whole loop, including retries, rather than silently starting again after each conversation. Within those boundaries, I want an exchange in which the agent can explain its recommendation, challenge a priority I have set, and suggest an alternative I had not considered. Discussion is one of the places where innovation happens. A shorter loop can create more opportunities for that exchange before implementation effort accumulates around a weak interpretation. My aim is to have conversations that change the next decision for the better, while allowing the agent enough room to carry out the work it already understands.
Saara Laakko's From Tests to Feedback Loops: QA in the AI Era describes how observations from product behavior can return to development as useful learning. I want to apply that same scrutiny to the workflow doing the development. Earlier review is a direction I want to explore, so I would assess whether it leads to useful alternatives, earlier clarification, and less avoidable rework while maintaining the required quality. The number of conversations or the speed of the first output would tell only part of that story. A workflow change should earn its place through what it improves, and remain open to correction when the result differs from the expectation. This is where I see a practical role for digital quality expertise as agent capability grows: shaping the intent, the evidence, and the feedback that guide the work. The next iteration should inherit better decisions. The value of those decisions should ultimately be visible in the product and the experience of the people using it.