Workflow

AI 에이전트를 팀처럼 꾸미는 방식은 꽤 그럴듯해 보입니다. CEO 에이전트가 방향을 잡고, 기획자 에이전트가 플랜을 짜고, 디자이너 에이전트가 UI를 보고, 개발자 에이전트가 코드를 만들고, QA 에이전트가 검수하는 식입니다. 그런데 이 영상은 그 구조가 오히려 AI를 가장 못 쓰는 방법일 수 있다고 말합니다. 핵심 논지는 단순합니다. 인간 조직도는 인간의 한계를 해결하기 위해 생겼지만, AI는 같은 이유로 역할을 나눌 필요가 없다는 것 입니다. YouTube 영상 더보기

하네스 엔지니어링이라고 하면 거창한 프레임워크부터 떠올리기 쉽습니다. 하지만 이 영상의 첫 문장은 오히려 반대입니다. “여러분은 이미 하네스를 쓰고 있다.” Claude Code, Codex, OpenClaw 같은 도구 자체가 이미 context, tools, permissions, feedback loop를 내장한 하네스이고, 우리가 할 일은 그 위에 내 프로젝트에 맞는 한 층을 더 쌓는 것 입니다. YouTube 영상 더보기

Claude Code를 쓰다 보면 어느 순간 플러그인과 스킬을 계속 붙이고 싶어집니다. 그런데 실제 작업에서는 기능이 많을수록 더 좋아지는 것이 아니라, 오히려 컨텍스트가 오염되고 흐름이 복잡해지는 경우가 많습니다. 이 영상의 출발점도 바로 그 지점입니다. 발표자는 여러 플러그인을 거의 다 지우고, GStack 과 Superpowers 두 개만 남겼더니 오히려 Claude Code가 가장 잘 써졌다고 말합니다. YouTube 영상 더보기

오케스트레이션 레이어를 Claude Code 위에 하나 더 얹으면 정말 결과가 더 좋아질까요? 이 영상은 바로 그 질문을 정면으로 다룹니다. GSD, Superpowers, 그리고 아무 플러그인도 없는 기본 Claude Code 에 같은 웹앱 과제를 맡기고, 최종 결과물·토큰 사용량·걸린 시간을 비교합니다. 영상의 결론은 꽤 의외입니다. 가장 화려한 레이어가 항상 이기는 건 아니고, 오히려 기본 Claude Code가 시간 대비 가장 실전적인 선택으로 평가됩니다. YouTube 영상 더보기

이 Threads 스레드는 꽤 강한 문장으로 시작합니다. Karpathy가 AI 코딩의 문제점을 짚었고, 누군가가 그것을 CLAUDE.md 한 파일로 해결했다는 것입니다. 실제로 링크된 forrestchang/andrej-karpathy-skills 저장소 README를 보면 이 프로젝트는 “A single CLAUDE.md file to improve Claude Code behavior” 라고 자신을 설명합니다. 즉 이 저장소의 핵심은 새 모델도, 긴 프롬프트 묶음도 아니라, 한 장의 규칙 문서로 에이전트 행동 편향을 바꾸려는 시도 입니다. Threads 원문 Jina Reader 추출 GitHub README 더보기

좋은 엔지니어는 코드를 빨리 쓰는 사람만은 아닙니다. 만들기 전에 먼저 생각하고, 이상한 동작이 나오면 체계적으로 디버깅하고, 머지 전에 스스로 점검하며, 낯선 분야를 공부할 때도 출력 중심으로 학습합니다. Waza 는 이런 습관을 “좋은 태도” 수준에서 말로만 남기지 않고, Claude나 Codex가 실제로 실행할 수 있는 스킬로 묶으려는 저장소입니다. GitHub 저장소 README 원문 더보기

DESIGN.md 의 핵심은 의외로 단순합니다. 에이전트에게 “예쁘게 만들어줘”라고 말하는 대신, 어떤 색을 쓰고, 어떤 폰트를 쓰고, 버튼과 레이아웃이 어떤 느낌이어야 하는지를 마크다운 문서로 먼저 건네는 것 입니다. 영상은 이것을 agents.md, CLAUDE.md 계열 문서와 같은 흐름으로 설명합니다. 에이전트가 코드를 만들 때 규칙 문서를 보듯, 디자인을 만들 때도 설계도 문서를 읽고 따라가게 하자는 것입니다. 0:51 2:53 더보기