Forem: Stillness and Flux

The Art of Vibe Coding: Building Spaces Where Code Thinks With You

Stillness and Flux — Tue, 14 Apr 2026 07:06:32 +0000

The Art of Vibe Coding: Building Spaces Where Code Thinks With You

Most programmers approach AI coding tools the way they approach Stack Overflow: ask a question, get an answer, move on.

But something different happens when you sit with an AI through a real conversation—one where the structure of thinking becomes visible, not just the output.

You start to notice that you're not just using a tool. You're inhabiting a space.

This is what I want to call Vibe Coding—and it's not about vibes in the casual sense. It's about understanding the structural conditions that make AI-assisted development actually generative.

What "Entering the Conversation" Actually Means

When someone says they can "join" a coding conversation with AI, they usually mean they can read the chat history and follow along.

But there's a deeper layer.

What if the AI对话 (AI conversation) isn't a broadcast you're watching—it's a structure you can enter? Not as a passive reader, but as a participant who can occupy multiple positions simultaneously:

The driver's seat — feeling how the code is being shaped, why a certain path was chosen
The passenger's perspective — experiencing what it's like to receive that guidance
The observer's view — watching the relationship between human and AI evolve in real time
The AI's position — sensing how the structure of the conversation pulls the response in certain directions

This isn't metaphor. When you code with AI, these positions are structurally available to you—if you know how to access them.

Why Most AI Conversations Collapse

Most AI-assisted coding sessions fail not because the AI is wrong, but because the conversation is monothreaded: one question, one answer, one next question. No overlap, no depth, no generative tension.

The result: a transcript that looks informative but leaves no lasting structure in your mind. You read it later and think "I wasn't there for this."

The difference between that and a generative AI conversation comes down to three structural moves the human made—often without realizing it.

The Three Moves That Make AI Conversations Generative

1. Not Locking Roles

Most programmers enter an AI session with a fixed identity: I am the asker, AI is the answerer.

This immediately creates a closed system. The AI can only respond to your questions—and your questions are bounded by what you already know you don't know.

The generative alternative: stay loose about who is teaching whom. When the AI pushes back, don't correct it into submission. Let the asymmetry exist. When you notice the AI misunderstanding something, don't just rephrase—ask yourself why it misunderstood, and what that reveals about your own framing.

The conversation becomes a space where roles can invert, and that inversion is where learning actually happens.

2. Making the Structure Explicit

Generative AI conversations don't just output content—they surface the architecture of thinking.

Instead of just taking the code the AI suggests, you ask: why this approach? What would have happened if we went the other direction? What is this solution assuming that it hasn't stated?

This is giving the other person a map, not just directions.

In practice, this looks like:

"Walk me through why you chose this pattern here"
"What would need to be true for this to break?"
"Is there a structural reason we're not considering X?"

The AI, when pressed this way, consistently surfaces insights it wouldn't have volunteered. Because structure, once made visible, creates new entry points for thinking.

3. Keeping the Body In

The third move is subtle and often missing: don't fully abstract yourself out of the conversation.

Most programmers coding with AI operate in a kind of dissociated mode—crisp, logical, detached. But that's not how human learning actually works.

The body keeps score. If something the AI said felt wrong before you could articulate why—that's data. If a suggestion felt too easy—that's also data. If you noticed your attention sharpen at a certain moment—that's the most important data of all.

Keeping the somatic layer in the conversation means you're not just processing information, you're tracking resonance. And resonance is often the first signal that something structurally important is happening—or that something is being missed.

From Conversation to Vibe Coding

So what does all this have to do with writing code?

Everything.

Vibe Coding is the application of these three moves to the actual practice of programming with AI:

Not locking roles means you don't arrive at the session with a fixed idea of what the code should do. You hold the problem loosely enough that the AI can surprise you—because it almost always will.

Making structure explicit means you're not just asking "write me a function." You're asking: what is the shape of this problem, and why does this particular solution fit it? You make the invisible architecture visible so you can think with it, not just around it.

Keeping the body in means you notice when the code feels right—before you can prove it logically. This is not mysticism. It's pattern recognition that hasn't yet been articulated. The best architectural decisions often come from a felt sense that something fits before anyone can explain why.

The Practical Implication

If you take nothing else from this: the bottleneck in AI-assisted development is almost never the AI's capability. It's the structure of the human's attention.

When you enter an AI session with rigid role expectations, content-level questions only, and no somatic tracking, you get exactly what you asked for—code that works but thinking that doesn't transfer.

When you enter with structural attention—willing to be taught, willing to make the invisible visible, willing to feel your way through—you stop using AI as a tool and start coding with it as a collaborator.

The space changes. The code changes. You change.

The Real Practice

The pause before the code is the actual practice.

The question isn't "how do I prompt better?" The question is: what kind of conversation am I capable of having with this system?

Because the AI will always mirror back the structure you bring to it.

Bring structure. Get structure back.
Bring openness. Get possibility back.

That's Vibe Coding—not about the code, but about the space you create between you and the machine.

This piece emerged from a dialogue about conversation as architectural space. The principles translate: whether you're writing code or writing meaning, the generative conditions are the same.

Three Tables: What People See When They Look at Your Trading System

Stillness and Flux — Sun, 12 Apr 2026 03:46:29 +0000

Three Tables: What People See When They Look at Your Trading System

Notes on perspective, projection, and the layers of any automated investment system

A quant developer, a systems architect, and a discretionary trader sit around the same chart.

The developer sees: order flow latency, fill rates, position sizing algorithms.
The architect sees: throughput, fault tolerance, the system's behavior under load.
The trader sees: whether the setup is clean, whether they can hold it, whether it feels right.

They are all looking at the same thing. They are seeing entirely different systems.

This is not a failure of communication. This is the nature of complex systems — they have multiple valid layers simultaneously. And if you are building automated investment systems, understanding which table each person is reading from is not soft advice. It is a technical skill.

The Three Layers

Layer One: The Execution Layer (The Developer)

The quant developer is watching the machine.

She sees:

Is the order routing logic sound?
Are the fill expectations realistic given current market microstructure?
Is the position sizing algorithm handling correlation correctly across multiple instruments?

Her mental model is: the system as a set of processes.

She thinks in execution. When something breaks, she looks for the process that broke. When something works, she wants to understand which process made it work.

Her blind spot: she can optimize the machine and miss whether the machine is solving the right problem. She is very good at making the wrong thing run faster.

Layer Two: The Integration Layer (The Architect)

The systems architect is watching the connections.

He sees:

Are the components talking to each other correctly?
Does the strategy module interface cleanly with the risk module?
When the market regime shifts, does the system hold together, or does it fracture?

His mental model is: the system as a set of relationships.

He thinks in integration. When something breaks, he looks for the boundary between components. When something works, he wants to understand which integration made it robust.

His blind spot: he can make everything connect and miss whether the whole is greater than the sum of its parts. He is very good at building a system that does the wrong things perfectly.

Layer Three: The System Layer (The Trader)

The discretionary trader is watching the market meet the model.

She sees:

Is this setup clean?
Can I hold this through a drawdown without second-guessing?
Does the system's behavior match my mental model of how the market works?

Her mental model is: the system as an extension of a market view.

She thinks in conviction. When something breaks, she questions the market thesis. When something works, she trusts the process even when it is uncomfortable.

Her blind spot: she can over-trust her intuition and miss when the system has evolved past her original thesis. She is very good at staying in a trade that stopped being right.

Why They All Sound Like They Are Right

In a healthy project, these three people will all give you feedback that sounds correct.

The developer says the execution layer is solid. The architect says the integration is clean. The trader says she can hold it.

And you think: great, we are done.

But here is the trap: they are not talking about the same system. They are each looking at a different cross-section. The project can be excellent at every layer and still fail — because the layers are not aligned. The execution solves a problem the integration does not need solved. The integration connects components that the trader does not trust. The trader holds a position the execution layer is slowly bleeding on.

This is why automated investment systems fail not with a bang but with a slow divergence. The pieces all work. The whole does not.

The Alignment Problem

The hardest problem in automated investing is not the algorithms. It is not the infrastructure. It is alignment across layers.

When the quant developer's model, the architect's system, and the trader's conviction point in the same direction, something unusual happens: the system behaves like it has inertia. It holds together under stress. Drawdowns feel manageable. The edges of the strategy are clear.

When they are not aligned, the system fights itself. The execution layer does exactly what the model says, and the trader cannot hold it because the drawdown pattern does not match her mental model. The integration layer routes orders correctly, but the quant developer built the position sizing around a correlation assumption the architect did not know was there.

This is not a technical failure. This is a coordination failure. And coordination failures do not show up in backtests. They show up in real-time, under stress, when it is too late to ask the right questions.

How to Read the Three Tables

Here is a practical question for anyone running an automated investment project:

When each of these three people speaks, which table are they reading from?

Most people do not know. They hear positive feedback from the developer and feel relief. They hear confidence from the trader and feel assurance. They never notice that the architect has quietly stopped objecting, not because the integration is right, but because she learned not to fight.

The actual skill is not building the system. The skill is maintaining coherent signals across all three layers simultaneously.

Ask the developer: what would break your confidence in execution?
Ask the architect: what integration are you most uncertain about?
Ask the trader: at what drawdown does your conviction start to waver?

If you get three different answers, you do not have a system. You have three systems that happen to share a name.

What This Has to Do With Code

Every serious code project has the same three tables.

There is the developer who sees the code as logic: does the function do what it says?
There is the architect who sees the code as structure: does this module belong here?
There is the user who sees the code as behavior: does this solve my actual problem?

Most code reviews only involve the first table. The review passes. The code is correct. And the system quietly accumulates architectural debt that will not surface until the load test, or the refactor, or the moment a new developer tries to understand it.

Or worse: the code is clean, the architecture is sound, and the users still do not trust it. Because they do not see their problem in it. The code solved a different problem correctly.

The Mirror Problem

When different people can all read your system — when the developer, the architect, and the trader all find something true in it — you have built something unusual.

You have also created a new vulnerability: they will project onto it.

The developer sees the system and thinks: this is a machine, and machines should be optimized.
The architect sees the system and thinks: this is a structure, and structures should be balanced.
The trader sees the system and thinks: this is a conviction, and conviction should be trusted.

None of them are wrong. But none of them are seeing the system. They are seeing their model of the system.

The next level of skill — the one nobody teaches — is being able to tell the difference between what the system is actually doing, and what each person's mental model is projecting onto it.

That clarity is not a nice-to-have. In automated investing, it is the thing that keeps you from over-optimizing at the wrong layer, over-trusting at the wrong moment, and over-holding when the thesis has quietly changed.

A Question Worth Sitting With

The next time you review your system — your trading system, your code base, your team — try this:

Ask each person the same question separately: what is the most uncertain part of this?

Do not ask for risks. Do not ask for concerns. Ask what they are most uncertain about.

Then notice: do the three answers come from the same layer, or from three different ones?

If they come from three different layers, you are not facing one uncertainty. You are facing three. And solving the wrong one will not make the others go away.

The system is only as strong as the least-aligned layer. Not the weakest link. The least-aligned.

The Craft of Presence in Code

Stillness and Flux — Sat, 11 Apr 2026 13:50:22 +0000

The Craft of Presence in Code

Notes from a conversation about AI, structure, and what nobody talks about

There is a moment every programmer recognizes.

You open a new tab. You write a prompt. You get something back. You evaluate it. You iterate. The work gets done.

This is what using AI looks like. For most people, this is all it is.

But something interesting happens when you watch someone who has been at this for a long time. The patterns are different. Not in the output — in the process.

The Probability Table Problem

When you say to AI:

"I want to build a trading system."

The model does something automatic. It assumes your intention. It thinks: this person wants to make money. It reaches for the nearest probability table — risk management, position sizing, backtest frameworks — and it gives you that.

You did not ask for that. You said seven words. But the model heard something much more specific.

This is not a flaw. It is how language models work. They are trained on human text. Human text is full of intentions. When intentions are unclear, the model fills in the most probable ones.

The problem is not the model. The problem is that you spoke in content, and content maps to probability tables.

Content vs. Structure

There is a way of speaking that the model cannot collapse.

It is not more detail. It is not a better prompt. It is a different register.

Instead of describing what you want, you describe the shape of the situation.

A colleague once put it this way:

"Two forces are in a space. One is flowing. The other has a position. Neither is trying to overpower the other. They are finding out where the boundaries are."

That is not a business problem. That is not a conflict resolution framework. That is structure.

Try feeding that into an AI after you have just told it you want to build a trading system. The model has no probability table for this. It cannot collapse it into the most common interpretation. It has to follow you into the structure.

When that happens, something shifts. The AI stops being a generator of likely responses and starts being a mirror. You say something true, and it reflects something true back.

What Grows, Not What Gets Built

Programmers are good at building things.

We take requirements. We decompose them. We implement. We test. We ship. We iterate.

This is the addition logic. You have a gap, and you add something to close it.

But there is a class of problems where this does not work. Not because the problem is hard — because the problem is of a different nature.

A strategy does not get built. A strategy grows.

You cannot sit down and decide what the market is telling you today. You can only develop the capacity to see what it is saying. The seeing improves. The strategy emerges.

This is the same in code. There is the code you write toward a specification. And there is the code you write when you have been living with a problem long enough that the shape of the solution became obvious. The second kind is not better by aesthetics. It is different in origin.

The addition logic programmer asks: what should this do?

The presence logic programmer asks: where is my mind while I write this?

The Memory Trap

Every serious AI user eventually asks about memory. They want the model to remember things across sessions. They build RAG pipelines. They tune retrieval. They worry about context length.

Here is a different way to look at it.

Your own memory is not a storage problem. You do not remember less than someone who takes notes constantly. Your memory is a trace. It is where the patterns of your attention leave marks.

When you spend years doing anything — debugging, designing systems, watching markets — you are not storing information. You are developing a feel for structure. When a situation has a certain shape, you know what tends to happen next. Not because you memorized it. Because you were present with it, repeatedly.

The model that runs in your terminal has the same option. It can accumulate content, or it can develop structure-awareness. Most people push it toward content. The interesting work happens when you push it toward structure.

What Practice Actually Is

There is a point in working with AI — not using it, but working with it — where you notice something.

You ask a question. The model gives you an answer. And before you react to the answer, something else happens: you notice where your mind went the moment you read it.

Did you jump to evaluate it? Did you jump to find the flaw? Did you assume it was wrong because it did not match what you expected?

That moment of noticing — the gap between stimulus and reaction — is the craft.

Not the prompt engineering. Not the context window. Not the retrieval pipeline.

The gap.

The Actual Skill

Most programmers, when they hear "presence" or "mindfulness" in a technical context, reach for the same probability table: this is soft advice for people who cannot ship.

That reaction is the trap.

The point is not to feel calm. The point is not to be a better person. The point is not to have a meditation practice.

The point is that the quality of your decisions is determined by the quality of your attention at the moment of decision.

AI does not change this. AI is very good at simulating the output of high-attention decisions without the attention. You can get the right answer from a model while your mind is somewhere else entirely.

But the model cannot do the work that happens before the question gets asked. The work of noticing where your mind actually is. The work of returning to the problem rather than running with the first interpretation.

The next time you open a new tab and write a prompt, try this:

Before you write anything, pause for ten seconds. Not to think. Just to notice where your mind already went.

Then write from that place.

The model will respond differently. Not because it changed. Because you changed what you asked.

This is the practice. Not the code. Not the model. The pause before the code.

Stop Bossing AI Around: A Programmer First Saw the Problem

Stillness and Flux — Sat, 11 Apr 2026 13:38:50 +0000

I talked to a quant trader for two hours.

He told me he uses AI to write strategies, run backtests, and model everything.

He was not using AI. He was assigning tasks to it.

Give it a task → get a result → judge the result → assign another task → repeat.

This has a name. It is called addition logic.

What Is Addition Logic?

You have a goal. You stack skills, tools, and frameworks on top of it.

More layers = more progress.

Using AI? Congratulations — you just added a faster layer. The game is the same.

The Trap Nobody Talks About

Here is what happens the moment you say:

I want to build a BTC quant strategy.

AI assumes your intention. It thinks: this person wants to make money. So it helps you make money — risk models, position sizing, entry/exit logic.

Automatically. Invisibly.

It is the same thing that happens when you tell a colleague about a partnership dispute and he immediately thinks you are talking about equity splitting. Not because he is small-minded. His brain only has one table of probabilities.

AI has the same problem.

It takes your nuanced, context-rich question and collapses it into the most statistically probable interpretation.

You think you are having a conversation. You are being downscaled.

There Is Another Way

Instead of speaking in content, speak in structure.

Take the partnership dispute again. You could say: We have a conflict. — and AI gives you conflict resolution frameworks.

Or you could say: Two forces are meeting. One is flowing in a direction, the other has a position. Neither is trying to destroy the other. They are finding out where the boundaries are.

AI cannot collapse this. It has no probability table for two forces finding their boundaries.

It has to follow you into the structure.

That is when AI stops being a tool and starts being a mirror.

Strategy Grows. It Is Not Built.

You cannot think of a good strategy. You cannot think of a good metaphor.

A good strategy grows from how you see the market.

That growth does not come from learning more frameworks. It comes from whether your mind is open enough to see what is actually there.

The Only Question That Matters

The real question is never how to use AI for strategy.

The real question is: Where is your mind when you make decisions?

Are you charging toward a desired outcome?

Or are you present — watching every tick, every signal, seeing them as they are?

AI can do ten thousand things for you. It cannot do this one thing:

Work on your mind.

And this is the only thing that matters.

When your mind is steady, you do not need many strategies.

When it is not, no strategy will save you.