skip to content
Mehdi Mehdikhani
Table of Contents

The real challenge of software engineering was always knowing what to build and why to build it, not about writing code. AI agents can write very decent code most of the time, but they can’t solve the actual hard problem - deciding what’s worth building in first place.

Two Laws That Still Matter

Even with AI doing the coding, two old laws become more important than ever:

Kidlin’s Law: If you can write the problem down clearly, the matter is half solved.

Pareto’s Law: 80% of outcomes come from 20% of causes.

AI makes writting code easy. But it makes writing clear problem definitions and finding the right 20% even more critical. Because now you can build wrong solutions at incredible speed.

What AI Can’t Do for You

AI agents can generate functions, refactor code, even build entire features. But they can’t decide what’s worth building. They can’t tell you which 20% of features will drive 80% of user value.

The hard part was never the coding. It was always the thinking.

Before you ask AI to write next function, ask yourself:

  • Can I write down what problem this solves?
  • Is this part of the 20% that actually matters?

If you can’t answer both, AI will just help you build the wrong thing faster.

Why Teams Struggle

When teams have slow velocity, problem is usually not about working more hours. It’s one of two things:

  1. Problem isn’t clearly defined. People build different solutions because they understand problem differently.

  2. They’re chasing wrong 20%. Energy goes into refactoring that doesn’t help users, or building features that sound cool but solve nothing.

Define Before You Prompt

Teams now jump from vague ideas straight to AI prompts. “Build me a user management system” or “Create an API for this.” But garbage in, garbage out still applies.

When you force yourself to write problem clearly before asking AI for help, half the complexity disappears. What looked like huge technical challenge becomes three smaller, well-defined problems. Sometimes you realize the problem isn’t worth solving at all.

I always ask: “Can I explain this problem to someone who doesn’t know our code?” If answer is no, we’re not ready to prompt any AI.

Focus on Right 20%

Pareto principle is everywhere in software. 20% of features drive 80% of user value. 20% of bugs cause 80% of complaints. 20% of technical debt creates 80% of problems.

But we love complexity. We want to handle every edge case, support every use case. More features must mean better software, right? Wrong.

Teams that ship fast focus on the 20% that matters. They say no to features that seem important but don’t move needle. They fix bugs users actually hit, not the interesting ones.