Training: how to write good prompts/tasks

Training in how to write good prompts and tasks is the L2 investment in the fundamental skill that determines whether AI agents are useful or frustrating. A developer who writes clear, well-contextualized task descriptions gets dramatically better results than one who writes vague, assumption-laden requests - from the same model, with the same tools, on the same codebase. The quality of agent communication is the highest-leverage individual skill in AI-augmented development, and it is teachable.

The skill is not about knowing magic words or memorizing prompt frameworks. It is about three underlying capabilities: decomposing work into appropriately-sized, well-defined units; providing the context the agent needs to do the work correctly; and specifying the success criteria clearly enough that the agent (and the developer reviewing the output) can determine whether the task is done. These are skills that experienced tech leads apply when assigning work to junior developers - the same skills apply when assigning work to AI agents.

By August 2026 the skill had a better name than "prompt writing", and the better name changes what the training has to cover. Simon Willison's "More than just code review" (August 22) states it as the ability to "confidently instruct them... and then confidently verify," and is explicit that verifying is not reading every line. Those are two halves of one competence, and most training programmes teach only the first. A developer who writes an excellent task specification and then reads 400 generated lines top to bottom has not learned the skill; they have moved the bottleneck. The verification half is its own curriculum: which signals to trust, which checks are cheap enough to run early and which are expensive enough to reserve for the end, and what evidence is sufficient to say a thing works without having read it.

The most teachable piece of that is writing stop conditions. Addy Osmani's "Practical Loop Engineering" (August 14) separates goals - bounded and deterministic, of the form "Lighthouse at least 92 and LCP under 1.8s" - from loops, which are cron-shaped and expire after seven days. A goal written that way is verifiable without reading anything, which is precisely the skill Willison is naming. Osmani's other standing rule belongs in the same lesson: never let a drafting agent approve its own work, use a separate verifier. Both are concrete enough to practise in an exercise, which is more than can be said for most prompt-engineering material.

What makes prompt writing teachable is that the quality signal is fast and visible. A developer who writes a vague task prompt sees a bad result in 30 seconds. A developer who rewrites it with better context and clearer scope sees a better result in 30 more seconds. This fast feedback loop means that people who engage seriously with the skill improve quickly. The training intervention is not about teaching rules - it's about creating structured practice opportunities where people get the feedback loop, compare good and bad approaches, and develop the pattern recognition for what makes a task description effective.

Training at L2 is typically informal: a workshop, a shared prompt library with examples, a regular "prompt review" in team standup where people share what worked and what didn't. At L3, this becomes more systematic - formalized training modules, onboarding curriculum, and peer coaching structures. But the L2 investment in formal training is the first time the organization acknowledges that this is a skill, not just an intuition, and that it's worth investing in developing it systematically. What that looks like at scale is worth borrowing from: Zalando's August 2026 snapshot describes enablement as a standing programme with countable attendance rather than a launch email - a weekly one-hour guild built from 20-minute slots and recorded, guided hackathons running two to three days with small teams, hands-on labs taking cohorts of around twenty through repeated sessions, and monthly topic-specific trainings. The formats are unremarkable. What makes them a programme is that each has a cadence, an owner and a number you can report.

Prompt quality training has a disproportionate return on investment because it affects every developer's AI output:

• Multiplies every developer's AI investment - a developer who spends 20% of their time on AI-assisted tasks and writes mediocre prompts is getting perhaps 40% of the value available to them; the same time investment with good prompt skills might yield 80% of the available value; training doubles the return on an existing investment
• Reduces senior debugging burden - a significant portion of the "senior debugs AI code" anti-pattern is caused by developers with poor prompt skills generating code with good tools; prompt training upstream reduces the debugging load downstream
• Creates a common language for AI collaboration - when a team has shared vocabulary and shared standards for task specifications, developers can review each other's prompts, suggest improvements, and build on each other's patterns; without shared training, each developer develops idiosyncratic approaches that don't transfer
• Reveals the task decomposition skill gap - many developers who struggle with prompt writing are actually struggling with task decomposition - the ability to break work into well-defined, appropriately-scoped units. Prompt training surfaces this gap and the skill development addresses it for both human and agent collaboration
• Accelerates the transition to L3 - the prompt skills developed at L2 are the foundation for the more sophisticated task specification needed at L3, where agents run more autonomously and the cost of a poorly specified task is higher

1. Start with task decomposition, not prompt syntax - before teaching anyone specific prompt patterns, ensure the team can decompose work into well-defined units. A task like "improve the performance" is not a prompt failure - it's a decomposition failure. Practice: take a vague task description and break it into three or four specific, independently-testable sub-tasks. This is the foundation.
2. Build a "before and after" prompt library - collect real examples from the team of vague prompts that produced bad results and improved prompts that produced good results for the same task. A dozen of these examples, organized by task type (implement a feature, write a test, refactor a function), is more effective training material than any abstract guide.
3. Run a weekly prompt review - add 10 minutes to a team meeting for one developer to share a prompt they wrote that week, the result it produced, and either what they'd do differently or why they were satisfied. Over time this creates a shared vocabulary for prompt quality and a culture of continuous improvement.
4. Create a task specification template - design a simple template for common AI task types: [Task Type] | [Context: what the agent needs to know] | [Scope: what's included and excluded] | [Success criteria: how will we know it's done] | [References: existing files or patterns to follow]. A template reduces blank-page anxiety and ensures the most common context omissions are caught.
5. Train specifically for high-value task types - don't try to teach prompt writing in the abstract. Focus on the three or four task types that represent most of the team's AI usage: "write unit tests for this function," "implement this API endpoint following existing patterns," "refactor this class to improve X." Deep practice on common task types is more valuable than shallow coverage of all cases.
6. Measure training impact - before and after training, ask developers to rate their confidence in writing effective AI prompts (1-5 scale) and measure agent error rates on their code. If training works, confidence should rise and error rates should fall. Simple before/after measurement creates accountability and evidence for the investment.
7. Teach stop conditions as a written artifact - run an exercise where developers convert a vague quality expectation into a bounded, deterministic goal that a machine can evaluate: a threshold on a performance metric, a coverage floor, a named test suite passing. Then have them state how they would confirm the goal was met without reading the diff. This is the verification half of the skill, and it is the half that decides whether the throughput gain survives contact with review.
8. Practise verifying without reading every line - take a completed agent task and ask the developer to reach a defensible verdict using evidence rather than a line-by-line read: run the checks, look at the right signals, decide ship or block, and be able to say why. Pair the exercise with the standing rule that a drafting agent never approves its own work. The goal is not lower rigour; it is rigour that scales past the point where reading everything stops being possible.

Teaching prompt frameworks instead of prompt thinking. There are dozens of "prompt engineering" frameworks online - RISEN, COSTAR, etc. Teaching a framework is not the same as teaching the skill. Frameworks are scaffolding for people who don't yet have the underlying intuition; they should be temporary support, not the permanent goal. The goal is developers who can write effective task specifications without consulting a cheat sheet. The evidence has hardened against the magic-words model of this skill: Anthropic removed more than 80% of Claude Code's system prompt for Claude 5 with no measurable quality loss, and Addy Osmani's August 2026 agent-file audit found that across 288 test runs, context files changed efficiency rather than correctness. More instruction is not reliably better instruction. Teach people to write less and verify more.

Stopping the curriculum at the instruction half. A programme that teaches people to specify tasks well and says nothing about how to confirm the result produces developers who generate faster and then read everything, which is where the throughput goes to die. Verification is teachable in its own right - which signals are worth trusting, which checks are cheap enough to run early, what evidence is enough to say a thing works - and it belongs in the same course, not in a later one that never gets scheduled.

Making training a one-time event. Prompt writing is a skill that develops through practice over time, not a body of knowledge that can be transferred in a single workshop. A two-hour workshop without ongoing practice and feedback will produce short-term awareness and long-term reversion to old habits. Design training as a 6-8 week program with weekly practice exercises, peer feedback, and visible measurement.

Focusing on individual prompts rather than prompt systems. The highest-value prompt training outcome is not better individual prompts - it's better prompt templates and patterns that the whole team can reuse. Train developers to think in terms of "what prompt pattern works for this category of task?" and encourage them to contribute their discoveries to the shared template library.

Ignoring the context provision skill. Many prompt training programs focus on how to phrase the task request and ignore how to specify the context the agent needs. Context provision is at least as important as task phrasing. Training should explicitly cover: how to identify what context an agent needs for a given task, where to find that context in the codebase, and how to include it efficiently without overwhelming the context window.

Not connecting training to team-specific conventions. Generic prompt training teaches general principles. It becomes dramatically more valuable when combined with team-specific content: "for our codebase, when writing prompts about the payment service, always reference the PaymentProcessor interface and include the error handling requirements from CLAUDE.md section 3." Team-specific prompt training requires team-specific context engineering to have happened first.