AI can generate more code than many teams can review, test, deploy, or support. Once implementation gets faster, the constraint moves somewhere else.
Matt Hargett joins Łukasz Chludziński to trace this pattern across nearly 30 years of software delivery. The conversation starts with paper test plans, products shipped in boxes, and source code stored on a single hard drive. It then moves into coding agents, overnight fuzzing loops, Jira handoffs, phased deployments, and production feedback.
Matt explains why shipping begins the economic life of a product, how agents can test and repair software while the team sleeps, and why every change to the delivery process needs an observable outcome.
Shipping begins the economic life of software
A team can release on schedule, collect revenue, and lose that revenue through support or infrastructure costs.
Matt recalls a McAfee product that shipped on time but created such a heavy support load that the release could not be considered a success. The same risk exists today. A product can attract thousands of users, fail under the demand, and lose those users as quickly as it gained them.
Faster implementation does not resolve this. Teams still need to test how the product behaves at scale, how much it costs to operate, and what happens when real customers begin using it.
Agents need goals, context, and known risks
Matt delegates to agents in much the same way he delegates to junior engineers. He explains the goal, why the work exists, and the hazards that require attention. He leaves room for the agent to determine the implementation.
His agents also learn the quality checks he regularly asks for, including high branch coverage, coverage-directed fuzzing, and marble tests for RxJS observables.
This gives agents space to work while keeping engineering expectations explicit. Experienced engineers still decide which risks deserve attention and whether the result is ready to move forward.
Testing can become an overnight repair loop
Coverage-directed fuzzing feeds malformed inputs into a program and observes which inputs reach new branches in the code. The process then concentrates on the cases that reveal previously unexplored behavior.
Matt explains how an agent can run this loop for hours, inspect the coverage data, fix discovered bugs, and verify the changes. By morning, it may also have found swallowed errors that would have left production telemetry blind.
This combines work that once moved between testers, developers, and separate reports. The agent can execute the loop continuously because each step produces evidence for the next one.
Faster coding moves work into the next constraint
An App Store queue does not move faster because a team generates more code. If deployment remains constrained, faster implementation creates larger release batches and delays feedback.
Matt recommends finding the current bottleneck and asking where work will accumulate after it improves. Some teams may need phased deployments, over-the-air updates, smaller JavaScript bundles, server-driven UI, or a staging environment.
Old handoffs deserve another look
Issue trackers provide visibility and traceability across teams. They also create work: someone has to write, read, update, and close every ticket.
Matt asks whether agents still need all of those handoffs. If one agent creates a Jira ticket for another agent to interpret and close, the process may be recreating the paper test plans that once moved between desks.
Some organizations still need detailed traceability. Others may only need tickets for higher-level work. Each team needs to understand why the handoff exists before automating it.
Local acceleration can create an expensive pileup
Matt describes a company whose quality assurance cycle had grown to 24 months. Developers delivered poor fixes into poor-quality code, testers found more defects, and the cycle repeated.
By the time a requested feature shipped, the customer who asked for it had already moved to a competitor.
AI can produce a similar pattern at a different speed. More implementation capacity can overwhelm review, testing, deployment, or production operations. Improving one stage does not improve the entire delivery system automatically.
Every change needs an observable outcome
Matt recommends changing the delivery process incrementally and observing what happens. A tooling, infrastructure, or workflow change should target a result such as fewer support calls or higher uptime within a defined period.
If the expected result does not appear, the team needs to reassess how the process works before adding another agent loop. More activity does not prove that delivery improved.
The episode leaves engineering leaders with one practical question: If coding became significantly faster tomorrow, where would work begin to pile up next?
Resources
- Matt Hargett on LinkedIn, X, and GitHub
- Łukasz Chludziński on X and LinkedIn
- Claude Code documentation
- OpenAI Codex repository
- RxJS marble testing guide
- Coverage-guided fuzzing: LLVM's libFuzzer guide (further reading)
- agent-device documentation and repository
- Rozenite for Agents documentation
- Apex: Callstack's agentic coding model
