유용한 첫 AI 작업을 고르세요

검증할 수 있는 작업을 고르세요

첫 작업에서는 도구가 여러분의 환경에서 어떻게 작동하는지 배울 수 있어야 합니다. 직접 확인할 결과도 나와야 합니다. 알려진 결함을 작게 수정하면 두 조건을 모두 충족하는 경우가 많습니다.

인상적인 데모를 만들 수 있다는 이유만으로 작업을 고르지 마세요. 대규모 재설계는 눈에 보이는 많은 변경 뒤에 잘못된 가정을 숨길 수 있습니다. 작은 작업으로도 에이전트가 지침을 읽고 범위를 지키며 실패한 검사를 정확히 보고하는지 확인할 수 있습니다.

가장 쉬운 작업을 고를 필요는 없습니다. 팀이 올바른 결과를 알아보고 왜 올바른지 설명할 수 있는 작업을 고르세요.

보고 애플리케이션의 가상 요청 세 가지를 살펴보세요.

설명 작업으로 추론과 증거를 살펴볼 수 있습니다. 회귀 테스트는 통제된 작업을 추가합니다. 아키텍처 작업도 나중에는 유용할 수 있지만 훨씬 탄탄한 작업 설명과 검토 절차가 필요합니다.

첫 실습에는 회귀 테스트를 고르세요. 가상 날짜와 로컬 브랜치를 사용하세요. 프로덕션 접근, 의존성 업그레이드, 관련 없는 리팩터링은 범위 밖이라고 명시하세요.

“날짜 처리를 개선하세요”는 해석의 여지가 너무 많습니다. 구체적인 조건을 쓰세요. “입력에 유효하지 않은 달력 날짜가 있으면 검증 오류를 반환하세요. 유효한 날짜에는 문서화된 출력을 유지하세요.”

유효한 입력과 잘못된 입력의 예시를 추가하세요. 기존 테스트 명령을 확인하세요. 에이전트가 파일을 바꾸기 전에 현재 동작을 조사하도록 하세요. 변경 후 결함과 증거를 짧게 설명하도록 요구하세요.

작업 결과와 활동을 구분하세요. “에이전트가 테스트를 작성했다”는 활동입니다. “테스트가 알려진 결함을 탐지한다”는 증거입니다. 올바른 코드와 잘못된 코드에서 모두 통과하는 테스트는 의도한 보호를 입증하지 않습니다.

실습 중 에이전트가 추가 맥락을 필요로 하는 지점을 기록하세요. 관련 저장소 지침을 읽는지 확인하세요. 범위 밖 파일을 바꾸거나 새 증거 없이 실패한 접근을 반복하는지 살펴보세요.

사소한 선택마다 즉시 고치지 마세요. 허용된 되돌릴 수 있는 작업을 완료하게 하고 결과를 평가하세요. 다음 행동이 경계를 넘거나 해결되지 않은 요구사항 때문에 작업을 계속할 수 없으면 개입하세요.

완료되면 diff를 검토하고 관련 검사를 실행하세요. 에이전트의 소요 시간과 여러분의 준비 및 검토 시간을 모두 기록하세요. 이 관찰로 다음 작업을 고르고 작업 지침을 개선할 수 있습니다.

실습이 성공하면 복잡성의 한 요소를 늘리세요. 함수 하나에서 관련 모듈 두 개로 넓힐 수 있습니다. 문서화된 통합을 추가할 수도 있습니다. 권한과 검증 요구사항은 명확히 유지하세요.

실습이 실패하면 범위를 넓히기 전에 원인을 찾으세요. 빠진 맥락, 불명확한 요구사항, 사용할 수 없는 테스트 환경, 모델의 한계는 서로 다른 수정이 필요합니다. 자율성을 늘린다고 네 문제가 모두 해결되지는 않습니다.

프로토타입을 계속 쓰면 유지보수 담당자를 지정하세요. 코드 변경 없이도 새로운 취약점 정보 때문에 조치가 필요할 수 있습니다. 지속적인 취약점 관리를 참고하세요.