▲
ndrgrd | 2일전 | parent | on: GitHub 이전의 오픈소스 세계 (lucumr.pocoo.org)

사실 이슈 pr 토론이 문제지 git 자체는 언제든 다른 서비스로 옮길 수 있거든요. git에 이 셋을 넣는 프로젝트도 있던데 그런 걸 사용하면 언제든 옮길 수 있겠네요

▲
ajh508 | 2일전 | parent | on: Claude한테 짜게 시키고 Codex한테 까게 시키기 — 두 에이전트를 한 레포에서 분담시키는 실무 패턴 (rubric.im)

저는 trilateral-validation이라고 claude subagent(fresh context)+codex+gemini 까지 붙여서 검증 스킬 하나 만들어두고 씁니다.
자잘한 오류 말고 방향성 자체를 틀어야 하는 실험이나 설계는 메인 개발은 클로드로 하고, gpt 5.5pro에 깃허브 앱달아서 검증시키구요.(codex가 프로 모델을 지원 안해서...)
프로덕션 개발은 안하고 연구만해서 생각못했는데 git hook도 한번 걸어봐야겠네요.

▲
minhoryang | 2일전 | parent | on: Show GN: Threadlens - 로컬 AI 세션을 검색하고 분석·백업·정리하는 오픈소스 도구 (github.com/hanityx)

@hanityx 혹시 다른 provider를 추가할 수 있는 가이드를 만들어주실 수 있을까요? (opencode나 다른걸 더 넣어보고싶은데) docs/PROVIDER_SUPPORT.md 의 정보는 직접 취합하신건가요? apps/api-ts/src/domains/providers/matrix.ts 에는 직접 추가를 해야하나요? 인터페이스를 분리한다면 조금 더 편해질 것 같아서요.

▲
svg1773 | 2일전 | parent | on: 자신보다 뛰어난 사람을 채용하는 법 (longform.asmartbear.com)

(Zuckerberg 본인은 다른 사람 밑에서 일한 적이 없음) ㅋㅋㅋㅋㅋㅋ

▲
xguru | 2일전 | parent | on: Cursor Camp (neal.fun)

HN 댓글이 이해 됩니다.
"Neal이 새 게임을 낼 때마다 직원 생산성이 떨어지니, 회사들이 집단소송을 걸 만하다고 봄"

일해야 하는데 한참 놀았네요 ㅠ

▲
xguru | 2일전 | parent | on: GoModel - Go로 작성된 고성능 AI 게이트웨이 (github.com/ENTERPILOT)

LiteLLM 도입 하려는 회사들이 한번 가벼운 대체제로 고려해 볼만한 듯

Python 기반인 LiteLLM이 예전에 공급망 공격 한번 당한 적이 있어서, 상대적으로 Go가 좀 더 안전해 보이는 효과도 있긴 하네요.

▲
hmmhmmhm | 2일전 | parent | on: Cursor Camp (neal.fun)

인트로 보려고 들어갔다가 바로 커서 압수 당하고 게임으로 빨려들어갈뻔...

▲
kaydash | 2일전 | parent | on: PgQue – Bloat 없는 Postgres 큐 (github.com/NikolayS)

진짜 올인원 db

▲
kaydash | 2일전 | parent | on: Warp의 오픈소스 전환과 에이전트 중심 개발 모델 발표 (x.com/zachlloydtweets)

이제 BYOL 처럼 개인 키를 쓸수있겠네요

▲
xguru | 2일전 | parent | on: GitHub 가용성에 대한 업데이트 (github.blog)

에러가 너무 많이 나니 급하게 아예 공지를 한거군요.
근데 너무 늦은거 아닌가 하는 생각이..
이미 에러가 너무 많이 나서 다들 이탈한다고 얘기중인데요 ㅠ

▲
winkagn | 2일전 | parent | on: DeepSeek-V4 논문 읽기 요약 - 노정석 (youtube.com)

사람들은 중국산이라고 못믿는다고 이런식으로 말하긴 하지만 저는 Deepseek가 연구하고 오픈하는 방향으로 시행착오도 공개하는 것 만큼은 정말 고맙다고 생각합니다.

▲
aldlfkahs | 2일전 | parent | on: stitch가 유행시킨(?) DESIGN.md를 모아놓은 사이트 (getdesign.md)

AI한테 프론트 맡길 때 좋겠네요 공유 감사합니다.

▲
neostom432 | 2일전 | parent | on: Claude한테 짜게 시키고 Codex한테 까게 시키기 — 두 에이전트를 한 레포에서 분담시키는 실무 패턴 (rubric.im)

저희는 둘 다 사용하는 쪽으로 정착했습니다.

슬래시 커맨드 흐름 안에 Codex 교차 리뷰 페이즈를 넣어두고(/ship 안에 기획 → 구현 → 검증 → Codex 리뷰 → 보고 식으로), 동시에 pre-push hook에도 같은 리뷰를 걸어둡니다. 슬래시 커맨드만 두면 급할 때 그냥 push해서 리뷰가 빠지고, hook만 두면 push 직전에야 결과가 나와 늦습니다.

두 경로 모두 Codex CLI를 직접 부르지 않고, 한 번 감싼 bash 스크립트(codex-review.sh) 한 개를 양쪽에서 똑같이 호출합니다. 그 스크립트가 타임아웃, 인증 체크, 시크릿 체크, 출력 포맷을 한 곳에서 처리해줘서 슬래시 커맨드든 hook이든 호출 측이 깔끔해집니다.

핵심은 Codex 리뷰 결과로는 절대 차단하지 않는다는 점입니다. CLI가 죽었거나 CRITICAL이 나와도 push는 그대로 통과시키고 결과만 출력해요. 한 번이라도 차단으로 만들면, Codex가 실제로는 문제없는 코드를 잘못 잡았을 때 사용자가 push를 하려고 hook을 우회하는 옵션(git push --no-verify)을 쓰게 되고, 이게 습관이 되면 hook이 걸려 있어도 안 도는 것과 똑같은 상태가 됩니다. 그래서 차단이 필요한 검사(린트·타입·테스트, 시크릿 파일 push)는 별도 게이트로 분리하고, 모델 의견은 참고용으로만 둡니다.

스크립트·슬래시 커맨드·hook 본문은 트랙 4~6챕터에 그대로 들어 있으니 참고하셔도 좋을 것 같습니다.

▲
ku9cu | 2일전 | parent | on: Claude한테 짜게 시키고 Codex한테 까게 시키기 — 두 에이전트를 한 레포에서 분담시키는 실무 패턴 (rubric.im)

이렇게 하시는 분들 있다고 하는데, 어떤 방식일지가 궁금하네요.
두 도구를 별도의 에이전트로 묶지 않고, 개발자가 직접 필요할 때마다 각각 호출하는 건지,
Git Hook 할 때 자동으로 Codex가 리뷰를 하게 만드는 설정으로 조치하는 지 궁금하네요.

▲
semjei | 2일전 | parent | on: Ask GN: 오픈클로 웹으로 세팅해서 사용해보려고 하는데

Oracle OCI 가 4CPU 24GB ram 50GB storage 로 무료로 돌리세요.