Discuss a projectRU
Module 03

Module 3. Give an AI agent a task you can review

Create a small project spec, give the agent context, and turn a vague request into a reviewable change.

A model cannot know what “good” means for your product until you show it the context and criteria. A very long prompt does not replace clear requirements. This module separates persistent project context from small work items.

Context and task are different

Persistent context explains what the product does, who it serves, which decisions are settled, and which actions are risky. Keep it with the project, for example in README.md or a supported project-instructions file.

A work item asks for one change: add a service selector, fix form submission, or handle an error state. It should be narrow and have acceptance criteria.

Do not put secrets, real customer requests, or vague rules such as “always change everything” in project instructions. Context helps an agent navigate; it should not grant unnecessary authority.

A task format that is easy to review

  1. Context: which files and behavior matter?
  2. Outcome: what can the user do after the change?
  3. Constraints: what must stay as it is?
  4. Acceptance criteria: which observable cases must pass?
  5. Verification: how will you run and inspect the change?

Example

Add a request form to the existing service page: service, name, and contact. Use the current styles and do not change navigation. Validate required fields before submission and show a hint beside the field that needs attention. Show confirmation only after a successful response. If the server returns an error, do not show success and let the user retry. First inspect the related files and propose a short plan. After the plan, change only those files, show the diff, and explain how to check success, a missing contact, and a request error. Do not connect payments or a live CRM yet.

A useful signal is that the agent can name the files, states, and verification steps. If it only says “I’ll handle everything”, ask for a plan before allowing changes.

The work loop

read context → ask for a plan → make one change → inspect the diff
      ↑                                          ↓
save the decision ← check the journey ← run the project

Create a Git checkpoint or the environment’s equivalent before a risky step. After each step, inspect the changed area; the agent’s summary is not proof that the result works.

When the agent goes off track

Stop the chain of edits. State which criterion failed and which files changed unexpectedly. Restore a stable version or undo the bad diff, then repeat with a smaller task. “Make everything beautiful” does not set a boundary.

Practice

  1. Create a README.md or project instructions file with the audience, journey, chosen environment, forbidden secrets, and run command.
  2. Use the agent task template.
  3. Ask the agent to change only a button label and request a plan first.
  4. Review the file list and diff.
  5. Repeat with one acceptance criterion from your brief and run the result.

Save: project context plus one bounded task with criteria and a verification step.

Self-check

  • Can another person distinguish project rules from today’s task?
  • Are the constraints and change area specific?
  • Is there a check that does not depend on trusting the model’s report?