What boardrooms are asking about the SI SDLC

Purna says boards now ask what AI investment delivered, what it cost per unit, and whether Finance can validate the results. Bain research cited in the session says organizations realize about 38% of expected AI value, while only 7% of surveyed firms had Finance validate both financial impact and all-in AI costs by use case. She recommends agreeing on baselines and attribution with Finance before deployment.

Purna describes AI spend as an input: value emerges when freed engineering capacity is deliberately used for outcomes such as more roadmap delivery, faster time to market, or improved quality. She recommends measuring total cost per delivered unit, including engineering time, AI consumption, review, rework, and quality costs. The metric should reflect the business outcome and be agreed with Finance.

Purna says AI can increase task completion while creating review bottlenecks; the figures cited are about 20% more tasks completed and 91% more review time. She outlines three foundations: make organizational context available to agents, route work according to confidence and risk, and manage the SDLC as a product with an owner and improvement backlog. Human judgment should sit at consequential decision points, with routine checks handled by automated quality controls.

The speakers explain that falling token prices can still accompany rising bills: one Azure data set showed usage growing about 4.5 times as cost per million tokens fell to 42% of its baseline, leaving the total bill about 2.3 times higher. They recommend tracking full workflow cost per acceptable output and governing routine, bounded development, and open-ended high-risk agents differently. Platform teams set standards, engineering owns workflow consumption, and Finance validates costs and realized value.

In the Q&A, the speakers say success is less tied to industry or company size than to continuous experimentation and sound engineering foundations. They caution that agents can amplify weak processes, and advise teams to identify end-to-end bottlenecks rather than optimize visible outputs such as lines of code or pull request counts. Examples include reducing production bugs and branch sprawl so engineers can spend more time on valuable work.