Lesson 1.4 covered small expected adjustments. This lesson is about the moment something feels genuinely broken.
The most important thing first: almost nothing you will encounter at this stage is unfixable, and you do not need to understand the underlying cause to describe the symptom accurately. Diagnosing the fix is the AI's job. Describing what is happening is yours.
The expected / actual / when framework
- What did you expect to happen? State it plainly.
- What actually happened instead? Be specific.
- When did it start? Tie it to a specific request or change.
That is it. An AI tool can usually take those three plain-language answers and locate the issue faster than a vague "it is broken, please fix."
A worked example
When I click the submit button, nothing happens. I expected it to show a thank-you message. It was working before I asked you to change the button color, so I think that is when it broke.
If an error message appears, copy the exact text and paste it into your next message, plus what you were doing right before it appeared.
A word on frustration: it is normal for the first real broken moment to feel discouraging. This is a completely ordinary part of building anything. The framework above is the skill, not a temporary workaround.
Assignment 1.5 - Break something, then fix it with words alone
You're done when: you caused a real problem on purpose and fixed it using plain-language description only.
0 of 5 items checked
Self-check
What are the three things worth stating when something goes wrong?
Expected outcome, actual outcome, and when the issue started.
Do you need to understand an error message before reporting it?
No. Copying the exact text and the immediate context is enough for diagnosis.
Is feeling discouraged by a broken first project a sign you are not cut out for this?
No. It is a normal part of building, and this framework is how you handle it.