The repeated-work tax

Slide-Hustle generates a five-slide HTML/CSS carousel and exports each frame at 1080×1080. The first version worked, but every run asked the model to reconstruct the same visual system: CSS rules, layout conventions, brand decisions, and correction history.

The token bill came from four places: repeated CSS, prose descriptions of design rules, full regeneration for isolated fixes, and conversation context that grew with every revision.

Make the agent operate a system

I separated stable knowledge from changing content. The stable layer became a reusable carousel.css, a concise BRAND.md, a workflow contract in FRAMEWORK.md, and fixed templates. Each new carousel arrived as a structured YAML brief.

The agent's job became smaller: interpret the brief, select a template, inject content, make local corrections, and export. It no longer had to reinvent the product on every run.

Context engineering principle: if information is stable across tasks, store it once and reference it. Do not repeatedly pay the model to recreate it.

Three rules that transferred

  1. Externalize static knowledge. Brand rules, schemas, examples, and constraints belong in versioned files.
  2. Structure changing input. A compact schema is easier to validate and cheaper to process than a long conversational brief.
  3. Isolate corrections. Fix the affected component or data field instead of regenerating the whole output.

Estimate your own workflow

The exact result depends on model, context size, and task shape. The useful question is architectural: how much of each request is reusable knowledge, and how much genuinely changes?

Try the estimatorView source

Adapted from the original Medium publication.