Transcription
Every time you give a vague instruction to a coding agent, you are gambling. And the worst part is that the agent won't tell you. So here's a workflow that flips that.
Let's say that you want to build a subscription [clears throat] management. You want to manage your subscriptions like Netflix or Prime Video, whatever. So you open your coding agent. It might be cursor. It might be cloth. It might be GitHub copilot. Whatever the one that you use in your day-to-day. So you prompt it with a simple prompt saying let's build a subscription management to keep track of my Netflix uh Prime Video and so on.
So you write that prompt, you send it and what usually happens is that if the system has to build it and doesn't know a couple of important things like what actually do you want to track? Is it just the cost? Is it the dates? Is it the subscription lifetime? Is it a a family account? Is it um change in terms of pricing you want to observe if the price is increasing for example if you don't say those details basically the coding agent will infer those.
So now if we take this to something that we have been talking about recently in this world of AI and building with agents that is specs or spec-driven development is one way to do that writing a complete document a proposal of what you want to build usually those documents tend to be quite extensive. So let's say that I use a coding agent to go from that tiny little prompt, the one let's build a subscription management thing to a spec. The spec will be a ton of lines, a huge document, ton of details. Inside of those details, some things might either be missing or some things might not be clear. But when you glance through that document, some things might go unnoticed. And eventually when you reach the final stage where you have the code or you are trying to deploying it or you don't even test it and you are just trying to use it maybe the thing that you just built is not the thing that you were looking for.
And why that happens because that small little line that you had in the beginning as the first prompt to build the spec or the first prompt to build the product the feature there's a ton of things missing. So the LLM is always I'm here to help you sir. So we'll try to do every single thing for you and we'll try to guess all of those things.
What I want to share with you today is one way to flip that with cloth code. The thing that I want to share with you is a tool. The name is ask user question. And what is this thing? This tool is a tool that knows how to stop the process and ask a couple of questions to get more context out of you. So before proceeding with trying to do anything and trying to guess uh or filling the blanks, what the tool will actually do is to stop the execution, ask a couple of questions and then proceed. Sounds simple, right?
The problem is that some of the coding agents that we use nowadays don't have this in place. Cursa has something similar. However, tools like GitHub copilot don't have an explicit tool like this one. at least at point of recording is a a feature that everyone is asking for. There's a ton of demand for it, but it's not there.
And the cool thing about this tool in the context of cloth code is the way that it was implemented. Why do I say that? Because at cloth code when you use the ask user question tool, cloth code will stop the process and will start asking questions, but they are multi-option questions. So you don't feel paralyzed with the question. you still have different possibilities that the agent is offering and a couple of them might come back as recommended approaches then you need to take your decision but at least you are involved on those decisions it's not something that you just let the agent do.
What I like about this process is that it removes part of the pressure on writing the perfect prompt because you don't need to to overthink some things or you might forget some couple of important details but you don't need to spend a ton of time trying to improve that prompt because then you can use a tool like this to improve the prompt itself. What is a great process at least to find the things that you that you missed or the things that are uh implied in in the prompt but you need an active decision to a point that it feels like that the best prompt engineer in our workflow is actually the AI itself.
So let's see it in action. I have been working in this tool that prompt that is a tool that allow you to manage your own library of prompts and quickly enhance prompts that you write to have a better prompt in just a couple of seconds. And one of the things that I'm working at the moment is in the integration with Puddle. Puddle will be the the place where I will manage licenses. Uh for example, it's kind of like Stripe if you want to to think about it but a bit more integrated with the software. And I was working on this.
So the thing that I've done was to write a spec and I used specd driven development um to build this thing with spec kit. But before keep going with that spec, I can take a moment and use the ask user question to understand if that spec has some limitation and I will prompt using cloth code read the path to the spec, the spec document and interview me about everything I might have missed implementation details, edge cases, tradeoffs. Skip the obvious stuff and keep going until it's complete. then please update the spec. So I'm basically saying let's look into this spec and try to find all of those things that might be missing and don't stop until we have covered every single thing. Okay, that's the idea.
So now I will run this in plan mode and let's see what happens. And it comes back with this quick dialogue or wizard to uh get our answers. By the way, if you use cloth code likely you have seen this before. Why? When you get into plan mode, cloth code tries to instrument the the prompts to do exactly that to use the ask user question when needed. The difference might be the fact that we clearly stated that we are looking for implementation details, edge cases, tradeoffs, and we want to keep going until it's complete. So then we update the spec. Okay, that's the difference.
But if you run a prompt to let's build our subscription management again and um you leave some things opaque but you run it in plan mode it might open something similar to this. Other approach that you can take if you want is when you write the prompt you can always append something like use ask user question tool that will force cloud code to look into that tool and to bring that tool in place to collect answers.
So now let's see what happens in this um type of flow. So even a spec that was built with that huge process of using spec driven development with spec kit. By the way I have a video on it if you want to watch it. I will link it in the top right here. So on that spec it could find a couple of things that need clarification. For example, the spec says that email and password sign in screen, but the app uh already uses browser based off and pk. So there's a mismatch between the thing that is there.
So let's say that I want to keep what is implemented next question. When the user sign in for the first time, what should happen to the existing local prompts? Okay, this is the type of question that often we don't think about that we eventually will get there and we'll learn that and we collect information by observing what is happening. But sometimes you might miss a couple of questions like this. Okay, let's pick our decision. Another one. When the pro user downgrades to free and has more than five prompts, what happens?
So you answer the questions and then it keeps going and as you can see it's now going into a round two and this will keep happening for a while until the moment that there's no more things to answer and then we'll offload the learnings into the doc. So then we can move to the next step. So I kept it going for a while and you can see it went through seven rounds of questions. Okay, so several runs and now is refreshing my spec with the clarifications and you can see here that cloud code is first refreshing the the document and then we'll force the exit plan mode. So we need to accept those changes. So I will accept it uh automatically just for the sake of the demo and then you start seeing updates to um user stories to edge cases and so on and so forth.
But this doesn't mean that the only way to use the ask user question is with a specification or in the context of the plan both. Let's say that I'm creating a new project and I say build a subscription manager to control my subscription costs and then I can add use the ask user question tool to find important requirements. What I'm doing with that is forcing cloth code to use that tool. I'm nudging the system to collect that information. And you can see that now it will start coming back with questions important questions. Okay, now I need to take decisions like is it a web app? Which the framework what do I want to control? Cost tracking renewal reminders things like that.
Okay, here the user experience is slightly different because I'm inside of the terminal using the CLI not the extension on VS Code but the idea is exactly the same. So you can take advantage of this tool in different contexts. While this might take a couple of more minutes in the process, those minutes will quickly pay off. Why? Because you don't take the risk of eventually understanding that the way that the feature was built is not exactly how it should be. So then you need to either revert and try again or now you are building on top of the thing that was built and usually that leads to suboptimal uh solutions.
So, it's a great tool to use when you you know that there's a chance that something is not clear or you missed something. There's an important decision and you don't want the AI to fill the gaps. So, next time that you are building something new like a new feature and you don't know all the details or you you might feel that the prompt is not complete enough, try to use this tool. Okay? either use the plan mode or do it like I I've done and try to force it and answer a couple of questions and see if the results are better. If you use something like specd driven development, run it on top of your spec. I hope you find this one useful and I think that you will also like this one right here.