The AI Project Write-Up That Survives a 90-Second Scan

What a reviewer actually reads

Here is the uncomfortable premise the rest of this guide is built on. The person assessing your project is not reading it. They are scanning it, in a fixed order, looking for a small number of specific signals, and they will decide whether to keep going long before they open a single file of code. That decision takes somewhere in the region of a minute and a half, and it is made on the title, the first paragraph, one image, and — if you have given them one — the evaluation section.

What they are scanning for is consistent across markets and across seniority levels. Hiring managers screen for production signals: how you handle failure, how you structure data, how you connect systems, and whether you have shipped working software that other people depend on. Toy demos and reproduced tutorials read as hobbyist work, not because the code is bad but because the write-up contains no evidence that anything was ever hard. A project that never encountered a constraint never had to make a decision, and decisions are the entire thing being assessed.

This is why the advice consensus lands where it does: three to five polished, end-to-end projects with live demos and measurable impact beat a long list of basic experiments, every time. And it is why projects framed around outcomes, metrics and deployment land better than projects framed as tool lists. Employers commonly screen for shipped projects, repository evidence and deployment experience before they get anywhere near formal credentials — which means the artefact doing the work on your behalf, in the room you are not in, is a page of text you wrote.

The good news is that this is a solvable problem with a fixed shape. What follows is a seven-part template, an explanation of the scan order it is designed for, a worked before-and-after on the same fictional project, and the specific differences between how an Indian services or capability-centre reviewer and a UK startup hiring manager read the same page.

The ninety-second scan, in order

Reviewers do not read top to bottom. They sample, in a repeatable sequence, and each stop is a small pass-or-continue decision. Knowing the sequence lets you put the right thing at each stop rather than distributing your best material evenly across a page nobody reads evenly.

Two things fall out of that table immediately. First, the evaluation section is the hinge. It is the only place in the scan where a reviewer slows down and reads properly, and it is the section most write-ups do not have at all. If you do nothing else after reading this guide, add an evaluation section with a stated baseline to your strongest project.

Second, the code is read last and least. This surprises engineers, who tend to invest their polish effort exactly where the least attention is spent. The code matters — it is what confirms or destroys the claims above it — but it is a verification step, not a discovery step. Nobody finds you through your code. They find you through a paragraph, and then check your code.

The seven-part template

Use the same seven parts every time, in the same order, for every project you write up. The consistency is not aesthetic. It means a reviewer who has read one of your write-ups can navigate the next one instantly, and it means you never have to decide what to include — only what to put in each slot. Parts one, two and four carry most of the weight; parts five and six are the ones that separate an experienced engineer from a capable beginner.

1. The one-line problem statement

What was broken, for whom, and what it cost. One sentence, readable in isolation, with no technology in it. The test is brutal and useful: if you cannot state the problem without naming a model, a framework or a vector database, you do not yet have a problem — you have a tool you wanted to use. Include the cost of the status quo in whatever unit is honest: hours a week, error rate, delay, money. A problem statement with a magnitude in it is immediately more credible than one without, because magnitudes are checkable and vague pain is not.

2. The constraint that made it hard

This is the single most under-written part of every project description on the internet, and it is the part that separates a real project from a tutorial. Every tutorial has unlimited latency, unlimited budget, clean data and no privacy boundary. Every real system has at least one of: a latency budget, a cost ceiling, data that could not leave a particular environment, an accuracy floor below which the system is worse than useless, an offline or air-gapped requirement, or a volume that made the obvious approach unaffordable. Name yours explicitly, with a number attached, and say what it ruled out. "Responses had to return in under four hundred milliseconds, which ruled out the multi-step agent design I started with" tells a reviewer more about your seniority than three paragraphs of architecture.

3. What you actually built

Three sentences of architecture, plus either one simple diagram or a plain-text list of components. Three sentences is a hard limit and it is deliberate. The purpose is not to document the system; it is to let a reviewer hold the shape of it in their head while they read the evaluation. Describe what the pieces do, not what they are called. "A nightly job normalises the source documents into passages, an embedding index serves the top candidates at query time, and a single model call composes the answer with citations back to the source" is a better sentence than any list of product names, and it survives you swapping every component out later — which matters, because retrieval-augmented generation is repeatedly cited as one of the most in-demand AI engineering skills as of 2026, and the reviewers who care about it care about whether you understand retrieval, not whether you can name a library.

4. How you knew it worked

The evaluation. Four things, all of them concrete: what the test set was, how you built it, how big it was, and what metric you used. Then the fifth and most important thing — what the baseline was. A stated baseline is the strongest single credibility signal available to you in a write-up, because it proves you understood that a number in isolation means nothing. "Seventy-eight per cent" is unfalsifiable noise. "Seventy-eight per cent against a keyword-search baseline of fifty-one per cent, on one hundred and twenty questions I wrote from real support tickets" is an engineering claim. And if your evaluation was weak, say so plainly. "I reviewed sixty outputs by hand against a written rule and judged forty-nine acceptable" is a perfectly respectable sentence that costs you nothing. A fabricated metric costs you everything, in the first follow-up question.

5. What broke, and what you did about it

Failure modes, named, with the specific mitigation next to each. This section is counter-intuitive to write and disproportionately effective to have written. A candidate who can name their system's failure modes is instantly more hireable than one who claims none, because claiming none only ever means one of two things: the system was never used, or you were not paying attention. Neither is a good look. Two to four failure modes is the right number. For each, say what triggered it, roughly how often it happened, and what you actually did — the mitigation matters more than the failure. "Long documents pushed the answer out of the retrieved window about one time in twelve, so I chunked on section boundaries rather than fixed length and added an overlap" is a complete, senior-sounding unit of work.

6. What it cost to run

A cost per task or a cost per month, and the trade you made to get there. Most side projects skip this because they think it does not apply. It always applies, and computing it is a twenty-minute job. Run your pipeline over a fixed sample — fifty tasks is enough — logging the input and output token counts your provider returns. Multiply by the published per-token price, add a retry factor for the runs that failed and were repeated, divide by the sample size, and write down the date and the price you used. That last part is what makes it defensible: prices move, and a figure that says which prices it was computed against ages gracefully instead of becoming wrong. Then state the trade in one line — what you gave up for that number, or what you would have had to spend to do better. Our guide to cost-aware evaluation and quality per pound goes considerably deeper if you want to make this a habit rather than a paragraph.

7. What you would do differently

One honest paragraph. Not false modesty, which reads as fishing, and not the humblebrag disguised as a weakness, which every reviewer has seen several hundred times and finds mildly insulting. The genuine version is specific and slightly costly to admit: an architectural decision you would reverse, a measurement you should have taken at the start and could not reconstruct later, a scope choice that made the project harder than it needed to be. This is also the part that most reliably generates a good interview conversation, because it hands the reviewer an obvious question that you have already thought about carefully — which is a far better position than being asked a question you have not.

Here is the whole thing as a skeleton. Copy it, fill it in, and delete the guidance lines in square brackets.

# [Project name] — [what it does, in six words]

## The problem
[One sentence. Who had the problem, what it cost them.
 No technology in this sentence. Include a magnitude.]

## The constraint
[The one thing that made this hard, with a number.
 Latency budget / cost ceiling / data that could not move /
 accuracy floor / offline requirement / volume.]
[And: what that constraint ruled out.]

## What I built
[Three sentences. What the pieces DO, not what they are
 called. Then a component list:]
  - [component] -> [what it does]
  - [component] -> [what it does]
  - [component] -> [what it does]

## How I know it works
  Test set    [N] cases, built by [how], covering [what]
  Metric      [exact definition, e.g. exact-match on the
              extracted field, judged by [rule]]
  Baseline    [the naive approach] scored [X]
  Result      [Y]  (measured [date], [N] runs)
  Caveat      [what this test set does NOT cover]

## What broke
  1. [Failure mode] — happened ~[frequency].
     Fix: [what you actually did].
  2. [Failure mode] — happened ~[frequency].
     Fix: [what you actually did].
  3. [Still open] — [why you have not fixed it].

## What it costs to run
  [Currency][amount] per task, or [amount] per month at
  [volume]. Computed from [N] sampled runs on [date] at
  [price] per 1M input / [price] per 1M output tokens,
  with a [x1.NN] retry factor.
  The trade: [what you gave up to get that number].

## What I would do differently
[One honest paragraph. One real decision you would reverse,
 and why. Not a disguised strength.]

## Run it
[Three commands, maximum. Live demo link if there is one.]

Weak signals and strong signals, side by side

The difference between a write-up that gets a reply and one that does not is rarely the underlying work. It is a set of small, repeatable substitutions, each of which converts an assertion into evidence. This table is worth keeping open while you edit.

The same project, written twice

Abstract advice about write-ups is easy to agree with and hard to apply, so here is the same fictional project described both ways. It is an illustrative example, invented for this guide — not a real company, a real client or a real person. The underlying work is identical in both versions. Only the description changes.

Nothing in that paragraph is untrue, and it is roughly what most portfolio entries look like. Read it as a reviewer with sixty candidates and ninety seconds each. There is no problem, so there is no reason the work existed. There is no constraint, so there was no difficulty. The accuracy claim has no test set behind it and is therefore ignored — worse than ignored, it is a small negative, because everyone reading knows that 99% on document extraction is not a thing you assert casually. There is no cost, no failure mode, and no decision anywhere in it. The list of five technologies is the only concrete content, and any of the other fifty-nine candidates could have written the same list.

Same project. The second version is roughly four hundred words against the first version's seventy, and every additional word is doing work: it establishes a constraint, a baseline, a failure mode, a cost, a trade and a reversed decision. A reviewer reaching the end of it has enough material for a forty-minute technical conversation, and — importantly — has stopped wondering whether you built this or followed along with something. That confidence is the entire product of a good write-up. If you are also going to demo the thing live, our guide to demoing an AI agent in a live interview covers the very different discipline of showing it in real time.

What to leave out

Editing down is harder than writing, and the things people add to project write-ups to look serious are almost all things that make them look less serious. Cut the following without regret.

Architecture diagrams with fifteen boxes. A diagram is worth including only if a reviewer can understand it in five seconds from across a room. Beyond about six boxes, the diagram is documentation for a team, not a signal for a stranger, and a large one actually reads as inexperience — it suggests you cannot identify which parts matter. If you have a fifteen-box system, draw the four boxes that matter and say the rest exists.

Tool and vendor logos. A row of logos communicates that you can install things. It is the visual equivalent of the tool list in the weak example above, and it occupies the one image slot in the ninety-second scan — the most valuable piece of real estate in the whole document. Spend that slot on a screenshot of the working system or a single clear diagram instead.

Leaderboard screenshots and benchmark tables you did not run. Nobody is assessing your project on someone else's benchmark of someone else's model. Including one signals that you could not produce an evaluation of your own, which is the exact opposite of the message you want at the exact point in the scan where the reviewer is paying most attention.

Unqualified accuracy claims. Any percentage without a test set described next to it is worse than no percentage at all. It is read as either carelessness or marketing, and both are disqualifying in a role where measurement is a core duty.

Long installation instructions above the fold. Setup belongs at the bottom. A reviewer decides whether to run your project after deciding it is interesting, never before, and twenty lines of environment configuration between the title and the problem statement destroys the scan order you have just spent effort designing.

The words "cutting-edge", "state-of-the-art" and "leveraged". They are load-bearing in nothing and they date the document badly.

Two markets, two reviewers

The seven parts do not change between India and the UK. The weighting does, and being deliberate about it is worth real money at offer stage. As of 2026 both markets are short of people who can demonstrate production judgement, but the shape of the shortage differs. In India, demand for AI engineers is rising at roughly 40% year on year while the skilled talent pool grows only 15–20%, and around 11.7% of Indian job postings now explicitly require AI skills, up from 8.2% a year earlier. In the UK, AI engineering job adverts rose 1133% between 2024 and 2026 according to IT Jobs Watch, with senior UK AI engineers sitting around £90k–£150k base and contract day rates near £550. Indian salary bands as of 2026 run from roughly ₹2–7 LPA at entry level to ₹10–15 LPA at four to six years and ₹25–50+ LPA for senior architects and specialists, per 2026 market surveys. We covered the underlying demand picture in more detail in our reporting on AI engineer hiring demand and pay.

Those are different market structures, and they produce reviewers who read the same page for different things.

The practical instruction is not to write two documents. It is to make sure every part contains both signals, and to put the market-specific emphasis in the first sentence of each section. Say the volume and the user in the problem statement. Say the result and how the test set was built in the evaluation. A write-up that satisfies both readers is only about fifteen per cent longer than one that satisfies either, and it means one artefact serves applications on both sides of the corridor. If you want to understand which signals a specific team actually weights before you tailor anything, the questions in our guide to reverse-interviewing an AI team will tell you more in twenty minutes than any amount of guessing.

Write once, publish in three places

The same write-up has three homes, and the mistake almost everyone makes is treating them as three separate pieces of work that then drift out of sync.

The repository README is the one that gets read. This is not intuitive — people assume the portfolio site is the shop window — but it follows directly from the scan order. A reviewer who has reached your code is already in the repository, and the README is the first thing rendered on that page. It requires no additional click, no additional decision and no trust in a domain they have never heard of. Make the README the canonical version: the full seven parts, the one image, the three commands to run it at the bottom. Everything else is derived from it.

The Builder profile entry is the one that gets found. A README only works on people who already know your repository exists. A profile works on people who do not yet know you exist, which is a much larger and more valuable group. Condense the seven parts to roughly a hundred and twenty words for a profile project entry: the problem in one line, the constraint in one line, the headline evaluation result with its baseline, the cost, and a link to the README for everything else. That condensation is the single highest-leverage editing exercise in this guide, because it forces you to identify which two facts about the project actually matter.

The portfolio page is the one you control. If you maintain a personal site, it can carry a longer version with more images and the reasoning you had to cut elsewhere. Treat it as optional. It is worth having and it is rarely the thing that gets you the conversation.

Keep the README as the single source of truth and derive the other two from it, so there is only ever one file to update when the project changes. And write the condensed profile version at the same sitting as the README, not months later. Nothing degrades faster than the memory of why you made a particular decision; the failure mode you could describe precisely in March becomes "there were some issues with long documents" by September.

The same text also does a fourth job. It is the artefact you paste into a cold approach, and it is what somebody forwards on your behalf when they refer you — which is exactly the mechanism our guide to getting referred into an AI team without a network is built around. If you have also been contributing to public repositories, the same discipline applies to the write-up of that work; our guide on AI-assisted open-source contributions and maintainer trust covers how to describe those without overstating your role.

Where to start this week

Do not attempt five write-ups. Do one, properly, on the project you are proudest of, and use it as the template for the rest.

First, build the evaluation you should have built at the time. This is usually two to four hours and it is almost always the missing piece. Assemble fifty to a hundred and fifty real cases, define the metric precisely enough that two people would score a given output identically, and run the naive approach — keyword search, a regular expression, a fixed template, whatever the obvious non-AI solution would have been — to get your baseline. The baseline is the point of the exercise. Without it, the number you produce is decoration.

Second, compute the cost per task. Fifty sampled runs, logged token counts, published prices, a retry factor, and the date. Twenty minutes. Write down the trade you made in one sentence.

Third, write the seven parts in order, then delete a third of it. The first draft of part three will be six sentences long and needs to be three. The first draft of part seven will be a disguised strength and needs to be an actual admission. Both edits take five minutes and both materially change how the document reads.

Fourth, condense it to a hundred and twenty words and put it somewhere public. A write-up that exists only in a private repository is doing none of the work it is capable of doing. The talent gap is real — we have written about the scale of the AI talent gap and why Builder visibility matters — but a gap only helps you if the people trying to close it can see you.

Then repeat until you have three to five. Not more. The write-up is the reusable unit of your career: it works in an application, in a referral, in a cold message and in the first ten minutes of an interview, and it is the thing that makes a conversation about your compensation a conversation about evidence rather than about years of experience — which is the entire premise of our guide to negotiating for compute, eval time and tooling. A profile is simply where those units become discoverable by the people who are looking. Both halves are necessary. Either one alone is wasted effort.