Core Principle: Code is cheap. Taste matters

When the marginal cost of generating and implementing code is driven toward zero by large models and tensorized foundations, the scarce resource in research and system building shifts from "can we write it" to "is it worth doing, and what counts as doing it well."

Code is cheap is an objective description of the current state of engineering: once implementation costs collapse, code is no longer a barrier, nor a unit of measurement for research contribution—"it runs" degrades from an achievement to a prerequisite, from a showable result to a ticket to keep working.

Taste matters is a repositioning of human responsibility after the human-machine division of labor: when "AI implements the answers, humans steer the direction" becomes the default, what is truly scarce on the human side is the ability to ask the key questions, set evaluation criteria, and judge direction amid conflicting objectives.

Where Has Scarcity Shifted To?

Problem selection: which problem you tackle determines your ceiling more than which method you use. When the direction is wrong, the faster you implement, the more you waste.
Design of objective functions and evaluation criteria: once the wrong metric is chosen, the model will only converge efficiently toward the wrong direction.
Trade-off rules for multi-objective decisions: preferences among performance, reproducibility, maintainability, and deployment cost must be explicitly declared, not decided on the fly.
Interpretation and attribution of results: distinguish "it happened to run" from "truly understood," and determine which changes the gains actually came from.

Taste Must Be Testable

Taste is not an aesthetic assertion, nor can it be settled by seniority or voting. It must be falsified through "entering real environments—accepting real feedback": write your judgment as a verifiable hypothesis and revise it with failures and successes from real scenarios. Otherwise, the discussion boils down to a quarrel over preferences.

Why Infrastructure Matters: Giving Taste Somewhere to Land

EvoX's ultimate goal lands exactly here: building open infrastructure that can enter real environments and accept real feedback. An open, decoupled, composable foundation lowers deployment costs enough that good ideas can enter real scenarios at low cost, where they are selected, consolidated, and inherited—giving judgment a vehicle that can be honed again and again.

Knowing the Boundaries: Code cheap does not mean engineering can be skipped

Acceptance gates, reproducibility, maintainability, and feedback loops still form real thresholds. Taste is reflected precisely in the judgment of how to handle these thresholds: which feedback is worth trusting, which metrics must be upheld, and which failed attempts should be rejected rather than merged. This is exactly where the value of a Genesis-style mechanism lies—only candidate changes that pass compilation, tests, behavioral checks, and top-level acceptance can become a historical foundation that subsequent executors can inherit.

An Echo

Turing wrote at the end of Computing Machinery and Intelligence: we can only see a short distance ahead, but we can see plenty there that needs to be done. Rather than debating the exact form of intelligence's endgame, it is better to first build open infrastructure that can continuously enter real scenarios and accept real feedback, so that every round of exploration can be validated and inherited.

This page follows up on the previous page's division of labor—"AI implements the answers, humans steer the direction"—and presents the core principles behind it; the next page moves into hands-on practice of guiding AI through EvoX tasks via dialogue.

Code cheap, Taste matters Poster

Centered on "Code is cheap. Taste matters," this poster shows that after implementation costs collapse, scarcity shifts to problem selection, the design of objective functions and evaluation criteria, multi-objective trade-off rules, and result attribution. Turing's quote and the EvoX vision are placed side by side, emphasizing that taste cannot rest on assertions alone—it must be tested through real-world feedback and, via open infrastructure, consolidated into inheritable judgment.

Question 1

With implementation costs driven toward zero, what is the most accurate engineering meaning of "Code is cheap"?

Code quality no longer matters, so engineering validation can be skipped and code shipped directly

The marginal cost of generating and implementing code approaches zero, so "it runs" degrades from an achievement to a prerequisite

Lines of code remain the primary metric for measuring research contribution

As long as the model is strong enough, no one needs to write code anymore

Question 2

After implementation costs collapse, where has the truly scarce resource shifted to?

Proficiency in programming languages and framework experience

Lines of code produced per unit of time

Problem selection, the design of objective functions and evaluation criteria, multi-objective trade-off rules, and the interpretation and attribution of results

GPU compute power and VRAM capacity

Question 3

Why is it said that "taste is not an aesthetic assertion"?

Because taste must be falsified through "entering real environments—accepting real feedback"; otherwise only a quarrel over preferences remains

Because taste can be measured directly by lines of code and commit frequency

Because taste is ultimately decided by the votes of senior researchers

Because taste only comes into play during paper review

Question 4

Which of the following still constitutes a real threshold that "Code is cheap" cannot skip for us?

Acceptance gates, reproducibility, maintainability, and feedback loops

The number of candidate changes and commit frequency

Code completion accuracy and development environment response time

Coding speed, framework popularity, and model parameter count

Question 5

What is the core purpose of EvoX building open, decoupled, composable infrastructure?

To further drive implementation costs to zero so that feedback loops are no longer needed

To lower deployment costs so that good ideas can enter real scenarios at low cost to be selected, consolidated, and inherited—giving taste a testable place to land

To let candidate changes enter the mainline version directly without acceptance

To replace human judgment and trade-offs with automated processes

Case Study: Trade-off Judgment in Genesis-Style Continuous Evolution

Read the scenario and answer the questions, writing out your reasoning process.

A scientific computing team uses a Genesis-style multi-agent collaboration approach to upgrade a long-maintained numerical codebase: upper-level executors understand goals and break down tasks, lower-level executors complete local implementations and tests within limited context, and the models can produce dozens of candidate changes per day. The team soon discovers that the real bottleneck is no longer "being unable to write it," but rather—among the large number of candidate changes that all compile—judging which ones deserve to enter the accepted project version, which metrics must be upheld, and which failed attempts should be rejected.

Given "Code is cheap. Taste matters," which stages should the team prioritize its limited manpower toward? List at least three and explain what problem each one solves.

Answer:
Key points: (1) Problem selection and goal definition—it sets the ceiling on your exploration direction and prevents you from efficiently optimizing a problem that isn't worth doing; (2) Design of objective functions and evaluation criteria—the wrong metric will make the model converge efficiently toward the wrong direction; (3) Formulation of acceptance gates and multi-objective trade-off rules—explicitly declare preferences and priorities among performance, reproducibility, maintainability, and deployment cost; (4) Interpretation and attribution of results—distinguish "it happened to run" from "truly understood," and determine which changes the gains came from. The reasoning: after implementation costs collapse, "being able to write it" is no longer a barrier; the stages above are the scarce capabilities that determine output quality and long-term accumulation.

Please design a candidate-change acceptance process that can test "taste," and explain how it works with the "candidate change—acceptance—historical inheritance" mechanism.

Answer:
Reference process: ① After a candidate change is submitted, compile it and run tests and behavioral checks in an isolated environment; ② Score it against pre-declared evaluation criteria (performance, reproducibility, maintainability) and assess whether it solves a problem worth solving; ③ Upper-level executors accept or reject it, rejecting unqualified or wrongly-directed attempts and recording the attribution; ④ Accepted changes are written into the accepted project version, becoming a historical foundation that subsequent executors can inherit; ⑤ The change's performance in real environments flows back as feedback to revise the evaluation criteria themselves. In this way, taste is written as a falsifiable judgment rather than a personal preference—failed attempts can be rejected, effective results can be inherited, and judgment is honed again and again through the loop.