Practical AI adoption

Questions & Tools

The tool isn't the work.

I wouldn't scramble eggs with a cheese grater.

I could, but I wouldn't.

Same goes for AI tools.

Or programming languages.

I've seen people spin up entire frameworks just to parse a file.
Not because it was the right choice, but because it was their choice.

I had a couple of really interesting back-to-back interactions this week, and those conversations left me wondering what, exactly, are we doing here?

First, I was asked what my favorite AI tool is. Twice.
Second, I participated in a coding test where the language was specified.
Third, I watched an engineering team in full crisis mode, needing to solve a problem in moments.

For weeks, I've been writing about how small businesses can take advantage of the AI boom, not by choosing a tool first, but by choosing to tell their story, then bringing the tools into the conversation. The goal is to reduce friction and save the time.

AI is a suite of very capable tools, in the right hands, deserving of the same respect I give my tools in my model building shop.

In my experience as a software engineer, we're given problems to solve and we choose the tools after we understand the problem. Or at least as much of it as we're allowed to understand.

In any given project, we use different tools for different phases.

Because each tool is well suited for the task it was designed for.

I can give ten categories for AI tools where those tools are well suited for the task they're designed for. We've started categorizing AI tools the same way we used to categorize programming languages.

Frontend. Backend. Scripting. Data. Testing.

Helpful...until it isn't.

Because eventually someone tries to parse a file with a framework that was never meant for it.

Maybe the answer to the coding test is that I wouldn't use the tool they requested. There are better options for the task at hand.

If I asked ten engineers to read the requirements without specifying the tool, I'd get several different answers back-and I'd bet none of them would start with the language.

I'd bet a dollar on it.

Then, after all of that, I was able to watch something different.

A talented and diverse team, not all engineers, responding to a real problem in real time that would have a very real effect on their business very quickly.

No egos. Just problem solving.

Some people building on ideas.
Some digging deeper into root cause.
Some shaping the plan as it came together.

Within moments, everyone knew what needed to be done.
Each chose their tools for their part.
And they got to work.

They communicated.
They adjusted.
They solved it.

Quickly.

The manager didn't ask about tools or process.
Just for solutions.

Once the solution was clear, the tools followed.

I know a lot of the people reading this are engineers. I follow a lot of engineers.

And I get it.

We like our tools.

We learn them.
We sharpen them.
We want to use them well.

That's a good instinct.

But the tool isn't the work.

The work is the problem in front of you.

My advice?

Don't use the cheese grater to scramble the eggs.