The Definition Is the Kernel. What Still Runs After the People and the Model Change Is the Asset.

2026-10-11

A while ago I read a piece from Tencent's engineering team. The real change, it argued, is not AI coding alone. It is the whole development process. Their OK platform delivers requirements end to end with AI. Automation is 68%. 51% of requirements finish within two hours.

The numbers are bright. They show that requirements can be finished fast. They do not answer a second question. In this way of working, what stays with the organization, and what leaves with the people and the model.

I spent an afternoon on that question with my boss. His judgments sit closer to this layer than that piece does. What follows is only the part that survives one test.

Change the people. Change the model. Change the vendor. Can the system still run at a similar quality and speed?

If it can, it belongs to the organization. If it cannot, it is one person's feel, one generation of model, or a lock-in to one vendor. "Quality" in that sentence cannot be graded by the system itself. The outside measure is in section 7.

1. A problem with no boundary is a wish

My boss opened with two lines. What problem are you solving. Who is it for.

Most teams landing AI stop one step earlier. "I want to study what software an industry needs." "I want to build a general agent platform." Those are wishes. A wish has nowhere to stop, and no way to be checked.

His split has three steps. What the problem itself is. Who is looking, and from which angle. Where the boundary is: the domain.

"Study industry software" became three problems, each able to stop. In the agent era, what software does an industry actually need. That is the demand baseline. What can current open-source projects provide. Are they stable. Can they be integrated. How large is the gap. That is the supply side. How software of any kind becomes components. That is the technical method.

Once they are separated, each one has a place to converge.

A definition decides what to do, and what counts as right. A definition written on a wiki and executed by no one is a liability. A definition welded to one set of tools, gone when the tools are swapped, is not yet an asset. The kernel is the layer that is still there after the carrier changes, and that can still constrain the next run. The toolchain and the runtime are the carrier. How that layer is drawn is in section 4.

2. There has to be structure. Structure inside the prompt cannot stop what already happened.

One line from him stayed with me. There is nothing wrong with form. Without form, the content has nothing to sit on. Without a body, what soul is there to talk about.

He did not mean more stamps on a document. He meant the content needs a structure to hold it.

Most prompts are one linear sentence. "Help me look up what software this industry has." The model can only guess. He asks for these, written apart: goal, context, conditions and constraints, output format, the agreements that matter, where to inject, which passage to cite. Goals can have sub-goals. Context loads as needed. Constraints go in by layer. Checkpoints in the flow are marked on their own, not mixed into the same sentence.

A prompt should be folded, injectable, and full of variables. The way a loop or a queue is organized in code is the way a prompt should fold. Longer is not better. Less redundancy and clearer folding work better.

This only says one thing. One linear sentence carries too little. It has not yet met the harder failure.

You write in the prompt, "if it does not pass, clarify." The model has already produced an answer. It treats the step as done, and goes on. Your sentence never gets a chance to run.

Structure is still necessary. Structure written inside the prompt is soft. For the flow to be able to stop, the check has to sit outside the model. A primitive in the runtime. A forced checkpoint in a script, before execution and after. No pass, no next stage. Whatever is not exposed can be bypassed. This is the same thing as design by contract. Preconditions, postconditions, and invariants are part of the system. They are not a reminder in a document.

If these checks live only inside one product, the set disappears when the vendor changes. What has to stay is what the check looks for. Where the check is built does not have to stay.

3. The same rule, put in two places, has two results

He had another abstraction. High-dimensional data can be used as a program. A program is itself data. Dictionaries, knowledge bases, specs, and rules look like data. When the structure is good enough, they drive the flow. A program can also be injected, folded, and combined. Write fewer fixed steps. Write the rules that generate the steps.

That sentence needs a minimal scene, or it stays a label. The scene takes only one kind of rule. If it is missing, there is no next step.

A cross-domain request needs five dimensions. The other side gave two.

Put "stop if the dimensions are incomplete" into the prompt. The model fills in the form, treats the step as handled, and continues.

Write the same rule as a record the runtime must read before submit. Five fields. Three missing. This step does not open.

The first hopes the model will obey. The second says the condition does not hold, so the next step does not exist in the flow. For a dictionary or a spec to act as a program, something outside the model has to read it. The model can be the machine that generates the content. The gate does not read a wish in the prompt. The gate reads the record.

He also made another comparison. Three of the five dimensions are themselves vague. There is no unique answer. Another person could not produce one either. That is a different failure. It belongs in section 6. The gate does not handle it.

4. The ontology describes the world. The gate checks this time.

The request in the last section was about the gate. It did not yet say how the gate relates to the ontology. One sentence here. The ontology describes what this world contains. The gate checks whether this time is allowed. A specification can say "confirm shipment." That does not mean this shipment may go. The gate has to stand independent of the ontology.

At the end of the conversation he reduced things to four words. Things, relations, actions, plus context. Entity, relation, action, context.

The split below is one I added while organizing this. He had not already separated it.

An action inside the ontology is a business verb. Check inventory. Confirm shipment. It describes what can happen in this world. A relation describes what connects to what. Context is the scene this time. Written down, this is a specification. It makes it possible for a person or a model to get it right.

An action on the gate is whether this time is allowed. Are the fields complete. Does it pass to the next stage. This layer is not written into the specification in the hope that it will be obeyed. It is a check at execution time.

He also split evolution into three levels. What a spec looks like in each domain is the top level. The concrete content under that shape is the middle level. A particular instance is the bottom level. Higher is more general. Lower is more specific.

The kernel takes only the layer that can still constrain the next run after the carrier changes. The shape of the spec belongs to this layer. It decides which slots exist, and what counts as right. Content in the slots counts only while someone keeps it true. If no one maintains it, the kernel is only the shape. Expired content can be carried across intact. The next run is no longer constrained by it.

What the check looks for is "what counts as right," taken and executed. The shape is how the problem's boundary, and that sentence "what counts as right," get written down. When the two sides match, it is still this one layer. When what the check looks for does not match "what counts as right," that is a fault. It is not an extra layer.

Which product this check is built into is the carrier. What leaves when the model changes is the instance inside one prompt, and the gate inside one vendor's product.

A general method, plus the entities of a domain, is what can land in that domain. That does not mean every industry must invent its own method. An empty template does not automatically become an industry conclusion. He later turned to manufacturing first. That is a decision. The meta-method lands in manufacturing first. It does not spread across every industry first.

5. Mistakes will happen. The cage decides whether you dare to use it.

One practical line from him. An agent cannot avoid mistakes. What matters is how a company dares to use an agent that will make them.

Give it a cage. A gate at the entrance. A check at the exit. Rollback when it is wrong. A person at the decisions that matter. When it reaches past its authority, a person decides whether to grant it.

The prior check sits in the cage too. Three of five fields are missing. That step should not start. Checking whether the input is valid is required. It is not something you look at after the run.

This check can stop a missing field. It cannot stop the case in the next section. The slots are full, and the problem still has no unique answer.

6. Two things are still unsolved

The direction is right. The conversation already showed two hard limits.

The first is how formalization continues. Structure, dictionaries, knowledge bases, specs. Who writes them. Who changes them. Who updates them before they expire. Too coarse, and they do nothing. Too fine, and they freeze. In the conversation this showed up as "it cannot be written," "it is too fragmented," "it is not normalized." That is not a team that failed to try. Formalization is expensive. Tools can lower the cost. People still find it troublesome. They call it formalism. When a person leaves, knowledge that was never written into the system breaks. That is a further layer. Why would an organization keep writing things down as structure. Tools do not lower willingness. The system can already be cheap, and people still will not use it. If no one maintains it, the kernel is only the shape.

The second is how you find out the structure itself is wrong. Back to that request. If the five dimensions are simply unfilled, the gate can close. The other half of what he said: three of them are themselves vague, and there is no unique answer. All five slots contain words. The gate lets the request through. Another person still cannot produce a unique answer. The gate can stop a missing field. It cannot stop "these five dimensions were the wrong five." It cannot stop a knowledge base running along a wrong map. Wrong content, kept as if it were true, still counts by the kernel's own ruler. So "the quality is still there" cannot be graded by the kernel.

A model that cannot read a structure that is too complex, or that gets worse when the context is too long, is today's floor on ability. This method cannot run in every setting yet. That floor is not a permanent boundary of the method.

7. What you can take with you

Models will be replaced. They will become ordinary goods. They will be open-sourced. Prompt technique will lose its price quickly. Rules that only sit on a wiki are a liability. Rules welded into one toolchain, or one product, disappear when the carrier changes. Those are not assets either.

What you can take with you is that layer. It is still there after the carrier changes, and it can still constrain the next run. The toolchain, the runtime, and which product the gate is built into, are the carrier.

Whether the quality is still there has to be read from results the kernel cannot alter. Can the thing that was handed over be used. Can the person receiving it actually take it. When it is wrong, can someone outside see it. A wrong kernel can move intact onto the next carrier and, by its own ruler, feel that it still runs well. That is still not an asset.

Apply the same test to the OK platform. 68% automation, and 51% of requirements finished within two hours, answer "fast." Fast is an outside number. It measures throughput. It does not answer whether, after a new model, a new group of people, and a new vendor, someone outside can still see a similar quality. That number is not there yet. Until it is, the piece shows throughput. It does not show an asset.

This is organized from an internal conversation. The judgments are my boss's. In section 4, the relation between the ontology and the gate, and the split of action into two layers, are additions I made while organizing. Collapsing the kernel into "the layer that can still constrain the next run," counting content only while someone keeps it true, and reading quality from outside results, are boundaries I drew while organizing. Other errors in the organizing are mine. This is a direction, plus engineering problems that are not finished. It is not a completed answer.