6개월 동안 코드를 직접 쓰지 않고 AI 에이전트로만 개발한 후기
Six Months of Writing Code Exclusively with Agents
저자는 2월부터 손으로 코드를 쓰지 않기로 결심하고 6개월간 AI 에이전트만으로 개발을 진행했다. 처음에는 에이전트가 생성한 코드를 검토하고 수정하는 데 시간을 썼지만, 모델이 좋아지면서 에이전트가 더 큰 변경을 처리할 수 있게 되었다. 이후 여러 에이전트를 병렬로 실행하면서 발생하는 충돌 문제를 해결하기 위해 exe.dev의 Linux VM을 도입했고, 각 작업에 별도 VM을 할당했다. 또한 에이전트 관리 도구 botd를 직접 만들어 모바일에서도 에이전트를 관리하고 대화를 보존할 수 있게 했다. 에이전트가 외부 서비스에 접근할 때는 프록시를 통해 자격 증명을 숨기고, 읽기 전용 접근을 허용하는 등 보안을 강화했다. 하지만 에이전트가 만든 변경 사항을 검토하고 이해하는 과정은 여전히 어려웠으며, 때로는 에이전트가 완벽하게 작업했음에도 시스템에 불필요한 복잡성을 추가한다고 판단해 변경을 폐기하기도 했다. 결론적으로, 에이전트가 코드를 대신 작성하지만, 무엇을 만들지 결정하고 검토하는 것은 여전히 인간의 몫이라는 것을 강조한다.
에이전트가 코드를 대신 작성하지만, 무엇을 만들지 결정하고 검토하는 것은 여전히 인간의 몫이다.
HN 토론
105- greenowl
나는 한동안 완전 에이전트 방식에 전념했다. 손으로 코드를 전혀 쓰지 않고!
도구의 '능력'은 제쳐두고, 몇 달쯤 지나서야 이게 잘못된 방향이라는 걸 알았다. 특히 큰 기능을 구현하는 동안 5시간 창에 대한 토큰이 다 떨어져서 혼자서는 계속할 수 없었던 때가 기억난다. 대부분 게으름 때문이었지만(그냥 내일 한도가 리셋될 때까지 기다리면 되지!), 동시에 기술 부패/위축이 시작되는 첫 번째 큰 신호를 느꼈고, 그게 불편하게 만들었다.
나는 이 완전 에이전트 방식이 장기적으로 잘 될 거라고 보지 않는다. 궁극의 의존성에 대해 말해보자!! 어떤 이유로든 '불이 꺼지면' - 중단, 비용 증가, 또는 에이전트 속도가 마침내 복잡성 임계점에 도달해서 시스템에 대한 통제력과 이해를 잃어 에이전트가 상황을 악화시키는 경우, 뭐든 간에 - 정말로 시계를 되돌려서 실제로 코드를 작성하던 때의 생산성 수준과 산출물로 다시 들어갈 수 있을 거라고 기대하는가?
- lostnfound8778
> 더 큰 비용은 타이핑이었다. 무언가를 만들고 싶을 때마다 코드가 머릿속에 보였다. 그저 충분히 빨리 타이핑할 수 없을 뿐이었다.
사실이다. 나에게는 머릿속에 보이는 것과 손가락이 물리적으로 그것을 현실로 만들 수 있는 속도 사이의 격차가 클수록 더 많은 스트레스를 느꼈고, 일부 마라톤 코딩 세션은 긴장 때문에 등이 완전히 망가진 채로 끝나곤 했다.
- thisisauserid
그리고 LLM 이전에는 점심시간에 20줄짜리 bash 스크립트와 cron 작업을 대충 만들고, 6개월 동안 다른 일을 했을 것이다.
- redlewel
사람들은 어떻게 이런 AI 냄새가 나는 글을 읽는 걸까? 나는 두세 문장 이상 읽을 수가 없었다.
- mrothroc
여기 몇몇 댓글이 핵심 문제를 다룬다: 에이전트가 우리가 검토할 수 있는 것보다 더 많은 코드를 작성하고 있다. 시니어들은 항상 검토할 시간이 부족했고, 코딩 에이전트의 엄청난 산출물이 상황을 악화시키고 있다. 게다가 코드는 거의 항상 좋다. 그래서 꽤 괜찮은 코드의 쓰나미를 검토하게 되고, 검토 피로가 생겨서 전체가 그냥 쇼가 되어버린다.
나에게 이것은 검사가 단순히 '내가 봤다' 이상이어야 한다는 것을 의미한다. 내가 그것을 보기 전에 두 가지 일이 일어난다: 첫째, 다른 사람들이 언급했듯이, 나는 다른 계열의 모델이 잘 정의된 기준으로 그것을 검토하게 한다. 같은 계열의 검토자는 편향을 공유하므로, 다른 계열이어야 한다. 둘째, 나는 실행되어야 하는 핵심 결정적 게이트(린트뿐만 아니라 단위 테스트도)를 가지고 있다. 어느 경우든 실패는 코딩 에이전트로 돌아간다.
그리고 나서야 나는 신경을 쓴다. 하지만 나는 정말 모든 것을 읽지 않는다. 평범한 CRUD 작업이라면 에이전트가 꽤 잘한다. 특히 성숙한 패키지를 사용한다면 말이다. 나는 권한을 어떻게 강제하는지 같은 중요한 것에 집중한다.
이것은 나에게 잘 작동하지만, 한 가지 주요 문제는 건드리지 않은 채로 남는다: 이것이 구축할 가치가 있는지. 에이전트는 약간 지나치게 열성적인 경향이 있어서, 산출물이 가치를 더할지 확인하기 위해 사전에 많은 작업을 해야 한다. 게이트는 산출물만 확인할 수 있고, 내 의도는 확인할 수 없다.
- iamflimflam1
LLM으로 코드를 작성하는 것은 훈련이 필요하고 어렵다. 그것을 하는 방법과 그것으로부터 최선을 얻는 방법을 배워야 한다.
소프트웨어 엔지니어링은 죽었다, 소프트웨어 엔지니어링 만세!
- rich_sasha
나는 이 모든 설명들과 정말 이상한 불협화음을 느낀다. 나는 직장에서 Cursor를 통해 최고 수준의 모델에 접근할 수 있다. 매번 나는 스스로에게 말한다, 여기 지루하지만 잘 정의된 작업이 있고, 명확한 성공 기준이 있으며, 지속적인 반복으로 많은 것을 성취할 수 있다. 그것을 Claude에게 맡기자.
첫째, 작업을 제대로 설명하는 데 오랜 시간이 걸린다. 이 모든 명확한 성공 기준, 음, 머릿속의 명확한 사양에서 코드를 작성하는 대신, 나는 수많은 산문을 쓰고 그것을 모호하지 않게 만들려고 노력한다. 나는 English++로 프로그래밍하고 있다.
하지만 그런 다음, 5번 중 1번은 어느 정도 작동하는 것을 만들어낸다. 완벽하지는 않지만 충분히 괜찮을 수도 있다. 5번 중 2번은 대충 괜찮아 보이지만 실제로는 사양의 80%를 무시하거나 주석에서 최소한의 형식적인 언급만 한다.
그리고 때로는, 아마도 5번 중 2번보다 약간 적을 수도 있는데, 완전히 엉망으로 분기한다. 이유 없이 메인 스크립트의 AST를 로드하고 피클한 다음 base64로 직렬화하는 스크립트를 작성하기 시작한다. 문자열에 어떤 것들을 인코딩한 다음 문자열 비교를 위해 ord(string[i])를 반복적으로 확인한다. 결국 컨텍스트가 부족해져서 LLM에 해당하는 심각한 치매가 발생한다.
나는 '야 컴퓨터 이거 써'라고 말하면 그게 시간을 잘 쓰는 것이라고 말하는 사람들과 내 경험을 정말로 조화시킬 수 없다.
- phildenhoff
그렇지 않으면 좋은 글이 AI 말투로 채워진 것을 보는 것은 유감이다("하지만 여기 반전이 있습니다: 제가 앞서 설명한 그 검색은 결코 botd로 전송되지 않았습니다. 모든 기록은 SQLite에 있었고, 그래서 저는 다른 에이전트를 그것에 지정했고 어쨌든 분석을 얻었습니다. 도구는 죽었지만 데이터는 죽지 않았습니다.", 다른 예들 중에서).
Maisem Ali는 코드 생산을 AI에 넘겼음에도 불구하고 엔지니어링을 멈추지 않았다고 쓴다. 나는 그것이 몇 가지 이유로 흥미로운 관점이라고 생각하지만, 무엇보다도 나는 동의하지 않을 수도 있다.
첫째, 우리는 그것이 어떻게 폭발할 수 있는지에 대한 훌륭한 예를 본다. "botd가 이번 달에 죽었습니다. 그것은 자신의 무게로 무너졌습니다." 에이전트 하네스(또는 다른 하네스 위의 오버레이인가?)가 순수한 기술적 복잡성으로 자신의 무게로 무너질 수 있다고 상상하기 어렵다. 이와 같은 도구가 '무너진다'는 것은 무엇을 의미하는가? 제대로 아키텍처가 설계되었다면, 어떤 외부 변화도 적응할 수 있을 것 같다. 실패하는 테스트는 고칠 수 있다.
이 AI 코딩 진화는 우리가 내부 작동을 이해하지 못하는 프로토타입을 빠르게 만들 수 있는 능력을 주었지만, 나는 가치 있는 것(그리고 botd는 Maisem에게 가치가 있었던 것으로 보인다고 주장한다)에 대해서는 적어도 우리가 구축하는 것의 아키텍처와 엔지니어링을 이해하고 영향을 미쳐야 한다고 믿는다. Maisem이 botd에 대해 그렇게 했다면, 그것은 '자신의 무게로 무너지지' 않았을 것이고 _그럴 수 없었을_ 것이다. botd 내부에 변화를 요구한 어떤 외부 영향도 관리할 수 있었을 것이다.
둘째, 이 글의 생산을 외부로 위임한 것은 [...]를 나타낸다.