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

260415

  • Debian Setup
  • AutoBuilder
Backlinks (0)

No backlinks found.

초대장의 시대
초대장의 시대

초대장의 시대

며칠 전 사람들이 자신의 독에 무슨 앱을 박아놓는지 공유하는 dockhunt.com이라는 웹사이트를 알게 되었다. 신기한 콘셉트라고 생각하며 내 독을 공유했다. 근데 얼마 지나지 않아 흥미로운 질문을 받았다.

1A746C

Amie 뿐만 아니라 Texts, Tana, Artifact까지 초대장이 있냐고 연락을 받았다. 하지만 원래는 이렇게 복잡하지 않았는데! 내부 알파 단계, 일부 단체에게만 공유하는 클로즈드 베타 테스트, 그리고 간단한 회원가입만 하면 바로 할 수 있는 오픈 베타가 있지 않았나. 여기에 초대장 시스템은 닫히지도 열리지도 않은 베타로 새로운 접근을 한다. 그렇다면 궁금하다:

왜 요즘 성공적인 스타트업들은 다 초대장을 쓸까?

생존자 편향. 성공적인 스타트업이 초대장이 없으면 기억을 못하고, 초대장을 가진 스타트업이 성공하지 못하면 우리의 관심에 전혀 들지 못한다. 예를 들어, ChatGPT가 초대장이 필요했는가? 완전 아니다.

물론 초대장 시스템은 여러 사회적 엔지니어링 기법을 쓴다:

친구의 이미지. 우리가 친구를 앱으로 초대하면 친구는 그 앱을 써볼 확률이 대단히 높아진다. 친구가 추천해줬기 때문이다. 아무렴 실사용 후기는 무엇도 못 따라간다. 여기에 더해 네트워크 효과도 있다. 내가 초대장을 남으면 누가 이 앱을 잘 쓸까 고민하면서 더 초대를 하려는 경향이 있다.

초기 운영 문제 방지. 초기 스타트업들은 대부분 로드 밸런싱 시스템도 차치하고 앱 내에 수많은 오류와 버그를 잡지 못한다. 첫인상은 항상 오래도록 남는다. 나의 경우에는 노션이 그랬다. 나는 노션을 2018년 초에 처음 써보았는데, 엄청나게 느리고 오류가 많았던 기억만 난다. 내가 다시 노션을 써보기까지 2년 가까운 시간이 걸렸다. 초기에 첫인상을 남기지 않으면 Ops 팀에게도 엄청난 노력이 절감될 것이다.

핵심 관중을 모으고 기대 끌어올리기. 사람은 가질 수 없는 것을 좋아한다. 초대장이 있다면 회사가 닿지 못하는 영역까지를 제품의 경험으로 만들어버릴 수 있다. 인터넷 상에 팬들로 구성된 그룹들이 삼삼오오 모이기 시작한다. 초대장은 사람들이 인터넷에서 이 앱을 쓰는 다른 사용자들을 적극적으로 찾아나서도록 만드는 가장 좋은 방법이다. 그렇게 사람들이 모이면 관심은 인터넷 상에서 더 메아리 칠 것이고, 결국 Fear of Missing Out(FOMO, 사회적 고립 공포감)을 조장하여 사람들을 더욱 끌어들인다. FOMO에 대해서는 나중에 더 깊게 다뤄보도록 하자.

값비싼 선물. 위 모든 것을 생각할 때 가끔 앱 초대장은 더할 나위 없는 선물이 된다. 실제로는 희소성과 전혀 상관 없는데 말이다. 가끔은 이 초대장이 가치가 결부된 특별한 형태로 오기도 한다. 예를 들어 나는 NFT가 유행이었을 때 Superlocal이라는 앱을 써보기 위해 Superlocal's Early Access Ticket을 구매했었다. OpenSea

클럽하우스. 가장 큰 자극제는 초대장을 바탕으로 로켓성장한 클럽하우스였을 것이다. 백문이 불여일견이다. 4조 원는 더더욱.

결국 초대장 시스템은 베타 테스팅을 조금 더 규격화된 방식으로 하는 것이다. 원래는 그것이 위치 기반이었거나 (초기 페이스북, 요즘 당근) 그룹 스터디 (대부분의 게임) 이었을 뿐이다.

또 하나 흥미로운 관찰은 이런 성공적인 초대장 기반 소프트웨어 기업은 대부분 소수정예 엘리트 팀이라는 점이다. 빅테크들은 왜 초대장 시스템을 사용하지 않을까? 어쩌면 이것은 자원이 충분하다면 초대장보다는 동시 오픈이 더 효과가 좋다는 반증이 아닐까?

그럼에도 나는 GitHub의 전 CEO Nat의 관점에 동의한다. 특히 ② 써보기 엄청 쉽다라는 항목. 아마 그는 온보딩 과정 전반을 칭하는 말이었겠지만 거기에는 플랫폼에 대한 접근 권한이 포함되고, 많은 앱들이 이 단계에서 초대장을 요구한다. 나는 기술적으로 숙련된 사용자가 앱을 써보기를 원한다면 초대장 없이 쓸 수 있는 길이 있어야 한다고 믿는다. 그게 회사한테도 이득일 것이다.

Not universal, but the pattern I tend to notice in successful new startup products:

  1. never heard of this, but sounds intriguing
    2. really easy to try
    3. "HOLY SHIT!" in the first 2 minutes
    4. sustained daily usage thereafter

— Nat Friedman (@natfriedman) November 24, 2022

Backlinks (2)
  • 230205
  • 30-Day Tweet Test (Harry Stebbings)
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
경고
1년 이상 지난 글입니다. 정보가 오래되었을 수 있습니다.