I Stopped Starting With Code

For the first few years of my software engineering career, my workflow was simple.

Receive a feature request.

Open VS Code.

Create a branch.

Start coding.

It felt productive.

After all, code was being written. Files were being created. Commits were being pushed.

The problem was that I often found myself rebuilding features, changing requirements, and deleting large chunks of code a few weeks later.

What looked like progress was sometimes just expensive guessing.

Today, my workflow looks very different.

When someone asks me to build a feature, I rarely start with code.

I start with questions.

Ironically, that small change has probably saved me more time than any framework, library, or AI tool I have used.

Coding feels productive because you can see it

There is something satisfying about writing code.

You can see components appearing.

You can see APIs being created.

You can see commits stacking up.

It feels like progress.

But motion and progress are not always the same thing.

Imagine someone walks into a restaurant and says:

Bring me momo.

The waiter disappears into the kitchen.

Ten minutes later, the momo arrives.

The customer looks disappointed.

I wanted fried momo.

The waiter responds:

You never said that.

Whose fault is it?

The momo was delivered exactly as requested.

The problem was never the cooking.

The problem was the order.

Software projects fail this way all the time.

Someone says:

Add notifications.

Or:

Create a dashboard.

Or:

Let's add AI.

Everyone starts working immediately.

Then, halfway through development, the real questions begin.

What kind of notifications?

What should the dashboard show?

What problem is AI solving?

Suddenly, the team realizes they were building before understanding.

The questions matter more than the code

Before I write a single line of code, I now try to answer a few simple questions:

• Who is this for?
• What problem are we solving?
• What happens if we don't build this?
• How will we know it is successful?
• What does the simplest version look like?

These questions sound obvious.

Yet they are often skipped because coding feels more productive.

A vague requirement like:

Build notifications.

Can become something much clearer:

As an investor,
I want to receive an alert when a stock reaches my target price,
so I can review it before making a decision.

Now the feature has direction.

The implementation becomes easier because the problem is understood.

AI changed one thing I didn't expect

Most people think AI has made coding more important.

I think it has made planning more important.

Tools like Cursor, Claude, and ChatGPT can generate code incredibly fast.

But there is a catch.

AI is like hiring the fastest construction worker in the world.

Give them a blueprint and they will build faster than almost anyone.

The problem is that they will build exactly what is on the blueprint.

If the blueprint is wrong, the speed becomes dangerous.

Imagine handing a construction worker these instructions:

Build a house.

What kind of house?

How many rooms?

What budget?

What style?

Who is going to live there?

Without answers, even the fastest builder in the world cannot produce the right outcome.

AI works the same way.

Many developers are discovering that AI is excellent at implementation but struggles with ambiguity.

Humans create ambiguity.

AI simply executes it faster.

The fastest way to write code is often to delay writing it

This sounds backwards.

But the more projects I work on, the more true it becomes.

A few minutes spent clarifying requirements can save days of development.

A simple document can prevent weeks of rework.

A conversation can eliminate dozens of unnecessary tasks.

When I receive a feature request today, I often spend more time defining:

• User stories
• Acceptance criteria
• Edge cases
• Success metrics

Than I do opening my editor.

Once those pieces are clear, implementation becomes surprisingly straightforward.

Whether a human writes the code or AI helps generate it, the outcome improves dramatically.

The real skill is understanding the problem

The software industry often celebrates coding speed.

Faster frameworks.

Faster deployments.

Faster AI generation.

But I think one skill is becoming even more valuable.

Understanding the problem.

Because once the problem is understood:

• Architecture becomes easier.
• Design becomes easier.
• Development becomes easier.
• Testing becomes easier.
• AI becomes more useful.

The biggest bottleneck is rarely typing speed.

It is clarity.

Final thoughts

I still enjoy writing code.

In fact, AI has made implementation more enjoyable than ever.

But code is no longer where I start.

When someone gives me a feature request, my first instinct is not to open my editor.

My first instinct is to ask questions.

Because I have learned something the hard way.

Writing code is expensive.

Deleting code is even more expensive.

And understanding the problem is usually cheaper than both.