The usual AI resume flow looks like this:
old CV + job posting → LLM → improved CV
It has a basic flaw. My old CV was already a heavily trimmed version of my professional history. If I didn't think something was important and didn't write it down for ten years, the model doesn't know about it either. It can only rephrase what's already there.
I hit this while preparing for a job search. Over the last six months the way I develop software changed a lot: more and more of the mechanical work (reading a codebase, writing code, fixing, refactoring, part of the analysis) goes to AI agents. Formally I'm still a developer and tech lead, but "Android Tech Lead" describes less and less of what I actually do. So the real question wasn't how to phrase my resume. It was what job should I even be looking for next?
So I flipped the flow:
facts and context first → then AI → and only then a resume
The result is Career Portal, a private knowledge base about my own professional life. The resume turned out to be the last step.
Store the context the fact was true in
The portal keeps a profile, jobs, projects, skills and notes, and context is split by level:
- Profile: who I am and what I want.
- Job: what role I held during that period.
- Project: what I did there, with what stack, in what role, with what result.
This looks excessive until you describe several years at one company. At one employer I might have an Android project where I own the mobile app and the team, a Kotlin/Ktor BFF where I'm a backend developer and architect, and elsewhere KMP, internal tooling, CI/CD or platform work. Dump all of that into one "Work experience" field and the model mixes contexts: technology from one project lands next to an achievement from another, and a Tech Lead role spreads onto work where I was a regular developer.
The principle: it's not enough to save a fact; you need to save the context in which it was true.
There's also a private free-form "About me" field. Things like "I don't want this role anymore" or "I managed people here but don't remember the exact team size" aren't resume material yet, but they are context for the AI later. And I don't want every intermediate edit to a public CV to read as "he's job hunting again."
The most useful AI output wasn't text
After filling in the profile you can run a review. I expected the usual advice: trim, reorder, make wording stronger. Instead the agent started asking questions.
I wrote that I managed Android teams. It asked: exactly how many people? I wrote about working fully remote. It asked whether I'd consider hybrid in St. Petersburg. I listed several career directions. It asked which is a current goal and which is just an option.
At the job level it gets more uncomfortable, in a good way:
The job review (UI in Russian). Left: questions and weak spots, such as "you wrote 'sped up development several times', is there a number?" and "the Team field is empty". Right: recommendations and strengths, such as the crash-free 60% → 99.8% metric.
- "Significantly sped up development" → by how much? Did the release cycle go from six weeks to two? One release a month to four?
- "Reduced incident response time" → from what value to what value?
- "Moved development from a contractor to in-house" → team size, project scale, and what changed in timelines, cost or speed?
At the project level, one of my facts already had a clear before → after: crash-free rate went from roughly 60% to 99.8%. There was almost nothing to improve. Right next to it sat "significantly sped up development", which is clear to me because I remember the context and nearly empty to anyone reading the resume for the first time.
I always assumed metrics were mainly a manager's territory. It turned out I need them just as much to explain my own work: team size, devices in production, number of stores, releases, cycle time, error rate, operation volume. Not everything is money, but "I improved the process" and "before → after" are very different claims.
The most useful thing the AI did wasn't writing about me. It asked about the things I didn't think to write down.
Then: what can this experience even be called?
My problem wasn't phrasing Head of Mobile nicely. I wasn't sure I should be looking for Head of Mobile at all. I didn't want to pick a title and stretch a biography over it; I wanted to collect what I actually did first and see which roles follow.
The "Suggest a role" feature looks at the profile, experience, projects, stack and results, and proposes positioning options with reasons:
Role suggestions (UI in Russian). Each role gets a fit label, what to emphasize, and why it fits, citing facts from the profile.
My options included Head of Mobile, Mobile Engineering Manager, and later Lead Android Architect, Mobile Platform Lead and a few others. The AI doesn't decide who I should be. It proposes a hypothesis with arguments from my own history; I accept, edit or ignore it.
A saved role becomes a separate view of the same fact base. These aren't three versions of me, just different selections of real facts:
-
Head of Mobile: team management, hiring, moving development in-house, engineering standards, release processes. -
Lead Android Architect: Android/Kotlin, architectural decisions, stability, modernization, hands-on work. -
Mobile Platform Lead: CI/CD, platform mechanisms, feature toggles, KMP, internal infrastructure.
With one fact base and a model that isn't allowed to invent achievements, this is choosing which part of a real history is relevant, not bending a biography to a job posting.
Resume generation comes last, and publishing stays manual
After choosing a role, the portal can help search for postings in that direction and assemble a resume for the role, or narrower, for a specific posting. I deliberately avoided building it around "Am I an 82% match?". The question I want answered is: what from my actual experience needs to be shown for this resume to answer this posting's requirements? The posting becomes context for selecting facts, not a verdict on the candidate.
The result is saved as a separate resume, in the UI and as files, and the last step is manual: I decide what gets published. For career data I don't want an agent that invents a role, writes a document and sends it out with no human in between.
It isn't a programmer-only problem
Later I made the portal multi-user and loaded my wife's resume. She's an accountant. The same pattern repeated:
- How many legal entities were you handling?
- How many invoices did you issue per month on average?
- How many material write-off transactions?
- What was the monthly volume?
The mechanism has nothing to do with Android or Kotlin. A person writes "I worked on X"; the AI answers "what was the scale of X, and what backs that up?"; the person goes back to their real history and fills it in.
Stack and authorship
- FastAPI, Jinja2 and SQLite; no heavy SPA.
- The database holds a profile, jobs with nested projects, skills, education, notes, roles, generated resumes and job-posting data.
- PDF/DOCX import: text is parsed, a preview is built, and data lands in the database only after confirmation. Replacing an already filled profile needs separate confirmation.
- AI providers: Claude CLI, Codex CLI, and an OpenAI-compatible provider. Job board integration came after the first MVP.
The project kept its genesis trail. The master plan spelled out the roles: Claude in chat is the architect, Claude Code is the executor, I'm the owner. An agent wrote every line of the portal's code. I didn't write a single line, and I didn't read one either. My part was the task, the roles, the specs, and the decisions about what the product should be.
The honest result: almost nobody writes to me
I'm using the portal for a real job search. The resume is much more detailed and evidence-backed, I found plenty of gaps in my own history, added metrics, and looked at roles differently.
But there are almost no calls or messages, and I don't know why. It could be the market, my positioning, the resume itself, or I'm optimizing the wrong part of the process. One uncomfortable hypothesis: iterating on a resume with AI for a long time can land you in a local maximum, where the document gets more logical to you and the model without working better in actual hiring. I don't have data to state that as a fact.
So I don't claim the portal solved my job search. It solved a different problem: my professional history is stored separately from its publications, claims were turned into evidence, I saw several possible roles, and I can build different resumes from one fact base. Whether they work is up to the market.
Takeaway
A resume is a temporary snapshot of a career, not its storage. What matters comes earlier: facts, context, projects, real roles, scale, numbers, preferences and constraints.
If that base is weak, AI rewrites weak material nicely. If it's good, AI can find a gap, ask an uncomfortable question, suggest an unexpected positioning, and assemble different documents from the same history. What I don't hand over: deciding who I should be, inventing achievements, deciding whether to apply, and publishing the final version.
I wanted AI to write about me better. First I needed to know and prove my own professional history much better myself.
The full case study, with more screenshots of the portal, is on my site: https://hram.github.io/en/articles/career-portal/


Top comments (0)