A career across the full breadth of IT.

“We can always regenerate it.”

A reassuring sentence until the person maintaining the code six months later hears it for the first time.

AI coding has introduced an interesting disagreement about what it means to own an implementation.

Some teams use AI to write code faster, while engineers still understand how it works and why it was built that way.

Others treat the implementation as replaceable. They invest in specifications and evaluations, with the expectation that they can regenerate the code when needed.

Both approaches can work. The trouble starts when people on the same team assume they are following different ones.

One engineer expects to inherit code they can understand and maintain. Another assumed nobody would need to read it again.

Production is an awkward place to discover that difference.

Before merging AI-generated work, we should agree on a few things:

• Who is expected to understand the implementation?
• What would we need to regenerate it reliably?
• How would we check that the replacement still does what we need?
• Which parts will still require human understanding?

“Who owns this code?” used to be a fairly straightforward question.

Now we also need to ask what that ownership means.

Inspired by “Do You Still Read the Code?” - https://zanlib.dev/blog/do-you-still-read-the-code/

#CTOThoughts #AIEngineering

“Can it work more like Excel?”

An innocent question that can make an engineering team stare quietly into the distance.

If you build software for people who spend much of their day in spreadsheets, you’ve probably heard it.

“Web applications aren’t Excel” is technically true. It also does very little to help someone finish their work.

People bring habits from tools they know. Often, those habits tell us something useful about what they’re trying to accomplish.

The tricky part is the cost. A familiar interaction that feels instant in a spreadsheet can require considerably more work against a large shared dataset.

So, how much extra waiting is that convenience worth?

As engineers, we tend to care about keeping the application fast. Users care about getting their work done. Those goals usually align, but sometimes a slower interaction saves someone several manual steps.

One way to approach it:

• Understand the task behind the request
• Measure the performance cost
• Make the trade-off clear
• Offer a choice where it makes sense

We still need to exercise engineering judgment. But “that will be slower” is only part of the answer. Slower for the application, or slower for the person doing the work?

#CTOThoughts

AI-generated software has changed what “unfinished” looks like.

Human-built systems usually show their missing pieces: the button does nothing, the endpoint is absent, the report is still an optimistic rectangle.

AI can produce something polished, tested, and demo-ready while hiding a much deeper gap. It looks 90% complete until the first real user discovers that the remaining 10% includes the foundations.

That changes the engineering leader’s job. Progress can no longer be judged mainly by visible features or passing tests. We need deliberate adversarial checks, real workflows, and engineers who understand enough of the system to distrust a convincing demo.

How are your teams distinguishing software that looks finished from software that can safely evolve?

Source: The Chasm: The Shape of Unfinished AI Codebases — https://jimmyhmiller.com/shape-of-unfinished-ai-codebases

#CTOThoughts #AIEngineering