Research. Plan. Execute. Test. The Only AI Workflow That Works.

Last week I wrote about the difference between generative AI and agentic AI. Generative gives you answers. Agentic is the worker. A lot of people read that and the next question was obvious: okay, but how?

This is the how.

I use a four-step process every time I sit down to work with AI. Software, content, research, design, business strategy. It does not matter. It works across all of it. And it works whether you are using Claude, ChatGPT, Gemini, or anything else, because it is not about the tool. It is about how you use it.

Research. Plan. Execute. Test.

In that order. Every time.

Research

AI is a pattern recognition system. I explained this in the last article but it bears repeating because it is the foundation of why this workflow exists.

These models are trained on massive amounts of text, code, images, data. They learn the patterns in that information and use those patterns to generate output. When you ask an AI to write a business plan, it is not thinking about your business. It is pulling from patterns of how business plans have been written before and assembling something that fits the shape.

Here is the problem. That training data has a cutoff. The model knows what it knew when training stopped. If you are working in a field that moves fast, and most fields move fast now, the model’s baseline knowledge might already be behind.

So when you skip research and go straight to “build me this,” you are asking the model to work from whatever it already has. Sometimes that is fine. Sometimes that is six months out of date.

Research fixes this.

When you tell the AI to search the web, pull current documentation, find recent data on your topic, look at what competitors are doing, you are feeding it fresh information it did not have before. New data points. Current standards. Real context about your specific project. And because the model is a pattern recognition system, those new data points become the reference it works from instead of stale training data.

You have probably seen content creators tell you to start your prompt with “You are an expert in X.” And the output does get better when you do that. But think about what is actually happening. You are telling the model to weight the patterns associated with expertise in that field. It works to a degree. But it is still pulling from whatever it already knows.

Compare that to actually making the model go find current information first. It is not just wearing the expert hat. It has the expert’s latest research on the table. Real articles. Real documentation. Real numbers. That is a different quality of output.

That is why research comes first. You are not just giving the model a task. You are giving it context it cannot get on its own.

Plan

After research, you plan. And this is the step that separates people who get real results from people who get AI slop.

When you ask AI to plan before doing anything, you are forcing it to think. Break the problem down. Consider the architecture. The sequence. The dependencies. What could go wrong. There is actual research behind why this works.

In 2022, researchers at Google published a paper on what they called chain-of-thought prompting. The finding was simple: when you make a model reason through steps before answering, accuracy goes up. On one math benchmark, accuracy jumped from 17.9% to 56.5%. Same model. Same data. The only difference was forcing it to think before it answered.

That finding is now baked into how these systems work. Claude has extended thinking. OpenAI built entire model lines around it. Planning is not a nice-to-have. It is how these models produce their best output.

But here is why planning matters even more for you as the person directing the AI.

If you are building something outside your own expertise, and a lot of people using AI are, you do not know what you do not know. You might not know the security protocols for handling payment data. You might not know the accessibility standards for a web interface. You might not know why one database structure works for your use case and another one will break at scale.

When you skip planning and just say “build me a fitness app,” the AI will build you something. It will look like a fitness app. It might even work in a demo. But the database might be wrong. The authentication might have holes. The data model might fall apart past ten users. And you will not know, because you never asked the model to think it through first.

This is the vibe coding problem. Andrej Karpathy, former head of AI at Tesla and one of the most respected researchers in the field, coined the term last year. He described it as fully giving in to the vibes, letting AI write everything, not really looking at what it produces. He meant it casually. But what followed was a wave of people building applications they cannot debug, cannot maintain, and cannot secure. Because they never asked the model to plan.

Planning fixes that. When the model creates a plan, you can read it. You can push back. “Why that database?” “What about mobile?” “Is this secure?” The model will answer because it already thought through those decisions. You go from spectator to architect. You are not passively watching AI produce output. You are directing the structure, questioning the decisions, shaping the approach before anything gets built. You do not need to be an expert to do that. You just need to read the plan and ask questions.

And if you started with research, the plan is even stronger. The model is not guessing. It is planning based on current information it just gathered.

Execute

Now you let it work.

If you are using generative AI, this is where you tell it to generate. Draft the article. Create the image. Build the proposal. The chatbots can export files, create PDFs, download documents now. If you are using agentic AI, this is where you tell it to execute. Build the feature. Process the files. Run the pipeline. The agent acts directly on your system.

Either way, execution comes third. Not first.

When you go straight to execution without research and planning, you are asking the model to make every decision on the fly while simultaneously producing the output. It is generating and deciding at the same time. That is how you end up with bloated code, generic content, and results that look impressive for about thirty seconds before you realize they do not actually work.

When you research first and plan second, execution is clean. The model knows what it is building. It knows the standards. It knows the constraints. It has current data to reference. All it has to do is produce. And these models are good at producing when they know exactly what to produce.

This week I was updating my custom article manager in WordPress to add social media automation. Building with AI is not new to me at this point. But WordPress plugin standards and protocols change often. If I had just said “add social posting to my plugin,” the model would have worked from whatever it already knew. Instead, it looked up the current connection requirements (APIs) for each social platform and the WordPress coding standards for plugins that talk to outside services. It planned how the new feature would fit into the existing plugin, the security requirements, and the posting flow for each platform. I reviewed the plan. There were no adjustments to make, so I approved it and told it to execute. It built out the feature. Not because the model is magic. Because it had current information and a clear structure before it started.

Test

Every AI output needs verification. Every single one.

If you are building software, this means running it. Checking for errors. Testing the cases that are not obvious. Researchers at Stanford found that developers using AI coding assistants were actually more likely to introduce security vulnerabilities. Not because the AI wrote bad code on purpose, but because the code looked so clean and confident that people trusted it without checking.

That is the trap. AI output looks right. It is formatted well. And that makes it easy to accept without checking.

If you are generating content, testing is your review. Is the information accurate? Is it concise? Did it slide into that generic AI voice with the buzzwords and the neat little bow-tie ending? If it reads like a LinkedIn post from someone who says “let’s unpack that,” rewrite it.

If you are making images or designs, is the output logical? Is it consistent with what you asked for? Did you iterate on it or just accept the first version?

Testing is quality control. It is about accuracy and making sure the output actually does what it is supposed to do.

Testing also sends you back to earlier steps. You test, find something off, research why, adjust the plan, execute again. That loop is the process. The best results come from iteration, not from a single pass.

Why This Works

No skilled professional jumps straight into execution without understanding the problem first. Engineers research before they architect. Consultants gather data before they recommend. Writers research before they draft. Doctors diagnose before they treat.

AI did not change those fundamentals. It changed the speed. What used to take a team of people days, one person can now do in a sitting. But the steps are the same. Skip them and you get the same bad results you always would have, just faster.

The four steps also line up with how these models actually work at a technical level. Research gives the model better input. Planning activates its reasoning. Execution uses its generation strength on a focused task. Testing catches the errors that every statistical system will produce.

You do not need to be technical to use this. You do not need to understand how language models work under the hood. You just need the discipline to follow the steps in order instead of skipping straight to “make me something.”

Research. Plan. Execute. Test.

Use it once. You will feel the difference.

Forward → Upward ↑ Onward ↗︎
Mstimaj

Sources and Further Reading

• Wei, J., Wang, X., Schuurmans, D., et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. Google Research, Brain Team.
• Perry, N., Srivastava, M., Kumar, D., Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? Stanford University.
• Lewis, P., Perez, E., Piktus, A., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Meta AI.
• Anthropic. Building Effective Agents.
• Karpathy, A. (2025). Vibe Coding. Commentary on AI-assisted development without code review.