Angel Espinoza

Ask me questions

People have started asking how the work actually gets done. Not what I built, but what a day looks like from idea to something running.

So here it is, start to finish. It is less about the tools than it sounds.

The talking part

An idea usually shows up while I am doing something else, so the first conversation is out loud. I keep a microphone on and I talk to a chatbot the way I would talk to a coworker who happens to know every language.

Can this be done? What would you write it in? What am I not thinking about?

That last question is the one worth paying for. I know the drawings, I know the workflow, I know what the deliverable has to look like. What I do not know is the shape of the problem I am about to walk into, and saying it out loud gets me a list of the parts I would have discovered later, in a worse mood.

Then I ask for a first prompt. Not code. A prompt.

The sharpening part

That first prompt is rough, because it came out of a conversation. So it goes to a second model with one instruction: improve this, and make it specific for the coding agent I am actually going to use.

Different tools want to be talked to differently. A prompt that a chat window would handle fine is not the same as a prompt handed to something that is going to open my files and change them.

Two passes, and nothing has been built yet. That is on purpose. Everything so far is cheap.

Then: Claude Code, and three words

The sharpened prompt goes into Claude Code, and I start in planning mode.

Nothing gets written in planning mode. It reads, it thinks, it comes back with a proposal. That alone is worth the step, because a plan is the last place a mistake is still free.

But the three words are what actually changed my results:

Ask me questions.

I put that on the end of every single one.

Why does it matter so much? Because a plan built from my description is a plan built on what I happened to remember to say. And I always leave things out. I leave out the version of the software. I leave out that the numbers come in as feet and go out as meters. I leave out that this has to survive a file somebody else named.

I do not leave those things out because I am careless. I leave them out because they are obvious to me. That is exactly the category of fact that never makes it into a description.

Questions drag them into the open before anything is built on top of them. Answering five questions costs me two minutes. Finding out later costs an afternoon and a bad mood.

Approve, then let it work

Once the plan comes back and the questions are answered, I approve it and it starts.

It checks in when it needs me, and I approve as it goes.

Here is the part I did not expect to love as much as I do: most of those approvals happen on my phone.

I have approved from an amusement park. On a walk. In front of the TV. The build does not need me in a chair, it needs me reachable, and those are very different requirements. Work that used to be pinned to a desk is now something I can keep moving from a bench, or in a line for a ride.

That is not a small thing. It is most of why the list of finished tools is as long as it is.

The part I would fix if I cared to

Three environments for one idea. Talk in one, sharpen in a second, build in a third.

I could probably collapse that. Somebody reading this is already thinking of how.

I have not, because each stop is genuinely doing a different job, and the friction of moving between them is smaller than the value of the pass. Talking is for discovery. Sharpening is for precision. Building is for building. The handoff is a copy and paste, and a copy and paste is not a problem worth solving.

Maybe it collapses on its own eventually. Until then, the seams are where the thinking happens, and I am not in a hurry to sand them off.

Be Better - Plan to /Plan