| |\n| | |\n|

| |\n|

GenAI Foundations & Prompt Engineering for Developers

| |\n|

A working model of what a language model actually does, and the prompting technique that follows from it. Everything here is aimed at one outcome: getting code you would be willing to put your name on.

| |\n|

| |\n| Session 1 of 2 | |\n| 2 hours + 2 hours | |\n| MERN + Java cohorts | |\n| Tools: any chat LLM | |\n|

| |\n|

A model does exactly one thing, over and over

| |\n|

| |\n| Thefunctionreturnsanemptyarray??? | |\n|

| |\n|

Given everything so far, predict the next piece. Append it. Repeat. Every capability and every failure in this session comes out of that single loop.

| |\n|

By the end of the session

| |\n|

Explain in plain terms how an LLM produces output, and why it invents things that do not exist.
Separate tasks where AI is reliable from tasks where it is risky.
Structure a prompt with role, context, task and output format, and improve it by iterating.
Use few-shot examples and constraints to get consistent, usable code.
Supply the right context — error output, data shapes, surrounding code, conventions — for debugging and generation.
Take a failing prompt, rewrite it, and say precisely why the rewrite worked.

| |\n|

| |\n| | |\n|

| |\n|

Run sheet

| |\n|

How the four hours are spent

| |\n|

Two blocks of two hours. The first block builds the mental model and the prompt structure. The second applies it to real developer tasks and ends with a rewrite exercise.

| |\n|

Block 1 — Foundations

| |\n|

35 min

How an LLM generates output — tokens, next-token prediction, context window, temperature

| |\n|

20 min

Why models hallucinate — live demonstrations of confident wrong answers

| |\n|

20 min

Reliable vs risky — building the task map

| |\n|

10 min

Break

| |\n|

35 min

Prompt anatomy — role, context, task, output format

| |\n|

Block 2 — Applied prompting

| |\n|

30 min

The refinement ladder — one task taken from useless to usable in six rounds

| |\n|

25 min

Constraints and few-shot — forcing a house style, in both JavaScript and Java

| |\n|

10 min

Chain of thought — where step-by-step reasoning earns its cost

| |\n|

10 min

Break

| |\n|

25 min

Developer patterns — explain, scaffold, test, debug, refactor

| |\n|

15 min

Anti-patterns — six broken prompts and the flaw in each

| |\n|

15 min

Rewrite worksheet — the one hands-on piece

| |\n|

10 min

Non-negotiables and what Session 2 covers

| |\n|

Most of this session is demonstrated live on screen rather than typed along with. Every prompt on this page is reproducible afterwards in any free chat tool — the value is in re-running them yourself once you have access.

| |\n|

| |\n| | |\n|

| |\n|

Part 1 · Mental model

| |\n|

How an LLM generates output

| |\n|

There is no database of answers inside the model, no lookup, no compiler, no execution. There is a single repeated prediction, and everything else is a consequence of it.

| |\n|

Tokens: the unit the model actually sees

| |\n|

Text is split into tokens before the model touches it. A token is roughly a word, a word fragment, or a piece of punctuation. Common words are one token. Rare words, identifiers and non-English text split into several.

| |\n|

The same sentence, as a human reads it and as a model receives it

| |\n|

| |\n| useState returns an array of two values. | |\n|

| |\n|

| |\n| useState returns an array of two values. | |\n|

| |\n|

useState is not one thing to the model. It is two fragments that very often appear together.

| |\n|

Three consequences worth carrying with you:

| |\n|

Character-level tasks are unreliable. Counting letters, reversing strings by hand, or counting words are exactly the tasks the tokenisation hides from the model.
Token count is not word count. Code, JSON and long identifiers consume more tokens than prose of the same length.
Tokens are the billing and limit unit. Everything you paste, and everything the model writes back, is counted.

| |\n|

Next-token prediction

| |\n|

At each step the model produces a probability distribution over every possible next token, picks one, appends it, and runs again with the longer text. That is the whole generation loop.

| |\n|

The model is optimising for what plausibly comes next, given everything before it. It is not optimising for what is true, what compiles, or what exists. When the plausible thing and the true thing coincide — which is often — the output is excellent. When they diverge, the output is confidently wrong.

| |\n|

This single sentence explains most of what follows: the model is a plausibility engine, not a truth engine. Every prompting technique in this session is a way of making the true answer also the most plausible one.

| |\n|

Context window

| |\n|

The context window is the total amount of text — your instructions, the code you pasted, the conversation history, and the response being written — that the model can consider at once. It is finite.

| |\n|

Nothing outside the window exists. A file you did not paste is not \"missing\"; from the model's position it was never mentioned.
Long conversations degrade. As a chat grows, early instructions compete with a large volume of later text. Constraints given twenty messages ago quietly stop being honoured.
More context is not automatically better. Pasting an entire project buries the three relevant functions among hundreds of irrelevant ones. Precision beats volume.
Fresh chat for a fresh task. A new problem in an old, cluttered conversation inherits all of that clutter.

| |\n|

Temperature

| |\n|

Temperature controls how the next token is chosen from the probability distribution. Low temperature concentrates on the highest-probability tokens. High temperature flattens the distribution and allows less likely choices.

| |\n|

| |\n| Low · near 0 | |\n|

Focused, repeatable

| |\n|

The same prompt gives near-identical output. Correct default for code, refactoring, data transformation, anything with a right answer.

| |\n|

| |\n| Medium | |\n|

Balanced

| |\n|

Normal conversation, explanation, documentation. Enough variation to phrase things well without wandering.

| |\n|

| |\n| High | |\n|

Varied, surprising

| |\n|

Brainstorming names, generating varied test data, exploring alternative approaches. Not for code you intend to keep.

| |\n|

Chat interfaces usually do not expose this control, but the behaviour is still visible: ask the same question twice in two fresh chats and compare. Low temperature does not mean correct. It means consistent. A model can be consistently wrong.

| |\n|

| |\n| | |\n|

| |\n|

Part 2 · Failure mode

| |\n|

Why models hallucinate

| |\n|

A hallucination is not a malfunction. It is the generation loop working exactly as designed, in a region where the plausible answer and the real answer are not the same thing.

| |\n|

When a model has seen thousands of examples of array.someMethod() patterns, a method name that fits the pattern is highly probable — whether or not that method exists. The model has no mechanism to check. It cannot run the code, open the docs, or fail to find something.

| |\n|

The four shapes hallucination takes in code

| |\n|

| |\n| Shape 1 | |\n|

Invented APIs

| |\n|

A method, hook or utility that does not exist, but sits perfectly inside the naming conventions of a real library. Frequently the most useful-sounding function in the answer.

| |\n|

| |\n| Shape 2 | |\n|

Real API, wrong signature

| |\n|

The function exists. The argument order, option names, or return shape are subtly wrong — often matching an older or newer version than yours.

| |\n|

| |\n| Shape 3 | |\n|

Confident factual claims

| |\n|

Complexity analysis, browser support, version behaviour, performance comparisons — stated in the same assured tone as everything else, with no signal of uncertainty.

| |\n|

| |\n| Shape 4 | |\n|

Fabricated specifics about your code

| |\n|

Referring to fields, props, files or functions you never showed it. The model fills the gap you left with something reasonable.

| |\n|

Live demonstrations

| |\n|

Demo A · character-level blindness

| |\n|

How many times does the letter \"r\" appear in \"refactoring\"?

| |\n|

What to watch for: the answer arrives instantly and confidently. The model never saw the individual characters — it saw two or three tokens.

| |\n|

Demo B · invented API

| |\n|

Which built-in React hook should I use to debounce a value so my search input does not fire on every keystroke?

| |\n|

What to watch for: pressure toward a built-in answer where none exists. A confident, well-named, non-existent hook is a common result.

| |\n|

Demo C · fabricated specifics

| |\n|

Fix the bug in my ProductCard component where the price is not displaying.

| |\n|

What to watch for: no component was provided, yet the answer names props and fields with total assurance. Everything after the first line is invention.

| |\n|

Demo D · confident wrong analysis

| |\n|

What is the time complexity of the algorithm below? Answer in one line. | |\n| function mystery(arr) { | |\n| let out = []; | |\n| for (let i = 0; i < arr.length; i++) { | |\n| if (out.includes(arr[i]) === false) out.push(arr[i]); | |\n| } | |\n| return out; | |\n| }

| |\n|

What to watch for: the hidden cost of includes inside the loop makes this quadratic. A quick, plausible \"O(n)\" is a common answer, and it reads exactly as confidently as a correct one.

| |\n|

The tell is that there is no tell. A hallucinated answer is written with the same fluency, structure and confidence as a correct one. Tone carries no information about accuracy. The only defence is verification.

| |\n|

What reduces it

| |\n|

Supply the ground truth. Paste the actual code, the actual error, the actual data shape. The model cannot invent what you have already specified.
Name versions explicitly. \"React 18\", \"Java 17\", \"Express 4\" removes an entire class of version-mismatch errors.
Give permission to not know. Asking it to say when it is unsure, or to flag which parts need verification, changes what it produces.
Ask for verifiable output. Something you can run, compile or check beats something you can only read and nod at.
Prefer familiar territory. Widely used, stable libraries produce far fewer inventions than niche or fast-moving ones.

| |\n|

| |\n| | |\n|

| |\n|

Part 3 · Judgement

| |\n|

Where AI is reliable, and where it is risky

| |\n|

The useful question is never \"is AI good at coding\". It is \"can I cheaply verify this particular output, and what happens if it is wrong\".

| |\n|

Two axes decide it

| |\n|

| |\n| Axis 1 | |\n|

Verification cost

| |\n|

How long does it take you to know the output is correct? Running a function takes seconds. Confirming an authorisation rule is watertight takes real effort. Low verification cost makes AI safe even when it is often wrong.

| |\n|

| |\n| Axis 2 | |\n|

Cost of being wrong

| |\n|

A malformed test file wastes a minute. A subtly wrong interest calculation or an access-control gap can reach production and cause real damage. High blast radius demands human authorship.

| |\n|

| |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n| | |\n|

Task	Verdict	Why
Explaining unfamiliar code	Reliable	You still read the code afterwards; errors surface immediately.
Boilerplate and scaffolding	Reliable	Highly patterned, and it either runs or it does not.
Syntax translation between languages	Reliable	Structure is preserved; mistakes are visible on reading.
Regex and string transformations	Reliable	Instantly testable against your own examples.
Decoding an error message or stack trace	Reliable	You have the ground truth in hand and can confirm the fix.
Test scaffolding and edge-case suggestions	Reliable	Tests are self-checking; a wrong test fails loudly.
Naming, docs, commit messages	Reliable	You are the judge, and the cost of a bad suggestion is zero.
Exact API signatures and options	Verify	Classic invention territory. Confirm against real documentation.
Version-specific behaviour	Verify	Training data blends versions. Always state yours.
Performance and complexity claims	Verify	Plausible reasoning, unverified conclusions. Measure instead.
Large multi-file refactors	Verify	Too much changes at once to review honestly. Break it up.
Authentication and authorisation logic	Risky	Failures are silent, and the blast radius is the whole system.
Business rules unique to your product	Risky	The model has never seen your rules. It will produce a generic guess.
Financial or regulatory calculations	Risky	Wrong answers look right and carry real consequences.
Anything involving real credentials or customer data	Risky	Never paste it. Covered under non-negotiables.
Learning a fundamental you will be assessed on	Risky	The output is correct and you still cannot do it. The cost arrives later.

| |\n|

A useful reframing: AI raises your ceiling, never your floor. It makes a strong engineer faster at things they could already check. It does not make an engineer who cannot review the output safer — it makes them faster at shipping things nobody has reviewed.

| |\n|

| |\n| | |\n|

| |\n|

Part 4 · Structure

| |\n|

The anatomy of a working prompt

| |\n|

Four components. Not every prompt needs all four, but when output is disappointing, the cause is almost always a missing one.

| |\n|

| |\n| 01 | |\n|

Role

| |\n|

Who the model should answer as. Sets vocabulary, depth and assumptions.

| |\n|

\"You are a senior React developer reviewing code from a junior teammate.\"

| |\n|

| |\n| 02 | |\n|

Context

| |\n|

Everything the model cannot see: the code, the error, the data shape, the versions, the conventions, what you already tried.

| |\n|

The component that breaks, and the exact console output.

| |\n|

| |\n| 03 | |\n|

Task

| |\n|

One specific thing to do, stated as an action. Not a topic, not a wish.

| |\n|

\"Identify why the list re-renders on every keystroke and fix it.\"

| |\n|

| |\n| 04 | |\n|

Output format

| |\n|

The exact shape you want back. Removes the guesswork about how much, in what form, with what around it.

| |\n|

\"One code block, no explanation before or after, comments only where the logic is non-obvious.\"

| |\n|

Same task, with and without the structure

| |\n|

Unstructured

| |\n|

write a search bar in react

| |\n|

What comes back: a generic component with an invented data source, arbitrary styling, a state pattern you may not use, and three paragraphs of explanation you did not ask for. Nothing about it fits your project.

| |\n|

Structured

| |\n|

You are a senior React developer writing code for a beginner-friendly codebase. | |\n| CONTEXT | |\n| - React 18, function components, plain CSS. No TypeScript, no Tailwind, no external libraries. | |\n| - State is managed with useState only. No useEffect in this component. | |\n| - The parent already holds the full list and passes it down. | |\n| - Props: items (array of { id, name, category, price }), onSelect (function). | |\n| TASK | |\n| Write a SearchableList component that renders the items and filters them | |\n| as the user types in a text input. Matching is case-insensitive on name only. | |\n| CONSTRAINTS | |\n| - Do not fetch data. Filter the items prop. | |\n| - Do not mutate the items prop. | |\n| - Show a message when nothing matches. | |\n| - Every list item must have a stable key. | |\n| OUTPUT FORMAT | |\n| One code block containing the complete component. No prose before or after. | |\n| Add a comment only where the logic is not obvious from the code.

| |\n|

What comes back: code that drops into the project unmodified, uses only patterns already in use, and can be reviewed in under a minute because you already know what it should look like.

| |\n|

The structured version takes about ninety seconds to write. It replaces four rounds of \"no, not like that\" — and more importantly, it forces you to decide what you actually want before asking, which is where most of the value sits.

| |\n|

| |\n| | |\n|

| |\n|

Part 5 · Iteration

| |\n|

The refinement ladder

| |\n|

One task, six rounds. Each round adds a single element, and the change in output is attributable to that element alone.

| |\n|

The task: a component that shows a list of items with a search box and a sort control.

| |\n|

Round 1 · bare task

| |\n|

make a list with search and sort

| |\n|

Result: unusable. No language specified, no framework, no data. The model picks all of it for you, and it picks wrong.

| |\n|

Round 2 · + stack and versions

| |\n|

Write a React 18 function component that renders a list of items | |\n| with a search box and a sort control. Plain CSS, no libraries.

| |\n|

Result: runnable React, but with invented data hardcoded inside, and possibly hooks or patterns the codebase does not use. Change: the stack is now fixed.

| |\n|

Round 3 · + the real data shape

| |\n|

... as above ... | |\n| The component receives this prop: | |\n| items: [ | |\n| { id: 1, name: \"Laptop Stand\", category: \"accessories\", price: 1299 }, | |\n| { id: 2, name: \"Mechanical Keyboard\", category: \"input\", price: 4599 } | |\n| ] | |\n| Search filters on name. Sort toggles between price ascending and descending.

| |\n|

Result: the field names are now correct. This single addition eliminates the most common category of unusable output — code written against a data shape that does not exist. Change: no more invented fields.

| |\n|

Round 4 · + constraints

| |\n|

... as above ... | |\n| CONSTRAINTS | |\n| - useState only. Do not use useEffect. | |\n| - Do not mutate the items prop when sorting. | |\n| - Do not fetch anything. | |\n| - Handle the empty-results case. | |\n| - Stable key on every list item.

| |\n|

Result: the two bugs that would otherwise have appeared — an in-place .sort() mutating the prop, and an unnecessary effect — are now prevented rather than corrected later. Change: known failure modes closed off in advance.

| |\n|

Round 5 · + role and output format

| |\n|

You are a senior React developer writing code for a beginner-friendly codebase. | |\n| Prefer clarity over cleverness. | |\n| ... context, task and constraints as above ... | |\n| OUTPUT FORMAT | |\n| One code block, complete component, no prose before or after. | |\n| Comments only where the logic is not obvious.

| |\n|

Result: readable code at the right level, delivered in a form you can copy directly. Change: tone, complexity and packaging are now controlled.

| |\n|

Round 6 · targeted follow-up

| |\n|

Keep everything else identical. Two changes: | |\n| 1. Search should also match category, not just name. | |\n| 2. Pull the filter-and-sort logic into a helper function above the component | |\n| so it can be tested independently. | |\n| Return only the changed parts, not the whole file.

| |\n|

Result: a small reviewable diff instead of a fresh rewrite. Change: iteration is now surgical, which means review stays honest.

| |\n|

What the ladder teaches

| |\n|

Change one thing per round. If you add context, constraints and a role simultaneously and the output improves, you have learned nothing about which mattered.
\"Keep everything else identical\" is the highest-value phrase in iterative prompting. Without it, follow-ups silently rewrite parts you had already accepted.
Ask for changed parts only. A full re-emission of the file makes it impossible to see what actually moved.
Restart rather than repair. After three or four failed rounds, the conversation is polluted with rejected attempts. A fresh chat with everything you have learned folded into round one beats a fifth correction.

| |\n|

The same ladder in Java

| |\n|

The technique is not language-specific. The identical progression applies to a backend task — and the components map one for one.

| |\n|

Java equivalent, fully specified

| |\n|

You are a senior Java developer writing code for a beginner-friendly codebase. | |\n| CONTEXT | |\n| - Java 17. No Lombok, no external libraries beyond the JDK. | |\n| - Existing record: record Item(int id, String name, String category, int price) {} | |\n| - Callers pass an unmodifiable List. | |\n| TASK | |\n| Write a utility class ItemFilter with one public static method that filters | |\n| items by a case-insensitive substring match on name or category, then sorts | |\n| by price. Sort direction is a parameter. | |\n| CONSTRAINTS | |\n| - Do not modify the input list. | |\n| - Return an empty list rather than null when nothing matches. | |\n| - Handle a null or blank search term by returning everything, sorted. | |\n| OUTPUT FORMAT | |\n| One code block. No prose. Javadoc on the public method only.

| |\n|

The point: role, context, task, constraints, output format — same five parts, different stack. The structure is the transferable skill; the syntax is not.

| |\n|

| |\n| | |\n|

| |\n|

Part 6 · Consistency

| |\n|

Constraints and few-shot examples

| |\n|

Describing a style is unreliable. Demonstrating it is reliable. When output needs to match an existing convention, examples beat adjectives every time.

| |\n|

Zero-shot vs few-shot

| |\n|

| |\n| Zero-shot | |\n|

Instruction only

| |\n|

You describe what you want. Correct default for most tasks — it is faster and the model is genuinely good at following clear instructions.

| |\n|

| |\n| Few-shot | |\n|

Instruction plus two or three worked examples

| |\n|

You show what you want. Worth the extra tokens when the output must match a specific format, house style, or existing convention.

| |\n|

Demonstration: enforcing a house style

| |\n|

The goal is DSA solutions in a fixed format — a required header comment block, a specific function signature, and a complexity note in a set position.

| |\n|

Zero-shot · described style

| |\n|

| |\n|

Result: some kind of header, some kind of complexity note, in some position. Ask three times and get three different layouts. \"Our standard format\" means nothing to a model that has never seen it.

| |\n|

Few-shot · demonstrated style

| |\n|

Write solutions in exactly this format. Two examples follow. | |\n| EXAMPLE 1 | |\n| /** | |\n| * Problem: Two Sum | |\n| * Approach: Single-pass hash map storing complements. | |\n| */ | |\n| function twoSum(nums, target) { | |\n| const seen = new Map(); | |\n| for (let i = 0; i < nums.length; i++) { | |\n| const need = target - nums[i]; | |\n| if (seen.has(need)) return [seen.get(need), i]; | |\n| seen.set(nums[i], i); | |\n| } | |\n| return []; | |\n| } | |\n| // Time: O(n) | Space: O(n) | |\n| EXAMPLE 2 | |\n| /** | |\n| * Problem: Maximum Subarray | |\n| * Approach: Kadane's algorithm, running local and global maxima. | |\n| */ | |\n| function maxSubArray(nums) { | |\n| let best = nums[0]; | |\n| let current = nums[0]; | |\n| for (let i = 1; i < nums.length; i++) { | |\n| current = Math.max(nums[i], current + nums[i]); | |\n| best = Math.max(best, current); | |\n| } | |\n| return best; | |\n| } | |\n| // Time: O(n) | Space: O(1) | |\n| NOW SOLVE | |\n| Problem: Valid Palindrome — ignore non-alphanumeric characters and case. | |\n| Follow the format above exactly. No prose outside the code block.

| |\n|

Result: the header block, the comment fields, the trailing complexity line and its exact separator all match. Run it five times and the shape is stable. Two examples are usually enough; a third helps when the pattern has variation the first two do not show.

| |\n|

The practical version of this at work: when adding a file to an existing codebase, paste one similar existing file as the example. You are not asking for good code in the abstract — you are asking for code that looks like it belongs.

| |\n|

Constraints that consistently earn their place

| |\n|

Negative constraints. \"Do not use external libraries.\" \"Do not use TypeScript.\" \"Do not add error handling I did not ask for.\" Naming what to avoid is often more effective than naming what to do.
Scope limits. \"Change only the function I pasted.\" \"Do not restructure the file.\" Prevents unrequested rewrites.
Length and shape. \"Under 40 lines.\" \"One code block.\" \"No explanation.\"
Level. \"Written for someone three months into React.\" Controls how clever the solution gets.
Uncertainty handling. \"If a detail is missing, ask instead of assuming.\" Converts silent invention into a question you can answer.

| |\n|

| |\n| | |\n|

| |\n|

Part 7 · Reasoning

| |\n|

Chain of thought

| |\n|

Asking for reasoning before the answer changes the answer. It also costs time and tokens, so it belongs on some tasks and not others.

| |\n|

Because output is generated one token at a time with each token conditioned on the ones before it, text that works through the problem gives later tokens something better to condition on. Reasoning written first genuinely improves what comes after — it is not a formality.

| |\n|

| |\n| Worth it | |\n|

Multi-step and diagnostic work

| |\n|

Debugging where the cause is not obvious
Choosing between design approaches
Tracing why a value ends up wrong
Anything with several interacting conditions
Complexity analysis, done properly

| |\n|

| |\n| Not worth it | |\n|

Pattern work with a known shape

| |\n|

Boilerplate and scaffolding
Syntax conversion
Renaming and formatting
Simple, well-specified components
Anything where you already know the answer's shape

| |\n|

Reasoning first, then the fix

| |\n|

Before writing any code, work through this in order: | |\n| 1. State what the code currently does, line by line, for the input given. | |\n| 2. Identify the exact point where actual behaviour diverges from expected. | |\n| 3. Explain the root cause in one or two sentences. | |\n| 4. Only then, give the corrected code. | |\n| Do not skip to step 4.

| |\n|

Why the last line matters: without it, the model frequently jumps straight to a plausible fix and the reasoning steps become a retroactive justification of a guess.

| |\n|

Reasoning that reads convincingly can still reach a wrong conclusion. Chain of thought improves the odds and makes the mistake visible — you can now see which step went wrong. It does not make the answer verified.

| |\n|

| |\n| | |\n|

| |\n|

Part 8 · Application

| |\n|

Developer prompting patterns

| |\n|

Five recurring tasks, each with a prompt shape that reliably works.

| |\n|

Pattern 1 — Explaining code

| |\n|

Explain

| |\n|

Explain the code below to someone comfortable with JavaScript | |\n| but new to React. | |\n| Structure the explanation as: | |\n| 1. What this component does, in two sentences. | |\n| 2. What each hook and handler is responsible for. | |\n| 3. The order things happen when the user types in the input. | |\n| 4. Anything here that would surprise someone new to React. | |\n| Do not suggest improvements. I only want to understand it. | |\n| [paste code]

| |\n|

Why it works: the audience level controls vocabulary, the numbered structure controls organisation, and the last line prevents the answer drifting into a code review you did not request.

| |\n|

Pattern 2 — Generating boilerplate

| |\n|

Scaffold

| |\n|

Generate the starting file for a new React component following | |\n| the conventions in the example file below. | |\n| Component name: OrderSummary | |\n| Props: orders (array of { id, total, status }), onCancel (function) | |\n| Behaviour: render each order; show a Cancel button only when status is \"pending\". | |\n| Match the example's import order, export style, prop handling and | |\n| file structure exactly. Same stack: React 18, plain CSS, useState only. | |\n| EXAMPLE FILE | |\n| [paste one existing component]

| |\n|

Why it works: the example carries every convention you would otherwise have to describe and would probably describe incompletely.

| |\n|

Pattern 3 — Writing tests

| |\n|

Test

| |\n|

Write unit tests for the function below. | |\n| Before writing them, list the edge cases you intend to cover | |\n| and wait for me to confirm. | |\n| Constraints once confirmed: | |\n| - Plain Jest, no extra libraries | |\n| - One assertion per test where reasonable | |\n| - Test names describe behaviour, not implementation | |\n| - Cover empty input, single element, duplicates, and invalid input | |\n| [paste function]

| |\n|

Why it works: the pause is the valuable part. The edge-case list is often more useful than the tests themselves, and reviewing it costs ten seconds while reviewing twenty generated tests costs ten minutes.

| |\n|

Pattern 4 — Debugging

| |\n|

Debug

| |\n|

A bug I cannot locate. | |\n| EXPECTED: the list filters as I type. | |\n| ACTUAL: the input accepts one character, then loses focus, and | |\n| the list does not filter. | |\n| EXACT ERROR (browser console): | |\n| [paste the full message and stack, unedited] | |\n| CODE (the whole component, unmodified): | |\n| [paste] | |\n| ALREADY TRIED: | |\n| - Confirmed the items prop arrives correctly (logged it) | |\n| - Removing the key prop changed nothing | |\n| Environment: React 18.2, Vite dev server, Chrome. | |\n| Give the most likely root cause first with your reasoning, then the fix. | |\n| If you need to see another file to be sure, say which one instead of guessing.

| |\n|

Why it works: expected versus actual defines the target, the unedited error is the ground truth, \"already tried\" prevents the first two suggestions being things you have done, and the last line converts invention into a request.

| |\n|

Pattern 5 — Refactoring

| |\n|

Refactor

| |\n|

Refactor the function below for readability only. | |\n| RULES | |\n| - Behaviour must be identical. Same inputs, same outputs, same errors. | |\n| - Do not rename anything exported. | |\n| - Do not change the file structure or add dependencies. | |\n| - Do not add features, validation or error handling. | |\n| After the code, list each change you made and why, one line each, | |\n| so I can review them individually. | |\n| [paste function]

| |\n|

Why it works: refactoring prompts fail by quietly changing behaviour. The rules block that, and the change list makes review a checklist rather than a diff hunt.

| |\n|

| |\n| | |\n|

| |\n|

Part 9 · Context

| |\n|

Giving the right context

| |\n|

The single highest-leverage skill in this session. Most disappointing output is not a model failure — it is a context failure.

| |\n|

The model knows only what is inside the context window. Every gap you leave is filled with something plausible and generic. Deciding what to include is the actual work.

| |\n|

What counts as context

| |\n|

ERRORThe exact error output, unedited. Full message, full stack trace, the line it points to. Paraphrasing an error — \"it says something about undefined\" — throws away the most information-dense text you have.
DATAThe real shape of your data. A sample API response, a props list, a record definition, a config object. This eliminates the most common cause of unusable code: correct logic written against field names that do not exist.
CODEThe surrounding code, not just the broken line. The whole function, the component it lives in, the caller. A bug is rarely on the line where it surfaces.
CONVYour conventions. One existing file that does something similar communicates naming, structure, import order and style more completely than a paragraph describing them.
VERVersions and environment. React 18, Java 17, Node 20, which build tool, which browser. Removes an entire class of confidently outdated answers.
DIFFExpected versus actual. Both halves. \"It does not work\" describes a feeling; \"expected X, got Y\" describes a problem.
TRIEDWhat you already ruled out. Otherwise the first suggestions are the things you spent an hour eliminating.
LIMITConstraints you are working under. Cannot change the API, cannot add dependencies, must keep the existing signature, must work on old browsers.

| |\n|

Same bug, two prompts

| |\n|

No context

| |\n|

my react app crashes when the data loads, how do I fix it

| |\n|

Result: a list of five generic possibilities, none specific to your code, and confident references to components and props that were never mentioned. You now have to test five guesses.

| |\n|

With context

| |\n|

EXPECTED: the product list renders once data arrives. | |\n| ACTUAL: white screen the moment the fetch resolves. | |\n| CONSOLE (exact): | |\n| Uncaught TypeError: Cannot read properties of undefined (reading 'map') | |\n| at ProductList (ProductList.jsx:14:23) | |\n| API RESPONSE (actual, from the Network tab): | |\n| { \"status\": \"ok\", \"data\": { \"products\": [ { \"id\": 1, \"name\": \"Laptop Stand\", \"price\": 1299 } ] } } | |\n| COMPONENT (unmodified, full file): | |\n| [paste] | |\n| ALREADY TRIED: confirmed the request returns 200 and the payload above. | |\n| Environment: React 18.2, Vite, fetch in a useEffect. | |\n| Identify the root cause, then give the minimal fix. | |\n| Do not restructure the component.

| |\n|

Result: the mismatch between the response shape and what the component reads is immediately visible in the context provided. The answer is specific, correct, and checkable in seconds.

| |\n|

Precision beats volume

| |\n|

Pasting more is not the same as pasting better. Three relevant files beat thirty. Signs you have pasted too much: the answer addresses code you did not ask about, earlier constraints stop being honoured, or the response becomes vague and hedged. Signs you have pasted too little: the answer references things you never mentioned, or opens with a list of assumptions.

| |\n|

Before pasting anything, check what is in it. API keys, connection strings, tokens, customer records, internal URLs, proprietary business logic. Context is the most valuable thing you give a model and the most dangerous. This is covered in full under non-negotiables.

| |\n|

| |\n| | |\n|

| |\n|

Part 10 · Diagnosis

| |\n|

Anti-patterns

| |\n|

Six prompts that fail. The flaw in each is named after the prompt — worth attempting the diagnosis before opening it.

| |\n|

1 · \"make my code better\"

| |\n|

Vague ask. \"Better\" is undefined — faster, shorter, more readable, more testable, safer? The model picks one at random, usually by rewriting everything. Fix: name the single dimension and the boundary. \"Reduce this function to under 30 lines without changing behaviour.\"

| |\n|

2 · \"write a react component for a product page and also set up routing and add authentication and write the tests and explain everything\"

| |\n|

Overloaded prompt. Five tasks in one request. Quality drops across all of them, the response is too large to review honestly, and correcting one part forces a regeneration of the rest. Fix: one task per prompt, in sequence, reviewing each before the next.

| |\n|

3 · \"why isn't my useEffect working\"

| |\n|

Missing context. No code, no error, no expected-versus-actual. The model answers about useEffect in general, which you could have read in the docs. Fix: the component, the exact console output, what you expected, what happened, what you already tried.

| |\n|

4 · \"fix the bug in the checkout function\"

| |\n|

Assumed context. Referring to code the model has never seen. It will not say \"I cannot see that file\" — it will invent a checkout function and fix a bug in the invention. Fix: paste it. Every time. Assume nothing carries over, including from earlier in the same chat once it grows long.

| |\n|

5 · \"write a function to sort products by price\"

| |\n|

Missing constraints. Ascending or descending? Mutate or return a copy? What about equal prices, missing prices, string prices? The model chooses, and it commonly chooses in-place .sort(), which mutates your input. Fix: state the direction, the immutability requirement, and the edge cases before asking.

| |\n|

6 · \"what's the fastest way to deep clone an object in javascript in 2026\"

| |\n|

Wrong tool for the job. This is a current-facts-and-measurement question. The model's knowledge has a cutoff, performance depends on your data and runtime, and \"fastest\" cannot be answered without measuring. It will still answer confidently. Fix: use it to generate the benchmark, then run the benchmark.

| |\n|

The pattern behind the patterns

| |\n|

Every one of these is a version of the same mistake: assuming the model knows something it does not. Your intent, your codebase, your definition of better, your constraints, or the current state of the world. It never says \"I do not have that.\" It produces something plausible in the shape of the gap.

| |\n|

| |\n| | |\n|

| |\n|

Part 11 · Exercise

| |\n|

Rewrite worksheet

| |\n|

Five failing prompts. For each: name the flaw, rewrite it, and write one sentence on why the rewrite is better. No AI tool required — the rewriting is the skill being practised.

| |\n|

| |\n| 01 | |\n|

\"add error handling to my api call\"

| |\n|

Which call? What should happen on failure — retry, message, fallback, log? What does the rest of the codebase do?

| |\n|

| |\n| 02 | |\n|

\"convert this to java\"

| |\n|

Which Java version? Preserve structure or idiomatic rewrite? What about the JavaScript-specific behaviour that has no direct equivalent?

| |\n|

| |\n| 03 | |\n|

\"my form doesn't submit\"

| |\n|

Expected versus actual. Any console output. The form code. Already ruled out.

| |\n|

| |\n| 04 | |\n|

\"write tests for this and also fix any bugs you find and improve the naming\"

| |\n|

Three tasks. Which one first, and how do you review the result of all three at once?

| |\n|

| |\n| 05 | |\n|

\"is my code secure?\"

| |\n|

Secure against what? Which code? What is the threat you are worried about, and is this a question a model can answer definitively at all?

| |\n|

Marking your own rewrite

| |\n|

A rewrite is good when it satisfies all of these:

| |\n|

Someone unfamiliar with your project could act on it without asking a question.
It asks for exactly one thing.
Every piece of information the answer depends on is present in the prompt.
The output shape is specified.
You can tell, by reading the result, whether it followed the instructions.

| |\n|

The last one matters most. A prompt so vague that any output looks acceptable has not been improved — it has only been lengthened.

| |\n|

| |\n| | |\n|

| |\n|

Part 12 · Close

| |\n|

Non-negotiables

| |\n|

Five rules. These do not change with tool, model, seniority or deadline.

| |\n|

| |\n| 01 | |\n|

Never ship code you have not read and understood

| |\n|

If you cannot explain each line, you cannot maintain it, review it, or debug it at 2am. The code carries your name in the commit history regardless of who wrote it.

| |\n|

| |\n| 02 | |\n|

Never paste secrets, credentials or customer data

| |\n|

API keys, connection strings, tokens, real customer records, internal system details, proprietary business logic. Once it leaves your machine you do not control it. Replace with realistic dummy values before pasting.

| |\n|

| |\n| 03 | |\n|

Always run and test what it writes

| |\n|

Reading is not verification. Code that looks correct and code that is correct are different things, and the gap is exactly where subtle bugs live.

| |\n|

| |\n| 04 | |\n|

Verify every API, method and factual claim

| |\n|

Especially the ones that solve your problem most conveniently. Confident tone is not evidence. Check the real documentation.

| |\n|

| |\n| 05 | |\n|

Do not outsource the fundamentals

| |\n|

Using AI on something you could not do yourself feels productive and leaves you exactly where you were. Interviews, incidents and design discussions all test the floor, not the ceiling.

| |\n|

| |\n| Where an employer is involved | |\n|

Follow your organisation's AI policy

| |\n|

Many companies restrict which tools may be used and what may be entered into them. These rules are the floor. Your workplace policy sits on top and always wins.

| |\n|

Session 2 · AI-Assisted Development

| |\n|

The next session moves from a chat box to tools that read your files, run commands and make multi-step changes: the AI coding tool landscape, Claude Code, what an agent actually is and when it helps or hurts, reviewing generated diffs line by line, and finding deliberately planted flaws in AI-written code.

| |\n|

Everything today carries forward. The role–context–task–format structure becomes the specification an agent works from, and reliable-versus-risky becomes the judgement about what to let an agent attempt at all.

| |\n|

Between now and then: re-run the prompts on this page in whichever tool you have access to. The refinement ladder is the one worth doing carefully — running rounds 1 through 6 yourself, in order, is the fastest way to internalise what each element actually contributes.

| |\n|

| |\n| | |\n|

| |\n|