내가 당신에게 편지를 쓴 것은 이번이 두 번째이며, 내가 미친 것처럼 들리기 때문에 대답하지 않는다고해서 당신을 비난하지는 않지만, 우리 가족은 매일 밤 저녁 식사 후 디저트로 아이스크림을 먹는 전통이 있다는 것은 사실입니다. 하지만 아이스크림의 종류가 다양해서 매일 밤 식사를 마친 후 온 가족이 어떤 아이스크림을 먹을지 투표하고 제가 직접 가게에 가서 아이스크림을 사옵니다.
최근에 새 폰티악을 구입했는데 그 이후로 매장에 갈 때마다 문제가 생겼습니다. 제가 바닐라 아이스크림을 살 때마다 바닐라 아이스크림을 살 때마다 매장에서 다시 출발할 때 차가 시동이 걸리지 않아요. 다른 종류의 아이스크림을 사면 시동이 잘 걸려요.
아무리 우스꽝스럽게 들리더라도 '폰티악에는 무엇이 있어서 바닐라 아이스크림을 사면 시동이 걸리지 않고 다른 아이스크림을 사면 시동이 잘 걸리는 걸까'라는 질문을 진지하게 하고 있다는 것을 알아주셨으면 합니다."
폰티악 사장은 편지에 대해 회의적인 반응을 보였지만, 어쨌든 엔지니어를 보내 편지를 확인하도록 했습니다. 엔지니어는 좋은 동네에 사는 성공한, 교육 수준이 높은 남자가 자신을 반갑게 맞아주자 깜짝 놀랐습니다. 그는 저녁 식사 시간 직후에 그 남자를 만나기로 약속했고, 두 사람은 차에 올라타 아이스크림 가게로 향했습니다. 그날 밤은 바닐라 아이스크림을 먹었는데, 당연히 차에 돌아와서도 시동이 걸리지 않았습니다.
엔지니어는 3일 밤 더 시도했습니다. 첫날 밤, 그 남자는 초콜릿을 샀습니다. 차가 시동이 걸렸습니다. 둘째 날 밤에는 딸기를 먹었습니다. 차가 시동이 걸렸습니다. 셋째 날 밤 그는 바닐라를 주문했습니다. 차가 시동되지 않았습니다.
이제 엔지니어는 논리적 인 사람이기 때문에이 남자의 차가 바닐라 아이스크림에 알레르기가 있다는 것을 믿지 않았습니다. 따라서 그는 문제를 해결하는 데 걸리는 시간 동안 계속 방문하기로 결정했습니다. 이를 위해 그는 모든 종류의 데이터, 시간, 사용한 연료의 종류, 왕복 운전 시간 등을 메모하기 시작했습니다. 얼마 지나지 않아 그는 단서를 찾았습니다. 그 남자는 다른 어떤 맛보다 바닐라를 사는 데 시간이 덜 걸린다는 사실입니다. 왜 그럴까요? 그 답은 매장 레이아웃에 있었습니다.
가장 인기 있는 맛인 바닐라는 매장 앞쪽에 별도의 케이스에 담겨 있어 빠르게 픽업할 수 있었습니다. 다른 모든 맛은 매장 안쪽의 다른 카운터에 보관되어 있어 원하는 맛을 찾아 계산하는 데 시간이 꽤 오래 걸렸습니다. 이제 엔지니어의 의문은 시간이 더 적게 걸리는데 왜 시동이 걸리지 않는지였습니다.
바닐라 아이스크림이 아닌 시간이 문제가 되자 엔지니어는 재빨리 증기 잠금 (Vapor Lock) 장치라는 해답을 떠올렸습니다. 매일 밤 일어나던 일이었지만 다른 맛의 아이스크림을 받는 데 시간이 더 걸렸기 때문에 엔진이 충분히 식어 시동이 걸릴 수 있었습니다. 남성이 바닐라를 받았을 때 엔진은 여전히 너무 뜨거워서 증기 잠금 (Vapor Lock) 이 사라지지 않았습니다. 그래서 시동이 걸리지 않았던 것입니다.
내가 당신에게 편지를 쓴 것은 이번이 두 번째이며, 내가 미친 것처럼 들리기 때문에 대답하지 않는다고해서 당신을 비난하지는 않지만, 우리 가족은 매일 밤 저녁 식사 후 디저트로 아이스크림을 먹는 전통이 있다는 것은 사실입니다. 하지만 아이스크림의 종류가 다양해서 매일 밤 식사를 마친 후 온 가족이 어떤 아이스크림을 먹을지 투표하고 제가 직접 가게에 가서 아이스크림을 사옵니다.
최근에 새 폰티악을 구입했는데 그 이후로 매장에 갈 때마다 문제가 생겼습니다. 제가 바닐라 아이스크림을 살 때마다 바닐라 아이스크림을 살 때마다 매장에서 다시 출발할 때 차가 시동이 걸리지 않아요. 다른 종류의 아이스크림을 사면 시동이 잘 걸려요.
아무리 우스꽝스럽게 들리더라도 '폰티악에는 무엇이 있어서 바닐라 아이스크림을 사면 시동이 걸리지 않고 다른 아이스크림을 사면 시동이 잘 걸리는 걸까'라는 질문을 진지하게 하고 있다는 것을 알아주셨으면 합니다."
폰티악 사장은 편지에 대해 회의적인 반응을 보였지만, 어쨌든 엔지니어를 보내 편지를 확인하도록 했습니다. 엔지니어는 좋은 동네에 사는 성공한, 교육 수준이 높은 남자가 자신을 반갑게 맞아주자 깜짝 놀랐습니다. 그는 저녁 식사 시간 직후에 그 남자를 만나기로 약속했고, 두 사람은 차에 올라타 아이스크림 가게로 향했습니다. 그날 밤은 바닐라 아이스크림을 먹었는데, 당연히 차에 돌아와서도 시동이 걸리지 않았습니다.
엔지니어는 3일 밤 더 시도했습니다. 첫날 밤, 그 남자는 초콜릿을 샀습니다. 차가 시동이 걸렸습니다. 둘째 날 밤에는 딸기를 먹었습니다. 차가 시동이 걸렸습니다. 셋째 날 밤 그는 바닐라를 주문했습니다. 차가 시동되지 않았습니다.
이제 엔지니어는 논리적 인 사람이기 때문에이 남자의 차가 바닐라 아이스크림에 알레르기가 있다는 것을 믿지 않았습니다. 따라서 그는 문제를 해결하는 데 걸리는 시간 동안 계속 방문하기로 결정했습니다. 이를 위해 그는 모든 종류의 데이터, 시간, 사용한 연료의 종류, 왕복 운전 시간 등을 메모하기 시작했습니다. 얼마 지나지 않아 그는 단서를 찾았습니다. 그 남자는 다른 어떤 맛보다 바닐라를 사는 데 시간이 덜 걸린다는 사실입니다. 왜 그럴까요? 그 답은 매장 레이아웃에 있었습니다.
가장 인기 있는 맛인 바닐라는 매장 앞쪽에 별도의 케이스에 담겨 있어 빠르게 픽업할 수 있었습니다. 다른 모든 맛은 매장 안쪽의 다른 카운터에 보관되어 있어 원하는 맛을 찾아 계산하는 데 시간이 꽤 오래 걸렸습니다. 이제 엔지니어의 의문은 시간이 더 적게 걸리는데 왜 시동이 걸리지 않는지였습니다.
바닐라 아이스크림이 아닌 시간이 문제가 되자 엔지니어는 재빨리 증기 잠금 (Vapor Lock) 장치라는 해답을 떠올렸습니다. 매일 밤 일어나던 일이었지만 다른 맛의 아이스크림을 받는 데 시간이 더 걸렸기 때문에 엔진이 충분히 식어 시동이 걸릴 수 있었습니다. 남성이 바닐라를 받았을 때 엔진은 여전히 너무 뜨거워서 증기 잠금 (Vapor Lock) 이 사라지지 않았습니다. 그래서 시동이 걸리지 않았던 것입니다.
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>