AI in Software Development: Why Judgment Matters

On 10 October 2026, I joined a panel at Agile Network India's Pune chapter event, Agility in the Age of AI. CoReCo Technologies hosted us. We discussed what happens when AI becomes part of the team.

For years, our challenge in IT services was capacity. We needed to build more, deliver faster and serve more customers without endlessly growing our teams. AI changes that equation. We can now produce a first draft of many things far more quickly than before.

I'm interested in what happens next. Who checks the work? Who decides whether it's any good? And how do we account for that effort when we price our services?

We Were Building Capacity. Then Came the Whiplash.

Before AI, the roadmap was almost always bigger than the team. More business meant more code and more features, and we had to find ways to deliver without adding people at the same rate.

We worked on people, process and technology. Agile helped us move faster. Offshore and nearshore teams helped us scale. Hiring was a constant battle, and adding people sometimes meant adding meetings before we saw much more code being written.

Then AI arrived, and the way we thought about capacity started changing.

The first year was a shock. Tasks that took hours could produce a draft in minutes. Ideas that might have been too expensive to explore became easier to test. Teams began trying different tools and workflows, often without a clear sense of what would work best.

AI Is in the Work, From the Start

At Altzor, we are AI-native. We use AI across our work, from thinking about capacity and building products to business automation. We are also exploring products we might not have considered building before.

There are plenty of tools available, and teams are finding their own ways of working with them. It can be chaotic. It's exciting, too. And honestly, a little scary.

The challenge is figuring out where AI helps, where it creates more work, and how to build a reliable process around it. Adding a tool is easy. Changing the way a team works takes more thought.

The First Draft Is Where We Gain Time

AI gives us a starting point for code, documentation, designs and product ideas. Instead of beginning with a blank page, we have something to react to.

That changes how many ideas we can try. We can explore two or three approaches, compare them and discard the weaker ones before committing too much time to any of them. A bad idea can be caught in a day rather than at a sprint review.

I've found this to be one of the most useful possibilities AI brings to the work. It lowers the cost of experimentation. We can spend less time getting something onto the page and more time deciding whether it deserves to be there.

Of course, producing a draft is only the beginning.

Almost-Right Is Where the Time Comes Back

Writing code is becoming cheaper. Fixing code that looks correct but isn't can still take considerable time.

A first draft is easy to question because everyone knows it needs work. The harder problem is code that looks finished, passes a quick review and contains a mistake that surfaces much later.

The 2025 Stack Overflow Developer Survey gives us a sense of this tension. Among respondents, 84% were using or planning to use AI tools in their development process. Yet 66% identified AI solutions that were almost right but not quite as a major frustration. Another 46% said they distrusted the accuracy of AI outputs.

Source: Stack Overflow Developer Survey 2025

The adoption numbers are encouraging, but the frustrations are worth paying attention to. Teams still need people who can spot a flawed assumption, understand the surrounding system and work out whether a solution is safe to ship.

We catch obviously wrong code. The harder problems are the ones that survive a quick check.

I can see room for a new kind of service here: helping companies review, correct and secure AI-generated code. If generating more code becomes easier, someone still has to make sure that code works as intended.

A developer who can judge the quality of a solution, understand the trade-offs and take responsibility for the result becomes particularly valuable. AI can offer several options. Someone still has to choose the right one.

Our rule is simple: optimise the commodity, augment the strength.

The Fresher's Path Is Changing, Too

Traditionally, freshers wrote code, learned through mistakes and had their work reviewed by senior developers. That process gave them a way to build experience.

AI now handles some of the first-pass work that junior developers used to do. We need to think about what replaces those learning opportunities.

If a fresher relies on AI to produce code but never learns to debug it, question it or understand why it works, we have a problem. They may be able to produce more, but they won't necessarily develop the judgment required to own a system.

Teams will need to be more deliberate about mentoring, code reviews and problem-solving. Junior developers still need opportunities to work through difficult problems themselves, even when AI can produce an answer quickly.

This is something engineering leaders need to address alongside tool adoption. The way we train people has to keep up with the way we build software.

Customers See the Draft. They Don't See the Directing.

Customers notice speed. A screen that once took weeks to build can now be presented in days, with several options and colour palettes.

That naturally raises a question: if engineers have access to AI tools that make them faster, why does the price remain the same?

It's a fair question. From the customer's perspective, paying the same amount while the team uses AI can look like overcharging.

We need to be able to explain what the customer is paying for. Generating code is one part of software development. Understanding the business problem, choosing an approach, reviewing the output, fixing defects, integrating systems and taking responsibility for the result are others.

Those activities take time and expertise, even when the first draft arrives quickly. But we shouldn't expect customers to understand that simply because we tell them. We need to show them where the work happens and what it contributes to the outcome.

This also puts pressure on the way IT services are priced. If AI reduces the time required for certain tasks, charging only for hours worked may become harder to justify. The conversation needs to include the quality of the solution, the complexity of the problem and the responsibility involved in delivering it.

For service companies, the question is how to price judgment when the customer can see the output but not all the work behind it.

The Delivery Floor and the Customer Room

At Altzor, we are bringing engineers into customer conversations. Our developers are becoming forward-deployed engineers, working closer to customers and the problems they need to solve. They also contribute to sales.

This changes what happens before development begins. Engineers can hear the problem directly, ask questions and challenge assumptions instead of receiving a specification after the important decisions have already been made.

They can also identify possibilities that might not emerge from a written brief. That matters when AI makes it easier to explore solutions, because producing options is useful only if we're solving the right problem in the first place.

Bringing engineers closer to customers helps connect the technical work with the business outcome. It also gives them a better understanding of why a particular solution matters.

Thank You

Thank you to Agile Network India and the CoReCo team for bringing us together, and to Prashant Gulvadi, Bhavana Sane and Jay Dholakia for the conversation.