한국의 입시가 물론 시간을 낭비하는 것은 맞다.
고등학교 때 수능을 위해 배운 기억,
전공 및 대졸을 위해 배운 기억,
그리고 실무에서 직접 다루는 기억까지 총 3번의 재교육이 필요하니까.
하지만 한국의 입시는 시간을 낭비한다는 것에서 오지 않는다.
가장 큰 문제는 어린 영혼들에게 거짓된 명예와 환희를 맛보인다는 점이다.
극단을 향해가는 또래 집단의 압박 아래 우연히 승리한 엘리트의 영혼들은
주변의 선망과 관심을 독차지하며 자신의 성공가도를 오해한다.
누구를 위한 미래인가?
주변을 만족시킴으로써 오는 선망과 관심을 차지하고 싶은 미래인가?
아니면 모두가 멸시하고 천시해도 그 미래를 택할만큼 그 미래를 갈망해서인가?
오히려 미국의 청소년들이 돈을 가지고 불장난을 하며 투자와 금융의 기본기를 익히고
청소년기에 주변인들의 사랑과 건강한 삶의 태도에 대해서 배운다는 것을 느꼈다.
우수한 성적을 받아도 그것은 그저 그런 것일 뿐.
당장 프롬 파티에 같이 갈 사람이 없으면
"엥? 너 뭐했어? 로봇도 아니고. 소셜 라이프가 아예 없다고?" 취급을 받는다.
굳이 성적에 의미를 두자면 Pass에 의미를 둔다.
한국의 입시가 물론 시간을 낭비하는 것은 맞다.
고등학교 때 수능을 위해 배운 기억,
전공 및 대졸을 위해 배운 기억,
그리고 실무에서 직접 다루는 기억까지 총 3번의 재교육이 필요하니까.
하지만 한국의 입시는 시간을 낭비한다는 것에서 오지 않는다.
가장 큰 문제는 어린 영혼들에게 거짓된 명예와 환희를 맛보인다는 점이다.
극단을 향해가는 또래 집단의 압박 아래 우연히 승리한 엘리트의 영혼들은
주변의 선망과 관심을 독차지하며 자신의 성공가도를 오해한다.
누구를 위한 미래인가?
주변을 만족시킴으로써 오는 선망과 관심을 차지하고 싶은 미래인가?
아니면 모두가 멸시하고 천시해도 그 미래를 택할만큼 그 미래를 갈망해서인가?
오히려 미국의 청소년들이 돈을 가지고 불장난을 하며 투자와 금융의 기본기를 익히고
청소년기에 주변인들의 사랑과 건강한 삶의 태도에 대해서 배운다는 것을 느꼈다.
우수한 성적을 받아도 그것은 그저 그런 것일 뿐.
당장 프롬 파티에 같이 갈 사람이 없으면
"엥? 너 뭐했어? 로봇도 아니고. 소셜 라이프가 아예 없다고?" 취급을 받는다.
굳이 성적에 의미를 두자면 Pass에 의미를 둔다.
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>
