During the last couple of years we have seen plenty of presentations and workshops where the presenter says: “I’ve let AI summarize what we’ve done so far.”

I can hear the audience’s brains collectively shut off.

They don’t want to read long unedited AI sloppified versions of what has been said.

It’s not about AI being bad. It’s about someone abdicating their thinking.

When people share what AI has written without putting their touch to it, they’re essentially saying “I didn’t think this was worth my time to understand, but maybe it’s worth yours.”

If you didn’t digest it, why should I?

Here’s what I’ve noticed: when I share a personal story or genuine viewpoint, people don’t care if AI helped me write it.

The authenticity of the experience matters more than the authenticity of the prose.

You can’t fake living through something. You can get help explaining what you lived through.

There’s a difference between using AI to find better words for your thoughts and using AI to have thoughts for you.

The story has to be yours. The telling can be collaborative.

I rarely share what AI writes directly.

It will always be my responsibility that I can stand behind the text, code, or image.

AI can help me articulate ideas. It cannot give me ideas I don’t actually have.

The tool doesn’t matter. The accountability does.

If you can’t defend it, don’t publish it.

Meta? Sure.

But here’s what just happened: I had a conversation with Claude about my writing process. We found three post ideas. Claude helped me draft them. I edited them down.

Now I’m writing about that process while doing that process.

The recursion doesn’t make it less real. It makes it more honest.

This is how collaboration works now.

Everyone worries AI will make us lazy writers.

The opposite is happening to me.

AI wants to write everything. Long paragraphs. Perfect transitions. Neat conclusions that wrap everything up with a bow.

I spend most of my time cutting. Removing words I don’t like. Cleaning up endings that over-explain the point.

The creative work has shifted. It’s not about generating anymore, it’s about recognizing what matters and ruthlessly eliminating what doesn’t.

I’m forced to practice saying “no” to perfectly decent sentences because they’re not essential.

I’m learning how to distill without losing the core.

How to be brief without being empty.

As a junior developer, I wanted to rewrite everything. Big commits, massive refactors, complete overhauls. It felt productive.

It wasn’t.

Senior developers know better. Small commits. Testable changes. Break it down further.

As a CTO, I coach the same thing. What’s the smallest thing we can release? Can we make a PoC first? How do we break this down?

Now I’m watching people learn this same lesson with AI.

AI wants to write your entire blog post, refactor your whole function, solve your complete problem. Just like junior me, it feels productive.

It isn’t.

The people who get the most out of AI are treating it like code. Small changes they can verify. Iterative improvements they can stand behind.

They’re learning in months what took me years: the more powerful your tool, the more restraint you need to use it well.

Turns out incremental thinking isn’t just good engineering. It’s good everything.

Creation loses to consumption because we make it harder than it needs to be.

Want to start writing? We think about starting a blog, choosing a platform, designing a theme. Too much friction.

Want to learn to code? We plan out an entire app, research frameworks, set up development environments. Too many steps.

Want to draw? We think about technique, style, the right tools. Too much pressure.

Meanwhile, consumption is always one click away.

The path of least resistance wins every time.

So make creation the easier path: open a text file and write one paragraph. Write a function that adds two numbers. Draw something, anything, on paper.

Lower the barrier until creation becomes the default choice.

Most productivity advice assumes you’re optimizing your entire day.

But that’s not reality.

Work takes 8 hours. Sleep takes 8 more. Cooking, family time, basic life maintenance fills most of the rest.

What you’re really optimizing for is maybe 2 hours of discretionary time.

Maybe an hour in the morning before things get hectic. Maybe an hour in the evening after everything settles down.

The consumption vs creation debate isn’t about revolutionizing your whole life. It’s about what you do with those precious few windows.

That’s when you’re actually choosing: do I scroll or do I write? Do I watch or do I build?

Forget the grand life overhaul. Just win those 2 hours.

Getting back to creating after completing something has always been complicated for me.

It’s like the weight of the completed, iterated, polished version becomes the goal post for the next creative thing. The next thing needs to start on the same level as the previous was when it was completed.

This happens almost every time I try to create again. I overconsume on data, reports, articles and research to make a “better” next project.

But really, I’m just avoiding starting at the messy beginning level again.

The solution isn’t better research. It’s permission to suck again.

Your first draft doesn’t need to compete with your last published piece. It just needs to exist.

We’ve trained ourselves to think long-term about everything.

“But what if this needs to scale to millions of users?”

“How will this architecture handle enterprise requirements?”

“What happens when the team grows to 50 developers?”

All reasonable questions. For the wrong projects.

I’ve watched teams spend years discussing between Symfony vs Laravel and then the problem disappeared in two weeks when company moved to java as the golden path. They were so focused on building the “right” foundation that they missed the shifting ground beneath them.

When you’re building a prototype to test an idea, enterprise-grade infrastructure is like bringing a crane to hang a picture frame.

The bias toward long-term thinking creates an invisible tax on every decision. Database schemas become more complex than needed. Code gets abstracted for flexibility that never comes. Simple features become architectural discussions.

Meanwhile, competitors ship working versions and learn what actually matters.

The irony? By the time you’ve built something robust enough to “scale properly,” the market has often moved on. Your bulletproof solution solves yesterday’s problem with tomorrow’s complexity.

I’m not advocating for sloppy work. I’m questioning our default assumption that every project needs to survive nuclear war.

Sometimes the best long-term strategy is admitting you don’t know what the long term looks like.

Build for what you know today. Let tomorrow teach you what it actually needs.