Friday is a good time to notice which problems spent the week being discussed instead of reduced.

When a team is stuck, the instinct is often to add more planning. I’m trying to ask a simpler question instead: What is the smallest thing we can complete that will teach us something?

That is where first-principles thinking becomes practical. Start with the outcome, remove the inherited assumptions, and run one useful experiment.

Coding agents can make that loop much faster. They cannot decide what matters, but they can help us replace days of speculation with evidence.

Which problem on your list needs a smaller experiment rather than a bigger plan?

#CTOThoughts

“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

Building pricing software: “Make it flexible enough for every pricing model and data structure - but simple enough to use without a manual”.

Configurable software creates an interesting paradox.

It is usually harder for vendors to build, test and maintain. Every additional rule, dependency and exception creates more possible combinations - and more opportunities for something to break.

But pricing is rarely simple

Different markets, customer segments, contracts, currencies and approval levels all introduce legitimate complexity.

So, what happens when pricing software is not configurable enough?

The complexity does not disappear. It moves somewhere else:

• Pricing rules and up in spreadsheets
• Exceptions are managed through email and Slack
• Every change becomes an engineering request
• Critical knowledge lives in the heads of a few people

The goal should no be to eliminate complexity. It should be to put it in a system twhere it can be tested, governed and understood.

Configurable software is technically harder to build, but usually better for pricing teams.

Because if your pricing platform cannot represent how your business actually prices … is it simplifying the work, or simply hiding it?

hashtag#CTOThoughts hashtag#PricingTechnology

The bugs I worry about most are the ones I’ve already learned to work around.

Use a product every day and its oddities become muscle memory: click here first, refresh after that, avoid this sequence entirely. Eventually, I stop seeing friction and start seeing “how the product works”. The user, inconveniently, has not attended the same training.

That is what I’m trying to get better at noticing. Dogfooding is useful, but familiarity can hide exactly what it is meant to reveal.

I need to watch new users more closely, write down the “little tricks,” and resist answering problems with “just do this”.

Which workaround has become so normal in your product that nobody calls it a bug anymore?

Inspired by the article Bug blindness - https://danluu.com/bug-blind/

#CTOThoughts #ProductQuality

Autonomous agents are missing one important analytics feature: the analyst’s raised eyebrow.

A human notices when a price looks stale or a revenue number feels suspicious. An agent can follow the workflow perfectly and act confidently on the wrong value. More intelligence does not repair missing context.

Before expanding autonomy, teams need to make human sanity checks explicit: freshness rules, data contracts, quarantines, agreed metric definitions and traceability. Start with read access, then earn the right to write.

The encouraging part is that this work is practical and incremental. It also improves the systems humans already use.

Which important data check in your organization still exists only inside someone’s head?

Source: Making Your Data Ready for Agentic AI

#CTOThoughts #AgenticAI

AI is making code abundant. Good software remains inconveniently scarce.

Generating a change faster does not help much if environment setup, CI, review and verification stay slow. A thirty-minute pipeline can defeat every frontier model you point at it, without displaying the slightest intelligence.

The useful metric is not lines of code or agent-written pull requests. It is cost per accepted change: the full journey from intent through validation to something we are willing to run in production.

Coding agents do not remove engineering constraints. They expose them faster—and move human attention toward judgment, architecture and evidence.

Where is the real bottleneck after code generation?

Source: When code is abundant

#CTOThoughts #AgenticEngineering

Hiring an entry level developer in 2026: “Must have five years of experience reviewing code generated in 30s”.

AI coding has created in interesting paradox.

The people getting the most value from coding agents are usually the experienced engineers. They know what good looks like so they can spot suspicious output and recognise when the AI has pulled an API endpoint out of the hat.

So, how do we get junior developers to acquire that judgment if AI removes the struggle that traditionally created it?

One way to do it is to preserve some productive friction:

• Explain the approach before generating the code
• Own and defend any generated code
• Actually spend some time to debug problems instead of going to the agent right away
• Measure understanding, not lines of code produced

We need to be better at enhancing the learning experience with AI, not replacing it.

If every junior developer becomes an AI manager on day one … who becomes the senior engineer five years from now?

#CTOThoughts #AugmentedEngineering

Inspired by the article AI Coding will Prevent Expertise

@Cursor: “Together it’s a couple of hours to implement your fixes.” Me: 😲 56 seconds later… Cursor: “Fixes are in, tests pass, and no lints. Here’s what changed.” I think we’ve entered a funny new phase of software development.

BEFORE: “I can do that in 10 minutes.” Translation: 2 hours writing the code. 8 hours debugging and testing. NOW: “This will take a couple of hours.” Translation: It’s done before I get a cup of coffee.

Development speed changed. Our ability to estimate apparently didn’t. At least some things in software engineering are predictable.

#SoftwareEngineering #Cursor #DeveloperTools #CTOThoughts