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
260418
260418

260418

  • AutoBuilder
  • @github@anaclumos@rsc-swr
Backlinks (0)

No backlinks found.

글감
글감

글감

  • TSMC
  • The Shadows Strikes Back (interface buttons)
  • 무제한 번역
  • 인쇄해서 보면 오류가 보인다
  • Korean Discount
  • R=VD and Generative AIs
  • Prompt Injection
  • AI 단톡방
  • You can do everything on computers but you really should not
  • Everyone has their intern now; Everyone is a CEO
  • 언어학과 우주적 소음
  • Are Social Networks drugs and are tech companies pharmaceutical companies?
  • database wrappers
  • pipe companies dumb pipe cloudflare openai
  • nintendo and emulators free cash grab? platform expansion
  • Notion and Zawinski's law
  • neural computer clock engine digital
  • diminishing openai cost
  • 모두가 일하러 모이는 곳과 자부심
  • 피상적인 직업 - 검색 기술사와 프롬프트 엔지니어
  • 크롬 주소창 제미니
  • Turing Complete Transformers
  • DOS
  • 전화교환원
  • 워크비자는 족쇄인가?
  • 뉴욕 줌 가판대 - 월급이란?
  • meta ai, llama and react
  • database wrappers
  • accountability
  • free car
  • 와비파커
  • 야크쉐이빙
  • time to regulate psychiatric drugs social network
  • 구글 조급해 말라
  • analog is power
  • 비스마르크
  • 차상위 시민권
  • Do not use location or particle-dependent UX writing
  • Lindy Effect
  • Chestertons fence
  • Gustafson's Law
  • hypnagogic inspiration
  • nonintrusive computing
  • Heath's Resume
Backlinks (14)
  • 240722
  • 240709
  • 240420
  • 230415
  • 230410
  • 230328
  • 230319
  • 230318
  • 230301
  • 230221
  • 230207
  • 230204
  • 230203
  • 230202
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>
경고
1년 이상 지난 글입니다. 정보가 오래되었을 수 있습니다.