How to keep an LLM from sounding like an LLM (on a CV)

I'm building a productized version of the continuous-CV setup I've been running for myself. The premise is plumbing-then-prose: bucket the day's git commits, calendar load, and done-log entries; roll them up by week; hand the structured digest to Claude; get back a CV section in markdown.

The plumbing is easy. The prose is the product.

A CV-rendering LLM will, if you let it, give you back exactly the language no one wants on a CV:

Owned the end-to-end stakeholder alignment for the high-leverage billing rewrite, driving outcomes that empowered the team to scale performant solutions.

You read that sentence and feel nothing. You don't know what they built, how big it was, or whether the company kept them. You only know they had access to a thesaurus and an MBA.

The instinct is to write a vague style instruction: "write tight, factual, engineering-grade prose." That doesn't work. The model has seen a million CVs and the gravity pulls toward the median. "Tight" and "factual" are aspirations the corporate-speak corpus already claims for itself.

What works is bans, with examples, in the prompt:

1. Banned filler verbs: owned, drove, leveraged, spearheaded,
   championed, facilitated, enabled, empowered, utilized.
   Replace with concrete verbs (built, shipped, wrote, fixed,
   migrated, deployed, scaled, debugged, designed, refactored).

2. Banned corporate-speak nouns: stakeholders, synergy,
   alignment, deliverable, learnings, ideation, bandwidth (as
   metaphor). Drop these — if a sentence requires them it
   wasn't worth keeping.

3. First-person implicit. Never say "I". Subject-elided
   declarative sentences only. "Shipped X." not "I shipped X."

4. Specific over generic. If a number, a system name, a unit, or
   a duration is in the source items, it goes in the prose.
   "Cut p99 from 450ms to 80ms" beats "improved performance."

A few things to notice:

Bans, not preferences. "Avoid filler verbs" is suggestion-shaped and the model treats it that way. "These specific words are banned" is rule-shaped. The model will route around the rule. That's what you want — the routing produces the specific verb you actually wanted.

Replacements listed inline. When you ban "drove," you have to give the model somewhere to go. "Built, shipped, wrote, fixed, migrated, deployed, scaled, debugged, designed, refactored" is a palette of verbs that describe what software engineers actually do. The model picks the right one because the source signal (a commit message) already tells it whether the work was new construction (built), a rewrite (refactored), a launch (shipped), or a deploy.

Bans on entire register. "Stakeholders," "synergy," "alignment," "deliverable" — these aren't bad words individually. They're a register. Banning the words bans the register. The output prose shifts from boardroom to engineering-blog without you having to describe what that means.

Subject-elided declarative sentences. This one's load-bearing. "I shipped the billing rewrite" reads like every other LinkedIn post. "Shipped the billing rewrite." reads like an engineer's commit message, which is what you wanted. The "I" forces a self-promotion posture; dropping it turns the same fact into a fact.

Specific over generic, with examples. This is where most prose- quality guidance ends. You can't just say "be specific" — the model will try and produce specific-sounding but actually vague output. The rule has to come with a contrast pair: "Cut p99 from 450ms to 80ms" beats "improved performance." Both look like the model is following the instruction. Only one of them is.

There's a related rule I keep coming back to: one sentence per item, two only if a second sentence carries a measurement or a 'because'. A CV is not a blog post. The reader is scanning. A three-sentence bullet earns its third sentence by adding a number or a reason, and otherwise has to die in editing.

The output now reads like:

- Shipped CertWatch MVP scaffold. $5/mo SSL + WHOIS expiry monitor with a 30/14/7/1 alert ladder, behind Stripe + magic-link auth. Built net-new overnight; landing page, daily cron, dashboard, and admin path all live. - Migrated 24 silent catches to the error pipeline across the Check on Mine iOS app. Every API failure in check-in, medications, and SOS flows now carries screen + action context to the backend instead of dying in print().

Not zero-LLM-flavored. But specifically not corporate-flavored. That's the achievable goal.

The full prose-rule block lives in EverCV's renderer source; if you'd rather get a continuously-updating public CV without setting up the engine yourself, it's the product I'm shipping. Or you can just read mine.

_Engineering content from someone who builds things this way for a living. More posts here, or drop a line if you want to compare notes._