AI 교정은 자신감 있게 들린다고 해서 신뢰할 수 있는 것이 아닙니다. 이미 생산 변경을 안전하게 만드는 엔지니어링 작업 부분(증거, 소유권, 검토, 테스트 및 명확한 병합 결정)을 보존할 때 신뢰할 수 있게 됩니다.
그 구별이 중요합니다. 올바른 컨텍스트로 풀 요청을 여는 도구는 시간을 절약할 수 있습니다. 프로덕션 코드를 자동으로 변경하는 도구는 팀에게 새로운 운영 위험을 수용하도록 요청합니다.
경계부터 시작하세요
첫 번째 디자인 결정은 어떤 모델을 사용할지 결정하는 것이 아닙니다. 모델에게 허용되는 작업입니다.
대부분의 팀에서 안전 경계는 다음과 같습니다.
- AI는 생산 신호를 검사할 수 있습니다.
- AI는 이러한 신호를 코드에 매핑할 수 있습니다.
- AI는 패치 초안을 작성할 수 있습니다.
- AI는 자신의 추론을 설명할 수 있습니다.
- 엔지니어는 승인, 편집, 거부 또는 병합합니다.
이는 여전히 강력한 작업 흐름입니다. 이는 시스템을 소유한 사람들로부터 책임을 옮기지 않으면서 사건 대응의 지루한 부분을 제거합니다.
"그냥 고치세요"가 잘못된 기본값인 이유
생산 실패는 지저분합니다. 동일한 오류는 잘못된 배포, 가드레일 누락, 역압이 필요한 대기열, 고객 데이터 엣지 케이스 또는 예상과 다르게 작동하는 업스트림 공급자를 의미할 수 있습니다.
시스템이 증상에서 코드 변경으로 바로 이동하면 검토자는 조사 없이 패치를 받습니다. 패치가 존재하는 이유를 리버스 엔지니어링해야 합니다. 이로 인해 검토 속도가 느려지고 코드가 합리적이더라도 자동화가 위험하다고 느끼게 됩니다.
더 나은 기본값은 증거 우선입니다.
프로덕션 동작을 표시하고, 의심되는 코드 경로를 표시하고, 제안된 변경 사항을 표시하고, 무엇이 잘못되었을 수 있는지 보여줍니다.
마지막 부분이 중요합니다. 교정 시스템은 증거가 부분적일 때 확실성을 가장해서는 안 됩니다. 불확실성을 가시화해야 합니다.
인간을 유지해야 하는 제어점
팀이 일반적인 작업 흐름에서 유지해야 할 몇 가지 결정이 있습니다.
소유권 및 범위
올바른 코드 소유자는 제안된 수정 사항이 서비스 경계에 맞는지 여부를 결정해야 합니다. 이는 좁은 사건이 광범위한 아키텍처 변경으로 변하는 것을 방지합니다.
제품 판단
일부 오류는 기술적으로 패치하기 쉽지만 제품에 민감합니다. 결제 재시도 버그, 권한 예외 사례 또는 청구서 수신 상태 불일치로 인해 코드가 변경되기 전에 제품 컨텍스트가 필요할 수 있습니다.
자신감 테스트
AI는 테스트를 제안할 수 있지만 엔지니어는 자신감이 무엇을 의미하는지 결정해야 합니다. 한 가지 수정에는 단위 테스트가 필요합니다. 또 다른 이벤트는 재생된 이벤트가 필요합니다. 다른 하나는 마이그레이션 확인과 롤백 경로가 필요합니다.
병합 승인
병합 결정은 팀의 기존 풀 요청 프로세스에 계속 표시되어야 합니다. 이를 통해 보안, 규정 준수 및 소유권 정책이 그대로 유지됩니다.
AI가 반드시 해야 할 일
사람의 승인을 유지한다고 해서 작업 흐름이 소심하다는 의미는 아닙니다. AI는 인간이 너무 자주 반복하는 작업을 대신해야 합니다.
- 5개의 개별 조사를 시작하는 대신 유사한 오류 이벤트를 클러스터링합니다.
- 스택 추적과 시끄러운 로그를 읽을 수 있는 하나의 사건 메모로 요약
- 가장 관련성이 높은 저장소, 파일, 기능 및 소유자 찾기
- 최근 배포 및 코드 변경 사항과 실패 비교
- 평범한 영어 설명으로 최소한의 패치 초안 작성
- 제안된 테스트 또는 검토 확인 추가
- 비코드 후속 조치를 Jira, Linear 또는 GitHub 문제로 라우팅
이것이 시간 절약의 원천입니다. 검토자는 단절된 신호 더미 대신 준비된 사례 파일로 시작합니다.
풀 요청은 인터페이스입니다
엔지니어링 팀의 경우 끌어오기 요청은 이미 위험을 협상하는 장소입니다. 차이점, 설명, CI, 소유권, 승인 내역이 포함되어 있습니다. AI 교정은 새 표면을 만드는 대신 해당 표면을 사용해야 합니다.
유용한 교정 PR에는 다음이 포함되어야 합니다.
- 조사를 촉발한 생산 신호입니다.
- 시스템이 책임이 있다고 믿는 코드 경로입니다.
- 제안된 패치.
- 패치의 이유.
- 실행되었거나 실행되어야 하는 테스트입니다.
- 신뢰 수준 및 가정.
이러한 구조는 리뷰어에게 평가할 구체적인 내용을 제공합니다. 그들은 진단에 동의하지 않거나, 패치를 개선하거나, 증거가 강력할 때 신속하게 병합할 수 있습니다.
간단한 정책 모델
팀은 세 가지 정책 수준으로 시작할 수 있습니다.
초안 전용
시스템은 끌어오기 요청을 생성할 수 있지만 자동으로 검토를 요청할 수는 없습니다. 이는 신호 품질을 평가하는 팀에게 좋은 첫 번째 단계입니다.
검토 준비 완료
증거가 확실할 경우 시스템은 끌어오기 요청을 열고, 소유자를 할당하고, 검토를 요청할 수 있습니다. 이는 대부분의 팀이 목표로 삼아야 할 기본값입니다.
제한된 변경 사항 자동 병합
시스템은 엄격한 정책과 일치하는 범위가 좁고 되돌릴 수 있는 변경 사항만 병합할 수 있습니다. 이는 드물고 기록되어야 하며 비활성화하기 쉬워야 합니다.
대부분의 조직은 레벨 3에서 시작할 필요가 없습니다. 비용이 많이 드는 부분은 진단과 초안인 경우가 많기 때문에 레벨 2에서 의미 있는 가치를 얻습니다.
거짓된 자신감을 조심하라
실패 모드는 추상적으로 "AI가 잘못된 코드를 작성합니다"가 아닙니다. 더 날카로운 실패 모드는 얇은 증거가 있는 세련된 패치입니다.
검토자는 시스템이 근본 원인을 찾았는지 아니면 단순히 근처 파일을 찾았는지 알 수 있어야 합니다. 좋은 작업 흐름은 생산 신호부터 코드 변경까지 체인을 노출합니다. 약한 작업 흐름은 자신감 있는 요약 뒤에 해당 체인을 숨깁니다.
증거가 약한 경우 도구는 그렇게 말하고 문제를 수정이 아닌 조사로 전달해야 합니다.
어떤게 좋아 보이는지
좋은 AI 교정은 수석 엔지니어가 검토 전에 준비 작업을 한 것처럼 느껴집니다. 풀 요청은 마술이 아닙니다. 비정상적으로 잘 조립되어 있습니다.
- 문제가 중복 제거되었습니다
- 관련 로그가 요약되어 있습니다.
- 코드 경로의 이름은 다음과 같습니다.
- 패치가 작아요
- 추론이 눈에 보인다
- 리뷰어는 여전히 책임을 맡고 있습니다.
그것이 균형이다. AI가 조사를 압축하도록 하세요. 엔지니어링 판단이 지워지지 않도록 하십시오.
