Is AI Really Making Software Cheaper?
Insights from Agile Community Network Episode 116
A conversation with my son-in-law, who works in DevOps, started with a problem that sounded familiar: code was getting easier to produce, while the work of getting it safely into production was piling up. More commits were arriving. Validation wasn't keeping pace. The savings at one end of the process were creating work at the other.
In Episode 116, the ACN community explored whether AI is reducing the total cost of software or moving it into testing, security, maintenance, and support. People shared real benefits as well as frustrations. Faster experimentation offers promise. The harder question is what happens after the first draft.
Follow ACN: Apple Podcasts · Spotify · More options · Episode page
The savings depend on where you look
Hendrik Esser described a mixed picture. Exploring a new business idea and building a first product to test it had become much faster and cheaper. In large, existing software systems, the overall improvement was more modest. Teams still needed to review the output, run quality checks, and address security vulnerabilities.
He gave an example of developers accepting code that looked plausible, only for it to fail the test run. The immediate response might be to add more test equipment. His concern was that people first needed to become better at checking what AI produced. A faster stream of submissions doesn't automatically mean a healthier delivery system.
Every new feature leaves a bill
Sheila Eckert challenged the idea that faster development should mean adding more features. Security and compliance teams still have work to do. Support teams need to understand the new behavior. Infrastructure has to carry it, and customers have to navigate the resulting product.
That cost can last for years. Once an important customer depends on a feature, removing it becomes difficult, even if few other people use it. Lowering the cost of writing code doesn't remove the responsibility of owning it. The decision to build something still needs a reason beyond the fact that it's now easier.
Keep the work small enough to understand
Another concern was the size of the work being handed to agents. Sheila described the risk of giving an agent a large requirements document and leaving it to build and review the result overnight. Large batches make feedback harder and can move the bottleneck into review.
Hendrik suggested limiting the amount an AI produces at once, so people can still judge whether each increment is correct. He was clear that this was an idea he had not yet tried in his organization. It connects directly to an Agile habit: make a small change, check it, and use what you learn to decide what comes next.
Governance has to change what the agent does
Diana Larsen drew attention to the difference between writing rules and enforcing them. How do we make sure an agent asks before taking an action? What makes it follow the conditions we've set, rather than choosing the first plausible solution and apologizing afterward?
She also brought the conversation back to value and flow. Human teams and teams that include AI agents still need clear boundaries and useful ways to work together. Buying a tool doesn't settle those questions. Teams need training and constraints that help them use it responsibly.
Sometimes the simpler tool is enough
Chris, a participant working with infrastructure teams, questioned why AI requests were getting priority while ordinary automation waited. Some tasks already had simpler ways to get them done. Prompting, reviewing, and approving an AI response could take longer than doing a small task directly.
Near the end, Jörg Pietruszka asked what people would do with the time they gained. Learning, connecting with colleagues, and developing ideas are worthwhile uses of that time. Filling it with more output of doubtful value can leave people carrying an even larger load.
Questions to bring to your team
Where has AI moved the constraint in your delivery system, and what evidence tells you that?
Which costs are you counting beyond code generation, including review, infrastructure, support, and maintenance?
What could you make smaller, stop building, or handle with ordinary automation before asking people to process more output?
Remembering Sheila McGrath
We opened this episode by remembering our friend and ACN cohost Sheila McGrath. Her voice, wisdom, and care helped shape these conversations and many other communities. We miss her. Her contributions remain part of the ACN archives for anyone who wants to listen again.
Explore this topic
Join Shawna Cullinan, Jörg Pietruszka, Diana Larsen, Sheila Eckert, April Mills, Hendrik Esser, Ray Arell, and all the callers to the monthly live event as we explore this topic. For details on the next live event or how to support our show, please visit acnpodcast.org.
ACN is a community conversation. Bring your experience, questions, or curiosity to a future live session. Listening is welcome, too.
Help keep the conversation going
If ACN brings value to your work, consider supporting the show. Your contribution helps us keep these community conversations going. Sharing an episode with a colleague helps, too.
Comments