wave2

Transformation Ready: Why AI Came for Software First

A practitioner's playbook for leaders who want AI to actually work in their business.

By Kiran Sahota

When I tell people I work in technology, I frequently get comments such as: "Building software is so easy now" or "I haven't seen much value from AI at our organization". This led me to reflect on what I have seen happening inside software development teams and what may or may not be happening in other disciplines. My conclusion is that this has very little to do with AI or models and everything to do with rigor and discipline.

Software, specifically coding, is not being disrupted first because developers are great at adopting change or because it is closest to those developing AI, it's because software engineering has spent decades making itself a rigorous and auditable discipline. Every line of code is in version control, every change has an owner, reviewer, a build, a test plan, deployment plan, rollback plan, cost meter and an audit trail. Software engineering was ready for AI to disrupt, other professions may just not be there yet.

Stack Overflow Developer Survey 2025 shows that 84% of software development teams are already using AI whereas the rest of the enterprise adoption is lagging behind.

The adoption gap

Software adopted AI. Most enterprises haven’t.

84%

~10%

Software developers

using or planning to use AI tools (2025)

Enterprises overall

with AI agents scaled in any single function

Sources: Stack Overflow Developer Survey 2025; McKinsey, “The state of AI” (Nov 2025)

The adoption gap: 84% of software developers are using or planning to use AI tools, while only ~10% of enterprises overall report AI agents scaled in any single function.

There are a lot of lessons to be learned from software engineering for those looking for a similar level of disruption in their industries or disciplines. I have created this as a playbook for leaders to ensure readiness for their AI journey. My hypothesis is simple: before you transform anything with AI, you have to be transformable.

A background on what software has actually done over decades

A junior engineer (let's call her Mila) at a software company today is working inside a system that has significant levels of controls and guardrails even without AI.

  • Mila writes code in a branch. She can't merge it without a review from at least one peer.
  • The merge triggers an automated build, dozens or hundreds of tests, security scanning, etc.
  • If anything fails, she finds out in minutes, not weeks, and definitely not from the end customer.
  • The code deploys to a staging environment.
  • Then to a small section in production, then scales up.
  • Every request her code handles is logged, every error is captured, every dollar of cloud spend her feature consumes can be attributed. If something goes sideways, she or any on-call engineer can roll the change back in minutes.

None of this requires her permission or a transformation initiative. This is how software engineering works. Software engineering didn't get transformed by AI because developers are smart (they are). It did so because the work itself was already structured for AI.

When an AI coding agent generates a pull request, every guardrail — review, tests, staged deploy, observability, cost attribution, rollback — is the same guardrail a human engineer faces. Those of us using AI to code know that it is not perfect and it doesn't need to be perfect, it just has to be reviewable.

Similarly, let's take an example of a claims adjuster in an insurance company. The adjuster making a judgement call in a process typically lives in a process guide, training binder or in someone's head. There has rarely been automated tests done on any process changes that review whether the change decision is consistent with the last 10,000 similar decisions. Approvals typically happen via email and new processes are launched through memos and training sessions. Cost per claim is not a real-time calculation, it is a metric run by the analytics or the finance team. And in customer facing roles, the rollback is nearly impossible because the decision has already been communicated to the customer.

You can deploy the best model or agents in that process and you will get faster decisions that you cannot verify, audit or undo. That is risk, accelerated.

The AI-Ready System

I think there are 4 transferable disciplines from software engineering that other industries and professions can adopt. They are: Transparency, Control, Verification, and Unit Economics. They should be built in that order and if you miss something, AI will just amplify what was already broken.

The AI-Ready Operating System

Four disciplines, in order. Each one compounds on the one below it.

then deploy AI →

04

Unit Economics

Per-action cost attribution, in real time

03

Verification

Outcome specs, golden datasets, continuous evaluation

02

Control

Gated, staged, reversible change

01

Transparency

Legible, attributable, queryable work

Foundation

The AI-Ready Operating System: four disciplines stacked from foundation to compounding layer — Transparency, Control, Verification, Unit Economics — built bottom-up before AI is deployed.

1. Transparency: show your work

Transparency in software is not a fancy value statement on posters, it is a technical requirement. Every artifact that is produced — code, configuration, requirement, test — is documented and queryable. This is why you can ask AI, "who changed this and why" and you will get answers in seconds.

Here is what you should do:

  • List your business process or use cases you want to transform with AI
  • Review work product produced in each process and determine whether it is documented
  • Review whether the output or decision is structured or machine readable

This is going to be foundational data for AI to learn from.

A quick test: pick any decision your team made last week. Can you reconstruct who made it, what inputs they had, what alternatives they considered, and what the outcome was — in under five minutes, without talking to a human? If the answer is no, you have a transparency problem, and no amount of model intelligence will fix it.

2. Control: gate every change

In software, everything essentially goes through a pipeline: Code review, automated tests, staging environments, progressive rollouts, feature flags, instant rollbacks. You can ship aggressively because you can un-ship just as fast.

Things for you to assess in your process:

  • How quickly can you make changes to your process today
  • Are changes small, iterative and reversable
  • Can changes be staged or A/B tested

Build these controls in your processes before you automate.

3. Verification: write down what "good" looks like

Software teams uncovered something in the late 90's: if you can't write a test for it, you don't really know what "it" is. The exercise of writing tests forced engineers to specify precisely what good looks like. I have worked for years asking my business partners to give me requirements, rules and explain the "definition of done." I got back statements like "It's too complicated" or "It depends". If you cannot explain it to a human, how can AI understand?

Things for you to assess in your process:

  • What is the outcome you are looking for
  • What does good look like
  • Build verification systems such as: ground truth, golden datasets, evaluation suites and human-in-the-loop sampling

If you can't grade the work, you can't improve the work, and you can't trust an AI to do the work.

4. Unit Economics: meter every action

The final discipline that I think is even often skipped by engineers is cost attribution per action. In most mature engineering teams, you can tell what each feature, each API call costs. Teams have cloud cost dashboards and observability tools that can trace a request. This is why companies don't go bankrupt when they "autoscale".

AI will change your cost structure in ways we have not seen in the pre-AI era. You may see that a decision that would cost human hours can now only cost a few cents of inference but you may be running 10x the times when you used to spend time prioritizing. The cost can get out of control even when per-unit or per decision cost continues to decline. But you will not know if you don't monitor.

The cost of intelligence is collapsing

Cost to query a GPT-3.5-class model, per million tokens

A decision that used to cost a human an hour now costs cents of inference — but you may run it 10,000 times where you used to run it 10.

Source: Stanford HAI, “2025 AI Index Report” (Gemini-1.5-Flash-8B vs GPT-3.5 baseline on MMLU)

The cost of intelligence is collapsing: per-million-token inference cost for a GPT-3.5-class model dropped 280× — from $20.00 to $0.07 — between November 2022 and October 2024.

What you can do:

  • Understand current cost per unit
  • Understand cost of AI and project your future cost
  • Build and monitor cost

Without unit economics, you will discover this on the P&L statement, two quarters later. With unit economics, you see it the same day.

The order is important

The four disciplines compound, but in order. Transparency without control gives you a beautifully documented mess. Control without verification gives you a well-gated process for shipping the wrong thing. Verification without unit economics gives you a high-quality system you can't afford to run. And all four without leadership commitment to building them before the launching AI projects will give you a list of pilots that never yielded any ROI.

The hardest part of this isn't technical. It's that the work is unsexy and not fun, otherwise we would have done it before. Building transparency, controls, verification, and unit economics isn't cool like working on AI. It's plumbing. It's the kind of project a board doesn't reward and a CFO doesn't sponsor. Software engineers did this work over decades, mostly because the alternative was not good and all of us are exhausted from being on late night or all night MI bridges. Other industries have been able to defer the work because the system is held together on human heroics and tribal knowledge.

The teams and companies that have done the discipline work will see compounding returns from every AI project. The companies that haven't will see a parade of pilots that never become production. Same AI. Same vendors. Wildly different outcomes.

What to do tomorrow

If I were running a team or business and I wanted to get this investment right, I would not start with fancy tools, I would start with a discipline audit.

Pick the three or four high value workflows or use cases in your business and ask the four questions, in order.

  1. Can I see every decision that happens here, and is the output structured and documented? If not, fix that first.
  2. Can I review, stage, and reverse a change to how this workflow operates? If not, fix that next.
  3. Can I tell whether this workflow is producing good outcomes? If not, fix that next.
  4. Do I know what this workflow costs me to run today — and what it would cost with AI in the loop? If not, fix that last.

Then, and only then, deploy AI. You will be amazed at how fast it works. Not because AI is suddenly better, but because your organization has finally become the kind of organization AI can help.

Software got there first because it's disciplined. The dividend is now visible to everyone. The question for every other industry is whether they'll do the unsexy work in time to collect it.

Sources