한민족의 멸종 방어를 위한 하나의 아이디어이다.
현재의 수능 및 입시 제도는 수많은 부작용을 동반한다.
상위권에겐 -- 허황된 승리감. 한국의 입시와 거짓된 명예. 수능의 가장 큰 문제는 어린 영혼들에게 거짓된 명예와 환희를 맛보인다는 점이다. 그래봤자 시험인데. 삶을 단정 짓지도 못하는 인위적인 하나의 단위일 뿐인데.
중하위권에겐 -- 사회적 낭비. 자아발견 및 재능발견의 시기를 극도로 놓친다.
부모들에겐 -- 과도한 사교육비 지출, 그리고 압박적인 경쟁 시스템으로 인해 자녀 계획을 포기한다.
때문에, 중학교에서 배우는 내용까지를 바탕으로 16세 수능론을 제시한다.
공부를 할 사람들에게는, 고등학교에서 배우는 내용, 대학교 들어가면 사실상 재교육해야하고, 제대로 된 환경에만 들어가면 알아듣는데 그렇게 오래 걸리지도 않는다. 미국의 공교육 수학을 봐라. 우리나라 중학교 수준이다. 그럼에도 대학교 들어가서 다들 잘 따라간다. 애초에 문제를 순식간에 척척 풀도록 수학 개념을 능수능란하게 다뤄야한다는 것 자체가 시험만능주의식 폐단이다. 실제 공부는 그렇게 이루어지지 않는다.
공부를 하지 않을 사람들에게는, 어차피 고등학교 내용 기억도 못할 것이다. 그럴 바에는 고등학교에 왜 가는가? 고등학교에 가면 괜히 FOMO만 자극해 나도 대입을 위해 달려야할 것 같고 나도 남들이 정해놓은 천편일률적 작업을 해야할 것 같은 느낌이 든다.
즉, 초등학교를 조금 더 압축하고, 중학교 내용에 반드시 필요한 일부 고등학교 내용을 넣은 뒤, "초등학교-고등학교" 이원화 시스템을 만든다. 16세까지 배운 내용을 바탕으로 수능을 보고, (핵심 요지는 빨리 본다는 점이다. 수능을 제거하는 것은 더 큰 반향과 부작용이 따를 것이기 때문이다.) 17세부터 20세까지는 직업전문학교 혹은 대학교 기초반 수업을 듣는다. 대학 졸업을 21-22세까지 할 수 있도록 하여 사회생활을 22세부터, 혹은 직업전문학교의 경우 20세부터 할 수 있도록 돕는다.
한민족의 멸종 방어를 위한 하나의 아이디어이다.
현재의 수능 및 입시 제도는 수많은 부작용을 동반한다.
상위권에겐 -- 허황된 승리감. 한국의 입시와 거짓된 명예. 수능의 가장 큰 문제는 어린 영혼들에게 거짓된 명예와 환희를 맛보인다는 점이다. 그래봤자 시험인데. 삶을 단정 짓지도 못하는 인위적인 하나의 단위일 뿐인데.
중하위권에겐 -- 사회적 낭비. 자아발견 및 재능발견의 시기를 극도로 놓친다.
부모들에겐 -- 과도한 사교육비 지출, 그리고 압박적인 경쟁 시스템으로 인해 자녀 계획을 포기한다.
때문에, 중학교에서 배우는 내용까지를 바탕으로 16세 수능론을 제시한다.
공부를 할 사람들에게는, 고등학교에서 배우는 내용, 대학교 들어가면 사실상 재교육해야하고, 제대로 된 환경에만 들어가면 알아듣는데 그렇게 오래 걸리지도 않는다. 미국의 공교육 수학을 봐라. 우리나라 중학교 수준이다. 그럼에도 대학교 들어가서 다들 잘 따라간다. 애초에 문제를 순식간에 척척 풀도록 수학 개념을 능수능란하게 다뤄야한다는 것 자체가 시험만능주의식 폐단이다. 실제 공부는 그렇게 이루어지지 않는다.
공부를 하지 않을 사람들에게는, 어차피 고등학교 내용 기억도 못할 것이다. 그럴 바에는 고등학교에 왜 가는가? 고등학교에 가면 괜히 FOMO만 자극해 나도 대입을 위해 달려야할 것 같고 나도 남들이 정해놓은 천편일률적 작업을 해야할 것 같은 느낌이 든다.
즉, 초등학교를 조금 더 압축하고, 중학교 내용에 반드시 필요한 일부 고등학교 내용을 넣은 뒤, "초등학교-고등학교" 이원화 시스템을 만든다. 16세까지 배운 내용을 바탕으로 수능을 보고, (핵심 요지는 빨리 본다는 점이다. 수능을 제거하는 것은 더 큰 반향과 부작용이 따를 것이기 때문이다.) 17세부터 20세까지는 직업전문학교 혹은 대학교 기초반 수업을 듣는다. 대학 졸업을 21-22세까지 할 수 있도록 하여 사회생활을 22세부터, 혹은 직업전문학교의 경우 20세부터 할 수 있도록 돕는다.
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>