원문: https://github.com/facebook/astryx/wiki/Required-Props-Pattern · 번역 기준: 2026-09-03
Exploration — 2026년 1월
모든 컴포넌트 prop을 required로 만들면(기본값 없음) AI 코드 생성이 개선되는지 탐구합니다. 가설: 명시적인 API가 더 "vibe-able"합니다. 모든 예제가 모든 prop을 보여주고, 에러가 더 actionable하기 때문입니다.
명시적이고 상세한 컴파일러 에러 덕분에 LLM 친화적이라는 Rust의 평판에서 영감을 받았습니다.
모든 것이 required이기 때문이 아니라 — 에러가 명시적이고 actionable하기 때문입니다.
Microsoft의 RustAssistant는 Rust 컴파일 에러를 고치는 데 74% 정확도를 달성했는데, 이는 컴파일러가 다음을 제공하기 때문입니다:
이는 빠른 iterate-until-correct 루프를 가능하게 합니다. LLM은 무엇이 잘못되었고 어떻게 고쳐야 하는지 정확히 압니다.
출처: RustAssistant: Using LLMs to Fix Compilation Errors in Rust Code
| 이점 | 설명 |
|---|---|
| Actionable한 에러 | "Missing prop X"는 구체적입니다; 조용히 잘못 적용되는 기본값은 그렇지 않습니다 |
| 완전한 예제 | 모든 사용 예가 모든 prop을 보여줍니다 — 숨겨진 동작이 없습니다 |
| 의도의 강제 | 암묵적 기본값에 우연히 의존할 수 없습니다 |
| 학습 데이터 품질 | LLM은 완전한 명세로부터 학습합니다 |
| 우려 | 설명 |
|---|---|
| LLM은 디테일에 약함 | 연구에 따르면 모델은 "prompt의 디테일을 놓칩니다" — required prop이 많을수록 놓칠 것도 많아집니다 |
| 직접적인 연구 없음 | 전부-required와 optional을 LLM 정확도 관점에서 비교한 연구를 찾지 못했습니다 |
| 인간 DX 비용 | 합리적인 기본값은 인간의 결정 피로를 줄여줍니다 |
| Rust는 builder를 씀 | Rust조차 optional 필드에는 builder 패턴을 사용합니다 |
LLM 실패 분석에서 얻은 핵심 발견: