The Ai Engineering Reality Check

Sept. 2, 2026 · 2 days, 4 hours ago Talk

Let us find the problem worth solving

By the end, we should be able to complete this sentence together:

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

Where is Ai already part of the work?

Which parts of the lifecycle have changed most?
Is adoption individual, team-led, or organized across the company?
Which tools and workflows are sanctioned? Which ones simply appeared?
Are you using Ai to build software, building Ai into your product, or both?
What has become normal? What is still experimental?

We do not need an inventory of every tool. We need to understand where Ai enters the work and how important it has become.

What is the scale of your engineering system?

How many developers, teams, and repositories are involved?
Roughly how many changes or pull requests move through it?
Is Ai part of daily development or still limited to pilots?
Are the same practices used across teams?

Scale changes the nature of the problem. A workaround that succeeds for one developer or repository may not remain reliable across an engineering organization.

Follow one change from idea to production

Think of a recent change where Ai played a meaningful role.

It could be a feature, a fix, a migration, or an Ai capability in your product.

How did that change move from idea to production?

Where did the work begin?
Who or what produced the first implementation?
What context did the developer or agent have?
Where did a human need to review or intervene?
What evidence did you require before moving forward?
Where did the work wait, loop back, or require rework?
What finally created enough confidence to release it?

Your real workflow includes tools, people, hand-offs, judgment calls, queues, controls, and workarounds. That is the system we want to understand.

Where do you lose time, confidence, or control?

Time

Does work wait for review or specialist attention?
Do developers repeat work or repair generated code?
Do teams move quickly on implementation but slowly through the full lifecycle?
Are you producing more code without releasing more valuable software?

Confidence

How do you decide that generated code is correct?
Can reviewers see the intent and context behind a change?
Do your tests answer the questions people actually worry about?
Can you distinguish plausible output from production-ready work?

Control

Do teams use different tools, models, rules, and practices?
Do security, privacy, architecture, or compliance enter too late?
Can engineering leadership see how Ai is being used and whether it improves delivery?
Where do you depend on individual judgment instead of a repeatable system?

Standards

How do you keep Ai-assisted work aligned with 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?

Where do you lose the most time, confidence, or control?

And:

What are you doing today to work around it?

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

What happens when Ai-generated work doubles?

Imagine twice as much Ai-generated work moving through your software lifecycle over the next six months.

Would your current process hold?

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

The purpose is not to predict an exact volume. It is to discover which parts of your engineering system can scale and which still depend on scarce attention or informal controls.

What happens downstream?

A constraint matters when it changes an outcome you care about.

What does this constraint cause downstream?

Does it delay releases?
Does it consume senior engineering time?
Does it create rework, escaped defects, incidents, or audit effort?
Does it make delivery less predictable?
Does it prevent successful experiments from becoming normal practice?
Does it weaken the return on the Ai tools you already use?

If nothing changes over the next twelve months:

What becomes expensive, risky, or impossible?

And:

Who feels the consequence most strongly?

Developers may feel interruption. Reviewers may feel overload. Security may feel exposure. Engineering leadership may feel unpredictability. The business may feel delay.

Can you put a rough size around the consequence?

How many hours of developer or reviewer time does it consume each week?
How much review or release delay does it create?
How often does it result in rework or escaped defects?
Has it contributed to incidents or audit effort?
What have you had to explain upward?

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?

Can you see where and how Ai is being used?
Can you compare its effect across teams?
Can you tell whether greater coding speed improves delivery?
Can you demonstrate that quality and standards remain under control?
Which questions are you currently unable to answer?

Ai can improve one part of the lifecycle while moving work or risk somewhere else. Visibility across the system is what separates local activity from an organizational result.

Why is this worth discussing now?

Perhaps Ai adoption is growing. Pull-request volume may be increasing. You may have experienced a security event, received a new governance requirement, started a platform initiative, or reached a tool-renewal decision.

What changed?

A real problem does not automatically create an urgent problem. We want to understand why this matters now.

What would meaningfully better look like?

Imagine that you improved this part of the engineering system.

What would become faster?
What would become safer or more predictable?
What would developers stop doing manually?
What would reviewers be able to trust?
What would engineering leadership be able to see?
What successful practice could you repeat across teams?

How would you know it was working?

The signal may be cycle time, review time, rework, escaped defects, policy coverage, adoption, developer interruption, or another measure you already trust.

The point is not measurement for measurement’s sake. It is to make “better” observable.

The problem, stated clearly

Let us bring the conversation together:

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.

Is that an accurate description of the problem?

What would you change?

A useful next step

The next step depends on the problem we find.

It may be:

a technical workflow deep dive;
an Ai engineering maturity assessment;
a use-case prioritization session;
an architecture, security, or governance workshop; or
a small proof of value around the highest-cost constraint.

A useful next step has a specific problem, the right people, and a decision it is meant to enable.

It should help you decide:

which constraint to address first;
whether the problem is systemic or specific to one team;
whether your existing tools and processes can scale;
what a proof of value should demonstrate; or
which stakeholders need to own the change.

The intake succeeds when we leave with a sharper problem than we had when we began.

The product can wait until the problem deserves it.

Intake worksheet

Copy this block into any Markdown editor or Google Docs.

# Ai Engineering Reality Check

**Organization:**
**Date:**
**Participants:**

## Ai in your software lifecycle

**Where is Ai already part of the work?**

|  | Discover | Design | Build | Review | Test | Release | Operate |
|---|---|---|---|---|---|---|---|
| Daily practice or pilot |  |  |  |  |  |  |  |
| Developers and teams |  |  |  |  |  |  |  |
| Repositories |  |  |  |  |  |  |  |
| Changes or pull requests |  |  |  |  |  |  |  |
| Tools and workflows |  |  |  |  |  |  |  |

## One change from idea to production

**The change:**
**Where Ai contributed:**
**Where humans reviewed or intervened:**
**Where work waited or looped back:**
**What created enough confidence to release:**

## The primary constraint

**Where do you lose the most time, confidence, or control?**

**Constraint:**
**Current workaround:**
**Standards or knowledge involved:**
**What would break first if Ai-generated work doubled:**

## Consequence and urgency

**Downstream consequence:**
**Approximate size — time, delay, rework, incidents, or risk:**
**Who feels it most strongly:**
**What engineering leadership cannot see today:**
**Why this matters now:**

## What better looks like

**Desired outcome:**
**What becomes faster, safer, or more predictable:**
**Observable success signal:**

## The problem statement

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

**Decision to enable:**
**People who should participate:**
**Proposed next session:**