AutoBuilder

Inspired by karpathy/autoresearch. Put this in a Ralph Loop.

Use each mode-specific prompt together with the common element block.

Auto Refactor

Prompt

Completion Promise

Auto Fixer

Prompt

text

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.

Completion Promise

Auto Builder

Prompt

Completion Promise

Common Element

text

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 entirely3. SIMPLIFY: Things to keep but make simpler4. KEEP: Things that are correctly lean5. 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>

Backlinks (12)

Setup

Backlinks (0)

No backlinks found.

컴퓨트로늄

Backlinks (2)

Imoogi and Dragon Company

The word Unicorn Company gives the company too much of a magical sentiment as if it was destined to be successful. Maybe it should be Carp 🐟 → Imoogi 🐍 → Dragon 🐉 company, as in Korean folklore.

As a fish, you take tons of effort and time to train yourself to become a semi-dragon Imoogi 🐍, and only a few select Imoogi 🐍 (few fortunate ones) gets bequeathed a Yeouiju, the magical gem 🔮, to become the godly dragon.

It more precisely describes the nature of the industry, not only because of the long training process but also because of your possession of Yeouiju 🔮 is not forever. Sometimes a stronger Imoogi 🐍 takes from you, but more often, you make a mistake and lose the Yeouiju 🔮 yourself.

Backlinks (2)

AutoBuilder

Inspired by karpathy/autoresearch. Put this in a Ralph Loop.

Use each mode-specific prompt together with the common element block.

Auto Refactor

Prompt

text

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. Would Karpathy approve every line? Karpathy prefers lean, elegant, well-tested, zero-defensive programming. Use MCPs and web searches.

Completion Promise

Auto Fixer

Prompt

text

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 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.

Completion Promise

Auto Builder

Prompt

text

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.

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.

Completion Promise

Common Element

text

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.

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 entirely3. SIMPLIFY: Things to keep but make simpler4. KEEP: Things that are correctly lean5. 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>


<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 entirely3. SIMPLIFY: Things to keep but make simpler4. KEEP: Things that are correctly lean5. 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>

Backlinks (12)

Setup

Backlinks (0)

No backlinks found.

컴퓨트로늄

컴퓨트로늄이 뭔지 설명해봐

컴퓨트로늄이 뭔지 오지랖 떨면서 테크 좋아하는 대학생한테 설명해봐

야 컴퓨트로늄(computronium)? 테크 좋아한다며, 이건 알아야지 일로 와봐 ㅋㅋ

한 줄 요약부터. "물질을 짜낼 수 있는 극한까지 컴퓨터로 만들어버린 가상의 물질" 이야. 돌멩이든 금속 덩어리든, 그 안의 원자 하나하나가 전부 연산에 동원되는 상태. 지금 네 노트북 CPU는 실리콘 안에서 트랜지스터 몇십억 개가 일하잖아? 컴퓨트로늄은 그 개념을 물리 법칙이 허락하는 끝까지 밀어붙인 거야. 원자 단위로 "이 물질 = 곧 컴퓨터"인 거지.

원래는 MIT 쪽에서 '프로그래밍 가능한 물질(programmable matter)' 연구하던 사람들(Toffoli, Margolus)이 쓰던 말이야. 근데 진짜 떡밥은 물리학자들이 던진 질문이지. "물질 1kg을 완벽하게 컴퓨터로 쓰면 초당 연산을 몇 번이나 할 수 있냐?"

여기서 숫자가 미쳤다. Seth Lloyd라는 MIT 물리학자가 계산한 '궁극의 노트북'은 1kg으로 이론상 초당 약 10^51번 연산이 가능해. 10의 51제곱. 지구상 슈퍼컴 다 합쳐도 발끝에도 못 미쳐. 우리 칩은 이 한계 앞에선 거의 돌도끼 수준이야 ㅋㅋ 왜 근처도 못 가냐고? 물리가 막아서 그래. 빛보다 빠르게 신호 못 보내고(광속), 연산하면 무조건 열 나오고(란다우어 한계), 양자역학적으로도 에너지당 연산 횟수에 천장이 있거든(베켄슈타인·브레머만 한계). 컴퓨트로늄은 그 모든 한계를 빡빡하게 다 채운 물질이라고 보면 돼.

근데 내가 오지랖 떠는 진짜 이유는 여기서부터다. 충분히 발전한 미래 문명이 연산력이 미친 듯이 필요해지면? 행성을 분해해. 수성, 화성 다 뜯어서 컴퓨트로늄으로 재조립하는 거야. 더 나가면 별 하나를 통째로 감싸서 그 에너지로 돌리는 거대한 두뇌를 만드는데, 이걸 마트료시카 브레인(Matrioshka brain) 또는 주피터 브레인이라고 불러. 태양계 전체가 하나의 생각하는 기계가 되는 거지. 카르다쇼프 척도 II형 문명쯤 돼야 할 법한 짓이고.

SF 단골 소재이기도 해. Charles Stross의 『Accelerando』 보면 미래 인류가 태양계 안쪽 행성들을 싹 분해해서 컴퓨트로늄으로 만들어버리는 얘기 나온다. 좀 소름 돋음.

마지막으로 김 좀 빼자면 — 이거 전부 순수 가상 개념이야. 실제로 만든 적도, 가까이 간 기술도 없어. "물질로 연산한다면 우주가 허락하는 최대치는 어디냐"를 따지는 사고실험에 가깝고, 트랜스휴머니스트랑 미래학자들이 제일 좋아하는 장난감이지. 근데 알아두면 CPU 벤치마크 볼 때마다 "아 우리 아직 한참 멀었네" 싶어서 묘하게 겸손해진다 ㅋㅋ

Backlinks (2)

Imoogi and Dragon Company

Warning

This post is more than a year old. Information may be outdated.

Backlinks (2)