When Coding Gets Faster, What Breaks Next?

Hargett recalls starting in QA at McAfee in 1997, when one developer kept source code on a hard drive and testers worked through printed test plans. He describes how estimation practices later shifted from days and hours toward T-shirt sizes and story points, though teams still often tried to turn them back into schedules.

Shipping on time does not guarantee a successful product: Hargett recalls a buggy release that created such a heavy support load that it undermined the launch. For live services, shipping begins the product’s economic life, so teams should test for failures, operating costs, and scale before success brings more users than the system can handle.

Hargett says he gives agents the problem, its purpose, and the risks to avoid, much as he would delegate to a junior engineer. He explains coverage-driven fuzzing, where a fuzzer prioritizes inputs that reach new code paths; agents can use that feedback to find and fix bugs, but experienced people still need to decide what matters and verify the work.

Hargett asks whether teams still need tickets for every task when agents can work directly, while recognizing that regulated work may require traceability. He argues that teams should examine what each process step is for instead of keeping Jira boards or other practices by habit, and adapt changes to what their organization needs.

Hargett recommends identifying the current bottleneck before adding agents across the life cycle, since speeding up coding may create a testing or release pileup. He uses app store review as an example: incremental delivery options such as over-the-air updates, delta bundles, server-driven UI, or server-side rendering can help teams get feedback without bundling every change into one submission. Teams should make changes incrementally and track observable outcomes such as support calls or uptime.