GitHub의 구조적 문제임. 관련 토론을 보면, OAuth App과 GitHub App의 권한 모델이 다름
GitHub App은 특정 리포에만 설치할 수 있지만 여전히 “사용자 대신 행동” 권한을 포함함
그래서 무섭게 보이는 팝업이 뜨는 것임
내 앱 codeinput.com은 OAuth App이라 이메일만 요청하지만, 로그인 후 다시 설치 과정을 거쳐야 하는 복잡한 인증 흐름이 생김
앱을 처음 실행할 때 GitHub 로그인을 요구함. 그 전엔 아무 것도 볼 수 없음
방향성은 흥미롭지만 비용 대비 효용이 애매함
LLM이 단일 PR diff만으로 프로젝트 맥락을 이해하기는 아직 어려움
오히려 과거 버그나 변경 빈도를 기반으로 한 데이터 기반 히트맵이 더 신뢰도 높을 것 같음
Gemini 무료 키를 쓰면 하루 요청량이 충분해서, 소규모 팀(10~20 PR/일)에는 큰 비용이 아님
개인 키로 실행할 수 있다면 더 좋을 듯함
diff의 엔트로피를 분석하는 비슷한 도구가 있을지 궁금함
우리도 예전에 리포를 VM에 복제해 Codex로 탐색시키는 실험을 했지만, 지연 시간과 비용 문제로 중단했음
Distillation으로 비용을 줄일 수 있을 것 같지만 아직 실험 중임
과거 버그와의 상관관계를 LLM 없이 계산할 방법이 있을지도 고민 중임
코드 리뷰할 때 diff에 없는 줄을 자주 언급하게 됨
이런 도구들은 결국 문제의 일부분만 해결할 수 있음
코드 변경이 잦은 부분이 꼭 버그가 많은 건 아닐 수도 있음
오히려 사람들이 더 주의 깊게 보는 영역일 가능성도 있음
오픈소스 데이터를 기반으로 검증해보면 흥미로울 것 같음
내 PR이 HN에 올라와서 반가웠음
0% 임계값으로 두고 색상 그라데이션을 다양하게 조정할 수 있으면 좋겠음
PR 생성 전에 AI가 만든 코드를 이 도구로 미리 리뷰할 수 있을지도 궁금함
색상과 그라데이션은 설정 가능하게 할 예정임
CLI나 HTML로 diff를 렌더링하는 명령어 형태가 괜찮을지 의견을 묻고 싶음
이런 도구를 쓰느라 결국 직접 코딩하는 시간보다 더 오래 걸릴 수도 있음
도메인 이름 0github.com은 오래 유지하기 어려울 듯함. 빨리 다른 도메인을 찾는 게 좋겠음
왜 그런지 궁금함
거대한 PR에서 특히 유용할 것 같음
슬라이더 대신 색상별로 클릭해 의미를 바로 볼 수 있으면 좋겠음
지금은 한눈에 파악하기 어렵지만 자주 쓰면 익숙해질 듯함
현재는 하이라이트된 단어에 마우스를 올리면 툴팁이 표시됨
모바일에서도 보이게 개선할 예정임. 혹시 다른 표시 방식이 나을지 궁금함
간단한 Rust PR에 적용해봤는데 꽤 잘 작동했음
다만 하이라이트 위치를 좀 더 세밀하게 조정할 수 있으면 좋겠음
동료 PR에서 거의 안 보이는 오타를 잡아낸 건 인상적이었음 테스트한 PR 링크
삭제된 코드 일부는 표시되지만 많은 부분이 무시됨
혹시 토큰 간 거리를 계산하는 방식인지 궁금했음
구현은 이 파일에 있음
지금은 단순한 LLM 프롬프트 기반임
향후 환각 토큰 감지 방식으로 발전시킬 수 있을 듯함. 관련 논문을 찾아볼 예정임
요즘 AI가 만든 대형 PR이 많아지면서 이런 도구의 필요성을 느꼈음
리뷰어의 스타일을 학습해 맞춤 리뷰를 제공하면 좋겠음 이 커밋이 맞는지 확인 중임
주요 로직은 이 파일에 있음
DSPy 시스템으로 리뷰어의 선호도에 맞춘 자동화 리뷰를 실험 중임
사실 이런 도구가 필요 없을 정도로 적당한 크기의 PR을 만드는 게 더 중요함
요즘은 AI로 작성된 PR을 리뷰하고, 심지어 내 코멘트에 AI가 답변함
결국 리뷰어도 AI로 대체되는 시대가 올 것 같음
Hacker News 의견
익숙한 코드베이스에서는 “LLM 고마워, 하지만 내가 더 잘 알아서 필요 없음”이라 생각함
반대로 익숙하지 않은 코드라면 애초에 내가 리뷰를 승인하거나 머지하지 않음
그래도 이런 창의적인 LLM 활용은 흥미로운 시도임
삭제된 코드도 전혀 표시되지 않았고, 변경되지 않은 줄만 하이라이트됨
정직한 시도였지만 결과는 실망스러움
왜 GitHub에서 나를 대신해 행동할 권한까지 요구하는지 의문이었음
cmux-agent가 GitHub 계정 전체 접근 권한을 요청함이슈를 등록하려 했지만 저장소에서 이슈 기능이 비활성화되어 있었음. 조금 수상한 느낌이었음
시크릿 모드로 예시 PR들, stack-auth, tinygrad, datasette 테스트했는데 잘 작동했음
이슈 비활성화는 몰랐고 지금은 이슈 페이지가 정상임
GitHub App은 특정 리포에만 설치할 수 있지만 여전히 “사용자 대신 행동” 권한을 포함함
그래서 무섭게 보이는 팝업이 뜨는 것임
내 앱 codeinput.com은 OAuth App이라 이메일만 요청하지만, 로그인 후 다시 설치 과정을 거쳐야 하는 복잡한 인증 흐름이 생김
방향성은 흥미롭지만 비용 대비 효용이 애매함
LLM이 단일 PR diff만으로 프로젝트 맥락을 이해하기는 아직 어려움
오히려 과거 버그나 변경 빈도를 기반으로 한 데이터 기반 히트맵이 더 신뢰도 높을 것 같음
개인 키로 실행할 수 있다면 더 좋을 듯함
Distillation으로 비용을 줄일 수 있을 것 같지만 아직 실험 중임
과거 버그와의 상관관계를 LLM 없이 계산할 방법이 있을지도 고민 중임
이런 도구들은 결국 문제의 일부분만 해결할 수 있음
오히려 사람들이 더 주의 깊게 보는 영역일 가능성도 있음
오픈소스 데이터를 기반으로 검증해보면 흥미로울 것 같음
내 PR이 HN에 올라와서 반가웠음
0% 임계값으로 두고 색상 그라데이션을 다양하게 조정할 수 있으면 좋겠음
PR 생성 전에 AI가 만든 코드를 이 도구로 미리 리뷰할 수 있을지도 궁금함
CLI나 HTML로 diff를 렌더링하는 명령어 형태가 괜찮을지 의견을 묻고 싶음
도메인 이름 0github.com은 오래 유지하기 어려울 듯함. 빨리 다른 도메인을 찾는 게 좋겠음
거대한 PR에서 특히 유용할 것 같음
슬라이더 대신 색상별로 클릭해 의미를 바로 볼 수 있으면 좋겠음
지금은 한눈에 파악하기 어렵지만 자주 쓰면 익숙해질 듯함
모바일에서도 보이게 개선할 예정임. 혹시 다른 표시 방식이 나을지 궁금함
간단한 Rust PR에 적용해봤는데 꽤 잘 작동했음
다만 하이라이트 위치를 좀 더 세밀하게 조정할 수 있으면 좋겠음
동료 PR에서 거의 안 보이는 오타를 잡아낸 건 인상적이었음
테스트한 PR 링크
삭제된 코드 일부는 표시되지만 많은 부분이 무시됨
혹시 토큰 간 거리를 계산하는 방식인지 궁금했음
지금은 단순한 LLM 프롬프트 기반임
향후 환각 토큰 감지 방식으로 발전시킬 수 있을 듯함. 관련 논문을 찾아볼 예정임
요즘 AI가 만든 대형 PR이 많아지면서 이런 도구의 필요성을 느꼈음
리뷰어의 스타일을 학습해 맞춤 리뷰를 제공하면 좋겠음
이 커밋이 맞는지 확인 중임
DSPy 시스템으로 리뷰어의 선호도에 맞춘 자동화 리뷰를 실험 중임
사실 이런 도구가 필요 없을 정도로 적당한 크기의 PR을 만드는 게 더 중요함
요즘은 AI로 작성된 PR을 리뷰하고, 심지어 내 코멘트에 AI가 답변함
결국 리뷰어도 AI로 대체되는 시대가 올 것 같음
예시 PR을 클릭했는데 계속 로딩만 됨. 캐싱이 필요해 보임