최근 친구와 재미있는 대화를 나눴음. 그는 연례 평가 주기 중에 있으며, 경영진이 그와 그의 팀에게 AI 도구를 더 많이 사용하도록 강력히 권장하고 있음. 그는 생의학 연구소에서 일하며 LLMs가 전혀 필요하지 않음. 하지만 팀원들은 다양한 인물로 사직서를 작성하는 데 회사의 언어 모델을 사용하며 즐거운 시간을 보냈음. 실제로 사직한 사람은 없지만, 팀 사기를 완전히 망치는 좋은 방법이었음
나는 항상 내 차이점에서 녹색보다 빨간색 선이 더 많기를 바라는 개발자였음. 우리는 수백 개의 통합 테스트를 선언적으로 만들 수 있도록 라이브러리를 작성하는 것을 좋아함. 나는 이틀 동안 사라졌다가 두 개의 루프 변수를 바꿔 10배 속도를 높인 개발자임
이 환경에는 나의 자리가 없음. 도구를 사용해 많은 코드를 만들 수 없다는 것이 아니라, AI 사용이 성공의 척도를 생산 속도로 만든다는 것임
나쁜 코드의 해결책은 더 많은 코드임. AI는 삭제를 절대 만들지 않을 것임. 출판하거나 사라지라는 압박이 우리에게 다가왔고, 슬픔을 느낌
Python 프로그래밍이 메인프레임 사람들을 늙게 만든 것처럼 나를 늙게 만듦. AI 개발자들을 늙게 만들 것은 무엇일지 궁금함
GenAI 댓글 섹션에서 가장 좋아하는 부분은 한 사람이 "이것은 AI를 사용하는 나의 개인적인 경험"이라고 말하면, 여러 사람들이 "당신은 잘못 사용하고 있어!"라고 합창하는 부분임
질문을 어떻게 구성하고 나에게 더 잘 맞는 것이 무엇인지에 대해 성찰하는 것이 흥미로움
AI를 사용해 "단순한" 작업을 수행하는 것에 만족함. 필드로 구문 분석할 수 있는 텍스트 파일이 있었고, 약간의 특이점(오른쪽 정렬된 텍스트 등)이 있었음. 필드 의미론을 지정하여 ICS 파일 캘린더로 프롬프트를 만들어 그대로 가져올 수 있었음
텍스트 노트를 구조화하여 캘린더로 가져오는 것이 달콤했음. 이 작업을 직접 수행하기 위해 AI를 훈련시킬 필요는 없음. 필드가 무엇인지 효율적으로 말하는 방법과 경계가 무엇인지 생각하는 것이 데이터를 이해하는 데 도움을 줌
ICS 파일을 보고 타입:값이라는 것을 알 수 있지만, 타입이나 날짜/시간에 필요한 특정 GMT/Z 형식, 확인/대기 등의 의미 구분은 모름. 이러한 고급 구조는 캘린더와 AI 설명에서 유용한 행동을 만들어 냈음
AI를 사용해 DJANGO 웹을 작성하여 간단한 예약 작업을 수행했음. 코드가 그대로 실행될 것이라고 기대하지 않았지만, 실행되었음. 이 제품과 함께 살 수 있을까? 네, 하지만 확장성에 대해 걱정됨. 기능을 추가할 때 잘못된 프롬프트 하나로 인해 엉망이 될 수 있음. 취약함
대학에서 컴파일러, 시스템 등을 가르침. AI가 학생을 완전히 잘못된 경로로 이끌어 가는 경우를 무수히 많이 봄
앞으로 모든 프로젝트에 .noai 파일을 추가하고 있음
AI는 경험 있는 개발자에게는 유용할 수 있지만, 경험 없는 개발자에게는 재앙임
"괜찮아, 우리는 경험 있는 개발자만 고용해."라는 말이 있음
그렇다면 경험 있는 개발자는 어디서 오는 걸까?
이 AI 아크에서 계속해서 판타지아의 마법사의 제자 장면이 떠오름
이것은 단지 수행적인 관리의 사례처럼 들림. 그들에게는 단지 "생산성-미래-기술"의 순간적인 구현임. 그래서 그들은 "AI 주도 개발로 성공적으로 전환했다"고 이력서에 쓸 수 있음. AI는 단지 소프트웨어일 뿐이며, 그것이 전략에 맞든지 안 맞든지임. 소프트웨어를 사용하기 시작했다고 해서 성공하는 회사는 없듯이, AI를 사용하기 시작했다고 해서 성공하는 회사도 없음
AI에 의존하는 것의 장기적인 영향을 회사들이 인식해야 함. 이는 위축을 초래하고, 버그가 발생했을 때, 직접 작성한 것보다 이해하고 수정하는 데 더 많은 시간이 걸림
생성된 코드에서 동시성 버그를 수정하는 데 일주일을 보냈음. 테스트가 있었지만, 테스트가 잘못되었음을 깨달았을 때 버그를 발견했음
내 강력한 조언은 생성된 코드의 모든 줄을 소화하라는 것임. 그것이 당신을 앞서지 않도록 하세요
최근 개념 예술에 진입하려는 것을 포기한 친구의 관점
AI 이전에는 아웃소싱이 있었음. 대량 생산된 저렴한 작품으로 외국 스튜디오가 대부분의 주니어 직위를 제거했음
이제 AI는 이 경향을 논리적 극단으로 가져가고 있음: 기계로의 아웃소싱, 궁극적인 아웃소싱 형태. 비용은 0에 가까워지고 양은 무한에 가까워짐
이 이야기는 개발자들에게 슬픔을 줌. 특히 게임에서는 AI가 제공하지 않는 창의성이 필요함. "기본 엔진 보일러플레이트"를 넘어서면 더욱 그러함. 그것이 당신을 도울 수 없다는 것은 아니지만, 이 "모두 참여" 방법은 강제적이고 고통스러워 보임
내가 플레이한 최고의 게임 중 일부는 많은 비전, 실행, 세련미, 세심한 장인 정신으로 "내가 하고 싶었던 게임"임
Hacker News 의견
최근 친구와 재미있는 대화를 나눴음. 그는 연례 평가 주기 중에 있으며, 경영진이 그와 그의 팀에게 AI 도구를 더 많이 사용하도록 강력히 권장하고 있음. 그는 생의학 연구소에서 일하며 LLMs가 전혀 필요하지 않음. 하지만 팀원들은 다양한 인물로 사직서를 작성하는 데 회사의 언어 모델을 사용하며 즐거운 시간을 보냈음. 실제로 사직한 사람은 없지만, 팀 사기를 완전히 망치는 좋은 방법이었음
나는 항상 내 차이점에서 녹색보다 빨간색 선이 더 많기를 바라는 개발자였음. 우리는 수백 개의 통합 테스트를 선언적으로 만들 수 있도록 라이브러리를 작성하는 것을 좋아함. 나는 이틀 동안 사라졌다가 두 개의 루프 변수를 바꿔 10배 속도를 높인 개발자임
GenAI 댓글 섹션에서 가장 좋아하는 부분은 한 사람이 "이것은 AI를 사용하는 나의 개인적인 경험"이라고 말하면, 여러 사람들이 "당신은 잘못 사용하고 있어!"라고 합창하는 부분임
질문을 어떻게 구성하고 나에게 더 잘 맞는 것이 무엇인지에 대해 성찰하는 것이 흥미로움
대학에서 컴파일러, 시스템 등을 가르침. AI가 학생을 완전히 잘못된 경로로 이끌어 가는 경우를 무수히 많이 봄
.noai파일을 추가하고 있음이것은 단지 수행적인 관리의 사례처럼 들림. 그들에게는 단지 "생산성-미래-기술"의 순간적인 구현임. 그래서 그들은 "AI 주도 개발로 성공적으로 전환했다"고 이력서에 쓸 수 있음. AI는 단지 소프트웨어일 뿐이며, 그것이 전략에 맞든지 안 맞든지임. 소프트웨어를 사용하기 시작했다고 해서 성공하는 회사는 없듯이, AI를 사용하기 시작했다고 해서 성공하는 회사도 없음
AI에 의존하는 것의 장기적인 영향을 회사들이 인식해야 함. 이는 위축을 초래하고, 버그가 발생했을 때, 직접 작성한 것보다 이해하고 수정하는 데 더 많은 시간이 걸림
최근 개념 예술에 진입하려는 것을 포기한 친구의 관점
이 이야기는 개발자들에게 슬픔을 줌. 특히 게임에서는 AI가 제공하지 않는 창의성이 필요함. "기본 엔진 보일러플레이트"를 넘어서면 더욱 그러함. 그것이 당신을 도울 수 없다는 것은 아니지만, 이 "모두 참여" 방법은 강제적이고 고통스러워 보임
Bradley의 게임은 DOA임. 혹시 ARK: Aquatica인가?