We call the testing team “QA”, then ask them to check everything after we’ve built it. That job title is doing quite a lot of work. Quality control checks whether the result meets the requirements. Run the test, inspect the output, find the deviation, correct it. It gives us feedback about what we actually built. Quality assurance asks whether the way we work gives us good reasons to expect those requirements will be met. Are they clear? Have we considered the failure modes? Have we planned checks that would actually expose them? Take a payment retry. A test finds that retrying after a timeout charges the customer twice. Finding that defect is QC. Asking what a timeout means, defining the retry behavior and requiring evidence that duplicate charges are prevented belongs in the engineering process before somebody writes the implementation. QA helps make sure that process exists and is followed. You need both. A sensible process can still produce a broken implementation. A passing test can still check the wrong expectation. And this is where the conversation about coding agents gets interesting. If the workflow is “generate code, then ask another agent to review it”, we’re putting a lot of responsibility on inspection. We’ve automated the reviewer, but we may still have no clear agreement about what the software is supposed to do. Agents can also help recover requirements, expose contradictions, analyse hazards and work out which checks are needed. Then they can test the implementation against those expectations. That gives us a chance to improve how software is built, as well as how quickly we find its defects. Otherwise we risk building a very expensive machine for discovering, at impressive speed, that nobody agreed what “correct” meant.