Sri Rang

The Ai Engineering Reality Check

Find the problem worth solving.

— Sri Rang
Ai Engineering & Ai SDLC

By the end, we should be able to say:

You are trying to achieve an outcome, but a constraint is costing you a consequence.

It matters now because something changed.

Where is Ai already part of your software lifecycle?

Discover → Design → Build → Review → Test → Release → Operate

• Which parts have changed most?
• What is normal today?
• What is still experimental?

What is the scale of your engineering system?

A workaround for one developer may not remain reliable across an engineering organization.

Follow one change from idea to production.

Think of a recent feature, fix, migration, or Ai capability where Ai played a meaningful role.

How did that change move from idea to production?

• Where did Ai contribute?
• Where did a human review or intervene?
• Where did the work wait, loop back, or require rework?
• What created enough confidence to release it?

Where do you lose the most?

How does Ai-assisted work meet your engineering standards?

• Where do your standards live?
• Which standards are automatically enforced?
• Which depend on reviewer knowledge?
• Would five developers describe “good code” the same way?
• What happens when the person carrying that knowledge is unavailable?

What are you doing today to work around the constraint?

A workaround shows where the formal system no longer meets the real need.

Where does the workaround depend on:

• scarce attention;
• individual judgment;
• manual coordination; or
• knowledge held by one person?

What happens when Ai-generated work doubles?

Would your current process hold?

• What becomes the first constraint?
• Where does work begin to queue?
• Which risks become harder to see?
• Whose time becomes the limiting factor?

What happens downstream?

Does the constraint create:

• release delay;
• senior engineering effort;
• rework or escaped defects;
• incidents or audit effort;
• unpredictable delivery; or
• weaker returns from your Ai investment?

What becomes expensive, risky, or impossible if nothing changes?

Can you put a rough size around it?

The estimate does not need to be perfect. We need enough signal to distinguish an irritation from a constraint worth changing.

What can engineering leadership see today?

• Where and how is Ai being used?
• Does greater coding speed improve delivery?
• Is the effect consistent across teams?
• Are quality and standards under control?
• Which questions can you not answer today?

Local activity is not yet an organizational result.

Why is this worth discussing now?

What changed?

• Ai adoption or code volume
• Delivery pressure
• A security event
• A governance requirement
• A platform initiative
• A tool or budget decision

A real problem does not automatically create an urgent problem.

What would meaningfully better look like?

• What becomes faster?
• What becomes safer or more predictable?
• What do developers stop doing manually?
• What can reviewers trust?
• What can leadership see?
• What can you repeat across teams?

How will you know it is working?

The problem, stated clearly.

You are trying to [achieve an outcome].

Today, [the primary constraint] gets in the way.

At your current scale, this causes [the consequence].

As Ai adoption grows, [the risk or bottleneck] becomes more significant.

It matters now because [the trigger].

You will know it is improving when [the signal] changes.

A useful next step should help you decide something.

• Which constraint should you address first?
• Is the problem systemic or specific to one team?
• Can your existing tools and processes scale?
• What should a proof of value demonstrate?
• Who needs to own the change?

The product can wait until the problem deserves it.