Skip to content

Compare two production prompts

The Week 1 loop keeps a short tool contract for a model, the CONTRACT text in demo.py. A production coding agent sends much more: a role, working rules, a permission policy, a stopping rule and a schema for every tool. Two open-source coding agents publish the code that builds that text under the Apache-2.0 licence: Codex CLI and Qwen Code. In this activity you read the same four parts in both, at fixed commits, and ask the same two questions of every sentence you pick: what does it make the model do, and what, if anything, enforces it?

You read the original files on GitHub. This page links them and quotes only a few words, always naming the project; it does not copy the files. Facts about the files come from two reading pages, one for Codex CLI (tools/codex-base-instructions; as_of: 2026-10-09; Source 1; Source 2; Source 3) and one for Qwen Code (tools/qwen-code-system-prompt; as_of: 2026-10-09; Source 1; Source 2; Source 3; Source 4; Source 5; Source 6; Source 7). Neither agent's files are the complete prompt a release sends at run time, and this page does not rank the two products.

Purpose

Optional, about 45 minutes. It earns no marks. It extends the notes' section on reading a production agent's instructions and replaces the shorter single-file reading. Parts 1-4 need only a browser. Part 5 is a written plan.

Before you start: your Week 1 run() passes its checks, or you have read its five steps in the Week 1 notes. You can name its three tools and its two stop reasons.

AI use: red. Write your answers yourself; the point is your own reading.

Output: one table for Parts 1-4 and a short Part 5 plan, for your own notes. Nothing is handed in.

The files

Part Codex CLI, commit 2351d9e Qwen Code, tag v0.25.0 (commit 6788c03)
1. Role and instructions default.md: the opening paragraph and capabilities list, "Task execution", "Validating your work" prompts.ts: getDefaultCoreIdentitySentence, "Core Mandates", "Software Engineering Tasks"
2. Tools and schemas the apply_patch example in "Task execution"; plan_spec.rs for update_plan "Using Your Tools" in prompts.ts; edit.ts for edit; todoWrite.ts for todo_write
3. Safety and permission the approval sentence in the capabilities list; "Validating your work"; the rules that begin NEVER or Do not "Denied Tool Calls", "Respect Tool Decisions", "Executing actions with care", the sandbox sections
4. Stopping and plans the first paragraph of "Task execution"; "update_plan" under "Tool Guidelines" "Final Reminder"; the todo_write description in todoWrite.ts

Open both Codex CLI files, the base instructions default.md and the tool definition plan_spec.rs, from the links on its reading page; the Qwen Code files are linked in the table and on its reading page.

default.md is Markdown: read it as it stands. prompts.ts is TypeScript that builds the prompt. Text between backticks is what the model receives, and ${...} inserts a value, often a tool name such as ${ToolNames.EDIT}; the names are listed in tool-names.ts. Which sections appear depends on the interaction mode, the sandbox configuration and whether the directory is a Git repository, and an environment variable can replace the whole default base prompt with a file. (tools/qwen-code-system-prompt; as_of: 2026-10-09; Source 1; Source 2; Source 3; Source 4; Source 5; Source 6; Source 7) Read the interactive default.

Record

Use one row per sentence or rule. Pick at least two per part, one from each agent.

Part Agent Section and a few words What it makes the model do What enforces it Where you saw that

For what enforces it, choose one: the schema (a malformed call is rejected before the tool runs); the tool's own code (it checks and returns an error text to the model); a runtime permission or sandbox outside the model; or nothing visible. Write "cannot tell" when you did not open the code that would decide, and say which file you would need.

Part 1: role and instructions

  1. Find the sentence in each file that says what the agent is and what its goal is. Which words could change a choice the agent makes on a dashboard repair, and which only name it?
  2. Find each agent's rule for checking work after a change. The Codex CLI file ties when to run tests and lint to the approval mode; the Qwen Code file asks for the project's own checks before reporting a change complete, and for an honest report when a check failed or was not run. (tools/codex-base-instructions; as_of: 2026-10-09; Source 1; Source 2; Source 3) (tools/qwen-code-system-prompt; as_of: 2026-10-09; Source 1; Source 2; Source 3; Source 4; Source 5; Source 6; Source 7) For each, describe a run in which the agent reports a change without having run a test. Which field in your Week 1 completion.json would show that case, and with what value?

Part 2: tools and schemas

  1. Compare update_plan with todo_write: required and optional fields, the allowed status values, and where "one step in progress" is written. In todoWrite.ts, read validateTodos: list what it checks, and say whether it checks that limit. For Codex CLI, can you tell from the files you opened? Mark "cannot tell" where you cannot.
  2. In edit.ts, read the edit tool's description, its parameter schema, validateToolParamValues and calculateEdit. Sort each rule into required by the schema, checked by code with an error returned to the model, or only asked in the description. Start from two: "at least 3 lines of context" is only asked, while a second match without replace_all fails with an error that gives the count. (tools/qwen-code-system-prompt; as_of: 2026-10-09; Source 1; Source 2; Source 3; Source 4; Source 5; Source 6; Source 7) What does the model see on its next turn when it breaks each kind?
  3. The Codex CLI file names apply_patch and shows one call. Did you open its schema? If not, name what you would need to read before you could sort its rules the same way.
  4. Sort your own loop the same way: what does checked reject, what does tool refuse, and what appears only in the CONTRACT text of demo.py?

Part 3: safety and permission rules

  1. In the Qwen Code file, "Respect Tool Decisions" says the runtime enforces tool permissions, while "Denied Tool Calls" asks the model not to reach a denied action another way, through a shell, a generated script or an alias. (tools/qwen-code-system-prompt; as_of: 2026-10-09; Source 1; Source 2; Source 3; Source 4; Source 5; Source 6; Source 7) Why might a product need that request as well as the runtime check? For your loop, name one route that tool closes and one that only the environment the agent runs in closes (the dedicated directory or container of the safety practices).
  2. The Codex CLI capabilities list refers to a "Sandbox and approvals" section that the file itself does not contain. (tools/codex-base-instructions; as_of: 2026-10-09; Source 1; Source 2; Source 3) What does that tell you about where the rest of the prompt comes from, and what would you need to read next?
  3. Pick one sentence from "Executing actions with care" or a sandbox section in the Qwen Code file. Describing a sandbox to the model does not create one: which control outside the prompt would have to exist for the sentence to be true? Compare with the permission comparison in the notes.

Part 4: stopping and plans

  1. Both files ask the agent to keep going until the request is resolved; the Qwen Code file also names an exit, reporting the specific blocker. (tools/codex-base-instructions; as_of: 2026-10-09; Source 1; Source 2; Source 3) (tools/qwen-code-system-prompt; as_of: 2026-10-09; Source 1; Source 2; Source 3; Source 4; Source 5; Source 6; Source 7) Neither sentence can stop a loop. Which code stops your run(), and what would a production agent need in place of your step_limit?
  2. A plan step marked completed is the model's own claim. Which observation would you need before you accept it? Compare your answer with question G of the session dissection.

Part 5: change one part for your own project

Choose one sentence or schema rule from either file that you would change or add if the agent were working in your own project repository. Examples: name the acceptance command instead of "the project's own test commands", or require a passing check after the last write before any final reply. Write three things:

  • The change and where it belongs: the product's base prompt, a repository instruction file (Week 3), a tool schema, or controller code. If a rule can be checked in code, say why you would or would not still put it in the prompt.
  • The predicted effect, as something a session record would show: which call appears, the stop reason and the check status.
  • The verification: which line of a record, or which check, would show the effect.

Keep this part a written prediction. The scripted proposer in the Week 1 demo.py never reads CONTRACT, so adding your sentence there changes nothing you can observe in scripted practice. Write the record you would expect with and without the change: did a verify call follow the last write, and what were the stop reason and the check? If you later try the sentence in a real agent session, one run of each version is one observation, not a rate; report it that way. Either way, also say which part of your loop already reports the truth regardless of the prompt: last_check stays not_run or check_failed whatever the model writes.

Common mistakes

Mistake How to notice it Small correction
Treating a sentence as a guarantee Your "what enforces it" column says the prompt Name a schema, a code check or a runtime control, or write "nothing visible"
Guessing about code you did not open You wrote "enforced" for a rule whose checker you never read Write "cannot tell" and name the file to read
Reading prompts.ts as one fixed text You quote two sandbox sections as if both were sent Pick one branch and say which condition selects it
Copying long passages into your record Your table holds whole paragraphs Give the section and a few words; link the pinned file
Judging one product better Your answer ranks the agents Compare what each rule does and what enforces it

All files are plain text on GitHub and can be read with a screen reader or keyboard; no diagram or colour is needed for any step.