Most advice on this topic is about prompts. This one is not. The thing that made an impossible project finishable was a plain text file of everything that went wrong — written down the moment it went wrong, then fed back in as the next prompt.
What does it actually mean to use ChatGPT to change your life?
It means using AI to close a specific capability gap that has been blocking a specific goal — not to feel productive. You pick one thing you cannot build alone, then run a repeating loop: attempt, fail, record the exact failure, turn that record into the next prompt. The log carries the project, not your prompting skill.
That distinction matters because the failure mode of AI tools is usually not bad output. It is discontinuity. ChatGPT and its competitors now offer cross-conversation memory and searchable history, but what actually carries between sessions is uneven and not under your control — so you re-explain the same context anyway, and you re-hit the same wall you hit on Tuesday without recognizing it. A written record of failures is the thing that makes session six smarter than session one.
Why do most AI-assisted projects stall before they ship?
They stall because starting is free and finishing is not. AI removes the friction that used to limit how many projects you began, so you begin more of them — and abandon them at the same rate, in a bigger pile. The bottleneck moves from capability to follow-through, and nobody adjusts their system for it.
The research picture is genuinely mixed, which is worth knowing before you bet a year on this. A 2023 controlled experiment by Peng and colleagues at GitHub and Microsoft Research found developers completed a specific coding task about 56% faster with an AI assistant. But a 2025 randomized controlled trial by METR found experienced open-source developers took roughly 19% longer to complete tasks with AI tools — while estimating afterward that the tools had made them about 20% faster. Speed and the feeling of speed came apart completely.
Meanwhile Stack Overflow’s 2024 Developer Survey found around 76% of developers using or planning to use AI tools, while only about 43% said they felt positively about the accuracy of what those tools produced. And Pew Research Center reported in 2025 that roughly a third of U.S. adults had ever used ChatGPT — adoption is broad, but shallow.
Read together: the tool is real, the perceived speedup is unreliable, and the difference is made by whatever system you wrap around it.
What is a failure log, and why does it beat better prompting?
A failure log is a running record of every point where the work broke — what you asked, what happened instead, and what you tried next. It converts a vague sense of “this isn’t working” into a specific, pasteable input. Better prompting improves one answer. A log improves every answer after it.
Here is the honest version of experience behind this article: the author shipped working software without being able to read code. Not by getting good at prompting — by writing down every point of failure the moment it occurred, and turning that written line into the next prompt. When something broke, the entry went into the file before the fix was attempted. That file, not the prompting, is what made the project finishable.
| Dimension | Prompt-first approach | Log-first approach |
|---|---|---|
| What you optimize | The wording of a single request | The accuracy of your description of reality |
| When something breaks | Rephrase and hope | Record the exact break, then reuse it |
| Where knowledge lives | In the chat window and the vendor’s memory feature | In a file you own and can search |
| Next session starts | From whatever the tool happened to retain | From the last known failure, deliberately |
| Repeated bugs | Re-solved from scratch each time | Recognized on sight |
| Requires expertise? | Yes — to judge the answer | No — only to describe the symptom |
The last row is the whole trick. You do not need to understand the code to write “clicked Save, screen went white, nothing in the list.” That sentence is a valid engineering input. Describing a symptom accurately is a skill anyone already has.
What failure-log format did the author actually use?
Five fields, one line each, written in plain language at the moment of failure. No formatting rules, no tool, no tagging system to maintain. The rule is timing, not structure: it gets written before the fix is attempted, because the details that make the entry useful fade quickly once the frustration passes.
| Field | What goes in it | Why it matters |
|---|---|---|
| What I asked for | Your intent in one sentence | Reveals when the ask itself was ambiguous |
| What happened instead | Observable symptom only — no theory | This is the pasteable payload for the next prompt |
| Exact message | Error text, copied verbatim | Verbatim text is worth more than your summary of it |
| What I tried | The attempted fix and its result | Stops you re-trying dead ends next week |
| Still open? | Yes / No | Turns the log into a to-do list for free |
A real entry looks about this dumb: “Asked it to save the form. Instead the page reloaded and the entry vanished. Console said ‘undefined is not an object.’ Tried adding the field back — same thing. Still open.” That paragraph, pasted into the next session, does more work than any prompt template.
How do you run the loop without burning out?
By rationing starts, not ideas. Ideas stay unlimited — that is where the fun is. What gets capped is how many things you are allowed to have in flight. Two per project. Anything else waits in a list until a slot opens, which forces finishing rather than accumulating.
That cap came from evidence, not theory. A scan of the author’s own backups turned up 41 tasks abandoned mid-flight — not 41 ideas, 41 things already started and left open. The constraint was never capability. It was the number of half-built things one person can hold at once.
Two more rules keep the system from rotting:
- Tag every stalled item by what it is blocked on — a decision, another person, an external reply, or you. Items blocked on a one-line decision are the cheapest progress available anywhere in your week, so they get cleared first.
- Treat abandonment as maintenance. Anything untouched for 30 days gets surfaced weekly as a discard candidate — and most of them get discarded. Deleting a dead item is housekeeping, not defeat.
And one rule for the notes themselves: index each entry by the symptom, not the topic. “White screen after save” is findable at 11pm when it happens again. “Form handling notes” is not. A knowledge system only compounds when the label matches the words you will panic-search for.
What should you hand to AI, and what must stay yours?
Hand over execution: syntax, boilerplate, translation, first drafts, and explaining unfamiliar territory. Keep judgment: what to build, what “done” means, what to abandon, and whether the output is actually correct. AI is unlimited execution attached to zero stakes. You supply the stakes.
This is where the METR result earns its place. If experienced people in that trial could feel 20% faster while running 19% slower, your subjective sense of progress is not a measurement. A log is. Counting closed entries tells you something your enthusiasm cannot.
What does this look like over a year?
It looks unremarkable day to day. The author left a 26-year career in one institution and had to rebuild, from scratch, everything that institution used to supply for free: deadlines, review, and someone who noticed when a task stalled. AI replaced none of those. A written system did — the log supplied review, the ledger supplied noticing, the WIP cap supplied deadlines.
The formula underneath is simple: Belief × Thinking × Action. It is multiplication, so a zero anywhere zeroes the product. AI can amplify thinking and speed up action. It cannot supply belief, and it cannot notice that you stopped.
If you want the noticing part handled outside your own head, the VisionDream app turns goals into daily habits so the loop keeps running on the days motivation doesn’t show up. And if the harder question is why the last several attempts died, the book Why Do I Fail While Others Succeed? works through that directly.
Where do you start today?
Open a plain text file. Name it after the one project you have been circling. Write the first entry the next time something breaks — five fields, plain language, before you attempt the fix. That file is the method. Everything else in this article is commentary on it.