코드를 동적으로 환경변수에서 가져오긴 하던데 시연 기능은 있더라고요. 애매한듯 합니다.

비공개라서 실행해볼수가 없는 순수 광고(?)인데 그러면 show gn에 올라오면 안 됩니다.
https://news.hada.io/blog/show

저는 이걸 좀 발전시켜서 한번 작성된 경험이 다시 재발했을 때 패턴화하고 일반화해서 진화(evolve)가 잘 되도록 더 확장해 볼 생각입니다.

Wow

이 프로젝트는 GC가 문제가 될 정도는 아닐 겁니다. "근래 대부분 프로젝트" 중 사실 프로그래밍 언어 채택은 특정 언어의 장점이나 한계 때문이라기보다는 취향의 영역인 경우가 많다고 보는데요, 그럼에도 범용 프로그래밍 언어로서 Rust가 Go에 대해 갖는 비교우위가 무엇이냐고 묻는다면 저는 Rust가 제공하는 추상화 수준과 컴파일 타임에 여러 오류를 잡아낼 수 있다는 점이라고 답할 것 같습니다. 물론 Go도 Rust에 대해 손쉬운 비동기 프로그래밍, 빠른 컴파일 타임, 간결한 문법 등의 장점이 있습니다.

같은 수준의 계약이더라도 신뢰도나 이미지가 참 다르게 느껴지네요.
gpt 구독 해지나 해야겠네요.

기분나빠 죄

우와 멋집니다. RustPython 때문에 가능하신가 보네요. 좋은 결과 있으시길!

rust는 컴파일때 오류가 잡히는 비중이 커서 컴파일 실패가 오히려 AI가 올바른 길로 가도록 도와주는 느낌이 있더라고요

신청해 보았습니다

뭐, 추측이긴합니다만, Rust 진입 장벽이 사라져서 아닐까 싶습니다.
가장 큰 어려움이 코딩했더니 컴파일이 계속 실패한다 인데, AI가 대신해주니깐요.

Joke 테스트 였나보군요

DIY, 메이커운동, 인디, 펑크, 오픈소스 모두 산업화, 자본주의, 소비주의에 대한 반론인데, 그것의 한계를 극복하는게 소비주의를 받아들이는거라니.

바이브코딩이 소비 프레임에 걸맞는다는거에는 동의합니다. 최근에 유행하던 테무깡, 알리깡 (https://www.asiae.co.kr/article/2024053117460950053) 의 코딩버전이라고 생각이 듭니다.
그런데 소비 프레임이 메이커운동의 실패를 반복하지 않을 방법이라고 하면 HN의 댓글처럼 여러모로 동의할 수 없네요.

바이브코딩은 시민개발자의 역사적 히스토리를 이어가고 있다.
바이브코딩은 이제 코딩을 마치 전기 처럼 쉽고 빠르고 필수불가한 존재로 나아가고 있다고 본다.
이미 수많은 기업의 천재적인 프로그래머도 코드를 한줄 안쓰고 프롬프트와 에이전트로 코딩을 이어가고 있다.
이를 낮추려는 사람들도 있지만 안드레 카파시의 바이브 코딩이 컴퓨터 역사에 한 획을 긋는 일이라는 것은 반론하기 어렵다고 본다.

좋은 질문입니다. 사실 저희 실험의 "하이브리드" 조건이 정확히 그 방향이었습니다 — 정리된 요약에 날것의 경험 로그를 함께 제공하는 구성이요.

결과적으로 하이브리드가 4.95/5.0으로 가장 높았습니다. 요약만 주면 2.65인데, 거기에 "실패했다", "원인 불명" 같은 과정 기록을 붙이니 오히려 요약의 약점이 보완되더라고요.

그래서 결론은 "요약 자체가 나쁜 게 아니라, 과정과 불확실성을 함께 담아야 한다"입니다.

하지만 N=1 이라서 다양한 사용자층으로 범용적 으로 쓰일 내용인지는 후속연구가 필요합니다.

그렇다면 합성 메모리에 그런 작업들의 프로세스, 실패, 성공의 내용을 담도록 구성하면 좀 달라질까요?

맞습니다. 저도 처음에 합성 메모리가 최소한 베이스라인보다는 나을 거라 예상했는데, 결과를 보고 놀랐습니다.

분석해보니 핵심은 "불확실성 보존" 이었습니다. 날것의 로그에는 "이거 해봤는데 안 됐다", "원인 모르겠다" 같은 흔적이 남아있어서 에이전트가 모르는 건 모른다고 답하는데, 요약본은 그런 맥락이 다 지워지면서 오히려 틀린 답을 확신있게 내놓더라고요.

경험적으로 어느정도 느끼던거긴 한데 합성 메모리는 제 생각보다도 너무 처참하네요

써보려했는데 gemini 2.5까지밖에 지원을 안하네요... 지원 모델 리스트도 바이브코딩 한 건가