The Human Element

For months before this was a product, it was just how I used AI. I'd be working on something creative and hit a moment of friction: a vague unease about the role AI was playing in my process. Instead of ignoring it, I'd open a conversation. I'd reflect on the tension, and Claude would surface a passage from Rilke on solitude, or Ruskin on handcraft, or Walter Benjamin on mechanical reproduction, that reframed something I'd been feeling all week.

The same deep questions kept recurring. What makes creative work mine? When does a tool extend me versus replace me? Is struggle essential, or just inefficiency? And the same authors kept proving useful across those questions. Over months, I'd built an informal canon of sources and ideas. The recognition that this practice could be systematized and shared with others navigating the same tension was the origin of the product.

I co-developed a 566-line product specification with Claude before writing a single line of code. The conversation was genuinely collaborative: I brought the editorial vision and audience instincts, Claude probed for gaps in the content strategy, challenged scope, and helped structure audience psychographics, content tiering, and editorial guardrails.

The spec defined 15 core themes distilled from those recurring questions, a three-tier source taxonomy organized by copyright status (public domain, fair-use excerpts, contemporary voices), tone guidelines ("explore, don't prescribe"), and an AI disclosure philosophy ("maintain the irony lightly"). These weren't abstract product requirements. They became direct constraints on the architecture, the prompt system, and the daily output.

With the spec as foundation, I built the entire site in a weekend. Claude Code handled implementation while I focused on architecture and design decisions shaped by the product constraints: solo maintainer, minimal budget, daily cadence, indefinite time horizon.

Architecture choices driven by those constraints:

• Git-as-database over a CMS: full audit trail via commits, rollback by default, zero infrastructure to maintain. Content lives as portable markdown with YAML frontmatter.
• Astro 5 static site with zero client-side JavaScript (one inline script for a random-entry button, progressively enhanced). Three self-hosted font families for a warm, literary reading experience.
• Draft-staging pattern: generated entries are created with draft: true, dated into the future. A separate publication step flips the flag when the date arrives. This creates a natural review window, but if no human intervenes, entries auto-publish on schedule. The system degrades gracefully from human-reviewed to fully autonomous without code changes.
• RSS-to-email distribution via Buttondown. Full pipeline from generation to subscriber inboxes, hands-free.

Total operating cost: ~$3–5/month. The publication runs indefinitely without revenue pressure.

The 106-line system prompt encodes months of curatorial practice into structured creative constraints. Five functional layers, each reflecting something I learned from having these conversations manually:

• Purpose framing establishes the publication's identity and audience before any technical instructions, mirroring how I'd set context in conversations before asking for specific sources.
• Dynamic source injection feeds 110+ curated authors, 16 themes, and 50+ controlled tags from a sources.json config at generation time. These are the authors and ideas that kept proving useful in my own conversations, formalized as editorial structure.
• Copyright-aware generation distinguishes public domain works (full text, excerpt: false) from copyrighted material (fair-use excerpts with source links and flagging). Legal awareness baked into generation rather than relying on post-hoc review.
• Anti-pattern rules block specific LLM writing tendencies: contrastive "it's not X, it's Y" reframing, em-dash overuse, parallel triads, rhetorical question transitions, staccato fragment punchiness. Each rule exists because I read generated output across multiple models and identified the pattern.
• Rolling repetition avoidance reads the last 14 entries from the filesystem, extracting recent authors and tags as exclusion constraints. An archive-wide used-passages.json fingerprint registry (SHA-256 hashes of normalized passage text) guarantees no passage is ever repeated.

Model evaluation was a significant part of the build. I tested Kimi K2.5 via OpenRouter, Claude Opus 4.5 without extended thinking, and Opus 4.5 with extended thinking at various token budgets. Each configuration produced distinct stylistic tendencies. Patterns that persisted across models (the same rhetorical tics, the same structural defaults) were flagged as inherent LLM behaviors worth blocking in the prompt. The final configuration (Opus 4.5 with 20K-token extended thinking budget at temperature 1) gave the best balance of creative variety and editorial consistency.

There's no automated metric for "does this meditation on Ruskin actually make you think?" Every round of evaluation required reading generated entries closely and making nuanced judgments about writing quality, tonal consistency, and whether the commentary genuinely opened something up or just performed depth.

Every day at midnight UTC, the pipeline runs unattended:

1. Publish: flip draft: true → draft: false for entries whose date has arrived
2. Generate: call Claude Opus 4.5 with extended thinking to create tomorrow's entry as a new draft
3. Validate: five structural checks before file write, plus Zod schema validation at build time
4. Commit and push: only if changes exist
5. Rebuild: Netlify detects the push and rebuilds the static site
6. Distribute: RSS feed updates, Buttondown sends email to subscribers

If the LLM produces malformed output, the build fails visibly. Two separate validation checkpoints (script-level and build-level) catch problems before they reach readers.

The publication has generated and published entries daily since launch with zero human intervention required.

AI was present at every phase of this project: co-developing the spec, implementing the site, generating daily content, and serving as the subject of iterative editorial evaluation. I wrote very little of the code myself.

What I built was everything around the code. The 110+ curated authors represent hundreds of conversations distilled into editorial structure. The anti-pattern rules are aesthetic judgments, each one encoding a moment where I read AI output and recognized a tendency a thoughtful human writer would avoid. The architecture (git-as-database, draft staging, static generation) came from reading the product constraints and choosing the simplest system that could serve them for years.

UX design thinking shaped the reading experience and the draft-staging degradation model. Full-stack fluency made the weekend build timeline possible. Product management instincts drove the spec-first approach and the editorial guardrails. Solutions architecture informed the zero-maintenance infrastructure decisions. These skills didn't operate separately. They converged in the act of orchestrating AI across every phase, from a conversation about Rilke to a cron job that runs at midnight.