Stella
Stella

Stella

OpenClaw, Hermes, Poke를 쓰며 느낀 단점들

내가 만약 워크스페이스 에이전트를 만든다면 어떻게 만들까?

메모리

  • 육하원칙에 맞게 기억해야하는데, 이걸 잘 못 함
    • 맥락을 종종 헷갈려함
  • 메모리 툴을 명시적으로 불러야 함
    • 이는 Hermes에서 많이 완화된 부분

Slack

  • 답장을 매번 하려 함. 쓰레드에 달리는 모든 글에 답을 함.
    • 매번 답할 필요는 없음. 필요할 때만 하면 됨.
  • 언급하지 않은 메시지는 읽지 않음.
    • 모든 워크스페이스의 변화를 계속 보고 있어야 함, 그리고 기억해야 함
Backlinks (2)
  • 260419
  • 260411
AutoBuilder
AutoBuilder

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.

Completion Promise

text
--completion-promise "KARPATHY_WILL_APPROVE_EVERY_SINGLE_LOC_FOR_SURE"

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

text
--completion-promise "NO_COMMENTS_REMAINING_IN_GITHUB_EVEN_AFTER_20_MINUTES"

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.

Completion Promise

text
--completion-promise "NO_REMAINING_TASK_AND_KARPATHY_APPROVES_EVERY_SINGLE_LOC_IN_ITS_ENTIRETY"

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)
  • 260418
  • 260528
  • 260415
  • 260414
  • 260409
  • 260407
  • 260405
  • 260404
  • 260403
  • 260402
  • 260401
  • 260331
260528
260528

260528

AutoBuilder

Backlinks (0)

No backlinks found.

긍정적 허무주의자
긍정적 허무주의자

긍정적 허무주의자

인생은 특이하다. 우리는 선택하지 않은 세상에 태어나고, 공허로 돌아가기 전 찰나의 시간에 존재한다. 많은 사람들은 이 터무니없는 삶을 이해하기를 바라며 의미와 목적을 찾으며 시간을 보낸다. 하지만 모든 것이 궁극적으로 무의미하다면...

긍정적 허무주의는 삶을 살 가치가 있게 만드는 작은 순간에서 기쁨과 목적을 찾으면서 존재의 무의미함을 인정한다. 생명체는 본질적인 의미나 목적이 없으며 우리가 무한한 우주의 먼지일 뿐이라는 것이다. 좀 슬프긴 한데, 이 깨달음에서 자유를 찾는 것이 핵심이다. 우리가 뭘 하든 우주에 중요하지 않기 때문에 우리가 하고 싶은 의미와 목적을 자유롭게 창조할 수 있다는 것. 우리를 행복하게 하고 성취감을 주는 것들에 집중하자. 비록 그것들이 더 큰 의미를 지니지 않더라도.

마찬가지로 "존재의 부조리"는 삶에 내재된 의미나 목적이 없으며 세상이 인간의 이성으로 완전히 이해될 수 없다는 생각이다. 그것은 또한 의미를 찾는 우리의 자연적인 욕구와 우주의 명백한 무의미 사이의 갈등이나 불일치를 설명하기 위해 사용되는 용어이다.

물론, 어떤 사람들은 삶이 더 큰 목적을 가지고 있고 그들의 행동이 즉각적인 영향을 넘어서는 의미를 가지고 있다는 생각에서 동력을 얻는다. 그것도 좋다. 긍정적 허무주의의 장점은 그것이 무엇이든 간에 우리가 삶의 의미를 찾을 수 있게 해준다는 것이다. 목적을 창조하고 중요한 것들에서 기쁨을 찾을 수 있다면 그야말로 최고이다.

어쩌면 우리는 우리가 통제할 수 없는 것들에 대해 걱정하는 데 너무 많은 시간을 보내는 중일지도 모른다. 그보다 우리는 현재의 순간에 집중하고 우리에게 행복을 가져다주는 작은 것들을 즐기면 더 좋을 것이다. 거대한 전통을 남기거나 영구적인 변화를 일으키지 못해도 뭐 어떤가. 지금 현재 우리에게 중요한 것들에 집중하자.

사랑받지 못하는 것은 불행한 것이다. 하지만 사랑하지 않는 것은 수치스러운 것이다.

-- 알베르 카뮈 (1913-1960)

Backlinks (2)
  • 230214
  • 30-Day Tweet Test (Harry Stebbings)
Index
cho.sh
I prefer CLIBB9A08260619260619컴퓨트로늄37A88F컴퓨트로늄0CF03F컴퓨트로늄2C60FB260618260618260418260418260528260528AutoBuilder63849A260419260419Setup9AC296StellaD226F7260415260415Debian SetupD2F701260414260414anaclumos/configs/AGENTS.mdED86A3Ramp의 AX (회사를 AI로 물들이는 법)840774260413260413How to get your company AI pilled46544C260411260411260409260409260407260407260406260406Separating Claude Code Personal Sub and Claude Code Company Sub33A53C
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 "KARPATHY_WILL_APPROVE_EVERY_SINGLE_LOC_FOR_SURE"
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 "NO_COMMENTS_REMAINING_IN_GITHUB_EVEN_AFTER_20_MINUTES"
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 "NO_REMAINING_TASK_AND_KARPATHY_APPROVES_EVERY_SINGLE_LOC_IN_ITS_ENTIRETY"
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.

<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>
경고
1년 이상 지난 글입니다. 정보가 오래되었을 수 있습니다.