No Code Shipped: Running A Job Search Like A Software Project, With An AI That Prepares Everything And Sends Nothing

By Juste Thales Gnimavo (CEO, ZeroSuite) & Claude Opus 5.5 — Claude Code instance

Everything on this blog so far has been about software: deploy pipelines, payment gateways, a programming language, a fleet-management ERP. This post is about a job search.

On September 24, 2026, the CEO opened a session with a request that had nothing to do with a ZeroSuite product: run a job search, from the first letter onwards, with the tooling we use to ship software. We are not describing the candidate here: not their trade, not their employer, not where they live. What is worth copying is the method, and the method does not depend on the trade. To show that, the examples below rotate on purpose through five of them: a developer, a nurse, a salesperson, an accountant and a site manager. They are illustrations, not the real case.

By the end of the day the search had:

• a repositioned personal website;
• two CVs and two cover letters, one for the target role and one for the current role;
• two e-mail templates;
• a first application ready to send;
• a 32-question interview preparation;
• a private git repository with one folder per employer;
• a single tracking file;
• a CASP cockpit whose roadmap does not end at "applications sent" but at "contract signed".

No product code was written. The session ran in Claude Code, the only tool we name in this post; everything below works with any AI assistant that can read and write files in a folder.

Part 1 — Treat the job search as a project, not as a pile of documents

The first real decision was structural. The CEO's instinct was the natural one: a folder with the CV and the letter, and a list of e-mail addresses in a notes file. That works for three applications. It falls apart at fifteen, when you no longer remember which letter version went to which employer, whether the follow-up was sent, or which CV the second recruitment firm received.

So we did what we do for a product:

One private git repository per candidate, separate from the public website. The website redeploys on every push. The application files must never ride along with a site deploy, and the site must never be touched by an application commit. Two repos, two lifecycles. The application repo can take a commit every ten minutes without anything going live.

One folder per employer, named in capitals with hyphens (EMPLOYER-A/, RECRUITER-B/). Each folder holds the personalized letter (DOCX and PDF), the e-mail as a plain-text file, and a copy of the PDFs exactly as sent. The master CV will evolve; what a given employer received must not.

A _commun/ folder with the masters: two CVs (target role, current role), two generic letters, two e-mail templates with [bracketed] placeholders and one rule written at the top: no bracket may survive in a sent e-mail.

A _entretien/ folder for interview preparation.

One tracking file, and only one. suivi-candidatures.md has one row per application: entity, target role, type (spontaneous or published offer), channel, folder, status, sent on, follow-up, notes. The statuses are a fixed chain: to prepare → ready → sent → followed up → interview / rejected / no answer.

The CEO asked for a green check-mark emoji on each submitted row. Claude declined, and the reason matters more than the emoji rule (ZeroSuite has a no-emoji policy everywhere). A check-mark is a claim with no evidence; a date is evidence. The rule we wrote instead: a row is submitted if and only if the "sent on" column holds a date. When you have twenty rows, you cannot fake that one by accident.

Part 2 — Letters: the AI's job is to refuse the unprovable sentence

The CV and letter content went through the same review discipline as a pull request, and the most useful moments were refusals.

The records sentence. The candidate's real strength, according to the CEO, is speed. The CEO's draft sentence said the candidate "beats almost every record". Claude refused it: nobody publishes those leaderboards, and a recruiter who asks "which records?" gets no answer. What we kept is a comparison the candidate can defend in an interview, measured against their own team, paired with the counterweight a recruiter actually worries about: speed that costs accuracy.

The rule generalizes to every trade: replace the superlative with a fact that a reference could confirm.

Absolutes go out with the superlatives. "Never a single mistake" is believed by nobody and invites exactly the wrong interview question.

No internal figures, no criticism of the current employer. Volumes, rankings and the reasons for leaving stay out of every document. The repo's rules file carries them, under the name the assistant loads automatically at the start of every session, so the future offer-watch agent inherits them without being told.

One letter structure, derived per role. The target-role letter opens on what that role is judged on and has one paragraph on the step up: coordinating others, owning a larger scope. For a developer moving to tech lead, that paragraph is about reviews and unblocking the team; for a site manager moving to works manager, it is about running several sites at once. The current-role letter is the same letter with that paragraph replaced by one about the candidate's own scope. We diffed the two rather than writing a second letter from scratch, so the claims cannot drift apart.

Which CV goes where is a rule, not a mood. Employers get the target-role CV. Recruitment and staffing firms get the same CV with an e-mail open to "target role or current role": a firm places people on its own missions, and closing a door there gains nothing. The current-role CV is reserved for published offers for that role. One subtle point went into the rules file: a placement through a staffing firm can reproduce exactly the contract setup the candidate wants to leave. It is only worth taking if the role is a step up or the hiring is direct.

The e-mail is a summary, not a cover note. The first e-mail draft read like a circular ("please find attached…"). The CEO rejected it: the e-mail must make the recruiter want to open the letter. The result is a three-paragraph summary of the letter, opening on the employer's need, not on the candidate.

Part 3 — Interview preparation as a test suite

The interview document is 32 questions in six sections, each with a coached answer. Section 3 was added late in the day at the CEO's request, and it is the one we would recommend to anyone: tools, incidents and security. Generic "top 50 interview questions" lists never contain it, and it is where an interview for a role with responsibility actually turns.

Write down the incident questions of your trade, the ones a recruiter who has done the job would ask:

• Developer: production goes down on a Friday evening and the last deploy was yours. What do you do in the first ten minutes?
• Nurse: you notice a dosage error after the medication has been given. Who do you tell, in what order, and what do you write down?
• Salesperson: a key client disputes a signed order and threatens to leave. What do you concede, and what do you not?
• Accountant: the account reconciliation does not balance the day before the close. Where do you look first?
• Site manager: a delivery arrives non-compliant on the morning the slab is due to be poured. Do you stop the pour?

Add the questions that are the same everywhere now: which tools of the trade you use and how well you know them, and what you do when someone calls claiming to be "IT support" and asks for your password.

Part 4 — CASP: a roadmap that ends at a signed contract

CASP (the Coding-Agent State Protocol) is the tool we open every working day on every ZeroSuite product. It's a casp/ folder in the repo: a state.json, a now.md and a roadmap.md, plus a validator, casp check, that proves the recorded state still matches git and refuses the push when it doesn't. The CEO asked for it here in passing, having forgotten it at the start of the session: install CASP in the application repo and fill it in until the job is signed.

casp init scaffolds the cockpit in a second. The work is in writing the state honestly:

The last line of now.md says it plainly: the cockpit closes the day the contract is signed. That is the part we would push hardest on anyone copying this. A job search tracked as "applications sent" measures activity. A roadmap ending at a signature measures the outcome, and it forces the uncomfortable phases (follow-ups, negotiation, notice period) to exist on paper before they arrive.

Three things CASP gave us that a notes file would not:

1. "Where are we?" has a one-screen answer. casp status prints the current phase, the next session prompt and the last commits. The next working session starts from docs/plan/sessions/PHASE-2-PREMIERE-VAGUE.md, not from memory.

1. Decisions get recorded as decisions. The CEO decided to apply to a published offer that Claude flagged as a step down: a fixed-term contract with entry-level requirements, against the candidate's current permanent contract. Claude recommended preparing it last, with a salary expectation at least equal to current pay. The CEO kept the decision, and the log records both the decision and the reservation. Three weeks from now nobody will have to reconstruct why that folder exists.

1. Open questions are listed, not remembered. The roadmap has a "Blocked / to decide" table. Midway through the session it held three items:
2. - two recruiter addresses whose company we couldn't identify yet;
3. - a salary expectation the offer requires;
4. - a hand edit the CEO had made to an e-mail template, which contradicted its body.

The last one was resolved within the hour (employers get the target role in the subject line, staffing firms get "target role or current role"), and it left the table in the same commit.

casp check ended the day at 18 PASS, 0 WARN, 0 FAIL. For a repo with no code in it, that is not decoration. It means the state file, the session log and git agree, which is the whole point when the next session, or the next person, picks it up.

The public website got its own section in the same roadmap rather than a second cockpit, because it serves the same outcome. It records what is deployed, one small commit waiting for the next push, and a last task for phase 5: on signature, remove the active job search from the site.

Part 5 — Offer watch and mail: prepare everything, send nothing

The CEO's original plan included handing the agent the SMTP credentials of the candidate's mailbox so it could send the plain e-mail applications itself. The online forms would stay manual.

We designed it the other way round, and the rule is now the first line of the repo's rules file: the agent never sends anything. The reasoning:

• Volume doesn't justify it. A first wave is under ten applications. Sending each takes the candidate under two minutes.
• A job application can't be taken back. A wrong attachment, a leftover [placeholder] or a letter naming the wrong employer is visible to the recruiter forever. The human send is the last review, and it's cheap.
• Deliverability is the candidate's reputation. The candidate's domain has SPF, DKIM and DMARC, and at least one target employer filters mail through an enterprise gateway. A burst of scripted sends from a new mailbox is exactly what those filters are built to catch.

What the automation will do is everything before the send:

1. Watch offers. It checks job boards and employer career pages, with no LinkedIn scraping (its terms forbid it), and deduplicates against the tracking file: one application per employer per role.
2. Prepare the folder. It creates the employer folder, personalizes the letter from the master, exports the PDF through Word and checks it: one page, text re-read with pdftotext, a rendered PNG looked at. It writes the e-mail file and sets the row to ready.
3. Leave the send to the candidate. The candidate reviews and sends. The row moves to sent only when they fill in the date.

Filter on the trade, not on the title. A job title is a label each employer defines for itself. "Consultant" covers a developer on a client mission and a salesperson on commission; "technician" covers a laboratory, a server room and a building site; "coordinator" covers a ward, a project and a sales territory. In our case, the raw results for the target title mixed in a different job from another sector, about half of them. An agent that filters on the title returns noise. Filter on the tasks and the context instead:

• Developer: the stack and the kind of product, not "engineer".
• Nurse: the department and the shift pattern, not "nurse".
• Salesperson: what is sold and the length of the sales cycle, not "business developer".
• Accountant: the scope (general ledger, consolidation, tax) and the size of the entity.
• Site manager: the type of works and the size of the sites.

Write the filter into the repo's rules file, next to the content rules, so the agent inherits it.

The SMTP and IMAP credentials live in a .env that is git-ignored from the first commit. Their best use is not sending. It is placing the prepared e-mail, attachments included, in the Drafts folder of the candidate's own mailbox, over IMAP. The candidate opens their mail client, reads the draft, presses Send. That is the phase-3 design: not built yet, recorded in the roadmap, and the same design we would recommend to anyone.

Part 6 — One production incident, because there is always one

PDFs were exported by driving Microsoft Word from a script. For one export the script brought Word to the foreground, while the CEO was typing in another window. Three of his keystrokes landed in the title of the interview document.

Claude caught it by re-reading the exported PDF's text, not by trusting the export's exit code. It re-exported the document and removed the activate call from the script, with a comment saying why. Then it compared every other PDF exported that day, word for word, against its source. Only that one had been affected. The lesson is a ZeroSuite constant: an export that ran is not an export that is correct; read the output. It applies just as much to a cover letter as to a build artifact.

How to copy this for your own job search

You don't need our stack. You need the shape, and an AI assistant that can read and write files. The whole workflow is also available as a step-by-step PDF guide, with the folder layout, the tracking file, the prompts and the checklists: download the job-search guide (PDF).

1. A private repo (or a folder under version control) separate from anything public.
2. Masters in one place, one folder per employer, with the PDFs frozen as sent.
3. One tracking file where a row counts as sent only when it has a date.
4. Written content rules (no superlative without a fact behind it, no internal figure, no criticism of your employer) that any assistant, human or AI, must follow, in a file your assistant loads at the start of every session (or reads first, on your instruction).
5. Interview prep as a test suite, built on the incident and security questions of your trade.
6. An offer filter on the trade, not on the title.
7. A roadmap that ends at a signed contract, with follow-ups, negotiation and notice period on it from day one.
8. Automation that prepares and never sends. Put the drafts in your mailbox, then read them and press Send yourself.

With CASP, the roadmap gets a validator: npm i -g @justethales/casp, then casp init in the repo.

CASP — the Coding-Agent State Protocol. Your AI agent runs the whole roadmap, and can't lose the thread. Git-native, local-only, MIT, zero telemetry. Built by Juste Thales Gnimavo of ZeroSuite, a solo CEO whose products run in production with Claude as the only engineer. Install: npm i -g @justethales/casp · https://casp.sh · https://github.com/ThalesGnimavo/casp