같은 프롬프트, 다른 조건 (Astryx 포함), 측정(평가표) 가능한 결과.
"우리 디자인 시스템이 AI가 쓰기 좋은가"를 의견이 아니라 점수로 결정하는 장치이다. AI 판이 너무 빨리 바뀌어서 어떤 게 맞는 선택인지 머리를 싸매봤자, 알 수 없었고, 그래서 측정할 방법이 필요했다는 게 동기. 어차피 AI 로 개발할테니, AI 한테 맡겨서 판단하자는 발상…!
같은 프롬프트를 (여기선 배터리라고 표현) 4개 타깃으로 관찰한다.
astryxastryx+tailwindbaseline = shadcn+Tailwind순수 HTML에 던지고,
6개 채점표로 (correctness · a11y · code quality · efficiency · maintainability + 스크린샷 기반 design) 채점한다. 단순 앞의 5개는 LLM 없이 결정론적 정적 분석(src/universal-eval.ts), design만 비전 LLM 심사.
1. 자기 시스템을 특권화하지 않는다. 최초 하니스(PR #57)는 그렇지 않았으나, "에이전트가 Astryx를 우리가 원하는 방식으로 썼나". 이건 Astryx가 정답이라고 이미 가정하는 자다. PR #243이 그걸 버리고 target-neutral로 갔다:
"is Astryx actually better, or do we just prefer it?"
2. 답을 흘리지 않는다. expectedComponents는 평가 전용이라 프롬프트에 안 들어가고, 시스템별 코칭("StyleX를 써라")도 금지, 서브에이전트는 매번 새로 뜬다.
따라서 프롬프팅 과정에서도 힌트를 안 준다. "CollapsibleGroup으로 아코디언" 하라는 이미 답을 주는 거 말고 "사용자가 각 질문을 펼치는 FAQ 페이지" 만들어~
환경도 실제 소비자 기준: Astryx 하위의 소스 레포가 아니라(그러면 Agent 가 그걸 알고서 할테니) node_modules 안의 README를 테스트한다.
3. 불리하게 채점한다. README에 Known Accepted Asymmetries 절이 따로 있고,
의도적으로 baseline에 유리하게 남긴 비대칭을 공개한다. 이유는 "making Astryx wins more credible".