테스트 기법 지시가 에이전트 코딩 정확도를 높이지 못한다
How well do agents use test/verification techniques?
Dan Luu이 26가지 프롬프트 조건(테스트 주도 개발, 퀵체크, 형식 검증 등)으로 에이전트(Zstd 구현)의 테스트/검증 기법 활용 능력을 평가했습니다. 결과는 기본 지시(추가 지시 없음)가 평균 이상의 성능을 보였고, 특정 기법을 지시해도 에이전트는 피상적으로 적용하거나 잘못 사용했습니다. 형식 검증과 퍼징은 평균적으로 비슷했으며, 인기 스킬(ECC 등)은 오히려 저조했습니다. 에이전트는 테스트 작성 능력이 부족하며, 이는 RL 환경 부재와 효과적 테스트 기법에 대한 지식 부족 때문일 수 있습니다.
에이전트는 테스트 기법이나 라이브러리를 효과적으로 사용하지 못하며, 지시를 받아도 피상적으로 적용하거나 잘못 사용하는 경향이 있다.
HN 토론
38- andai
저는 인디 게임 개발을 하고 있어서 제 경험이 얼마나 전수가 될지 모르겠지만, 브라우저 게임을 만들고 있고 그 게임은 좀 별로인데 (제 기준으로) 테스트가 엄청 많습니다. 그래서 테스트가 많다고 해서 좋은 소프트웨어는 아닐 수 있습니다. (테스트가 거의 없어도 훌륭한 소프트웨어가 있을 수 있습니다!) 또한, AI가 아키텍처 변경을 완전히 반대로 구현한 재미있는 경험도 있었습니다. 그 구현은 무의미했고 오히려 상황을 악화시켰습니다. 하지만 여전히 "모든 테스트가 통과"했습니다. 왜냐하면 그것은 단지 잘못된 것이 제대로 작동한다는 것을 증명했기 때문입니다. 공식 검증도 그 경우에는 도움이 되지 않았을 것이라는 점을 재미있게 지적했습니다. 그것은 단지 애초에 존재하지 말아야 할 것의 "정확성"에 대한 더 강력한 증명이 되었을 뿐입니다.
- ivanzhaowy123
제 경험상, 에이전트는 단위 테스트를 작성할 때 인간보다 더 많은 엣지 케이스를 생각하는 경우가 많습니다. 그러나 특정 스킬의 지도 아래에서는 기계적으로 변하고 비즈니스 로직을 놓칠 수 있습니다. 예를 들어, Superpowers 스킬 세트를 사용할 때 에이전트는 모든 새 기능에 대해 TDD를 적극적으로 채택합니다. 그러나 테스트에 대한 이해는 종종 피상적입니다. 사용자가 "보내기" 버튼이 있는 화면을 요청하면, 먼저 버튼이 존재하는지 확인하는 테스트를 작성합니다. 테스트가 실패하면 버튼을 추가하여 통과시킵니다. 그 결과, 테스트 스위트는 속성 존재 여부나 문자열이 정확히 일치하는지 확인하는 저가치 케이스로 가득 차게 됩니다. 에이전트는 "실패하는 테스트를 작성한 다음 기능을 구현"하는 워크플로우를 따르지만, 실제 비즈니스 동작을 테스트하지는 않습니다. 보내기가 언제 허용되어야 하는가? 성공 또는 실패 후에는 어떻게 되어야 하는가? 중복 제출은 어떻게 처리되어야 하는가? 문제는 에이전트가 테스트를 작성할 수 없다는 것이 아닙니다. 그들은 TDD를 일련의 고정된 단계로 축소하는 경향이 있고, 비즈니스 요구 사항에서 의미 있는 테스트 케이스를 독립적으로 도출하고 이를 개발에 사용하는 데 어려움을 겪는 것 같습니다.
- siscia
아직 이르지만, 이 실험은 거의 의미가 없고 거의 유용하지 않다고 생각합니다. 코드를 테스트하는 방법은 코드 자체를 아키텍처링하는 방법과 분리될 수 없고 (그리고 분리되어서도 안 됩니다). 효과적인 테스트의 80% 이상은 테스트 프레임워크가 아니라 코드 아키텍처에 있습니다. 저자는 코드가 어떻게 아키텍처링되고 관리되는지 언급하지 않습니다. 제 경험으로는, 에이전트에게 DI/헥사고날 아키텍처를 강제하고 사소한 커버리지 검사를 강제하는 것이 꽤 유용하며 비교적 적은 노력으로 전반적으로 충분히 좋은 코드를 생성합니다.
- movpasd
이것은 제가 해온 어떤 테스트보다 훨씬 철저하고 완전히 다른 도메인에 있지만, 에이전트에게 Hypothesis를 사용하게 한 저의 일화적 경험은 상당히 나빴습니다. 에이전트는 코드와 그것이 모델링해야 하는 실제 비즈니스 규칙 사이의 간극을 메우는 데 정말 어려움을 겪었습니다. 또한 어떤 레이어의 어떤 함수에 대해 테스트를 작성하는 것이 적절한지 파악하는 데도 어려움을 겪었습니다. 그래서 그 테스트는 도메인 로직의 변경에 매우 취약했습니다. 본질적으로, 에이전트는 모듈성과 문제 분해에 항상 어려움을 겪는 것 같습니다. 좋은 테스트는 올바른 것을 테스트하는 것입니다. 즉, 입력 상태를 적절한 제품 상태로 세분화하고 각 동작을 독립적으로 확인하는 방법을 알아내는 것입니다. 제 생각에 이것은 프로그래밍에서 가장 어렵고 복잡한 부분이므로, 에이전트가 인간보다 더 어려움을 겪었다고 말하지는 않겠습니다. 그러나 인간은 잠을 자며 생각할 수 있는 이점이 있습니다. 제가 관찰한 사소한 점은 에이전트가 부동 소수점 엣지 케이스(NaN, 무한대)에 매우 집착하는 경향이 있다는 것입니다. 아마도 부동 소수점 엣지 케이스는 프로퍼티 테스트 훈련 데이터에 과대 대표되어 있을 수 있지만, 적어도 비즈니스 규칙과 관련해서는 제 사용 사례에는 본질적으로 관련이 없습니다.
- anitil
모두가 에이전트가 자신이 잘하는 일을 못하고 자신이 못하는 일을 잘한다고 생각한다는 거 아시죠? 알고 보니 제가 테스트를 못하는 것 같습니다. 왜냐하면 저는 에이전트가 테스트를 꽤 잘한다고 생각했기 때문입니다.