블로그 글에는 여러 차트가 있어서 객관성과 엄격함이 있는 것처럼 보이지만, 실제로는 느낌과 추측뿐임을 강조함. 최근 실증 연구들은 오히려 AI가 불평등을 악화시키는 방향을 보여줌. 이코노미스트의 그래프와 기사에서 관련 내용을 확인할 수 있음
당연히 AI가 불평등을 심화시킨다는 생각임. AI는 사람들이 경험을 쌓아 올라가는 사다리의 하위 단계를 자동화해서, 미래의 전문가가 될 사람들에게 발판을 제공하지 않고, 이미 정상에 있는 사람들이 투자하여 그 사다리를 더 빠르게 올리는 기술이라고 봄
그래프는 너무 큰 가정을 하고 있는데, 이는 AI 극성주의자의 머릿속에서만 뒷받침되는 느낌임. 특히 '사이드 프로젝트' 관련해서는 애매하게 다루고 있는데, AI가 초보의 입력을 받아서 '충분히 괜찮은' 결과를 만들어 내기에 부족하다고 생각함
글의 요지에 어느 정도 공감함. 과학자처럼 실험실 가운을 입은 듯 위장하지만, 사실 자신들이 어떻게 세상을 보는지에 대한 관계성만 표현했을 뿐임. 그래도 그래프에 '가설'임을 명시하거나, 축 끝을 물결선으로 표현하는 등 시각적 방법으로 가설임을 강조하면 커뮤니케이션 수단으로 가치는 있다고 봄. 곡선의 평탄화(숙련도 정체)가 생긴다고 전제하는 것 역시 확신할 수는 없음. 저자는 오히려 경제학자들의 링크보다 더 선의의 글쓰기를 했다고 생각함. 나는 사람들이 솔직한 의견을 드러내고, 데이터가 있으면 가설 검증까지 보여주면 이상적이라고 봄
그래프에는 불평등 증가를 보여주는 연구가 4개, 불평등 감소를 보여주는 연구가 6개 언급됨
은퇴한 수학자 입장에서, 2025년에 AI에 푹 빠지게 됐고 Claude Max 요금제를 써서 제한 없이 Claude Code Opus 4를 사용하고 있음. 병렬 세션으로 방대한 레거시 코드 베이스를 리뷰하면 사용 한도에 닿기도 함. 한동안 AI에 관한 그 어떤 소통도 기피했으나, 최근에는 HN에서 흥미로운 논의들이 보여 다시 관심 가짐. 내 의견으론 신경다양성(neurodivergent)이 있는 사람들이 AI 사용에 더 성공적인데, 이는 AI가 거대한 연상 엔진이기 때문임. 나는 선형대수 전공이니, AI의 연상 구조와 내 독특한 사고방식이 잘 맞음. 결국 AI는 바닥이 아닌 천장을 올리는 효과를 가져옴
Andrew Ng의 최근 AI 스타트업 발표와 비슷한 통찰임. 요즘 창업가들에게 주는 새 조언은, 피벗할 때 프로토타입을 버리고 처음부터 새로 하라는 것임. 이는 본문의 내용과도 연관됨. 프로토타입 개발은 최대 10배 향상되지만, 기존 코드베이스는 30~50% 정도만 개선된다고 함. 이 변화는 과거 VM에서 컨테이너로 옮겨갈 때의 '펫 vs 가축' 비유와 유사함. 코드베이스를 정성스럽게 아끼는 '펫'이 아니라 효율적으로 대하는 '가축'처럼 다뤄야 하는 시대일 수도 있음. 관련 발표 동영상에서 10:30 부분 참고할 수 있음
나의 생각에는 '펫 vs 가축' 비유가 코드에만 집중해서, 진짜 가치는 개발자의 머릿속에 있다는 점을 놓치기 쉬움. AI는 코드 관리는 도와줄 수 있지만, 진정한 가치는 개발자의 이해와 정신적 모델에 있음
좋은 포인트지만, '가축'보다는 '가축(cattle)'이라는 표현을 더 자주 들어봤음. 지리적 차이인지 궁금해짐
이 비유 언급 감사함. 앞으로 생성형 코드를 대규모 클라우드 인프라처럼 다룰 필요가 있을 것 같음. 오랜 세월 써온 레거시 코드에는 덜 적용될 수 있음. 혹시 통찰을 블로그로 정리한 적 있는지 궁금하고, stillpointlab.com 나 @stillpointlab 트위터가 궁금해서 찾아봤으나 자료가 별로 없음
"펫 vs 가축" 비유가 "장인 vs 대충 만드는 사람" 논쟁보다 훨씬 잘 맞는다고 느낌. LLM을 써도 결과물의 가치가 깎이는 게 아니라, 코드에 대한 정서적 애착 대신 실용적으로 바라보는 시각의 전환임
LLM으로는 아직 할 수 없는 일이 꽤 있음. 예를 들어 체스를 같이 두다보면 5~10수 정도 지나면 불법 수를 두기 시작하고, 최고의 경우에도 18수 정도가 한계였음. 상대방의 잘못된 움직임도 바로잡지 않으므로 잘못된 학습이 될 수 있음. 결국 실제로 복잡한 문제를 모델링하지 못하니, 사용자가 무엇을 질문해야 할지 인식하는 것이 매우 중요함. LLM은 나이트의 이동 방법이나 유명한 오프닝 정도는 알려줄 수 있지만, 체스 기보 전체를 올바르게 따라가거나, 현 보드 상황에서 최선의 수를 알려주는 것은 불가능함. 많은 사용자가 얼마나 잘못된 답변이 나올 수 있는지 모르는 채로, 자신있게 뱉는 답변을 그대로 믿을 가능성이 큼. 얼핏 보면 단단해 보이지만, 사실은 보이지 않는 크레바스 위를 걷는 것과 같음
LLM이 체스에 약한 것은 큰 문제라고 생각하지 않음. 체스 전용 모델은 꽤 괜찮은 수준의 ELO로 합법적인 수만 두게끔 할 수 있음. 포스트 트레이닝이 체스 능력을 저해할 수 있고, OpenAI 같은 곳에서도 크게 신경 쓰지 않는 듯함. LLM으로도 체스 잘 둘 수 있음. 관련 논문 및 평가 예시 참고함
나도 주변에 박사나 의사 같은 전문가들이 LLM이 실수할 거라는 건 아예 상상도 못하는 경우를 자주 봄. 환상적이고 논리적인 문장에 자신감까지 더해지니, 완전 전문가라 착각하는 ‘후광 효과’도 있을 것 같음
LLM으로 코드 에이전트 모드에서 작업해보면, 처음엔 잘하다가 점점 엉뚱한 방향으로 흐르기도 하고, 전혀 상관없는 코드 들여쓰기를 시도하는 등 의외의 행동을 많이 목격했음
체스의 경우, 전문 AI는 인간보다 훨씬 뛰어나는데, 반면 범용 LLM은 합법적인 수를 두기도 어렵다는 점이 흥미로움. AI의 천장은 LLM보다 훨씬 높은 위치에 있음
"10수 이상 따라가기 어려움"에 대해, 체스에서는 과거 수보다 현재 보드 상태가 더 중요함. LLM은 불필요한 정보를 거르는 데 약하니, 오히려 보드 상태만 입력하면 성능이 좋아짐. 더 자세한 토론 참고
에이전트가 그린필드 프로젝트에만 좋다면, 기존 코드베이스도 새 기능마다 새로운 그린필드 프로젝트처럼 준비해서, 인턴이 플러그만 꽂으면 동작하도록 해야 함. 나머지 부분은 사람의 손이 필요하고, 그렇지 않으면 인턴이 벽 전체를 다 뜯어버릴 수 있음
말도 안 된다고 생각함. npm의 Y 프로젝트를 WebStorm으로 GitHub에서 받아서 Junie에게 물어보면, 바로 답을 받을 수도 있고, 이해 안 되는 데이터 구조도 예시와 함께 문서화해줌. PR까지 바로 만들 수는 없어도, 페어 프로그래머로 충분히 활용할 수 있음. 오히려 더 많은 테스트를 쓰고 오류 처리도 더 신경 쓰게 되어 최종적으로 더 나은 결과를 만듦
에이전트는 잘하는 것도 많고 못하는 것도 많음. 쓸수록 뭐가 더 잘되는지 헷갈릴 지경임
에이전트가 완전히 새로운 프로젝트 시작은 오히려 별로고, 소~중간 규모 프로젝트에는 매우 좋으며, 크기가 커질수록 점차 효율이 떨어지는 경향이 있다고 생각함. 완전히 새 프로젝트의 경우엔 실제로 써먹을 수 없는 '예제 수준' 코드가 많이 나옴.
나는 'interpolator'를 'intruder'로 착각해서 읽었음. 그렇다면 'extraloper'라는 단어도 있는지 궁금해짐
본문의 대부분에는 동의하지만, "AI가 제공할 수 있는 수준에서 실력 향상이 멈춘다"는 것에는 agree하지 않음. 내 경험상 AI를 잘 쓰려면 '고정적'이 아니라 '성장적' 마인드로, 나는 AI의 매니저처럼 역할 놀이하며 출력을 계속 개선함. 어느 정도 한계는 있지만, 직접 해당 스킬을 배우지 않아도, 문제의 경계에 집중해가며 결과의 품질을 상당히 높일 수 있었음. 시간이 흐를수록 현장 전문가가 되지 않고도, 그 분야의 더 나은 매니저로 성장함을 느끼고 있음
본인이 "어떻게"를 모른다면 품질이 충분히 나아졌다는 걸 무슨 기준으로 아는지 궁금함. 결국 시작 품질과 비교한 상대적 향상일 텐데, 자기 만족만 되면 실제로 품질이 낫지 않아도 상관 없는 걸로 보임
나는 이런 방식이 "치팅"이라고 보지 않음
학습 곡선에서 AI를 쓰다가도, 절정 근처에 이르면 오히려 AI 없이 배우는 경우가 더 좋아질 것임. 최고의 숙련도는 천천히, 자기주도적으로 배우는 시간을 통해서만 가능함
LLM의 가장 큰 장점은 광고나 소셜 미디어에 방해받지 않고, 통일된 포맷으로 정확한 답변을 받을 수 있다는 점임. reddit이나 insta, tvtropes에서 답변을 찾는 것과 정반대임. 생각 도우미로서 완전히 집중할 수 있는 OS와, 자녀가 콘텐츠 함정에 빠지지 않게 도와주는 환경이 빨리 나왔으면 좋겠음. 나는 ad hoc UI에 방해받지 않고 필요한 문서와 정보만 빠르게 받는 게 정말 좋음
나는 AI 답변이 정확하다고 생각하지 않고, 오히려 위험할 정도인 경우가 흔하다고 느낌. 커뮤니티에서는 누가 전문가인지 판단하기 쉽고, 결국 맞는 답변을 얻을 수 있지만, AI 역시 이 데이터를 다 수집했으니 틀린 답을 내놓을 위험도 똑같음. 광고 없는 환경도 얼마 못 갈 것 같음. AI 기업들은 엄청난 적자를 내고 있으니 곧 광고와 소셜 요소가 넘칠 테고, 지금의 무료 혜택은 그냥 고객을 유인하는 손실 보전 전략에 불과함
"정확하다"는 표현이 주관적임을 비꼼
내가 더 잘 아는 AI 분야도 이 흐름과 일치함. 평균 이하인 사람도 AI로 평균에 가까운 결과를 얻을 수 있음
더 많은 지식을 가진 사람이 LLM을 써야 제대로 이득을 본다는 또다른 요약과도 일치함
평균 이상인 사람도 AI를 써서 평범한 결과물을 낼 수 있음. 많은 작업에서 '충분히 괜찮다'의 기준이 오히려 매우 낮음
그래서 여기 있는 사람들이 AI를 반대하는 이유는 다들 평균 이상이라서 그런 것 같다는 농담임
"평균 이하가 AI로 평균 수준의 결과를 내면" 전체 평균도 그만큼 올라가는 셈임
"AI는 프로토타이핑에 좋고, 엔지니어링에는 좋지 않다"고 요약할 수 있을 것 같음. AI 도구는 속도는 빠르지만 breadth(넓이)와 depth(깊이)가 부족함. 빠르게 PoC나 부분 문제 해결에는 유용하지만, 전체 맥락과 깊이는 부족하고, 진정한 엔지니어링은 구현 이상의 훨씬 더 많은 요소(문맥, 예외, 실패 형태, 깊은 이해 등)가 필요함. 아무리 뛰어난 프로그래머여도 엔지니어가 아닐 수 있고, 최고의 leetcoder가 팀에 실질적으로 도움이 안 될 수도 있음. 진짜 마스터리로 가려면 경험이 필요하고, 그건 미묘한 것들(비직관적 요소)까지 알아야 함. 매니저가 버튼 하나로 제품을 엔지니어링할 수 있는 시대는 오지 않겠음. 현재의 AI 코드 생성기도 '매니저용 자동화'라는 착각에서 출발했고, 오히려 현업 엔지니어의 설명을 바탕으로 동작하는 툴이 더 낫다고 생각함. Dijkstra의 "자연어로 프로그래밍하는 어리석음"에 대한 논평이 여전히 유효하다고 봄. 관련 원문
Michael A. Jackson의 Problem Frames Approach, T.S.E Maibaum의 수공학적 수학 기반, Donald Schön의 암묵지(tacit knowledge) 등 기존 사고도 읽어봤음. LLM 기반 프로그래밍은 프로그램 텍스트와 주석에 지나치게 치중된 논의가 많음. 소프트웨어 엔지니어링은 단순히 프로그램 텍스트를 만드는 게 아니고, 응용수학이나 과학에도 국한되지 않는 분야임. AI 에디터에는 이런 암묵지가 많이 내재되어 있다고 보지만, 이런 부분을 좀 더 명확하게 검토하고 논의하는 것이 좋다는 입장임
Hacker News 의견
블로그 글에는 여러 차트가 있어서 객관성과 엄격함이 있는 것처럼 보이지만, 실제로는 느낌과 추측뿐임을 강조함. 최근 실증 연구들은 오히려 AI가 불평등을 악화시키는 방향을 보여줌. 이코노미스트의 그래프와 기사에서 관련 내용을 확인할 수 있음
당연히 AI가 불평등을 심화시킨다는 생각임. AI는 사람들이 경험을 쌓아 올라가는 사다리의 하위 단계를 자동화해서, 미래의 전문가가 될 사람들에게 발판을 제공하지 않고, 이미 정상에 있는 사람들이 투자하여 그 사다리를 더 빠르게 올리는 기술이라고 봄
그래프는 너무 큰 가정을 하고 있는데, 이는 AI 극성주의자의 머릿속에서만 뒷받침되는 느낌임. 특히 '사이드 프로젝트' 관련해서는 애매하게 다루고 있는데, AI가 초보의 입력을 받아서 '충분히 괜찮은' 결과를 만들어 내기에 부족하다고 생각함
글의 요지에 어느 정도 공감함. 과학자처럼 실험실 가운을 입은 듯 위장하지만, 사실 자신들이 어떻게 세상을 보는지에 대한 관계성만 표현했을 뿐임. 그래도 그래프에 '가설'임을 명시하거나, 축 끝을 물결선으로 표현하는 등 시각적 방법으로 가설임을 강조하면 커뮤니케이션 수단으로 가치는 있다고 봄. 곡선의 평탄화(숙련도 정체)가 생긴다고 전제하는 것 역시 확신할 수는 없음. 저자는 오히려 경제학자들의 링크보다 더 선의의 글쓰기를 했다고 생각함. 나는 사람들이 솔직한 의견을 드러내고, 데이터가 있으면 가설 검증까지 보여주면 이상적이라고 봄
그래프에는 불평등 증가를 보여주는 연구가 4개, 불평등 감소를 보여주는 연구가 6개 언급됨
은퇴한 수학자 입장에서, 2025년에 AI에 푹 빠지게 됐고 Claude Max 요금제를 써서 제한 없이 Claude Code Opus 4를 사용하고 있음. 병렬 세션으로 방대한 레거시 코드 베이스를 리뷰하면 사용 한도에 닿기도 함. 한동안 AI에 관한 그 어떤 소통도 기피했으나, 최근에는 HN에서 흥미로운 논의들이 보여 다시 관심 가짐. 내 의견으론 신경다양성(neurodivergent)이 있는 사람들이 AI 사용에 더 성공적인데, 이는 AI가 거대한 연상 엔진이기 때문임. 나는 선형대수 전공이니, AI의 연상 구조와 내 독특한 사고방식이 잘 맞음. 결국 AI는 바닥이 아닌 천장을 올리는 효과를 가져옴
Andrew Ng의 최근 AI 스타트업 발표와 비슷한 통찰임. 요즘 창업가들에게 주는 새 조언은, 피벗할 때 프로토타입을 버리고 처음부터 새로 하라는 것임. 이는 본문의 내용과도 연관됨. 프로토타입 개발은 최대 10배 향상되지만, 기존 코드베이스는 30~50% 정도만 개선된다고 함. 이 변화는 과거 VM에서 컨테이너로 옮겨갈 때의 '펫 vs 가축' 비유와 유사함. 코드베이스를 정성스럽게 아끼는 '펫'이 아니라 효율적으로 대하는 '가축'처럼 다뤄야 하는 시대일 수도 있음. 관련 발표 동영상에서 10:30 부분 참고할 수 있음
나의 생각에는 '펫 vs 가축' 비유가 코드에만 집중해서, 진짜 가치는 개발자의 머릿속에 있다는 점을 놓치기 쉬움. AI는 코드 관리는 도와줄 수 있지만, 진정한 가치는 개발자의 이해와 정신적 모델에 있음
좋은 포인트지만, '가축'보다는 '가축(cattle)'이라는 표현을 더 자주 들어봤음. 지리적 차이인지 궁금해짐
이 비유 언급 감사함. 앞으로 생성형 코드를 대규모 클라우드 인프라처럼 다룰 필요가 있을 것 같음. 오랜 세월 써온 레거시 코드에는 덜 적용될 수 있음. 혹시 통찰을 블로그로 정리한 적 있는지 궁금하고, stillpointlab.com 나 @stillpointlab 트위터가 궁금해서 찾아봤으나 자료가 별로 없음
"펫 vs 가축" 비유가 "장인 vs 대충 만드는 사람" 논쟁보다 훨씬 잘 맞는다고 느낌. LLM을 써도 결과물의 가치가 깎이는 게 아니라, 코드에 대한 정서적 애착 대신 실용적으로 바라보는 시각의 전환임
LLM으로는 아직 할 수 없는 일이 꽤 있음. 예를 들어 체스를 같이 두다보면 5~10수 정도 지나면 불법 수를 두기 시작하고, 최고의 경우에도 18수 정도가 한계였음. 상대방의 잘못된 움직임도 바로잡지 않으므로 잘못된 학습이 될 수 있음. 결국 실제로 복잡한 문제를 모델링하지 못하니, 사용자가 무엇을 질문해야 할지 인식하는 것이 매우 중요함. LLM은 나이트의 이동 방법이나 유명한 오프닝 정도는 알려줄 수 있지만, 체스 기보 전체를 올바르게 따라가거나, 현 보드 상황에서 최선의 수를 알려주는 것은 불가능함. 많은 사용자가 얼마나 잘못된 답변이 나올 수 있는지 모르는 채로, 자신있게 뱉는 답변을 그대로 믿을 가능성이 큼. 얼핏 보면 단단해 보이지만, 사실은 보이지 않는 크레바스 위를 걷는 것과 같음
LLM이 체스에 약한 것은 큰 문제라고 생각하지 않음. 체스 전용 모델은 꽤 괜찮은 수준의 ELO로 합법적인 수만 두게끔 할 수 있음. 포스트 트레이닝이 체스 능력을 저해할 수 있고, OpenAI 같은 곳에서도 크게 신경 쓰지 않는 듯함. LLM으로도 체스 잘 둘 수 있음. 관련 논문 및 평가 예시 참고함
나도 주변에 박사나 의사 같은 전문가들이 LLM이 실수할 거라는 건 아예 상상도 못하는 경우를 자주 봄. 환상적이고 논리적인 문장에 자신감까지 더해지니, 완전 전문가라 착각하는 ‘후광 효과’도 있을 것 같음
LLM으로 코드 에이전트 모드에서 작업해보면, 처음엔 잘하다가 점점 엉뚱한 방향으로 흐르기도 하고, 전혀 상관없는 코드 들여쓰기를 시도하는 등 의외의 행동을 많이 목격했음
체스의 경우, 전문 AI는 인간보다 훨씬 뛰어나는데, 반면 범용 LLM은 합법적인 수를 두기도 어렵다는 점이 흥미로움. AI의 천장은 LLM보다 훨씬 높은 위치에 있음
"10수 이상 따라가기 어려움"에 대해, 체스에서는 과거 수보다 현재 보드 상태가 더 중요함. LLM은 불필요한 정보를 거르는 데 약하니, 오히려 보드 상태만 입력하면 성능이 좋아짐. 더 자세한 토론 참고
에이전트가 그린필드 프로젝트에만 좋다면, 기존 코드베이스도 새 기능마다 새로운 그린필드 프로젝트처럼 준비해서, 인턴이 플러그만 꽂으면 동작하도록 해야 함. 나머지 부분은 사람의 손이 필요하고, 그렇지 않으면 인턴이 벽 전체를 다 뜯어버릴 수 있음
말도 안 된다고 생각함. npm의 Y 프로젝트를 WebStorm으로 GitHub에서 받아서 Junie에게 물어보면, 바로 답을 받을 수도 있고, 이해 안 되는 데이터 구조도 예시와 함께 문서화해줌. PR까지 바로 만들 수는 없어도, 페어 프로그래머로 충분히 활용할 수 있음. 오히려 더 많은 테스트를 쓰고 오류 처리도 더 신경 쓰게 되어 최종적으로 더 나은 결과를 만듦
에이전트는 잘하는 것도 많고 못하는 것도 많음. 쓸수록 뭐가 더 잘되는지 헷갈릴 지경임
에이전트가 완전히 새로운 프로젝트 시작은 오히려 별로고, 소~중간 규모 프로젝트에는 매우 좋으며, 크기가 커질수록 점차 효율이 떨어지는 경향이 있다고 생각함. 완전히 새 프로젝트의 경우엔 실제로 써먹을 수 없는 '예제 수준' 코드가 많이 나옴.
AI는 보간(interpolation)을 잘하는 도구이고, 외삽(extrapolation)은 못한다는 한줄 요약임
본문의 대부분에는 동의하지만, "AI가 제공할 수 있는 수준에서 실력 향상이 멈춘다"는 것에는 agree하지 않음. 내 경험상 AI를 잘 쓰려면 '고정적'이 아니라 '성장적' 마인드로, 나는 AI의 매니저처럼 역할 놀이하며 출력을 계속 개선함. 어느 정도 한계는 있지만, 직접 해당 스킬을 배우지 않아도, 문제의 경계에 집중해가며 결과의 품질을 상당히 높일 수 있었음. 시간이 흐를수록 현장 전문가가 되지 않고도, 그 분야의 더 나은 매니저로 성장함을 느끼고 있음
본인이 "어떻게"를 모른다면 품질이 충분히 나아졌다는 걸 무슨 기준으로 아는지 궁금함. 결국 시작 품질과 비교한 상대적 향상일 텐데, 자기 만족만 되면 실제로 품질이 낫지 않아도 상관 없는 걸로 보임
나는 이런 방식이 "치팅"이라고 보지 않음
학습 곡선에서 AI를 쓰다가도, 절정 근처에 이르면 오히려 AI 없이 배우는 경우가 더 좋아질 것임. 최고의 숙련도는 천천히, 자기주도적으로 배우는 시간을 통해서만 가능함
LLM의 가장 큰 장점은 광고나 소셜 미디어에 방해받지 않고, 통일된 포맷으로 정확한 답변을 받을 수 있다는 점임. reddit이나 insta, tvtropes에서 답변을 찾는 것과 정반대임. 생각 도우미로서 완전히 집중할 수 있는 OS와, 자녀가 콘텐츠 함정에 빠지지 않게 도와주는 환경이 빨리 나왔으면 좋겠음. 나는 ad hoc UI에 방해받지 않고 필요한 문서와 정보만 빠르게 받는 게 정말 좋음
나는 AI 답변이 정확하다고 생각하지 않고, 오히려 위험할 정도인 경우가 흔하다고 느낌. 커뮤니티에서는 누가 전문가인지 판단하기 쉽고, 결국 맞는 답변을 얻을 수 있지만, AI 역시 이 데이터를 다 수집했으니 틀린 답을 내놓을 위험도 똑같음. 광고 없는 환경도 얼마 못 갈 것 같음. AI 기업들은 엄청난 적자를 내고 있으니 곧 광고와 소셜 요소가 넘칠 테고, 지금의 무료 혜택은 그냥 고객을 유인하는 손실 보전 전략에 불과함
"정확하다"는 표현이 주관적임을 비꼼
내가 더 잘 아는 AI 분야도 이 흐름과 일치함. 평균 이하인 사람도 AI로 평균에 가까운 결과를 얻을 수 있음
더 많은 지식을 가진 사람이 LLM을 써야 제대로 이득을 본다는 또다른 요약과도 일치함
평균 이상인 사람도 AI를 써서 평범한 결과물을 낼 수 있음. 많은 작업에서 '충분히 괜찮다'의 기준이 오히려 매우 낮음
그래서 여기 있는 사람들이 AI를 반대하는 이유는 다들 평균 이상이라서 그런 것 같다는 농담임
"평균 이하가 AI로 평균 수준의 결과를 내면" 전체 평균도 그만큼 올라가는 셈임
"AI는 프로토타이핑에 좋고, 엔지니어링에는 좋지 않다"고 요약할 수 있을 것 같음. AI 도구는 속도는 빠르지만 breadth(넓이)와 depth(깊이)가 부족함. 빠르게 PoC나 부분 문제 해결에는 유용하지만, 전체 맥락과 깊이는 부족하고, 진정한 엔지니어링은 구현 이상의 훨씬 더 많은 요소(문맥, 예외, 실패 형태, 깊은 이해 등)가 필요함. 아무리 뛰어난 프로그래머여도 엔지니어가 아닐 수 있고, 최고의 leetcoder가 팀에 실질적으로 도움이 안 될 수도 있음. 진짜 마스터리로 가려면 경험이 필요하고, 그건 미묘한 것들(비직관적 요소)까지 알아야 함. 매니저가 버튼 하나로 제품을 엔지니어링할 수 있는 시대는 오지 않겠음. 현재의 AI 코드 생성기도 '매니저용 자동화'라는 착각에서 출발했고, 오히려 현업 엔지니어의 설명을 바탕으로 동작하는 툴이 더 낫다고 생각함. Dijkstra의 "자연어로 프로그래밍하는 어리석음"에 대한 논평이 여전히 유효하다고 봄. 관련 원문