Clojure/Conj 2026

The pitch: an AI agent will happily invent a "fibonacci" that returns the wrong value on n=13 and pass code review. A test.check property that asserts iter/recur/matrix agree for every n in [0,40] rejects the invention before it ships. Ten tools in the repo follow the same shape – pure .cljc core with one named invariant, vanilla-DOM .cljs adapter, thin org wrapper, one shadow-cljs build target. The pattern is the spec (docs/specs/tool-maintenance.org v1.0.0

• .claude/skills/tool-maintainer/SKILL.md); it's what lets the

agent add tool #11 without breaking tool #7. Show:

1. Scaffold + start gmake dev-tool TOOL=new-thing (10 s)
2. Write core.cljc with the invariant in the docstring (2 min)
3. (defspec ...) that rejects a plausible-but-wrong impl (2 min)
4. browser.cljs that mounts on #tool-root and delegates (1 min)
5. Live-reload the SPA at :871N (1 min)
6. Close: "the invariant is the code the agent is not allowed to change"

Why it fits the "actually working" bar: 10 shipped tools on wal.sh right now, all following this pattern.

The pitch: LLMs are 30% of your traffic. Amazonbot alone is 110K requests over two weeks on this site; ChatGPT-User (3,261) already outpulls Googlebot (1,482). Your publish pipeline should serve them first-class, not as a scraping afterthought. The Clojure move: wal-sh.site.org/read-all is the single parser; indexer, feed, sitemap, headers-lint, verify annotations, and provenance are six independent consumers of the same parsed data structure. Adding an llms.txt generator is a new consumer, not a new parser.

Show the .md frontmatter filter in publish.el (35 lines of elisp) that emits Pydantic-shaped YAML on every ~.md export using the same read-all-derived metadata; then the pocket-es indexer's 240-char description cap that keeps search snippets sane. Close: the Clojure "data + fns" ethos is exactly the right shape for content that has to serve humans, search bots, and LLM agents concurrently.

The pitch: you don't need Elasticsearch to search your own site. If you already speak Clojure, the same BM25 core runs in the JVM (indexer), the browser (search UI), and Node (build-time query). pocket-es is a ~700 LoC project that indexes 820 docs into a 1.2 MB JSON blob, ships it as a static asset, and searches it with BM25 in the reader's browser. The .cljc core is host-neutral; pocket-es.indexer (Clojure) writes the file, pocket-es.ui (CLJS) reads it, and both share the tokenizer + scorer.

Ten-minute shape: show the indexer running on-disk, the query resolving in the browser DevTools console, and (the punchline) the same query resolving in a node -e '...' one-shot for CI/agent use without spinning a service.

The pitch: when an agent reviews your content and stamps it "correct" or "disputed," how do you prove that stamp wasn't retroactively rewritten? Two Clojure primitives: property drawers on the heading (readable, greppable, per-claim) + a JSONL hash chain (one file, append-only, editing block N breaks every block after N). Data-first, no ceremony, no dependency beyond the JVM. Demo: agent reviews a claim → writes a verdict drawer → appends a chain block → verify-chain passes; then edit one prior block → verify-chain exits 1 and prints the broken link.

Fits inside 10 min because both artifacts are plain text and the verifier is ~15 lines. Aligns with the "practices" side of the showcase.

The pitch: every clojure -M … spawn is a 12-second JVM startup. An AI agent that spawns one per query has burned its session budget before it makes progress. The fix is boring: one persistent nREPL on :42527, both cider-nrepl and shadow-cljs middleware in the same JVM, and every clj OR cljs task evaluates through CIDER against that one instance. The demo is embarrassingly small: start the nREPL once, connect once, and then do a Clojure query + a CLJS release build + a hot-reload in the browser – all in the same process, all in ~30 s.

The lesson translates directly to any agent-plus-Clojure workflow: the persistence is the productivity gain. Great fit for a workshop audience already fluent in CIDER.

Submit #1 (invariants as the contract for AI-authored code). It's the tightest fit for tools + practices actually working, has 10 shipped artifacts to point at, and the invariant framing lands independently of whether the audience already writes AI-assisted code. Runners-up: #2 is the strongest "why Clojure specifically" pitch; #5 is the safest demo if I want the fewest live variables.

• [ ] Pick one from #1–#5
• [ ] Fill application form (URL in CFP email)
• [ ] Record the demo dry-run on the pi or nexus (screencast) so if a live-demo prop fails on Sep 30 there is a fallback
• [ ] Prepare a two-line "why this matters" for the September attendee vote
• [ ] Land free Workshop Day pass on selection