고원 함정

최근에 나는 AI 피로에 대해 글을 썼다. 나는 엔지니어가 경험하는 것이 만성 질환이 아니라 훈련으로 인한 근육통이라고 주장했다. 그것을 극복하고, 적응하고, 더 강해지라고 말했다.

그것은 모두 좋고 합리적인 이야기지만, 그 이야기에 더 많은 것이 있다. 그리고 그것은 점점 더 명백해지고 있다. 현재 엔지니어링 팀이 직면한 실제 위험은 소진이 아니다. 그것은 고원에 머무는 것이다.

새로운 분리

거의 모든 시니어 엔지니어가 현재 AI를 사용한다. Copilot, Claude, Cursor, Codex, 당신이 이름을 불러도 된다. 그 부분은 이미 정해져 있다. 만약 당신이 엔지니어링 조직을 이끌고 있다면, 당신은 아마도 광범위한採用 숫자를 보게 될 것이고, 그것에 대해 좋은 느낌을 가질 것이다.

그러나 당신은 그렇게 생각해서는 안 된다.

採用 숫자는 무의미하다. 중요한 것은 그 아래에서 발생하는 분리이다. 당신의 팀은 조용히 두 그룹으로 나누어지고 있다. 생산성의 향상을 얻고 정착한 엔지니어들이 있고, 매주 계속해서 밀어붙이는 엔지니어들이 있다. 새로운 워크플로우, 새로운 에이전트 구성, AI가 처리할 수 있도록 문제를 분해하는 새로운 방법들.

두 그룹 모두 대시보드에서 “AI採用자”로 나타난다. 그러나 하나는 점진적인 훈련 프로그램에 있다. 다른 하나는 첫 번째 중량이 편안하게 느껴질 때 중단했다.

6개월 전, 이 두 그룹 사이의 간격은 거의 보이지 않았다. 이제 그것은 주의를 기울이는 누구에게나 명백하다. 또 6개월 후, 그것은 구조적인 것이 될 것이다.

고원이 실제로 무엇인지

고원에 머무르는 엔지니어는 전통적인 의미에서 무엇을 잘못하고 있는 것이 아니다. 그들은 능숙하다. 그들은 배송한다. 그들은 에이전트를 사용하여 간단한 작업을 수행하고, 그 뒤를 청소한다. 그들은 아마도 20-30%의 생산성 향상을 얻었고, 그것으로 충분하다고 생각했다.

문제는 그 엔지니어 옆에 있는 엔지니어가 거기서 멈추지 않았다는 것이다. 그 엔지니어는現在 다중 에이전트 워크플로우를 실행하고, 검증 루프를 개선하고, 전체 기능을 AI에서 실행할 수 있는 조각으로 분해하고, 아키텍처 수준에서 검토하고, 이전보다 2-3배 빠른 속도로 배송하고 있다. 그것은因为 그들이 더 재능이 있기 때문이 아니다. 그것은因为 그들이 모두가 휴식을 취하는 동안 계속 훈련했기 때문이다.

이것은 AI에 대한 열정이나 초기採用자에 관한 것이 아니다. 초기採用 단계는 이미 끝났다. 이것은 연속적인 적응과 일회적인 조정에 관한 것이다. 그리고 이 두 가지 접근 방식 사이의 차이는 점점 더 무시할 수 없게 된다.

경쟁 압력이 실제이고 가속화되고 있다

만약 당신의 팀이 자신의 시간표에 따라 적응할 수 있는 여유가 있었다면, 고원 문제는 성과 관리 문제였다. 짜증나지만, 관리할 수 있었다.

그러나 당신이 소프트웨어 산업의 더广い 상황을 본다면, 아마도 당신은 그ような 여유가 없을 것이다.

소프트웨어 산업은 대체로 디지털 작업을 도와주는 것을 위해 만들어졌다. 지원 에이전트가 들어오는 경우를 보는 것, 고객에게 대한 반응을 추적하는 것, 워크플로우를 관리하는 것. 이제 AI 에이전트가 전체 워크플로우를 대체하고, 그와 함께 기본 SaaS 플랫폼을 혼란시키고 있다. 또한, AI가 더 능숙해짐에 따라, 당신의 고객들은 다음과 같은 질문을 시작한다. “우리가 이것을 여전히 사야 하는가, 아니면 지금 자신이 만들 수 있는가?” AI는 “사다”와 “만들다” 사이의 장벽을 점점 더 낮추고 있다. 당신의 수익을 보호하던 끈끈함은 매 분기마다 약해지고 있다.

당신의 고원에 머무르는 엔지니어들은 더 이상 존재하지 않는 경쟁 환경에 맞춰진 속도로 작동하고 있다.

내게 모든 것을 재구성한 인용문

나는 이미 여러 번 들었다. 제품 매니저들이袖을 걷어붙이고 기능을 구현한 경우, 엔지니어링 리더들이 실패한 아키텍처를 재설계한 경우, 다른 회사에서, 다른 상황에서:

“에이전트와 함께 이 것을 반복하는 것이, 그 엔지니어와 함께 하는 것보다 더 쉬웠다.”

처음에 나는 그것을 과장이라고 생각했다. 세 번째에는 그것이 선도 지표라는 것을 깨달았다.

내가 본 바에 따르면, AI의 능력을 증폭할 수 있는 엔지니어들이 있다. 그렇게 하려면 두 가지 분야에서 강해야 한다. 둘 다 내적인 동기와 지적 호기심으로 자체 개발할 수 있다:

• 그들은 이해관계자(제품 매니저, 엔지니어 매니저 등)와 같은波長에서 작동한다. 그들은 무엇이 좋은지 이해하므로, 당신이 그것을 설명할 필요가 없다. 만약 그들이 코딩 에이전트와 같은 수준의 오해를 일으킨다면, 에이전트가 항상 그 싸움을 이길 것이다. 그것은 즉시 사용 가능하고, 24/7이고, 피로하지 않다.
• 그들은 자신의 AI 설정을不断 개선한다. 그래서 당신이 그들에게 무엇인가를 넘길 때, 그것이 잘 처리될 뿐만 아니라, 새로운 시장 템포에 따라 충분히 빠르게 처리될 것이라는 것을 알 수 있다.

왜 이것은 개인의 문제가 아닌 리더십 문제인지

이것을 개인 엔지니어의 책임으로 프레임하는 것이 유혹적이다. “뒤처지지 않으려면 따라와라.” 그러나 만약 당신이 엔지니어링 조직을 이끌고 있다면, 그런 프레임은 당신을 책임에서 면제한다.

당신의 고원에 머무르는 엔지니어들은 공허한 공간에서 고원에 머무르지 않았다. 그들은 초기 조정 후에 더 나아가지 않았기 때문에 고원에 머무르게 되었다. 합리적인 생산성 향상을 얻었고, 아무도 그들을 더 나아가도록 도전하지 않았고, 관성의 나머지는 알아서 되었다.

계속해서 밀어붙이는 엔지니어들은 대부분 자발적이다. 그들은 아무리도 밀어붙일 것이다. 그러나 당신은 엔지니어링 조직을 전적으로 자발적인 개척자들로만 구성할 수 없다. 리더에게는 다음과 같은 질문이 있다: 중간을 어떻게 움직일 수 있는가?

이것은 변화 관리 문제이다. 그리고 내가 가장 좋아하는 프레임워크 중 하나는 히스 형제의 책 스위치에서 나온 것이다. 간단한 버전: 당신은 사람들에게 명확한 방향을 주어야 하고, 왜 그것이 중요한지 느끼게 해야 한다. 그리고 새로운 행동이 가장 저항이 없는 길이 되도록 환경을 재구성해야 한다. 엔지니어링 팀에 적용하면 다음과 같다:

밝은 점을 찾고 그것을 가시적으로 만든다. AI 워크플로우에서 가장 멀리 나아간 엔지니어들을 식별하고, 팀에게 정기적으로 데모를 하도록 한다. 훈련 세션이 아니다. 실제 작업의 라이브 워크스루이다. 팀의 중간이 자신의 워크플로우와 최상단 어댑터의 워크플로우 사이의 델타를 볼 때, 그것은 명령이 할 수 없는 생산적인 불편함을 생성한다.

• 변화를 축소한다. “AI를採用한다”는 너무 추상적이다. 이번 스프린트에는 종단간 에이전트 테스트를 해결하고, 다음 스프린트에는 전체 조직에 걸쳐 롤아웃한다. 구체적이고 관리할 수 있는 단계가 대담한 변환 프로그램보다 항상 승리한다. 작은 승리도 중요하다.
• 기본값을 재구성한다. 에이전트의 검증 과정을 코드화하고, 그것을 팀과 모든 에이전트에 걸쳐 배포한다. 워크플로우를 정의하고, 그것을 지원하는 툴링을 사용한다. 새로운 작업 방식이 가장 저항이 없는 길이 되도록 한다. 그래서 사람들이 거기서 벗어나기 위해 싸울 필요가 없이, 자연스럽게 그쪽으로漂向한다.

창이 닫히고 있다

이것이 긴급한 것이 아닌 단순히 중요한 것인지에 대한 부분이다.

현재, 적응 간격은 성과 차이다. 당신의 고원에 머무르는 엔지니어들은 더 느리다. 그러나 그들은 여전히 생산적이다. 그들은 여전히 기여한다. 당신은 그들을 지탱할 수 있다.

그 창은 닫히고 있다. AI의 능력이 가속화되고, 경쟁 압력이 합성되면서, 엔지니어링 작업의 최소한의 속도는 올라가고 있다. 오늘날의 “충분한” 엔지니어는 내년 분기에 충분하다고 보장할 수 없다. 그것은因为 그들이 더 나빠진 것이 아니라, 바닥이 올라갔기 때문이다.

전체 팀을 적응 곡선으로 이동하는 조직은 합성적인 구조적인 이점을 가질 것이다. 그렇지 못한 조직은 더 이상 존재하지 않는 경쟁 속도에 맞춰진 팀을 발견할 것이다.

나는 이야기하는 모든 엔지니어링 리더가 이것을 지적으로 이해한다. 그러나 매우少數的人이 팀을 운영하는 방식을 바꾸었다. 이해와 행동 사이의 간격은 또 다른 종류의 고원이다.

편안한 속도가 없다

AI 피로에 대한 글에서, 나는 근육통이 훈련이 작동하는 증거라고 주장했다. 그것은 여전히 진실이다. 그러나 후속 진실은 더 어렵다: 중량이 계속 증가한다.

일반적인 짐에서, 당신은 편안한 중량을 선택하고, 영원히 유지할 수 있다. 아무도 당신의 바에 중량을 추가하지 않는다. 현재 소프트웨어 풍경에서, 새로운 모델 출시, 새로운 에이전트 기능, 새로운 워크플로우가 누군가가 발견하고 공유할 때, 바는 움직인다. 서 있으면, 결국 중량이 당신을 끌어당긴다.

현재 소프트웨어 산업에는 편안한 공간이 없다. 개인 엔지니어에게도, 팀에게도, 팀이 구축하는 회사에게도 없다. 안전한 위치는 연속적인 운동뿐이다. 엔지니어링 리더에게 가장 중요한 질문은, 당신의 전체 팀이 이동하는지, 아니면 이미 이동하던 사람들만 이동하는지에 대한 것이다.