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.

젠리의 성공 공식
젠리의 성공 공식

젠리의 성공 공식

어제 젠리가 문을 닫았다. 프랑스의 한 개발자로부터 시작해 3천억에 스냅에 인수된 기술 강소 기업은 어떻게 성장하고 어떻게 사라졌을까. 그리고 우리는 무엇을 배울 수 있을까?

전략

기술력. 위치 추적 앱은 정말 많지만, 배터리를 많이 먹거나 성능이 떨어진다 (실시간이 아니거나, 위치 동그라미가 넓거나). 젠리는 정확한 위치 추적 앱임에도 배터리를 놀랍게 적게 쓴다. 창업 전 3년 이상 자녀 안전 앱을 개발하며 효율 좋은 위치 추적을 연구했다. 젠리 초기에도 박사급 인재들을 채용하며 독자적인 기술력을 보유했다. 서버와 프론트엔드 기술도 시니어 엔지니어 위주로 소수 정예 기업을 구성했다.

타게팅. Gen-Z 그룹을 집중적으로 타게팅했으며 한 학교에서 25%의 사용자를 넘기면 일주일 안에 전교생이 사용한다는 것을 관찰했다. 대만 대학에 유학 간 일본 학생들로부터 대만 전체로 앱이 퍼지는 것 같은 서브 그룹 주도의 성장에 집중했다. 타게팅을 하다 알게 된 사실은, Z세대들은 프라이버시를 전혀 신경쓰지 않았다는 것. 대표는 초기 프라이버시 걱정이 시간 낭비였다고 밝혔다. 시장은 제작자들과 항상 같은 듯 다른 생각을 한다는 것을 알았다고 한다.

브랜딩. 위치 추적이라는 개념은 혐오스럽다. 그래서 초기부터 찐친의 이미지를 잘 녹여냈다. 팝팝 튀는 인터페이스, Z세대 말투, 귀여운 색깔, 그리고 넘쳐나는 이모지. 위치를 직접적으로 요구될 때는 친구와의 직접적인 교류를 강조했다.

인재 영입. 젠리는 기술력 뿐만 아니라 디자인 실력과 운영 실력도 좋았다. 훌륭한 엔지니어와 디자이너는 스타트업에 참여하려 하지 않는다. 처음에는 프리랜서로 계약하고 점차 팀에 끌여들였다.

역사의 뒤안길로

2020년 코로나 집콕 챌린지부터 2022년 대규모 3D 지도 업데이트까지 미래를 준비했지만 최근 Snap의 대규모 정리해고에 Snap Mini App과 함께 젠리 팀 또한 해산되었다. 나는 스냅의 큰 실수라고 생각한다. 미국 대학생 사이에서도 더 이상 스냅을 쓰지 않는다. 젠리는 쓴다. 페이스북이 감원하며 인스타그램을 없애고 페이스북만 남긴 느낌. 젠리의 DNA가 스냅에 잘 결합되어 부활할 수 있길 바란다.

More Info
  • Alexis Bonillo - Zenly
  • Zenly uses Docker 1.12 to scale analytics for over 500M data points per day
  • How Zenly Nailed It - Product Methods!
  • Zenly's Antoine Martin on Next-Level Location Sharing at Disrupt London 2016
  • B2Secrets with Antoine Martin, CEO at Zenly
  • Symbiote (Company) Zenly Analysis

Zenly Playbook

Backlinks (3)
  • Zenly
  • 230203
  • 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>
경고
1년 이상 지난 글입니다. 정보가 오래되었을 수 있습니다.