{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreih4jixxncnp5hvpkwya7tw5qn2vassvfr74g23fwroydtjp63uk6a",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpr4vfcovbg2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreibnaokfbnrlqvba7kowc5ro5i4oxdbxgxaeu3m5rchtunqgg6gwge"
    },
    "mimeType": "image/webp",
    "size": 58366
  },
  "path": "/saltxd/i-replaced-1000-lines-of-python-with-a-500-word-prompt-29ao",
  "publishedAt": "2026-07-03T17:14:14.000Z",
  "site": "https://dev.to",
  "tags": [
    "ai",
    "kubernetes",
    "selfhosted",
    "automation"
  ],
  "textContent": "_Or: what building a $0/month autonomous AI librarian taught me about running LLM agents in production._\n\nMy documentation wiki was rotting. Not dramatically — just the usual entropy: pages with no tags, books filed on the wrong shelf, duplicated titles, stale metadata blocks pasted from templates. I had written governance rules. Nobody was enforcing them, because the only \"body\" available was me at 11pm.\n\nSo I built an autonomous agent to do it. Twice, it turned out.\n\n##  Version 1: the framework reflex\n\nThe first version was what most engineers would build in 2026: a Python service. Rule engine for the mechanical checks, an LLM API call for the judgment calls, an executor module to apply fixes, an SDK wrapper, retry logic. About a thousand lines.\n\nIt worked. It also:\n\n  * cost ~$0.70 per run, because one badly-scoped rule sent every page to the model without a pre-filter,\n  * died mid-sweep the first live night when API credits ran out,\n  * and hid two genuine integration bugs (a skipped protocol handshake that made tool calls silently no-op) inside plumbing I had written myself and therefore trusted.\n\n\n\nI retired it the same day it shipped.\n\n##  Version 2: the prompt is the program\n\nThe realization: an agentic CLI (I use Claude Code, but the shape generalizes) already **is** the rule engine, the tool executor, the retry loop, and the judgment module. I had rebuilt, worse, the thing I was paying for.\n\nVersion 2 is a Kubernetes CronJob. The container has the CLI installed. The entrypoint is ~50 lines of shell: load a prompt from a ConfigMap, point the CLI at an MCP server that exposes my wiki's API as tools, run headless, post the summary to my chat channel. The prompt — about 500 words — _is_ the curator logic.\n\n\n\n    CronJob (weekly, Sunday 04:00)\n      └─ agent pod (fresh per run)\n           ├─ agentic CLI + auth\n           ├─ ConfigMap: system-prompt.md   ← the \"codebase\"\n           ├─ MCP server: wiki API as tools\n           └─ entrypoint: load prompt → run → post summary\n\n\nBecause it authenticates with the subscription I already pay for rather than metered API keys, the marginal cost per run is zero. That's not an accounting footnote — it changed the architecture. When runs are free, you can afford to re-scan everything weekly instead of building incremental-state machinery. Half of v1's code existed to avoid API spend.\n\nAnd the prompt-based version finds _more_ real problems than the Python version did, with better judgment — it flags near-miss duplicate titles for human review instead of blindly \"fixing\" them.\n\n##  The part that actually matters: letting an agent edit things\n\nGiving an LLM write access to a system you care about is the whole question. Permissions alone don't answer it. Three design choices did the work:\n\n**1. Two lanes, not one.** Every finding is classified: _Tier 1_ (mechanically obvious — auto-fix) or _Tier 2_ (judgment — propose to the human, touch nothing). Tag-case normalization is Tier 1. \"This page might belong in a different book\" is Tier 2 forever, because moving someone's content is disruptive even when you're right.\n\n**2. An edit-review gate the agent runs against itself.** Before _any_ write, the prompt requires the agent to state the exact change and ask: _\"Could a reasonable maintainer object to this?\"_ If yes — or anywhere near yes — the item is demoted to the propose lane with a reason. The bias is explicit: a bad auto-fix costs more than another week of backlog. In months of weekly runs, zero regressions.\n\n**3. Undo as a first-class dependency.** The wiki keeps full page revision history, so every agent edit is one click from reverted. I would not point this pattern at a system without native versioning. Reversibility, not permission scoping, is what makes autonomy safe.\n\nOne more habit that earned its place: the agent reads its own previous report before starting, so every summary carries a trend line — _\"12 items awaiting review, was 14 last run, net −2.\"_ A snapshot tells you nothing; the derivative tells you whether the system is healing.\n\n##  Lessons I'd generalize\n\n  1. **Delete the framework.** If your agent code is mostly orchestration — routing, retries, tool dispatch — you've rebuilt the harness. Ship a prompt and a schedule instead. Mine went from ~1,000 lines to ~50 plus 500 words of English.\n  2. **Prompts are code.** The curator prompt lives in git, deploys through the same chart as everything else, and gets reviewed like a module — because it is one.\n  3. **Give agents an undo, not just an allowlist.** Scoped credentials limit blast radius; versioned targets make mistakes cheap. You want both, but if I had to pick one, I'd pick undo.\n  4. **Make the agent defend each write.** A self-applied \"would a maintainer object?\" gate sounds soft. Empirically it's the difference between an agent you trust weekly and one you babysit.\n  5. **Marginal cost shapes architecture.** Free re-runs beat clever state. Before optimizing an agent, check whether the economics that forced the complexity still exist.\n\n\n\nThe same skeleton now runs other jobs in my cluster — different prompt, same image, same MCP tools, same report-to-chat pattern. Each new agent is a config change, not a codebase.\n\nThe wiki, for the record, is clean. The librarian doesn't sleep, doesn't get bored, and — unlike v1 — has never once billed me.\n\n_I'm writing a series on AI-native, self-hosted IT automation: running LLM agents in production on infrastructure you own — safely, cheaply, and without a SaaS bill. Follow along if that's your kind of problem._",
  "title": "I replaced 1,000 lines of Python with a 500-word prompt"
}