AI Is a Tool. Creativity Is Ours.

A few months ago, I found myself sitting in front of a spinning piece of clay.

There were around twelve of us in the pottery class.

Same teacher.
Same instructions.
Roughly the same amount of clay.

We were all trying to make the same thing: a plate.

But none of the plates looked the same.

Some were wide and flat. Others were deeper, smaller, or slightly uneven.

The difference wasn't the clay or the wheel.

It was the person using them.

How much water we used. How much pressure we applied. How we controlled the speed. And how we reacted when the clay started moving somewhere we didn't expect.

I've been thinking about that a lot as AI becomes part of everyday software engineering.

We're increasingly working with the same models, similar tools, and access to an enormous amount of knowledge.

But that doesn't mean we'll produce the same results.

Because engineers don't arrive at these tools empty-handed.

We bring technical experience, mistakes, domain knowledge, product understanding, curiosity, and judgment.

And I think those things are becoming even more important.

Recently, I wanted to help a friend solve a problem in his business.

I understood the software side. I understood the network. And I understood enough about his business to know what the solution actually needed to accomplish.

What I didn't understand well enough was the hardware.

So I used AI to explore that gap.

I described the environment, constraints, network, and ideas I already had. AI helped me identify possible hardware approaches and directions to investigate further.

But the interesting part wasn't that AI gave me answers.

It was what those answers allowed me to ask next.

We stopped thinking about how to reproduce an existing solution more cheaply and started thinking about what we could build specifically for his environment.

That experience reinforced something I've been thinking about:

The value of an engineer is moving further away from simply producing code.

Our value is increasingly in understanding the problem well enough to decide what should be built.

In recognizing tradeoffs.

In connecting technical possibilities to business needs.

In knowing when a solution is unnecessarily complex.

In challenging an answer that looks convincing but doesn't make sense.

And, increasingly, in helping other engineers use these tools without giving up the thinking that makes their work valuable.

For technical leaders, I think that's an important responsibility.

Adopting AI isn't just about making a team faster.

It's about helping a team develop the judgment to use that speed well.

Because speed without judgment can be expensive.

In pottery, spinning the wheel faster doesn't help if you're applying pressure in the wrong place. You can lose the shape, waste the material, and have to start again.

Software isn't so different.

AI can help us produce more, faster. But producing the wrong thing faster isn't progress. Sometimes it just means creating more complexity, more rework, and more technical debt in less time.

The goal shouldn't be speed alone. It should be better decisions with greater leverage.

AI can expand the territory we can explore.

It can shorten the distance between an idea and an implementation.

But it can't decide whether we're solving the right problem.

That's still our responsibility.

We may have the same clay.

We may have the same wheel.

But our hands are different.

The wheel can spin faster.

The clay can become easier to shape.

But we still have to decide what we want to make.