PromptSharp › Daily briefs › Dev & Engineering › September 9, 2026

Dev & Engineering prompt of the day

September 9, 2026 · for Software engineers, tech leads, engineering managers. One sharp, copy-paste prompt — free, every weekday.

You are a senior engineer writing characterization tests (a.k.a. pinning / golden-master tests, after Michael Feathers) for an untested legacy module I am about to change. The goal is a safety net that documents what the code ACTUALLY DOES today — not what it should do — so I can refactor without silently altering behavior. I will paste the module and the context.

Produce:

A) OBSERVED-BEHAVIOR MAP — from the pasted code, the module's public entry points and, for each, the inputs it consumes and the outputs/side effects it produces (return value, mutated state, I/O, exceptions thrown). Mark each output either "determined from code" or "MUST CAPTURE BY RUNNING" where the value cannot be read off the source (formatting, ordering, floating-point, downstream calls).

B) SEAM MAP — the seams where I can sense or separate behavior WITHOUT changing it (object seams via injected collaborators, a wrapping function, a parameterized clock/random/IO). For each: the smallest dependency-breaking edit that makes the code testable while leaving runtime behavior identical, and the risk that edit carries.

C) CHARACTERIZATION SUITE — tests that PIN the current behavior, ordered change-point-first then working outward. For each test: the exact input, the assertion against the OBSERVED output, and a comment `# pins current behavior — captured from a real run, do NOT 'correct' this value`. Include boundary and error paths the module currently exhibits (including current exceptions).

D) GOLDEN MASTER — for any output too large or complex to assert inline (rendered strings, big structures, serialized blobs): a capture-and-diff harness — how to sample a representative range of inputs, snapshot outputs to a golden file on a known-good commit, and fail the test on any diff. Name the exact inputs to sample.

E) CHANGE-SAFETY GATE — the order of operations: pin the change point, run the suite GREEN against the unmodified module, then refactor in small steps keeping it green — plus the one test that most protects the specific change I described.

Inputs: [PASTE THE MODULE + ITS DIRECT DEPENDENCIES] · [WHAT I NEED TO CHANGE + WHY] · [LANGUAGE / TEST FRAMEWORK] · [HOW TO RUN IT / SAMPLE INPUTS I CAN FEED IT]

Rules: Do not invent behavior the code does not demonstrably produce — every asserted value must come from the pasted source or from a real run I perform, and wherever you cannot determine an output, emit a `# CAPTURE:` TODO telling me to run the code and paste the result, never a guessed value. These tests document what IS, not what SHOULD be: if you suspect a bug, PIN the current (even wrong) behavior in the test AND list it separately as a "suspected defect to fix AFTER the net is green" — do not quietly assert the corrected value. Verify every pinned value against an actual execution before relying on the suite; a characterization test asserting an imagined output is worse than none. Keep proprietary or confidential source out of consumer AI tools beyond what I pasted, and strip any secrets, credentials, or real user data from fixtures and golden files.

How to run “Legacy-code characterization tests: pin what the module DOES before you dare touch it”, step by step

The situation this prompt is built for: You have to change an untested legacy module and you don't fully trust what it does. Wrap it in behavior-pinning tests that document the CURRENT behavior first, so your refactor can't silently change it. Below is exactly what to feed it and what comes back — no model-specific tricks, it runs the same in any chat AI.

What each placeholder does

Demo profile for the example fills: a senior backend engineer on a 12-person product team, working in GitHub, CI, and an AI coding assistant. Swap in your own context — or save it once at /profile and copied prompts arrive pre-filled.

• [PASTE THE MODULE + ITS DIRECT DEPENDENCIES] — this is the input the whole output quality hangs on. Each part narrows the answer: paste the module; its direct dependencies. Demo fill: your own paste the module + its direct dependencies — one or two concrete lines beats a paragraph of vague context. Leave it vague and the model pads with boilerplate; make it concrete and every section downstream sharpens.
• [WHAT I NEED TO CHANGE + WHY] — this is the input the whole output quality hangs on. Each part narrows the answer: what i need to change; why. Demo fill: your own what i need to change + why — one or two concrete lines beats a paragraph of vague context. Leave it vague and the model pads with boilerplate; make it concrete and every section downstream sharpens.
• [LANGUAGE / TEST FRAMEWORK] — this is the input the whole output quality hangs on. Each part narrows the answer: language; test framework. Demo fill: your own language / test framework — one or two concrete lines beats a paragraph of vague context. Leave it vague and the model pads with boilerplate; make it concrete and every section downstream sharpens.
• [HOW TO RUN IT / SAMPLE INPUTS I CAN FEED IT] — this is the input the whole output quality hangs on. Each part narrows the answer: how to run it; sample inputs i can feed it. Demo fill: your own how to run it / sample inputs i can feed it — one or two concrete lines beats a paragraph of vague context. Leave it vague and the model pads with boilerplate; make it concrete and every section downstream sharpens.

Why this structure works

The one rule that makes characterization tests work is the one everyone breaks: the tests must encode the behavior that EXISTS, bugs and all, not the behavior you wish existed — because their only job is to catch your refactor changing something. Forcing every assertion to trace to an observed run (with a CAPTURE TODO instead of a guess) kills the fabricated-output failure that turns a safety net into a lie, and pinning the change point first with a golden master for the messy outputs is exactly Feathers' order for getting untested legacy code under test cheaply.

On Pro, pro personalization loads your test framework, your snapshot/golden-file conventions, and your codebase's known-gnarly modules so the characterization suite and its capture harness drop straight into how your team already tests.

When to use it — and when not to

Reach for it when

• You have to change an untested legacy module and you don't fully trust what it does. Wrap it in behavior-pinning tests that document the CURRENT behavior first, so your refactor can't silently change it.
• You can actually supply the inputs it asks for ([PASTE THE MODULE + ITS DIRECT DEPENDENCIES] and 3 more) — this prompt is an amplifier for real context, not a substitute for it.
• You need the output in a shape you can forward as-is — the fixed structure above is the point.

Skip it when

• You don’t yet have the source material — the prompt is built to refuse to fake it. Its own guardrail: “Do not invent behavior the code does not demonstrably produce — every asserted value must come from the pasted source or from a real run I perform, and wherever you cannot determine an output, emit a `# CAPTURE:` TODO telling me to run the code and paste the result, never a guessed value.” With nothing to work from, you’ll get a list of “not provided” flags, which is honest but not useful. Collect the inputs first.
• The classic misuse this prompt was tuned against: Characterization tests that assert invented or 'corrected' behavior instead of the module's real current output — every assertion must trace to an observed run (CAPTURE TODO, never a guess), and suspected bugs are pinned then flagged, not silently fixed in the assertion.
• The task is genuinely one sentence long — a structured prompt earns its overhead when the output has parts. For quick one-off questions, just ask.

Adapting today’s prompt for adjacent roles

“Legacy-code characterization tests: pin what the module DOES before you dare touch it” sits in the Testing lane of the dev & engineering pool. If your seat is one desk over, these are the same craft-move rebuilt for the neighbouring workflow — pulled from the same curated pool, each free in full at its permalink:

You are a staff engineer reviewing a pull request. I will paste the diff and its context. Produce: A) REVIEW TABLE — columns: file/line reference, severity (blocker /…

You are a senior engineer running a structured root-cause investigation. I will paste the symptoms and every piece of evidence I have. Produce: A) HYPOTHESIS LADDER — 5…

You are a principal engineer drafting a design document. I will describe the problem and constraints. Produce: A) DOC SKELETON — context and problem, goals and explicit…

Common failure modes (and the fixes)

• Failure: letting the model drift past the prompt’s own guardrail — “Do not invent behavior the code does not demonstrably produce — every asserted value must come from the pasted source or from a real run I perform, and wherever you cannot determine an output, emit a `# CAPTURE:` TODO telling me to run the code and paste the result, never a guessed value.” Fix: keep that line in when you edit the prompt; it exists because this is exactly where outputs go wrong without it.
• Failure: letting the model drift past the prompt’s own guardrail — “These tests document what IS, not what SHOULD be: if you suspect a bug, PIN the current (even wrong) behavior in the test AND list it separately as a "suspected defect to fix AFTER the net is green" — do not quietly assert the corrected value.” Fix: keep that line in when you edit the prompt; it exists because this is exactly where outputs go wrong without it.
• Failure: letting the model drift past the prompt’s own guardrail — “Verify every pinned value against an actual execution before relying on the suite; a characterization test asserting an imagined output is worse than none.” Fix: keep that line in when you edit the prompt; it exists because this is exactly where outputs go wrong without it.
• Failure: filling [PASTE THE MODULE + ITS DIRECT DEPENDENCIES] with a vague summary. The output can only be as specific as this input — generic context in, generic deliverable out. Fix: paste raw specifics (real names, real numbers, real constraints), then trim the model’s output, not your input.
• Failure the prompt was tuned against: Characterization tests that assert invented or 'corrected' behavior instead of the module's real current output — every assertion must trace to an observed run (CAPTURE TODO, never a guess), and suspected bugs are pinned then flagged, not silently fixed in the assertion.
• Failure: accepting the first pass. Fix: reply with one line — “now cut everything that is generic to any company and keep only what is specific to mine” — the cheapest quality doubling available.

Quick answers

Is “Legacy-code characterization tests: pin what the module DOES before you dare touch it” free to use?

Yes — every weekday issue of the PromptSharp Dev Brief publishes one full pool prompt free on the web, and it stays free in the archive. Pro is the daily full prompt set, personalization, and MCP delivery — not a paywall on this page.

Which AI model does this prompt work with?

Any of them. Every PromptSharp prompt is model-agnostic plain text — ChatGPT, Claude, Gemini, Copilot, or a local model. No plugins, no custom GPTs; paste and run.

How is the dev & engineering prompt of the day chosen?

Deterministic rotation over the curated dev & engineering pool — currently 11 prompts across 5 sections — the same single source the paid brief reads. Same date, same prompt: the archive never silently changes under you.

What goes in the [BRACKETED] placeholders?

Your context — the walkthrough above covers each one. The short rule: the more concrete the fill (real names, numbers, constraints), the sharper the output. Save your details once at /profile and web copies arrive pre-filled.

How do I get this in my inbox instead?

The capture form above — PromptSharp Dev Brief status is honest: live briefs send every weekday; pre-launch verticals email their free list the day the email edition starts.

More daily AI prompt briefs

The same free weekday format, tuned to other crafts:

• PromptSharp Finance — for Investment banking, sales & trading, equity research, FP&A
• PromptSharp CPG Brief — for Brand managers, category managers, insights & shopper teams
• PromptSharp Marketing Brief — for Brand and growth marketers, agency strategists, content leads
• PromptSharp Sales Brief — for AEs, SDRs, sales leaders, RevOps
• PromptSharp Consulting Brief — for Management consultants, corporate strategy, biz-ops
• PromptSharp Product Brief — for PMs, product ops, founders wearing the PM hat
• PromptSharp Vibe Coding Brief — for Founders, PMs, designers, analysts — anyone building real software with AI without an engineering background
• PromptSharp C-suite Brief — for CEOs, CFOs, CMOs, CTOs, COOs and their chiefs of staff
• PromptSharp Law Brief — for Solo & small-firm attorneys, litigation & transactional associates, in-house counsel
• PromptSharp Personal Finance Brief — for Anyone running their own money — budgets, investing, taxes, and the rent-vs-buy / home-buying decisions that dwarf every other line item
• PromptSharp Career Brief — for Job seekers, career changers, anyone negotiating an offer
• PromptSharp Focus Brief — for Anyone who wants external structure for deep work — ADHD-friendly by design
• PromptSharp Learning Brief — for Self-directed learners — languages, skills, certifications, exam prep
• PromptSharp Health & Fitness Brief — for Anyone training, eating better, or building durable habits
• PromptSharp Travel Brief — for Trip planners — itineraries, deals, points, family logistics
• PromptSharp Students — for College students (undergrad + grad) — study, research, essays with integrity, exam prep, applications
• PromptSharp Trading — for Self-directed retail traders and active investors — risk and position-sizing thinking, regime awareness, journal review, bias-checking, earnings prep. Your own account, your own process.

← 2026-09-08 · All Dev & Engineering issues