End of fiscal year, so you get to write your final review: dig up what you did over twelve months, work out why any of it mattered, and say so in a way somebody two levels up will actually read. With one project that’s annoying. With several running at once I lose track of my own year.

I spent three hours on mine and none of it on writing. I’m lazy in the way most engineers are lazy, so the three hours went into a prompt that pulls numbers out of git history, Terraform files, Ansible inventories, docs and cloud spend reports, then builds the review around whatever it found.

What comes out is a document with real numbers in it, written in the register leadership already reads. Close enough to hand over as is.

I’m bad at self-promotion

Most technical reviews I’ve read, mine included, look like this:

“Improved infrastructure. Consolidated agentpools. Reduced costs.”

Between engineers that’s plenty. You know what consolidating agent pools involves and roughly what it’s worth.

Your manager’s manager doesn’t. There’s no number in it, so there’s nothing to compare it against. There’s no business consequence, so there’s no reason to care. And whatever was actually hard about it, the tickets thrown over the wall, the missed SLA, the release train you were late for, doesn’t appear at all, because you wrote down the outcome and skipped the fight.

You remember “consolidated agentpools.” What your manager needs is “73% infrastructure reduction delivering $xx annual savings while maintaining 100% uptime for Y projects across X organizations.”

That translation takes hours, and it’s creative writing, which is the work I’m worst at and least willing to do.

Self-discovering prompts

Most AI review attempts fail the same way. They ask you to feed in every metric by hand, and since they know nothing about your projects, what comes back is corporate filler with holes where the numbers should be. Answering twenty questions to get that’s worse than writing it yourself.

So make the prompt go and look. Start with the filesystem:

## Phase 0: Repository Structure Discovery
Run these commands to discover infrastructure paths:

# Terraform configurations
find . -type f -name "terraform.tfvars" 2>/dev/null

# Ansible inventories
find . -type f -path "*/inventory/group_vars/*.yml" 2>/dev/null

# Documentation
find ./docs -type f -name "*.md" 2>/dev/null

Self-discovery adapts to whatever layout the repo has, so the same prompt works on the next project without reconfiguration.

Then old commits, because that’s where the “before” state lives:

# Count VMs 12 months ago
git show HEAD~200:infrastructure/terraform/main.tf

# Compare current vs historical
git log --since="2025-07-01" --until="2026-06-30" --oneline --all

That’s how you get “Before: N VMs across X agent pools. After: M VMs across Y pools (48% VM reduction, 73% pool consolidation).” Nobody remembers the before number a year later. Git does.

Anything that isn’t in the repo comes from an API:

# Count projects using your infrastructure
az devops project list --org https://dev.azure.com/YOUR_ORG | jq '. | length'

# GitHub Actions usage
gh api /orgs/YOUR_ORG/actions/runners

“X organizations, Y projects” beats “hundreds of projects”, and the gap between them is one call.

What a good review prompt does

I’ve built three of these now: an annual summary, a universal template, and a domain-specific one. The same two things keep mattering.

It forces quantification. Don’t ask “what did you do”. That question invites prose. Ask things that can only be answered with a number:

### Scale & Complexity
- How many users/teams/organizations affected?
- How many systems/services/components touched?
- Concurrent usage/traffic/volume metrics?
- Cross-team/cross-org coordination required?

### Quantified Results
- Infrastructure: VM counts, regions, compute resources (before/after)
- Cost: Before/after spend, savings, efficiency gains
- Performance: Latency, throughput, uptime improvements

“Describe your accomplishments” gets you a paragraph. This gets you “X organizations, Y projects” instead of “many teams”.

And it translates, which is the part I have complicated feelings about:

Don’t Say Say Instead
“it works better” “operational resilience”
“uptime” “business continuity”
“devs are happy” “developer productivity”
“major reduction” “X% reduction” (quantify)
“we added DR” “eliminates single points of failure”

Your manager’s manager doesn’t care about better uptime. They care about business continuity protecting the revenue stream that runs on top of it. It’s the same fact pointed at a different person, and I still find typing the second version slightly humiliating.

Where it fails hardest

“What I learned” is where I spent most of my editing time. The model produces one of two things. Generic fluff: “I learned the importance of teamwork and communication.” Or a mechanical formula: “this taught me that leadership is 30% tech, 70% people.” The first says nothing. The second screams AI, because nobody arrives at a percentage split by living through something.

What works is the specific thing you couldn’t have read in a book. Start with the organizational problem, say what you tried that didn’t work, say what did, finish on whatever surprised you.

The model has none of that. No failed attempts, no surprises, nothing that left a mark. The prompt gets you most of the way there - structure, numbers, business framing - and then stops. What’s left you write by hand, and it’s the only part anyone remembers.

(Yes, I nearly wrote “70% / 30%” in that paragraph. See two paragraphs up.)

The part I don’t feel good about

Read that translation table again. I built a machine that turns “uptime” into “business continuity”. I started this because I hate corporate writing, and what I did about it was produce more of it, faster, with my name on the output.

The discovery half I’d defend without blinking. Counting VMs in a commit from last July is accounting, and doing it by hand was never a test of anything except patience. The generation half is different. It makes me read better than somebody doing identical work who writes their review plainly, and that gap is tooling being scored as impact. I don’t have an answer for it. I’m still using it.

Making it reusable

After the domain-specific prompts I pulled the shared parts into one template. The questions cover the project context (what problem, who was affected, what it was costing), the scale, the numbers before and after, the business impact, and then the organizational side: who you had to align, whose priorities competed with yours, how you built trust. That last group is the one everybody skips and the one that carries the promotion case. The domain only changes which metrics you go looking for: VMs and spend for infrastructure, events per day and query latency for data, onboarding time for developer experience.

The output is always the same shape: achievements table, metrics table, five sections of organizational value (risk, cost, productivity, scalability, operations), then the “what I learned” narrative you write yourself. Fifteen to twenty minutes of answering questions and the document exists.

My year had three projects: an infrastructure consolidation, Docker-in-Docker on Kata Containers, and a couple of vendor bugs I found and escalated, one in GitHub and one in the Azure DevOps API. One review per project, stapled together, worked better than trying to write a single document about all three. The summary on top describes the portfolio rather than the projects: what got cheaper, what got escalated, who depends on any of it.

Start with one project

Don’t build the universal template first. Build the smallest thing that works:

Generate a performance review for [PROJECT_NAME] covering [START_DATE] to [END_DATE].

## Discovery

Run these commands:
- `git log --since="START_DATE" --oneline`
- `find . -type f -name "*.tf"` (or your config files)

## Questions

Answer these:
1. What problem did this project solve?
2. How many [USERS/PROJECTS/SYSTEMS] were impacted?
3. What metrics improved? (cost, performance, time)
4. What was organizationally hard about this? (not technical)

## Output Format

Goal | Success Criteria | Employee Perspective

Where Employee Perspective includes:
- Context: The problem
- Results: What you delivered (with numbers)
- Impact: Business effect
- What I learned: 4 sentences showing scale, org complexity, relationships, insight

Run it on something small and check two things: whether the numbers are right, and whether the narrative sounds like you. Then show it to your manager and ask whether it captures the impact. My first version produced “managed infrastructure for many projects”. After I added the API discovery it came back with the actual project count and the actual number of organizations. Same work, completely different document.

Twenty minutes, and the output is better than what hours of manual writing gets me.

What went wrong on the way

I used the calendar year in the first version. Most large orgs run July to June, so half of what I’d shipped landed in the wrong review period. The dates are parameters now:

Fiscal year calculation: July 1 YYYY-1 to June 30 YYYY

Cost data has to come from you. The model can’t open a cloud portal or a finance report, it doesn’t know budget against actual, and left alone it will fill the gap with something plausible. So the prompt stops and asks:

**IMPORTANT:** Before generating Cost Optimization section, ASK USER for cost data.
DO NOT proceed without actual numbers.

“What I learned” needs a length floor too. One sentence is a shrug: “I learned that infrastructure work requires stakeholder coordination.” Four to six sentences forces you to name the scale, the organizational dynamics and at least one real example. Put the number in the prompt, because the model will never choose to write more than it has to.

If you share any of this publicly, strip it first. The employer becomes “a large Fortune 500 enterprise”, exact project counts become “thousands”, colleagues become roles. Internally do the opposite and keep the real numbers and the real names, because specificity is most of what makes it credible.

The prompt is a mirror

Forcing the model to quantify my impact forced me to find out what my impact was.

How many projects use this? I didn’t know. I had to query the API, and the answer had four digits in it.

What’s the cost reduction? I didn’t know. I had to go and pull the real numbers. 51%.

What was organizationally hard? I’d forgotten. I had to read back through old threads to remember who I’d needed to convince, and in what order.

I did the work and I still couldn’t answer three questions about it from memory. The prompt shows you what you built instead of what you remember building, and that turned out to be worth more than the document it produced.

Which leaves me somewhere odd. The output I built the whole thing for is the part I’d throw away first, and I’m still going to submit it. Make of that what you like…