몬테카를로 알고리즘은 무작위 샘플링을 사용하여 복잡한 문제에 대한 대략적인 해를 구하는 확률적 방법이다. 몬테카를로 카지노에서와 같이 무작위성 개념에서 영감을 얻은 이 방법은, 수많은 무작위 시뮬레이션을 수행하여 원하는 결과를 추정한다. 예를 들어 π의 값을 추정하기 위해 정사각형 안에 원이 있는 다트를 무작위로 던진다고 상상할 수 있다. 총 던진 다트 수와 비교하여 원 안에 들어간 다트의 비율을 통해 π를 추정할 수 있다. 몬테카를로는 금융, 물리학, 게임 이론, 그래픽 등 다양한 분야에서 사용되며, 기존 방법으로는 한계가 있는 복잡한 시스템과 고차원 공간도 다룰 수 있다. 하지만 일반적으로 정확도가 느리게 향상되므로 더 정밀한 결과를 얻으려면 더 많은 샘플이 필요하다.
흥미로운 점은, 몬테카를로 알고리즘은 추산치를 구하는 시간은 매우 빠르지만 아주 낮은 확률로 크게 값이 틀린다는 것이다. 즉 빠른 시간을 약속 받는 대신 정확도에 리스크를 거는 것이다. 계산 이론에서 흥미로운 점이 아닐 수 없다.
몬테카를로 알고리즘은 무작위 샘플링을 사용하여 복잡한 문제에 대한 대략적인 해를 구하는 확률적 방법이다. 몬테카를로 카지노에서와 같이 무작위성 개념에서 영감을 얻은 이 방법은, 수많은 무작위 시뮬레이션을 수행하여 원하는 결과를 추정한다. 예를 들어 π의 값을 추정하기 위해 정사각형 안에 원이 있는 다트를 무작위로 던진다고 상상할 수 있다. 총 던진 다트 수와 비교하여 원 안에 들어간 다트의 비율을 통해 π를 추정할 수 있다. 몬테카를로는 금융, 물리학, 게임 이론, 그래픽 등 다양한 분야에서 사용되며, 기존 방법으로는 한계가 있는 복잡한 시스템과 고차원 공간도 다룰 수 있다. 하지만 일반적으로 정확도가 느리게 향상되므로 더 정밀한 결과를 얻으려면 더 많은 샘플이 필요하다.
흥미로운 점은, 몬테카를로 알고리즘은 추산치를 구하는 시간은 매우 빠르지만 아주 낮은 확률로 크게 값이 틀린다는 것이다. 즉 빠른 시간을 약속 받는 대신 정확도에 리스크를 거는 것이다. 계산 이론에서 흥미로운 점이 아닐 수 없다.
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>