AI Transformation in Software Engineering, Lessons from 2025 - Writing

AI Transformation in Software Engineering, Lessons from 2025

· 3 min read

AI Transformation in Software Engineering, Lessons from 2025

“AI as a tool” has continually matured over the past few years. In 2025, our organization, and the ones we support, saw this become a legitimate transformation for SE.

What makes this a transformation?

LLM usage increased in both breadth across the software delivery pipeline, and depth of usage such that how we measure, manage and think about software delivery has changed. Usage here means any of skills, MCP tools or agentic workflows. Some examples are,

  • summary/todo/qa/doc-gen of meeting content
  • validating assets against conventions/specs
  • knowledge management via hybrid cloud/closed systems
  • code generation/review/validation at various depths
  • increasing automation with agentic workflows

What was challenging?

Breadth (across the pipeline), variations (many ways of doing a task), and pace of evolution (newer models/skills/agentic-workflows) created org level challenges with reliability, quality and security.

  • velocity increased, but velocity over quality metrics dropped in many measures
  • some engineers tackled the challenges better than others, but the hurt was from the weakest link
  • stakeholders increasingly prefer contractual articulation of how we handle these challenges

How did we think about it?

We started by viewing this as a velocity vs quality balance. For example, faster coding but unexpected failures. These failures are needed to learn and push ahead. The cost of failure differs across ‘zones’, ie. prototype vs production. Roughly speaking, learning and leverage need to be lower when failure cost is higher. Our goal was to maximize leverage without killing the org. Balance LLM-inspired creation with economic responsibility.

Aspects of our solution

  • ‘zone’ is the scope in which ‘how you can use LLMs’ is defined and controlled
  • zones can be seen as profiles of differing velocity and failure rates for LLM adoption
  • zone owners commit to adoption and risk KPI targets (ie 20% agentic monitoring with no change in mean-time-to-detect)
  • sandboxing, context control (spec templates, system prompt adds etc) and qualifying LLM assets (skills, MCP tools, agentic workflows) are the key control mechanisms
  • signals from co-author attribution, semi-automated impact list (where did LLM help), agentic completion rates

Results and observations

  • as confirmed by other orgs, the numbers are correlated with org specifics, but are directionally informative
  • velocity increase: green-coding ~3x, bug-fixing ~2x, prod-support ~50%, documentation ~3x
  • LLMs themselves can be used to fight the challenges, when you look at the task as enforcement (vs generation)
  • detailed specs, self-reflection, ensembles, workflow iteration are still underutilized
  • agentic workflows have huge evolution ahead

My key takeaway is that effective usage of LLMs requires baking in the specifics of your org deep into adoption. The org then develops the cultural DNA of leveraging the potential of LLMs optimally. You need a framework to support that.

Here’s to making 2026 the year agentic engineering offers reliability, quality, and safety!

#AITransformation #SoftwareEngineering #AgenticWorkflows