Edited September 26, 2026. The original version described an earlier CareerOps architecture centered on GitHub intake issues and runner-triggered resume generation. The workflow has since evolved into a prompt-driven system with spreadsheet-backed state, reusable overlays, and a staged resume-tailoring pipeline. Dubnium automation is the long-term execution target rather than a claim about every step being automated today.
Most AI-assisted job-search tooling is optimized for throughput.
Mass-generated applications. Keyword stuffing. One-click submissions. Autonomous agents blasting resumes into applicant tracking systems.
That model has never interested me very much. The hard problem is not producing more applications. It is transforming professional history without silently changing what is true.
I learned that from a number I supplied myself.
The 20% problem
At one point I described a login flow as roughly 20% faster after a combination of platform upgrades, React state-management changes, and threading-model improvements.
The improvement was real and operationally obvious. The flow was visibly more responsive, and reduced contention and latency allowed the operating system’s password-manager popovers to work reliably again.
But 20% was not a benchmark result.
It was a guesstimate: a rough professional tax assigned to an obvious amount of inefficiency rather than a measured before-and-after result.
The AI did not invent the number. I did.
The failure was that it accepted the number without asking what kind of evidence supported it. Subsequent resume transformations repeated the percentage, and each repetition made it look a little more like a measured performance result.
The actual evidence looked more like this:
observed outcome:
visibly faster login flow
OS password-manager popovers became usable again
engineering causes:
platform upgrades
React state-management improvements
threading-model improvements
unsupported precision:
20% faster
That changed how I think about AI-assisted professional writing.
The important distinction is not simply human-written versus AI-written. It is supported versus unsupported.
AI can hallucinate. Humans can estimate badly. A transformation pipeline can also take a weak human claim and make it look increasingly authoritative without inventing anything new.
The better rule is:
claims should carry an evidence class, regardless of who supplied them
A useful minimum taxonomy is:
measured = supported by a repeatable baseline and result
estimated = explicitly approximate, with a stated basis
observed = operationally demonstrated without a numeric benchmark
inferred = derived from indirect evidence and clearly labelled
In this case, the defensible resume claim is stronger without false precision:
improved login responsiveness through platform upgrades, React state-management
changes, and threading-model improvements, restoring reliable OS password-manager
popovers
That failure became one of the design constraints for CareerOps.
A resume is a controlled transformation
A resume is not really a static document. It is a projection of a larger body of career evidence onto the needs of a particular role.
A practical model looks more like this:
canonical truth
+ reusable overlays
+ contextual emphasis
+ governance constraints
= application artifact
The canonical layer contains stable facts: employers, projects, responsibilities, technologies, outcomes, dates, and evidence quality.
An overlay changes emphasis without changing truth. It can move platform work forward for one role, application security for another, mobile architecture for another, or AI governance for another.
The generated resume is therefore not a new source of truth. It is an artifact.
That distinction matters because free-form rewriting accumulates drift quickly. A phrase gets strengthened. A number becomes more precise. A title gets rounded upward. A technology mentioned in context becomes a claimed specialty. After a few generations, nobody remembers which version was grounded in the original experience.
CareerOps treats tailoring as controlled transformation instead.
The architecture now
The system has become less about a single automation trigger and more about making the reasoning reusable.
The current shape is:
The important change is that prompts are now part of the system design.
I keep the stronger prompts in a meta repository rather than treating each chat as an isolated interaction. They encode the method: how to discover roles, how to compare them, how to curate career evidence, how to tailor it, and how to review the result.
The spreadsheet carries workflow state. It is useful for things such as:
- job sources used for discovery;
- discovered opportunities;
- active applications;
- interview or follow-up state;
- rejected, expired, or otherwise archived roles;
- the structured inputs needed by later prompt stages.
That makes the workflow easier to inspect than a conversational agent with a large hidden state. The prompts define transformations; the spreadsheet records operational state; generated resumes remain artifacts.
The system is still deliberately human-directed. A discovered role is not an instruction to apply. It becomes input to the next decision surface.
Prefer explicit control surfaces over mystery agents
I deliberately rejected a more autonomous design.
A lot of agentic tooling encourages systems that browse websites, mutate hidden state, make decisions without explicit checkpoints, and execute side effects in long chains that are difficult to replay.
Those systems can be impressive in demos. They are harder to govern when the artifact being mutated represents a person.
The failure modes are familiar:
- unclear provenance;
- hidden execution chains;
- weak replayability;
- difficult failure analysis;
- ambiguous consent at the point of action;
- confusion about where judgment ended and automation began.
CareerOps instead follows a simpler rule:
prefer explicit control surfaces over hidden autonomy
That does not mean every step must be manual. It means automation should have a visible trigger, bounded inputs, inspectable outputs, and a clear owner for the next consequential action.
Spreadsheet state is operational memory
Email is still an important signal source because it is searchable, timestamped, and useful for reconciliation. It can answer whether an application was acknowledged, rejected, moved to interview, or given a deadline.
But the workflow no longer depends on email or a GitHub issue as the primary operational memory.
The spreadsheet is a better fit for the recurring state machine:
sources
-> discovery
-> shortlisted
-> application
-> interview / follow-up
-> archive
Those categories are intentionally mundane. They make duplicate discovery, stale recommendations, and lifecycle drift visible.
The spreadsheet is not the source of professional truth. Career evidence still belongs in the canonical resume data. It is the source of job-search state: what has been found, what is worth attention, what has been acted on, and what should no longer be suggested.
This also gives the prompt system bounded inputs. A discovery prompt can read from the sources and archive views. A prioritization prompt can operate on the current discovery set. A follow-up prompt can operate only on active applications.
That is easier to reason about than asking one long-running agent to remember everything correctly.
Compose discovery with overlays
I increasingly think of CareerOps prompts as composable overlays.
A base discovery pass answers a broad question:
What opportunities are worth looking at?
An overlay then changes the decision lens without replacing the underlying discovery logic.
For example:
job discovery
+ current constraints
+ strategic role preferences
= candidate set
candidate set
+ top-10 overlay
= bounded review queue
The top-10 step matters because generating detailed analysis or tailored resumes for every plausible role is wasteful. It forces the system to spend more effort on ranking before synthesis.
This is not an attempt to turn fit into a single magic score. The point is to make the criteria explicit and reusable: role family, technical credibility, location and work model, compensation where known, strategic value, application cost, and any other current constraints.
The output is a queue for human judgment, not an autonomous application list.
Resume tailoring is a prompt sequence
The resume system still separates truth from emphasis:
BASE = stable career evidence + neutral framing
OVERLAY = role-family emphasis + vocabulary + ordering
CUSTOM = application-specific artifact
But the practical workflow is no longer best described as one AI pass that writes an overlay.
Tailoring is a sequence of higher-quality prompts with different responsibilities.
1. Curate the evidence
The first stage selects the subset of canonical career data that is genuinely relevant to the role.
Its job is mostly subtractive:
- remove weakly related material;
- preserve concrete technical evidence;
- identify unsupported or ambiguous claims;
- retain the strongest examples for the target role;
- keep evidence classes such as measured, estimated, observed, and inferred visible where they matter.
This stage should not optimize prose yet.
2. Tailor the content
The next stage maps the curated evidence onto the job.
It can change emphasis, ordering, terminology, and the amount of detail given to different projects. It can make an application-security version read differently from a platform or mobile-architecture version without inventing a different career.
This is where reusable role overlays remain useful.
3. Style and render
The final stage deals with presentation:
- concise bullet construction;
- section balance;
- role-appropriate vocabulary;
- ATS-safe formatting;
- deterministic DOCX/PDF generation;
- final consistency checks.
Separating these stages matters. A single prompt that simultaneously decides what is true, what is relevant, how to phrase it, and how to style the document has too much authority and too little observability.
A staged pipeline lets each transformation be inspected on its own terms.
Generated resumes remain application artifacts. They do not automatically flow back into the canonical base. Promotion requires review.
Versioned prompts now carry part of the provenance
Git still provides the right substrate for the pieces that need deterministic history, but the important versioned object is not only the generated resume.
The prompt library is part of the implementation.
Keeping the CareerOps prompts in a meta repository provides:
- reviewable changes to the reasoning process;
- reusable prompt sequences across roles;
- a place to improve failure handling once rather than in every chat;
- provenance for why a later run behaves differently from an earlier one;
- a boundary between durable workflow design and temporary conversational context.
The career-data side remains responsible for canonical resume truth and generated artifacts. The spreadsheet carries job-search state. Together, those are a much cleaner separation of concerns than putting every concern into one agent.
Dubnium is the long-term execution environment for automating this system.
The target is not an autonomous bot that applies for jobs. It is scheduled, bounded orchestration:
Dubnium scheduler
-> run discovery prompts against configured sources
-> reconcile spreadsheet state
-> produce bounded candidate sets
-> run overlays such as top-10 prioritization
-> queue resume curation / tailoring work
-> generate review artifacts
-> stop at human approval boundaries
AI models can change underneath that workflow. The valuable asset is the versioned method, explicit state, and bounded execution contract.
That is also why local infrastructure is useful: scheduling, model routing, tooling, secrets, and reproducible execution can evolve without changing the human approval boundary.
Failure modes become review rules
The system has accumulated a useful list of ways to fail:
- quantification drift;
- ATS overfitting;
- title inflation;
- hallucinated specificity;
- stale resume forks;
- duplicated bullets;
- formatting drift;
- application-status mismatch;
- duplicate job recommendations;
- duplicate synthesis runs;
- stale spreadsheet state;
- prompt drift or version skew;
- missing prioritization rationale;
- weak distinction between discovery, decision, and execution.
The common pattern is that AI often compresses ambiguity into certainty.
Sometimes that is exactly what summarization requires. It becomes dangerous when the output is a claim about professional history.
So the review boundary asks not only whether the AI invented something, but whether any transformation increased the apparent certainty of the source.
For a numeric claim, that means asking:
- What was measured?
- What was the baseline?
- Which changes contributed to the result?
- Is the number measured, estimated, observed, or inferred?
- Can the claim be defended independently of the number?
That last question is especially useful. If the accomplishment disappears when the percentage is removed, the number may be carrying more rhetorical weight than evidence.
The human boundary
AI is useful throughout this workflow:
- summarization;
- ranking;
- drafting;
- review;
- formatting;
- consistency checks.
But the human remains responsible for:
- truth;
- interpretation;
- approval;
- accountability;
- submission.
That is not a sentimental preference for keeping a person in the loop. It is a trust-boundary decision.
The final application represents a person to another organization. The system can prepare that representation, but it should not silently assume authority to make the commitment.
The broader pattern
CareerOps is a personal-scale instance of a more general governance problem:
How do you let AI transform important artifacts without letting it silently mutate truth?
The same design principles appear in governed software delivery:
- explicit control surfaces;
- policy-gated execution;
- reviewable artifacts;
- provenance-aware outputs;
- bounded automation;
- human approval for high-impact side effects.
The domain here is resumes rather than code, but the architectural shape is the same.
The most useful AI-assisted workflows are not necessarily the most autonomous. They are the ones where autonomy is bounded by evidence, intent, provenance, and clear authority.
For CareerOps today, that means a prompt-driven operational system: versioned high-quality prompts, spreadsheet-backed discovery and application state, composable overlays for prioritization, staged resume curation and tailoring, deterministic document generation, drift review, and human submission.
The next step is to automate more of that method on Dubnium: scheduled discovery, state reconciliation, bounded prioritization, and queued resume synthesis using the same reviewed prompts and explicit approval boundaries.
Not AI replacing professional judgment.
A professional systematizing it.