Question 1

What does "prompt engineering" mean in your day-to-day work?

Accepted Answer

Move away from magic-word hunting — emphasise the engineering side. For me it is three things: 1. Precise task framing — what I want, what counts as done, what must not be touched. 2. The right context — which file, which pattern. Not the whole repo, 2-3 relevant files. 3. A verification loop — a build/test command so the agent checks itself. Then add: I don't keep repeated instructions in prompts, I move them into CLAUDE.md or a skill. So the output of prompt engineering is not a good prompt but a well-configured repo.

Question 2

You are teaching a junior developer to work with the agent. What are your first three rules?

Accepted Answer

Pick simple, checkable rules: 1. Don't merge code you don't understand. If you can't explain code the agent wrote, it is not yours. Ask for an explanation or simplify it. 2. Move in small steps. One task, one verification, one commit. A large change doesn't get reviewed — it gets waved through as "seems to work". 3. Always give a verification path. Put the build/test command in the prompt so the agent catches its own mistakes. Then add that these are not AI-specific rules but ordinary engineering discipline — the agent just makes them matter more, because writing code got cheap while understanding it did not.

Question 3

The agent left a task half-finished and said "done". What do you do, and what do you put in place so it doesn't recur?

Accepted Answer

Answer in two layers: immediate response plus systemic fix. Immediately: point out concretely what was not done and continue. Trust the build/test result, not the word "done". Systemically: take the definition of "done" out of the prompt and automate it — In CLAUDE.md: which commands must be run after every change. A hook: format/lint runs automatically after a file edit. CI: build and tests as a mandatory gate on the PR. Put the core idea plainly: the agent saying "done" is a claim, not a gate. Machines put up the gates.

Anti-pattern	Why it is a problem	Instead
"Improve the code"	"Good" is not measurable — the agent makes arbitrary changes	"Replace the nested ifs in this function with early returns"
Dumping the whole repo into context	Signal is diluted, cost rises	Naming 2-3 relevant files
Five tasks in one prompt	Half stays unfinished, review becomes hard	One task → verify → next
Fixing a wrong result by hand	The cause remains — it repeats next time	Recording the cause in CLAUDE.md or a skill

Prompting and supplying context

📚 Sources and documentation