Road to ALM

Don’t let AI Optimize the Wrong 30%

Published by

on

There’s a strange pattern emerging in the way companies talk about AI and software development. Almost every conversation focuses on how AI can help developers write code faster. That sounds compelling at first glance. After all, developers spend a lot of time writing code, so anything that speeds that up must be a win. But the uncomfortable truth is that coding often isn’t even the majority of a developer’s job. In many teams, it can be as little as 30 percent of the workweek. The rest disappears into meetings, clarifying requirements, writing documentation, fixing CI pipelines, dealing with testing, responding to security alerts, and untangling the endless administrative threads that bind modern software development together.

Despite this, when companies adopt AI tools, they usually pour all their attention into supercharging that 30 percent. They look for features that autocomplete functions, generate boilerplate, or help with refactoring. These improvements aren’t bad. They just miss the point. If the bottleneck in your process isn’t the act of writing code, then making that part faster doesn’t speed up the overall system. In fact, it can create more work: more code means more to test, more to review, more to document, more to integrate, and more that can break. By focusing AI efforts on the enjoyable part of the job, teams inadvertently expand the pile of work that lives in the less enjoyable 70 percent.

This is where the real opportunity lies. The greatest potential of AI isn’t in making already-skilled developers type faster; its in relieving them from the work they tolerate but rarely enjoy. Requirements are a perfect example. Teams often walk out of meetings with scattered notes, half-decisions, and three slightly different interpretations of what was agreed. An AI system can turn a messy transcript into a clean set of user stories with acceptance criteria, ready for discussion. Documentation is another area ripe for change. No developer wakes up excited about updating a sequence diagram or writing a detailed overview of how the checkout flow works. Yet an AI system can generate those diagrams directly from the code or reconcile the documentation with what is actually implemented.

Testing, too, becomes lighter. An AI-guided exploratory test can open the browser, click through the interface, and capture a full narrative of what happened, complete with screenshots and observations. That narrative can then be converted into an automated test that runs in the pipeline. The same applies to build pipelines and security alerts. Instead of manually digging through CI logs to find a missing path or misconfigured environment variable, AI can read the logs, point out the likely cause, and even prepare a patch. When a security scan flags a risky logging statement or an unsafe input pattern, the system can suggest a fix or apply one automatically in a new branch.

What this does is subtle but important. Instead of making the enjoyable part of software development go faster, AI starts to chip away at the friction surrounding the craft. It reduces the administrative burden, shortens the refinement cycle, improves communication, and eliminates repetitive tasks that drain energy. In other words, it gives developers more time to engage with the parts of the job that drew them into the field in the first place: solving problems, designing systems, and building things that matter.

There’s another reason this matters. Coding is one of the few aspects of the job that directly contributes to a sense of flow, mastery, and satisfaction. It is the part where developers feel in control and see the immediate results of their decisions. The surrounding 70 percent rarely provides the same sense of reward. By optimising only the enjoyable part, organisations risk amplifying pressure: developers can produce more code in less time, but the pile of non-coding work grows just as fast and remains just as manual. That imbalance leads to stress and diminishing returns.

The more transformative way to think about AI is to treat it as a reducer of friction, not just an accelerator of output. It becomes a tool for unblocking, clarifying, recommending, summarising, and stitching systems together. It dissolves the little tasks that clutter a developer’s day. When applied thoughtfully, AI creates a shift in how teams spend their time. The distribution moves away from administrative overhead and toward meaningful creation.

So the real challenge is simple: stop optimising the 30 percent developers already enjoy and start shrinking the 70 percent they don’t. That is where AI can meaningfully change the rhythm of a team, the quality of the work, and the satisfaction of the people doing it. The future of software development is not just faster coders. It is fewer bottlenecks, less friction, and more room for the work that actually inspires people to build.