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

260619

  • I prefer CLI
Backlinks (0)

No backlinks found.

Debian Setup
Debian Setup

Debian Setup

sudo apt update && sudo apt install git && /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" && echo >> ~/.bashrc && echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv bash)"' >> ~/.bashrc && eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv bash)" && sudo apt-get install build-essential && brew install gcc btop
Backlinks (1)
  • 260415
Setup
Setup

Setup

Backlinks (0)

No backlinks found.

바잘제트 오버엔지니어링
바잘제트 오버엔지니어링

바잘제트 오버엔지니어링

조잡생각 260108

바잘제트의 오버엔지니어링

1800년대 런던 하수도는 참혹했다. 콜레라 대유행에, 런던 전역에 악취가 끊이지 않아 그레이트 스팅크라는 이름도 있을 정도. 이에 조세프 바잘제트는 1859년 런던의 새로운 하수도를 건설할 총괄 책임자로 선정되었다. 그는 전문가들의 제안을 받아 런던 실정에 맞는 하수도 규격 초안을 설계했다.

하지만 바잘제트는 전문가들이 합의한 최초 하수도 규격에 반대했다. 런던의 산업 폭발을 보았기 때문이다. 급성장하는 런던의 규모에 그는 하수도 전면 재건의 기회는 자주 오지 않을 것이라는 것을 직감했다. 즉, 다음 하수도 재건은 수백 년 뒤에 일어난다는 직감. 그는 이렇게 말했다.

우리는 이 일을 두 번 할 수 없습니다. 그리고 언제나 예기치 못한 일은 생깁니다.

그러고는 파이프 직경을 2배로 늘렸다. Hagen–Poiseuille 방정식에 따르면 유량은 최소 16배 증가했다. 또 그는 당시 포틀랜드 시멘트라는 최첨단 시멘트를 사용했다. 포틀랜드 시멘트는 물속에서도 강도가 유지되는 특정 종류의 시멘트다. 1824년에 특허가 난 포틀랜드 시멘트는 비교적 신기술이었고, 1840~1850년대에 활발히 개선이 진행되고 있었다.

모든 면에서, 설계 규격은 너무 오버엔지니어링이었고, 재료는 미성숙한 기술 도입 강행이었다. 예상 건설비와 공기는 폭증했고, 안전 우려가 쇄도했으며, 많은 정치인과 시민들이 반대했다. 하지만 바잘제트의 강력한 주장에 이는 승인되었다.

흥미롭게도 결국 바잘제트가 옳았다. 바잘제트의 시스템 상당 부분은 150년이 넘은 지금도(소규모 개축은 있었지만) 여전히 사용되고 있다. 20세기에 런던의 인구가 네 배로 늘었음에도, 바잘제트의 과잉설계된 시스템은 부하를 감당하기에 충분하고도 남았다.

분석에 따르면, 바잘제트가 없었더라면(그리고 초기 제안된 파이프 규격과 재료를 사용했더라면) 하수도는 1960년대에 넘쳐흘렀을 것이라고 한다. 그리고, 1960년대에 하수도 규격 재시공을 해야 했다면, 그 사회적 비용은 바잘제트의 오버엔지니어링 비용의 수백-수천 배를 넘을 것이라는 분석도 있다.

오래된 이야기지만, 오늘날의 많은 공학적 의사결정과 너무나 닮아있다. 런던은 성장하는 도시이니 기다리면 바잘제트가 옳게 되는 시점은 반드시 오겠지만, 그에게서 배울 점은 1859년에 그러한 계산된 확신을 했다는 점이다.

AI 없이 순수 조성현이 2026년 1월 7일 작성

Backlinks (1)
  • 260108
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>
sudo apt update && sudo apt install git && /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" && echo >> ~/.bashrc && echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv bash)"' >> ~/.bashrc && eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv bash)" && sudo apt-get install build-essential && brew install gcc btop