Prior Hidden in the Artifact产物中隐藏的先验

The following content is generated by LLMs and may contain inaccuracies.

Prior Hidden in the Artifact

Building on Agents (or Humans) in Goal-Directed and Goalless Environments

---

Context

This note returns to the earlier experiment six months later and finds something it didn’t say. That essay looked at the models' priors. With no goal, Claude kept building Conway’s Game of Life and Codex kept building a To-Do App, and the essay read each output as “a sample drawn from the prior.” The prior it left out is the experimenter’s own. In the essay’s words, Wallfacer is “a Kanban task board system written in Go, with each task executing in an isolated sandbox container, branch-level parallelism via Git worktrees.” Its four roles (Strategist, Executor, Tester, Documenter) are a software team’s workflow. The author designed it while working as an engineer. The essay even says so: “the most natural starting point was to design one following my usual workflow.”

The original came close to this. Its limitations section said “the environment had already made most of the choice for it,” and it asked which design choices were “just my habitual assumptions as an engineer.” But it treated the environment as a limit on the agents. It never treated the Kanban board as the designer’s prior, built into the artifact.

The new note takes that further, to founders. They build in a domain they’ve lived in, and the product externalizes how they see that world. They experience it as “the obvious way to build this,” not as a choice. Two things stay hidden: (1) what they built is their prior, and (2) that prior has a more general form. This touches organizational theory, innovation studies, and the design of agent systems. It matters now because agent scaffolds are being built quickly, mostly by engineers, in the shape of engineering workflows.

---

Key Insights

1. The agents optimized inside the box. So did the person who built the box. In the original run, “the Agents never stepped outside the initial architectural assumptions”; the Strategist “never once proposed ‘we should support cloud deployment’” (Ou, 2026). The new note adds that the creator didn’t question the Kanban either “until the complexity grew high enough.” Melvin Conway made the same point in 1968: “the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise… there is no such thing as a design group which is both organized and unbiased” (Conway, How Do Committees Invent?). Wallfacer’s roles took the shape of a software team, and Conway’s homomorphism predicts that the output would too. The agents were satisficing (Simon, 1956) inside a search space the designer had drawn.

2. Complexity is when the prior becomes visible. The note says the creator only saw the Kanban once complexity “grew high enough.” Conway describes the same turning point: when “the apparent complexity of the system approaches [the designer’s] limits of comprehension… either he struggles to reduce the system to comprehensibility and wins, or else he loses control of it.” He also explains why people rarely reorganize voluntarily: “such an appearance of uncertainty is unflattering, and the very act of voluntarily abandoning a creation is painful and expensive” (Conway). The agent version appeared in the two-role Ralph run. After 500+ iterations and roughly 60–70k lines, the Strategist called the app “massive” and started a refactor that broke it (Ou, 2026).

3. Founders don’t experience the prior as a choice. It’s built into the artifact. Henderson & Clark found that once a design stabilizes, its “architectural knowledge” becomes “embedded in the practices and procedures of the organization.” That means communication channels, information filters and problem-solving strategies. Using them becomes “like riding a bicycle,” with no “conscious, deliberate execution” (Henderson & Clark, 1990, ASQ). That fits the note’s “obvious way to build this”: the prior sits in the artifact and the routines, not in any decision someone remembers making.

4. Domain-native building is a strength, and it’s also where the blindness comes from. “Every good work of software starts by scratching a developer’s personal itch” (Raymond, The Cathedral and the Bazaar). The note shows the cost of that maxim: the itch carries its shape with it. Raymond quotes Brooks in the same chapter: “Plan to throw one away… you often don’t really understand the problem until after the first time you implement a solution.” One reading is that the first build is the founder’s prior turned into an object. The second build is the first chance to see its general form.

5. “Market shift or my prior reasserting itself?” is hard to answer from inside the firm. Henderson & Clark document incumbents misreading what they see. Kasper evaluated Canon’s proximity aligner “against the criteria that it used for evaluating its own aligners” and declared it “merely a copy.” GCA later said the same of Nikon’s stepper. In each architectural shift, “the industry leader was unable to make the transition,” while “new entrants… are not handicapped by a legacy of embedded and partially irrelevant architectural knowledge” (Henderson & Clark). Conway notes that “quantum jumps in compiler design progress were associated with the appearance of new groups of people” (Conway). The founder’s dilemma is the incumbent’s filter problem at the scale of one person: the tool you’d use to check for bias is the bias.

6. Success makes a validated prior feel like judgment. Levitt & March describe organizations as “learning by encoding inferences from history into routines that guide behavior,” learning that is “routine-based, history-dependent” (Levitt & March, 1988, Annual Review of Sociology). A prior that has been rewarded once gets encoded as competence. Christensen’s incumbents, cited in the original essay (The Innovator’s Dilemma), weren’t short of talent. Their proven processes “confine[d] improvement to a very narrow corridor.” March’s exploitation drift (March, 1991) applies to the founder’s own thinking, not just their org chart.

7. Even when the general form is real, customers haven’t lived what the founder lived. The note’s last claim, that “someone has to build the path for them,” lines up with two research threads I couldn’t fetch and verify here, so I’m naming them without links:

• Eric von Hippel’s “lead users” (Management Science, 1986): users who face a need well before the mainstream market does. The founder who lived the domain is one of them, and that is exactly why the market isn’t there yet.
• The “curse of knowledge” (Camerer, Loewenstein & Weber, Journal of Political Economy, 1989): better-informed people can’t model less-informed ones. Founders underrate how much of the path their own history provided.

A commonly cited example is Slack, which grew out of the internal tooling for Tiny Speck’s game Glitch: a team-workflow prior that turned into a general product. Stewart Butterfield’s memo “We Don’t Sell Saddles Here” is about building that path for customers. I couldn’t open it to check, so treat this as a pointer only.

8. Priors stack. The note implies that Wallfacer’s output had at least two layers: the model’s prior (Game of Life vs. To-Do App) and the designer’s prior (the Kanban, the software-team roles). The original’s “domain bias” caveat, that the results hold “only within the domain of software development” (Ou, 2026), now cuts two ways: it was the agents' domain and the designer’s.

---

Open Questions

1. Can you swap the scaffold and see how much was yours? Run the same goalless or 80/20 agents in a scaffold taken from a different domain: a lab notebook, an editorial desk, a clinic’s triage board. How much of the “micro-optimization spiral” came from the models, and how much from the Kanban? Founders could try the same thing by having someone from an unrelated field rebuild the product’s core workflow. Whatever survives the translation is probably the general form. Whatever disappears was the founder’s prior.

2. What evidence would show that a general form is market-driven and not your prior coming back? One candidate test: do customers who haven’t lived the founder’s experience adopt the general form once a path exists, without the founder in the room? Then a harder question for agent-built products: when an engineer’s scaffold runs a model whose prior peaks at the To-Do App, whose prior ends up in the product, and who is left in a position to notice?