소개
In a이전 게시물, 나는 나의 새로운 도구 개발에 AI 사용에 대해 다음을 썼습니다include-tidy(Tidy)를 사용하는Libclang, 이전에 사용해 본 적 없는 도서관:
무엇이 도움이 되었습니까로트는 AI(정확히는 LLM)를 사용하고 있었습니다(구체적으로는 Google의 Gemini를 사용했습니다, Claude에 비용을 지불할 여유가 없기 때문입니다, 특히 제가 돈을 벌기로 결정하지 않은 개인 프로젝트에 대해서는 더욱 그렇습니다). 나는 추후에 제 경험을 설명하는 블로그 포스트를 작성할 수도 있지만, AI는 제가 많은 문서를 읽지 않아도 되게 해주었고, 튜토리얼을 읽지 않아도 되게 해주었으며, 메일링리스트나 Stack Overflow에 질문을 게시하고 답변을 기다리지 않아도 되게 해주었습니다(만약 답변이 있다면).
이것은 이전에 언급한 후속 블로그 게시물입니다. AI를 사용해 오랫동안이면 이후에 설명할 내용은 대부분 당신에게 놀라운 것이 아닐 것입니다. Tidy용 AI를 사용하기 전에 저는 작은 기능에만 사용하거나 특수한 경우의 질문을 할 때만 사용했습니다. Tidy용으로 AI를 사용하는 것은 제가 처음으로 "큰" AI 사용이었습니다.
이 블로그나 저를 처음 접하는 분이라면 "이 분은 누구인가요, 그리고 왜 저의 생각을 신경 써야 하는 거죠?"라고 생각하실 수 있을 겁니다. 저는 컴퓨터를 오랜四십 년간 취미로도, 전문적으로도 다뤄왔습니다. 일부 프로그래머들은 특히 오래된 세대 출신 프로그래머들은 AI에 대해 꽤 의심스러워하며, 이를 종종 "강화된 자동 교정"이라고 부른다. 그러나 그 안에는 기술적인 진리가 조금은 있지만, 여전히 매우 인상적이다.
프롬프팅
“프롬프트 엔지니어링”이라는 용어와 그와 관련된 “프롬프트 엔지니어”라는 직책은 매우 과장되었다고 생각한다 (뒤의 것은 “청소 공학자”와 같다), 당신는 로 detailed하고 specific해야 합니다 — Stack Overflow에서 질문을 제출하는 경우와 같습니다.
스택 오버플로우와는 달리, 이전에 질문된 질문을 하거나 FAQ을 읽지 않은 것에 대해 벌하지 않으며, 대지로 왜 그럴 거라는 질문을 하지 않으며, 염세적인 답변 또는 의견을 받지 않으며, 아니 답변을 받지 않으며, 몇 초 안에 답변을 받게 됩니다.
모든 것이 좋다고 들리지만, 당신이 얻는 답은 완전히 틀릴 수 있습니다. 몇 번이고, Gemini는 존재하지 않는 API 함수를 사용해야 한다고 말했습니다. 저가 그 점을 지적한 후, 그것은 자기 자신을 수정했습니다만.
또한, 당신이 얻는 답은 종종 당신의 정확한 질문에만 기반할 뿐입니다. AI를 사용하는 것을 원숭이의 손처럼 생각하는 것이 가장 좋습니다.그렇지 않으면 응답을 받지 못할 수 있습니다.기술적으로요청을 만족시키지만,예기치 못한 결과.
예를 들어, 제가 제미니에게 Tidy를 만들도록 첫 번째 프롬프트를 보낸 것은 이렇습니다:
clang API를 사용하여 C 또는 C++ 소스 파일을 입력받아 각 심볼(마크로, 상수, 함수, 타입, 변수 등)과 그 심볼이 선언된 파일과 줄 번호를 출력하는 프로그램을 작성하라, 또는 결정할 수 없는 경우 "unknown"을 출력하라.
그리고 Libclang에서 어떤 파일을 보여주는 몇 화면 분량의 C 코드를 출력하라#include는 Libclang을 초기화하고 정리하는 데 호출해야 할 함수는 무엇인가, 소스 파일을 파싱하고 그 추상 구문 트리 (AST)를 반복하는 방법은 무엇인가. 물론 Libclang의 튜토리얼을 준비할 수 있었지만, Gemini의 응답은 내가 하고 싶은 일에 맞게 맞춰져 있었다.
물론 그가 생성한 프로그램은 전혀 완전하지 않았습니다. 명령줄 옵션, 구성 파일, 오류, 색상 출력 또는 C 또는 C++ 소스 파일을 분석할 때 모든 예외적인 경우를 처리하지 않았습니다. 이런 점들은 다음 주에 구체화될 것입니다. 하지만 나는 좋은 출발을 했습니다.
일상적인 작업
AI를 사용하는 또 다른 좋은 점은 그것이 당신이될 수 있다하지만 코드가 지루해서 귀찮게 하고 싶지 않습니다. 예를 들어 Tidy는 명령줄 인수를 사전 스캔해야 하며, 그 중에서 앞에 있는 것을 찾아야 합니다.-Xtidy두 배열로 나누기: Tidy 특정인 것들과 Libclang으로 그대로 전달해야 하는 것들. 여기 내 프롬프트가 있었어:
주어진
argc그리고argv때문에main는 C 프로그램에서 두 가지 유형의 옵션이 있습니다: (1)-Xtidy옵션, 즉-Xtidy로 시작하는 옵션; 그리고 (2) 단순한 옵션. "옵션"은 짧은 옵션 또는 긴 옵션입니다.
argc와argv를 조작하여-Xtidy로 시작하는 모든 옵션을 별도의tiny_argv배열로 분리하고 싶습니다.tiny_argc를argv에서 모든-Xtidy를 제거하고 바로 다음 옵션을 제거합니다.
그리고 그것은 그냥 올바르게 했 몇 초 안에, 내가 코드를 작성했다면 예기치 않은 off-by-one 오류를 디버깅할 필요 없이 모두 완료했습니다.
경험
경험 많은 프로그래머라면 생성된 코드를 보고 빠르게 올바른지 아닌지 알 수 있습니다. 따라서 경험 많은 프로그래머에게 AI는 매우 효율적인 가속기입니다; 경험 부족한 프로그래머(혹은 프로그래머가 아닌 사람)라면, 저는 당신이 원숭이의 팔에 의존해야 한다고 생각합니다.
버그 찾기
특정 .c 완료 후에 할 수 있는 또 다른 일은,.cpp 파일을 업로드하고, "이 코드에 버그를 찾을 수 있나요?"라고 묻는다. 그리고 그렇게 한다. 물론 당신은 모든 버그를 찾았는지 알 수 없으므로, 여전히 단위 테스트와 다른 테스트를 작성해야 합니다.
물론 그것은 제가 내 것처럼 거짓 긍정을 보고할 수도 있다.c_chan 프로젝트. 그는 제가 특정 뮤텍스를 사용하는 것이 잘못되었다고 생각했습니다. 물론, 이는 인간 프로그래머들도 혼란을 줄 수 있는 뮤텍스 사용 방식이었지만요. 하지만 몇 가지 다른 실제 버그를도 발견했습니다. 초기화되지 않은 구조체 멤버들과 tv_nsec 구조체의 timespec 구조체 멤버 가 필요합니다.는 0에서 999999999까지의 범위에 있어야 하므로 오버플로우를 확인하기 위한 코드를 추가해야 합니다.
AI가 하지 않은 일
다른 코드베이스와 마찬가지로, 코드의 대부분은 코드베이스의 주요 목적과 직접적으로 관련이 없습니다. Tidy의 경우:
- 18%만
#include지시문을 스캔하고 심볼을 포함 파일에 매핑하는 데 관련이 있습니다. - 26%은 단순히 “ utility ” 코드(나머지 코드 작성을 쉽게 만드는 작은 함수)입니다.
- 25%은 설정 파일을 파싱하기 위해 사용됩니다(구문적으로 TOML을 파싱하고, 의미적으로 해석하며, 오류를 확인하고, 정확한 줄과 열을 포함한 오류 메시지를 출력합니다).
- 15%은 일반 데이터 구조(동적 배열, 적색-검은색 트리)에 사용됩니다.
- 9%은 명령줄 파싱에 사용됩니다.
- 8%은 테스트에 사용됩니다.
AI를 사용했다도와주다와 (아니요)쓰다Libclang을 사용하여 코드를 작성하세요, 유틸리티 코드나 설정 파일은 아니며, 명령줄에서 매우 조금만 사용합니다(인수를 분할하기 위해), 그리고 테스트용은 아닙니다.
영향
이 블로그 게시물의 목적은 소프트웨어 개발을 위한 인공지능에 대한 제 인상을 설명하는 것뿐입니다.me에게, 전체적인 소프트웨어 개발에 대한 제 생각의 함의에 대해 댓글에서 물어볼 가능성이 높을 것 같아, 그래서 지금 바로 그에 답하자고 생각해.
물론 AI에 대한 많은 홍보가 있었고, 계속될 것이라고 생각해, 그래서 말했듯이, 그것은 내게 많은 도움이 된 것 같아 Tidy와 함께. 이것은 소프트웨어 개발의 게임 체인저입니다. 경험 많은 프로그래머의 손에 이것은 가속제가 됩니다. 더 이상 경험 부족한 프로그래머가 아니기 때문에, 경험 부족한 프로그래머에게 AI 사용이 어떤지에 대해 직접적으로 의견을 드리지 못합니다. 이것도 가속제일 가능성이 높지만, 경험 부족한 (또는 아님) 프로그래머들은 잘못된 코드나 보안을 무시한 코드를 본 뒤에도 감지하지 못할 수 있습니다. 분명히 더 많은 데이터 유출과 소송이 발생할 것입니다.
분명히 듣고 (그리고 아마도 불행하게 직접 경험했을 수도 있겠지만) 기술 회사의 광범위한 채용 채우기를 들으셨을 겁니다. 저는댓글을 남겼습니다네, 많은 인사 채용이 있었지만, 저는 AI가 CEO들이 비효율적이지 않은 것처럼 들리지 않게 하고, 회사들이 문제에 처한 것처럼 들리지 않게 하기 위해 도피소로 사용되고 있다고 생각합니다. 인사 채용의 이유는 여전히 동일합니다:
- 회사는 일반적으로 비효율적으로 인력을 과다 채용했습니다.
- 새로운 제품이나 서비스가 성공하지 못했다.
- 회사는 재정적 어려움에 처해 있다.
모든 것이 CEO가 비효율적이라는 것을 보이게 한다. 대신 AI를 책임지고, 최첨단 기술을 동시에 채택하면서 비용을 절감하는 것으로 CEO가 교활해 보이게 하며 - 둘 다 월스트리트에 보상받는다.
그에 대해, 다음은 해고의 이유를 추가한다. 비효율적인 CEO:
- 사실 모든 홍보를 믿고 AI로 개발자를 대체할 수 있다고 생각할 수도 있습니다can
다음 시나리오를 고려해 보세요. 당신은 대표 소프트웨어 제품을 판매하며 큰 고객 기반을 가진 기술 회사의 CEO입니다. 직원으로는 100명의 개발자가 있습니다. 평균적으로 한 달에 하나의 새로운 기능을 추가하고 10개의 버그를 수정합니다. 한 달에 더 많은 기능을 추가하고 더 많은 버그를 수정하고 싶지만, 더 많은 개발자를 고용할 여력이 없습니다. 이제 AI가 나타나서 두 가지 옵션이 있습니다:
- 한 달에 한 가지 새로운 기능을 추가하고 10 개의 버그를 수정하되, 더 적은 개발자와 비용으로
- 같은 수의 개발자를 사용하여 AI를 가속제로 하여 한 달에 두 가지 또는 세 가지 새로운 기능을 추가하고 30 개의 버그를 수정합니다.
정신이 차린 CEO가 옵션 1을 선택하고 "우리의 현재 개발 속도에 만족하고 고객들도 마찬가지입니다"라고 생각하는가요? 옵션 2는 기존 고객들에게 더 만족스럽게 하고 새로운 고객을 유치하는 데 더 효과적일 가능성이 높습니다. 사실, 이러한 주장을 뒷받침하는 연구가 있었습니다.
그래서 만약 شما도 해고에 영향을 받았다면, 어쩌면 슬픔을 느끼는 것에서(.__JHSNS_SEG_48a16740_123__schadenfreude) 조금의 위안을 얻을 수 있을 수도 있습니다.는 CEO가 비효율적일 가능성에 따라서입니다.
결론
AI는 매우 그럴듯하게 남아있을 가능성이 높습니다. 명백히 개발자를 가속화하는 도구입니다. 물론, 격동, 인수합병, 그리고 몇몇 파산이 있을 것입니다. 최소 현재로서는 AI를 운영하는 것이 돈을 많이 잃는 일입니다. AI를 이익을 낼 수 있도록 만드는 것이겠습니다.다른 문제입니다. Google과 같이 대체 수입원(광고)이 있는 거대 기업은 AI를 영원히 자금 지원할 수 있습니다; Anthropic은 그저지금 막 이익을 내기 시작했습니다첫 번째로. 그들이 할 수 있는지는 불분명합니다.계속하다이익을 내기 위해. 다음 몇 년이 걸릴지 모른다.