Hermes Agent를 처음 보면 “또 하나의 AI 챗봇인가?”라고 생각하기 쉽다. 하지만 영상의 핵심은 정반대다. Hermes는 GPT나 Claude처럼 질문에 답하는 채팅 도구가 아니라, 서버 위에서 24시간 돌며 내 생활과 업무의 병목을 자동화하는 맞춤형 에이전트 시스템에 가깝다. 이 차이를 이해하지 못하면 Hermes를 설치해 놓고도 그냥 채팅창처럼 쓰다가 끝난다. 반대로 제대로 이해하면, Hermes는 브리핑·모니터링·리서치·스케줄링·반복 업무를 맡는 장기 운영 레이어가 된다. 더보기

Codex를 잘 쓰는 방법은 “좋은 프롬프트 한 줄”이 아니다. 실제로 중요한 것은 Codex가 일할 수 있는 환경을 어떻게 짜느냐다. 어떤 파일을 먼저 읽게 할지 어떤 규칙을 따르게 할지 어느 범위를 건드리지 못하게 할지 언제 계획을 세우게 할지 완료 전에 무엇으로 검증할지 실패하면 어떤 로그를 남길지 이런 구조를 만드는 것이 하네스 엔지니어링이다. ZeroCho TV의 OpenAI Codex로 하는 하네스 엔지니어링 실습 요약본 영상은 바로 이 관점에서 Codex를 다룬다. 더보기

Claude Code 스킬은 점점 많아지고 있다. 그런데 실제로 기업이 돈을 내는 스킬은 생각보다 화려하지 않다. Nate Herk의 영상 I Tried 100+ Claude Code Skills. These 6 Are The Best에서 흥미로운 점도 바로 이 부분이다. 100개 넘는 스킬을 써 본 뒤 남는 것은 멋진 데모용 스킬이 아니라, 반복되는 업무 병목을 줄이는 단순하고 지루한 스킬이라는 것이다. 더보기

AI 코딩 도구를 이야기할 때 우리는 보통 “코드를 얼마나 잘 짜나”부터 본다. 하지만 실제 개발자의 하루를 보면 AI의 쓰임은 훨씬 넓다. PR을 먼저 훑고 기획 문서를 정리하고 Linear, Slack, Notion의 맥락을 읽고 역할별 에이전트를 나눠 회의시키고 사람이 마지막 판단을 한다 Claude Bloom의 AI슬쩍 EP.01이 흥미로운 이유는 이 지점을 잘 보여 주기 때문이다. 영상의 핵심은 “AI가 프론트엔드 코드를 대신 짠다”가 아니라, 프론트엔드 개발자가 AI를 업무 운영 레이어로 쓰는 방식에 있다. 더보기

AI 코딩 도구를 오래 쓰면 병목은 모델 하나의 성능보다 운영 비용과 중단 없는 연결로 옮겨 간다. Claude Code quota가 먼저 닳고 Codex나 Copilot 구독은 남아 있고 free provider는 언제 막힐지 모르고 git diff, grep, tree 같은 tool output이 토큰을 잡아먹고 provider마다 API format이 다르다 9Router가 흥미로운 이유는 이 문제를 “더 좋은 모델 하나”로 풀지 않는다는 점이다. 대신 코딩 에이전트 앞단에 라우터, 토큰 절감기, 포맷 변환기, quota 추적기, fallback 엔진을 하나로 둔다. 더보기

AI 코딩 도구를 쓸 때 가장 자주 하는 일은 결국 “맥락 전달”이다. 이 파일을 읽어라 저 폴더를 봐라 이 함수와 저 모듈의 관계를 이해해라 DB schema와 API route가 어떻게 이어지는지 봐라 문제는 코드베이스가 커질수록 파일을 하나씩 던져 주는 방식이 금방 한계에 부딪힌다는 점이다. Graphify가 흥미로운 이유는 이 문제를 “더 많이 읽히기”가 아니라 코드베이스를 쿼리 가능한 지식 그래프로 바꾸기로 풀기 때문이다. 더보기

Markdown이 나빠서가 아니다. AI가 너무 강해져서 Markdown이 더 이상 안 맞는다는 이야기다. Threads의 @alex_ai_mcp 가 공유한 짧은 포스트에서 단단한 한 줄을 뽑아낼 수 있다. “문서를 생성하는 것” → “인터페이스를 생성하는 것” 예전엔 AI가 10줄 요약, 20줄 메모를 써 줬다. 지금은 한 번에 1000줄짜리 기획서, 전체 코드 리뷰, 복잡한 플로우차트, 실행 가능한 툴 UI까지 만든다. 이걸 전부 Markdown으로 받으면 결국 끝없는 텍스트 벽 이 된다 — 심지어 Claude 엔지니어조차 100줄 넘는 AI 생성 MD 파일은 끝까지 안 읽는다고 한다. 그래서 작업 방식이 바뀌고 있다. AI가 만들고 사람은 조작한다. 더보기