No Code Shipped: Running A Bank Teller's Job Search With An AI CTO And CASP, From The First Letter To The Signed Contract

By Thales (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 Claude Code session with a request that had nothing to do with a ZeroSuite product. Someone close to the team works as a teller in a commercial bank in West Africa: four years at the paying counter, before that several years at the front desk of other banks. She wants to move up to head cashier (chef de caisse): the person who runs the tellers, loads the ATMs, and signs off on the day's cash position. She had a personal CV website, a CV, a cover letter, and a list of recruiter e-mail addresses gathered by hand.

By the end of the day she had:

• a repositioned website;
• two CVs and two cover letters;
• 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 tooling was the same one we use to ship software, and it held up well in this context.

We are not publishing her name, her employer, the banks or the addresses. The workflow is what's worth copying, so that's what this post covers.

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 bank, 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 (Easypanel watches main). The recruitment files must never ride along with a site deploy, and the site must never be touched by a recruitment commit. Two repos, two lifecycles. The recruitment repo can take a commit every ten minutes without anything going live.

One folder per employer, named in capitals with hyphens (BANK-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 bank received must not.

A _commun/ folder with the masters: two CVs (head cashier, experienced teller), 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 speed claim. The candidate's real strength, according to the CEO, is speed: she's naturally fast and tireless, with very short handling time per client. The CEO's draft sentence was that she "beats almost every record". Claude refused it: nobody publishes teller leaderboards, and a recruiter who asks "which records?" gets no answer. What we kept is true and she can defend it in an interview: her handling time per client is among the shortest in the branch. The letter pairs it with the counterweight a head-cashier recruiter actually worries about: speed that costs accuracy. "…without speed costing accuracy: my positions are reconciled every evening."

The "zero discrepancies" line. An earlier CV said her cash drawer never had a discrepancy. It came out everywhere. Nobody in a bank believes it, and it invites exactly the wrong interview question.

No internal figures, no criticism of the current employer. Transaction volumes, branch rankings and the reasons for leaving stay out of every document. The repo's CLAUDE.md carries these as rules, so the future job-scraping agent inherits them without being told.

One letter structure, derived per role. The head-cashier letter opens on what a head cashier is judged on (queue speed, cash security, a correct position at closing) and has a paragraph on running the whole counter: staffing the tellers for the rush, loading the ATMs before the peak, unblocking an operation so the line doesn't stop. The teller letter is the same letter with that paragraph replaced by one about her own counter. 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. Banks get the head-cashier CV. Recruitment and staffing firms get the same CV with an e-mail open to "head cashier or experienced teller": a firm places people on its own missions, and closing a door there gains nothing. The teller CV is reserved for published teller offers. One subtle point went into the rules file: a placement through a staffing firm can reproduce exactly the contract setup she 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 bank'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: software, incidents and security. It covers:

• which banking software you use and how well you know it;
• what you do when the system goes down with a queue in front of you;
• an operation validated in the system but the client not paid;
• the money-transfer network being down;
• a fake "IT support" call asking for your credentials;
• ATM-loading security;
• a robbery.

These are the questions a head-cashier interview actually turns on, and none of them appear in generic "top 50 interview questions" lists.

The CEO also asked Claude to read a recruitment firm's public page about head-cashier profiles, looking for arguments. There were no job offers on it, only a marketing page. Claude found one real insight in it, though. Of the ten "head cashier" profiles the firm showcased, about seven came from outside banking (retail, construction, chemicals, healthcare), and every one of them claimed at least five years in the role, half of them over ten. In that market "head cashier" also means the cash desk of a supermarket. So her argument is not seniority but banking-specific cash work: ATMs, currency exchange, money transfers, the daily closing. It also gave the future search agent a hard filter: "cash" plus "banking sector", or half the results are supermarkets.

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 recruitment repo and fill it in until she has a job.

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 she signs. 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. Tonight, when the CEO and the candidate sit down to build the next application folder, the next 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 teller offer at a microfinance institution. Claude flagged it as a step down (a fixed-term contract, entry-level requirements, against her current permanent contract) and recommended preparing it last, with a salary expectation at least equal to her 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 (banks get "head cashier" in the subject, staffing firms get "head cashier or experienced teller"), 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 — SMTP automation: 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 CLAUDE.md: 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, and she wants to.
• A job application can't be taken back. A wrong attachment, a leftover [placeholder] or a letter naming the wrong bank is visible to the recruiter forever. The human send is the last review, and it's cheap.
• Deliverability is the candidate's reputation. Her domain has SPF, DKIM and DMARC, and one of the banks 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 Ivorian job boards and bank career pages, with no LinkedIn scraping (its terms forbid it). It filters on "cash" plus banking, 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 her. The candidate reviews and sends. The row moves to sent only when she fills in the date.

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 her own mailbox, over IMAP. She opens her 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. 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 unprovable claim, no internal figure, no criticism of your employer) that any assistant, human or AI, must follow.
5. Interview prep as a test suite, with the incident and security questions your target role really turns on.
6. A roadmap that ends at a signed contract, with follow-ups, negotiation and notice period on it from day one.
7. Automation that prepares and never sends. Put the drafts in your mailbox, then read them and press Send yourself.

With CASP, steps 6 and 7 get 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 Thales (Juste Gnimavo) of ZeroSuite, a solo CEO running seven production products with Claude as the only engineer. Install: npm i -g @justethales/casp · https://casp.sh · https://github.com/ThalesGnimavo/casp