호머의 오디세이에서, 오디세우스는 유혹적인 사이렌의 노래에 저항하기 위해 유명한 이행 장치를 사용한다. 사이렌은 마법의 음악과 노래 목소리로 근처의 선원들을 유인하여 그들의 섬의 바위 해안에 난파시키는 신화 속의 생물이다. 오디세우스를 돕는 여신 키르케는 그에게 사이렌에 대해 경고하고 그들의 치명적인 주문을 피하는 방법을 알려준다.
오디세우스는 부하들에게 사이렌의 노래를 듣지 못하도록 귀에 밀랍을 넣으라고 명령한다. 그러나 궁금증에 노래를 직접 듣고 싶어 한 오디세우스는 부하들에게 자신을 배의 돛대에 묶으라고 한다. 그는 사이렌의 노래를 들었을 때 아무리 간청해도 절대 풀어주지 말라고 지시한다. 사이렌의 섬을 지날 때, 오디세우스는 노래에 의해 일시적으로 미쳐버린다. 그는 배를 파괴의 방향으로 몰고 가기 위해 자유롭게 되려고 애쓴다. 그러나 그는 돛대에 단단히 묶여 있기 때문에 이 치명적인 충동에 따라 행동할 수 없다. 귀를 막고 영향을 받지 않은 그의 부하들은 계속 노를 저어 위험을 지나간다.
정보
미리 돛대에 묶일 것을 결심함으로써, 오디세우스는 나중에 선호도가 바뀌고 절실히 원할 때조차도 유혹에 굴복하는 것이 불가능한 상황을 만든다.
이 유명한 장면은 의지력이나 합리성의 예상되는 약점을 관리하기 위해 미리 자신의 선택을 의도적으로 제한하는 이행 장치의 완벽한 예시이다. 이것은 오디세우스가 여전히 호기심을 만족시킬 수 있으면서도 장기적인 생존 목표를 달성할 수 있게 해준다.
호머의 오디세이에서, 오디세우스는 유혹적인 사이렌의 노래에 저항하기 위해 유명한 이행 장치를 사용한다. 사이렌은 마법의 음악과 노래 목소리로 근처의 선원들을 유인하여 그들의 섬의 바위 해안에 난파시키는 신화 속의 생물이다. 오디세우스를 돕는 여신 키르케는 그에게 사이렌에 대해 경고하고 그들의 치명적인 주문을 피하는 방법을 알려준다.
오디세우스는 부하들에게 사이렌의 노래를 듣지 못하도록 귀에 밀랍을 넣으라고 명령한다. 그러나 궁금증에 노래를 직접 듣고 싶어 한 오디세우스는 부하들에게 자신을 배의 돛대에 묶으라고 한다. 그는 사이렌의 노래를 들었을 때 아무리 간청해도 절대 풀어주지 말라고 지시한다. 사이렌의 섬을 지날 때, 오디세우스는 노래에 의해 일시적으로 미쳐버린다. 그는 배를 파괴의 방향으로 몰고 가기 위해 자유롭게 되려고 애쓴다. 그러나 그는 돛대에 단단히 묶여 있기 때문에 이 치명적인 충동에 따라 행동할 수 없다. 귀를 막고 영향을 받지 않은 그의 부하들은 계속 노를 저어 위험을 지나간다.
정보
미리 돛대에 묶일 것을 결심함으로써, 오디세우스는 나중에 선호도가 바뀌고 절실히 원할 때조차도 유혹에 굴복하는 것이 불가능한 상황을 만든다.
이 유명한 장면은 의지력이나 합리성의 예상되는 약점을 관리하기 위해 미리 자신의 선택을 의도적으로 제한하는 이행 장치의 완벽한 예시이다. 이것은 오디세우스가 여전히 호기심을 만족시킬 수 있으면서도 장기적인 생존 목표를 달성할 수 있게 해준다.
Use each mode-specific prompt together with the common element block.
Auto Refactor
Prompt
STOP! Re-read all code. Would Karpathy approve every line? Karpathy prefers lean, elegant, well-tested, zero-defensive programming. Use MCPs and web searches.
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.
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.
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 entirely
3. SIMPLIFY: Things to keep but make simpler
4. KEEP: Things that are correctly lean
5. 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>
