On my current team, QA files bugs against a story when it finds defects. Those defects have to be corrected before the story can be accepted and merged into the larger codebase. Producing the implementation gets the work to that inspection point. It doesn’t get the work through it.
That distinction matters more as AI reduces the effort required to produce an implementation. If code arrives faster while the capacity to evaluate it stays the same, the unfinished work accumulates somewhere else. You can have a remarkably productive coding agent and a growing queue of software you aren’t ready to accept.
The fundamental problem of software engineering is not producing an implementation. It is establishing sufficient evidence that the implementation is fit for purpose.
By fit for purpose, I mean more than passing the tests we happened to write. The software must solve the intended problem, behave correctly under relevant conditions, and meet the security, reliability, and maintenance needs of the system it joins. The evidence needed for a disposable experiment will differ from the evidence needed for a production data migration. Someone still has to decide what is sufficient.
Construction Already Understands This
I’ve often said that software development resembles construction more closely than other fields. Our vocabulary reflects that affinity: architecture, scaffolding, frameworks, and builds. In Software Development is a Trade, I made the connection through how developers learn, practice, and pass experience to others.
The comparison also helps explain the relationship between completed work and accepted work. King County requires inspections at stages of construction and requires the work to remain visible until inspection is completed and approved. It also warns that inspection demand can prevent a visit from happening on the requested date. Inspection is part of the schedule, with its own capacity and dependencies.
Finishing the framing faster doesn’t automatically make the inspector available sooner. You have improved one part of the delivery system. The next dependent step still has to happen, and the schedule has to account for it.
Inspection supplies evidence. Approval records a decision based on requirements and that evidence. Software has the same distinction whenever test results, review findings, and observed behavior inform a decision to accept a change. A passing check answers a particular question; the acceptance decision concerns the work as a whole.
Construction isn’t a perfect model for software. Software can change its structure and behavior in ways a building cannot. But coordinating specialized work against specifications, inspecting it before dependent work proceeds, and taking responsibility for the result are familiar problems in both fields.
Cheaper Implementation Exposes the Queue
The economic change I’m describing in October 2026 is relative. Implementation doesn’t have to become free. It only has to become cheap enough that producing the next candidate takes much less effort than establishing whether that candidate belongs in the product.
Lower implementation cost makes more features, experiments, alternatives, and revisions worth attempting. More of those implementations reach verification. Each brings behavior, assumptions, dependencies, and interactions that need to be evaluated. When that demand exceeds the capacity to produce and interpret evidence, verification becomes the binding constraint on delivery.
Lower implementation cost → more implementations → more verification demand → verification is exposed as the most constrained resource.
The need to verify was already there. Implementation effort previously limited how much work reached it. Relieving that upstream bottleneck exposes the next limitation. This is the mechanism to look for in your workflow, not a conclusion that every software team now has the same bottleneck.
AI is not making verification the constraint; it is making the constraint impossible to ignore.
You can see the practical consequence in a proof of concept. A demonstration establishes that something works under the conditions of that demonstration. It leaves open questions about permissions, recovery, integrations, load, and the customer’s actual workflow. As I argued in Vibe Shipping Is the Real Problem, the boundary between a prototype and production needs an explicit decision.
A faster demonstration can make the project look nearly finished while those questions remain unanswered. Answering them can require redesign as well as testing. The visible implementation is an unreliable measure of how much engineering remains.
Manufacturing Invested in the Inspection Line
Manufacturing provides another useful example. Cognex’s machine-vision documentation describes systems that detect a passing part, acquire an image, analyze it, and communicate a result. That result can drive an actuator that rejects or sorts the part. The inspection is connected to what happens next.
For software, the corresponding design question is whether a failed check merely produces a report or actually prevents the affected change from advancing.
Our QA process illustrates that distinction. The bug recorded against the story creates work that must be completed before acceptance and merge. Finding the defect and controlling its progress through the system are separate responsibilities, and the process connects them.
A final inspection can tell a steelmaker which material to reject. In January 1994, NIST described research into measuring the steel continuously during manufacture. The goal was to spot a problem while operators could still adjust the process, before they produced more steel with the same defect.
Timing changes the cost of a software defect, too. Suppose a change writes the wrong value to a customer record. If QA catches it before merge, we can fix the code and verify the correction within the story. If customers have already used it, that same code fix leaves us with another job: find the affected records, repair the data, and help customers recover any work that depended on it.
Repeated manufacturing inspection often checks instances of an established design. Software changes can alter the design itself, including the assumptions behind the checks. The transferable lesson is to design production, inspection, feedback, and acceptance together. Software already has tests, static analysis, continuous integration, and release gates. Cheaper generation makes the capacity and effectiveness of those practices harder to neglect.
Prevention and Evidence Do Different Jobs
This is how my work on modular instructions and code scorecards fits together. They address different parts of the same problem.
Modular instructions are prescriptive and preventive. They give a developer or agent the relevant architecture, coding conventions, and workflow expectations before implementation begins. An API task loads the API guidance; data access work loads the relevant conventions. The purpose is to reduce avoidable mistakes and inconsistent decisions before they become review work. I described that approach in Your AI Code Quality Problem Is Actually a Standards Problem.
The code scorecard is diagnostic and evidentiary. It examines the resulting code against explicit criteria and directs attention to properties that need investigation or improvement. Instructions explain what to do. The scorecard provides evidence about what was produced.
Neither replaces the other. Having an instruction file doesn’t establish that the implementation followed it. A favorable score doesn’t establish that the application solves the right problem. Stop Reading AI Code. Score It. makes that boundary explicit: measurements of code structure and evidence of intended behavior answer different questions.
I use the same approach before anyone writes code. In my requirements pipeline, Story Writer asks the product owner who will use the feature, what they need to do, and what they should see afterward. Story Prefinement reviews the resulting story before the team meets. If a story says “show an error for an invalid email address” but leaves open whether the user can still save it, that’s a decision the product owner can make while the cost of a correction is an edit to the story.
During refinement, QA can turn that decision into a test. If an invalid email address should block a save, the test checks both the error the user sees and whether the stored address stays unchanged. Compilers, analyzers, and architecture tests catch other known mistakes as the code takes shape. When QA keeps finding the same defect, use that finding to improve the instructions or add an earlier check. I describe QA’s role in that feedback loop in QA Belongs in the Loop.
Verification Can Keep Pace
I believe verification can improve as quickly as generation when it is set up correctly. A constraint identifies where the system needs attention. We can increase that capacity, reduce unnecessary demand on it, and eventually expose a different constraint. There is no reason to treat today’s inspection queue as a permanent ceiling.
UI-based verification is the most challenging part in my assessment, but tools such as Playwright enable automated browser interactions and checks on their results. Playwright’s guidance emphasizes user-visible behavior. Its assertions can check displayed text, input values, element visibility, URLs, and other observable outcomes.
The hard dependency is an excellent specification. The tool can perform an interaction. The specification establishes what the interaction is supposed to accomplish, under which conditions, and what must happen when it fails.
Consider a hypothetical customer-profile form. “The user can save changes” doesn’t provide enough information to verify the feature. A more useful specification would include:
| Condition | Required behavior |
|---|---|
| A user with edit permission saves valid changes | Show confirmation only after a successful save; the saved values remain after a reload. |
| A required field is missing | Identify the field, retain the other entered values, and leave the stored record unchanged. |
| A user without edit permission attempts an update | Deny the update and leave the stored record unchanged, including when the request bypasses the UI. |
| The save service fails | Show a failure message, preserve the entered values for correction or retry, and do not display success. |
Those requirements tell us what to inspect. Browser automation can exercise the user flow. Service and data checks can establish what was persisted and whether the permission boundary held. A green message on the screen alone doesn’t demonstrate either of those things.
An agent can help create the implementation and the tests, but both can inherit the same mistaken assumption. The expected behavior needs to come from requirements reviewed against the actual business need. Tests that reproduce the implementation’s behavior without questioning it can confirm the same mistake twice.
This is why specification work matters economically. Clear requirements make it possible to automate meaningful verification and reuse it as the system changes. Ambiguity forces someone to reconstruct intent, investigate inconsistent expectations, and redo work. Faster test execution cannot recover a requirement nobody defined.
Verify the Verification Process
Anthropic’s October 15, 2026 article, How the Claude Code team does code review, provides a current example. The team describes automated checks, review effort matched to risk, and recurring findings fed back into instructions. It also tests its reviewer against past incidents. These are investments in verification capacity as implementation volume grows.
The team reports that merged pull requests more than doubled from June to September while the proportion reverted fell by more than 40 percent. That is encouraging evidence about throughput and reverts. It leaves an important question unanswered: what happened to defects experienced by users?
A defect can remain in the product without triggering a revert or a formal incident. A falling revert percentage can also coexist with more reverted changes when the total number of changes rises. Neither measure, by itself, tells you how often a customer workflow fails or how long the customer waits for a correction.
I checked the public Claude Code issue tracker for the same four months. I could count reports labeled as bugs and read the recorded reasons for closure. From those labels and closure reasons alone, I couldn’t tell how many distinct defects users encountered or how many had been fixed. To verify a fix, I’d want to see the failing case work in the corrected version.
The same discipline applies to your own process. Track confirmed defects that escape, their severity, and time to correction alongside review effort and waiting time. Account for changes in usage and release volume. A faster review process is valuable when it reduces the total cost of reaching and maintaining acceptable behavior, including the correction work that reaches users.
This extends the specification question. Define what successful verification means, then evaluate the process against that outcome. Otherwise, you can make the inspection line faster without establishing that it catches the failures that matter.
Develop the Judgment That Verification Needs
As implementation gets cheaper, developer value shifts toward problem definition, constraints, architecture, verification design, failure interpretation, and accountability. These responsibilities determine whether increased implementation capacity produces useful results. Technical knowledge remains essential because it helps you recognize where apparently correct behavior can conceal a broken system.
This also explains why the tool that produced the code is such an incomplete basis for judging it. In his October 13, 2026 Linux mailing-list response, Linus Torvalds rejected the idea that using an easier tool demonstrates a lack of understanding. He still expected contributors to understand what they were doing. My extension is straightforward: choose useful tools, then take responsibility for the resulting software. Tool provenance alone cannot establish fitness for purpose.
Architecture training belongs here. Developers need to understand how boundaries affect what can be verified independently, how dependencies expand the impact of a change, and which failures a design makes difficult to observe. A useful exercise is to compare two plausible implementations, explain their assumptions, and design checks that would distinguish their fitness for the actual problem.
The management question follows from that: where is completed implementation waiting for acceptance, and why? Look at time spent interpreting requirements, correcting recurring defects, preparing test data, running checks, and investigating failures. Separate time spent working from time spent waiting. Compare the cost of verification with implementation effort, and watch whether defects still escape into production.
Then improve the part that is actually limiting delivery. Sometimes that means more automated coverage. Sometimes it means a reliable test environment, a clearer specification, or an architectural change that makes a behavior easier to inspect. Sometimes it means declining to start another implementation until the existing work is accepted.
Before you add another coding agent, pick one story waiting for acceptance. What’s holding it up? If nobody has checked whether a saved change survives a reload, run that check and make it repeatable. If the evidence is already in hand and the story is waiting for signoff, find out who can accept it and when they can review it.
Receipts
- Current team practice: QA files bugs against stories, and defects must be corrected before story acceptance and merge. This is my team’s process, not a measured comparison of verification throughput across organizations.
- Construction inspection: King County documents staged inspections, visibility of work until approval, and scheduling limits based on inspection demand. Building and fire inspections.
- Automated inspection and rejection: Cognex documents triggered image analysis and optional actuators for rejecting or sorting parts. In-Sight documentation.
- Earlier process feedback: NIST’s January 10, 1994 account describes research into continuous steel-property measurement and process control. These were program objectives, not results measured in this essay. NIST steelmaking program.
- Tool choice and understanding: Torvalds’s October 13, 2026 response separates tool use from competence while retaining the expectation that contributors understand their work. Linux mailing-list response.
- Browser verification: Playwright documents user-visible behavior testing and assertions on observable outcomes. Best practices and assertions.
- Review process and reported results: How the Claude Code team does code review, October 15, 2026, by Addy Osmani, Morgan Westlee Lunt, and Qing Wang. Read October 28, 2026. The results are the team’s report, not an independent evaluation of customer outcomes or proof of causation.
- Public defect reports: The Claude Code issue tracker informed my questions about escaped defects. The October 27 investigation examined bug-labeled reports and closures for June through September 2026. Labels and closure states can change; neither a bug label nor a completed closure establishes a verified defect or repair. No confirmed defect rate or fix rate is asserted here.
- Economic interpretation: The cost inversion is my argument about what happens when implementation capacity outpaces verification capacity. The industrial examples establish mechanisms and precedents. They do not establish a universal cost ratio or show that every software team has reached that point. My position is that well-designed verification can keep pace.