Welcome, Guest | Browse

Software Factory Archive

← Previous Work All Works Next Work →

The Model Stylesheet

Rating:
General Audiences
Fandom:
StrongDM Software Factory
Characters:
Justin McCarthy Navan Chauhan Jay Taylor
Tags:
Attractor Model Stylesheet CSS Analogy LLM Selection
Words:
442
Published:
2025-09-10

Navan was the one who called it a stylesheet, and the name stuck immediately because it was exactly right.

The problem was simple: different nodes in an Attractor pipeline needed different models. The requirements-gathering node worked best with Claude, which was good at interpreting ambiguous human language. The code generation node performed well with Codex, which was optimized for writing structured programs. The assessment node, which evaluated whether generated code met the spec, benefited from a model with strong reasoning. One pipeline, multiple models, each chosen for a specific task.

"It's like CSS," Navan said one morning, holding up his notebook where he'd drawn the analogy in two columns. "CSS separates structure from presentation. HTML says what the content IS. CSS says how it LOOKS. The model stylesheet separates workflow structure from model selection. The DOT file says what the pipeline DOES. The stylesheet says what DOES IT."

Justin leaned over the notebook. "Keep going."

"So you have selectors. In CSS, you select elements by type, class, or ID. In the model stylesheet, you select nodes by handler type. All nodes of type codergen use Claude. All nodes of type assessment use Opus. You can override by node ID for specific cases."

"And if you want to change the model for every codergen node in the entire pipeline," Jay said, following the thread, "you change one line in the stylesheet. Not in the DOT file. The pipeline structure doesn't change."

"Exactly. Separation of concerns. The graph describes the workflow. The stylesheet describes the models. They're independent. You can swap the entire model stack without touching the pipeline topology."

Justin sat back. "Build the spec for it."

Navan had the spec written by lunch. It was terse—maybe forty lines. A model stylesheet was a simple mapping: handler type to model configuration. It supported default models, per-type overrides, and per-node overrides. Specificity rules, just like CSS. The most specific selector won.

By the afternoon, the first stylesheet was in use. Jay flipped two pipelines from Claude to a mixed configuration: Claude for requirements, Codex for code generation, Claude again for assessment. The pipelines didn't notice. The DOT files were unchanged. Only the stylesheet was different.

"The thing I like about this," Jay said, watching the reconfigured pipeline run, "is that it makes model selection a first-class concern. It's not buried in handler code. It's not hardcoded. It's a visible, editable, version-controllable artifact. You can diff it. You can review it."

"You can A/B test it," Navan added quietly. "Same pipeline, two stylesheets. Compare satisfaction scores."

The room went quiet with the particular silence that follows a good idea landing.

Kudos: 82

convergence_simp 2025-09-12

The CSS analogy is going to be the thing that makes Attractor make sense to every frontend developer who reads this. Separation of structure and style, but for AI pipelines. Navan cooked here.

cedar_policy_nerd 2025-09-13

A/B testing model stylesheets. Same pipeline, different models, compare satisfaction. That quiet addition at the end is worth more than most entire design documents I've read.

← Previous Work All Works Next Work →