Eight comparison pages in one afternoon
Three coding agents running in parallel on separate worktrees produced eight competitor comparison pages in about three hours of wall clock, prompt to merged PR. What made the output keepable was not the agents: it was a structural template, a batch of two or three pages per agent, and a fairness rubric, all written before any agent started.
Comparison pages are a strange genre. Customers want them - “how does OriginChainDB compare to Pinecone?” is the most common question on a sales call after pricing. Marketing pages want them - they rank for high-intent queries like “pinecone vs…” and “alternatives to…”. And yet, building eight of them by hand takes a week of writer time, an editor’s review pass, and three rounds of “is this fair?” pushback.
We shipped eight in under an afternoon. /vs/postgres, /vs/pinecone, /vs/weaviate, /vs/qdrant, /vs/milvus, /vs/supabase, /vs/neon, /vs/mongodb - each a standalone Astro page with a comparison table, an honest “what they do well” section, an “how OriginChainDB differs” section, a code example contrasting the two stacks, and a closing call-to-action.
Each agent worked on its own worktree with a small batch of pages.
The pattern: structural template + small batches + fairness rubric
Three decisions made the difference between “agents wrote a content pile we threw away” and “agents shipped pages we kept.”
Decision 1: Pre-write a strict structural template
The biggest failure mode for AI-written marketing pages is structural drift. Page 1 leads with a code example; page 2 leads with a comparison table; page 3 leads with a quote. Inconsistency reads as carelessness, and worse, it makes the pages feel like they were written by an LLM - which is the one signal we needed to avoid.
The fix was a structural template, written by a human, that every page must match 1:1:
1. Hero (one sentence, what they are, one sentence, what we are)
2. Comparison table (8–12 rows, identical row labels across all pages)
3. "What [competitor] does well" (3 paragraphs, no hedging)
4. "How OriginChain differs" (3 paragraphs, concrete, no hype)
5. Code example (their stack vs ours, side-by-side)
6. "When to pick which" (decision rubric, 3 bullets)
7. CTA (links to /docs/quickstart and /pricing)The row labels in the comparison table are fixed: Atomic across shapes, SQL with JOINs, HNSW recall@10 at 100k, BM25 full-text, Graph traversal, Tenant isolation, Replication and failover, Pricing model, Self-host story. Same labels across all eight pages. Readers comparing two of our pages immediately see the same axes - that is the whole reason a comparison table is worth printing.
Decision 2: Small batches per agent
Each agent got 2–3 pages, not 8. This sounds like a small detail. It is not.
An agent given 8 pages will compress. By page 4 the descriptions get shorter, the code examples get more generic, and the “what they do well” paragraphs start sounding suspiciously similar across competitors. Context budget runs out, and quality silently drops.
An agent given 2–3 pages keeps the working set small, the writing fresh, and the per-page time roughly constant. We split 8 pages across 3 agents (3 + 3 + 2) and saw uniform quality across all eight outputs. The cost of running three sessions is a tiny fraction of the cost of having a human re-edit a degraded batch.
Decision 3: Fairness as a hard rubric
The most important sentence in the prompt was this one:
Be FAIR. Pinecone is a real product used by real teams. Explain what they do well - managed vector search, fast time-to-first-query, mature SDKs, dense ecosystem of integrations. Then explain how OriginChain differs. Do not be hostile, do not strawman, do not omit a competitor’s strengths to make ours look better. Hostile comparisons rank poorly on Google, read poorly to engineers, and damage the brand they’re trying to elevate.
Fairness is not a soft preference. It is a hard rubric, because:
- Hostile comparisons get flagged by Google’s helpful-content classifiers and rank below neutral writeups.
- Engineers comparing tools can smell hype in two paragraphs and bounce.
- The pages need to survive being read by the competitor’s engineers without making us look unserious.
The agents complied with the rubric cleanly. The Pinecone page calls out Pinecone’s managed-service polish and SDK quality before pivoting to atomicity-across-shapes. The Postgres page calls out pgvector and the Postgres ecosystem before pivoting to native multi-shape. The Neo4j… we didn’t do Neo4j, that one’s still on the list.
A sample agent prompt (excerpt)
This is the actual middle of one of the prompts we used:
You are writing /vs/pinecone.astro for the OriginChain marketing site.
Follow the structural template in /docs/internal/vs-template.md exactly.
Do not deviate from row order in the comparison table. Do not invent
performance numbers. The only numbers you may cite for OriginChain are:
- HNSW fast: recall@10 = 0.69, p99 = 37 ms (100k vectors, D=128)
- HNSW high_recall: recall@10 = 0.96, p99 = 109 ms
- Asynchronous standby replication with fenced automatic failover
- crash testing at 4 durability boundaries, 5,000 iters/boundary nightly
For Pinecone numbers, link to their public docs; do not state internal
benchmarks you have not run. If a row in the table is genuinely "both
support this," mark it Yes / Yes. Do not gaslight rows green for us
that are not green for us.
The "what Pinecone does well" section must be 3 paragraphs. Suggested
angles: managed-service quality, SDK ergonomics, integration ecosystem.
The "how OriginChain differs" section must be 3 paragraphs. Suggested
angles: atomicity across rows + vectors + FTS + graph in one write,
single bearer, sub-millisecond SQL alongside vector.
Do not use the words "revolutionize", "unleash", "game-changer",
"next-generation", "paradigm", or "empower."The word ban looks petty. It is not. Those six words are the dominant tells of LLM marketing prose, and banning them forces the agent into more concrete language. Ban one and another grows back; ban six and the prose tightens.
What agents don’t replace
This is the part that matters, and the part most “agents wrote our marketing site” stories skip.
Agents do not replace editorial judgment. Every decision the agents made was already encoded in the prompt:
- The structural template (1 hour to write, used 8 times).
- The fixed row labels for the comparison table (45 min, including arguing about which 9 axes to settle on).
- The fairness rubric (15 min, but every word matters).
- The numbers list (we have to be ready to cite these on a sales call).
- The word ban (5 min, but it took six months of reading bad LLM prose to know which words to ban).
That is roughly 80% of the actual creative work. The agent contribution is the last 20% - turning the rubric into eight specific pages of prose, each calibrated to a specific competitor.
This is the part that most teams misjudge in both directions. The bullish version is “agents will write our marketing site for us.” The bearish version is “AI-generated content is slop and we won’t use it.” The realistic version is “agents are an extremely fast last-mile, and the editorial work that decides whether the output is good is exactly the work humans were always going to do.”
What this is NOT
A few honest scope notes:
- There is no /vs/ index page yet. Each page is reachable via direct URL -
/vs/postgres,/vs/pinecone, etc. - but there is no landing page that lists all eight. The index is on the punch-list; for now, link to the individual pages. - The pages are static. No A/B tests, no dynamic copy based on referrer, no conversion-tracking instrumentation beyond the standard analytics. Comparison pages tend to convert on long tail SEO, not paid acquisition, so the simplicity is intentional.
- We did not run benchmarks against the competitors. Where the table cites a competitor capability, it is sourced from their public documentation. We cite our own numbers (HNSW recall@10, p99, crash-injection iters) from our own benchmarks. If a competitor publishes new numbers, the page can be regenerated against the updated source in one agent run.
- Eight pages is not the universe. Cassandra, Redis, ClickHouse, DynamoDB, Couchbase, Elasticsearch - there are at least a dozen more comparisons that make sense. We shipped eight because eight is the batch where we know our positioning is sharp; the next batch lands when the next batch’s positioning is sharp.
Try it
If you are evaluating OriginChainDB against another database, the eight comparison pages are at:
Each is a fair, technical writeup - not a hit piece. If the comparison you want isn’t there yet, the docs cover the substrate-level shape of OriginChainDB in detail; the comparison page is just the last-mile rendering against a specific alternative.
Three agents. One afternoon. Eight pages. The pattern works.