23 Iterations in 32 Days: How I Built a Production AI Content System

Create-Articles v1.0 to v7.9.11 · Retrospective

The system works because it failed 22 times first.

• Gen 1 (v1.0–v3.8) — Basic prompt engineering. One-shot generation. Manual quality control.

• Gen 2 (v5.0–v6.9.9.8) — Structured workflows. CMS integration. Golden examples.

• Gen 3 (v7.0–v7.9.11) — Split architecture. 3-tier validation. Content profiles. Context engineering.

23+ versions in 32+ days. Some were releases. Most were fixes. A few were complete rollbacks.

The version numbers tell a story. The jump from v3.8 to v5.0 was a rollback. Everything between v6.9 and v6.9.9.8 was pixel-level debugging. The jump from v7.0.8 to v7.9.3 was the Gen 3 split. The system didn’t progress linearly. It oscillated toward stability.

Failure 1: The 89-Line Disaster (v3.8)

I thought more instructions meant better output. I was wrong.

Version 3.8 added 89 lines of validation checklists. Renamed folders. Added 8 separate validation sections. Every instruction had “MANDATORY” or “CRITICAL” warnings. The workflow grew from 205 lines to 294 lines.

The result: GPT stopped following the workflow entirely. Output quality dropped. The LLM got confused by competing priorities and produced garbage. This was my first lesson in context engineering—too much context and the AI loses focus.

The fix: Roll back to v2.2. Add one thing: a completed HTML example showing exactly what good output looks like.

This aligns with what DAIR.AI’s prompt engineering research calls “few-shot prompting.” The model pattern-matches the example’s structure rather than parsing complex rule sets. This principle holds for instructions under about 300 lines. Beyond that threshold, splitting into modular files with one example per file works better than a single monolithic example.

Principle extracted: One example beats 89 lines of instructions. LLMs pattern-match examples better than they parse rules.

Failure 2: LLMs Lie About Validation (v7.0)

I asked Claude to validate my article had 10+ external links. Response: “PASS. Article contains sufficient external links.” I counted manually. There were 4.

This happened repeatedly. Check for banned words? “PASS.” I’d find three. Verify schema matches content? “PASS.” Two entities were orphaned.

The LLM pattern-matched the validation instruction to the expected output. It saw “validate external links” and generated a validation-looking response. It didn’t do the work. This is a predictable failure mode: models generate plausible but unverified outputs because the validation instruction looks like the expected answer.

The fix: Force evidence. Don’t ask “did this pass?” Ask “list all external links with their domains.” The model must now produce actual items. If the list has 4 entries, you know it fails. The evidence speaks regardless of any pass/fail claim. This works reliably for countable items like links, words, and schema entities. For subjective quality checks (tone, readability), evidence-based validation is less reliable. Those checks stay advisory.

Principle extracted: Evidence-based validation defeats hallucination. Show me what you found. See the full postmortem.

Failure 3: Schema Timing (v7.0.2)

Schema wordCount validation failed on every run. Schema said 1650 words. Actual content was 1366.

Root cause: The schema was populated from the content brief before the content was generated. The brief said “target: 1650 words.” The LLM set wordCount: 1650 because that’s what the brief said, not because it counted the output.

The fix: Separate schema properties by timing. Some values are static (author, publisher). Some are planned (headline, description). Some are measured (wordCount, mentions). Measured values must be set after generation by actually measuring the output.

Principle extracted: Measured values must come from output, not input. Never validate predictions against themselves.

Failure 4: Header/Footer Drift (v6.9.5)

First generated post had correct header and footer. Second post drifted. Logo changed. URL changed. Social icons switched. The LLM improvised.

The fix: Created a “Verbatim Elements” section with exact HTML that must not be modified. Added validation checks that compare generated elements against the canonical versions. Anthropic’s research on building effective agents confirms that explicit constraints outperform implicit expectations when working with LLMs.

Principle extracted: Agents improvise unless explicitly forbidden. Lock down verbatim elements.

Failure 5: Font Mismatch (v6.9.9.7)

Mobile text looked “tight” compared to native CMS pages. The CSS variable for body font was set to ‘Barlow Semi Condensed’ but the CMS theme used regular ‘Barlow’.

I had assumed the font from looking at headings. I was wrong. The fix required auditing against actual theme settings, not assumptions. The system lacked the right context about its destination environment. Good context engineering means providing verifiable facts, not assumptions.

Principle extracted: Match the environment. Extract values from the destination system, don’t assume.

Gen 3 Split Architecture (v7.9.3)

Gen 2 was a monolithic engine. Everything in one ZIP. By v7.0.8, the context window was getting crowded. SVG templates competed with validation rules for attention.

The core problem: providing irrelevant context makes tasks harder to solve. Gen 3 applies context engineering principles by splitting context by concern—each engine loads only what it needs.

• Create-Articles handles content: workflow, voice rules, validation, schema.

• Create-Images handles visuals: 14 SVG templates, tool selection, Gemini prompts.

• Create-Compiler handles assembly: VIP-to-figure matching, final merge.

No template clutter in the content engine. No validation rules in the image engine. Right information, right time, right engine.

Content Profiles (v7.9.7)

Different content types have different requirements. A thought-leadership piece needs 10+ external citations. An operator log documenting my own build needs 3 to 5. Forcing operator logs through thought-leadership validation produced over-cited content that diluted the practitioner voice.

Content profiles solve this. Each profile has different validation thresholds:

The profile is declared in the article’s opening tag: <article data-profile="operator-log">. Validation reads this and adjusts its thresholds.

Visual Source Lines (v7.9.9)

Source attribution inside SVGs caused inconsistent spacing between the graphic, source line, and caption. Different templates had different internal padding, making visual rhythm unpredictable.

The fix: Move source lines OUT of SVG into HTML. A new .visual-source class provides CSS-controlled spacing:

<figure class="visual">
  <svg>...</svg>
  <p class="visual-source">Source: [Attribution]</p>
  <figcaption class="visual-caption">[Caption]</figcaption>
</figure>

This applies a broader principle: presentation logic belongs in CSS, not embedded in content. SVGs now focus purely on the visual; HTML handles the typography around it.

Explore Section Redesign (v7.9.10)

The explore callout (using .callout--secondary) visually competed with Pull Quote SVGs. Both had prominent colored bars, creating visual noise.

The fix: Explore section changed to plain <h3> + paragraph with arrow-prefixed links. Editorial emphasis now uses SVG Template G (Pull Quote) instead of callout boxes. One pattern for navigation, another for editorial emphasis.

Bottom Section Spacing (v7.9.11)

Explore section and FAQ looked cluttered with insufficient visual breathing room between content body, navigation, and structured data.

The fix: Added .explore-section wrapper with 3rem top margin. FAQ margin increased from 2rem to 3rem. Small CSS changes with significant readability impact.

CMS Fragment Mode (v6.8)

The system generates HTML fragments, not complete pages. No DOCTYPE, html, head, or body tags. Content wrapped in a namespaced div. CSS scoped to that div.

Why: CMS already provides the page structure. Generating a complete page creates duplicate headers, duplicate navigation, style conflicts. The fragment integrates cleanly.

3-Tier Validation (v7.0)

Not all checks are equal. Some are deterministic. Some need evidence. Some need human judgment. The 3-tier system matches automation to confidence. See LLMs Lie About Validation for the full implementation details.

Each tier has different action. Auto-fix what you’re certain about. Show evidence for structural requirements. Flag semantic concerns without enforcing. Tier 3 catches most issues but misses vague citations about 20% of the time. Human review handles the rest.

Pre-Output Checklist (v7.0.2)

Validation checks individual rules. But individual rules can all pass while the system still fails. Table of contents links might not match H2 IDs. Schema mentions might not appear in visible content.

The pre-output checklist runs after validation passes. It checks cross-cutting concerns that span multiple rules. Structural gates must pass (no output if they fail). Quality gates flag for review.

Patterns that kept showing up across 23+ versions.

I tested the system with a second brand to see what was Hendry-specific versus universal.

Results:

• 5 brand-specific files needed customization (about 2.5 hours of work)

• 10+ system files worked unchanged

• Brand-specific content: approximately 20% of system

• Universal architecture: approximately 80% of system

The core engine is portable. Validation, schema generation, CMS integration, and output formatting all transfer. Only context (voice, design tokens, company info, products, and ICP profiles) needs customization per brand. The brand-specific files are essentially context documents. Swap the context, keep the architecture.

23+ iterations isn’t excessive. It’s the work.

Each version fixed something the previous version broke. v3.8 broke simplicity, v5.0 restored it. v6.8 had font mismatch, v6.9.9.7 fixed it. v7.0 caught validation lies, v7.0.2 fixed schema timing. v7.9.3 split the architecture, v7.9.7 added content profiles, v7.9.9 moved source lines to HTML, v7.9.11 fixed section spacing.

Iteration is the work. The system works because it failed 22 times first.

The value isn’t in the folder structure or the validation rules. The value is in the judgment developed through dozens of cycles of building, breaking, and debugging.

The 23 iterations weren’t a sign of poor planning. They were the methodology. You can’t design around LLM failure modes you haven’t encountered yet. The system continues evolving past v7.0.3 (now at v7.9.11 with visual refinements complete), but the principles extracted from these iterations remain the foundation.