Talking to Agents: Prompt Engineering That Actually Works

Summary

The single biggest jump in results does not come from a better model, it comes from a better brief. Talking to an agent well is a management skill: you set clear rules, frame the work for quality over shortcuts, invite disagreement, and hand over a spec instead of a vibe. This lesson gives you the concrete patterns that separate frustrating sessions from agents that nail it first time.

What you will learn

You will learn to write axioms (non-negotiable rules), to use the unlimited-budget framing that stops an agent cutting corners, to explicitly ask for pushback so the agent catches your mistakes, and to convert a vague request into a spec sheet with goal, context, constraints and acceptance criteria.

Prerequisites

A working Claude Code or Codex setup from the previous lesson. You should also remember the context lessons: a great prompt is partly about giving the right context, not just the right words.

The problem

The classic failure is the one-line wish: "build me a website". The agent has to guess the audience, the stack, the design, the scope and the definition of done, and it guesses wrong. Then you blame the AI. The real issue is that you briefed a contractor in five words and expected a finished house. Good prompting removes the guessing.

Axioms: state the rules once

Axioms are non-negotiable rules you state up front so the agent stops re-deciding them every task. Instead of correcting the same thing ten times, you write it as a rule. "Always use TypeScript. Never use em dashes. Every new feature needs a test. Never commit secrets." These read like a contract, and the agent treats them as constraints rather than suggestions. In Course 2 you will move these into a permanent CLAUDE.md, but even pasted at the top of a session they sharply raise consistency.

• Phrase rules as absolutes: "Always...", "Never...", "Every... must...".
• Cover style, stack, testing, security and tone - the things you keep correcting.
• Keep them short and unambiguous; an agent follows a crisp rule better than a paragraph of nuance.

The unlimited-budget framing

Agents, like junior staff, default to the fastest acceptable answer. If you want world-class work you have to say so. Framing the task as if budget and time are unlimited - "do the right thing for the long-term health of this project, not the easy thing; do not cut corners" - measurably raises quality, because it licenses the agent to add tests, handle edge cases and refactor instead of bolting on the quickest fix. It sounds soft, but it reliably shifts output from "technically works" to "actually good".

Ask for pushback

By default an agent is agreeable and will cheerfully implement a bad idea. The fix is one sentence: "Before you start, tell me anything wrong with this plan, anything I have missed, and a better approach if one exists." This flips the agent from order-taker to advisor. It will catch missing requirements, point out security holes, and suggest simpler designs. Some of the most valuable moments in agentic work come from the agent disagreeing with you - but only if you explicitly give it permission to.

Step by step: write a spec sheet

A spec sheet is the difference between a vague wish and an executable brief. It does not need to be long. Four parts are enough, and writing them forces you to make the decisions the agent would otherwise guess.

• Goal: what should exist when this is done, in one or two sentences.
• Context: the stack, the relevant files, examples to follow, and anything the agent cannot infer.
• Constraints: your axioms plus task-specific limits (no new dependencies, must work on mobile, and so on).
• Acceptance criteria: a concrete checklist that defines "done" so both you and the agent know when to stop.

## Goal
A contact form on the landing page that emails me submissions.

## Context
- Stack: this Astro project, existing styles in src/styles.
- Follow the button style already used in the hero section.

## Constraints
- TypeScript only. No new UI library.
- Never expose the email API key in client code.
- Add a test for the form validation.

## Acceptance criteria
- [ ] Form validates name and email before submit.
- [ ] Submitting shows a success message.
- [ ] The validation test passes.

Typical mistakes

The recurring errors: the one-line wish with no spec; never stating axioms so you correct the same things forever; accepting the first answer instead of asking for pushback; and over-stuffing the prompt with irrelevant context, which triggers the performance cliff from lesson one. Tight, structured briefs beat long rambling ones.

Business ROI

Briefing skill is the multiplier on everything else. The same agent and model produce mediocre or excellent work depending entirely on the brief, and a good spec sheet often turns three frustrating rounds into one clean delivery. For a founder, learning to write a tight spec is the cheapest possible way to triple the value you get from every AI subscription you already pay for.

Checklist

Before moving on, make sure you can produce each of these on demand, because every later lesson assumes you can brief an agent well.

• A short list of axioms for your own projects.
• A task framed for quality with the unlimited-budget and pushback lines.
• A four-part spec sheet for a real feature.
• An honest sense of when your prompt is too long, not too short.

Resources

Save your axioms somewhere reusable - you will paste them into a CLAUDE.md in Course 2. The Agent Task Brief template in the resource library is a ready-made spec-sheet skeleton you can copy. Next, you put all of this to work building a real project.

Your task

Take the project idea you chose two lessons ago and write a full spec sheet for its first feature, including your axioms, the unlimited-budget framing and the pushback request. Hand it to your agent and notice how much sharper the result is than a one-line prompt would have been.

Next lesson

You can brief an agent. Now you build something real. The next lesson scaffolds an actual project, starts a dev server so you can see it in the browser, and puts it under version control with Git and a private GitHub repo.