Relax. Plan Before Prompting.

Something hit me recently about a former manager of mine.

He kept trying to convince me to use Kiro.

“Bassel, use Kiro.”

My immediate reaction was simple:

“What the hell is Kiro?”

At the time, I did not understand why he was pushing it. I already knew how to work with AI. Quietly, and with all necessary humility temporarily suspended, I admit that I am very good at prompting.

I can visually scan a project, understand its structure, give an AI agent a detailed prompt, and watch it implement something complex surprisingly fast. I often do not need to answer twenty follow-up questions. I know how to provide enough context from the beginning.

The result appears. It works. Maybe there are two small hallucinations hiding somewhere, but nothing seems broken during my quick inspection.

So I ship it.

Fast. Clean. Done.

At least, that is what I told myself.

My manager had noticed the problem

A good manager does more than celebrate your speed. A good manager notices the habits that could eventually turn your speed into a liability.

My former manager understood that I could make AI produce results quickly. He also understood something I was missing: generating working code and understanding the complete solution are two different achievements.

That was why he kept saying:

“Bassel, use Kiro.”

Kiro writes code like many other AI tools. Its real value comes from encouraging you to define the work before asking the AI to execute it.

Its specification workflow can separate a feature into requirements, technical design, and implementation tasks before coding begins. Depending on the situation, it can start from the desired behavior or the technical architecture. Kiro’s official documentation describes this as a structured path from an idea to an implementation.

In simpler terms, Kiro was forcing me to plan.

And apparently, I needed to be forced.

Prompting and planning are different skills

A strong prompt can contain a lot of detail. It can describe the database, interface, validation, tests, security, and expected behavior.

A detailed prompt can still hide weak thinking.

When everything is placed inside one enormous instruction, it becomes easy to overlook contradictions. You may request two features that cannot coexist cleanly. You may describe the happy path while forgetting permissions, failure states, migrations, accessibility, or backward compatibility.

Then the AI begins implementing immediately.

The speed feels incredible, but speed can hide uncertainty. You are watching files appear, tests run, and components render. That movement creates the impression that the problem has already been understood.

Sometimes it has only been interpreted.

Planning creates a pause between wanting something and building it. During that pause, you can ask:

• What problem are we actually solving?
• What behavior must the system support?
• What should it explicitly refuse to do?
• Which decisions affect the architecture?
• What could break existing functionality?
• How will we know the implementation is correct?

Kiro formalizes that pause. Its requirements-first workflow produces requirements, a technical design, and an implementation task list for review before execution. The design can cover components, data models, interfaces, error handling, and testing strategy. Kiro’s requirements-first guide explains that progression.

The AI still performs a large part of the work. The difference is that you receive several opportunities to catch bad assumptions before they become code.

The fast-food problem

Think of unplanned prompting as fast food.

You are hungry. You order something. It arrives almost immediately. It tastes good, and the immediate problem disappears.

You did not learn how it was prepared. You do not necessarily know what went into it. You might not even notice what is missing because your attention is focused on how quickly the hunger disappeared.

That is what rapid AI implementation can feel like.

You ask for a feature. The feature appears. You click through it twice. Nothing explodes.

Shipped.

But what did you learn?

Do you understand why the database was structured that way? Can you explain the authorization model? Do you know which assumptions the agent made? What happens when another developer has to modify the feature six months later?

Fast food has its place. Sometimes it is exactly what you need. Prototypes, experiments, throwaway tools, and early ideas do not always require a formal specification.

The mistake begins when you eat fast food every day and call it nutrition.

The two “harmless” hallucinations

I used to treat small AI hallucinations as background noise.

The AI misunderstood two details? Fine. The feature still works.

A hallucination can survive a quick test and still cause damage later. A fabricated database field, incorrect API assumption, incomplete permission rule, or invented framework behavior can sit quietly until the system reaches production.

The most dangerous bugs often look completely reasonable. They represent decisions that nobody consciously made.

A planning stage makes those decisions visible.

Instead of discovering an assumption inside a pull request containing thirty changed files, you can catch it in a requirements or design document while it is still one sentence.

That is much cheaper to fix.

Speed is still valuable

I am keeping fast prompting as part of my workflow. It is one of my strengths, and I would be foolish to pretend otherwise.

The lesson is that speed becomes more valuable when it has direction.

Planning does not require spending three weeks writing a document for a button. The amount of planning should match the risk and complexity of the task. Kiro even supports quicker specification workflows when a full approval process would be excessive. Its specification documentation distinguishes between detailed feature specs, quick specs, and bug-fix workflows.

The goal is deliberate execution without unnecessary bureaucracy.

For a small visual adjustment, prompt it and move forward. For authentication, payments, database architecture, permissions, migrations, or a feature that will shape the rest of the product, slow down.

Define the requirements.

Review the design.

Break the work into tasks.

Then let the AI move fast.