Blank-page advice is everywhere. Start with a prompt, give it context, get a draft — fine. But the stall that happens mid-project is a different problem, and most AI advice doesn’t touch it.
You’ve already got a half-built thing. A document that’s 60% written. A plan that made sense two weeks ago and now has a gap in the middle you can’t see around. A piece of code that works except for one behavior you can’t quite characterize. The problem isn’t starting. It’s that you’re stuck inside something you’ve already put real time into, and you can’t see it clearly anymore because you’re too close to it.
AI is quietly more useful here than most people expect — but only if you use it differently than you would at the start of a project.
Explain what you have before you ask for anything
The instinct when stuck is to jump straight to a question: “How do I fix this?” or “What’s wrong with this section?” But a model that doesn’t know what you’ve built will give you a generic answer, not a useful one. Spend the first message just describing the state of the project: what exists, what’s working, what you were trying to do, and where specifically things stopped moving. Don’t clean it up. Rough is fine.
What you’re doing is using the model as a rubber duck that talks back. Putting the stuck state into words often surfaces the problem on its own — and when it doesn’t, you’ve at least given the model something real to work with instead of a vague question it has to fill with assumptions.
Ask it to identify the gap, not solve it
Once you’ve explained what you have, the most useful next prompt usually isn’t “fix this” — it’s “what’s missing.” Ask it to read what you’ve got and tell you what question isn’t answered yet, what assumption is doing a lot of work, or where the logic has a step that’s implied but not actually there.
This is the version of AI assistance that’s genuinely hard to get from a person. Most people, asked to review something mid-project, will start editing the surface. A model will go looking for structural gaps if you ask it to, without the social friction of telling you your third section is doing nothing useful.
Be skeptical of what it finds, though. A model identifying a “gap” might be pointing at something you deliberately left implicit, not something that’s actually broken. Read its diagnosis as a prompt for your own thinking, not as a verdict.
Use it to pressure-test one specific assumption
Mid-project stalls often trace back to one assumption you made early on that’s now quietly causing problems downstream. It’s hard to spot because you stopped questioning the foundation once you started building on it.
Pick something that felt obvious when you decided it and try this prompt shape: “I assumed X because Y. What are the cases where that doesn’t hold?” Not “is my assumption right” — that gets a hedge. “What are the cases where it doesn’t hold” gets specifics.
I’ve run versions of this on automation pipelines — when a design that looked clean in planning turns out to have an edge case that breaks the whole structure. The model won’t always know your exact domain, but it’s good at generating the category of counter-example that makes you realize you hadn’t thought an assumption all the way through.
Dictate the mess, then ask for the shape
Sometimes what’s stuck isn’t a logical gap — it’s that you have too many half-formed thoughts pulling in slightly different directions and you can’t figure out which one to follow. Writing them all out in clean prose takes longer than it should, because the prose itself requires decisions you haven’t made yet.
Just dump it all in: bullet points, fragments, contradictions included. Then ask the model to find the underlying structure. Not to write it up — just to find the structure. “What are the two or three things these are all versions of?”
Raw input often gets a more useful response than polished input, because the model is working from what you actually think rather than from a tidied version that’s already lost some of the signal.
Ask it to argue against the direction you’re going
If you’re mid-project and starting to suspect the direction is wrong but you’re not ready to abandon it, ask the model to make the case against it. Describe where you’re headed, then ask: “What’s the strongest argument that this is the wrong approach?”
You’re not asking it to decide. You’re using it to surface the objection you already half-know is there but haven’t looked at directly. Models are reasonably good at steel-manning opposing positions when you ask explicitly — they’re much worse at volunteering that your plan has a problem if you didn’t ask.
Whether you change course is your call. But you’ll make it with more information than you had before.
What doesn’t work here
Asking for motivation. If you’re stuck because you don’t want to do the thing, AI can’t fix that — it’ll generate an enthusiastic response about how you can definitely do it, which helps for about three minutes. The techniques above are for when you’re genuinely trying to figure out the problem, not when the problem is that you’ve decided (consciously or not) to avoid it.
Also: asking for a complete rewrite. It’ll give you one, it might even be decent, but you’ll lose context and you’ll own it less than you did. For mid-project work specifically, the goal is to get unstuck enough to continue — not to hand off and receive back.
One thing worth trying before you open the model at all
The stuck feeling mid-project is almost always a signal that something earlier needs revisiting, not that what’s in front of you is the actual problem. AI is useful here not because it knows your project, but because explaining your project to something that doesn’t know it forces you to see it from outside again.
Before your next session, write one paragraph describing the current state of the project to someone who’s never seen it — not to a model, just as text in a scratch file. The places you fumble or go vague are probably where the real problem is. Sometimes that’s enough, and you don’t need the model at all.
