Adam은 2026년 7월 28일 개발자 커뮤니티가 AI 도구 사용 여부가 아니라 엔지니어링 품질로 AI 보조 프로젝트를 판단해야 한다고 주장했다. 이 의견은 기여자를 찾던 Madsen의 Open Vectorizer 게시물이 AI의 도움을 받았다는 이유로 일부 문지기들에게 의심스럽게 취급된 데서 출발했다. Adam은 현재의 필터가 흔히 “AI냐 아니냐”라는 이분법으로 검토를 축소하지만, 그 라벨만으로는 프로젝트가 테스트됐는지, 유지보수되는지, 재현 가능한지, 책임 있게 관리되는지 알 수 없다고 말했다.

Adam은 문제를 설명하기 위해 2개의 가상 프로젝트를 대비했다. 프로젝트 A는 2년 동안 벡터화 알고리즘을 다시 설계하고, 머신러닝을 검토한 뒤 배제하며, 결정론적 접근을 구현하고, 자체 벤치마크가 부풀려졌다는 사실을 발견해 수정한 뒤 재현 가능한 결과를 공개하고 코드를 유지한다. 프로젝트 B는 AI에 “음악 스트리밍 앱을 만들어 달라”고 요청한 뒤 테스트되지 않은 결과물을 공개하고 사라진다. Adam은 두 프로젝트 모두 “AI-generated”라는 라벨이 붙을 수 있지만, 커뮤니티가 거부해야 할 저노력 작업에 해당하는 것은 두 번째뿐이라고 말했다.

Adam은 검증되지 않은 AI 생성 코드가 보안 취약점을 만들 수 있고, AI가 저노력 게시를 더 쉽고 저렴하게 만든다는 점은 인정했다. 다만 그의 반론은 기술 검토 전에 일괄적으로 거부하는 방식에 있다. 그는 이를 프로그래밍 언어 선택에 비유하며, Rust는 일부 메모리 안전성 위험을 줄일 수 있고 C는 메모리 오류를 가능하게 할 수 있지만 언어만으로 프로젝트가 좋은 엔지니어링인지 결정되지는 않는다고 설명했다.

Adam은 더 나은 검토 질문이 어렵지만 더 유용하다고 말했다. 유지관리자가 아키텍처를 설명할 수 있는지, 의미 있는 테스트가 있는지, 주장을 독립적으로 재현할 수 있는지, 벤치마크가 투명한지, 약점이 공개됐는지, 변경 사항이 검토되는지, 프로젝트가 6개월 뒤에도 유지될 것인지가 핵심이라는 것이다. 그는 이런 기준이 사람이 작성한 코드, AI 생성 코드, 혼합 코드에 똑같이 적용된다고 말했다.

해당 글은 @unitbuilds의 발언을 인용해 소프트웨어 개발의 가치는 사람이 타이핑한 시간만이 아니라 작동하고, 감사됐으며, 테스트된 소프트웨어에 있다고 전했다. Adam은 이 관점으로 개발자 커뮤니티가 작업을 공유하고 실질적 피드백을 받는 공간이어야 한다고 옹호했다. 여기에는 정규직으로 일하면서 99% AI를 사용해 3000줄짜리 게임을 출시한 사람, 반복적인 자동 완성에 GitHub Copilot을 쓰는 사람, AI 도움을 받아 아키텍처 결정을 내린 Open Vectorizer 작성자가 모두 포함된다.

Adam은 AI 보조를 소프트웨어 개발에서 추상화가 확장돼 온 긴 역사 안에 놓았다. 어셈블리에서 C로, 수동 메모리 관리에서 가비지 컬렉션으로, 원시 SQL에서 ORM으로, 손으로 쓴 Dockerfile에서 템플릿으로, Stack Overflow 복사·붙여넣기, IDE 리팩터링, GitHub Copilot 자동완성으로 이어지는 흐름이라는 설명이다. 그는 일관된 기준은 개발자가 생성된 결과물을 이해하고, 방어하고, 유지할 수 있는지여야 한다고 말했다.

Adam은 좋은 조정 방식이 상당한 AI 관여를 공개하도록 요구하고, 재현성, 테스트 범위, 유지관리자 책임성을 평가해야 한다고 말했다. 공개 벤치마크나 적극적인 버그 해결이 있는 프로젝트는 빠르게 검토하고, 얕은 작업은 출처가 아니라 깊이 부족을 근거로 거부해야 한다는 것이다. Adam은 DEV가 AI 보조 콘텐츠를 금지하는 대신 공개를 요구하는 방향으로 움직인 점을 더 나은 접근으로 평가했으며, 그 방식은 창작자에게 정직성을 요구하고 커뮤니티가 실제 작업물을 평가하게 한다고 말했다.

Adam은 2026년 7월 28일 개발자 커뮤니티가 AI 도구 사용 여부가 아니라 엔지니어링 품질로 AI 보조 프로젝트를 판단해야 한다고 주장했다. 이 의견은 기여자를 찾던 Madsen의 Open Vectorizer 게시물이 AI의 도움을 받았다는 이유로 일부 문지기들에게 의심스럽게 취급된 데서 출발했다. Adam은 현재의 필터가 흔히 “AI냐 아니냐”라는 이분법으로 검토를 축소하지만, 그 라벨만으로는 프로젝트가 테스트됐는지, 유지보수되는지, 재현 가능한지, 책임 있게 관리되는지 알 수 없다고 말했다.

Adam은 문제를 설명하기 위해 2개의 가상 프로젝트를 대비했다. 프로젝트 A는 2년 동안 벡터화 알고리즘을 다시 설계하고, 머신러닝을 검토한 뒤 배제하며, 결정론적 접근을 구현하고, 자체 벤치마크가 부풀려졌다는 사실을 발견해 수정한 뒤 재현 가능한 결과를 공개하고 코드를 유지한다. 프로젝트 B는 AI에 “음악 스트리밍 앱을 만들어 달라”고 요청한 뒤 테스트되지 않은 결과물을 공개하고 사라진다. Adam은 두 프로젝트 모두 “AI-generated”라는 라벨이 붙을 수 있지만, 커뮤니티가 거부해야 할 저노력 작업에 해당하는 것은 두 번째뿐이라고 말했다.

Adam은 검증되지 않은 AI 생성 코드가 보안 취약점을 만들 수 있고, AI가 저노력 게시를 더 쉽고 저렴하게 만든다는 점은 인정했다. 다만 그의 반론은 기술 검토 전에 일괄적으로 거부하는 방식에 있다. 그는 이를 프로그래밍 언어 선택에 비유하며, Rust는 일부 메모리 안전성 위험을 줄일 수 있고 C는 메모리 오류를 가능하게 할 수 있지만 언어만으로 프로젝트가 좋은 엔지니어링인지 결정되지는 않는다고 설명했다.

Adam은 더 나은 검토 질문이 어렵지만 더 유용하다고 말했다. 유지관리자가 아키텍처를 설명할 수 있는지, 의미 있는 테스트가 있는지, 주장을 독립적으로 재현할 수 있는지, 벤치마크가 투명한지, 약점이 공개됐는지, 변경 사항이 검토되는지, 프로젝트가 6개월 뒤에도 유지될 것인지가 핵심이라는 것이다. 그는 이런 기준이 사람이 작성한 코드, AI 생성 코드, 혼합 코드에 똑같이 적용된다고 말했다.

해당 글은 @unitbuilds의 발언을 인용해 소프트웨어 개발의 가치는 사람이 타이핑한 시간만이 아니라 작동하고, 감사됐으며, 테스트된 소프트웨어에 있다고 전했다. Adam은 이 관점으로 개발자 커뮤니티가 작업을 공유하고 실질적 피드백을 받는 공간이어야 한다고 옹호했다. 여기에는 정규직으로 일하면서 99% AI를 사용해 3000줄짜리 게임을 출시한 사람, 반복적인 자동 완성에 GitHub Copilot을 쓰는 사람, AI 도움을 받아 아키텍처 결정을 내린 Open Vectorizer 작성자가 모두 포함된다.

Adam은 AI 보조를 소프트웨어 개발에서 추상화가 확장돼 온 긴 역사 안에 놓았다. 어셈블리에서 C로, 수동 메모리 관리에서 가비지 컬렉션으로, 원시 SQL에서 ORM으로, 손으로 쓴 Dockerfile에서 템플릿으로, Stack Overflow 복사·붙여넣기, IDE 리팩터링, GitHub Copilot 자동완성으로 이어지는 흐름이라는 설명이다. 그는 일관된 기준은 개발자가 생성된 결과물을 이해하고, 방어하고, 유지할 수 있는지여야 한다고 말했다.

Adam은 좋은 조정 방식이 상당한 AI 관여를 공개하도록 요구하고, 재현성, 테스트 범위, 유지관리자 책임성을 평가해야 한다고 말했다. 공개 벤치마크나 적극적인 버그 해결이 있는 프로젝트는 빠르게 검토하고, 얕은 작업은 출처가 아니라 깊이 부족을 근거로 거부해야 한다는 것이다. Adam은 DEV가 AI 보조 콘텐츠를 금지하는 대신 공개를 요구하는 방향으로 움직인 점을 더 나은 접근으로 평가했으며, 그 방식은 창작자에게 정직성을 요구하고 커뮤니티가 실제 작업물을 평가하게 한다고 말했다.