열역학에서, 엔진은 하나 이상의 형태의 에너지를 기계적인 힘이나 운동으로 변환하는 기계이다. 소프트웨어에서 엔진의 정의는 더욱 모호해진다. 엔진은 복잡한 소프트웨어 시스템의 핵심 구성 요소이다. 예를 들어, 일부 요소가 두 개 이상의 프로그램에 사용되는 경우 해당 구성 요소를 재사용 가능한 라이브러리로 패키징하면 그게 엔진이다. 근데 엔진을 조금 더 잘 정의할 수 있을까?
엔진은 자원과 시간을 소비하여 다른 유용한 자산으로 변환한다. 여기서 유용함이란, 마치 정보의 정의가 단순히 유용한 데이터이듯, 전적으로 인간의 관점에서 주관적이다. 몇 가지 예를 들어보자.
경제는 노동, 자본, 천연자원, 시간 등의 자산을 산출물과 서비스로 생산하는 엔진이다.
군사 조직은 인력, 장비, 자원, 시간 등의 자산을 보안과 안전의 효용으로 생산하는 엔진이다.
정부는 세금, 노동 및 천연 자원과 시간 등의 자산을, 교육, 의료 및 인프라와 같은 재화와 서비스로 생산하는 엔진이다.
기업은 자본, 노동, 천연자원과 시간 등의 자산을, 판매할 수 있는 상품이나 서비스로 생산하는 엔진이다.
대학은 교수진, 직원, 학생, 자원과 시간 등의 자산을, 교육 및 연구 성과물을 생산하고 직업 전망 개선, 높은 수준의 비판적 사고 및 문제 해결 능력의 효용으로 생산하는 엔진이다.
이 정의가 흥미로운 점은, 엔진은 서로의 내부에서 재귀될 수 있는 단순한 함수라는 것이다. 이것은 아이작 아시모프의 심리역사학(통계적 분석을 사용하여 많은 사람들의 행동을 예측하고 역사의 흐름을 예측하는 전략을 개발하는 가상의 과학)과 연결된다. 우주는 시간이 지남에 따라 큰 집단의 집단적 행동에 따라 작동하는 일종의 엔진의 엔진(메타-엔진)이다.
결국 우주는 연쇄-엔진-나무일 뿐이며, 여기서 최초 입력은 빅뱅이고, 최종 출력은 열이다. 궁극적으로, 물리적인 의미에서 엔진은 엔트로피가 흐르는 경로일 뿐이다.
신성한 엔진은 영원한 질서를 규정한다. 모든 것은 신성한 엔진에서 흐르고, 모든 물건과 모든 승객은 제자리에서, 모든 것을 흘려보내는 것이 그 질서이다... 모든 이들은 이 위치를 지키는 신성한 엔진에 경의를 표하라...
열역학에서, 엔진은 하나 이상의 형태의 에너지를 기계적인 힘이나 운동으로 변환하는 기계이다. 소프트웨어에서 엔진의 정의는 더욱 모호해진다. 엔진은 복잡한 소프트웨어 시스템의 핵심 구성 요소이다. 예를 들어, 일부 요소가 두 개 이상의 프로그램에 사용되는 경우 해당 구성 요소를 재사용 가능한 라이브러리로 패키징하면 그게 엔진이다. 근데 엔진을 조금 더 잘 정의할 수 있을까?
엔진은 자원과 시간을 소비하여 다른 유용한 자산으로 변환한다. 여기서 유용함이란, 마치 정보의 정의가 단순히 유용한 데이터이듯, 전적으로 인간의 관점에서 주관적이다. 몇 가지 예를 들어보자.
경제는 노동, 자본, 천연자원, 시간 등의 자산을 산출물과 서비스로 생산하는 엔진이다.
군사 조직은 인력, 장비, 자원, 시간 등의 자산을 보안과 안전의 효용으로 생산하는 엔진이다.
정부는 세금, 노동 및 천연 자원과 시간 등의 자산을, 교육, 의료 및 인프라와 같은 재화와 서비스로 생산하는 엔진이다.
기업은 자본, 노동, 천연자원과 시간 등의 자산을, 판매할 수 있는 상품이나 서비스로 생산하는 엔진이다.
대학은 교수진, 직원, 학생, 자원과 시간 등의 자산을, 교육 및 연구 성과물을 생산하고 직업 전망 개선, 높은 수준의 비판적 사고 및 문제 해결 능력의 효용으로 생산하는 엔진이다.
이 정의가 흥미로운 점은, 엔진은 서로의 내부에서 재귀될 수 있는 단순한 함수라는 것이다. 이것은 아이작 아시모프의 심리역사학(통계적 분석을 사용하여 많은 사람들의 행동을 예측하고 역사의 흐름을 예측하는 전략을 개발하는 가상의 과학)과 연결된다. 우주는 시간이 지남에 따라 큰 집단의 집단적 행동에 따라 작동하는 일종의 엔진의 엔진(메타-엔진)이다.
결국 우주는 연쇄-엔진-나무일 뿐이며, 여기서 최초 입력은 빅뱅이고, 최종 출력은 열이다. 궁극적으로, 물리적인 의미에서 엔진은 엔트로피가 흐르는 경로일 뿐이다.
신성한 엔진은 영원한 질서를 규정한다. 모든 것은 신성한 엔진에서 흐르고, 모든 물건과 모든 승객은 제자리에서, 모든 것을 흘려보내는 것이 그 질서이다... 모든 이들은 이 위치를 지키는 신성한 엔진에 경의를 표하라...
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>