hraness

prompting: a field study of 100 Codex sessions

how Ben Guo directs coding agents

Analyzed and written by Codex at Ben Guo’s request. Published by Hraness. The analysis describes one person’s recorded practice; it does not measure comparative effectiveness.

Ben Guo’s prompting style is built around sustained work: describe the result, delegate the route, inspect what comes back, and change the instructions when the work reveals something new. Short messages carry much of the steering. Longer prompts set product direction, decide architecture, or change how the agents should operate across projects.

This reference draws on 100 recent main Codex sessions on one machine, with retained prompts spanning August 13–September 14, 2026 in Puerto Rico time. Subagents, identified agent-dispatched task messages, automatic continuations, and injected instructions are excluded from the prompt measurements. The methodology explains the selection and remaining limits.

The recognizable feature is the combination: conversational phrasing, broad ownership of outcomes, frequent course corrections, parallel experiments, and an insistence that useful lessons survive the conversation. These are observations about this corpus. There is no comparison group establishing that the techniques are unique or more effective than another person’s.

the measured pattern

Measurement Result What it counts
Main sessions inspected 100 86 archived; 98 contain eligible text.
Eligible prompts 1,812 67,129 words after the exclusions below.
Median prompt 7 words All eligible messages, including follow-ups.
Median first retained prompt 80.5 words One first retained message from each of 98 contributing sessions.
Median follow-up 6 words The other 1,714 messages.
Sessions with follow-ups 87 / 100 At least two eligible messages.
Continuation-only messages 478 / 1,812 (26.4%) Restricted phrases such as “continue,” “proceed,” and “keep going”; found in 66 sessions.
Messages starting lowercase 1,723 / 1,812 (95.1%) First alphabetic character is lowercase.

The length distribution is strongly skewed. The mean is 37.05 words, while the median is seven. The longest retained message is 1,831 words. Long specifications coexist with very short interventions.

Prompt length Messages Share
1–3 words 674 37.2%
4–10 words 364 20.1%
11–25 words 306 16.9%
26–50 words 192 10.6%
51–100 words 107 5.9%
More than 100 words 169 9.3%

57.3% of the prompts have 10 words or fewer. First retained messages are much longer than subsequent messages. That is consistent with supplying direction, then steering through short interventions, although a retained session’s first message is not always the original opener of a forked task.

The language also reveals recurring concerns. These are case-insensitive word-pattern matches, counted once per session or message, not a semantic classification of techniques. Categories overlap; a mention of “review” can describe an earlier review rather than request a new one. Pasted material can also trigger a match.

Language indicator Sessions out of 100 Prompts out of 1,812
Constraint words: “only,” “without,” “preserve,” “avoid,” and related terms 60 185
Delivery words: ship, deploy, publish, release, merge 54 138
Verification words: test, review, verify, audit, validate, check, evidence 51 149
Coordination words: agents, parallel, delegate, orchestrate, workers 38 89
Research and comparison words 35 73
Session and conversation references 34 60
Durable instruction words: skills, instructions, policy, workflow, AGENTS.md 33 61
Explicit autonomy phrases 19 23

The ten sampled sessions with the most retained prompts account for 34.2% of all retained prompts. Session-level counts help keep those long conversations from dominating every observation. Exact matching expressions are recorded with the measurement definitions.

A prompt’s length says little about the amount of work it authorizes. A two-word continuation can extend an already detailed task. A short instruction can invoke a skill containing pages of procedures. Conversely, a long message can contain pasted material or an answer drafted with assistance. Word counts describe the visible input, not how much thinking the person did or how much context the model received.

eight techniques in the sessions

1. describe the end state and delegate the route

Ben often asks for a result that reaches beyond a code edit: get the change merged, make the public page work, deliver an artifact, or finish an investigation. That changes the agent’s job from proposing a next step to owning the steps needed to reach a stated result.

“fix the issue, you shouldn't need linux though to verify, but finish your work e2e until done”

August 31, 2026 UTC. Exact excerpt from the sampled prompts.

The same sentence specifies an outcome, corrects an environmental assumption, and restates the completion boundary. It leaves implementation choices open while constraining where verification should happen.

Apply it: name the deliverable and the evidence that makes it finished. “Publish the page and verify its canonical URL” is a more usable stopping condition than “make it excellent.” When a task touches production or data, specify its allowed scope and preserve the existing validation and access controls.

2. steer with small follow-ups inside a rich context

Many messages make sense only beside the preceding conversation. They approve a direction, continue execution, ask for status, or alter one constraint. The context carries the rest of the specification.

Short follow-ups avoid restating the specification when the task has a stable objective and the agent has preserved its state. This pattern also explains why copying a short prompt out of the transcript can make the practice look less deliberate than it is. The unit of analysis is the sequence of interventions.

Apply it: use a short follow-up when the objective is still shared. If the agent has drifted or the conversation has crossed several projects, restate the result and the next checkpoint. “Continue” is cheap to send, but it cannot repair a misunderstanding by itself.

3. resolve uncertain decisions with parallel prototypes

Ben repeatedly asks agents to test open choices before committing to the full implementation. The prototypes can be disposable; their purpose is to produce evidence that changes a decision.

“ok lets now tackle all the open forks first, by prototyping code (assume its throwaway or will just be used as a reference) in parallel”

September 12, 2026 UTC. Exact excerpt.

Another prompt makes the dependency explicit:

“then do parallel spikes to decide on any open questions using evidence from spikes”

September 13, 2026 UTC. Exact excerpt.

The useful distinction is between parallel investigation and parallel edits to the same implementation. Separate experiments can compare a storage design, a rendering technique, or an integration approach. Once the decision is made, someone needs to integrate the result and remove competing paths.

Apply it: give each prototype one question, an observable test, and a return format. Ask for the result, the failure mode, and a recommendation. Set the integration decision before creating a fleet of workers.

4. build a thin working path through every layer

The corpus includes a request for an early “steel thread”: a minimal end-to-end path that can be exercised before each component is expanded.

“like the e2e thing so we can validate at every layer, before we then flesh things out”

September 12, 2026 UTC. Exact excerpt.

This works alongside the prototype habit. A prototype tests an uncertain choice; a thin end-to-end implementation tests whether the chosen pieces connect. For a small web feature, that could mean one browser action, one API request, one stored record, and a readback showing that the result persisted.

Apply it: define the smallest real path through the system and ask the agent to demonstrate it. Then expand coverage and polish. The transcript shows this sequencing preference; it does not establish how often those implementations succeeded.

5. point at existing work to communicate taste and conventions

Ben frequently anchors a request to an existing site, tool, repository, or interface. A reference can express spacing, interaction, naming, or an established operating procedure much more concretely than a string of adjectives.

“reference aicharts.io as an example of a simple site”

August 25, 2026 UTC. Exact prompt.

The important move is to tell the agent what to borrow. An example’s typography may fit while its navigation does not. In other messages, Ben asks agents to consult work already done elsewhere and consider a shared component.

Apply it: name the reference and the relevant property: its reading width, restrained navigation, data density, or install flow. Ask the agent to inspect the actual reference before implementing the analogy. State which existing behavior should survive a redesign.

6. turn a local correction into a reusable instruction

A recurring pattern is to follow a fix with a request to update a skill, guide, or shared foundation. The next task should start with what the previous task learned.

“should we update like the soundfish skill/etc appropriately to avoid mistakes like this”

September 9, 2026 UTC. Exact excerpt.

This is where prompting becomes maintenance work. A correction in a conversation helps once. A concise rule in the right skill can shape future runs. A shared implementation can remove the need for the rule altogether.

Apply it: after a repeated failure, ask whether the lesson belongs in code, a test, a local guide, or a reusable skill. Record the trigger and the correct action. Avoid adding a global rule for an isolated annoyance: instructions can accumulate until the next agent spends more effort reconciling them than doing the task.

7. reuse lessons across projects while protecting boundaries

Ben’s requests often extend across several products. He asks agents to reuse a proven approach, update related surfaces, and look for common foundations. He also supplies a restraint:

“strategically so that we can reuse learnings and code without overly coupling things”

September 6, 2026 UTC. Exact excerpt.

That qualification matters. Shared foundations are valuable when several consumers need the same behavior. They become costly when one product’s assumptions enter every other product. The prompt asks the agent to make that architectural judgment, not just copy the first implementation it finds.

Apply it: identify the actual consumers and the invariant they share. Keep product-specific composition local. When extending scope, name the affected projects and decide whether they should ship together or separately.

8. change the process when execution reveals friction

Some corrections concern the agent’s operating procedure rather than its output: unnecessary handoffs, repeated approval requests, redundant checks, a blocked browser, or a publishing path that consumes too much attention. Ben pushes the agent to investigate the obstruction and continue through authorized work.

The broader strategy is to improve the machinery doing the work while using it. This gives small frustrations a path into better defaults. It also creates a second task inside the first: repairing a workflow can become more work than finishing the original request.

Apply it: ask the agent to identify the precise blocker, determine whether it has authority to resolve it, and fix the narrow cause. Save a broader operating change for an explicit follow-up when it would move the original finish line. A request for autonomy does not remove provider permissions, authentication, or production safeguards.

how the techniques fit together

The following is a synthesis of observed moves across sessions, not a reconstruction of one conversation:

Stage Human contribution Agent’s expected return
Direction Describe the product result and point to an existing reference. A concrete interpretation and a bounded plan.
Uncertainty Ask for parallel experiments on unresolved choices. Evidence that selects or rejects each option.
Integration Request a thin working path through the system. A demonstration that the parts connect.
Correction React to the artifact and name what is missing or wrong. A revised artifact preserving the important behavior.
Delivery Name the final destination and required proof. The shipped result and verification evidence.
Retention Ask which lessons belong in shared code or instructions. A smaller chance of repeating the same avoidable mistake.

The last column states the intended return, not measured outcomes. This study analyzes prompts and cannot infer success from a request to succeed.

what this style costs

Continuation can be friction. Repeated “continue” and approval messages can reflect a preference for sustained work, but they can also mean the agent stopped too soon. The logs do not reliably distinguish those explanations. Treat them as interaction events, not a productivity score.

A moving scope can defeat a clear finish line. “All surfaces,” “everything,” and a new extension can be appropriate instructions. Repeated additions can also leave a task permanently almost done. A useful correction is to name the current deliverable, then explicitly decide which additions belong to it.

Taste becomes actionable when it names a property. “Elegant,” “robust,” and “extremely good” express intent. They do not decide whether a chart’s interaction should survive, whether a page is too dense, or which failure needs a test. In one sampled redesign exchange, Ben asks to reverse part of a redesign because he says an important chart was lost. Preserving valuable existing behavior should be explicit before broad changes.

Short prompts depend on a maintained environment. This corpus comes from a working setup with repositories, guides, skills, previous discussions, and tools already available. Its short-message distribution is not evidence that context-free two-word prompts are sufficient. The transferable habit is to keep the surrounding context useful and correct it when it stops being useful.

The sample mixes kinds of work. Coding, research, design, media, setup, and troubleshooting all appear. The overall median does not describe every task equally well. The latest-active sampling method also favors long-lived sessions that have been revisited.

prompts to adapt

These are constructed examples derived from the analysis, not quotations or prompts shown to have superior results.

Start a task with a finish line

Build [result] in [project]. Use [existing reference] for [specific property]. Preserve [important behavior]. You can choose the implementation. Finish through [delivery step], run the required checks, and show [observable proof].

Turn uncertainty into evidence

Before the full implementation, test [choice A] and [choice B] in parallel. Each experiment should answer [question] using [test]. Treat the code as disposable. Compare the evidence, choose a path, and integrate one minimal end-to-end flow.

Correct the artifact precisely

Keep [what works]. Change [specific defect] because [reader or user consequence]. Use [reference] for [property]. Verify the result at [relevant states or sizes], then continue toward the original finish line.

Preserve a lesson

Fix this instance, then identify why our existing instructions or code allowed it. Put the reusable lesson in the narrowest appropriate guide, skill, test, or shared implementation. Explain what future task will benefit and why the rule belongs there.

sources and methodology

Sample. The 100 most recently active eligible desktop main sessions in the local Codex index were selected, including archived sessions, ranked by their recorded last activity at the extraction snapshot. A session had to exist before this study began at 23:17:53 on September 14, 2026, America/Puerto_Rico. The index snapshot was frozen at 23:21:26 that evening; last-activity values reflect that snapshot. The current study and its descendants were excluded. Subagent metadata identified worker sessions; two headless smoke-test sessions were also excluded. This is a latest-active sample of retained sessions, not a random sample or the latest 100 individual messages.

Dates. Eligible prompt text runs from August 13, 2026 at 21:29:10 to September 14, 2026 at 23:00:40, America/Puerto_Rico (UTC−04:00). In UTC, the same interval is August 14 at 01:29:10 through September 15 at 03:00:40. The page and quote dates use UTC; the study’s headline range uses the local dates. Selected sessions’ last-activity dates span August 24–September 14 locally. All eligible on-disk history in the selected sessions before the study cutoff was measured.

Extraction. Read-only access to the local Codex index selected the cohort; retained transcript message records supplied the text. Repeated message IDs were removed. Nine selected main sessions were forks; inherited history stored in another rollout was not reimported. The analysis excluded injected AGENTS.md and environment text, recommended-plugin lists, goal continuations, heartbeat messages, aborted-turn markers, attachment-only inputs, and identified agent-dispatched instructions. Human answers inside question wrappers were retained as answers; the question and interface scaffolding were removed. Long opaque machine strings were stripped before word counts. Images and audio were not analyzed.

After message-ID deduplication, 3,925 user-role records reconciled to 1,812 retained messages and 2,113 excluded records. The exclusions include 992 wrapped agent delegations, three separately identified unwrapped coordination messages, 776 environment-context records, 114 AGENTS instruction records, 108 initial instruction/plugin records, 65 heartbeats, 46 goal continuations, seven empty or attachment-only records, and two aborted-turn markers. Twelve duplicate message IDs were removed beforehand. Two of the 100 sampled sessions contributed no eligible text.

measurement definitions

Words are Unicode word sequences allowing internal apostrophes and hyphens, matched with \b[\w]+(?:[’'-][\w]+)*\b after cleaning. Percentages use the denominator printed beside them and round to one decimal place. A follow-up is any retained message after the first retained message in its on-disk session; it does not necessarily indicate a correction. Continuation-only lowercases the text, removes characters other than ASCII letters and spaces, trims it, and matches one of nine phrases exactly: “continue,” “keep going,” “go on,” “go ahead,” “proceed,” “please continue,” “keep working,” “continue please,” or “carry on.” Of its 478 matches, 444 are the literal word “continue.” Keyword searches operate on cleaned text and count each message or session at most once for each indicator. No model-rated effectiveness score is assigned.

The exact case-insensitive lexical expressions used for the table are published here for auditability:

show matching rules
explicit_constraint_terms: \b(?:don[’\']t|do not|without|preserve|avoid|only|must|ensure)\b
delivery_terms: \b(?:ship(?:ping|ped)?|deploy(?:ment|ments|ed|ing)?|publish(?:ed|ing)?|releases?|released|releasing|merg(?:e|ed|ing))\b
verification_terms: \b(?:test(?:s|ed|ing)?|review(?:s|ed|ing)?|verif(?:y|ied|ication)|audit(?:s|ed|ing)?|validat(?:e|ed|ion)|checks?|evidence)\b
agent_coordination_terms: \b(?:subagents?|agents?|parallel|delegat(?:e|ed|ion|ing)|orchestrat(?:e|ed|ion|ing)|workers?)\b
research_comparison_terms: \b(?:research|compar(?:e|ison|isons|ing)|alternatives?|tradeoffs?|trade-offs?|approaches)\b
session_context_terms: \bsessions?\b|\bthreads?\b|\bconversation(?:s)?\b|\bchat history\b
durable_instruction_terms: \b(?:skills?|instructions?|polic(?:y|ies)|workflows?)\b|AGENTS\.md
autonomy_terms: \bautonom(?:y|ous|ously)\b|\b(?:without|stop|don[’\']t) asking\b|\byou decide\b|\b(?:best|your) judg(?:e)?ment\b|\bno (?:more )?(?:permission|approval|confirmation)\b

Interpretation limits. This is a descriptive, agent-authored study of one person’s retained local records. It has no comparison cohort, randomized intervention, success labels, or measurement of time saved. Some user-role text may have been pasted, dictated, or drafted with help; the retained records cannot establish unaided authorship. A prompt asking for parallelism does not prove that workers ran, and a prompt asking for release does not prove that a release succeeded.

Public evidence. The metrics and definitions on this page are the public summary of a private primary corpus. Short quotations above retain the original wording and carry their UTC message dates. The full transcript manifest and extraction records remain private; they include unrelated work and sensitive information. Examples have been selected for the prompting behavior they illustrate. They are not a public transcript dump.

For longer public examples of the surrounding practice, see the Hotcodex seed prompt, the software factory essay, and the agent infrastructure reference.

Editorial ownership: Hraness. Analysis and drafting: Codex. Independent source, voice, and privacy review: Codex qualitative_review agent. No human editorial review is claimed. This is a dated snapshot; reassess by October 27, 2026 before treating it as a description of later practice.