The 10-80-10 Rule: Stop Coding and Start Leading Your AI

I first heard about the 10-80-10 rule a few weeks back, and something clicked.

It wasn’t about time management. It’s about where your involvement matters.

There was this washing machine analogy that stuck with me:

“The first 10% needs to be human. You figure out what you want to create. Then the middle 80% is like throwing clothes in the washing machine—the machine does all the work. And then you take them out and fold.”

That simple metaphor changed how I think about building.

The rule is this: 10% human clarity. 80% AI execution. 10% human customer conversations.

Not equally split effort. Not planning-building-launching. It’s about what only humans should do versus what we’re just doing out of habit.

For 13 years, I built software the traditional way. I thought. I coded. I shipped.

But here’s what I actually did:

• Spent 30-40% of my time thinking about system design(scaling, availability, reliability) and how to code a functionality

• Spent 40-50% writing the code

• Spent 10-20% shipping and learning

The problem: I was doing the machine’s job.

I was writing boilerplate. Connecting APIs. Refactoring. Writing tests. Fixing edge cases.

Machines are better at all of this.

But I wasn’t doing the human job. The real job.

Understanding if the problem matters. Talking to customers. Deciding what to build. Knowing when to change direction.

I was backwards.

This is where you decide what matters.

Not how to build it. But, what to build and why

This is the human work:

• What problem are you actually solving?

• Who has this problem?

• Why does it matter to them?

• What are your constraints?

• What’s your thesis?

This is crafting. Researching. Humanizing the problem.

For XeniaKit, this was about living the pain myself. Talking to hosts. Understanding fragmentation isn’t a feature gap. It’s a human problem. People are exhausted from managing five tools.

That clarity is human work. Only you can do it.

More on Xeniakit here

Claude Code or Cursor does the work. You do the review.

The machine handles:

• Boilerplate and scaffolding

• API integrations

• Database migrations

• Testing and test generation

• Refactoring

• Bug fixes

• Documentation

Your job is:

• Validate: Does this actually solve the problem?

• Direct: This works, try this way instead.

• Review: Is it secure? Does it fit our standards?

• Unblock: When the AI gets stuck.

• Decide: Is the architecture right? Should we pivot?

You’re not writing code anymore. You’re steering code generation.

The shift is uncomfortable because it feels like you’re doing less. You’re not. You’re doing different work. Better work.

After you have something real, get it in front of people.

This isn’t marketing. It’s learning.

• What actually matters to them?

• What did we get wrong?

• What will make them pay?

• What should we change?

This is where you iterate based on reality, not assumptions.

The middle 80% is astonishing. The AI capabilities are magic. It’s wild what machines can do now.

But that’s not where the real magic is.

The real magic is you. Your human touch. Your ability to understand what matters. Your judgment about what’s worth building.

Seth Godin said it: “Now that we’ve got a tireless computer ready to do the jobs we trained to be pretty good at, it’s human work that matters.”

We spent a century training ourselves to be cogs. Efficient machines, Productive executors.

Now that machines are better at execution, suddenly, human work of thinking, deciding, understanding, and connecting is what’s valuable.

The 10-80-10 rule lets you do that.

Week 1 (10%): What do I want to create? Why?

I own properties. I live the fragmentation. Four pillars emerged. Done.

Weeks 2-6 (80%): Claude Code builds. I review. I decide. I steer.

Week 7-8 (10%): I talk to early users. What matters to them? What changed? What’s missing?

The machine did 80% of the work. I did the rest.

Most people skip the first 10%.

They jump to “productivity.” Building features. Executing.

Because execution feels productive. Because we’ve been trained to measure ourselves by output, not by clarity.

But skipping the first 10% means you’re letting the machine do all the work without direction.

You’re a cog with better tools.

The 10-80-10 rule only works when you actually do the human work.

Where are you actually spending your time?

Are you getting clarity on the problem? Or are you building without it?

Are you letting the machine do the machine work? Or are you doing it yourself?

That’s the 10-80-10 rule. Simple. Uncomfortable. True.

Reply and tell me what you’re stuck on.