Chen Ran wrote a piece whose core message is this: most people search for alpha in every corner of life, but what they should do is pursue beta in most domains — zero-effort passive returns — and chase alpha in only a few.
The observation identifies a real problem, but it buries the hardest part inside the phrase “only a few.” Which few? How do you decide? If alpha itself comes in different kinds, which kind is the trap and which kind is real? The question worth answering is not whether to pick alpha or beta, but when, and by what criteria.
What people call “pursuing alpha” in everyday life actually covers two fundamentally different behaviors.
One is tweak. Making marginal optimizations to an existing system: refining prompts, adjusting configurations, gaming credit card rules, stock picking, price comparison. The system already exists. You are making it slightly better for your own output.
The other is build. Creating something new, either from scratch or in an immature domain: writing a tool, designing a workflow, building a creative system, starting a community. You are creating new structure, not fine-tuning existing structure.
These two kinds of alpha have entirely different feedback structures. Tweak’s feedback loop is typically long and noisy. You change a prompt and need at least several rounds of conversation to judge the effect, with model randomness, task variance, and your own shifting usage patterns mixed in. You study an investment strategy; backtests look good, but live results take years to distinguish from luck. When feedback is this blurry, learning barely compounds. You might think a prompt template is great today simply because you happened to ask the right question.
Build’s feedback loop is far shorter. You make a tool. People either use it or they don’t, and you know quickly. You set up a workflow. Run it for a month and you know where it chokes. The signal is clear enough that iteration accumulates.
This distinction is more than academic. Its practical consequence: most people think they are pursuing alpha when they are actually just tweaking, and the expected return of tweak-type alpha is negative in most domains. Your time cost is certain; the benefit is uncertain; system upgrades will overwrite your optimizations anyway. When Chen Ran says “most people who optimize prompts end up worse off than those who just wait for the tool to upgrade,” this is exactly what he means.
Tweak-type alpha faces a structural problem: the object you are optimizing is itself evolving, and it may be evolving faster than you can optimize.
You carefully debug a prompt template in Claude Code. Two months later the model upgrades, and your template suddenly performs worse than the new model’s default behavior. You spend time assembling a vim plugin stack. Six months later the IDE builds those features natively. You spend a week comparing five mechanical keyboards. A year later new switch generations arrive, and your knowledge resets to zero.
The underlying mechanism: alpha has a half-life; beta compounds. Every tweak you make depreciates over time, at a rate determined by how fast the underlying system evolves. The faster the system evolves, the shorter alpha’s half-life. Beta works in the opposite direction: you attach yourself to a positive trend, and every system evolution automatically reflects in your returns.
This does not mean tweak is never worth doing. Some systems evolve slowly: your foundational understanding of a programming language, your grasp of writing structure. Tweak in these areas has a long half-life and may accumulate. But most tools, consumer choices, and financial strategies sit atop systems that evolve fast. The half-life is too short to justify entering.
Chen Ran’s examples all fit this pattern. Investing: the probability that your stock picks beat the S&P 500 drops sharply after a certain time threshold. Credit cards: a 2% no-annual-fee cashback card is beta, with stable rules and a long half-life. Premium card churning is tweak — point values, category restrictions, and redemption rules all shift, and your knowledge gets partially wiped with each rule change. Claude Code: using it directly is beta, benefiting from every upgrade automatically. Researching MCP and agent frameworks is tweak; the frameworks and protocols are in an intense iteration phase, and what you build today will likely need rebuilding in six months.
Once we set aside tweak-type alpha, the remaining cases are where alpha genuinely belongs. Three dimensions determine whether a domain deserves alpha effort.
The first is compounding potential. Can your improvements in this domain accumulate over time, or do you start over each time? Writing ability, programming fundamentals, deep understanding of an industry, and a creative system you maintain yourself — these can compound for a decade or more. In contrast, the optimal configuration of a tool or the best choice for a single purchase is exhausted on use. The test is straightforward: if the improvement in this domain is something you could do for twenty years, it likely compounds. If its shelf life is under two years, it likely does not.
The second is feedback quality. How fast do you know whether you got it right or wrong? Is the signal strong enough to rule out luck? If you build a product, user feedback tells you within days whether the direction is right — that is high-quality feedback. If you manage your health, weight, sleep, and blood markers reflect changes at a weekly level — also usable feedback. If you invest, you cannot distinguish skill from luck within a year — that is low-quality feedback. Feedback quality determines whether you can learn from mistakes within a reasonable timeframe. If you cannot learn, you are on a random walk.
The third is your comparative advantage. This is the hardest to assess honestly. Most smart people overestimate their comparative advantage in every domain. They think: I am smarter than average, so if I just study this, I can beat the default option. But the default option itself is the product of many smart people iterating together. The S&P 500’s pricing embeds the judgment of all market participants. Claude Code’s default behavior embeds the work of the model team and feedback from a massive user base. The idea that you can outperform it from day one is probabilistically unlikely.
An actionable evaluation method: look at historical records, not feelings. Have the optimizations you made in this domain in the past produced verifiable, sustained positive returns? If so, where are the records? If there are no records, or if the records show no clear benefit, your comparative advantage likely does not exist.
A domain where all three dimensions hold — high compounding potential, good feedback quality, genuine comparative advantage — is your active alpha zone. The count should be limited to one or two.
A domain where only one or two hold — say high compounding but poor feedback (health management, investing), or good feedback but low compounding (choosing daily tools) — belongs to the gray zone. The approach is to allocate a limited alpha budget, not to enter at any time. For health management, use proxy metrics to bring feedback forward: track weight trends rather than daily feelings. For investing, use asset allocation instead of stock picking, converting an alpha problem into a beta problem.
A domain where none of the three hold: decisively choose beta. Pick a default option and stop.
This framework is not hard to understand, but it hits a deep execution barrier. Smart people chase alpha in every domain precisely because they can genuinely see room for improvement.
You glance at a tool and immediately know where the configuration could be tighter. You look at a process and immediately know where a step could be saved. This ability is real, not illusory. The problem: seeing room for improvement is not the same as that improvement being worth making.
Seeing an improvement only tells you about your relative perceptual ability in that domain. It says nothing about the value of the improvement itself. You can see an 8% optimization opportunity in a hotel price. That does not mean spending thirty minutes to save that 8% is a good use of time. You can see room to optimize a prompt. That does not mean what you optimize today will still matter three months from now.
A simple but effective test: convert the improvement into time value. If your time is worth X per hour, multiply the amount saved or time saved by the expected number of years the improvement will last. If the result is less than half your hourly rate, it does not belong in your alpha zone. The improvement may be real, but its cost is pulling your attention away from better places.
Another test: ask whether the improvement transfers. Can the prompt template you spent time optimizing be used in other scenarios? Can the credit card strategy you studied help you understand how financial systems work? If the answer is no, this is a one-shot deal. One-shot deals do not qualify as alpha.
One often-overlooked point: choosing a beta is not the same as choosing arbitrarily. It requires judgment — just applied to picking the track, not the running form on the track.
Good beta has several characteristics. First, strong competition drives the underlying system’s evolution. AI coding tools have four or five major players competing right now; attaching yourself to any mainstream tool lets you capture the competitive dividend. Second, upgrades enter your workflow automatically, without requiring you to relearn or migrate. Third, switching costs are low. If the system degrades one day, you can move to another without friction.
Bad beta, conversely, is a system that looks stable but is actually shrinking, or one whose upgrades require constant readaptation.
So the skill of beta selection is fundamentally the skill of trend judgment. You are judging which system will trend upward over time, not which parameter within the system is optimal. This is why Chen Ran saying “just wait for CC or Codex to upgrade” is not a passive act. It is an active beta selection.
Returning to Chen Ran’s piece. When he says “pursue alpha only in a few places,” the difficulty is not in “few” but in having to make a judgment in every domain and then ruling most of them as beta.
This judgment rests on three pillars. Compounding potential and feedback quality determine whether a domain is worth entering. Comparative advantage determines whether you can win once inside. Domains where all three pillars stand may number only one or two. For the rest, pick a good beta, attach yourself, and pour all the freed-up attention into those few alpha zones.
This is not laziness. This is resource allocation.