Definition Is the Core: When Both People and Models Change, What Assets Still Run

AI coding is just the surface; what's really changing is the entire development process. Tencent's engineering team shared a set of impressive numbers from their OK platform: end-to-end AI-delivered requirements, 68% automation rate, 51% of requirements completed within two hours. The numbers answer "fast," but they don't answer a sharper question—after migrating to this way of working, what stayed in the organization, and what left along with the people and the models.

The author spent an afternoon sorting through this question with their manager, and the criterion came down to a single sentence: if you swap the people, swap the models, swap the vendors, can the system still run at roughly the same quality and speed? If yes, it belongs to the organization; if no, it's just someone's muscle memory, one generation of a model, or lock-in to a particular vendor.

A problem without boundaries is just a wish

"I want to research what software an industry needs"—this isn't a problem, it's a wish. A wish has nowhere to stop, and no way to be checked.

The manager broke the problem into three layers: what the problem itself is, who is observing it from what angle, and where the boundary is (i.e., the domain). The first was split into three convergent sub-problems: what software the industry needs in the Agent era (requirement baseline), what current open-source projects can provide and whether they're stable enough to integrate (supply side), and how to componentize software (technical method). Once separated, each sub-problem has a place to converge.

The definition determines what to do and what counts as correct. A definition written on a wiki that nobody enforces is a liability; a definition welded to a toolchain disappears when the toolchain is replaced, and that's not an asset either. The real criterion for the core is: when the carrier is replaced, it's still there, and it still constrains the next run.

Design by Contract was proposed by Bertrand Meyer in 1986 for the Eiffel language, with the core idea that preconditions, postconditions, and invariants are part of the program (checkable at runtime), not reminders in a document. Preconditions specify what the caller must satisfy, postconditions specify what the callee must guarantee, and invariants hold true throughout the entire lifecycle. It is highly isomorphic to the "gate" idea discussed here: a check is not a wish written to the model, but a judgment executed at runtime. In AI Agent scenarios, both parties to a traditional contract are deterministic; the Agent introduces non-deterministic generation, so the enforcing party of the contract must move outward—a runtime outside the model asserts whether the condition holds, and the model itself does not participate in the pass/fail judgment.

Structure must exist, but structure written in a prompt can't stop what has already happened

"Without form, content has nowhere to reside. Without a body, what soul is there to speak of?" Form is not about stamping a document; it's that content needs a structure to carry it. Most prompts are just a line of linear description, and the model can only guess. The manager required that goals, context, conditions and constraints, output format, key conventions, injection locations, and reference passages be written separately—goals can have sub-goals, context loaded on demand, constraints injected in layers, and checkpoints in the flow marked individually. Prompts should be foldable, injectable, and full of variables, organized like loops or queues in code.

But the real problem comes later: you write in the prompt "if it doesn't pass, clarify," and the model has already given an answer, treats that step as done, and moves on. Your sentence never gets a chance to execute. The structure is still needed, but structure written in a prompt is soft. To make a process stop, the check must sit outside the model—as a runtime primitive, a mandatory checkpoint before and after execution in a script—failing means it can't enter the next stage. This is the same thing as Design by Contract: preconditions, postconditions, and invariants are part of the system, not reminders in a doc. If these checks live only in one product, the whole set disappears when you change vendors. What must remain is what the check looks for, not where the check is built.

The same rule, placed in two places, produces different results

High-dimensional data can serve as a program, and a program itself is data. Dictionaries, knowledge bases, specs, rules—they all look like data; when structured well enough, they can drive a process. Write fewer fixed steps, and write the rules that generate steps.

A scenario needs only one kind of rule: without it, there is no next step. A cross-domain request needs five dimensions, but the other party only gave two. Write "if the dimensions are incomplete, stop" into the prompt, and the model fills out the form, treats it as handled, and continues. Write the same rule as a record that must be read before runtime submission: five fields, three missing, this step doesn't open. The former hopes the model obeys; the latter declares the condition doesn't hold, so the next step doesn't even exist in the flow. For a dictionary or spec to act as a program, something outside the model must read it. The model can be a machine that generates content, but the gate doesn't read wishes in a prompt—the gate reads records.

Ontology describes the world; the gate checks this one time

An ontology describes what this domain contains; a gate checks whether this run is permitted. A spec can say "confirm shipment," but that doesn't mean this shipment can proceed. The gate must be independent of the ontology.

The dialogue was ultimately distilled into four words: entity, relation, action, plus context. Actions in the ontology are business verbs (check inventory, confirm shipment), describing what can happen in this world; relations describe what connects to what; context is this particular instance. Writing it down makes it a spec, giving a person or model a chance to get it right. Actions on the gate are "is this run permitted": are the fields complete, can it enter the next stage. This layer is not written into the spec hoping to be obeyed; it's a check at execution time.

Evolution is divided into three levels: what a domain spec looks like is the top level, the specific content under that shape is the middle level, and a specific instance is the bottom level. The higher, the more general; the lower, the more specific. The core takes only the layer that "still constrains the next run after the carrier is replaced"—the shape of the spec belongs to this layer; it decides which slots exist and what counts as correct. The content in the slots only counts if someone maintains it; with no maintainer, the core is reduced to just shape. Outdated content can be moved intact to the next carrier, but the next run is no longer constrained by it. What the check looks for, and "what counts as correct" being enforced—the shape is the boundary of that question and the way that "what counts as correct" is written down. When the two sides match, it's still the same layer; when what the check looks for doesn't match "what counts as correct," that's a fault, not an extra layer.

A general method plus domain entities is what can actually land in a domain. This doesn't mean every industry must invent its own method; empty templates don't automatically become industry conclusions. The author's manager later turned first to manufacturing—a decision: land the meta-method in manufacturing first, rather than rolling it out to all industries at once.

Ontology originates in philosophy; in computing and knowledge engineering, it refers to an explicit, formal specification of the concepts, properties, and relations in a domain. It answers "what exists in this domain and what can happen," and common forms include classes, properties, instances, and relation constraints. A concept often mentioned alongside ontology is the knowledge graph: a knowledge graph usually refers to a large-scale set of facts composed of entity-relation-entity triples, and is a concrete instantiation of an ontology. The four words in this article—entity, relation, action plus context—are precisely the most minimal engineering compression of an ontology. The value of an ontology is that it gives people and models a shared vocabulary for the same domain; its truth and coverage need external verification, which also explains the judgment in this article that "the gate cannot stop the case where the five dimensions were the wrong five to begin with."

Errors will happen; the cage determines whether you dare to use it

Agents cannot avoid mistakes; the key is whether a company dares to use an Agent that makes mistakes. Give it a cage: a gate at the entrance, checks at the exit, rollback on error, a human at important decision points, and a human deciding whether to authorize when permissions are exceeded. Pre-checks are also inside the cage: if three of five fields are missing, this step shouldn't even start; checking whether the input is valid is mandatory, not something to look at after it runs. This check can block missing fields, but it can't block the situation in the next section—slots are filled, but the problem still has no unique answer.

Two unresolved things

First, how does formalization persist? Structures, dictionaries, knowledge bases, specs—who writes them, who changes them, who updates them before they expire? Too coarse is useless; too fine is rigid. Formalization is expensive; tools can lower the cost, but people still find it troublesome and call it formalism. When a person leaves, knowledge never written into the system is cut off. Why should an organization keep writing things into structure? Tools don't reduce willingness—the system is already cheap, but people still don't use it. Without a maintainer, the core is reduced to just shape.

Second, how do you discover that the structure itself is wrong? Return to that request: five dimensions are filled, the gate lets it through, and another person still can't give a unique answer. The gate can block missing fields, but it can't block "these five dimensions were the wrong five to begin with," nor can it block the knowledge base running along the wrong map. Wrong content is stored as if it were true, and by the core's own ruler it still counts. So "is quality still there?" cannot be scored by the core itself. Models can't read overly complex structures, or perform worse when the context is too long—that's today's capability floor; this method can't run in all scenarios yet, but that floor is not the method's permanent boundary.

The term formalism (形式主义) in everyday usage is often pejorative, meaning a focus on form without substance. But in software engineering and knowledge engineering, formalization means writing tacit knowledge into a structure that machines can read and verify, and its cost mainly comes from three places: acquisition (who writes down the expert's feel), maintenance (who updates the rules before they expire), and verification (how do you know the written rules are correct). The phrase in the article "too coarse is useless, too fine is rigid" corresponds precisely to the granularity trade-off of formalization. When organizations outsource formalization to tools, cost can decrease, but willingness doesn't automatically increase—this is a long-standing incentive misalignment in organizational knowledge management, consistent with the article's judgment that "with no maintainer, the core is reduced to just shape."

What you can take with you

Models get replaced, become commodities, get open-sourced; prompt tricks quickly lose their price. Rules that live only on a wiki are a liability; rules welded into a toolchain or a product disappear when the carrier is replaced, and they're not assets either.

What you can take with you is that layer—when the carrier is replaced, it's still there, and it still constrains the next run. Toolchains, runtimes, and which product the gate is built into—all are carriers. Whether quality is still there must be read from external results the core cannot tamper with: is what you hand over usable, can the person taking over truly catch it, can outsiders see when something goes wrong. A wrong core can be moved intact to the next carrier and, by its own ruler, feel it's running well—that's still not an asset.

The same test applies to the OK platform: 68% automation rate, 51% of requirements completed within two hours—these answer "fast." Fast is an external number; it measures throughput, not whether, after a new model, new team, or new vendor, outsiders can still see comparable quality. That number isn't here yet. Until it appears, this material demonstrates throughput, not assets.

The author notes at the end: this article is organized from an internal conversation, and the judgments come from their manager; in section four, the relationship between ontology and gate, and the two-layer division of actions, were additions made during organization; the core being reduced to "the layer that still constrains the next run," content counting only when someone maintains it, and reading quality from external results, are boundaries drawn during organization. This is a direction, plus unfinished engineering problems—not a complete answer.

One-line Summary

AI coding is just the surface; the key is whether the system can keep running after people and models are swapped—that's the organizational asset.

Paragraph Summary

Using Tencent's OK platform's 68% automation rate and 51% completion within two hours as an entry point, the article notes that these numbers only answer "fast," not "after swapping people, models, and vendors, can the system continue running at comparable quality and speed." Around this criterion, the author develops four layers: problems must have boundaries and convergence points; structure written in prompts is soft, so checks must sit in a runtime outside the model, similar to Design by Contract; ontology describes what can happen in the world, while the gate only checks whether this run is permitted, and the two must be independent; the core takes only the layer that still constrains the next run after the carrier is replaced, and without maintenance, slot content is reduced to just shape. Finally, two unresolved problems are noted—how formalization persists, and how to discover that the structure itself is wrong—and it's emphasized that quality must be read from external results; 68% and two hours measure throughput, not assets.