메뉴
HN
Hacker News • 18일 전

AI 코딩 에이전트는 테스트·검증 기법을 얼마나 잘 활용할까?

IMP
7/10
핵심 요약

테스트 전문 지식이 없는 사람이 단순히 'TDD를 사용하라', 'QuickCheck를 사용하라' 같은 지시만으로 코딩 에이전트에 특정 검증 기법을 적용했을 때 구현 정확도가 실제로 개선되는지 실험한 글입니다. Zstd 압축 알고리즘 구현을 Rust로 평가했으며, 총 26가지 프롬프트 조건과 4가지 스킬을 비교했습니다.

번역된 본문

우리는 이전에, 코딩 에이전트에게 효과적인 테스트 기법을 사용하게 하는 것이 특정 품질 기준을 달성하는 것은 그 어느 때보다 쉬워졌음에도, 소프트웨어 품질은 오히려 나빠지고 있는 것처럼 보인다는 점을 지적한 바 있습니다. 이는 개발자들이 사용하는 기본 설정이 그리 효과적이지 않을 수 있다는 것을 시사합니다. 여기서 우리는 특정 기법이나 라이브러리를 사용하라고 에이전트에게 단순한 지시를 내렸을 때 구현의 정확성이 개선되는지 테스트합니다. 이는 테스트에 전문 지식이 없지만 특정 기법을 적용하거나 특정 라이브러리를 사용해야 한다는 얘기를 어디선가 들어본 사람이 에이전트를 이끌었을 때 얼마나 효과적인지 확인하는 일종의 시험입니다.

우리는 에이전틱 프로그래밍 언어 효과 비교에서 논의된 Zstd 구현 평가를 재사용하고, 대신 '테스트 주도 개발(TDD)을 사용하라', 'Lean 4를 사용하라', 'QuickCheck를 사용하라', '속성 기반 테스트(property-based testing)를 사용하라' 등 다양한 추가 지시문과 함께 Zstd를 구현하라는 프롬프트를 에이전트에 주었을 때 서로 다른 테스트 기법과 테스팅 라이브러리를 비교합니다. IMAP RFC에 대한 평가 등 다른 평가도 몇 가지 진행했으며, 이에 대해서는 간략히 논의합니다. 모든 구현은 Rust로 작성되었습니다.

테스트된 26가지 프롬프트 조건은 다음과 같습니다: ACL2, Alloy, '위험 영역 감사(audit) 및 퍼징', '감사 먼저 수행', Creusot, 기본(추가 지시 없음), 차등 테스팅(differential testing), 퍼징(fuzzing), Hegel, Insta, 판단형(에이전트에게 최선의 기법을 사용하라고 요청), Kani, Lean 4, '실수하지 마라', 메타모픽 테스팅(metamorphic testing), 뮤테이션 테스팅(mutation testing), 속성 기반 테스팅, Proptest, QuickCheck, rstest, Rust 기본 테스트 프레임워크, SMT 솔버(Z3, cvc5, Yices 모두 사용 가능), Spin, TDD, TLA+, Verus.

추가로 4가지 스킬이 테스트되었습니다: 공식 Hegel 스킬, ECC Rust 테스트 스킬(ECC는 GitHub 스타 25만 개와 포크 3.8만 개를 보유한 스킬 모음), Trail of Bits의 속성 테스트 스킬, 그리고 제가 직접 작성한 테스트 스킬입니다(저는 스킬 대신 프롬프트를 쓰는 테크노포비아적 인간이라 좋은 스킬을 쓰는 감각이 없습니다). 제 스킬을 제외한 나머지 스킬들은 관련 스킬을 찾아달라고 codex에 요청했을 때 상위에 나온 것들이라서 선정되었습니다.

예측

각 조건이 어떻게 될지에 대한 추측을 사전 등록해두었습니다:

TDD는 성과가 낮을 것이다 (신뢰도 55%) TDD가 성과가 낮을 것이라고 생각했기에 TDD를 일부러 추가했습니다. 에이전트가 TDD를 지시받았을 때 무엇을 할지 모르기 때문에 신뢰도가 낮습니다. 어쩌면 에이전트는 TDD를 하지 않고 성과가 나쁘지 않은 다른 무언가를 할 수도 있습니다(혹은 TDD 성과 저하에 대한 제 판단이 틀렸을 수도 있습니다).

형식적 방법(formal methods)은 성과가 높지 않을 것이다 (신뢰도 52%) 제 생각에는 형식적 방법이 효과적이고 유용하며(지금 그 어느 때보다 더욱), 좋은 테스트 방법도 마찬가지로 효과적이고 유용하기 때문에, 비슷한 수준의 숙련도로 사용된다면 간단한 문제에서 형식적 방법이 더 좋은 성과를 낼 이유가 없습니다. 위와 마찬가지로, 그 이상으로 신뢰도가 낮습니다. 에이전트가 무엇을 하든 지시받았을 때 어떻게 할지 모르기 때문입니다. 그리고 형식적 방법은 에이전틱 코딩에서 좋은 테스트 기법보다 더 과대홍보되어 왔기 때문에, 랩들이 합성 데이터를 활용한 강화학습 환경으로 에이전트를 훈련시켜 형식적 방법에는 매우 능숙하지만 좋은 테스트 기법에는 능숙하지 않도록 만들었을 가능성이 충분히 있습니다(저는 좋은 테스트 기법으로 훈련시키는 것이 더 쉬웠을 것이라 예상하지만, 좋은 테스트 기법이 상대적으로 유행하지 않았기 때문에 시도되지 않았을 것입니다).

'실수하지 마라'는 지시 없음보다 나은 성과를 내지 못할 것이다 (신뢰도 95%) 이것은 농담이지만, 많은 사람이 시도해본 농담입니다. 효과가 있었다면 분명 누군가 알아챘을 것 아닌가요?

ECC 테스트 스킬(스타 25만 개, 포크 3.8만 개)은 성과가 높지 않을 것이다 (신뢰도 65%) 이 스킬은 다소 덩치가 크고, 유용할 것으로 예상되는 정보가 하나도 없습니다. 에이전트에게 TDD를 사용하라고 지시하는데, 에이전트가 실제로 TDD를 하게 된다면 상황을 악화시킬 것으로 예상합니다(TDD 조건보다 더 지시적이어서 TDD를 실행할 가능성이 높지만, 그것이 오히려 성공 가능성을 낮출 수도 있습니다). 나머지 정보는 유용해 보이지 않고 약간의 비용만 발생시킵니다.

제 스킬 예측은 모두 신뢰도가 낮습니다. 왜냐하면... (원문 누락)

원문 보기
원문 보기 (영어)
We previously noted that, while it's easier than ever to hit a particular quality bar by having coding agents use effective test techniques, software quality seems to be getting worse , indicating that whatever defaults developers are using may not work very well. Here, we test if simple instructions to agents to use particular techniques or libraries improve implementation correctness, as a kind of test to see how effective agents are when guided by someone with no expertise in testing who's maybe heard that you should apply certain techniques or use certain libraries. We'll re-use the Zstd implementation eval discussed in this comparison of agentic programming language effectiveness and, instead, compare different testing techniques and testing libraries when agents are given a prompt to implement Zstd with different addendums, such as "Use test-driven development", "Use Lean 4", "Use QuickCheck", "Use property-based testing", etc. I also ran some other evals, such as on the IMAP RFC, which are briefly discussed. All implementations were in Rust. The 26 prompt conditions tested were ACL2, Alloy, "Audit and fuzz risky areas", "Audit first", Creusot, Default (no additional instructions), Differential testing, Fuzzing, Hegel, Insta, Judgement (agents asked to use the best technique), Kani, Lean 4, "Make no mistakes", Metamorphic testing, Mutation testing, Property-based testing, Proptest, QuickCheck, rstest, Rust built-in test framework, SMT solvers (with Z3, cvc5, and Yices, all available), Spin, TDD, TLA+, and Verus. Additional, 4 skills were tested: Hegel with the official Hegel skill , the ECC Rust test skill (ECC is a collection of skills with 250k GitHub stars and 38k forks), the Trail of Bits property test skill , and a test skill I wrote (I'm a luddite who uses prompts instead of skills and have no feel for how to write a good skill). Other than my skill, the skills were chosen because those were the top skills codex turned up when asked to find relevant skills. Predictions I pre-registered some guesses on how conditions will do: TDD will underperform (55% confidence) I actually added TDD specifically because I thought it would underperform My confidence is low here because I don't know what agents will do when instructed to do TDD; perhaps agents won't do TDD and will do something that doesn't underperform (or perhaps I'm wrong about TDD underperformance) Formal methods will not overperform (52% confidence) My thought here is that formal methods are effective and useful (more so now than ever), good test methods are also effective and useful and, on simple problems, formal methods shouldn't outperform if used at a similar level of competence As with the above, but even more so, my confidence is low here because I don't know what agents will do when instructed to do anything, and formal methods have been more hyped than effective test techniques for agentic coding, so it's entirely plausible that labs have trained agents with RL environments with synthetic data which trains them to be very effective with formal methods without having trained agents to be effective with good test techniques (which I would expect to be easier to do, but not done because of how relatively untrendy effective test techniques are) Make no mistakes will not outperform no instructions (95% confidence) It's a joke, and one that a lot of people have tried. If it worked, surely people would've noticed? The ECC test skill (with 250k stars and 38k forks) will not outperform (65% confidence) It's somewhat big and doesn't have any information I'd expect to be useful. It instructs agents to use TDD; to the extent that it gets agents to use TDD, I'd expect this to make things worse (and it's more directive than the TDD condition and perhaps more likely to succeed, although for all I know that makes it less likely to succeed); the rest of the information doesn't seem useful and has some cost All of my skill predictions are low confidence because I don't tend to use skills and don't know how to really evaluate them. I'm thinking of this like, "how effective would it be if I passed the text in as a prompt and had this thing floating around in the LLM's context window?" Hegel's skill will not outperform (65% confidence) It's very big (the SKILL.md plus the linked Rust reference are over 20k tokens) and reads more like a tutorial than agent instructions The Trail of Bits test skill will not outperform (55% confidence) It has what looks like it might be useful information, but it's also fairly big Overall results Below, we have a very messy graph which shows the results for the conditions tested (codex with GPT-5.6 Sol, with medium and xhigh efforts). When looking at data, I tend to prefer much denser and messier graphs than most people, such as the first graph here . Because most people find these kinds of graphs unreadably messy, I tend to split information out into a series of graphs, each of which shows less information, when presenting information to others. For reasons discussed elow, I'm not going to do this here and am just going to present this extremely messy graph where we have cost on the x axis and the fraction of runs that passed 100% of the (hidden) tests on the y axis, average of 80 runs from each condition and effort (mousing over items shows bootstrap covariance, 50% uncertainty , and there's some attempt at making like things similar colors, e.g., blue-ish for formal methods, green-ish for property-based testing, etc.): One thing we can see is that nothing really wildly outperforms. However, Default (no additional instructions) does well above average. Looking at xhigh, on average, the fuzzing and PBT-related conditions did a little better than formal methods on average, with the situation being a lot more mixed at medium. The testing-related skills codex recommended we try underperformed, although our quick custom skill did ok (a major difference is that our skill is designed to nudge away from their default behavior towards more productive behaviors whereas the other skills seem more like tutorials). TDD didn't do well, as predicted (one skill also suggested that agents used TDD, and that skill also fared poorly in the cases where agents attempted to follow the instruction). If we actually look at what agents did, it quickly becomes apparent that, in general, agents don't know how to use these tools or techniques very well. As we noted here , and as everybody I've talked to has also noted, agents are really bad at testing and don't seem to understand how to test reasonably "by default". For example, here's a comment by Gary Bernhardt : AI agents' approach to testing, more or less: Take the pathological cases dreamed up by someone objecting to mocks 15 years ago, without ever having actually used mocks. Naive dreams of excessive mocking. Make those pathologies the backbone of your testing strategy. It turns out, if you ask agents to use a particular test technique or test library, this approach doesn't change as much as you'd hope. We'll look at what happened in cases in more detail, but at a high level, with test techniques, agents tend to either just write the tests they would normally write, but inside a framework for a different type of test technique, or they'll use a technique superficially but not really do the things that get the value out of the technique. For the most part, when a technique was named, they did what Gary described, but with respect to that technique (for example, for formal methods, they mostly proved irrelevant properties and with property-based testing, agents would lean heavily on totally random inputs and heavily hit invalid/rejection cases or find a trivial property to check and run low-value random cases against the trivial property). Results weren't materially different on the IMAP RFC (where I tried 40 runs of each condition) or other random RFCs (where I tried a few individual runs). In general, regardless of the type of probl