Reasoning compression beats vague abstraction (an interesting idea)

I was debugging water interaction around voxels in a 3D engine and noticed that the model had issues in understanding explanations towards local topology behaviour.

The model kept fixing one artifact and reintroducing another: extended width, a rear interaction effect, and a visible one-cell gap between edges that receive the effect.

Plain English was too ambiguous, so I stopped describing the whole system and reduced the prompt to the exact failing geometry.

The original English task was roughly this (hard to understand):

The water hit effect around an obstacle has the right width now, but the corner between two active hit lines is empty. The edge response should fade into the water by 1-3 cells, should not look like stairs, and should move slightly with the waves instead of staying as a static shape around the object. It should look like water hitting an obstacle, forming a local response, then blending back into the surface.

So I reduced the task to the actual topology rule.

Basically:

Flow direction: southwest.

Imagine a cube with numbered corners:

1 2
3 4

Wanted effect:

1 -> 2
3 -> 4

Forbidden effect:

1 -> 3
3 -> 4

(P.S. the explanation has the corners already numbered, no need to explain such complexities, just 4 symbols and it's done)

Extra constraints:

• no effect behind the object
• no one-cell gap
• corners must be cut
• the effect must not extend past edges 1 -> 2 and 2 -> 3
• corner 2 must stay clean

Task:

• Apply the water interaction only on the front and side edges exposed to the flow based on the flow direction (my example shows a solution for a southwest flow), removing all other unnecessary effects. (P.S. in my case I needed to remove unnecessary effects since it implemented a lot of incorrect stuff trying to understand my approach)

That worked.

In my case the issue was related to topology behaviour around objects in water. So instead of continuing the explanation in English I just interpreted the behaviour through a system, that is capable of representing it, and is far more understandable because explaining this system in English requires to use a lot of considerations and that explanation has too much steps where the model could just hallucinate.

Basically giving to the model this specific interpretation where I drew that cube using numbers, and just prompting 1 or 2 requirements with constraints instead of writing a dissertation around my request.

This is just one way of how you can compact more complex ideas, into shorter, more understandable ones.

Although, using numbers for describing 3D objects, or some kind of 2D interactions is quite helpful at times, similar to my approach with the cube.

A good, less-creativity demanding alternative, is have precise debug in your code, and instead of giving text, just copy the debug lines, and explain exactly what the debug must show, and what currently it shows incorrectly.

A good debug is a step by step breakdown of what happens to your data that is related to your functionality, to achieve a result you want to express via code.