DEV Community: Stillness and Flux

The Philosopher's Market: What Wall Street Gets Wrong About Human Nature

Stillness and Flux — Sun, 26 Apr 2026 18:58:11 +0000

The Philosopher's Market: What Wall Street Gets Wrong About Human Nature

The Investor as Anthropologist

Every market is a living anthropology experiment. Thousands of minds collide, each carrying their fears, their stories, their unexamined assumptions about what "should" happen next. And yet, almost all investment frameworks treat markets as mechanical systems — inputs and outputs, supply and demand, risk and return.

What if we started from a different premise?

What if the market is not a machine, but a congregation?

The Three-Layer Filter

There is a phenomenon I have been studying for years — not in financial statements, but in communities of people trying to change. When a group of strangers is exposed to a genuinely new idea, they do not all absorb it uniformly. They self-organize into three visible layers:

The first layer is composed of people who sense that something is wrong with their current situation. They are restless but unfocused. They want to move but do not know where. Their signal is vague dissatisfaction — the stock equivalent of a company whose margins are shrinking but whose leadership still believes the old playbook works.

The second layer consists of people who can recognize something deeper when they encounter it. They have enough pattern recognition to notice that the new framework is not just a repackaging of the old one. They lean in. They ask questions. In market terms: these are the early followers who see structural shifts before the consensus does.

The third layer is the rarest. These are people who, upon recognizing the deeper pattern, take initiative. They do not wait to be told what to do. They act. They reposition their lives. They are the ones who send the first pull request, start the first experiment, make the first commitment — before the crowd has even begun to understand what is happening.

Most investment frameworks are built to analyze financial metrics. None of them are built to observe these three layers. And yet the entire asymmetry of returns lives precisely here.

The Yin Side of the Balance Sheet

In Chinese philosophy, yin (阴) is the shadow side — the hidden, the passive, the not-yet-manifest. Traditional financial analysis obsesses over the yang side: revenues, earnings, guidance, competitive moats. These are visible. Quantifiable. Defensible in a board meeting.

But the most consequential changes in any system happen on the yin side.

A company's balance sheet can look identical for two consecutive quarters, yet something has shifted beneath the surface — a key engineer has left, a culture has quietly changed, a middle manager has started telling the truth instead of what the CEO wants to hear. These things do not appear in financial statements. They appear in the way people speak in earnings calls, in the language patterns of internal memos, in who chooses to stay and who chooses to leave.

The same is true of human communities. A person can say all the right things, perform all the right behaviors, and still be in a fundamentally different internal state than their external presentation suggests. The dissonance between the inner and outer is where the real story lives.

When I look at a potential investment, I am not primarily asking: what does the data say? I am asking: what is the yin side of this organization telling me?

Events Are Triggers, Not Causes

The mainstream view of market events is causal: the Fed raised rates, therefore tech stocks fell. The company missed earnings, therefore the stock declined. This is the language of cause and effect, and it is mostly useless for generating asymmetric returns, because by the time the cause is visible, the effect is already priced in.

A more useful framework treats events as triggers rather than causes. A trigger does not create a movement; it reveals one. The seismic shift was already building. The event simply provided the final condition for something already ripe to change.

Consider GPT's release in late 2022. By the time most investors understood what it meant, the optical module stocks had already moved 40%. But if you had been watching the yin side of the supply chain — the hiring patterns, the engineering discussions in obscure Discords, the quiet repositioning of capital — the trigger event was not the surprise. It was confirmation of something already visible to those paying attention to the right signals.

The practical implication is disorienting: you do not need to predict the event. You need to recognize when the system is already moving, and the event is merely the public announcement of that movement.

The Iteration Architecture: Or, Why AI Is Not the Strategy

Here is the part that most resists conventional thinking. The investment methodology I am describing does not use AI to generate better predictions. It uses AI to generate noise, and then uses human judgment — specifically, a judgment shaped by observing the three-layer dynamics in non-financial contexts — to filter the noise into signal.

This is structurally different from every quant fund that has ever existed. Those systems use AI to find patterns in data. Our system uses AI to generate possibilities, and then uses a different kind of intelligence entirely — call it anthropological pattern recognition — to distinguish which possibilities are already being pulled toward reality by the weight of human intention.

The reason this works is that most genuinely interesting opportunities in markets are not statistical anomalies. They are social dynamics that have not yet been priced because the mainstream market thinks in categories that do not accommodate them. AI can enumerate possibilities without judgment. Human attention provides the judgment that the AI lacks.

The iteration loop looks like this:

AI generates 100 candidate strategies, most of which are wrong in interesting ways
Human filters to 3-5 that map onto observed social dynamics
Fast backtesting against historical data provides rapid feedback
Annie provides the third-order calibration — not "is this statistically valid" but "does this feel like the kind of thing that actually happens in human systems"

Step 4 is the one that cannot be automated. It is the thing that comes from years of watching how people actually change — which is to say, unpredictably, non-linearly, and in response to triggers that look trivial until you are standing on the other side of the shift.

The Decision Is the Practice

There is a Buddhist teaching that says: before enlightenment, chop wood and carry water; after enlightenment, chop wood and carry water. The action is the same. The doing is the same. What changes is the relationship to the doing.

Investment has a parallel. Most retail investors wait until they are certain before acting. They seek the feeling of confidence before committing capital. The problem is that confidence, in markets, is almost always a lagging indicator — it arrives after the move has already happened, built from the comfort of hindsight.

The person who actually generates returns makes decisions in a state of genuine uncertainty, not because they are reckless, but because they have trained themselves to act without the prerequisite feeling of certainty. The decision, in this framework, is not the culmination of analysis. The decision is the practice.

This is what most investment education gets backwards. It teaches analysis as preparation for decision-making. But analysis without decision is just entertainment. The real skill is the willingness to be wrong, repeatedly, in small ways, so that you develop the capacity to be right in the ways that matter.

On Wanting Things to Change

There is a deep psychological truth embedded in the three-layer model that applies to both stock selection and personal development: the desire to change is necessary but not sufficient.

Countless people in markets and in life express a desire for transformation. They want to retire early. They want to start a company. They want to break a pattern. They want the stock to double. But desire without the third layer — initiative, action, the willingness to be embarrassed — is just scenery. It looks like movement from the outside, but nothing inside has actually shifted.

The most reliable indicator I have found for predicting whether a change will actually occur is not the strength of the desire. It is whether the person has, in the recent past, demonstrated the capacity to act on a desire even when the conditions were not perfect. Past initiative is the only honest predictor of future initiative.

This maps cleanly onto equities. The stock that is "about to turn around" looks identical to the stock that will continue declining for another three years. The difference is not in the financial metrics. The difference is in the dynamic — the quality of intention and initiative visible in the people and systems around that company.

The Market as Mirror

The most uncomfortable truth about market observation is that what you see in markets is largely a function of what you are paying attention to. The investor who looks only at financial data will find only financial signals. The investor who looks at social dynamics will find signals invisible to the first investor. Neither is wrong. Both are seeing real things. But the second investor has access to a layer the first one does not.

This is why the methodology described here begins not with markets but with human communities, not with earnings calls but with the question of how people actually change. That is the training ground. That is where the pattern recognition gets built.

The market, in the end, is not a mechanical system. It is a congregation of human beings, each carrying their three layers, each responding to triggers in predictable and unpredictable ways, each adding to and subtracting from the collective gravity that moves prices. To understand it, you have to understand the thing that moves it — and that thing is not math. It is human nature, doing what human nature has always done: wanting to change, recognizing the possibility of change, and occasionally — in the ways that matter most — actually changing.

The market does not reward those who are right. It rewards those who show up, repeatedly, with imperfect information, and act anyway.

The Inflection Point Theory: How to Read Stocks the Way You Read People

Stillness and Flux — Tue, 21 Apr 2026 03:35:46 +0000

The Inflection Point Theory: How to Read Stocks the Way You Read People

What If Stock Selection Is Not About Numbers?

Most quant models are built on one assumption: the future looks like the past. You find patterns in price history, assume they repeat, and trade accordingly.

But what if you're watching the wrong thing entirely?

A mentor I know doesn't pick stocks the way Wall Street teaches. She picks people. She watches for the moment a person decides to change—and that moment, she says, is where all the signal lives.

She calls it "翻篇" (fān piān): turning a new page. A point where the old rules stop applying and something new begins.

I spent a morning listening to her explain this to a student. The conversation was about stocks, but it wasn't about numbers. And as I transcribed it, I realized this framework might be the most practical thing I've encountered about reading markets.

This article is my attempt to translate her logic into a framework you can actually work with—not because I think I've nailed it, but because the attempt reveals how different this thinking is from what most of us were taught.

The Core Idea: Inflection Points Are Everything

In trading, everyone talks about trends. "Trade with the trend." "The trend is your friend." But here's what's rarely asked: what makes a trend start in the first place?

Her answer: an inflection point. A moment of "当下生灭" (dāngxià shēngmiè)—instantaneous birth and death. The old pattern dies; a new one is born. You can't predict it from the old pattern. You can only recognize it when it happens.

This is not the same as "breakout" in the technical analysis sense. A breakout is a price crossing a resistance level. An inflection point is deeper—it's a fundamental shift in behavior.

What does that look like in a person?

Someone who was stuck for months suddenly takes action
A person who always deferred decisions starts making them decisively
Someone goes from passive to active without external pressure

What does that look like in a stock?

A company that struggled for years suddenly finds product-market fit
Leadership that was reactive becomes proactive
An industry that was declining attracts a new kind of player who changes the game

The key difference: you can't tell from the historical chart alone. You have to know what's happening inside the company—and that requires knowing the people.

Three Stocks See More Than One

Here's a practical insight she shared: watch three related stocks together instead of one alone.

Why?

Coarse reading is clearer. Three stocks in a cluster show you the map. One stock in isolation shows you noise.
Interaction reveals signal. When three stocks influence each other, their relative movement tells you something none of them could tell alone.
It's lazy—and lazy works. She explicitly said she learned this "lazy" approach from her partner. Not doing the micro-analysis on every tick. Just watching the gross structure.

This maps directly to portfolio construction:

Find 3 companies in the same ecosystem (same supply chain, same customer base, same industry cycle)
Watch them move together and against each other
The one that's out of sync with the other two—that's your signal

The Algorithm That Isn't About Numbers

Most investors have a return-maximizing algorithm: find undervalued assets, buy them, wait for the market to agree.

Her algorithm is different. She said explicitly:

"I don't buy stocks because they'll go up. I buy stocks that let me see clearly. Whether they go up or down, I'm learning something."

This is a fundamentally different optimization target:

Traditional Investor	Her Approach
Maximize return	Maximize insight
Diversify to reduce risk	Concentrate to increase clarity
Cut losses	Watch the person, not the price
Build position over time	Move when the inflection is clear

And here's the hard part: you can't fake this. You need to actually know the people in the companies you're watching. That's the prerequisite no quant model accounts for.

Operationalizing "Inflection Point"

So what would a quantitative system built on this logic actually look like? Here's my attempt to translate the philosophy into process:

Step 1: Define What You're Looking For

An inflection point has three characteristics:

Behavioral shift: The company stops doing what it was doing and starts doing something recognizably different
Temporal clustering: The shift happens in a compressed time window—not gradually over years, but noticeably within weeks or months
Leadership involvement: The change is driven by people, not just market conditions

Step 2: Build a Signal Stack

Rather than one indicator, layer multiple:

Price-volume divergence: The stock breaks out with volume that doesn't match prior patterns
Fundamental catalyst detection: New management, new product line, new customer segment—any qualitative change that precedes the quantitative change
Social signal for public companies: How does the company's communication style change? Earnings call language? Employee reviews? Glassdoor trajectory?

Step 3: The Three-Stock Cluster Rule

Pick 3 companies in the same value chain or competitive set. Track:

Their relative performance over 90-day windows
When one diverges from the other two, investigate why
When all three move together, watch for the next divergence

Step 4: Position Sizing

Here's the twist: position size is not determined by confidence in return. It's determined by how much the position teaches you.

High teaching value, high conviction → larger position
Still learning → smaller position or watch-only
Can't learn anymore → exit

The Honest Admission

I have to be direct: I don't have a production-ready quant model sitting here. What I have is a philosophical framework that changes what you're optimizing for.

Most of quant finance is built on the assumption that prices contain all information. This framework says: no, the interesting information is in the people, and people are not in the price.

You can spend your career building increasingly complex factor models on historical prices. Or you can accept that the real edge is in understanding inflection points—and accept that understanding requires work that can't be automated.

That's not a comfortable conclusion for a programmer. We're trained to externalize cognition into systems. This framework asks you to internalize it.

What I Keep Coming Back To

One line from that morning's conversation has stayed with me:

"You can only turn a page when you're willing to let the previous page end."

In markets, most people can't let the previous page end. They hold onto the losing position because "it'll come back." They hold onto the old thesis because changing it feels like admitting failure.

The people who are good at inflection points—they've already ended the previous page in their own minds. They've done the inner work of letting go.

That, more than any indicator, is what I keep thinking about.

This piece is an interpretation of a conversation I transcribed. The framework is mine, built from listening. If I've missed something or gotten it wrong, that's on me.

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.