Here be monsters: What do you still need to know when agents do the work?

사건: CI가 깨졌다

작성자는 에이전트 워크플로를 잘 다듬어서, 에이전트가 테스트가 실패하는 브랜치를 커밋하면 놀랄 정도라고 해요. 그런데 CI가 실패했어요. 원인은 SonarQube가 App.tsx의 순환 복잡도(cyclomatic complexity)를 지적한 것이었어요.

• App.tsx는 30줄 정도인데, 그중 15줄이 Codex가 컴포넌트 하나를 한 줄로 몰아 쓴 것이었어요.
• 포매터만 돌리면 될 일 같았지만, 각 컴포넌트에 표시·비즈니스 로직이 꽤 많아 복잡도 문제는 그대로였어요.
• 예전의 작성자라면 조심스럽게 리팩터링해 읽기 쉽게 만들었겠지만, Codex는 개의치 않고 여러 기능을 거치며 그 파일을 잘 고쳐 왔어요.

직접 들여다보니 Codex가 엣지 케이스를 보통 개발자보다 더 챙기고 약간 과설계했지만, 전부 맞았고 복잡도도 비즈니스 요구에 따른 것이었어요. Codex에게 SonarQube를 만족시키라고 하자 10개 파일로 나눴고 CI가 통과했어요. 작성자는 이번엔 쉽게 끝났지만 한 번도 본 적 없는 코드였다는 점에서 훨씬 나쁘게 흘러갈 수도 있었다고 말해요.

핵심 주장

소프트웨어 시스템을 소유하는 일은 그것을 손으로 짰는지에 훨씬 덜 의존하게 될 거예요. 대신 뭔가 잘못됐을 때 알아챌 만큼만 알고, 필요할 때 필요한 만큼 깊이 들어갈 의지와 능력이 가장 중요해져요.

비유: 다이브봇과 금덩이

바다 밑의 금덩이를 줍는 일에 비유해요. 예전엔 직접 잠수해 금을 주웠고, 얕은 바다의 금이 줄자 엔지니어들이 더 깊고 위험한 곳에서 캐낼 장비와 도구를 만들어 직접 조립·유지했어요. 글은 이제 그 일을 '다이브봇'(에이전트)이 대신하는 상황으로 이야기를 이어가요.

원문 앞부분(사례와 핵심 주장, 비유의 시작)을 기준으로 옮겼어요. 비유의 뒷부분과 결론은 다 읽지 못했어요.