AI Is a Tool, Not a Competitor

When people talk about AI and software engineering, the conversation often becomes a contest.

Will AI replace developers?

Will developers who use AI replace developers who do not?

I find the framing less useful than the practical question: what becomes possible when execution gets cheaper?

That is the question I care about.

I do not need AI to think for me

There are parts of engineering where I want judgement to remain mine.

What problem are we solving?

What constraints actually matter?

What are we unwilling to trade away?

Is the evidence good enough to act?

Those decisions are part of the work, not obstacles around it.

AI is much more interesting when it handles the parts around those decisions.

Exploring an unfamiliar codebase. Generating a first implementation. Producing tests. Comparing approaches. Transforming information from one representation into another. Repeating a small operation while I inspect the results.

The point is not to hand over responsibility.

The point is to lower the cost of moving from a decision to evidence.

Cheap experiments change engineering

For a long time, the cost of implementation encouraged engineers to think extensively before acting.

That instinct was often rational.

If an experiment required a day of development, deployment, and coordination, it made sense to maximise the amount of thinking before starting it.

When the same experiment can be explored in minutes, the optimal loop changes.

I can test an assumption earlier.

I can throw away a bad direction sooner.

I can compare two implementations instead of arguing abstractly about which one is better.

The empirical side of engineering becomes cheaper.

That matters.

The bottleneck moves

When execution gets faster, judgement becomes more visible.

A model can produce a plausible solution very quickly. That does not mean the solution deserves to exist.

So I increasingly think of AI-assisted engineering as a problem of governance.

Who decides what should happen?

What evidence is required before execution?

What actions are safe to automate?

Where must a human remain in the loop?

How do we detect when the system is confidently moving in the wrong direction?

These questions are more interesting to me than raw generation speed.

The goal is a tighter loop

My ideal workflow with AI is simple:

Observe.

Decide.

Let the machine execute the part that is cheap to execute.

Inspect the result.

Learn.

Adjust.

Repeat.

The machine becomes part of the feedback loop rather than a substitute for the engineer.

That distinction matters because good engineering is not just producing output. It is continuously correcting the distance between what we intended and what the system actually does.

What I want from AI

I do not want AI to make me unnecessary.

I want it to make unnecessary friction disappear.

Less waiting to get a prototype.

Less manual translation between tools.

Less repetitive implementation.

Less time spent maintaining the machinery required to perform simple experiments.

More time spent on the decisions that determine whether the system is going in the right direction.

That is a much more useful relationship with AI.

Not human versus machine.

Human judgement, machine execution, and a tighter loop between them.