Chain-of-Thought Prompting

Chain-of-thought (CoT) prompting asks the model to reason through a problem step by step before producing its answer.

When you write an essay, you probably don't start with the introduction — you start with an outline. CoT is the same thing for LLMs: asking for the plan before the output. The reasoning step makes errors visible before they reach the code, and it typically produces more accurate output because the model has "thought" before acting.

Two forms

Implicit CoT adds a short phrase to any prompt:

[Your task]. Think step by step before answering.

Explicit CoT structures the prompt to produce labelled sections:

[Task description]

First write a Plan: section that lists:
- What HTML elements and structure you'll use
- How you'll handle [specific concern]
- Any potential problems

Then write a Code: section with the complete HTML and CSS.
Output ONLY the plan and code. No prose outside these two sections.

For code tasks, explicit CoT is more reliable than implicit. Structure it so the plan comes first and the code comes second — you can read the plan and catch problems before committing to the output.

When to use it

Use CoT for tasks with multiple interacting parts:

• Multi-section layouts (sticky nav + hero + card grid + footer)
• Features with logic (a form that validates input before submitting)
• Responsive designs (layout that works at multiple screen widths)

For simple tasks ("give me a button in HTML"), CoT adds overhead without much benefit. Save it for when the task has real complexity.

Live example

Direct prompt:

Build a responsive page section with a heading, a three-column card grid,
and a "See all projects" button centred below the grid.
Each card has a title and a two-line description.

The output is likely mostly correct but has at least one problem: columns that don't collapse on mobile, a button that isn't centred, or inconsistent spacing.

CoT prompt:

Build a responsive page section with a heading, a three-column card grid,
and a "See all projects" button centred below the grid.
Each card has a title and a two-line description.

First write a Plan: section. In it, list:
- What HTML elements and structure you'll use
- How you'll make the columns responsive on small screens
- How you'll centre the button
- Any CSS properties worth noting

Then write a Code: section with the complete HTML and CSS.
Output ONLY the plan and code. No prose after the Plan.

Read the plan before looking at the code. If the plan is wrong, correct it there rather than debugging the output later. That's the point — the plan is a checkpoint.

Combining CoT with structured output

Stack them: ask for the plan and structured code in a single prompt.

[Task description]

First write a Plan: section covering your approach.

Then write a Code: section with the HTML and CSS.
The Code section should be paste-ready: no markdown fences, no explanation outside the two labelled sections.

Use this when you need the plan and the code both to be clean.