AI가 개발자를 도왔는데 왜 출시는 더 빨라지지 않았나

이건 브룩스가 이미 "맨먼스 미신"에서 숙고했던 것입니다:

"가끔 신문에서 두 프로그래머가 개조한 차고에서 대규모 팀의 최선의 노력을 능가하는 중요한 프로그램을 만들었다는 기사를 읽는다. 그리고 모든 프로그래머는 그런 이야기를 믿을 준비가 되어 있다. 왜냐하면 그는 산업 팀에서 보고된 연간 1000줄보다 훨씬 빠르게 어떤 프로그램이든 만들 수 있다는 것을 알기 때문이다. 그렇다면 왜 모든 산업 프로그래밍 팀이 전용 차고 듀오로 대체되지 않았을까? 무엇이 생산되고 있는지 살펴봐야 한다."

브룩스는 차고에서 이루어진 코딩은 최종 제품에 필요한 것의 일부에 불과하다고 주장합니다:

"그것은 9배의 비용이 든다. 하지만 그것은 진정으로 유용한 물건이며, 대부분의 시스템 프로그래밍 노력의 의도된 제품이다."

지금 우리가 보고 있는 것도 크게 다르지 않게 느껴집니다. 초안, 그린필드 프로젝트, 실험, 또는 적어도 그 초기 반복을 크게 가속할 수 있습니다. 라이브 프로덕션 시스템이나 널리 사용되는 라이브러리를 변경하는 것은 완전히 다른 문제입니다.

나는 훨씬 더 많이 배포하고 있지만, 고객들이 반드시 그것을 알 것이라고는 모르겠다. 범위 때문에 미뤄졌던 전체 재작성 작업이 이제 완료되고 있다. 보안 문제가 패치되고 있다. 지원 티켓 개설부터 해결까지의 시간이 줄어들고 있다. 그래서 그렇다, 단지 기능에만 집중하기보다 훨씬 더 나은 프로젝트를 만들기 위해 훨씬 빠르게 배포하고 있다.

AI 코딩이 도입한 한 가지 역학은 AI 이전의 코딩에 비해 기능이 첫 개발 반복 후에 더 커지고 더 "완전"하거나 "복잡"해진다는 것입니다. 한 예로, 최근에 회사 내부 문서 사이트를 위한 웹 크롤러를 만들었습니다. 데이터 스크래핑, 파싱, 벡터화 및 인덱싱에 대한 내 설계는 AI를 사용하지 않았다면 훨씬 덜 복잡하거나 완전했을 것입니다. 이는 주로 해당 분야에 대한 나의 지식 부족과 프로젝트의 일반적인 시간 제약 때문입니다.

그 증가된 복잡성은 이전보다 비용이 덜 들지만, 설계가 "더 멍청"했다면 없었을 인지 부하와 테스트 측면에서 프로젝트에 시간/비용을 추가했습니다. 설계 복잡성 증가라는 이 개념은 설계의 복잡성이 사용 가능한 시간을 채우기 위해 성장하는 파킨슨 법칙의 한 형태로 생각할 수 있습니다.

AI가 확실히 우리가 코드를 더 빨리 작성하도록 만들고 있다고 생각하지만, 코드 작성이 더 저렴해진 지금 실제로 얼마나 많은 시간이 확보되고 있을까요? 우리는 종종 그 확보된 시간을 다른 것으로 채우고 있으며, 설계 복잡성 증가가 그 중 하나라는 인상을 받습니다.

더 많은 티켓과 더 큰 티켓, 예전에는 3개 팀과 조정하며 4주가 걸렸던 전체 마이그레이션이 이제 하루 만에 단일 PR로 이루어집니다.

edit: PR이 느려지는 것을 보고 있다면, 아마도 당신의 10배 개발자 10명이 근무 중에 8개 스타트업에서 codex의 3-4개 이상의 계정으로 코드를 던지고 있을 가능성이 더 큽니다.

LLM에 대한 흥분은 프로젝트의 품질이 아니라 엔지니어의 생산성에 관한 것이었습니다. 전통적으로 우리는 새로운 작업에 대해 리뷰와 QA 단계에서 병목이 있었고, 많은 조직이 그 병목을 해결하지 않은 채 새로운 코드의 물줄기를 틀어버립니다.

고속으로 달리고 싶다면, 먼저 고속도로를 건설해야 합니다.

소프트웨어 개발에서 AI의 영향에 의문을 제기하는 사람들을 보면 내가 미쳐가는 것 같다.

사람들은 불과 몇 년 전만 해도 소프트웨어 개발이 얼마나 길고 고된 일이었는지 이미 잊어버린 것 같다.

이제 가장 큰 병목은 엔지니어링과 관련된 CI/CD/실험이고, 비즈니스와 관련된 제품 정렬이다.

우리는 그렇습니다. 한 달의 작업이 하루로 바뀌었습니다.