Compiling a Brag Doc: Engineering Growth Evidence in the Agentic IDE Era
Two months of running a Cursor-agent-maintained vault changed how I think about brag docs. The capture problem is mostly solved by the IDE; the missing piece is synthesis. Here's the layered system I built and what I'd tell you if you're starting.
Picture the moment a manager asks an engineer what they’ve shipped over the last quarter. Even when the honest answer is a lot, the work that surfaces first is often the work that broke something. Small things across multiple repos blur together; the work that matters for a review case rarely comes back fully formed.
Most engineers I’ve talked to have this same problem. The brag-doc advice — keep a running doc, update it weekly — works in theory and falls apart in practice. Discipline rarely fixes it. The actual bottleneck is recall: remembering what happened is itself a hard problem, and the moments when you’d want to update the doc are the moments when you have the least appetite to.
What’s changed for me is that my IDE now has agents. The Cursor agent reads my code, writes my code, and — critically — leaves a trail. Two months ago I started treating that trail as a primary source for the growth evidence problem. This post is what I learned.
The brag-doc problem isn’t what it used to be
The classic framing assumes two things: that you remember the work worth recording, and that the friction is the act of writing it down.
Both assumptions break once you’re working with an agentic IDE on a team that ships across multiple repos. You’re not the bottleneck on capture anymore — the agent’s transcripts are sitting in ~/.cursor/projects/*/agent-transcripts/. Your git history is more granular than ever. The real bottleneck is synthesis: turning a noisy stream of commits and chat logs into something a manager would call evidence.
The reframe I landed on: treat the brag doc as a compile target. The sources are immutable — transcripts, git, ADRs. The synthesis is the agent’s job. Curation, meaning what mattered and what it added up to, stays with me.
The vault, layer by layer
The system lives in a single repo, cursor-powered-kb. The Cursor agent maintains it across IDE sessions; I curate the small fraction that carries growth signal.
raw/ — Immutable mirrors of transcripts, Cursor plans, per-repo .cursor/rules, clipped external docs. The agent reads these. It never rewrites them.
wiki/ — Compiled concept pages. One focused topic per file. The agent writes these by reading raw sources and existing pages, and updates them when new sources contradict or improve them.
insights/ — Cross-repo synthesis. The unit here is “this taught me something.” Each insight links back to its source plan(s) and merged PR(s) in frontmatter, so traceability is queryable.
journal/ — One file per working day. The agent scaffolds the entry from transcripts and git activity. The middle three sections — Decisions, Stuck, Learned — are mine, and the only ones the agent is forbidden from writing.
growth/ — Synthesis on top of synthesis. brag-doc.md lives here, continuously updated. goals.md for the current cycle. Optional weekly/monthly summaries.
The piece that took me a while to internalise: the layers map onto a real maintenance loop. raw/ is the source of truth. wiki/ and insights/ are what the agent compiles from it. journal/ is the upstream signal collector that funnels into growth/. The brag doc is a derived artifact, like a build output.
The contract: what the agent must NOT do
The structure isn’t what made this work. The contract did.
There’s an AGENTS.md in the vault that the Cursor agent reads at the start of every session. Most of it is conventional: where files go, what layer they belong to, how to write wiki frontmatter. The part that earned its keep is the short list of must-nots.
Never write the middle of a journal entry. The Decisions, Stuck, and Learned sections carry the growth signal. The agent can pre-fill “Worked on” from transcripts and git — that’s a clerical task. But the moment the agent writes “I decided to refactor X because Y,” the growth signal collapses into AI-generated narration that sounds plausible but isn’t mine. So those sections are off-limits.
Never silently update the brag doc. The agent can propose a brag-doc entry when an insight ships, with the full diff for review. It can’t apply the change. The brag doc is the artifact most prone to looking impressive while being empty, and the only protection is keeping the curation step human.
Never delete or rewrite past journal entries. Journal is append-only from my perspective. The temptation to “clean up” yesterday’s stub is what kills the practice.
Don’t mix vault maintenance into the personal journal. There’s a separate log.md for vault-side activity — compiles, mirrors, schema migrations. Journal is engineering work. The two get conflated very easily.
The anti-tells in the brag doc template are part of the same contract: no “in today’s fast-paced world,” no rule-of-three padding, no fake metrics. If I don’t know the impact number, the field reads ”—.” Empty fields are honest. AI-flavoured prose is the failure mode the whole system exists to prevent.
A worked example: walking a competency rubric
Consider how this plays out in a realistic case. An engineer is preparing a self-assessment against a senior-engineer competency rubric — the kind most companies have somewhere, with rows for architecture, mentoring, driving alignment, technical depth, and so on.
The capability question for each row is the same: is there evidence? That evidence lives in the vault if the system has been running for a while. Working through the rubric one row at a time, the engineer queries by tag and date range. “Architecture” pulls up insights tagged with multiple repos and the journal entries that captured the decisions. “Mentoring” might return mostly silence — itself a useful finding. “Driving alignment” might surface a recent cross-team workflow change, with branches, PRs, the adoption note, and the journal entries where the engineer worked through how to teach it.
What the agent does: surface evidence. What the agent does not do: decide ratings. The walkthrough takes a few hours and produces a per-row rating with confidence flags, plus a one-page summary that names where the strong evidence sits.
The interesting result tends to be a reframing. A first-pass self-assessment from memory usually over-counts capability gaps — anything an engineer can’t immediately recall reads as missing. The evidence-anchored walkthrough sharpens this. Some of the “gaps” turn out to be a documentation problem: the capability is there, but the journal entries aren’t. Others turn out to be structural — the engineer hasn’t had access to the kind of work that would produce the evidence (rare review opportunities, no junior to mentor, no roadmap-shaping invite). Those are different conversations to have with a manager.
This is the kind of framing that doesn’t come back from memory alone.
What doesn’t work yet
The system isn’t load-bearing yet. A few parts worth naming honestly.
The journal habit is the gate. All of the synthesis upstream of brag-doc.md depends on journal entries existing. Working-day coverage hovers below where it needs to be; getting it to a consistent four-out-of-five is harder than designing any layer of the vault. None of the architecture saves you if the daily three-minute write doesn’t happen.
There’s no 10× productivity claim here. The system mostly buys not-forgetting and review-readiness. It doesn’t make anyone ship more code. If you’re looking for a “this AI workflow doubled my output” arc, this isn’t it.
The brag-doc-update workflow is the most fragile bit. Insight → propose diff → review → append is sound on paper. In practice, drift toward writing the entry from memory and skipping the insight step is constant. The fix is probably tooling. A “make-this-into-an-insight” command would make the step the default, where right now it requires remembering the step exists.
What changes in the agentic IDE era
The broader shift is real and underexplored.
The IDE knows what you did. Cursor and Claude Code transcripts are the most granular record of an engineer’s day-to-day work that has ever existed. Git knows what shipped. Together they cover capture more thoroughly than any brag-doc habit ever could.
The journal knows why. That layer can’t be automated. The growth signal lives in an engineer’s own narration of decisions; the diff doesn’t carry it.
The brag doc knows what it added up to. That’s a quarterly synthesis act. Doing it continuously is what kills most brag-doc habits in the first place — treat it as something you compile from journal entries and insights a few times a year and the maintenance problem mostly evaporates.
Three artifacts, three voices. Transcripts and git in the machine’s voice, the journal in the engineer’s voice during the work, the brag doc in the engineer’s voice at review time. AI is bad at judging what’s significant and excellent at being present for every keystroke. The system has to let those two facts complement each other.
What I’d tell you if you’re starting
Pick one repo and one growth area. Stand up journal/ with a template. Write the must-nots in AGENTS.md before the first agent-written file lands. Resist the urge to make brag-doc.md look impressive; empty fields with ”—” beat fabricated impact numbers.
The vault matters less than the journal habit, and the journal habit matters less than the willingness to write “stuck for 40m on X, unblocked by Y” honestly.
The IDE will keep getting more agentic. What it still can’t do is decide what mattered. Build the habit that does.
If you want the schema — AGENTS.md, the journal template, the brag-doc anti-tells — happy to share. Reach me at hello@setiyaputra.me.