Technology · July 21, 2026 · 8 min read

Prompt engineering for software engineers: prompting as code review in reverse

For engineers, prompting isn't a phrasing trick — it's system design plus code review. Specify the constraints, include the tests, read the output, catch the deprecated call. A practical guide with a worked example and how it's assessed.

Engineers were the first professionals to live with an AI assistant every working day, so it's worth being precise about the skill. It isn't typing a clever prompt and hoping. The engineers who get real leverage from AI treat prompting the way they treat any interface: they define the contract, the constraints and the failure modes, then verify what comes back. This is the software-engineering entry in our per-role prompt engineering series, and it's one of the clearest things the AI Sandbox surfaces.

Prompting is code review in reverse

The best practice that holds up across every recent study is boring on the surface: state the success criteria and constraints before you ask, give the model structured inputs, and specify the exact output you want. Prompt engineering didn't become 'write longer prompts' — it became 'write clearer specs.' That's why it forces engineers to think like systems engineers. But the part that actually separates strong from weak is what happens after the code appears: reading it critically and catching the subtle problem — a deprecated call, a retry that swallows a 4xx it should have surfaced, an unhandled edge case. That's AI fluency applied to code.

A worked example

Ask an assistant for an async API client with retry logic. A weak prompt is 'write a function to fetch a user with retries.' A strong one pins down the contract, the constraints, and — crucially — the tests the code has to pass. Then the engineer reads the result, spots that the generated retry loop backs off on a 404 it should have thrown on, fixes it, and runs the test to confirm.

## TASK
Write an async fetchUser(id) client method in TypeScript.

## CONSTRAINTS
- Modern async/await fetch — no deprecated request libraries
- Retry on 5xx and network errors only, never on 4xx
- Exponential backoff with jitter, max 3 attempts, 5s per-attempt timeout

## TESTS IT MUST PASS
- Returns parsed JSON on 200
- Throws immediately on 404 (no retry)
- Gives up after 3 failed attempts

## OUTPUT
Code first, then one line on any assumption you made.

• Good: constrains the request, hands the model its tests, reads the output, catches deprecated or unsafe code, verifies with a quick run.
• Weak: pastes 'write a fetch with retries', accepts the first plausible function, and ships it with the 4xx bug intact.

Best practices that actually move the needle

• Structure over length. Separate the request into sections — task, inputs, constraints, output format — instead of one long paragraph. Reasoning quality tends to degrade well before you run out of room, so tight and clear beats sprawling.
• Hand the model your tests. Include the cases the code must pass, not just the requirements. It writes to your bar instead of a generic one.
• Make it show its reasoning before the code, so a wrong assumption is visible before you're reading through an implementation built on it.
• Treat your test suite as the eval. The output isn't done because it looks right — it's done when it passes.

Common failure modes

• Paste-and-ship: trusting confident-looking code without reading it.
• Vague asks: no constraints, no output format, so the model guesses — and guesses generically.
• No verification step: the code compiles, so it must be right (it isn't, reliably).

How we assess it

You can't measure any of this with a quiz about prompt syntax, and you learn nothing by banning AI in the interview. You put the candidate in a realistic engineering task with the tools they'd actually use and watch how they direct, read and correct — which is exactly what an AI Sandbox assessment does, and how AI fluency is scored as a pillar. See what else a strong software engineer assessment covers, why this is the honest way to test the job in AI-native hiring, or watch a role-tuned assessment get composed.

The strongest engineers don't prompt for code. They prompt for a draft, then bring the same skepticism to it they'd bring to any pull request — and that skepticism is the thing worth hiring for.