Field notes — the blog

Notes from inside the system.

Specific write-ups on decisions that moved the needle: architecture trade-offs, delivery pipelines, and leading engineers who are better than you at their part of it.

              {{ totalPosts }} notes
              {{ totalMinutes }} min total
              Monthly
            

/

                Latest
                {{ featured.date }}
                {{ featured.cat }}
                {{ featured.read }}
              

{{ featured.title }}

{{ featured.excerpt }}

Read the note →

// before → after
{{ row.text }}

{{ listHeading }}

{{ resultCount }}

                {{ post.cat }}
                {{ post.date }}
              

{{ post.title }}

{{ post.excerpt }}

{{ post.read }}

Nothing matches that.

Try a different term, or clear the filters.

The architect's dispatch

One note a month. Nothing else.

A single deep write-up on a system I worked on: the trade-off, the numbers, what I'd do differently.

            {{ article.cat }}
            {{ article.date }}
            {{ article.read }}
          

{{ article.title }}

{{ article.excerpt }}

{{ part.text }}{{ part.text }}{{ part.text }}

{{ b.alt }} — {{ b.caption }}

{{ b.label }}

{{ h.text }}

{{ cell.text }}

{{ b.label }}

{{ link.label }} {{ link.note }} {{ link.host }}

{{ b.caption }}

{{ b.text }}

{{ b.text }}

{{ b.label }}

{{ line.text }}

{{ item.no }}

{{ part.text }}

{{ part.text }}

{{ part.text }}

Takeaways

▖ {{ t }}

Tags

{{ tag }}

← Newer

{{ prevPost.title }}

Older →

{{ nextPost.title }}

Related notes

{{ post.cat }}

{{ post.title }}

{{ post.read }}

Stop collecting AI prompts. Give it a better brief.

AI · Oct 2026 · 8 min read

Seven practical AI tips for work you actually need to finish. Better context, useful examples, targeted revisions and a verification loop—with copyable prompts and animated graphs that show what to measure.

“Make it better” is a perfectly reasonable thing to say when the other person knows what better means. A model usually needs you to spell that out. Better for whom? Shorter, more accurate, easier to act on, or more like the way you actually write?

A long prompt can still leave all of those questions unanswered. A short brief can answer them in a few lines. The useful trick is to make the task easy to judge before you ask the model to do it.

Here are seven habits to try on your next email, report, plan or piece of code. The examples are deliberately ordinary. You should be able to use them before your next meeting, without buying a course or switching tools.

The useful unit of AI productivity is a finished task you can trust.

1. Give it a finish line

Start with the result someone will use. “Help me with a project update” describes a topic. “Write a 150-word update that tells the client what shipped, what is blocked, and what we need from them” describes a deliverable. Add the audience, relevant facts and a few boundaries.

Google’s prompt design guidance recommends clear instructions, context and examples. The brief below is one practical way to apply that advice. It is a starting point, not a special formula.

Outcome: Write a client update, under 150 words.
Audience: A busy, nontechnical operations manager.
Facts: [paste completed work, blockers and dates].
Rules: End with one decision we need from the client.
Do not invent dates, progress or commitments.

Notice what is missing: a paragraph telling the model it is the world’s greatest communicator. You can use a role when it supplies a useful perspective, but it cannot substitute for the facts of the job.

Bar chart counting five brief elements: the vague request contains one, and the expanded request contains all five: deliverable, audience, facts, limits and acceptance check. — A count of information supplied in these examples. This is not a model-quality benchmark.

2. Let it ask when the answer would change

“Ask me three questions first” is a useful rescue for an unclear task. It is also unnecessary friction when you only want a sentence shortened. Make clarification conditional: ask about missing information that changes the result, then proceed.

Before drafting, check whether anything essential
is missing. Ask up to 3 questions only if the answers
would materially change the result.
Otherwise, state your assumptions and write a draft.

For a launch plan, audience and deadline can change almost everything. For a spelling correction, they usually do not. Answer the meaningful questions once and keep those answers in your reusable brief.

3. Show it what good looks like

“Write in my voice” leaves the model guessing. Give it a short sample you are comfortable sharing, then say what to preserve: sentence length, directness, vocabulary or structure. Separate the sample’s style from its facts so yesterday’s project details do not leak into today’s update.

STYLE SAMPLE: [paste a short example]
NEW FACTS: [paste the facts for this task]
Write using the sample’s tone and sentence length.
Use only NEW FACTS for factual claims.
Do not reuse the sample’s names, numbers or promises.

Read the result beside your sample. If the structure fits but the tone does not, name the difference: “Use shorter sentences; remove the sales language.” That is more useful feedback than asking it to sound more human.

4. Separate evidence from inference

A fluent summary can hide the boundary between what a source actually says and what the model concludes. Ask for that boundary explicitly. When working from documents, request a supporting passage and a page or section for each important claim. Then check those locations yourself.

Use the supplied documents to answer [question].
For each key claim, give the document and section
plus a short supporting passage.
Separate direct evidence from your interpretation.
If the documents do not answer it, say so.

5. Revise one dimension at a time

If a draft has the right facts but a weak opening, ask for a better opening. A complete rewrite creates more material to check and may lose something you already liked. Keep a good version, identify the specific defect, and make a narrow request.

Keep the facts, numbers and final request unchanged.
Rewrite only the opening two sentences.
Lead with the customer’s problem.
Give me 2 alternatives, each under 35 words.

Afterward, compare the revision with the original. “Keep the numbers unchanged” is an instruction, not a guarantee. For code, the equivalent is a focused change with a test that exercises the behavior you care about.

Animation follows the work once, then stops. A revision returns to checking before you use it.

6. Keep the context relevant

If you have changed the audience, the deadline and the deliverable several times, write a fresh brief containing the decisions that still apply. A new conversation can help when the old one is full of obsolete instructions. Keep the useful source material; do not make the model reconstruct your task from a history of abandoned ideas.

Anthropic’s context engineering guide treats context as a limited resource and recommends adding instructions and examples in response to observed failures. The everyday application is simple: include what the job needs, then adjust when you see a specific problem.

Summarize the current task for a fresh conversation.
Include: outcome, confirmed facts, constraints,
decisions, source references and open questions.
Exclude abandoned approaches.
Clearly label anything that remains unverified.

Review that handoff before reusing it. A summary can drop a constraint or turn an assumption into a fact. Reattach any source files the next conversation needs; a reference to a file is not the file itself.

7. Measure finished work, not the first reply

A reply that arrives quickly is useful only if the checking and fixing do not swallow the saving. Track the whole task: preparing the brief, drafting, checking and revising. Keep your usual quality standard fixed.

Illustrative stacked bar graph of minutes per task. Vague request: brief 1, draft 1, check and fix 18, total 20. Clear brief: brief 4, draft 1, check and fix 7, total 12. These are invented example values, not measured results. — Illustrative arithmetic only: 1 + 1 + 18 = 20 minutes; 4 + 1 + 7 = 12. Replace these values with your own observations.

The chart is a hypothetical scenario, not evidence that a better prompt saves eight minutes. It shows why you should count review time. A more detailed brief could save time, make no difference, or cost more than it returns on a simple task.

A small experiment for your next week
Record	What to write down
Task	A recurring job with a comparable scope
Brief	The prompt and source material you supplied
Total time	Preparation + drafting + checking + revision
Quality	Did it pass the same acceptance checks?
Rework	What still needed correction?

Try both approaches across a few comparable tasks. Record failures as well as successes. Keep a prompt because it repeatedly helps you finish acceptable work, not because one output sounded impressive.

A reusable prompt you can actually keep

If you save one thing from this article, save a brief you can fill in. Keep it short for simple jobs and expand it when the cost of a misunderstanding is higher.

I need [deliverable] for [audience].
The outcome is [what someone should understand/do].
Use these facts and sources: [material].
Follow these constraints: [length, tone, boundaries].
Here is a good example: [optional sample].
Ask only about missing details that change the work.
Label assumptions and unsupported claims.
Before finishing, check against [acceptance criteria].

Then do the part the prompt cannot do for you: read the output, verify the important facts, and decide whether it serves the person who will use it. The best prompt in your collection is the one attached to work you actually finished.

Takeaways

Specify the deliverable, audience, facts and acceptance criteria.
Ask clarifying questions when the answers would change the result.
Use examples for style and supplied evidence for facts.
Make focused revisions, then check what changed.
Measure total time to acceptable work, including verification.

All notes · Shehzad Aslam