개발자의 지옥

• 이전에는 튜토리얼 헬(강의만 듣고 개발 x) -> 프레임워크 헬(배우는 속도 < 나오는 속도) -> 스킬 헬(좋은 스킬 판별 불가)
• 좋은 스킬 채점표 4단

1. 트리거: 누가 부르냐(사용자 vs 모델 호출)

• 인지 부하 vs Context 부하 (설명문이 대화 context에 상주, 예측 불가능성)
• superpowers는 대부분 모델 호출
• 뭘 포기할지의 문제다.

2. 구조: 내용물은 딱 2종류

• agent가 밟아가는 순서와 참고자료 ref.
• 가끔 쓰는 자료를 밖으로
  
  
  

3. 유도: 적어왔는데 안 한다.

• 그래서 길게 설명을 늘여놓은데, leading word를 사용하자. => vertical slice
• plan 모드: 2~3개만 물어보고 목표인 계획 만들기가 되버리지않나?
  

해법: 스킬을 쪼개서, 미래를 숨긴다. 즉, 질문 skill/계획 skill 따로 두어서 질문 skill은 계획을 짜는건지를 모르도록

4. 가지치기: 거대한 스킬은 증상이다. - 지워도 결과가 같다면 지워라.

스킬 저장소
링크

grill-me: 나를 인터뷰하게하는 스킬

스킬은 확률적인 시스템에서 예측가능성을 짜내는 장치. 매번 같은 답이 아닌 방식을! 필요한 건 새 스킬이 아니라, 지워보는 눈

하네스 엔지니어링 정말 제대로 쓰고 있나?

달은 안 보고 손가락만 보고 있다.

손가락

• 어떤 모델을 쓸까
• 토큰 절약 꿀팁
• 칼퇴 필수 스킬

뭘 하고자 하는가를 잘 달성하게 해주는 게 '하네스'이다.

• Agent = model + harness
  - 모델을 바꿀 수 없으니 이를 감싸는 환경을 건드는 것
  - 모델은 확률로 움직인다. 그 한번이 장애다.

인프라를 통한 방지

• deny설정과 같이 반드시 지켜야할 요소는 개인 설정이 아니라, 프로젝트 규칙에 박아둔다. 장애를 막는 건 습관이 아니라, 인프라이다.

처음부터 완벽하지말자

• 오히려 모델이 매턴 context 증가, 안 쓰이는 규칙 잔뜩
• 가면서 최적화. 하네스는 설계도가 아니라 사고 이력으로 짓는 것.
• 통용되는 하네스는 없다. 프로젝트에 맞게 깎여나가는 것

• 하네스는 다르더라도 위 4계층을 지켜보자.

당장 적용해볼만한 것들

• deny 규칙: 최소한 위험한 명령에 대해 작성
  
  

• 검증은 자동
  

• 먼저 감싸야할 일: 반복되는 일, 사고나면 비싼 일

링크