Breaking Development into why and action: A Proposal to Rebuild the Runtime Around a Judgment Engine

Today I joined an event and came away with an idea I wanted to write down immediately.

In 2026, a new engine called jev came out. According to what was said at the event, it belongs to the category of "judgment engines." If judgment can be handed to an engine, could we use it to reorganize and replan the IT development process? What follows is the line of thinking I pulled together from a day of discussion.

Development can be abstracted into two things

First, let's abstract development as far as it goes. As I see it, it is nothing more than an action — a motion that runs on a computer. Then why develop? Because we have a why, a reason: why does this action exist?

Put the two together and they form a natural key-value pair: why is the key, action is the value — after the "why," which action to run. Stripped all the way down, development may come down to just these two things.

Let the judgment engine decide "what to do now"

If we have a judgment engine, we can boldly imagine a new form: the computer, or the IT hardware, first judges now — what state we are in. It does not reason in the abstract; it receives and absorbs input, meaning the current state. Then it hands that state to jev's judgment model and looks up the key-value pairs we have already registered — the why-action database. It ends up with two outputs:

1. Given the current now, which why-actions should be prioritized;
2. In what order those why-actions should be executed.

Then those why-actions run automatically. At this point, a loop of "state → judgment → decision → execution" has taken shape.

Closing the loop: use reaction to trigger the next Y

Today, while talking with Syama and Eva, Syama gave me a really good idea that filled in exactly the missing link in this loop: after a Y registered in jev decides what action to take, finishing that action triggers some feedback.

He used an example from a game. You send a little soldier into battle, and the enemy cannon wipes out his health; the soldier's state after the action — say, a cry, a rather sad cry — is a reaction. We register that "state of being consumed or interacted with" as an action too, and let it trigger another Y. Wouldn't the loop then start running automatically? That is a good line of thinking I got today.

An action can take three forms; the execution environment is still an open question

The next thing to answer is: in what form does an action actually exist, and where does it run?

For now we can define an action as:

• code directly — a piece of code or a program;
• or a skill;
• or simply a prompt.

If we really want to implement this as a new kind of runtime, the execution layer still needs to be worked out: does the action execute code directly? If the action is a skill, do we give it a harness engineering environment so it performs harness engineering operations, executes the skill, and gets that program running? If the action is a prompt, does it also dynamically generate something, turn into a motion, and ultimately become a programmatic flow?

Where "now" comes from: watching the screen like browser use

On the front end, there is a concrete idea for "judging now" as well. Take the computer: could we build something like browser use that monitors your display and then judges the current state over and over? If we could, wouldn't that construct a new kind of runtime?

Back to people: we need an interview entry point

Once the runtime exists, thinking further brings us to human society.

For a person facing something, they have to think about the why — why am I doing this; they also have to think about what action they can take; and they have to use their head once more to connect the action to the why. Today all of this has to be done by people themselves.

And people differ: some are good at thinking about these things, while for many others the act itself is very hard. So to get the runtime into real use as quickly as possible, we first have to solve a human problem: provide an interface that interviews the person, and through that interview app or system, help generate the key-value pairs that are useful to them — their own why-action database. Then run it on this runtime. Wouldn't that work?

There is a philosophical idea that grows out of this, two sides of human nature:

• human like to: what people are willing to do is accept an interview and say these things about themselves;
• human want: what people want to get is a set of things that can do the work for them.

What the so-called interview system, or qualification-conversion system, does is rebuild the relationship between a person's why and action — this graph. It is an intermediate system.

Narrowing the scope: start with a small example that helps you find a job

Given all these ideas, building a large system in one go would be hard. So I'm thinking: could this week's and next week's topic narrow the scope and start with a small example — helping you find a job?

Using the method above, I break it into three steps.

Step one: a small interview app. Its job is, first, to let the person talk; second, to guide them to talk. Guide them to say what they can do, what they want, why they make this judgment, and so on — draw out as much as possible and get them to say it. Once they have said it, the interview system processes it in the background, and the final output is that key-value table, the why-action table. This is the point the interview system ultimately lands on.

Step two: connect the action to software. An action is itself a motion that can be connected to software, so we can give it a service type: the type is basic software execution, or command line interface execution — in other words, it can turn directly into program execution. Or we can package the action someone wants to take as a skill and run it, for example, with a harness engineering CLI. Or wrap it as a prompt. Register all these actions, and register the corresponding Y as well.

Step three: start that brand-new Runtime. When the runtime starts, it needs an initial action, such as "I want to find a job," and then let the why-action loop run — say, leave it cycling for some amount of time. Or use the design mentioned earlier: after the action, attach one more judgment to the action — checking the state after the action runs, the reaction. Judge that reaction, then throw the reaction back as new input to browser use, and let jev judge the Y and judge the action.

Finally, I want to see whether it can really help this person find a job they want, that suits them, and that they are willing to do. It's worth a try.