Technology · July 21, 2026 · 9 min read

Prompt engineering for software engineers: a real guide

Prompt engineering for software engineers is system design plus code review: specify constraints, include the tests, read the output, catch the deprecated call.

← Part of AI-generated assessments: the complete 2026 guide

Engineers were the first professionals to live with an AI assistant every working day, so it is worth being precise about the skill. Prompt engineering for software engineers is not typing a clever prompt and hoping. If you hire engineers, the leverage is real and so is the risk: an assistant now drafts a meaningful share of first-pass code, and how well an engineer directs and interrogates that draft feeds straight into shipped quality and review load. The engineers who get real value 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 is one of the clearest things the AI Sandbox surfaces.

Why this is now core competence

The instinct to treat AI coding fluency as a fad, or as something that only juniors lean on, gets the risk exactly backwards. The more code an assistant drafts, the more the bottleneck shifts from writing to reviewing, and review is the harder skill. A team that ships AI-drafted code without an engineer who reads it critically has not saved time; it has moved the cost downstream, into production incidents and the review queue. The engineers worth hiring are the ones who make the assistant a force multiplier for judgement rather than a firehose of plausible-looking code nobody has properly read.

That reframes what you are actually assessing. Not whether someone can produce code with AI, which almost anyone now can, but whether the code they stand behind is code you would want in your codebase. The difference between those two engineers is invisible on a résumé and invisible in a syntax quiz. It is only visible in how they work a real task.

Prompting is code review in reverse

The best practice that holds up 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 did not become 'write longer prompts'; it became 'write clearer specs.' That is why it forces engineers to think like systems engineers. But the part that 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 is AI fluency applied to code, and it is the same discernment a good reviewer brings to a colleague's pull request.

The specification carries the work

When engineers describe a prompt that 'just worked', what they usually mean is that they specified the problem well. The model is not reading intent; it is reading text. Every constraint you leave implicit is one the model fills with a generic default, and generic defaults are how deprecated libraries, missing timeouts and swallowed errors get in. Writing the spec is not overhead you tolerate to use the tool. It is the same clarifying work you would do before writing the code yourself, made visible and reusable.

Small, reviewable drafts beat big ones

There is a scaling law to reviewing AI output that experienced engineers learn quickly: the larger the generated chunk, the less carefully anyone reads it. Ask for a whole feature and you get a wall of plausible code that is genuinely hard to audit, so it gets skimmed and shipped. Ask for one function with a clear contract and its tests, and you get something small enough to actually understand. The strong engineer therefore prompts in reviewable units, not because the model cannot produce more at once, but because they intend to read everything they keep. Scoping the request is itself an act of quality control, and it is one of the more reliable tells between an engineer who is directing the tool and one the tool is directing.

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.

The review reflex is the scarce skill

The reason the 4xx bug is a good test is that it is invisible to anyone who does not already know how retries should behave. The generated code compiles, passes a happy-path smoke test, and looks like every retry loop the model has ever seen, because it is an average of them. Catching it requires an engineer who reads with a specific question in mind: what happens on the error paths nobody demonstrated? That reflex, reading for the failure modes rather than the success case, is the same skill senior reviewers have always had. AI has not created it, but it has made it rarer relative to demand, because the volume of code needing review has climbed while the discipline of reading it has not. Assessing for that reflex is now more valuable than assessing raw output speed, which the tool has largely commoditised.

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 are reading through an implementation built on it.
• Ban the failure modes explicitly. Name the deprecated libraries, the disallowed patterns and the semantics that matter, because the model defaults to the average of everything it has seen.
• Treat your test suite as the eval. The output is not done because it looks right. It is done when it passes.

Common failure modes

• Paste-and-ship: trusting confident-looking code without reading it, then discovering the bug in production.
• Vague asks: no constraints, no output format, so the model guesses, and it guesses generically.
• No verification step: the code compiles, so it must be right, which it is not, reliably.
• Prompting for the whole feature at once instead of a reviewable draft, so nothing about the output is small enough to actually check.

Each of these is a review failure, not a coding failure. The AI did not introduce a class of bug that did not exist before; it made the old ones faster to produce and easier to overlook because the output looks so finished. The safeguard is the same one that has always separated senior from junior: the refusal to trust code you have not understood, applied now to code a machine wrote.

What this looks like across the stack

The retry-loop example is deliberately small, but the same shape recurs everywhere an engineer works. On the front end it is the generated component that re-renders on every keystroke because nobody constrained the effect dependencies. In infrastructure it is the Terraform block that opens a security group wider than intended because the model reached for the permissive default. In data-layer code it is the query the assistant wrote without an index hint, fine on the seed data and a full table scan in production. None of these are exotic bugs; they are the ordinary consequences of accepting a plausible first draft without the domain-specific reading that would catch them. The prompt discipline is universal, but the review discipline is where an engineer's actual depth shows, because you can only catch what you understand.

That is worth dwelling on when you design an assessment. A candidate who directs the model beautifully but never notices the widened security group is telling you something precise about the boundary of their competence. The tool is doing the typing; the engineer is supplying the judgement about what is safe to keep. An assessment that only measures whether working code appeared misses the entire question of whether the engineer would have caught it going wrong. That distinction, between output produced and output understood, is the one worth building the whole evaluation around.

AI fluency is a pillar, not a bolt-on

In our five-pillar model, AI fluency sits alongside cognitive, domain, situational and behavioural ability rather than replacing any of them. For an engineer that ordering matters: catching that a retry loop mishandles a 404 requires knowing HTTP semantics and error handling first. AI fluency is discernment layered on top of engineering judgement, which is why we treat it as AI fluency assessed as a distinct pillar scored on top of core skills, never as a substitute for them. This also updates the old debate over take-home assignments versus live coding: the question is no longer whether the candidate can write the code alone, but how they work with the tools they will actually use on the job.

How we assess it

You cannot 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 would actually use and watch how they direct, read and correct, which is exactly what an AI Sandbox assessment does. See what a strong software engineer assessment covers, how the sibling role differs for data analysts, and why this is the honest way to test the job in AI-native hiring.

The strongest engineers do not prompt for code. They prompt for a draft, then bring the same scepticism to it they would bring to any pull request, and that scepticism is the thing worth hiring for.