버그를 수정하고 문서를 작성하기 위해 AI 사용해야 하는 이유

AI 코딩 보조자는 서면 의도로 코드를 생성할 수 있습니다. 만약 그것이 역경로도 처리하고 레거시 시스템에 사용 가능한 문서를 생성한다면 어떨까요?

ChatGPT와 깃허브 코파일럿을 사용한 첫 경험을 공유했습니다. AI 제안은 정확할 수 있지만 질문이 구체적이고 핵심적인 범위에서만 가능합니다. 마음을 읽을 수는 없지만 이전에 해결되었고 이미 완벽하게 좋은 라이브러리 솔루션이 존재할 수 있는 잘 정의된 작업에 대한 해결책을 찾을 수 있습니다. 무엇을 구축해야 할지 아는 것이 가장 어려운 부분으로 남아 있으며 아이디어에서 코드까지 전체 여정을 자동화하는 데 전혀 도움이 되지 않습니다.

이 주제에 대해 두 가지 요점이 더 있습니다. 첫째, 프로그래머는 당분간 운전석에 있어야 하기 때문에 냉정을 유지하는 것이 좋습니다. 둘째, 나는 아이디어를 코드로 변환하는 솔루션에 초점을 맞추어야 한다고 생각합니다. 개인적으로 그 반대의 일을 할 수 있는 유용한 인공지능을 기다릴 수 없습니다. 80개의 마이크로서비스의 문서화되지 않은 엉킴을 스캔하고 아무도 문서를 최신으로 유지하려고 하지 않았기 때문에 무엇인지 명확한 영어로 설명합니다.

 

 

버그를 수정하고 문서를 작성하기 위해 AI 사용해야 하는 이유

 

 

아이디어에서 코드로

새로운 프로그래밍 언어는 바이트를 이동시키는 어려운 수학으로부터 훨씬 더 멀리 떨어져 있습니다. 그것들은 실행 가능한 코드에서 현실 세계를 훨씬 더 높은 수준의 추상화로 모델링하는 도전을 처리하기 위해 머리 공간을 자유롭게 합니다. 그러나 심지어 코드가 없는 해결책이나 그래픽 작업 흐름 엔진도 여전히 프로그래밍 언어입니다. 그것들은 단지 다른 형태의 코딩 기술을 취할 뿐인데, 이것은 수학 재능에게 나쁜 소식입니다. 결국, 인공지능과 대화를 시작하고, 자동화되기를 원하는 작업을 설명하고, '프로그래머'가 그것이 어떻게 구현되는지 보거나 신경 쓰지 않고 그것을 할 것입니다.

그 완벽한 무대는 완전 자율 주행 자동차와 동등합니다. 당신이 원하는 곳을 말하면 그곳으로 데려다 줍니다. 운전대나 가속기가 필요하지 않아 매우 신뢰할 수 있습니다. 사실 더 이상 간섭할 수 없는 것은 옳은 일입니다. 당신은 더 이상 어떻게 하는지 모를 것입니다. 우리는 아직 거기에 있지 않습니다. 책임을 둘러싼 법적 지뢰밭은 많은 운전자들보다 더 나은 일을 하는 최첨단보다 더 큰 장애물입니다. 우리가 로봇 운전사를 명령할 수 있을 때까지, 우리는 완전히 유능한 운전자를 필요로 하는 점점 더 정교한 도움을 받을 것입니다. 역설적이게도, 이것은 운전을 더 안전하게 만들지 못합니다. 인공지능이 더 신뢰할수록 주변 교통과 연결되고 싶은 유혹이 더 심합니다. 행동에 뛰어들 필요가 있는 드문 순간이지만, (만약 당신이 조금이라도 주의를 기울이고 있었다면) 당신의 기술이 위축되었다는 것을 알게 될 것입니다.

인공지능의 지원을 받는 소프트웨어 작성에 대한 비유는 명백합니다. 인간으로서, 편집처럼 프로세스가 완벽하고 예측 가능할 때에만 제어권을 자신 있게 포기할 수 있습니다. 인간 언어로 표현되고 실행 가능한 소프트웨어로 번역되는 아이디어는 컴파일러에 의해 바이트 코드로 변환되는 자바 코드와 같아야 합니다. 이것이 어떻게 작동하는지 자세히 아는 프로그래머는 거의 없습니다. 대부분은 단서를 가지고 있지 않습니다. 그것이 강력하고 예측 가능한 프로세스이기 때문에 알 여유가 없습니다.

 

 

부조종사 및 자동조종사 모두

현학적인 것은 아니지만 깃허브 코파일럿은 정말로 자동 조종사입니다. 항공에서 부조종사는 완전히 능력 있는 인간입니다. 비행기의 자동 조종은 조종사를 대체할 수 있지만 도움이 되지 않는 고급 도구 모음입니다. 그러나 그들은 게으르게 만들 수 있는 힘을 가지고 있습니다. 운전자와 조종사처럼 프로그래머는 날카로움을 잃을 수 없습니다. 그녀는 제안된 제안에 대한 좋은 판단을 가지고 있어야 합니다.

전통적인 자동 완성은 우리를 게으르게 만들었습니다. 새로운 인공지능 맛은 더욱 더 그렇게 만들 것입니다. 스레드 안전을 알지 못하고 재진입 잠금, 동시 수집 또는 원자 정수가 무엇인지 모른다면 인공지능에게 생성하도록 지시하거나 필요하다고 인식할 수 없습니다. 여전히 OCP-17 시험을 준비하고 있습니다. 자존감 있는 선배 개발자로서 이런 것을 알아야 한다는 확신과 이 주제와 질문 줄에 대한 짜증 사이에 놓여 있습니다. 복잡한 조각을 자세히 살펴서 누락된 송구 선언을 발견하면 무엇을 배울 수 있을까요? 왜 파일 클래스의 주요 정적 방법의 정확한 서명을 알아야 합니까? 사용하지 않으면 잃어버리면 많은 부분을 금방 잊어버릴 것을 알고 있습니다. 제 뇌는 이상한 효율성을 가지고 있습니다. 실제로 고착된 것은 영화 인용문과 노래 가사입니다. 아마도 저는 NIO API를 음악으로 설정해야 할 것입니다.

하지만 오라클의 사람들은 조심스럽게 혼란스러운 작은 기차 사고에 일리가 있습니다. 그것은 당신의 인식력을 강화하고, 당신이 경력의 많은 시간을 끔찍한 코드를 읽는데 사용한다는 것을 인정하는 것입니다.

너무 많은 책과 과정은 새로운 코드를 작성하는 방법을 가르쳐줍니다. 시스템을 충돌시키지 않는 단편적인 개선과 버그 수정을 하는 것과 같은 좋은 유지보수 기술을 배우는 것의 가치를 높이 평가하는 사람은 많지 않습니다. 아무도 그것을 하는 것을 좋아하지 않으므로 AI가 그것을 시도하도록 하십시오. 만약 그것이 매우 똑똑하다면, 서버 로그의 스택 흔적을 뒤져서 그 중단에 대한 근본 원인을 가지고 돌아오도록 하십시오. 그것은 인상적일 것입니다.

 

 

구현에서 의도로의 회귀

부품이 어떻게 맞물려 돌아가는지에 대한 개요를 잃지 않았다면 레거시 시스템의 재작성을 몇 번이나 막을 수 있었을까요? 하지만 아무도 설명서를 다시 작성하지 않으려고 하지 않았습니다. (대기업 시스템의 설명서가 비싸다고 생각한다면 전체 재작성을 시도하십시오.) 라이브러리를 업데이트하고 소스를 최신 런타임 버전으로 마이그레이션하는 일반적인 작업에도 동일하게 적용됩니다. OpenRewrite와 같은 이니셔티브를 사용하십시오.

구현에서 의도(즉, 문서)로 돌아가는 것이 다음 큰 승리입니다. 우리는 더 이상 코드가 필요하지 않습니다. 우리는 AI의 도움을 받아 이미 존재하는 것을 더 잘 이해해야 합니다. 나는 이미 자체 문서화되어 있는 방법에 대한 자동 생성 API 문서에 대해 말하는 것이 아닙니다. 그것은 큰 그림의 의도를 결코 전달하지 않습니다. 나는 다양한 수준의 복잡성에서 대기업 시스템에 대한 사용자 친화적인 설명서에 대해 말하는 것입니다. AI가 그러한 상호 연결된 서비스의 네트워크의 의도를 구성 부분의 코드에서 증류하도록 하세요. 그것을 이해할 수 있는 다이어그램으로 바꾸고 간단한 영어로 설명하세요. 모든 것을 하나의 시퀀스 또는 활동 다이어그램에 주입하지 마십시오. 큰 그림에서 개별 세부 정보로 분기하는 분할 정복 방식을 사용하십시오. 나는 그것에게 다음과 같은 데이터 모델을 제공합니다:

이 데이터 모델은 도서 대출 라이브러리를 나타냅니다. ISBN에 의해 식별된 도서 제목을 저장하고 각 저자의 전기 데이터를 저장합니다. 도서 제목은 물리적 사본이 0개 이상일 수 있습니다. 도서 대출은 회원의 ID, 도서 사본, 현재 날짜 및 반환 날짜로 등록됩니다. 그들은 개발자들이 코딩하는 것을 좋아하고 문서 작성을 싫어한다고 말합니다. 아마도 마이크로소프트는 깃허브 코파일럿의 미래 버전과 우선순위를 재조정해야 할 것입니다.