Prompt like the highest-paid engineer in the room

Learn in your browser · Chapter 01 of 07

Anyone can type a request into an AI model. The people who get expert-grade results, every time, are not luckier with wording. They are working to a structure, and they check their own output the way a good editor checks a junior colleague's draft. This chapter sets out that structure. The next five chapters put it to work on five real jobs: a website that does not look like a template, a working app, a document an investor would actually read, an image or video that looks directed rather than generated, and an email that moves a difficult conversation forward.

You already know the basics from Your first prompts: role, task, context, format, constraints and examples. Those six parts get you a competent answer. On their own they will not get you a result that is hard to tell apart from something a senior specialist produced. For that you need three more habits: a deliberate iteration loop decided before you start, an explicit verification step, and a named list of the failure modes this particular kind of task tends to fall into. Put together, these eight ingredients are what separates a prompt engineer from someone who simply types well.

Scroll sideways to see every column.

A model answers by predicting the most statistically likely continuation of your words. A vague prompt (write me a landing page, build me an app, draft a pitch) has appeared, in some close form, an enormous number of times in what the model learned from. The most likely continuation is the most average one: the layout everyone else got, the pitch deck everyone else got. Specificity is not decoration. It is the only thing that moves a model off the average, and the eight parts above are simply a disciplined way of supplying it.

Here is the anatomy in miniature, on a task none of the next five chapters cover, so you can see the shape once before the deep dives.

Weak: Summarise this quarterly report for me.

Strong:
Role: You are a careful financial analyst briefing a busy managing director.
Context: I have pasted the full report below. The reader has 90 seconds and cares about cash runway and anything that changed since last quarter.
Constraints: Use only numbers that appear in the text. Do not round in a way that changes the number of significant figures. 150 words maximum.
Output format: Three bullet points, then one line naming the single biggest risk.
Example: Match the plain, declarative tone of a board memo, not a press release.
Iteration: Give me this version first. I may ask for a second version aimed at the finance team instead, with more detail.
Verification: After the summary, list any figure you were unsure how to interpret from the source text.
Failure mode to avoid: Do not smooth over a bad number with vague language like 'broadly stable'. Name it plainly.

Learn in your browser · Chapter 02 of 07

Every AI model has seen thousands of software-product landing pages and near-identical templates. Ask for 'a modern, professional website' and it hands you the average of all of them: a centred hero, a gradient background, three icon boxes in the same rounded style, and a testimonial carousel. None of that is exactly wrong. It is just instantly recognisable as generated. This chapter shows you how to prompt for something that reads as designed, and how to brief an AI coding assistant so the result holds together section by section instead of drifting.

Weak: Design me a landing page for my software product. Make it look modern and professional, with a hero section, features, and a call to action.

• No layout hierarchy: nothing tells the model what the eye should land on first, second and third, so it falls back on the most common pattern: centred text, centred button, symmetrical everything.
• No type pairing: 'modern' carries no typographic meaning, so you get a generic system font at a generic weight.
• No whitespace direction: without a spacing rule, sections crowd together at a default density that reads as a free template.
• No motion restraint: many assistants now add hover-lift and fade-in effects by default. Left unscoped, you get animation on everything, which reads as busy rather than premium.
• No colour discipline: 'professional' commonly resolves to blue on white with a gradient accent, because that is the statistical average of the training data for that word.
• No negative examples: without being told what to avoid, the model cannot distinguish your brief from the enormous number of near-identical ones it has absorbed.

Set a design system before you build anything. This is the single highest-leverage move in this chapter: a short, fixed set of rules that every section afterwards must obey, so nothing drifts.

Before building anything, define a small design system and show it to me as a short list, not code yet:
- A type scale: one display typeface for headings only, one workhorse typeface for body text, four sizes only, using a 1.333 ratio from a 16px base.
- A spacing scale: 8px, 16px, 24px, 40px, 64px, 96px. Nothing outside this scale, anywhere.
- A colour system: one near-black ink, one off-white background (not pure white), one neutral mid-grey, and exactly one accent colour used only for the single primary action on each section. No gradients.
- A motion rule: transitions only on opacity and transform, 150 to 250 milliseconds, ease-out, triggered only on the primary action and on scroll-into-view for section headings. Nothing else moves.
Wait for my approval before building any section.

Then brief one section at a time, referencing only that approved system.

Using only the design system above, build the hero section as its own HTML and CSS block. Layout: an asymmetric two-column grid, roughly 60/40, not centred. Left column: an eyebrow line in the mid-grey at the smallest type size, a headline at the largest size spanning no more than two lines, one sentence of supporting text at body size, and a single primary button using the accent colour. Right column: reserve the space with a placeholder box, do not invent an illustration or icon set. Avoid a gradient background, avoid a hero image containing people, avoid centring the text block. Give me the code only, then stop and wait for my review before the next section.

A useful order for sections: navigation, the hero, a proof or trust block (real logos, a real figure, a real short quote, never invented), a feature breakdown with one clear point per block rather than five equally loud ones, and a final call to action. Aim for one genuine hero moment on the page, not five competing for attention at once. Restraint reads as confidence. Decoration reads as compensation for a weak layout underneath it.

After each section, ask the assistant to check its own output against a short list: does any element sit outside the spacing scale, is any colour used that is not in the palette, is there more than one primary action visible at once, would this section be recognisable as a specific common template if you searched for it. Read the answer, then look yourself. The two do not always agree, and your eye is the one that actually has to be satisfied.

Learn in your browser · Chapter 03 of 07

Build your first app with an AI coding assistant taught you to brief, build in small steps, review and test. This chapter is about the prompting discipline that makes that whole process reliable at a senior level: a hard scope boundary, acceptance criteria you write before any code exists, and two AI coding failure modes worth naming out loud rather than discovering the hard way.

Weak: Build me a habit tracker app where I can add habits and check them off each day.

• No platform or stack boundary: the assistant guesses a framework and may bring a heavy stack for what should be one small file.
• No data model: nothing defines what a 'habit' record actually contains, so the assistant invents fields, and possibly a backend or database nobody asked for.
• No acceptance criteria: there is no way to check whether the result is correct beyond 'it looks like it works'.
• No constraint on dependencies: the assistant may add a UI library or analytics 'because that is common', adding invisible bloat and surface area.
• No verification instruction: nothing asks the assistant to handle edge cases such as local midnight, zero habits, or a habit name that is only emoji.
• No named failure modes: AI-generated code commonly calls a library function that does not exist, or quietly weakens error handling under the pressure to 'just make it work'.

Build a single-file habit tracker, index.html, inline HTML, CSS and JavaScript only, no external libraries, no network calls, no backend, everything stored in localStorage only.
Data model: a habit is { id, name (max 40 characters), createdOn (date), history (a map of date string to boolean) }.
Behaviour: I can add a habit, mark today done or not done, and see a 7-day strip per habit. Habits reset visually at local midnight.
Constraints: do not add a framework, build step or dependency of any kind. Do not add analytics or any outbound request. Do not invent features I have not asked for.
Before you write any code, list: (1) every assumption you are making about behaviour I have not specified, (2) the exact shape of the data model in code, (3) three edge cases you will handle and how. Wait for me to confirm before building.
Once confirmed, build in this order and stop after each: the data layer and its self-tests, then the render layer, then the input handling. Tell me if at any point you would need to guess rather than follow what I gave you.

Write your own acceptance criteria before you write the prompt, in the same way you would write them before writing the code yourself. If you cannot state what 'correct' looks like for a given input, no amount of clever prompting will rescue you, because you will not be able to tell a right answer from a merely fluent one.

Asking the assistant to list its assumptions before writing code, rather than explaining them after, does two things at once. It is a verification step, because you can correct a wrong assumption for free before any work is done. It is also a failure-mode pre-empt, because most AI-written code goes wrong precisely at the points the brief left ambiguous.

Learn in your browser · Chapter 04 of 07

Business writing has a failure mode the other four outcomes in this workbook do not share as sharply: a model asked to sound 'compelling' about a company it barely knows will invent specifics to sound convincing. A market-size figure, a growth rate, a competitor claim, stated with exactly the same fluent confidence as a real one. This chapter is built around removing that risk entirely, not just writing better sentences.

Weak: Write me an investor pitch summary for my startup. Make it compelling and professional.

• No real inputs supplied, so the model must invent specifics to fill the gaps: a market size, a growth figure, a competitive claim, all fabricated to sound plausible. This is the single most dangerous failure mode in AI-written business writing: invented precision.
• No structure requested, so the response defaults to the generic pitch shape every reader has already seen a hundred times: the problem, the solution, why now, the ask.
• No audience calibration: a seed-stage angel and a growth-equity fund are reading for different things, and an unscoped prompt cannot tell which you mean.
• No tone constraint, so 'compelling' resolves to hype: revolutionary, game-changing, disrupting.
• No verification step, so any invented figure ships completely unflagged, indistinguishable in tone from a real one.

Write a one-page investor summary. Audience: a seed-stage angel who has seen 40 decks this quarter and skims in under two minutes.
Here is every fact you may use, and you may not add to it: [one-line description of the company], [the problem, one sentence, with the one real data point I supply], [what we have built and shipped], [the traction figures I give you, exactly as given, with the date they are as of], [the ask and what it funds].
Structure: problem, evidence the problem is real, what we built, traction, the ask. One short paragraph each. No headers longer than three words.
Tone: plain, declarative sentences. No adjectives doing the work evidence should do. Ban list: revolutionary, game-changing, disrupt, unprecedented, cutting-edge, seamless.
Constraint: 200 words maximum. If a claim is not in the facts I gave you, write [NEED: description of what is missing] instead of inventing it.
After the draft, list every number and every factual claim in it, and mark each one 'from the facts I gave you' or '[NEED]'. I will check that list before I check the prose.

A style sample is often more reliable than describing tone in adjectives. Paste a paragraph you admire, or one you wrote yourself in a document you were pleased with, and ask the model to match its sentence length and restraint rather than chase a word like 'professional', which has no fixed meaning on its own.

For iteration in this genre, ask for three lengths from the same locked fact set in one pass, a 50-word version, a 150-word version and the full page, rather than writing three separate prompts. Board-level material gets read at different depths by different people, and you want all three versions to agree with each other exactly, which only holds if they are drawn from one fact set at once.

Learn in your browser · Chapter 05 of 07

Ask an image model for 'a professional image of a business meeting' and you get the single most common arrangement in its training data for that phrase: a symmetrical group, evenly lit, everyone facing camera. Recognisably generated, at a glance. This chapter replaces vague description with the vocabulary a photographer or a director actually works in, plus a disciplined way of refining what comes back.

Weak: Generate a professional image of a business meeting for my website.

• No composition or framing instruction, so the model defaults to the single most common arrangement for that phrase: a symmetrical, centred, wide group shot.
• No lighting language, so it defaults to flat, even, slightly artificial light, the single most recognisable 'AI stock photo' signature.
• No camera or lens vocabulary, so there is no real sense of depth or of an actual optical system having taken the shot.
• No negative constraints, so common artefacts (illegible background text, a malformed hand, a generic logo-like shape) go unchecked.
• No end-use context (aspect ratio, where it sits on the page, the mood the rest of the brand carries), so the result may not even fit the job it was made for.
• No iteration plan, so each new attempt is a fresh roll of the dice rather than a controlled refinement of one result you already liked part of.

A single person at a desk reviewing documents, shot from a three-quarter angle, not facing camera. 35mm lens look, shallow depth of field, background softly out of focus. Late-afternoon side light through a window, warm but not golden-hour orange, a visible soft shadow. Muted, desaturated palette: charcoal, warm grey, one small point of a deep red accent. No visible screens with legible text. No logos, no brand marks, no illustrated icons. No other people in frame. Composition: subject placed on the left third, generous negative space on the right for a headline to sit over later. 16:9, high detail on the hands and face, everything else soft.
Negative: no extra or malformed fingers, no uncanny or waxy skin texture, no generic stock-photo smiling-at-camera pose, no gradient or bokeh circles used as decoration.

Generate a batch rather than rewriting the whole prompt to fix one thing, and change only one variable per follow-up, only the lighting, or only the crop, so you can tell exactly what each change actually did. If your tool supports a seed or a reference image, reuse it while you refine, so you are steering one result rather than starting over each time.

Check the result deliberately against the parts most likely to be wrong, rather than glancing at the whole image: hands, any visible text, reflections and shadows for consistency with the stated light source, and any repeated or tiled pattern in the background. These are the details a viewer's eye catches first, and the ones a model gets wrong most often.

Learn in your browser · Chapter 06 of 07

Write a firm email to a client who hasn't paid and you will get exactly that: firm, and generic. It will not tell you whether firm is even the right register for this specific person, and it cannot pre-empt an objection it was never told about. This chapter treats a difficult message as a small negotiation with a stated objective, not a tone to request.

Weak: Write a firm email to a client who hasn't paid their invoice.

• No stated objective beyond 'firm', so the model cannot calibrate: full payment by a date, a payment plan, or simply documenting the request for a paper trail.
• No context on the relationship or history, so it defaults to a generic template tone that fits nobody's actual situation, either too soft to work or too harsh to repair afterwards.
• No information about leverage or what you are willing to concede, so there is no room for the email to actually negotiate rather than just state a demand.
• No read on the other side's likely position, so the email cannot pre-empt the obvious objection.
• No iteration plan, so you get exactly one tone and have to guess whether it is calibrated right.

I need to email a client, [name], about an invoice [amount] that is [X days] overdue. History: they have paid on time for two years, this is the first time it has been late, and I have not chased it yet. What I actually need: payment in full within 7 days, or, if genuinely necessary, a two-instalment plan over 30 days, no longer. I am willing to waive nothing else. I want to keep the relationship. This is not the moment to end it.
Before you draft anything, list the three most likely reasons a client with this history is late, and the objection or reaction each one would produce.
Then write the email: firm about the 7-day date, warm about the relationship, one clear ask, one fallback offered proactively rather than only if they push back. Under 120 words. No corporate throat-clearing ('I hope this finds you well'), no passive voice on the ask itself.
Give me two versions: one at this firmness, one noticeably firmer, so I can choose.

Ask for two versions at different firmness levels rather than one 'right' tone in a single pass. A single draft cannot be checked against anything. Two drafts at known different settings let you choose, or blend a line from each, with your own judgement doing the calibrating rather than the model's default.

After drafting, ask the model to state what response it expects and why, then sanity-check that prediction against your own read of the relationship. If the model's read of the situation is thinner than yours, that is a sign to add more context before you send anything, not a reason to trust the draft as it stands.

Learn in your browser · Chapter 07 of 07

You have five weak-to-strong examples behind you now, plus the eight-part structure that produced every one of them. Here is what to do with that structure next.

You can now look at any AI request you are about to type and check it against the eight parts before you send it: role, context, constraints, output format, examples, iteration, verification and failure modes. You can set a design system before briefing a website, write acceptance criteria before prompting for a tool, fact-lock a document before asking for a draft, direct an image or video with camera and lighting language instead of a vague description, and pre-empt the other side's objections before you send a difficult email. None of that depends on a particular model or tool. It travels with you to whatever you prompt next.

Ready to prove it? Take the exam for this workbook at trust-agent.ai/exam/prompt-like-a-frontier-engineer. Score 81% or higher and you earn a certificate with your own name on it.

This is free educational content published by Mickai LTD, not professional, legal, financial or compliance advice, and Mickai accepts no liability for how you use it.

Checking a model's own work against stated criteria before you trust it, rather than accepting fluent output at face value, is the same principle behind Mickai's approach to trustworthy AI: a human stays in control of the judgement calls, even as the drafting itself speeds up.