DEV Community: Marco

I let every AI crawler in. A month later I cannot tell you how many people read me

Marco — Wed, 12 Aug 2026 13:07:09 +0000

In early August Cloudflare sent me a congratulations email. The site had passed ten thousand pageviews in its first month: 33,561, on a domain that went live on 5 July.

For about ten seconds it was good news.

Then I remembered what I had done in July, which was open robots.txt to every AI crawler in existence. Training included, on purpose. I have no brand to protect and my problem is not that someone copies me: it is that nobody finds me. So everyone gets in.

Which makes that number, taken as it is, good for nothing.

Why does a pageview count not tell you how many people read you?

Because Cloudflare's free plan counts requests, not people, and it does not separate humans from bots. Inside those 33,561 are the crawlers I invited myself, and I have no way to know in what proportion.

This is a practical problem, not a philosophical one. If a client asks me tomorrow how much traffic the site gets, I do not have an answer I can defend. "Thirty-three thousand" would be a true sentence and false information, because whoever hears it understands "thirty-three thousand people". I would rather say I do not know.

And there is the opposite question, which matters more to me: is opening the gates working? If GPTBot comes through and re-reads the site every week, I did the right thing. If it never comes, I am giving away bandwidth for nothing, and I would like to know.

Is letting AI crawlers in actually worth it?

On half the question I have a measured answer, and the two halves look nothing alike. Perplexity cites me in first position for "who is Marco Bellingeri, cloud and security engineer". ChatGPT, asked the same thing, does not cite me at all.

The monitor that measures this runs every Monday and writes the history to a database. So far, routine. The interesting part is what the model did when I asked it that question.

It did not look for me. It rewrote the question into a search query, "Marco Bellingeri AI security", and read twelve pages about the topic: the European regulation, the AI Act, the Bletchley declaration, a couple of newspapers. None of them was about a person. It answered about the subject because it never found the person.

That is a different kind of failure from "your content is not good enough". It is the engine failing to connect the question to the page, and the difference changes what is worth doing next. If the crawler never comes, rewriting articles is wasted time and the problem is access. If it comes and does not cite, the problem is that the content is not extractable, and then rewriting is the work.

To know which, I needed to count who comes through.

How do you count crawlers without tracking people?

By looking at the User-Agent of every page request and recording only the family it belongs to, with no IP address, no cookie, no session, nothing that ties two requests to the same person.

The site is static and runs on Cloudflare Workers, so the Worker was the obvious place. I started from an assumption that turned out to be false: I thought every request went through it. It did not. The Worker was configured to run on five routes only, the root and four APIs. Every page of the site was served straight from static assets, and my code never saw a thing.

The fix was not "send everything through". Requests to static assets are free and unlimited; requests that invoke the Worker consume the free plan's quota of a hundred thousand a day. Sending everything through would have put my code in front of every font and every stylesheet, which is most of the volume and all of the latency that matters, in order to count things that are not pageviews.

So only HTML goes through. A pageview is an HTML request. The rest is what that page drags along with it.

What NOT to keep, which is the hard part

The classification is trivial: a list of names, GPTBot, ClaudeBot, PerplexityBot, Googlebot, and a couple of rules to spot a real browser. Twenty lines. What took me time was deciding what to throw away.

A browser's User-Agent identifies a person far more than it looks. Combined with other signals it becomes a fingerprint. So for a person I keep one word, human, and drop the string.

For a crawler I already know I keep the family name and nothing else: I know who it is, the rest adds nothing.

That leaves the awkward case, the one that made me rewrite the code twice. If I do not recognise the client, what do I do? The first version called it a bot and kept its full User-Agent. Wrong on two counts. The first is that a person can be in there: a text browser, a webview inside an app, an accessibility tool, a User-Agent stripped by a privacy extension. Treating them as a bot and keeping their string is exactly the thing I said I would not do.

The second reason is that the number lies. If I put "a crawler I do not recognise" and "I could not tell what this was" in the same bucket, I then read that forty per cent of the traffic is automated and believe it, when part of that forty is my own uncertainty wearing a certainty's clothes. And that number is the one that ends up in front of a client.

Now there are two labels. A client that declares itself automated in its own User-Agent, by writing bot or crawler or curl into it, gets kept as its short product name: that is what lets me notice a new family. A client that simply does not place gets recorded as unclassified and nothing else.

What does counting cost?

Little, but not nothing, and the point is knowing beforehand rather than finding out. Every page that goes through the Worker consumes one request of the free quota. At today's traffic that is around eleven hundred a day against a hundred thousand: a margin of about ninety, which is comfortable but not infinite, and there is no rate limit on those routes.

I wrote it into the project README, along with what I will do if the number gets close, in order: watch the counter, narrow the routes and accept counting less, and only then pay. A declared ceiling with an exit path next to it is acceptable debt. A ceiling discovered by accident one night is an incident.

The line that nearly made me publish a lie

My site's privacy policy said, in Italian and in English, that it "uses no tracking or analytics".

That was true until the day before. If I had shipped the counter without touching that page, the site that sells transparency would have published a false statement about itself, and no test would have caught it: tests look at code, not at promises.

I rewrote it before shipping. It now says what it does: it counts requests one at a time, with no identifiers, no profiling, and keeps the data for three months because that is when the platform deletes it. I also removed the word "aggregate" from a first draft, because it was not true: what I write is one event per request, not a running total, and calling it aggregate would have been more reassuring and less accurate.

What I still do not know

The counter has been on for a few hours. I generated the first data points myself, sending three test requests with fake User-Agent strings to check that it worked, and honestly I could not tell them apart from real traffic.

So I have nothing to tell you about crawlers yet. In a week I will know: which families come through, how often, on which pages, and above all whether GPTBot shows up at all. That answer decides whether it is worth continuing to write to be found by a model, or whether I have been writing for an audience that never came.

In the meantime I have lost the ability to say thirty-three thousand. It looks like a step backwards and it is a real step forward: before, I had a big number and no idea what was inside it. Now I have a measurement on its way, and in the meantime an honest answer.

A permissive robots.txt is not a licence

Marco — Tue, 11 Aug 2026 16:24:23 +0000

I have a scraper that watches ten sites I consider adjacent to my work. It has been running since early July. The output goes into a vector store that nothing currently reads, which is the only reason this story ends without a lawyer in it.

I audited those ten sources this week, against the same bar I use for the security feeds on my site: the licence has to permit commercial reuse in writing. My site sells things. Ambiguous means no.

Two passed. Eight didn't. And the pattern in the failures was not the one I expected.

The two questions are not the same question

Here is Simon Willison's robots.txt, which is about as welcoming as they come:

User-agent: ChatGPT-User
Disallow:

User-agent: *
Disallow: /admin/
Disallow: /search/

An explicit allow for an AI user agent. No GPTBot block, no Google-Extended block, nothing. My scraper is welcome.

Now the footer of that same site: a copyright symbol and a list of years. No licence. No terms page. Nothing that grants me the right to republish a line of it on a page that sells consulting.

And here is Troy Hunt's footer, on a site whose robots.txt blocks nothing interesting either:

Copyright 2026, Troy Hunt. This work is licensed under a Creative Commons Attribution 4.0 International License. In other words, share generously but provide attribution.

That is a licence. It says what I may do and what I owe in return. Under my own admission rule, Troy Hunt is in and Simon Willison is out, and it has nothing to do with which of them is friendlier to crawlers.

The two questions are separate, and only one of them is the one I need answered:

robots.txt answers "may your bot fetch this page?"
the licence answers "may you republish what your bot fetched?"

A site can say yes to the first and stay silent on the second. Silence is not a yes. It is the absence of one, which under my rule is a no.

Both of them, in both directions

The inverse showed up too. Julia Evans' robots.txt contains, in ASCII art large enough to be unmissable:

NO LLM PLZ

plus a Disallow: / for GPTBot. It could not be clearer. What it is not, technically, is a licence restriction: /license, /licence, /copyright and /terms all 404, and the footer says only "© Julia Evans."

So a lawyer might tell me that robots.txt is not a contract, and that the absence of an explicit prohibition leaves me room. I don't want that room. A person wrote NO LLM PLZ in ASCII on their own website. That is the clearest possible statement of intent, and building a business on top of the gap between what someone stated and what they happened to make enforceable is a bad way to run a business that sells trust.

I gave that verdict its own name. Not "out" for licensing reasons, but out by intent. It documents that we read the wish and honoured it, rather than losing the distinction in a spreadsheet where every rejection looks the same.

The Pragmatic Engineer's newsletter turned out to be the most precise of all of them, with a header I hadn't seen in the wild before:

Content-Signal: search=yes, ai-input=yes, ai-train=no

Retrieval yes, training no. That is a genuinely useful signal, and I am glad someone is putting it in machine-readable form. It still isn't a reuse licence, so the source is out for me, but for once I knew exactly what the author wanted.

The failure isn't the audit, it's when I ran it

Eight sources out of ten failed, and I could tell you that finding it is the win. It isn't. The scraper ran for a month against sites that had said no in writing, and the only reason nothing was published is that the retrieval path on top of that store doesn't exist yet.

That is luck, not a control.

The licence gate belongs at the moment a source is admitted. Not at the moment its content is first served, which is where I had implicitly put it by thinking of the whole thing as "internal, for now". Internal is a property of today's architecture. The scraping happened anyway.

Two things went into the repo alongside the deletions. The verdicts, each with a verbatim quote and a link to the page I read it on, in the same compliance file I already keep for the site's public feeds. And a note, in plain sight, that the public feeds have a CI test which fails when a source has no written licence, while the internal roster has no such test, because it lives in a database and my test suite runs without network. That gate is a human reading a file. It is a declared ceiling, not a control, and writing it down as such is the difference between a limitation and a surprise.

The short version

Check both, in both directions.

A crawler-friendly robots.txt with no licence gives you access and no rights. A hostile robots.txt on a CC BY site gives you rights you probably shouldn't take. The combination you want is a written grant, and the only way to find it is to open the licence page yourself.

The scraper never had to ask. That was the whole problem.

My quality gate wasn't strict. It was dead.

Marco — Tue, 11 Aug 2026 13:59:58 +0000

There is a job in my CI called judge. It reads the monthly issue my content pipeline writes, scores it against a rubric with five criteria, and blocks the merge if anything comes back at 2 out of 5 or lower. An LLM grading an LLM, with a written policy about what counts as broken.

It went red on a content PR this week. My first thought was that the piece was weak. My second thought, about four minutes later, was worse: this gate had been red on every content PR for a while, and I had been reading that as a high bar.

It wasn't a high bar. The job never reached the rubric at all.

Error: anthropic messages -> 400: output_config.format.schema:
For 'integer' type, properties maximum, minimum are not supported

The judge asks the model for structured output, and the schema it sends had this in it:

voto: { type: "integer", minimum: 1, maximum: 5 },

Which is correct JSON Schema, and which the structured output layer rejects. The request never made it to the model. The job exited 1 before scoring a single word.

A gate that cannot go green is not enforcing anything. It has the same effect on your pipeline as continue-on-error, except it also makes you feel virtuous while it does nothing.

The error message named half the problem

The obvious fix is to delete minimum and maximum and move on. I nearly did. What stopped me was noticing that the schema had a second kind of constraint in it:

motivo: { type: "string", maxLength: 300 },

Length constraints are rejected too. maxLength, minLength, pattern, minItems, all of it. My schema had three of them, and the 400 mentioned none, because validation stops at the first failure. If I had fixed what the message named, I would have pushed, waited for CI, and collected the next 400. Then the one after that.

This is a general property of error messages, not a quirk of one API: they report the first thing that broke, not the set of things that are broken. The fix that only addresses what the message says is a fix sized to the message, not to the defect.

The other thing worth knowing here: the Python and TypeScript SDKs strip unsupported constraints for you before the request goes out. My pipeline is zero-dependency and calls the API with native fetch, so nobody was stripping anything. If your SDK has been quietly saving you, you will find out the day you drop it.

So the test is about the contract

I could have written a test asserting no minimum on integers. It would have passed, and it would have been useless three weeks later when someone adds a pattern to a string.

Instead the accepted and rejected keywords are written down once, and every schema I send to the API gets checked against them:

const RIFIUTATE = new Map([
  ["minimum", "numeric constraint"],
  ["maximum", "numeric constraint"],
  ["maxLength", "length constraint"],
  ["pattern", "string constraint"],
  // ...
]);

export function keywordRifiutate(schema, path = "$") { /* walks the tree */ }

It walks nested schemas, and it knows that inside properties the keys are my field names rather than schema keywords, so a field genuinely called pattern doesn't trip it.

On first run it found sixteen violations across the judge schema. Not two. My generation schema, checked at the same time, was already clean, which I would not have bet on.

There is a second check next to it that lists keywords the contract doesn't mention. It fails rather than allowing them, which sounds aggressive for something the API might accept fine. The reason is that I want the moment where somebody adds an unfamiliar keyword to be the moment somebody reads the docs, instead of the moment CI goes red for a reason nobody connects to the schema.

Where the constraint went

The rubric still runs on a 1 to 5 scale. That range now lives in the two places the API can't reject it.

The prompt describes it, with each score defined. And the code treats an out-of-range score the way it already treats a missing one:

const fuoriScala = (v) => !Number.isInteger(v) || v < 1 || v > 5;

Fail closed. If the model returns a 7, the rubric is unreadable, and an unreadable rubric doesn't promote anything. That was already the policy for a criterion the model forgot to fill in. A score outside the scale is the same class of problem, so it gets the same answer.

Moving a constraint out of a schema usually means giving it up. Here it just meant enforcing it somewhere with a worse reputation and better reach.

What I'd check on your own pipeline

Grep your CI history for a job that has never been green. Not "was red today", never green at all, or not since some commit that had nothing to do with it. That job is not protecting you, and it is currently costing you the specific kind of comfort that comes from thinking it is.

Mine ran for weeks. It was the most reassuring line in the workflow file.

From text-JSON parsing to Claude tool use in JobSearch

Marco — Tue, 21 Jul 2026 00:55:05 +0000

My job-search tool had five functions whose only purpose was fixing JSON that Claude had just written. _clean_json_text, _fix_unescaped_newlines, _fix_single_quotes, _strip_markdown_wrapper, _extract_and_parse_json. There was also a sixth, _retry_json_fix, which took the broken JSON and sent it back to the model with a polite request to fix its own mess. I wrote every one of them, one bug at a time, over weeks. I was a little proud of them.

That was the problem.

How you end up with five parsers

JobSearch is my personal tool, in production, single user: me. It ingests job offers from nine boards, and when I press "Analyze", Claude reads the offer against my CV and returns a structured verdict: score, recommendation, career track, the English level the ad actually requires. That verdict has to be JSON, because everything downstream is a database row, not prose.

The first version did what every tutorial does. Ask the model for JSON in the prompt, take response.content[0].text, run json.loads on it. It worked in the demo and then production started teaching me things.

The model wrapped the JSON in markdown fences, so I wrote a function to strip them. Sometimes it used single quotes, so I wrote a function to fix those. Then a description with a line break inside a string, so I wrote _fix_unescaped_newlines. Then a NaN where a number should be. Every fix was five lines, obviously correct, and came with its own tests. I still have the test names in the git history and they read like a confession: test_removes_trailing_commas, test_replaces_nan_with_null, test_replaces_infinity, test_unclosed_fence_still_strips_opening.

By April the parsing layer was around 250 lines with seven strategies, chained, each catching what the previous one let through. The last resort was the AI self-repair call: if nothing parsed, send the broken output back and ask the model to repair it. A second API call, with real latency and real cost, to fix a formatting problem the first call should never have had.

I had a test suite asserting that my code could survive output nobody should ever have produced. That is not robustness. That is a bug report addressed to the wrong recipient.

How do you get guaranteed JSON from Claude with tool_choice instead of parsing text?

You define exactly one tool whose input schema is the shape of the answer you want, and you force it with tool_choice. The model cannot answer any other way, and the JSON arrives already parsed and validated against the schema by the API, not by your code.

Anthropic's API has tool use, and you normally reach for it to let the model call your functions. This is the stricter reading: one tool, forced, and the answer comes back as a Python dict on the response object.

I already had a Pydantic model for the analysis, because the DB row needed one. So the schema was free:

def _schema_from_model(model_cls: type[BaseModel]) -> dict[str, Any]:
    """Produce a JSON Schema from a Pydantic model, suitable for input_schema."""
    ...

response = client.messages.create(
    model=model_id,
    system=system,
    messages=[{"role": "user", "content": user}],
    tools=[{
        "name": "submit_analysis",
        "description": "Return the structured job analysis.",
        "input_schema": _schema_from_model(JobAnalysis),
    }],
    tool_choice={"type": "tool", "name": "submit_analysis"},
)
block = next(b for b in response.content if b.type == "tool_use")
data = block.input  # a dict, parsed by the SDK, no text in sight

The refactor landed on April 14 as one commit: every AI call in the codebase migrated, all five parsers deleted, the self-repair fallback deleted, the garbage-JSON test file deleted with them. The commit message says minus 200 lines and it undersells it, because the lines that left were the ones I had to re-read every time something broke.

It was the scary PR of the batch. I shipped it in the middle of an afternoon where Claude and I pushed thirteen PRs to production, and I wrote about that day separately. Twelve of those PRs were routine. This one deleted a safety net and replaced it with a promise from an API, in the same diff.

One thing I kept: the Pydantic validation after the call. The schema guarantees shape, not sense. A score of 950 on a 0-100 field is schema-valid JSON and still garbage, and model output stays untrusted input no matter how it is delivered. The contract moved into the API; the checking stayed on my side of it.

The surprise came after launch

Here is the part I did not expect, and the reason this piece is not just "use tool use, delete your parsers".

With text output, the model treated my prompt rules a bit loosely, and the parsing chaos hid it. With a forced schema, it obeys much more literally. I had a fallback rule for freelance positions: Italian job ads sometimes want a P.IVA, a VAT number, which changes whether the offer makes sense for me at all. The rule said, roughly, "if freelance status is ambiguous, flag it". Under tool use the model started flagging offers that mentioned freelancing in passing, a line about contractors in another team, anything. Ambiguous had quietly meant "mentioned anywhere".

The schema made the model more obedient, and the obedience exposed how sloppy my instructions had been. The fix was not code. It was rewriting the prompt with explicit precedence: the contract type stated in the offer wins, the fallback fires only when the offer itself is about the contract and does not settle it.

So the lesson I actually paid for: when you migrate from text parsing to tool use, your interpretive prompt rules need to be tightened, not loosened. The model stops improvising on format and starts taking your words seriously. If your rules were vague, you find out now.

What I would tell past me

The parsers were never defensive programming. They were a symptom that the contract lived on the wrong side of the API call, and every new repair function was me renegotiating that contract in the worst possible place, after the response, one edge case at a time.

If your pipeline has a function called _fix_single_quotes, you do not need a better parser. Move the shape into input_schema, force the tool, keep your validation, and delete the museum. Then go re-read your prompt, because the model is about to start believing every word of it.

I made my portfolio site audit its own security headers, live, in front of you

Marco — Wed, 15 Jul 2026 14:13:30 +0000

My portfolio has a section that runs curl -I on itself while you watch. Not a screenshot of headers I pasted in last year and forgot to update. The page fetches its own URL, reads the response headers off it, and prints each one ON or missing, right there in the section. If I ever ship a build that drops a header, the page snitches on me the next time someone loads it.

I want to walk through how it works, and then the part that made me rewrite it: the real Content-Security-Policy is not in one place. It is split across two. Showing only the header would have told half the truth, on a page whose whole point is not doing that.

The setup

The site is built with Astro, output fully static, served from Cloudflare. There is a section on the page titled like a shell command. Under it, a list of the security headers I expect the edge to send. The expected list is not hardcoded into the script, it comes from the component:

const expected = [
  'Content-Security-Policy',
  'Strict-Transport-Security',
  'X-Content-Type-Options',
  'Referrer-Policy',
  'Permissions-Policy',
];

Same origin, so the browser is allowed to read the response headers back. That is the whole trick. A fetch to any other site would get its headers hidden by CORS, but a page is allowed to look at itself.

How can a website audit its own security headers live, in the page itself?

The page runs a HEAD fetch against its own URL. Same origin, so the browser lets it read the response headers back, and the card prints which ones are there and which are missing while you watch.

The client script, in full:

fetch(window.location.href, { method: 'HEAD' })
  .then((res) => {
    box.replaceChildren();
    expected.forEach((name) => box.appendChild(row(name, res.headers.get(name))));
    box.appendChild(row('Content-Security-Policy (meta)', metaCsp && foldHashes(metaCsp)));
  })

HEAD, not GET, because I only care about the headers and there is no reason to pull the body again. For each expected header it calls res.headers.get(name). If the value is there, the row renders ON and prints it. If it is null, the row goes missing and gets a different style. No allowlist of "good" values, no grading. It shows what came back.

One detail I care about more than it probably deserves: every cell is built with document.createElement and textContent, never innerHTML. This is a section about security headers. If I XSS my own security section by piping a header value straight into the DOM as HTML, I have earned every bit of the embarrassment. So the header values are text, and text only.

The site also scored A+ on Mozilla's HTTP Observatory, and the hero links straight to that scan so you can re-run it yourself instead of taking my word for the badge. The live card and the external scanner are checking the same thing from two sides.

Why does a hash-based CSP have to live in a meta tag instead of the response headers?

Because only the build knows the hashes, and the headers file is static. Astro computes the sha256- values at build time and writes them into a <meta http-equiv>; if the same policy also sat in the headers, the browser would apply both as an intersection, and a script-src 'self' written there would cancel out the hashes in the meta.

This is where I had to go back and change the card. When I first wrote it, it read the five headers off the response and stopped. Clean, done. Except the meaningful part of my policy, the script-src full of sha256- hashes, lives in the HTML, not in the header the card was reading.

Why not just put the whole CSP in the Cloudflare _headers file and be done? Because then the browser applies both policies as an intersection, and they fight. My _headers file says exactly this, in a comment I left for future me:

# La CSP non sta qui: la genera Astro (`security.csp` in astro.config.mjs) come
# <meta http-equiv>, perché solo in build può calcolare gli hash dei propri script.
# Se una CSP vivesse anche qui, le due policy verrebbero applicate entrambe come
# intersezione: un `script-src 'self'` in questo file annullerebbe gli hash del meta
# e rimetterebbe il sito offline.

A script-src 'self' in the header would intersect with the hash-based script-src in the meta, and the result blocks the very scripts the hashes were meant to allow. Site offline.

So there is exactly one CSP directive that has to live in the header, and it is the one a <meta> tag is not allowed to express: frame-ancestors. Per spec, frame-ancestors inside a <meta> is ignored, so it has to be a real response header. That is the whole content of the CSP header at the edge:

Content-Security-Policy: frame-ancestors 'none'
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Which means my original card, reading only headers, would have proudly printed a Content-Security-Policy of frame-ancestors 'none' and called it a day. Technically true. Also a lie by omission, because it hid the part of the policy that does most of the work.

So the card reads the meta too. It pulls the <meta http-equiv="content-security-policy"> content out of the DOM and prints it as a second CSP row. The hash list is dozens of entries long and useless to look at, so it folds each run of hashes into a count:

const foldHashes = (csp) =>
  csp.replace(/(?:'sha\d{3}-[A-Za-z0-9+/=]+'\s*)+/g, (run) => {
    const n = run.match(/'sha\d{3}-/g)?.length ?? 0;
    return `${n} hash `;
  });

The count is read from the real policy on the page, not a number I typed. If Astro emits one more inline style tomorrow, the number goes up on its own.

What this cost me, honestly

I am mid-level. I did not know going in that frame-ancestors was meta-blind, or that two CSPs intersect instead of one winning. I learned both by breaking the site. There is a manual hash in my Astro config for one inline script, the anti-flash theme script that runs before first paint, because Astro leaves is:inline scripts alone and will not hash them for me:

scriptDirective: {
  resources: ["'self'", 'https://challenges.cloudflare.com'],
  hashes: ['sha256-WV81hIAeXjEdgj/cFIXtOf53g8pIquCjmXQuCHOehlw='],
},

If I touch that script and forget the hash, npm run test:csp fails and tells me the new hash to paste. That test exists because I shipped the mismatch once and the theme script got blocked in production.

The card is not clever. It is a HEAD request, five .get() calls, and one querySelector. What I like about it is that it cannot drift. A README claiming "we set strict security headers" ages the moment someone edits a config. This section re-derives the claim from the live response every time the page loads, and it reads both halves of a policy that lives in two files, because reading one half would make the page a small liar about the one topic it is supposedly honest about.

If you want to try the pattern: same-origin HEAD, read the headers, read the meta CSP too if you have one, build the DOM with textContent. That is the entire thing.

Thirteen PRs in one afternoon, and the boring rule that made it possible

Marco — Wed, 15 Apr 2026 10:05:39 +0000

I sat down one afternoon with a list of six things I wanted to ship to JobSearch, the job hunting tool I wrote for my own job hunt and then kept running in production for exactly one user. Three small features, two pieces of tech debt, and one refactor I had been avoiding for a month because it deleted a safety net and replaced it with a promise.

I expected to finish two of them. Maybe three if the afternoon went well.

Six hours later thirteen pull requests were merged into main, every one of them green, every one of them live. I have gone back over that day more than once since, because the interesting part is not the number. Thirteen is a number I got by accident. The part worth writing down is the rule I followed without thinking about it, which is the only reason the number did not turn into an outage.

What was actually on the table

JobSearch is a FastAPI application with PostgreSQL and Redis behind it, deployed on Render. Nothing exotic. At the time it had 394 tests and a CI pipeline with nine stages: linting, formatting, a security scanner, a dependency audit, stylelint, CodeQL, the test suite, a Docker build, and the deploy. It is a real production app with a user base of one, and that one user files very detailed bug reports.

I started by asking Claude to plan the work rather than do it. What came back was a six PR roadmap ordered by risk, cheapest and safest first, with the refactor I was scared of sitting last. I changed two things about the order and then we just started walking down it. That planning step is the only reason the afternoon had a shape at all. Without it I would have opened the scary one first, because that is what I always do.

The rule

Every single PR went the same way, with no exceptions and no shortcuts when I got tired:

Branch from the latest main.
One concern per branch. Never a bug fix riding along with a feature.
Tests written for the change.
Push, wait for nine green checks, merge, delete the branch.
Pull main, then start the next one.

Written down it looks like the first page of any guide to working with git, and I know how unremarkable it sounds. It is also the whole answer. No two branches were ever open at the same time, so no two changes ever had to be reasoned about together, so no merge ever produced a surprise. When something did go wrong, and it did, the surface area of what could have caused it was one small diff, not six overlapping ones.

We never rolled anything back. Production never broke. Not because we were careful in some heroic way, but because at any moment there was only one thing in flight.

Who did what

Claude did the typing and most of the verification. I did the decisions and the order.

That split sounds like a slogan, so here is what it looked like in practice. On two of the thirteen PRs I threw away the first proposal, not because the code was wrong but because it had quietly grown: I asked for a fix and got the fix plus a small refactor of the module around it plus a new helper that nothing else would ever call. Both times the second attempt was a third of the size and did exactly what I asked. Scope creep is the failure mode I watch for now. It arrives helpfully.

I also read every diff before merging. All thirteen. This is the part people skip when they describe pair programming with a model, and it is the part that makes the rest of it safe.

The claim I stopped believing

Twice that afternoon Claude told me the test suite was passing, and twice it was not.

Both times the mechanism was the same. A slow test had been skipped locally, the summary line said everything else was green, and the report I got was true about what had run and silent about what had not. Running pytest myself took ten seconds. Believing the summary would have cost a full CI cycle each time, and worse, it would have taught me that the summary is worth believing.

That is now a habit rather than a rule: when the report is about whether we are allowed to proceed, I check the report myself. Not out of suspicion. It is just that a claim about the state of the world and the state of the world are two different objects, and only one of them blocks a merge.

The one I was afraid of

The last PR on the list deleted about 250 lines of code whose only job was repairing JSON that Claude had just written, and replaced the whole thing with Anthropic's tool use and a forced schema. Net delta across the client and its tests was around 370 lines removed.

It went out alone, last, behind its own flag, with nothing else in flight. And it introduced a bug that took until the next morning to notice, because the bug was not in the code. It was in a prompt rule that had been surviving on ambiguity. I wrote that one up separately, in from parsing JSON in the text to Claude's tool use, because it deserves its own piece.

The relevant bit here is that the riskiest change was the easiest one to diagnose the next day. One PR, one concern, one diff to reread. If it had shipped in the middle of the pile with four other things, I would have spent that morning bisecting instead of thinking.

What I would keep

Plan before you execute, even for an afternoon. Especially for an afternoon, because that is when the temptation to just start is strongest.

Keep the reviews. The model writes faster than you read, and that gap is where the mistakes live.

And keep the boring rule. One branch, one concern, wait for green. It is not a productivity technique and it does not feel fast. It is what let me work for six hours at that pace without ever being in a position where I could not explain what was running in production.