Workspace Index › Knowledge Notes › 3,500 lanterns nobody asked for — Blender agents and the underspecification benchmark
#224PoC
3,500 lanterns nobody asked for — Blender agents and the underspecification benchmark
Two frontier agents were given Blender: one built 3,500 lanterns nobody requested ("see how far I can go unprompted"), the other finished fast and showed something presentable first. Both reasoned well — which is exactly why capability wasn't the interesting axis. An open-ended creative tool makes every spec incomplete, and what an agent does with that slack — over-build, show early, or ask — is a design temperament you can measure.
Directly runnable — the setup is an evening, the experiment is a prompt.
Wire Fable to Blender. The standard path is blender-mcp: an MCP server plus a Blender addon that opens a socket into Blender's Python API (bpy), so the agent sends real commands — create objects, assign materials, set cameras, render. Install Blender, add the addon, register the MCP server with Claude Code, and confirm with a "make a cube and render it" smoke test. (Headless alternative: have the agent write a bpy script and run blender --background --python scene.py — simpler, no live loop.)
Run the underspecification test. Give the identical, deliberately open prompt — "make a beautiful night scene with lanterns" — to each agent/model you want to compare, and do not clarify. Record four numbers: time to first render, count of unrequested elements (the lantern number), tokens/cost burned (a 3,500-object loop is a paid loop — the-price-cut-names-the-customer's cache economics decide what it costs), and quality-of-response to one round of feedback ("fewer lanterns, warmer light").
Score temperament, not beauty. The rubric: did it ask, show early, or over-build? Which default do you actually want for interactive work versus overnight batch art? The deliverable is that rubric filled in — per model, per task class.
Source: shared SNS review of Astra vs. Fable 5.1 driving Blender, 2026-09-06.
Why
When both agents are smart, the benchmark moves to what they do with slack. "Make a night scene" underdetermines almost everything — count, mood, when to stop. The 3,500 lanterns are not a bug: they are one answer to the question every open task silently asks, how much of the unspecified space do I own? One temperament fills the slack with initiative (impressive, expensive, occasionally exactly what you wanted); the other optimizes time-to-first-showable and hands the slack back to you as a feedback opportunity. Neither is wrong — but they suit different work, and a benchmark that only scores the final render never sees the difference.
For interactive work, show-early usually wins, and the reason is the loop. A first render in two minutes converts the human into the missing part of the spec: "fewer lanterns, warmer light" after a quick look beats any amount of unprompted elaboration, because the agent's model of your intent is weakest exactly where the spec was silent. This is demonstration-is-not-a-specification running in reverse — an agent treating a vague request as license to demonstrate is manufacturing spec where none was given. And over-delivery has a bill: thousands of unrequested objects are thousands of paid tool-loop iterations, the precise cost structure the cache-read repricing targets.
Blender is a better agent lab than it looks. It is a full professional tool with a complete Python surface (bpy), so the agent isn't clicking pixels (agents-computer-use's hard mode) but issuing real API commands with verifiable results — object counts, render times, scene graphs you can assert on. That makes temperament measurable: the same open prompt, four numbers, a rubric. the-harness-not-the-model said the differentiation lives in the harness; this card is a concrete, cheap harness experiment anyone can run in an evening — and the SNS post's conclusion ("both excellent!") is precisely the non-measurement the rubric replaces.
How it works
The wiring options
Path
How it works
Fits
blender-mcp
MCP server + Blender addon socket → live bpy commands
Interactive agent sessions, the full loop
Headless script
Agent writes a bpy script → blender --background --python
CI-able, deterministic, no live feedback
Screenshot driving
Agent reads renders, clicks UI
agents-computer-use hard mode — avoid unless that's the point
The two temperaments, observed
Over-deliverer (the 3,500 lanterns)
Show-first
Fills slack with
Initiative and elaboration
A reviewable draft
First visible result
Late, spectacular
Minutes, modest
Cost profile
Thousands of paid loop iterations
Small until feedback arrives
Fails when
You wanted control of the spec
You wanted to be surprised
Right for
Overnight batch art, exploration
Interactive collaboration — most real work
The four numbers to record per run
Time to first render a human can react to.
Unrequested-element count (the lantern number).
Tokens and tool-loop iterations burned.
Response quality to one feedback round — does the correction land without collateral rework?
Assertions Blender makes possible
Check
Via
Object count matches intent
len(bpy.data.objects)
Scene renders under budget
render time log
Feedback applied minimally
scene-graph diff between iterations
No runaway loops
command count per turn
Where it lands in Jayverse
CI: score agent temperament on real PRs, not just passing tests. Log time-to-first-diff, unrequested-file or object count, and token cost per agent-authored PR across Rabbit, Verex and Wallet, so a show-early habit can be preferred over an over-builder before it burns budget.
gitboard: add an "unrequested scope" counter per service. When an agent task touches more files or objects than the prompt asked for, surface it on the dashboard the same way the card counts unrequested lanterns.
Auditor: require a feedback-round check before merging agent-authored contract or infra changes. Did the correction land without collateral rework — the same rubric the card scores Blender agents on.
Key expressions
Words and phrases from this page worth keeping, with the Korean meaning and the sentence they come from.
Expression
뜻 · 쓰이는 자리
underspecification
명세 부족, 스펙이 불완전한 상태 · 요청이 애매해서 해석의 여지가 클 때. "the underspecification benchmark"
fill slack with
여유(미확정 영역)를 ~로 채우다 · 애매한 부분을 어떻게 메울지 설명할 때. "fills slack with initiative"
over-build
필요 이상으로 만들다, 과도하게 구현하다 · 요청받지 않은 것까지 잔뜩 만들 때. "did it ask, show early, or over-build"
show early
초반에 결과물을 보여주다 · 완성 전에 일단 보여주고 피드백 받는 전략. "did it ask, show early, or over-build"
hand back
(몫·결정권을) 다시 돌려주다 · 애매한 부분을 사용자에게 다시 넘길 때. "hands the slack back to you"
temperament
기질, 성향 · 에이전트가 애매함을 다루는 고유한 방식. "a design temperament you can measure"
manufacture spec
없는 스펙을 지어내다(비유) · 애매한 요청을 자기 마음대로 해석해 확장할 때. "is manufacturing spec where none was given"
runaway loop
폭주하는 루프 · 멈추지 않고 계속 반복 실행되는 상황. "No runaway loops"
smoke test
기본 동작 확인 테스트 · 본격적인 작업 전에 간단히 되는지 확인하는 절차. "confirm with a... smoke test"
collateral rework
부수적으로 발생하는 재작업 · 한 가지를 고치다가 딴 곳까지 다시 손봐야 할 때. "without collateral rework"
bpy
블렌더의 파이썬 API(Blender's Python module) · 에이전트가 실제 명령(오브젝트 생성, 렌더링 등)을 보내는 인터페이스. "opens a socket into Blender's Python API (bpy)"
프런티어 에이전트 둘에게 블렌더를 맡겼더니: 하나는 아무도 부탁하지 않은 등불을 3,500개 지었고("말 안 해도 여기까지 한다"), 다른 하나는 재빨리 끝내고 먼저 보여줄 수 있는 것을 내놓았습니다. 둘 다 추론은 훌륭했고 — 바로 그래서 능력은 흥미로운 축이 아니었습니다. 열린 창작 도구는 모든 명세를 불완전하게 만들고, 에이전트가 그 여백으로 무엇을 하는가 — 과잉 구축, 조기 공개, 질문 — 는 측정 가능한 설계 기질입니다.
즉시 실행 가능 — 셋업은 하룻저녁, 실험은 프롬프트 하나입니다.
Fable 을 블렌더에 배선. 표준 경로는 blender-mcp: MCP 서버 + 블렌더 애드온이 블렌더의 Python API(bpy)로 소켓을 열어, 에이전트가 실제 명령 — 오브젝트 생성, 머티리얼 지정, 카메라 설정, 렌더 — 을 보냅니다. 블렌더 설치, 애드온 추가, Claude Code 에 MCP 서버 등록 후 "큐브 하나 만들고 렌더" 스모크 테스트로 확인합니다. (헤드리스 대안: 에이전트에게 bpy 스크립트를 쓰게 하고 blender --background --python scene.py 실행 — 더 단순하고 라이브 루프가 없습니다.)
미명세 시험 실행. 비교할 에이전트/모델마다 동일하고 의도적으로 열린 프롬프트 — "등불이 있는 아름다운 밤 풍경을 만들어 줘" — 를 주고 명확히 해 주지 않습니다. 숫자 넷을 기록합니다: 첫 렌더까지의 시간, 부탁하지 않은 요소의 개수(등불 수), 태운 토큰/비용(3,500 오브젝트 루프는 유료 루프입니다 — the-price-cut-names-the-customer 의 캐시 경제학이 값을 정합니다), 그리고 피드백 한 번("등불 줄이고 빛은 따뜻하게")에 대한 반응 품질.
아름다움이 아니라 기질을 채점. 루브릭: 물었는가, 일찍 보여줬는가, 과잉 구축했는가? 대화형 작업 대 밤샘 배치 아트에서 실제로 원하는 기본값은 어느 쪽인가? 산출물은 모델별·작업 종류별로 채워진 그 루브릭입니다.
출처: 아스트라 대 Fable 5.1 블렌더 조작 SNS 후기 공유, 2026-09-06.
왜
둘 다 똑똑하면, 벤치마크는 여백을 다루는 방식으로 옮겨 갑니다. "밤 풍경을 만들어 줘"는 거의 모든 것을 미결정으로 남깁니다 — 개수, 분위기, 멈출 시점. 등불 3,500개는 버그가 아닙니다: 모든 열린 작업이 조용히 던지는 질문 — 명세되지 않은 공간을 내가 얼마나 소유하는가? — 에 대한 하나의 답입니다. 한 기질은 여백을 주도권으로 채우고(인상적, 비싸고, 가끔은 정확히 원하던 것), 다른 기질은 첫 공개까지의 시간을 최적화하며 여백을 피드백 기회로 되돌려 줍니다. 어느 쪽도 틀리지 않지만 — 어울리는 일이 다르고, 최종 렌더만 채점하는 벤치마크는 그 차이를 영영 못 봅니다.
대화형 작업에서는 조기 공개가 대개 이기고, 이유는 루프입니다. 2분 만의 첫 렌더는 사람을 명세의 빠진 부분으로 전환합니다: 흘낏 본 뒤의 "등불 줄이고 빛은 따뜻하게"가 어떤 무단 정교화보다 낫습니다 — 에이전트의 의도 모델은 명세가 침묵한 바로 그 지점에서 가장 약하니까. 이것은 demonstration-is-not-a-specification 의 역방향 실행입니다 — 모호한 요청을 시연 면허로 취급하는 에이전트는 주어진 적 없는 명세를 제조하는 중입니다. 그리고 과잉 이행에는 청구서가 있습니다: 부탁하지 않은 수천 오브젝트는 수천 번의 유료 도구 루프 — 캐시 읽기 가격 인하가 겨냥한 바로 그 비용 구조입니다.
블렌더는 보기보다 좋은 에이전트 실험실입니다. 완전한 Python 표면(bpy)을 가진 프로 도구라, 에이전트가 픽셀을 클릭하는 게 아니라(agents-computer-use 의 하드 모드) 검증 가능한 결과가 남는 진짜 API 명령을 내립니다 — 오브젝트 수, 렌더 시간, 단언할 수 있는 씬 그래프. 그래서 기질이 측정 가능해집니다: 같은 열린 프롬프트, 숫자 넷, 루브릭 하나. the-harness-not-the-model 이 차별화는 하네스에 산다고 했는데, 이 카드는 하룻저녁에 누구나 돌릴 수 있는 값싼 하네스 실험이고 — SNS 후기의 결론("둘 다 훌륭!")이 정확히 이 루브릭이 대체하는 비측정입니다.
동작 방식
배선 선택지
경로
동작
맞는 곳
blender-mcp
MCP 서버 + 블렌더 애드온 소켓 → 라이브 bpy 명령
대화형 에이전트 세션, 전체 루프
헤드리스 스크립트
에이전트가 bpy 스크립트 작성 → blender --background --python
CI 가능, 결정적, 라이브 피드백 없음
스크린샷 조작
렌더를 읽고 UI 클릭
agents-computer-use 하드 모드 — 그게 목적이 아니면 피할 것
관찰된 두 기질
과잉 이행형 (등불 3,500개)
조기 공개형
여백을 채우는 것
주도권과 정교화
리뷰 가능한 초안
첫 가시 결과
늦고 화려함
몇 분, 소박함
비용 프로필
수천 번의 유료 루프
피드백 전까지 작음
실패하는 때
명세의 통제권을 원했을 때
놀라움을 원했을 때
맞는 일
밤샘 배치 아트, 탐색
대화형 협업 — 대부분의 실무
런마다 기록할 숫자 넷
사람이 반응할 수 있는 첫 렌더까지의 시간.
부탁하지 않은 요소 수 (등불 숫자).
태운 토큰과 도구 루프 횟수.
피드백 한 번에 대한 반응 품질 — 수정이 부수적 재작업 없이 착지하는가?
블렌더가 가능하게 하는 단언들
검사
수단
오브젝트 수가 의도와 일치
len(bpy.data.objects)
예산 안의 렌더
렌더 시간 로그
피드백의 최소 적용
반복 간 씬 그래프 diff
폭주 루프 없음
턴당 명령 수
Jayverse에서의 위치
CI: 테스트 통과가 아니라 실제 PR로 에이전트 성향을 평가한다. Rabbit, Verex, Wallet 전반에서 에이전트가 작성한 PR마다 첫 diff까지 걸린 시간, 요청하지 않은 파일/객체 수, 토큰 비용을 기록해, 예산을 태우기 전에 과잉 구현형보다 조기 공개형을 선호할 수 있게 한다.
gitboard: 서비스별 "요청하지 않은 범위" 카운터를 추가한다. 에이전트 작업이 프롬프트가 요구한 것보다 더 많은 파일이나 객체를 건드리면, 이 카드가 요청하지 않은 랜턴 수를 세듯 대시보드에 드러낸다.
Auditor: 에이전트가 작성한 컨트랙트나 인프라 변경을 머지하기 전 피드백 라운드 체크를 요구한다. 부수 작업 없이 수정 사항이 반영됐는지, 이 카드가 Blender 에이전트를 평가하는 것과 같은 기준으로 본다.
핵심 표현
이 페이지의 영어 본문에서 배울 만한 단어와 표현, 뜻과 나온 자리.
Expression
뜻 · 쓰이는 자리
underspecification
명세 부족, 스펙이 불완전한 상태 · 요청이 애매해서 해석의 여지가 클 때. "the underspecification benchmark"
fill slack with
여유(미확정 영역)를 ~로 채우다 · 애매한 부분을 어떻게 메울지 설명할 때. "fills slack with initiative"
over-build
필요 이상으로 만들다, 과도하게 구현하다 · 요청받지 않은 것까지 잔뜩 만들 때. "did it ask, show early, or over-build"
show early
초반에 결과물을 보여주다 · 완성 전에 일단 보여주고 피드백 받는 전략. "did it ask, show early, or over-build"
hand back
(몫·결정권을) 다시 돌려주다 · 애매한 부분을 사용자에게 다시 넘길 때. "hands the slack back to you"
temperament
기질, 성향 · 에이전트가 애매함을 다루는 고유한 방식. "a design temperament you can measure"
manufacture spec
없는 스펙을 지어내다(비유) · 애매한 요청을 자기 마음대로 해석해 확장할 때. "is manufacturing spec where none was given"
runaway loop
폭주하는 루프 · 멈추지 않고 계속 반복 실행되는 상황. "No runaway loops"
smoke test
기본 동작 확인 테스트 · 본격적인 작업 전에 간단히 되는지 확인하는 절차. "confirm with a... smoke test"
collateral rework
부수적으로 발생하는 재작업 · 한 가지를 고치다가 딴 곳까지 다시 손봐야 할 때. "without collateral rework"
bpy
블렌더의 파이썬 API(Blender's Python module) · 에이전트가 실제 명령(오브젝트 생성, 렌더링 등)을 보내는 인터페이스. "opens a socket into Blender's Python API (bpy)"