Motion vs Action: Staying in the Driver Seat in the AI Era

I've not been a consistent reader, but in the spirit of the new year, perhaps it's worth revisiting some old resolutions. I recently read a chapter from Atomic Habits about motion versus action.

The explanation wasn’t new to me, but the author articulated it in a way that landed.

Motion is planning. Designing. Learning. Talking.
Action is execution. Commitment. Doing the thing.

Motion feels productive.
Action brings outcome and by outcomes, I mean success or failure. It comes with risk and cost.

That landed differently and resonated well with the idea I had in mind for my first post here.

The story that stayed with me

The chapter in the book tells a simple story. If you have a goal of getting in shape, losing weight or gaining strength, one common idea is to hit the gym. You can talk to a personal trainer (PT). You can plan workouts. You can read about nutrition and discipline.

You can do all of that for months. And still not be in shape.

The thinking, the planning — what we call motion — doesn't get you anywhere. Because none of it is the workout. Only action changes the body.

You can’t outsource that part.

Why motion is so tempting

What struck me most wasn’t the example itself, but why we stay in motion.

Sometimes, motion is necessary. We genuinely need to learn more.
We need to understand the problem better.

But more often, motion serves another purpose. It lets us feel like we’re progressing without risking failure. Without being judged. Without being wrong in public.

Motion is safe.
Action isn’t.

Action exposes intent. Action invites criticism. Action makes it clear where responsibility sits. And when failure feels too close, we delay it — quietly — by staying busy.

The AI version of the same trap

In software, we’ve always had ways to stay in motion. Being in the industry for quite some time, I'm not ashamed to admit that I've mastered some of these procrastination techniques.

Diagrams.
Documents.
Meetings.
Endless refinements.

And now we are in the AI era, which adds a new layer. Here are different forms of procrastination.

Prompting.
Generating.
Iterating.
Refining outputs.

It looks like action. It feels productive.

But often, it’s just motion with better visuals. And AI makes it very easy to appear decisive without ever fully committing to a direction.

Where things quietly drift

I'm very much in favor of AI. In fact, I’ve been advocating to developers I work with day-to-day to embrace AI fully.

Not cautiously.
Not defensively.
Fully.

But also — not blindy. Always with intent.

What I see instead are two extremes.

1. AI Avoidance

Some teams are still restrained from using AI at all. They're afraid of losing control or falling behind.

• Policy fears
• Skill anxiety
• Organizational hesitation disguised as rigor

The result isn't better engineering. It's slower execution and inconsistent AI usage because some developers will still use it anyway, just without shared standards or intent.

That's not disicpline.
That's denial.

2. AI Laziness

The opposite is more subtle — and more dangerous. Developers skip the thinking, hand control over too quickly, let AI decide before they do. They prompt AI before they understand the problem.

This is motion without action. It looks like productivity, no doubt.

• Many prompts
• Many iterations
• Lots of generated code

But the outcome are usually weak: misaligned solutions, over-engineered abstractions and code that "works" but doesn't fit. This is exactly the PT conversation problem, modernized.

AI didn't fail here. We did.

Both extremes are understandable. Both avoid the same thing — ownership.

In one case, nothing really moves. In the other, things move, but failure is deferred, not removed.

When thinking becomes the real action

Here’s the shift I keep coming back to. In the AI era, thinking is no longer preparation.

Thinking is the action.

• Understanding the business problem
• Digesting context
• Choosing trade-offs
• Deciding what not to build

That’s the workout. You can’t outsource that part. That’s where responsibility becomes real. AI can help you move faster after that. It can’t take that risk for you.

Code has never really been about machines.

As Martin Fowler once said:

Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.

AI hasn’t changed that.

If anything, it’s made it more obvious.

Because when intent isn’t clear, AI will happily generate something anyway. It will compile. It will pass tests. And the result looks fine — until no one can explain why it exists.

Because no one truly stood behind the decision.

AIDD, but human-led

This is how I think about AI-Driven Development (AIDD). Being AI-first doesn't mean outsourcing judgement. It means:

• We think deeper
• We decide faster
• We execute better

AI amplifies whatever you bring to it.

The habit we should build isn't "use AI more" or "use AI less". The habit is this:

Think deliberately. Then act decisively — with AI.

That's where motion turns into action. That's where AI stops being noise and starts being leverage.

Staying in the driver seat

Motion has its place and AI has its place. But action only happens when someone accepts the risk of being wrong.

Chooses direction.
Owns the outcome.

That’s what I want to explore here — piece by piece. How to build systems, features and habits that are AI-first, but human-led. How to keep intent visible when execution is cheap. How to avoid hiding in motion when action is what’s needed.

For now, this feels like a good place to start.