Elwaleed Gadalla — I build products and help others build with AI.

Understand

Know where you’re trying to go before you start building.

Before I open a coding agent, I need to get clear on the problem I’m trying to solve. Depending on the project, that could mean speaking with the team, walking through the current workflow, talking to the people who will actually use the tool, or working through a problem I’m trying to solve for myself. I want to understand what is happening today and, most importantly, what the outcome actually needs to look like. I don’t need to know how to build it yet, but I do need to know where I’m trying to go. If I don’t, AI can lead me any and every which way.

Context

Give the AI enough context to understand exactly what you’re trying to do.

Once I understand the problem and the outcome, I need the agent to understand them too. I give it everything useful and safe to share, including the current workflow, existing solutions, conversations, documents, screenshots, data, constraints, previous work, and a clear picture of the result I’m working toward. The goal is to give the AI enough context to understand exactly what I’m trying to get done instead of leaving it to make assumptions. When I move between tools, I can have the agent turn that into a context document so the same understanding comes with me.

Visualize

Get a visual of what you’re trying to build early on. (See your idea come to life)

With that context in place, I create a first visual of what the tool could look like. That might be a UI render, a prototype, or anything that gives me something real to see and interact with. The prototype is not production, and that is not its job. Its job is to help me move through the idea, change what doesn’t feel right, catch what is missing, and decide whether this is actually the direction I want to go. Once the direction feels right, the visual becomes the north star for the build and gives the agent a clear picture of the end result too.

Reverse Engineer

Work backward from the end result and map out what it will take to get there.

I bring the visual back to my coding agent along with everything we already have. Now it can see both sides: where we are today and the version of the outcome we’re trying to reach. From there, we work backward through the gap and figure out what is still needed, whether that is more context, documents, data, integrations, systems, or technical knowledge I don’t have yet. We turn that into a plan made up of digestible phases, each with a concrete success point. The same process can be used to map out an entire product or just one feature.

Build

Build through the plan one phase at a time, testing as you go.

Once the plan is clear, I start building through it one phase at a time. I’m not trying to make every phase perfect before I move on. I’m trying to reach the success point, which means enough of the right thing is working for us to move into the next phase. When I run into something I don’t understand, I ask the agent to explain what it is, why it matters here, how it works, and what alternatives I have. I learn what I need at the point I need it, make the decision, and keep building.

Use

Use the real tool as you build, find the gaps, and repeat.

As I build, I start using the real tool instead of waiting until everything is finished. After each phase, I test it with real inputs and real workflows to see whether it actually does what I wanted it to do. That’s where I find the issues, misalignment, missing pieces, or changes I could not have seen earlier. I work with the agent to identify the gap, then repeat the process at the level of that problem. Sometimes I need another visual. Other times, I only need the agent to walk me through a technical piece or help me rethink the plan. I use the parts of the framework that the gap actually needs, solve it, bring it back into the larger build, and keep going.