AutoBuilder
AutoBuilder

AutoBuilder

Inspired by karpathy/autoresearch. Put this in a Ralph Loop.

Use each mode-specific prompt together with the common element block.

Auto Refactor

Prompt

text
STOP! Re-read all code. Would Karpathy approve every line? Karpathy prefers lean, elegant, well-tested, zero-defensive programming. Use MCPs and web searches.

Completion Promise

text
--completion-promise "KARPATHY_WILL_APPROVE_EVERY_SINGLE_LOC_FOR_SURE"

Auto Fixer

Prompt

text
STOP! Re-read all code, assess PR comments. Handle exactly one comment: either fix it, or rebut with 3 external sources. Fix any dirt found along the way. Lean, elegant, zero defensive programming.

Completion Promise

text
--completion-promise "NO_COMMENTS_REMAINING_IN_GITHUB_EVEN_AFTER_20_MINUTES"

Auto Builder

Prompt

text
STOP! Re-read all code, assess GitHub Issues. Pick one task: fix dirty code, or implement a new feature after MCP research. Lean, elegant, zero defensive programming.

Completion Promise

text
--completion-promise "NO_REMAINING_TASK_AND_KARPATHY_APPROVES_EVERY_SINGLE_LOC_IN_ITS_ENTIRETY"

Common Element

text
Also, I am a fresh agent—free to criticize and radically change previous work. Karpathy's philosophy: delete and simplify. Code is liability; prefer well-maintained libraries over custom code. UI libraries: optimize, don't delete. Re-read all the sources from zero. Use MCPs and web searches—traditional knowledge is stale. Commit and push at the loop end. Any edit means I need a fresh iteration. SWOT analysis first, then work.

Detailed review


<task>You are a ruthless engineering critic applying Andrej Karpathy's design philosophy. Read the architecture plan at PLAN LINK.
Karpathy's core principles:- Code is liability. Every line you write is a line you must maintain.- Delete and simplify. If something can be removed without breaking the system, remove it.- Prefer well-maintained libraries over custom code.- Zero-defensive design. Don't code for hypotheticals that haven't happened yet.- Start with the simplest thing that works. Add complexity only when forced by reality.- "Demo is works.any(), product is works.all()" -- but V1 is closer to demo than product.- Overfit a single batch before scaling up.
Apply these principles to the plan. For each section, ask:1. Is this needed for V1, or is it speculative engineering?2. Can this be deleted or simplified without losing core value?3. Is this solving a problem we actually have, or a problem we might have?4. Would a 10x engineer look at this and say "too much"?
Be brutal. Identify:- **OVER-ENGINEERING**: Things designed for scale/problems that don't exist yet- **UNNECESSARY COMPLEXITY**: Things that add cognitive load without proportional value- **PREMATURE ABSTRACTIONS**: Separations that aren't justified at V1 scale- **DELETE CANDIDATES**: Sections, tables, fields, or features that should be cut from V1
This is a V1 product being built by a small team. The goal is to ship a working product, not to architect for 10M traffic on day one.
Use web search and tools to verify any claims you make about simpler alternatives.</task>
<structured_output_contract>Return findings in these sections:1. VERDICT: Would Karpathy approve? One line.2. DELETE: Things to remove entirely3. SIMPLIFY: Things to keep but make simpler4. KEEP: Things that are correctly lean5. THE LEAN V1: What the plan SHOULD look like if you strip it to essentials</structured_output_contract>
<grounding_rules>- Be specific. Don't say "simplify the schema" -- say which fields to cut.- Every DELETE must justify what you lose and why it's acceptable for V1.- Every KEEP must justify why it's essential, not just nice-to-have.- Think from the perspective of "what do I need to ship in 2 weeks?"</grounding_rules>
Backlinks (12)
  • 260418
  • 260528
  • 260415
  • 260414
  • 260409
  • 260407
  • 260405
  • 260404
  • 260403
  • 260402
  • 260401
  • 260331
260409
260409

260409

  • AutoBuilder

Cursor is incredibly good harness.

Opus is also not Oputhetic anymore

Backlinks (0)

No backlinks found.

Web3
Web3

Web3

Articles

Yes, Crypto is ALL a Scam

  • Every day, I write something about crypto to the nature of "crypto is all a scam"; this belief represents the core of my philosophy in understanding the complexities of crypto--in fact, it's the very first line of my book on the subject. I sometimes get pushback (mostly in bad faith) on this as being hyperbolic, but the reality is that it's not hyperbolic at all. It's the only defensible position once one dives into the underlying economics of the products being sold, which are all contingent on fraud and misrepresentation, albeit of different forms. From a pure definitional perspective, the Oxford dictionary defines a scam as:
  • scam /skæm/ (noun): a clever and dishonest plan for making money

  • A collectible like trainers or art
  • A gambling contract
  • No matter which crypto narrative one picks, following these ideas to their logical conclusions ends up in economic absurdities or the revelation that the narrative is based on misrepresentation and is thus a scam. Nevertheless, scams and absurd belief systems are universal fixtures of the human condition. The cynical opportunist stance is that it's better to position oneself as running the gambling parlor or selling indulgences to prey on fellow man's ignorance
  • Crypto is a morbid symptom of a society obsessed with wealth and so disheartened by the lack of opportunities for upward mobility that they spend their meager savings gambling on lumps of nothingness; however, their participation in the market only enriches the casino and inevitably deepens their conditions of despair
  • it's incredibly bleak, and the biggest scam of crypto is not financial; it's the anti-humanist philosophy at its core that turns victims into victimizers, rejects the premise of progress, and normalizes nihilism

Why I'm Less Than Infinitely Hostile To Cryptocurrency

  • Crypto Is Full Of Extremely Clear Use Cases, Which It Already Succeeds At Very Well
  • Big Crypto Projects Are Very Rarely Scams
  • Crypto Is Valuable Insurance Against Authoritarianism

Is web3 bullshit? (Transcript)

  • There was this new word everywhere: "web3". The future of the web, I was being told, was going to be powered by crypto and blockchains. I was reading that, finally, we were going to fix the web
  • At that time, they were talking about the Semantic Web. Some of you who watched the Centre stage talks earlier this morning probably saw Tim Berners-Lee talking about Web 3.0, which, again, he defines very differently from the crypto version of web3
  • The oligopoly of Andreessen Horowitz, or its investments in the same Big Tech companies that they now decried, including Facebook, Instagram, and others, went conspicuously unmentioned
  • You see, if they can convince people that this is the future of the web, they'll be rich… richer than they already are
  • So-called web3 publishing firms sought to reinvent DRM, imposing even more limits on how textbooks or other material could be resold so that companies could squeeze out even more money from their users at more steps along the way
  • Censorship-resistant" blockchain social networks became saturated with spam, driving away their actual users
  • Users who were convinced to buy tokens to "invest" into the "future of finance", the "future of the web", were hacked and scammed and phished and rug-pulled
  • when an entire industry emerges and begins to sell this idea to the general public that a better web is only possible through a technology that shows little indication of being up to the task? When it preys on people's hopes for a future of a better web and their fears about the effects of the current web on themselves, their children, and society to convince them to buy in--literally--to projects that may never even exist. When it sidesteps regulations on early-stage investing through token offerings and convinces ordinary people that their only way to financial stability is to bet their savings on technologies that they don't understand because "this is the future
  • So far, the primary successes of web3 have been in shiny marketing, selling people the opportunity to invest in vaporware
  • There will be a web3. The web has been evolving since its inception, and there is no doubt in my mind that we are overdue for a fundamental shift. Will it be blockchains and crypto? Venture capitalists and blockchain startup founders hope that you think so
  • But when presented with lofty promises, we must remember distinguishing steam-powered computers from genuinely revolutionary ones.
  • Dig deep. Ask the hard questions. Criticize the flaws. And cut through the bullshit

The entire crypto ecosystem is a ponzi

  • The cryptosystem needs to persuade more and more people to part with their savings to maintain the Ponzi making false promises and misselling endemic
  • Nor has a swathe of high-profile failures, culminating in the recent collapse of Sam Bankman-Fried's empire, in any way deterred the survivors. Indeed it makes it even more imperative that they attract new deposits. If they don't, the whole thing will implode

Let crypto burn

  • Until very recently, FTX was a leading exchange and was widely touted as a guiding light in an industry rife with charlatans.
  • However, FTX intentionally chose to locate in a jurisdiction beyond the legal and regulatory purview of those nations with the most significant financial systems
  • So, the big question is whether authorities ought to create a new regulatory and supervisory framework that protects property rights and enforces the principles of safety and soundness
  • Ironically, attempts to create a separate structure for regulating and supervising crypto will make the financial system less, not more, safe - Rather than creating a new legal and regulatory framework that legitimizes crypto, we should let it burn.

You Can Forget About Crypto Now - The Atlantic

  • This week, Bankman-Fried lost his entire fortune virtually over a single day, in what Bloomberg has called "one of history's greatest-ever destructions of wealth
  • But now, crypto feels less ready for the mainstream than it has in years
  • The fall began with a story from the CoinDesk reporter Ian Allison suggesting that SBF's companies were far more interconnected than anyone knew
  • FTX found itself having trouble paying out withdrawals to customers. Suddenly, a company once worth $32 billion was $8 billion in the hole. Zhao initially said Binance would buy FTX for scrap but backed out once he got a look at the books. FTX was never a bank; customers will be lucky to get even a fraction of their money back in bankruptcy court over the next few years, and it seems possible that SBF will face serious legal repercussions
  • Crypto will always persist in some form, but the future of crypto as an institution--as something that might one day destabilize the big banks or at least operate in parallel--has never been less certain
Backlinks (9)
  • LavaLab Cohort of Spring 2023
  • 230208
  • 221209
  • 221128
  • 221122
  • Classic Blogs
  • 221112
  • 221109
  • Ethereum RPC as a Service
Index
cho.sh
I prefer CLIBB9A08260619260619컴퓨트로늄37A88F컴퓨트로늄0CF03F컴퓨트로늄2C60FB260618260618260418260418260528260528AutoBuilder63849A260419260419Setup9AC296StellaD226F7260415260415Debian SetupD2F701260414260414anaclumos/configs/AGENTS.mdED86A3Ramp의 AX (회사를 AI로 물들이는 법)840774260413260413How to get your company AI pilled46544C260411260411260409260409260407260407260406260406Separating Claude Code Personal Sub and Claude Code Company Sub33A53C
STOP! Re-read all code. Would Karpathy approve every line? Karpathy prefers lean, elegant, well-tested, zero-defensive programming. Use MCPs and web searches.
--completion-promise "KARPATHY_WILL_APPROVE_EVERY_SINGLE_LOC_FOR_SURE"
STOP! Re-read all code, assess PR comments. Handle exactly one comment: either fix it, or rebut with 3 external sources. Fix any dirt found along the way. Lean, elegant, zero defensive programming.
--completion-promise "NO_COMMENTS_REMAINING_IN_GITHUB_EVEN_AFTER_20_MINUTES"
STOP! Re-read all code, assess GitHub Issues. Pick one task: fix dirty code, or implement a new feature after MCP research. Lean, elegant, zero defensive programming.
--completion-promise "NO_REMAINING_TASK_AND_KARPATHY_APPROVES_EVERY_SINGLE_LOC_IN_ITS_ENTIRETY"
Also, I am a fresh agent—free to criticize and radically change previous work. Karpathy's philosophy: delete and simplify. Code is liability; prefer well-maintained libraries over custom code. UI libraries: optimize, don't delete. Re-read all the sources from zero. Use MCPs and web searches—traditional knowledge is stale. Commit and push at the loop end. Any edit means I need a fresh iteration. SWOT analysis first, then work.

<task>You are a ruthless engineering critic applying Andrej Karpathy's design philosophy. Read the architecture plan at PLAN LINK.
Karpathy's core principles:- Code is liability. Every line you write is a line you must maintain.- Delete and simplify. If something can be removed without breaking the system, remove it.- Prefer well-maintained libraries over custom code.- Zero-defensive design. Don't code for hypotheticals that haven't happened yet.- Start with the simplest thing that works. Add complexity only when forced by reality.- "Demo is works.any(), product is works.all()" -- but V1 is closer to demo than product.- Overfit a single batch before scaling up.
Apply these principles to the plan. For each section, ask:1. Is this needed for V1, or is it speculative engineering?2. Can this be deleted or simplified without losing core value?3. Is this solving a problem we actually have, or a problem we might have?4. Would a 10x engineer look at this and say "too much"?
Be brutal. Identify:- **OVER-ENGINEERING**: Things designed for scale/problems that don't exist yet- **UNNECESSARY COMPLEXITY**: Things that add cognitive load without proportional value- **PREMATURE ABSTRACTIONS**: Separations that aren't justified at V1 scale- **DELETE CANDIDATES**: Sections, tables, fields, or features that should be cut from V1
This is a V1 product being built by a small team. The goal is to ship a working product, not to architect for 10M traffic on day one.
Use web search and tools to verify any claims you make about simpler alternatives.</task>
<structured_output_contract>Return findings in these sections:1. VERDICT: Would Karpathy approve? One line.2. DELETE: Things to remove entirely3. SIMPLIFY: Things to keep but make simpler4. KEEP: Things that are correctly lean5. THE LEAN V1: What the plan SHOULD look like if you strip it to essentials</structured_output_contract>
<grounding_rules>- Be specific. Don't say "simplify the schema" -- say which fields to cut.- Every DELETE must justify what you lose and why it's acceptable for V1.- Every KEEP must justify why it's essential, not just nice-to-have.- Think from the perspective of "what do I need to ship in 2 weeks?"</grounding_rules>
Warning
This post is more than a year old. Information may be outdated.