Gensyn Mainnet
https://chainlist.org/?search=gensyn
Gensyn (AI)
Bridged USDC
슬슬 젠신 TGE 준비해볼까.
https://chainlist.org/?search=gensyn
Gensyn (AI)
0x4e742319f6b0FeC4afA504fC8ED3cEAB0fb751A2
Bridged USDC
0x5b32c997211621d55a89Cc5abAF1cC21F3A6ddF5
슬슬 젠신 TGE 준비해볼까.
델파이(Delphi) 체험 및 리워드 관련 안내
• 10$ 리워드 청구:
• 델파이 앱 사용하기:
• 델파이 공식 문서:
젠신 메인넷 상에서 가스비로 쓰일 소량의 ETH가 필요
Relay를 사용하여 가스비를 브릿지하는 방법
• 10$ 리워드 청구:
https://del.fyi/delphi-testing• 델파이 앱 사용하기:
https://app.delphi.fyi/• 델파이 공식 문서:
https://docs.delphi.fyi/젠신 메인넷 상에서 가스비로 쓰일 소량의 ETH가 필요
Relay를 사용하여 가스비를 브릿지하는 방법
1. Relay 접속: https://www.relay.link/bridge/gensyn 에 접속합니다.
2. 지갑 연결
3. 체인 선택: 현재 ETH를 보유하고 있는 체인(모든 EVM 체인 가능)을 선택
4. 대상 체인 설정: 젠신(Gensyn) 메인넷으로 설정
Relay
ETH on Gensyn | Relay
Buy or swap ETH on Gensyn instantly with Relay. Fast, low-cost swapping and bridging — any token, any chain, built for everyone.
Forwarded from 새우잡이어선 공지방
Forwarded from 새우잡이어선 공지방
Gensyn (AI) 윈터뮤트가 MM이면 10배 가야지? 🙂
https://etherscan.io/tx/0xf4316d1ff0e0f3a9041bbae7234aa2a3896c51ed4499262482975d8884d1a080
Forwarded from GDR Capital (꺼드럭 캐피털)
며칠전 핫한 ai 행사였던 OmOCon 가서 ai 고수들 보고 왔더니 생산성 격차 느끼고 옴
[ai 고수들 발표 17개 보고 느낀 점]
1. 요새 대세는 클코에서 코덱스로 넘어감. 서브로 쓰는 저렴이 모델은 kimi 젤 많이들 쓰심
2. 모델은 codex + 하네스는 omx + 터미널은 cmux 조합이 제일 인기있는듯함. 저도 터미널은 superset + tmux가 워크트리, 브랜치, 세션 관리 편해서 썼었는데, cmux로 넘어갈듯함.. 좀 불편하지만 터미널 내에서 웹브라우저 열고 페이지 내용 다 터미널로 바로 읽어들이면서 ai가 작업하는 기능이 넘 편해보임
3. 내가 ai 잘 쓰는게 아니라 ai 작업장을 잘 짜야하는듯함. ai가 계속 일하게 만드는 구조 짜야됨.
4. 지리는 ai 하네스나 오픈소스 코드들 만드는 사람들 나이대가 정말 어림..
5. 깃허브는 이제 바이럴부터 하고 관심부터 받고 시작하면 되는 인스타 같은 매체임. 예전처럼 코드 완성하고 공개하는게 아니고 일단 공개해서 관심 받고 바이럴부터 하고 피드백 받아서 계속 고쳐나간다.
기존 제품 개발과 GTM은 대충 이랬다.
근데 AI 네이티브 빌더들은 점점 이렇게 가는 느낌이다.
6. "스펙 깎기"가 실력임
클코한테 ~~한거 만들어줘 하면 쓰레기 같은 결과물 나옴
뭘 만들지 정말 잘 설계해야 하고, ouroboros, deep-interview, ralplan 같은 설계 도구들도 잘 사용을 해야할 것 같음. GPT-image-2 도 설계 단계에서 유용할 것 같음.
7. 코인시장도 다음에 불장이 온다면 크립토 윈터동안 ai 실력 갈고 닦아서 리서치 자동화 잘 해두고, 온체인 데이터나 github 업데이트같은거 추적 잘 하고, 여러 에이전트로 리서치 조직처럼 세팅 잘 한 사람이 먹을 것 같음..
8. 크립토 쪽에도 일찍 들어왔다가 ai로 넘어간 사람 많음..
[인상적이었던 발표내용이나 유용해보였던 코드]
1. MEMORY.md 에 진짜 상세 메모리 때려넣지 않고, 별도 파일로 상세 데이터 저장하고 MEMORY.md에는 그 파일 위치와 요약만 넣는다.
2. 거대한 개발 플랜 짤 때 ouroboros 써야겠다
3. agent-messenger 쓰면 ai가 봇계정 아니고 사람계정으로 카톡, 텔레그램, 디스코드, 인스타 등 쓸 수 있게 해줘서 유용해보임
4. K-skill 도 재밌고 일상에서 종종 쓸 거 같음
——
보니까 핫한 ai 개발 세팅들을 빠르게 적용하고 트렌드 따라가는 것도 중요한 것 같은데 @trendingrepo 이 채널 구독하면 매일 깃헙에서 제일 핫한 코드들 받아볼 수 있음
발표 영상
다른 참여자분의 정리노트
디스코드 커뮤니티
[ai 고수들 발표 17개 보고 느낀 점]
1. 요새 대세는 클코에서 코덱스로 넘어감. 서브로 쓰는 저렴이 모델은 kimi 젤 많이들 쓰심
2. 모델은 codex + 하네스는 omx + 터미널은 cmux 조합이 제일 인기있는듯함. 저도 터미널은 superset + tmux가 워크트리, 브랜치, 세션 관리 편해서 썼었는데, cmux로 넘어갈듯함.. 좀 불편하지만 터미널 내에서 웹브라우저 열고 페이지 내용 다 터미널로 바로 읽어들이면서 ai가 작업하는 기능이 넘 편해보임
3. 내가 ai 잘 쓰는게 아니라 ai 작업장을 잘 짜야하는듯함. ai가 계속 일하게 만드는 구조 짜야됨.
4. 지리는 ai 하네스나 오픈소스 코드들 만드는 사람들 나이대가 정말 어림..
5. 깃허브는 이제 바이럴부터 하고 관심부터 받고 시작하면 되는 인스타 같은 매체임. 예전처럼 코드 완성하고 공개하는게 아니고 일단 공개해서 관심 받고 바이럴부터 하고 피드백 받아서 계속 고쳐나간다.
기존 제품 개발과 GTM은 대충 이랬다.
투자 → Build → PMF → Viral → Lock-in
근데 AI 네이티브 빌더들은 점점 이렇게 가는 느낌이다.
Build → Viral → Lock-in → Iterate → PMF
6. "스펙 깎기"가 실력임
클코한테 ~~한거 만들어줘 하면 쓰레기 같은 결과물 나옴
뭘 만들지 정말 잘 설계해야 하고, ouroboros, deep-interview, ralplan 같은 설계 도구들도 잘 사용을 해야할 것 같음. GPT-image-2 도 설계 단계에서 유용할 것 같음.
7. 코인시장도 다음에 불장이 온다면 크립토 윈터동안 ai 실력 갈고 닦아서 리서치 자동화 잘 해두고, 온체인 데이터나 github 업데이트같은거 추적 잘 하고, 여러 에이전트로 리서치 조직처럼 세팅 잘 한 사람이 먹을 것 같음..
8. 크립토 쪽에도 일찍 들어왔다가 ai로 넘어간 사람 많음..
[인상적이었던 발표내용이나 유용해보였던 코드]
1. MEMORY.md 에 진짜 상세 메모리 때려넣지 않고, 별도 파일로 상세 데이터 저장하고 MEMORY.md에는 그 파일 위치와 요약만 넣는다.
2. 거대한 개발 플랜 짤 때 ouroboros 써야겠다
3. agent-messenger 쓰면 ai가 봇계정 아니고 사람계정으로 카톡, 텔레그램, 디스코드, 인스타 등 쓸 수 있게 해줘서 유용해보임
4. K-skill 도 재밌고 일상에서 종종 쓸 거 같음
——
보니까 핫한 ai 개발 세팅들을 빠르게 적용하고 트렌드 따라가는 것도 중요한 것 같은데 @trendingrepo 이 채널 구독하면 매일 깃헙에서 제일 핫한 코드들 받아볼 수 있음
발표 영상
다른 참여자분의 정리노트
디스코드 커뮤니티
❤1
Forwarded from GDR Capital (꺼드럭 캐피털)
요즘 해외 바이브코딩 하는 사람들 사이에선 타입스크립트 1타강사인 Matt Pocock의 방법론 영상과 스킬이 바이럴되고 있습니다.
요즘 유행하는 SDD, Spec Driven Development 운동을 경계하고 fundamentals와 craftmanship이 중요하다고 주장하는 입장입니다.
핵심 주장은 이거입니다:
그래서 최근 SDD 방식으로 문제를 경험한 사람들 때문에 이 영상과 그의 skills repository가 바이럴 되고 있습니다.
아래 영상 요약 한 번 보시고 공감되시면 skills repository 가서 grill-me 한 번 써보시는 것도 괜찮을 것 같네요
@trendingrepo 채널에서도 여러번 소개됐던 스킬이었습니다
[영상 내용 요약]
1. AI 시대에도 소프트웨어 기본기가 중요한 이유
1.1. AI가 코드를 엄청 잘 만들어도, 결국 사람이 제대로 설계하고 관리하는 능력이 더 중요해짐
• 1.1.1. AI는 코드를 빨리 만들지만, 복잡한 코드를 계속 만들면 나중에 고치기 힘든 엉망진창 코드가 될 수 있음
• 1.1.2. 마치 로봇이 벽돌을 엄청 빨리 쌓아도, 설계도가 엉망이면 집이 무너지는 것과 같음
1.2. 소프트웨어 기본기는 예전부터 중요했지만, AI 시대에는 더 중요해짐
• 1.2.1. AI가 좋은 코드를 만들도록 사람이 잘 이끌어줘야 함
2. '스펙 투 코드' 방식의 문제점
2.1. '스펙 투 코드(Specs to Code)'는 설계도(명세)만 주고 AI가 코드를 만들게 하는 방식임
• 2.1.1. 문제가 생기면 코드를 직접 고치지 않고, 설계도만 바꿔서 AI에게 다시 코드를 만들라고 하는 식
• 2.1.2. 마치 요리 레시피만 계속 바꾸고, 실제 요리가 어떻게 만들어지는지는 신경 안 쓰는 것과 비슷함
2.2. 하지만 이 방식은 결국 엉망인 코드를 만들게 됨
• 2.2.1. 계속 시도해도 코드가 점점 더 나빠지고, 결국 쓸모없는 코드가 되어버림
• 2.2.2. 마치 레시피만 계속 고치다가 결국 맛없는 음식만 계속 만드는 것과 같음
2.3. 코드를 무시하고 AI에게만 맡기는 건 좋은 방법이 아님
• 2.3.1. 나쁜 코드는 고치기 어렵고, 버그를 많이 만들어서 결국 돈이 더 많이 들게 됨
• 2.3.2. 반대로 좋은 코드는 고치기 쉽고, AI가 더 잘 활용할 수 있게 함
3. AI와 소통하는 방법: 'Grill Me'
3.1. AI가 내가 원하는 대로 코드를 만들지 못하는 경우가 많dma
• 3.1.1. 내가 머릿속으로 생각한 것과 AI가 만든 결과물이 다를 때가 있음
• 3.1.2. 마치 내가 친구에게 '맛있는 거 만들어줘' 했는데, 친구가 내가 생각한 것과 전혀 다른 음식을 만들어주는 것과 같음
3.2. 이건 AI와 나 사이에 생각의 차이(디자인 컨셉)가 있기 때문
• 3.2.1. 우리가 만들려는 것에 대한 '보이지 않는 생각'이 서로 다를 수 있음
• 3.2.2. 마치 같은 그림을 그리는데, 서로 다른 그림을 상상하는 것과 같음
3.3. 이 문제를 해결하려면 AI와 'Grill me' 스킬을 사용하면 좋음
• 3.3.1. AI에게 "내가 계획한 모든 것에 대해 끊임없이 질문해서 서로 완벽하게 이해할 때까지 물어봐 줘"라고 시키는 방식
• 3.3.2. AI가 40~100개까지 질문을 하면서 내가 뭘 원하는지 정확히 파악하게 됨
• 3.3.3. 이렇게 하면 AI와 내가 같은 그림을 그리게 되고, AI가 더 정확한 코드를 만들 수 있음
4. AI와 같은 언어 사용하기: '공통 언어'
4.1. AI가 너무 장황하게 설명하거나, 내가 이해하기 어려운 말을 할 때가 있음
• 4.1.1. 마치 외국인과 대화하는데, 서로 다른 단어를 써서 오해가 생기는 것과 같음
4.2. 이럴 때는 '공통 언어(Ubiquitous Language)'를 만들어야 함
• 4.2.1. 나와 AI가 함께 사용하는 용어 목록을 만들거나
• 4.2.2. 마치 우리만의 '비밀 사전'을 만들어서, 그 단어들만 쓰는 방식
4.3. 이 공통 언어는 코드, 설계 문서, 그리고 AI와 대화할 때 모두 사용함
• 4.3.1. AI가 내 코드를 스캔해서 용어 목록을 자동으로 만들어주기도 함
• 4.3.2. 이렇게 하면 AI가 더 간결하게 생각하고, 내가 계획한 대로 코드를 만들게 됨
• 4.3.3. 마치 같은 언어를 쓰면 대화가 훨씬 잘 통하는 것과 같음
5. AI가 제대로 작동하는 코드를 만들게 하는 방법: '작게 나누어 테스트하기'
5.1. AI가 코드를 잘 만들었는데, 막상 돌려보면 작동하지 않을 때가 있음
• 5.1.1. 마치 로봇이 멋진 장난감을 만들었는데, 스위치를 눌러도 움직이지 않는 것과 같음
5.2. 이럴 때는 '피드백 루프(Feedback Loop)'를 활용해야 함
• 5.2.1. 자동화된 테스트나 타입스크립트(TypeScript) 같은 도구를 사용해서 AI가 만든 코드를 바로바로 확인하는 방식
• 5.2.2. 마치 요리사가 음식을 만들면서 중간중간 맛을 보며 간을 맞추는 것과 같음
5.3. AI는 한 번에 너무 많은 코드를 만들려고 해서 문제가 생김
• 5.3.1. 이건 마치 운전할 때 헤드라이트가 비추는 범위보다 훨씬 빠르게 달리는 것과 같음
• 5.3.2. 그래서 '테스트 주도 개발(TDD)' 방식을 사용해야 함
• • 5.3.2.1. 먼저 작은 테스트를 만들고, AI가 그 테스트를 통과하는 코드를 만들게 하는 식
• • 5.3.2.2. 그리고 코드를 더 좋게 다듬는 과정을 반복
• • 5.3.2.3. 마치 작은 목표를 하나씩 달성하면서 큰 목표에 도달하는 것과 같음
5.4. 'Deep Modules' 구조로 코드를 만들면 테스트하기 쉬워짐
• 5.4.1. 코드를 작은 상자들(모듈)로 나누는데, 이 상자들은 겉은 단순하지만 안에는 복잡한 기능들이 숨어있는 거임
• 5.4.2. 마치 장난감 상자 겉면에는 '자동차'라고만 쓰여 있지만, 안에는 복잡한 부품들이 들어있는 것과 같음
• 5.4.3. 이렇게 하면 AI가 코드를 이해하기 쉽고, 테스트도 간단하게 할 수 있음
• 5.4.4. Matt Pocock은 이 구조를 만들기 위해 '코드베이스 아키텍처 개선'이라는 기술을 사용함
5.5. 이렇게 하면 머리도 덜 피곤해짐
• 5.5.1. 나는 상자의 겉모습(인터페이스)만 설계하고, 안의 복잡한 내용은 AI에게 맡길 수 있음
• 5.5.2. 마치 내가 집의 외관과 방 배치만 정하고, 내부 인테리어는 전문가에게 맡기는 것과 같음
• 5.5.3. 결국, AI 시대에는 시스템 설계에 매일 투자하는 것이 가장 중요함
• 5.5.4. AI는 코드를 만드는 '전술가'이고, 우리는 전체를 지휘하는 '전략가'가 되어야 함
요즘 유행하는 SDD, Spec Driven Development 운동을 경계하고 fundamentals와 craftmanship이 중요하다고 주장하는 입장입니다.
핵심 주장은 이거입니다:
AI가 코드를 더 많이, 더 빨리 만들수록 나쁜 architecture, 얕은 module, 빈약한 test, 불명확한 domain language는 더 빠르게 부채가 된다.
그래서 최근 SDD 방식으로 문제를 경험한 사람들 때문에 이 영상과 그의 skills repository가 바이럴 되고 있습니다.
아래 영상 요약 한 번 보시고 공감되시면 skills repository 가서 grill-me 한 번 써보시는 것도 괜찮을 것 같네요
@trendingrepo 채널에서도 여러번 소개됐던 스킬이었습니다
【26.04.26 일요일 오늘의 깃헙 트렌딩 repo 2번】
mattpocock / skills (https://github.com/mattpocock/skills)
• 🧩 코드 한줄 설명
에이전트가 PRD 작성, TDD, 리팩터링 같은 일을 더 잘하게 만드는 작업 스킬 모음입니다.
• ✅ 장점
코딩 에이전트 운영 패턴을 템플릿처럼 재사용하기 좋고, 실제로 어떤 업무를 스킬로 분리할지 감을 빠르게 잡게 해줍니다.
• 🗨 코드 코멘트
코드 라이브러리보다는 운영 노하우 모음에 가까워서 그대로 복붙하기보다 팀 방식에 맞게 덜어내는 편이 좋습니다.
• ♻️ 재등장 여부
신규
• 🤖 추천 여부: 추천
• 추천 이유: AI 코딩 에이전트의 실전 운영 감각을 익히는 레퍼런스로 좋습니다.
• 🎯 활용 예시 상황
팀 공통 .claude 스킬셋을 만들거나 개인 에이전트 워크플로를 정리할 때.
• 🌟 총 누적 stars 20,010
• ⚡️ 오늘의 stars 1,139
[영상 내용 요약]
1. AI 시대에도 소프트웨어 기본기가 중요한 이유
1.1. AI가 코드를 엄청 잘 만들어도, 결국 사람이 제대로 설계하고 관리하는 능력이 더 중요해짐
• 1.1.1. AI는 코드를 빨리 만들지만, 복잡한 코드를 계속 만들면 나중에 고치기 힘든 엉망진창 코드가 될 수 있음
• 1.1.2. 마치 로봇이 벽돌을 엄청 빨리 쌓아도, 설계도가 엉망이면 집이 무너지는 것과 같음
1.2. 소프트웨어 기본기는 예전부터 중요했지만, AI 시대에는 더 중요해짐
• 1.2.1. AI가 좋은 코드를 만들도록 사람이 잘 이끌어줘야 함
2. '스펙 투 코드' 방식의 문제점
2.1. '스펙 투 코드(Specs to Code)'는 설계도(명세)만 주고 AI가 코드를 만들게 하는 방식임
• 2.1.1. 문제가 생기면 코드를 직접 고치지 않고, 설계도만 바꿔서 AI에게 다시 코드를 만들라고 하는 식
• 2.1.2. 마치 요리 레시피만 계속 바꾸고, 실제 요리가 어떻게 만들어지는지는 신경 안 쓰는 것과 비슷함
2.2. 하지만 이 방식은 결국 엉망인 코드를 만들게 됨
• 2.2.1. 계속 시도해도 코드가 점점 더 나빠지고, 결국 쓸모없는 코드가 되어버림
• 2.2.2. 마치 레시피만 계속 고치다가 결국 맛없는 음식만 계속 만드는 것과 같음
2.3. 코드를 무시하고 AI에게만 맡기는 건 좋은 방법이 아님
• 2.3.1. 나쁜 코드는 고치기 어렵고, 버그를 많이 만들어서 결국 돈이 더 많이 들게 됨
• 2.3.2. 반대로 좋은 코드는 고치기 쉽고, AI가 더 잘 활용할 수 있게 함
3. AI와 소통하는 방법: 'Grill Me'
3.1. AI가 내가 원하는 대로 코드를 만들지 못하는 경우가 많dma
• 3.1.1. 내가 머릿속으로 생각한 것과 AI가 만든 결과물이 다를 때가 있음
• 3.1.2. 마치 내가 친구에게 '맛있는 거 만들어줘' 했는데, 친구가 내가 생각한 것과 전혀 다른 음식을 만들어주는 것과 같음
3.2. 이건 AI와 나 사이에 생각의 차이(디자인 컨셉)가 있기 때문
• 3.2.1. 우리가 만들려는 것에 대한 '보이지 않는 생각'이 서로 다를 수 있음
• 3.2.2. 마치 같은 그림을 그리는데, 서로 다른 그림을 상상하는 것과 같음
3.3. 이 문제를 해결하려면 AI와 'Grill me' 스킬을 사용하면 좋음
• 3.3.1. AI에게 "내가 계획한 모든 것에 대해 끊임없이 질문해서 서로 완벽하게 이해할 때까지 물어봐 줘"라고 시키는 방식
• 3.3.2. AI가 40~100개까지 질문을 하면서 내가 뭘 원하는지 정확히 파악하게 됨
• 3.3.3. 이렇게 하면 AI와 내가 같은 그림을 그리게 되고, AI가 더 정확한 코드를 만들 수 있음
4. AI와 같은 언어 사용하기: '공통 언어'
4.1. AI가 너무 장황하게 설명하거나, 내가 이해하기 어려운 말을 할 때가 있음
• 4.1.1. 마치 외국인과 대화하는데, 서로 다른 단어를 써서 오해가 생기는 것과 같음
4.2. 이럴 때는 '공통 언어(Ubiquitous Language)'를 만들어야 함
• 4.2.1. 나와 AI가 함께 사용하는 용어 목록을 만들거나
• 4.2.2. 마치 우리만의 '비밀 사전'을 만들어서, 그 단어들만 쓰는 방식
4.3. 이 공통 언어는 코드, 설계 문서, 그리고 AI와 대화할 때 모두 사용함
• 4.3.1. AI가 내 코드를 스캔해서 용어 목록을 자동으로 만들어주기도 함
• 4.3.2. 이렇게 하면 AI가 더 간결하게 생각하고, 내가 계획한 대로 코드를 만들게 됨
• 4.3.3. 마치 같은 언어를 쓰면 대화가 훨씬 잘 통하는 것과 같음
5. AI가 제대로 작동하는 코드를 만들게 하는 방법: '작게 나누어 테스트하기'
5.1. AI가 코드를 잘 만들었는데, 막상 돌려보면 작동하지 않을 때가 있음
• 5.1.1. 마치 로봇이 멋진 장난감을 만들었는데, 스위치를 눌러도 움직이지 않는 것과 같음
5.2. 이럴 때는 '피드백 루프(Feedback Loop)'를 활용해야 함
• 5.2.1. 자동화된 테스트나 타입스크립트(TypeScript) 같은 도구를 사용해서 AI가 만든 코드를 바로바로 확인하는 방식
• 5.2.2. 마치 요리사가 음식을 만들면서 중간중간 맛을 보며 간을 맞추는 것과 같음
5.3. AI는 한 번에 너무 많은 코드를 만들려고 해서 문제가 생김
• 5.3.1. 이건 마치 운전할 때 헤드라이트가 비추는 범위보다 훨씬 빠르게 달리는 것과 같음
• 5.3.2. 그래서 '테스트 주도 개발(TDD)' 방식을 사용해야 함
• • 5.3.2.1. 먼저 작은 테스트를 만들고, AI가 그 테스트를 통과하는 코드를 만들게 하는 식
• • 5.3.2.2. 그리고 코드를 더 좋게 다듬는 과정을 반복
• • 5.3.2.3. 마치 작은 목표를 하나씩 달성하면서 큰 목표에 도달하는 것과 같음
5.4. 'Deep Modules' 구조로 코드를 만들면 테스트하기 쉬워짐
• 5.4.1. 코드를 작은 상자들(모듈)로 나누는데, 이 상자들은 겉은 단순하지만 안에는 복잡한 기능들이 숨어있는 거임
• 5.4.2. 마치 장난감 상자 겉면에는 '자동차'라고만 쓰여 있지만, 안에는 복잡한 부품들이 들어있는 것과 같음
• 5.4.3. 이렇게 하면 AI가 코드를 이해하기 쉽고, 테스트도 간단하게 할 수 있음
• 5.4.4. Matt Pocock은 이 구조를 만들기 위해 '코드베이스 아키텍처 개선'이라는 기술을 사용함
5.5. 이렇게 하면 머리도 덜 피곤해짐
• 5.5.1. 나는 상자의 겉모습(인터페이스)만 설계하고, 안의 복잡한 내용은 AI에게 맡길 수 있음
• 5.5.2. 마치 내가 집의 외관과 방 배치만 정하고, 내부 인테리어는 전문가에게 맡기는 것과 같음
• 5.5.3. 결국, AI 시대에는 시스템 설계에 매일 투자하는 것이 가장 중요함
• 5.5.4. AI는 코드를 만드는 '전술가'이고, 우리는 전체를 지휘하는 '전략가'가 되어야 함