Skip to content
←

Split View: 코드 생성이 싸질 때 값이 오르는 기술 — 감가하는 것과 절상하는 것

|

코드 생성이 싸질 때 값이 오르는 기술 — 감가하는 것과 절상하는 것

들어가며 — 질문을 바로 세우기

"AI가 개발자를 대체할까"는 잘못 세운 질문입니다. 이 질문은 개발자를 하나의 기술로 취급합니다. 실제로 개발자는 열댓 가지 기술의 묶음이고, 그 묶음의 항목들은 지금 서로 다른 속도로 재가격되는 중 입니다. 어떤 항목은 0에 수렴하고, 어떤 항목은 오릅니다.

그래서 제대로 된 질문은 이것입니다 — 묶음에서 싸지는 항목은 무엇이고, 그 값은 어디로 가는가. 이건 취향의 문제가 아니라 꽤 지루한 경제학의 문제이고, 답의 뼈대는 이미 나와 있습니다.

메커니즘 — 병목은 사라지지 않고 이동한다

공정 하나가 싸지고 흔해지면 병목은 소멸하지 않습니다. 다음 공정으로 이동 합니다. 그리고 값은 병목이 있는 곳에 붙습니다. 생성이 싸지면 값은 생성 다음 단계로 갑니다 — 그것이 맞는지 확인하는 일, 무엇을 만들지 정하는 일, 남의 시스템에 끼워 넣는 일로.

이 직관을 AI 쪽에서 가장 날카롭게 벼려 놓은 사람이 Jason Wei입니다. 그의 검증의 비대칭성(asymmetry of verification) 은 간단합니다 — 어떤 과제는 푸는 것보다 확인하는 게 훨씬 쉽습니다. 스도쿠를 푸는 데는 오래 걸리지만 다 푼 답이 맞는지는 즉시 압니다. 여기서 그는 검증자의 법칙(verifier's law) 을 끌어냅니다 — "AI에게 어떤 과제를 가르치는 난이도는 그 과제의 검증 가능성에 비례한다." 더 날 선 표현으로는, 풀 수 있고 검증하기 쉬운 과제는 결국 전부 AI가 풀게 된다 는 것입니다.

대부분은 이 법칙을 "AI가 잘하게 될 일" 목록으로 읽습니다. 그런데 뒤집어 읽는 쪽이 훨씬 중요합니다. 검증하기 쉬운 일이 자동화된다면, 사람에게 남는 일은 정확히 검증이 비싸거나 느리거나 주관적이거나, 애초에 정답지가 없는 일 입니다. 이건 위안이 아니라 예측입니다.

그리고 병목은 실제로 이미 움직였습니다.

  • DORA 2025 는 기술 인력의 약 90%가 AI를 쓴다고 보고합니다. 그런데 결론이 묘합니다 — AI 도입은 처리량과 양의 관계로 돌아섰지만, 배포 불안정성은 계속 오릅니다. DORA의 요약은 AI가 조직의 기존 강점과 약점을 함께 증폭하는 증폭기 라는 것입니다. 속도만 올리고 품질 통제를 안 하면 병목은 그저 하류로 밀려납니다.
  • LinearB의 2026 벤치마크 는 그 하류가 어디인지 숫자로 보여 줍니다. 4,800여 개 조직의 PR 810만 건을 분석했더니, AI가 만든 PR은 리뷰를 4.6배 오래 기다립니다. 에이전트가 연 PR은 픽업 시간이 5.3배 깁니다. 병합률은 32.7% 대 84.4% 로 사람이 쓴 코드에 한참 못 미칩니다. 생성이 폭증한 자리에서 리뷰 앞에 줄이 생긴 것입니다.
  • 그 줄이 왜 안 줄어드는지는 Stack Overflow 2025 가 설명합니다. 개발자의 84%가 AI 도구를 쓰거나 쓸 계획이고 절반 이상이 매일 씁니다. 그런데 최대 불만 1위가 "거의 맞지만 정확히는 아닌 코드"(66%) 이고, 2위가 "AI가 만든 코드를 디버깅하는 데 시간이 더 든다"(45.2%) 입니다. 정확성을 높게 신뢰한다는 응답은 3.1%뿐입니다.

마지막 항목이 이 글 전체의 핵심입니다. 거의 맞는 코드는 틀린 코드보다 비쌉니다. 틀린 코드는 즉시 걸러집니다. 거의 맞는 코드는 훑어보기를 통과하고, 리뷰를 통과하고, 스테이징을 통과한 다음, 프로덕션에서 터집니다. 생성이 싸질수록 이런 코드가 더 많이, 더 빨리 쏟아집니다. 검증 비용은 생성량에 비례해서 늘어나는데, 검증 역량은 그렇지 않습니다.

감가하는 기술 — 원래 가치가 아니라 대리 지표였던 것들

솔직하게 이름을 붙이겠습니다.

  • 암기한 프레임워크 API. 모델은 문서를 당신보다 정확히, 전부 읽었습니다. 시그니처를 외우는 능력에 붙어 있던 프리미엄은 사라졌습니다.
  • 보일러플레이트 처리량. CRUD 스캐폴딩, DTO 변환, 설정 파일, 테스트 픽스처 — 분당 생산량으로 경쟁하던 영역입니다.
  • "나는 빨리 친다" 식 생산성. 타이핑 속도가 병목이었던 적은 사실 한 번도 없었지만, 그래도 값이 매겨지던 시절은 있었습니다.

중요한 건 이겁니다 — 이 기술들은 원래부터 가치 그 자체가 아니라 가치의 대리 지표(proxy) 였습니다. 생성이 병목이던 시절에는 희소했기 때문에 값이 붙었을 뿐입니다. 희소성이 사라지면 값도 사라집니다.

다만 감가와 무용은 다릅니다. 읽지 못하는 코드는 리뷰할 수 없습니다. 문법도 모르고 프레임워크도 모르면 아래에서 말할 절상 기술은 하나도 시작되지 않습니다. 바닥은 여전히 필요합니다. 다만 바닥은 이제 입장료지 경쟁 우위가 아닙니다.

절상하는 기술 (1) — 검증: 훑어보는 눈이 아니라 정답을 공급하는 능력

먼저 오해를 걷어냅시다. 절상하는 검증 능력은 "디프를 꼼꼼히 읽는 성실함"이 아닙니다. 그건 기계가 이미 상당 부분 합니다. 린터, 타입 체커, 정적 분석, AI 리뷰 봇 — 널 체크 누락과 명백한 경쟁 조건은 검증하기 쉬운 축에 속하고, 검증자의 법칙에 따라 그쪽은 계속 자동화됩니다.

값이 오르는 건 기계가 공급할 수 없는 쪽입니다 — 정답지(ground truth) 자체. 이 시스템에서, 이 사업에서, 이 규모에서 "맞다"가 무엇을 뜻하는지 결정하는 일 입니다. 모델은 테스트를 통과시킬 수 있지만, 무엇을 테스트해야 하는지는 결정하지 못합니다. 그건 사업의 사실이지 코드의 사실이 아니기 때문입니다.

의도적으로 기르는 법:

  • 모델이 코드를 쓰기 전에 통과 조건을 먼저 쓰세요. 통과 조건을 문장으로 못 쓰면 그건 요구사항이 아니라 소망입니다.
  • 가설을 갖고 리뷰하세요. 디프를 열기 전에 "이 변경이 프로덕션을 깨뜨릴 수 있는 경로 세 가지"를 적고, 그것들을 찾으러 들어가세요. 가설 없는 리뷰는 오타 검사입니다.
  • 버그 장부를 쓰세요. 프로덕션 버그마다 "어떤 검증이 있었다면 이걸 잡았을까"를 한 줄로 적으세요. 그 목록이 당신에게 없는 테스트입니다.
  • "테스트 통과"와 "정확함"을 구분하는 훈련을 하세요. 평가 설계는 그 자체로 하나의 기술이고, 이건 AI 코딩 모델 평가에서 신호와 잡음 가려내기에서 다룬 문제와 정확히 같은 문제입니다 — 잡음보다 큰 차이만 신호입니다.

절상하는 기술 (2) — 프로덕션 디버깅: 맥락이 암묵적일 때

METR의 무작위 대조 실험이 이 대목에서 가장 유용합니다. 숙련 오픈소스 개발자 16명이 자기 저장소(평균 별 2만 개 이상, 코드 100만 줄 이상)에서 실제 이슈 246건을 처리했습니다. 이들은 시작 전 24% 빨라질 거라 예상했고, 끝난 뒤엔 20% 빨라졌다고 느꼈습니다. 실제로는 19% 느려졌습니다.

이유가 결정적입니다. 오래 다뤄 온 성숙한 저장소는 AI에게 최악에 가까운 조건입니다 — 요구사항이 저장소 바깥의 맥락에 얽혀 있고, 사람 쪽에는 문서에 없는 방대한 로컬 지식 이 쌓여 있기 때문입니다. 모델에게는 그 지식이 없습니다.

이게 해자의 모양입니다. AI는 맥락이 암묵적이고 실패가 창발적인 곳에서 가장 약합니다. 프로덕션이 정확히 그런 곳입니다. 버그는 디프 안에 없습니다. 디프와, 아무도 적어 두지 않은 6년치 결정들 사이의 상호작용 안에 있습니다.

제 경험으로 말하자면 — KubeVirt GPU 패스스루 VM이 112일간 스케줄되지 못한 부검에서 원인은 저장소 안에 없었습니다. 저장소만 읽는 무엇도 그걸 찾아낼 수 없었습니다. CloudNativePG로 Postgres를 띄우고 죽여본 기록도 같습니다 — 페일오버가 실제로 무엇을 하는지는 읽어서 아는 게 아니라 프라이머리를 죽여 보고 23초를 재서 압니다.

의도적으로 기르는 법:

  • 장애를 끝까지 소유하고 부검을 직접 쓰세요. 배움은 대응이 아니라 글쓰기에서 생깁니다.
  • 안전한 곳에서 일부러 부수세요. 프라이머리를 죽이고, 디스크를 채우고, 네트워크를 끊으세요. 먼저 결과를 예측하고, 그다음 측정하세요. 예측과 측정의 간극이 곧 당신이 가진 시스템 모델의 오차이고, 회사가 돈을 내는 대상이 바로 그 모델입니다.
  • 코드가 아니라 시스템을 읽는 훈련. 메트릭, 트레이스, 커널 로그, 이벤트. 관찰 → 가설 → 실험의 루프를 몸에 붙이세요.
  • 내가 안 쓴 코드를 디버깅하세요. 이게 앞으로의 기본값입니다. 코드는 모델이 썼고, 책임은 당신에게 있습니다.

절상하는 기술 (3) — 시스템 설계와 트레이드오프 취향

모델은 어떤 설계 질문에도 그럴듯한 답을 내놓습니다. 못 하는 건 당신의 조직이 5년간 감당할 수 있는 트레이드오프가 어느 쪽인지 고르는 일입니다. 그 판단은 저장소에 없는 사실들에 달려 있기 때문입니다 — 팀 규모, 온콜 성숙도, 감당 못 할 마이그레이션, 만료를 앞둔 벤더 계약, 6개월 뒤 나갈 사람.

취향은 신비한 게 아닙니다. 지난번에 무엇이 터졌는지에 대한 압축된 기억 입니다. 결과를 겪고 만든 사전 확률이죠.

의도적으로 기르는 법: 남의 부검을 읽으세요(공개된 것이 많습니다). 설계 문서마다 무엇을 포기하는지 를 명시적으로 쓰세요. 기각한 대안을 최소 두 개 적고 왜 기각했는지 쓰세요. 그리고 12개월 뒤 자기 결정을 다시 열어 채점하세요 — 이 되먹임이 없으면 취향은 자라지 않고 고집만 자랍니다.

규칙 하나 — 기각된 대안이 없는 설계 문서는 설계가 아니라 선호입니다.

절상하는 기술 (4) — 요구사항 고고학: 무엇을 만들지 아는 일

가장 비싼 버그는 완벽하게 구현된 엉뚱한 것 입니다. AI는 만드는 비용을 떨어뜨립니다. 그 말은 엉뚱한 것을 훨씬 빠르게, 훨씬 대량으로 만들 수 있게 됐다 는 뜻이기도 합니다. 그래서 무엇을 만들지 아는 능력은 만드는 비용이 싸지는 만큼 정확히 비례해서 절상됩니다.

요구사항 고고학은 사람들이 말한 것에서 실제로 필요한 것을 발굴하는 일입니다. 대부분의 진짜 요구사항은 문서에 없습니다. 아무도 지우지 못하는 2019년의 if 문 안에, 이상한 예외 처리 안에, 옛 시스템의 기본값 안에 화석처럼 박혀 있습니다.

이 모호함을 다루는 일이 직무 자체인 자리도 있습니다 — Forward Deployed Engineer 준비 글에서 정리했듯, 거기서는 모호함이 부작용이 아니라 업무입니다.

의도적으로 기르는 법: 사용자 옆에 앉아 실제로 하는 걸 보세요(말하는 것과 다릅니다). "이게 실패하면 그다음에 뭘 하세요?"를 물으세요 — 진짜 요구사항은 대개 그 답에 있습니다. 코드베이스에서 가장 흉한 분기를 골라 왜 존재하는지 끝까지 파세요(대개 실수가 아니라 요구사항입니다). 설계 문서 이전에 한 장짜리 문제 정의 를 쓰세요. 그리고 틀리려면 일찍, 싸게, 소리 내어 틀리세요.

절상하는 기술 (5) — 오너십: 호출기를 찰 수 있다는 것

모델에게 호출기를 채울 수는 없습니다. 똑똑함이 모자라서가 아닙니다. 책임은 결과를 감당하는 주체를 요구하기 때문 입니다. 조직은 결정에 이름이 붙기를 원합니다. 새벽 3시에 깨어나 "이건 내가 롤백한다"고 말할 사람이 필요합니다.

여기서 정직할 필요가 있습니다. 이건 역량의 사실이라기보다 사회적·법적 사실 입니다. 언젠가 제도가 바뀔 수도 있습니다. 다만 사회적 사실은 끈질기고, 노동의 값을 실제로 매깁니다.

커뮤니케이션도 여기 속합니다. 코드를 못 읽는 사람에게 트레이드오프를 설명하지 못하면 결정을 통과시킬 수 없습니다. 생성이 싸질수록 희소해지는 행위는 결정 이고, 결정은 본질적으로 사회적 행위입니다.

의도적으로 기르는 법: 호출기를 받으세요. 아무도 하기 싫어하는 마이그레이션에 손을 드세요. 무언가를 출시하고 1년간 그것에 붙어 있으세요. 결과가 나에게까지 도달하는 되먹임 고리 — 판단력은 오직 거기서만 자랍니다.

반론 — "검증도 결국 AI가 하지 않나"

이 반론은 진지하게 다뤄야 합니다. 약하게 만들어 놓고 이기면 자기기만입니다.

가장 강한 형태는 이렇습니다. 검증자의 법칙은 검증하기 쉬운 일은 전부 AI가 가져간다 고 말하는데, 리뷰의 상당 부분은 검증하기 쉽습니다. 타입 오류, 널 참조, 명백한 경쟁 조건, 스타일 — AI 리뷰 도구는 이미 이걸 잘합니다. 테스트 생성, 퍼징, 코드를 실제로 실행해 보고 관찰하는 에이전트까지 붙으면 검증의 상당 부분은 자동화됩니다. 여기에 더해, 위에서 인용한 METR 결과조차 METR 자신이 단서를 달았습니다 — 2026년 2월 업데이트에서 이들은 실험 설계를 바꾸겠다고 밝히면서, 2026년 초 시점에는 개발자들이 초기 추정보다 더 빨라졌을 가능성이 높다 고 봅니다(다만 그 크기에 대한 증거는 약하다고 인정합니다). 그러니 "19% 느려진다"를 영구 법칙처럼 들고 다니면 안 됩니다. 그건 한 시점의 측정입니다.

여기까지는 인정합니다. 기계적 검증은 자동화될 것이고, 대체로 자동화되는 편이 낫습니다. 당신의 "검증 능력"이 널 체크 누락을 잡아내는 것이라면, 그것도 함께 감가합니다.

그럼에도 남는 경계가 있습니다. 정확성 검증은 대조할 정답지 를 필요로 합니다. 그 정답지는 어디서 옵니까? 수학과 알고리즘 문제에는 답안지가 있습니다. 당신 회사의 정산 시스템에는 없습니다. 누군가 무엇이 맞는지를 결정해야 합니다.

이 경계가 실재한다는 가장 깨끗한 증거가 DeepMind 팀의 결과입니다 — 외부 피드백 없이 모델이 스스로 답을 고치게 하는 내재적 자기교정 은 정확도를 올리지 못했고, 오히려 떨어뜨리기도 했습니다. 정답 레이블(오라클)을 쥐여 줬을 때만 개선이 나타났습니다. 이 결과는 2023년 모델 기준이고 그 사이 모델은 크게 좋아졌습니다 — 구체적 수치를 오늘에 그대로 적용하면 안 됩니다. 그런데 구조적 논점은 모델 성능의 함수가 아닙니다. 자기 믿음을 자기 믿음으로 검사하는 시스템은, 갖고 있지 않은 정답지를 만들어 낼 수 없습니다.

여기서 정직하게 불확실성을 표시하겠습니다. 저는 이 경계가 어디까지 밀릴지 모릅니다. 만약 모델이 당신의 사업에서 "맞다"가 무엇인지 당신보다 잘 결정하게 된다면, 이 글의 조언은 만료됩니다. 저는 그게 가깝다고 보지 않습니다 — 제약은 지능이 아니라 결과에 대한 접근 이라고 보기 때문입니다. 하지만 "그렇게 보지 않는다"는 증거가 아니라 믿음입니다. 느슨하게 쥐십시오.

제가 걸겠다면 이쪽에 겁니다 — AI가 대부분을 검증하는 세계에서도 그 판정에 책임지는 누군가는 여전히 필요하고, 책임이야말로 직업의 정의 입니다.

마치며

양쪽 극단을 모두 거부합시다.

"개발자는 끝났다"는 틀렸습니다. 묶음 전체가 0으로 재가격됐다고 가정하지만, 실제로는 불균등하게 재가격됐을 뿐입니다. "달라진 건 없다"도 틀렸습니다. 많은 사람이 커리어를 세운 바로 그 항목들이 정확히 싸진 항목이기 때문입니다.

불편한 대목도 남겨 두겠습니다. 이 재가격은 주니어에게 특히 가혹합니다. 감가하는 기술들은 그동안 사다리의 아래 칸 이었기 때문입니다 — 보일러플레이트를 치면서 코드베이스를 익히는 길이 막히고 있습니다. 저는 여기에 깔끔한 답이 없습니다. 그나마 최선은 결과에 더 빨리 닿는 것 입니다. 작더라도 프로덕션에서 무언가를 소유하고, 그것이 깨질 때 호출당하는 자리에 일찍 서는 것.

절상하는 기술들은 하나의 공통 성질을 갖습니다. 전부 결과와의 접촉 을 요구합니다. 검증은 무엇이 터지는지 알아야 하고, 디버깅은 호출을 당해 봐야 하고, 취향은 틀려 봐야 생깁니다. 그래서 이것들은 다운로드할 수 없습니다. 그리고 같은 이유로, 한 번도 호출당해 본 적 없는 모델에게 아직은 학습시키기 어렵습니다.

한 줄로 줄이면 이렇습니다 — 코드를 짜는 값은 떨어졌고, 코드가 맞는지 아는 값은 올랐습니다.

참고 자료

When Code Generation Gets Cheap, Which Skills Go Up in Value — What Depreciates and What Appreciates

Introduction — Asking the Right Question

"Will AI replace developers?" is the wrong question. It treats "developer" as a single skill. In reality a developer is a bundle of a dozen or so skills, and the items in that bundle are being repriced at different rates right now. Some are converging on zero. Some are going up.

So the real question is this — which items in the bundle are getting cheap, and where does their value go? That is not a matter of taste. It is a fairly boring question in economics, and the skeleton of the answer already exists.

The Mechanism — Bottlenecks Don't Disappear, They Move

When one stage of a process gets cheap and abundant, the bottleneck does not vanish. It moves to the next stage. And value accrues wherever the bottleneck sits. When generation gets cheap, value moves to what comes after generation — confirming the thing is correct, deciding what to build, wiring it into someone else's system.

Jason Wei has sharpened this intuition on the AI side better than anyone. His asymmetry of verification is simple — some tasks are far easier to check than to solve. Solving a sudoku takes a while; checking a finished grid is instant. From this he derives verifier's law — "the ease of training AI to solve a task is proportional to how verifiable the task is." Put more bluntly: all tasks that are possible to solve and easy to verify will eventually be solved by AI.

Most people read that law as a list of things AI will get good at. Reading it backwards matters far more. If everything easy to verify gets automated, then what is left for humans is precisely the work whose verification is expensive, slow, subjective, or has no answer key at all. That is not a consolation prize. It is a prediction.

And the bottleneck has, in fact, already moved.

  • DORA 2025 reports that roughly 90% of technology professionals now use AI. But the finding is a strange one — AI adoption has flipped to a positive relationship with throughput, while delivery instability keeps climbing. DORA's own summary is that AI acts as an amplifier, magnifying an organization's existing strengths and weaknesses alike. Raise speed without raising quality control and the bottleneck simply gets shoved downstream.
  • LinearB's 2026 benchmarks show exactly where downstream is, in numbers. Across 8.1 million pull requests from more than 4,800 organizations, AI-generated PRs wait 4.6x longer to be reviewed. PRs opened by agents have a pickup time 5.3x longer. Acceptance rates trail human code badly — 32.7% versus 84.4%. Generation exploded, and a queue formed in front of review.
  • Why that queue doesn't drain is explained by Stack Overflow 2025. 84% of developers use or plan to use AI tools, and more than half use them daily. Yet the number one frustration is "AI solutions that are almost right, but not quite" (66%), and number two is "debugging AI-generated code is more time-consuming" (45.2%). Only 3.1% report high trust in the accuracy of the output.

That last item is the hinge of this entire essay. Almost-right code is more expensive than wrong code. Wrong code gets filtered immediately. Almost-right code passes the glance, passes review, passes staging — and then detonates in production. The cheaper generation gets, the more of this arrives, and the faster. Verification cost scales with volume generated. Verification capacity does not.

What Depreciates — Things That Were Proxies for Value, Not Value

Let me name them plainly.

  • Memorized framework APIs. The model has read the docs more accurately and more completely than you have. The premium attached to remembering signatures is gone.
  • Boilerplate throughput. CRUD scaffolding, DTO mapping, config files, test fixtures — the arena where people competed on output per minute.
  • "I type fast" productivity. Typing speed was never actually the bottleneck, but there was a time it still got priced.

Here is what matters: these skills were never value in themselves. They were proxies for it. They were priced because they were scarce back when generation was the bottleneck. Remove the scarcity and you remove the price.

But depreciating is not the same as worthless. You cannot review code you cannot read. If you don't know the language and don't know the framework, none of the appreciating skills below can even start. The floor is still required. The floor is just an entry ticket now, not an advantage.

What Appreciates (1) — Verification: Not Skimming Diffs, but Supplying the Ground Truth

Clear one misconception first. The verification skill that appreciates is not "the diligence to read a diff carefully." Machines already do a great deal of that. Linters, type checkers, static analysis, AI review bots — a missing null check and an obvious race condition are on the easy-to-verify side of the line, and by verifier's law that side keeps getting automated.

What goes up in value is the part machines cannot supply — the ground truth itself. Deciding what "correct" even means for this system, in this business, at this scale. A model can make the tests pass. It cannot decide which tests should exist, because that is a fact about the business, not a fact about the code.

How to build it deliberately:

  • Write the pass condition before the model writes the code. If you cannot state the pass condition in a sentence, you don't have a requirement. You have a wish.
  • Review with a hypothesis. Before you open the diff, write down three ways this change could break production. Then go hunting for those. Reviewing without a hypothesis is spellchecking.
  • Keep a bug ledger. For every production bug, write one line: what check would have caught this? That list is the set of tests you don't have.
  • Train yourself to separate "passes the tests" from "is correct." Designing an evaluation is a skill in itself, and it is exactly the problem covered in separating signal from noise in coding evals — only a difference bigger than the noise is signal.

What Appreciates (2) — Debugging Production: When the Context Is Implicit

METR's randomized controlled trial is the most useful evidence here. Sixteen experienced open-source developers worked 246 real issues in their own repositories (averaging 22,000+ stars and over a million lines of code). Going in, they forecast a 24% speedup. Coming out, they felt they had been sped up by 20%. In fact they were 19% slower.

The reason is the decisive part. A mature repo you have worked in for years is close to a worst case for AI — the requirements are entangled with context that lives outside the repo, and the human is carrying an enormous store of local knowledge that was never written down. The model does not have it.

That is the shape of the moat. AI is weakest where the context is implicit and the failure is emergent. Production is exactly such a place. The bug is not in the diff. It is in the interaction between the diff and six years of accumulated decisions nobody ever recorded.

From my own experience — in the postmortem of KubeVirt GPU passthrough VMs that went 112 days without being scheduled, the cause was not in the repository. Nothing that only reads the repository could have found it. Same story with spinning up Postgres on CloudNativePG and killing it — you do not learn what failover actually does by reading about it. You learn it by killing the primary and measuring the 23 seconds.

How to build it deliberately:

  • Own an incident end to end and write the postmortem yourself. The learning happens in the writing, not in the firefighting.
  • Break things on purpose somewhere safe. Kill the primary. Fill the disk. Sever the network. Predict the outcome first, then measure. The gap between your prediction and the measurement is the error in your model of the system — and that model is the thing you are actually paid for.
  • Practice reading the system, not the code. Metrics, traces, kernel logs, events. Drill the loop: observe, hypothesize, experiment.
  • Debug code you did not write. This is the default now. The model wrote it. You own it.

What Appreciates (3) — System Design and Taste in Tradeoffs

A model will produce a plausible answer to any design question you ask. What it cannot do is pick which tradeoff your organization can live with for the next five years. That judgment depends on facts that are not in the repository — team size, on-call maturity, the migration you cannot afford, the vendor contract about to expire, the person who is leaving in six months.

Taste is not mystical. It is compressed memory of what blew up last time — a prior built out of consequences you personally absorbed.

How to build it deliberately: Read other people's postmortems (plenty are public). In every design doc, state explicitly what you are giving up. Write down at least two rejected alternatives and why you rejected them. Then reopen your own decisions twelve months later and grade them — without that feedback loop, taste does not grow; only stubbornness does.

One rule — a design doc with no rejected alternatives is not a design. It is a preference.

What Appreciates (4) — Requirement Archaeology: Knowing What to Build

The most expensive bug is the wrong thing, implemented perfectly. AI drives the cost of building down. Which also means you can now build the wrong thing much faster, and at much greater scale. So the ability to know what to build appreciates in exact proportion to how cheap building becomes.

Requirement archaeology is the work of excavating what people actually need out of what they said. Most real requirements are not written down anywhere. They are fossilized inside a 2019 if-statement nobody dares delete, inside a strange piece of exception handling, inside a default value in the system you are replacing.

For some roles, handling that ambiguity is the job itself — as I laid out in preparing to become a Forward Deployed Engineer, ambiguity there is not a side effect. It is the work.

How to build it deliberately: Sit next to users and watch what they actually do (it differs from what they say). Ask "what do you do when this fails?" — the real requirement usually lives in that answer. Pick the ugliest branch in the codebase and dig until you know why it exists (it is usually a requirement, not a mistake). Write a one-page problem statement before you write a design doc. And when you are going to be wrong, be wrong early, cheaply, and out loud.

What Appreciates (5) — Ownership: Being Someone Who Can Carry the Pager

You cannot put a model on the pager. Not because it isn't smart enough — because accountability requires a party that bears the consequences. Organizations want a name attached to a decision. They need someone who will wake at 3 a.m. and say "I'm rolling this back."

Be honest about what kind of claim this is. It is a social and legal fact more than a capability fact. The institutions could change. But social facts are stubborn, and they really do price labor.

Communication belongs here too. If you cannot explain a tradeoff to someone who cannot read code, you cannot get the decision made. The scarcer generation-adjacent work becomes, the more the scarce act is deciding — and deciding is inherently social.

How to build it deliberately: Take the pager. Raise your hand for the migration nobody wants. Ship something and stay attached to it for a year. The feedback loop where consequences actually reach you is the only place judgment grows.

The Counter-Argument — "Won't AI Just Do the Verification Too?"

This deserves a serious hearing. Building a weak version and beating it is self-deception.

The strongest form goes like this. Verifier's law says AI takes everything that is easy to verify — and a large share of review is easy to verify. Type errors, null dereferences, obvious races, style. AI review tools already do this well. Add test generation, fuzzing, and agents that actually execute the code and observe it, and a large share of verification does get automated. On top of that, even the METR result I cited above has been qualified by METR themselves — in their February 2026 update they announced they are changing the experiment design, and stated that as of early 2026 developers are likely more sped up than their early-2025 estimate suggested (while conceding their evidence for the magnitude is weak). So do not carry "19% slower" around as a permanent law. It was a measurement of a moment.

I concede all of that. Mechanical verification will be automated, and mostly it should be. If your "verification skill" amounts to catching a missing null check, that depreciates right along with the rest.

And yet a boundary remains. Verifying correctness requires a ground truth to check against. Where does that ground truth come from? Competition math and LeetCode have answer keys. Your company's billing system does not. Someone has to decide what correct means.

The cleanest evidence that this boundary is real comes from the DeepMind result — intrinsic self-correction, where a model revises its own answers with no external feedback, did not improve accuracy and at times made it worse. Improvement showed up only when the model was handed an oracle: the correct labels. That result is from 2023-era models, and models have improved enormously since — do not apply the specific numbers to today. But the structural point is not a function of model strength. A system checking its own beliefs against its own beliefs cannot manufacture a ground truth it does not possess.

Let me mark the uncertainty honestly. I do not know how far this boundary will move. If a model becomes better than you at deciding what "correct" means for your business, this essay's advice expires. I don't think that is close — I think the binding constraint is access to consequences, not intelligence. But "I don't think so" is a belief, not evidence. Hold it loosely.

If I had to bet, I'd bet here — even in a world where AI verifies most things, somebody still has to be accountable for the verdict, and accountability is what a job is.

Closing

Reject both poles.

"Developers are done" is wrong. It assumes the whole bundle repriced to zero, when in fact it repriced unevenly. "Nothing has changed" is also wrong — because the items many people built their careers on are precisely the items that got cheap.

Let me leave the uncomfortable part in, too. This repricing is especially harsh on juniors, because the depreciating skills were the bottom rungs of the ladder. Learning a codebase by grinding through boilerplate is a path that is closing. I do not have a clean answer for that. The best I have is get closer to consequences, faster — own something small in production and put yourself where you get paged when it breaks, earlier than feels comfortable.

The appreciating skills all share one property. Every one of them demands contact with consequences. Verification requires knowing what blows up. Debugging requires having been paged. Taste requires having been wrong. That is why you cannot download them. And for the same reason, they are hard to train into a model that has never once been paged.

One line — the price of writing code has fallen. The price of knowing whether the code is right has gone up.

References