June 12 was a double-header: generating polished PDF charter proposals for incoming leads while simultaneously chasing down visual bugs on the event pages that kept slipping past automated tests. Both threads exposed something useful about where AI tooling earns its keep — and where it burns tokens on problems that shouldn't recur.
The jada-pdf-proposal skill exists to produce a branded, printable PDF for prospective charter guests — the thing you send after a Getmyboat inquiry comes in. The design constraint behind it is what we call the cost guarantee: everything in the pipeline is deterministic except one small step.
The flow looks like this:
render_proposal.py) that produces an HTML fileweasyprint or playwright to produce the PDFThe only non-deterministic step — Step 4 in the skill definition — is where the model writes three short bespoke copy blocks: an opening line personalized to the occasion, a "why JADA" paragraph, and a closing call to action. The rest is plumbing. That split matters because it means the model is a copywriter, not a layout engine. Token spend scales with the number of proposals, not with the complexity of the PDF format.
Two proposals were generated in the session. The skill invocation is a single /jada-pdf-proposal call; the model collects facts interactively, writes the three blocks, and hands off to the deterministic scripts. Round-trip from invocation to downloadable PDF runs under two minutes on a warm shell.
Parallel to proposals, the session included frontend fixes on the event pages — built with the frontend-design skill, served from S3 behind CloudFront. The bug reports coming in during the session:
The photo rendering issue was the sore spot. It had come up before. The standing instruction was not to re-litigate it — any token spend on a known-and-forbidden pattern is waste. The right fix (lazy loading with explicit width/height attributes to prevent layout shift, and a preload hint for the hero) had already been identified. The session surfaced the issue again anyway, which is the kind of regression that a tighter feedback loop at the skill level would prevent.
This is the honest part. The automated browser tests were checking DOM structure and interaction paths — not visual rendering. A Playwright test that asserts img[src] is present will pass even if that image is below the fold, loading slowly, or clipped by an overflow container. Font overlap is invisible to a test that only checks that text nodes exist.
Visual regression requires screenshot diffing — something like Percy or a local pixelmatch pass. That layer wasn't wired in. The fix is to add a screenshot comparison step to the CI pipeline for the event pages, gating on a baseline diff threshold. Until that exists, the browser tests are checking the wrong things and giving false confidence.
The PDF proposal skill is a good example of the right architecture: constrain the AI to a small, well-defined creative task and make everything else a deterministic script. The event page work surfaced the opposite lesson — test coverage that doesn't reach visual output isn't test coverage for a UI. Both findings came out of the same late-night session, which is usually how this works.