소프트웨어 팩토리는 규모에 맞게 조정된 루프를 활용합니다. 사람이 참여하는 루프(라이트 팩토리)를 운영할 수도 있습니다. 이 경우 판단력과 집중력을 속도와 파손 가능성과 맞바꾸는 것입니다. 또는 사람을 배제(다크 팩토리)하고 에이전트가 코드를 분석하고 구축하며 배포하도록 할 수 있습니다. 단, 아무도 세부 사항을 실제로 읽지 않을 때 가능합니다. 하지만 사람들이 읽기를 중단하면, 소프트웨어를 이해하지 못하게 됩니다. 이제 가장 어려운 작업은 어떤 검증을 구축할지, 그리고 얼마나 많은 자율성을 위임할지 결정하는 것입니다.
소프트웨어 팩토리라는 개념은 Bob Bemer 의 1968년 논문 "프로그램 생산의 경제성"에서 유래했습니다. 반세기 동안 많은 사람들은 소프트웨어가 개인의 고립된 장인 정신이 아니라 반복 가능하고 계측 가능한 생산 프로세스(마치 자동차 부품을 공장에서 찍어내는 것처럼)가 되는 세상을 꿈꿔왔습니다. 역사적으로 이 꿈은 일반적으로(보편적이지는 않지만) 실패했는데, 그 이유 중 일부는 아이디어를 찍어내는 것이 어렵기 때문입니다.
하지만 지난 2년 동안 상황이 극적으로 변하여, 이제 오래된 꿈을 다시 살펴볼 필요가 있습니다. 그리고 몇 가지 미묘한 차이점이 쉽게 간과될 수 있기 때문에, 실제로 새롭고 다른 점이 무엇인지, 그리고 새로운 기회로 위장된 반복적인 함정이 무엇인지에 대해 어느 정도 정확하게 파악하는 것이 가치 있습니다.
@dexhorthy (HumanLayer 공동 창립자)는 최근 AI Engineer World's Fair에서 "Harness Engineering is not Enough: Why Software Factories Fail." 라는 훌륭한 강연을 했습니다. 이 주제에 대해 확인해 볼 가치가 있습니다.
루프가 원자입니다. 팩토리는 규모에 맞춰진 루프입니다.
구조가 모든 것이며, 모든 것은 작은 단위에서 시작됩니다. 전체 스택은 실제로 서로 계층화된 세 가지 개념입니다: 루프, 하네스, 팩토리입니다.
루프는 하나의 에이전트가 단일 작업을 반복적으로 수행하는 것입니다: 컨텍스트 수집, 조치 실행, 결과 확인, 특정 조건이 충족될 때까지 다시 시작합니다. 이것은 에이전트 작업의 가장 작은 단위이며, 그 위의 모든 것은 루프 위에 쌓인 루프일 뿐입니다.
루프 엔지니어링 의 핵심은 에이전트에게 턴마다 프롬프트를 제공하는 것을 중단하고 대신 에이전트를 대신해 프롬프트를 제공하는 작은 시스템을 설계하는 것입니다.
하네스는 루프 주변의 경계입니다: 루프가 실행되는 샌드박스, 도달할 수 있는 도구, 실행 간에 유지되는 메모리, 그리고 "완료"가 무엇을 의미하는지 결정하는 게이트입니다. 루프는 행동이고, 하네스는 그 행동이 실행되는 환경입니다.
하네스 없이 원시 모델을 제공하면 모델은 행복하게 영원히 회전할 것입니다. 하네스는 모델을 유용하고 안전하게 실행할 수 있게 해주는 모든 것입니다.
소프트웨어 팩토리는 여러 개의 하네스 처리된 루프가 동시에 실행되는 것입니다. 작업 큐에서 공급되고 검토 게이트를 통해 프로덕션으로 배출되며, 인간이 전체를 총괄합니다. 이것은 더 큰 에이전트가 아니라 루프로 구성된 조직도입니다.
최종 패러다임 전환은 코드를 작성하는 것에서 코드를 작성하는 팩토리 를 구축하고 실행하는 것으로 이동하는 것입니다. 작업 단위는 개별 코드 diff가 아니라 루프, 하네스 및 그 사이의 흐름으로 한 단계 위로 올라갑니다.
루프 → 하네스 → 팩토리. 팩토리는 더 똑똑한 에이전트가 아닙니다. 하나의 검토 게이트에 공급되는 여러 하네스 처리된 루프이며, 인간이 외부 루프를 소유합니다. 그려진 팩토리
Dex가 가장 많은 시간을 할애한 중심 슬라이드는 명확한 배선 다이어그램으로, 그렇지 않으면 당연해 보이는 루프를 시각화하기 때문에 훌륭했습니다. 제 해석은 다음과 같습니다:
팩토리는 폐쇄 루프입니다: 의도와 프로덕션 신호가 큐에 공급되고, 하네스가 구축하며, 자동화된 검사와 검토 게이트가 통과시키고, 배포가 출시하며, 모니터링이 프로덕션을 다시 신호로 전환합니다. 의도는 엔지니어링 리더십의 비전과 엔지니어로부터 직접 큐로 흘러들어가 해야 할 일 목록이 됩니다. 인시던트와 사용자 요청에 의해 생성된 신호도 동일한 큐를 구동합니다.
하네스는 단순히 큐에서 항목을 선택하고 이에 대한 변경 사항을 구축하는 것입니다. 하네스를 넘어, 변경 사항을 프로덕션에 반영할 수 있을 만큼 안전하게 만드는 데 필요한 모든 자동화된 검사를 볼 수 있습니다. 이러한 자동화된 검사는 CI, 테스트, 정적 분석 및 모든 종류의 스캐닝 덕분에 엔지니어의 의식적인 개입 없이 한 번에 쉽게 실행됩니다. 여기서 유일한 결정 지점은 검토 게이트입니다. 승인 후 변경 사항은 프로덕션에 배포 및 모니터링되며, 모니터링 데이터는 루프를 시작하게 한 신호로 다시 피드백됩니다.
대체로 이 다이어그램의 모든 상자는 거의 비용이 들지 않습니다: 생성, 테스트, 스캐닝. 모두 무시할 수 있는 비용으로 규모에 맞게 실행됩니다. 확장에 완고하게 저항하는 값비싼 상자는 단 하나, 바로 검토 게이트입니다. 그 반짝이는 호박색 상자는 "판단"이며, 개발 속도를 더 빠르고 빈번하게 만들 수 있는지에 대한 논쟁의 핵심이 있습니다.
"다크"라고 부르는 이유
다크 팩토리는 조명이 물리적으로 꺼진 상태로 운영됩니다. 바닥에 있는 유일한 것은 기계이고, 기계는 보기 위해 빛이 필요하지 않기 때문입니다. 다크 소프트웨어 팩토리도 마찬가지입니다: 어떤 인간도 읽지 않은 코드가 출시되며, 다른 기계에 의해서만 검증됩니다.
이 이미지는 제조업에서 차용했습니다. 그 기원은 디지털이 아닌 물리적이며, 조명이 꺼지고 작업이 로봇에 의해 수행되는 시설에 뿌리를 두고 있습니다. 일본의 FANUC는 2001년부터 이러한 종류의 무인 팩토리를 운영해 왔습니다; 샤오미는 2024년에 자체적으로 고도로 자동화된 다크 팩토리를 열었습니다. 이들의 공통점은 단 한 명의 인간도 제품을 읽지 않고 조립 및 출시한다는 것입니다. "다크"는 이러한 읽기 행위가 프로세스에서 제거될 때 발생합니다.
저는 분위기나 모욕을 위해 이 개념을 빌리는 것이 아닙니다. 으스스한 유행어에도 불구하고, 여기서 "다크"는 단순한 물리적 주장입니다: 원래 공장 바닥이지만 빛이 없는 것입니다. 소프트웨어에서 바닥은 diff입니다. diff를 작성한 사람, 검토한 사람, 출시한 사람, 그 인간들은 사라지고, 남은 것은 그것을 구축한 기계에 의해서만 검증된 diff입니다.
이것은 적어도 처음에는 놀라울 정도로 쉬운 일입니다. 빠진 검토 단계가 모든 것을 방해하기 때문에 쉽습니다. 그 단계가 없으면 팀의 수직적 처리량에 대한 인식이 갑자기 극적으로 높아집니다. 마치 음속 장벽을 깬 것처럼 느껴집니다. 겉보기에는 쉬워 보이지만, 숨겨진 비용이 있는 이러한 다크 워크플로우에서 살아남는 것은 생각보다 어렵습니다.
하네스 엔지니어링만으로는 충분하지 않습니다
오케스트레이션, 샌드박스 프로토타이핑, 모델이 세계 및 서로와 상호 작용할 때의 도구 호출의 하네스는 점점 더 강력하고 효과적이 될 것입니다. 그러나 장기적인 게임과 추가 변경을 통해 코드베이스 품질을 유지하려는 노력에는 본질적인 모델 내 실패가 있으며, 모델만으로는 궁극적으로 이해 부채 와의 싸움에서 패배할 것이라고 믿을 만한 충분한 이유가 있습니다.
이해 부채는 존재하는 코드의 양과 어떤 인간이 여전히 이해하는 양 사이의 벌어지는 격차입니다. 다크 팩토리는 이 부채를 상환하지 않습니다. 가능한 한 빠르게 부채를 떠안으며, 테스트는 항상 통과합니다.
모델이 일부 작업을 잘 수행하기 때문에 이것은 중요한 구분입니다. 그러나 코드베이스의 작은 부분에 대한 즉각적인 변경이 아닌 모든 것, 특히 복잡한 브라운필드 시스템에서 모델 전용 자동화 코딩은 극복할 수 없는 장애물에 직면합니다. 그린필드 앱, 주말 장난감 및 사이드 프로젝트는 모두 몇 달의 개발 주기로 작동 상태를 만들거나 적어도 충분히 가깝게 만드는 데 충분하다는 점에서 유사합니다.
그러나 10년 이상 개발된 엔터프라이즈 시스템은 다른 짐승입니다. 전문적인 환경에서 전문적인 속도로 유지 관리되어야 합니다. 프로젝트 시작 후 3~6개월이 지나면 이미 읽지 않은 코드에 빠져들게 됩니다. 그러한 종류의 환경, 특히 프로덕션 코드에 의해 강제되는 제약 조건은 강력한 에이전트조차도 제대로 수행하지 못하게 할 것이며, 이는 주말 장난감을 작업하는 개발자들이 즐기는 바이브 코딩과 대조적입니다.
Dex는 경험상 이것이 주요 실패 지점이라고 보고하며, 이를 정확히 찾아내기 위해 고통스러운 수동 디버깅이 필요할 정도라고 합니다. 이는 약 4개월 동안 완전 자동화된 코드 팩토리를 운영하면서 비롯되었으며, 그 동안 아무도 작성된 코드를 보지 않았습니다. 이러한 경험의 기저에는 상충되는 두 가지 지표 간의 트레이드오프가 있습니다. 하나는 현재 우리가 진보로 간주하는 숫자인 토큰 활용도를 최대화하는 것입니다. 다른 하나는 조용히 최소화하는 것으로, 어떤 인간 참가자가 특정 시점에 여전히 이해하는 시스템의 양입니다.
다크 팩토리가 진정으로 빛나는 점은 테스트가 통과하는 동안 완벽한 코드를 빠르게 소모하는 능력입니다. 궁극적인 대가가 치러질 때, 그것은 극적인 "모든 것이 잘못되는" 순간이 아닐 것입니다. 그것은 조용하고 늦게 올 것입니다.
다크와 라이트는 조명이 다른 위치에 있는 동일한 파이프라인입니다. 라이트 버전은 단순히 검토를 끝에 다시 추가하는 것이 아닙니다. 인간의 판단을 설계 및 아키텍처로 업스트림 이동시킵니다. 병목 현상은 결코 생성이 아니었습니다.
소프트웨어 팩토리의 근본적인 제약 조건은 얼마나 많은 코드를 쏟아낼 수 있는지가 아니라 얼마나 빨리 검증할 수 있는지입니다.
백프레셔는 루프에 저렴하고 안정적으로 검증할 수 있는 만큼의 자율성만 부여할 수 있다는 규칙이며, 그 이상은 안 됩니다. 생성이 아니라 검증이 팩토리의 실제 제약 조건입니다.
무제한의 생성 능력은 유한하고 확장 불가능한 인간의 주의력 자원과 영원히 긴장 관계에 있기 때문에, 핵심 문제는 저렴한 생성과 제한된 검토 사이의 격차입니다. 깔때기를 보십시오: 검증을 나타내는 목이 넓어지지 않는 한, 역류할 것입니다. Dex가 지적했듯이, 볼륨 자체가 문제가 아닙니다. 우리가 실제로 겪고 있는 것은 나쁜 PR의 과잉입니다. 신뢰할 수 있는 게이트 없이 높은 볼륨이 있을 때, 제조된 결함은 불가피합니다. 이것은 다시 백프레셔입니다: 자율성은 저렴하고 안정적으로 검증할 수 있는 범위를 넘어 확장될 수 없습니다.
2차 문제는 모델을 개선한다고 해서 모델이 생성할 수 있는 것과 검증할 수 있는 것 사이의 격차가 자동으로 좁혀져서는 안 되는 이유입니다. 잘 설계된 시스템에 대한 훈련은 단순한 테스트를 통과하는 것보다 훨씬 더 어려운 제안입니다. 기억하십시오: 아키텍처 우수성을 측정하는 비용 함수는 초 또는 분 단위가 아니라 몇 달 및 몇 년 단위로 측정됩니다. 깔끔한 그래디언트는 사실상 계산이 불가능하므로, 복잡한 설계 결정에 대한 선명하고 즉각적인 평가를 기대하는 시스템은 좋은 예제에 대해 훈련되지 않을 것입니다.
생성은 넓은 입이고, 검증은 좁은 목입니다. 입을 빠르게 하는 것은 목에서 쌓이는 양만 늘릴 뿐입니다.
다시 불을 켜기
라이트 팩토리는 판단이 있는 곳에 조명을 켜둔 동일한 파이프라인입니다. 에이전트는 여전히 대부분의 구축을 수행하지만, 인간은 출시 전에 결과물을 읽고, 잘못된 결정이 비용이 많이 드는 곳에서는 조명이 계속 켜져 있습니다.
라이트 버전은 검토를 끝에 추가하는 것이 아니라 인간의 판단 지점을 업스트림, 즉 에이전트가 루프를 시작하기 전에 제품, 설계 및 아키텍처로 이동시킵니다.
그 사전 시간의 좋은 점은 구현 시간을 줄여준다는 것입니다. 길고 좌절스러운 코드 리뷰를 200줄짜리 계획에 대한 빠른 읽기로 바꿔줍니다. 결정이 구축되기 전에 검토할 수 있으므로, 나중에 생성된 2000줄의 코드를 뒤져서 결정이 무엇이었는지 알아낼 필요가 없습니다. 일부 결정은 비용이 많이 들고 오래 지속되어 비용이 복리로 증가하기 전에 초기에 사람을 참여시키는 것이 좋습니다. 물론, 사전에 시간을 들였더라도 diff를 살펴봐야 하는 경우도 여전히 있습니다.
이 모든 것이 화려하지 않게 들릴 수도 있습니다. 맞습니다. 안전망은 우리가 항상 알고 있었고 대부분 무시해 온 평범한 아키텍처 관행으로 구성됩니다: 좋은 타입과 메서드 시그니처는 프로덕션 대신 컴파일러에서 실수를 잡아내도록 합니다; 동작을 고정하고 변경 사항을 관찰 가능하게 만드는 테스트 지점; 코드를 배치하여 다음 독자(인간이든 모델이든)가 관심 있는 것을 찾을 수 있는 위치를 알 수 있도록 합니다; 호출 스택을 짧고 읽기 쉽게 유지합니다; 변경 사항의 폭발 반경이 크지 않도록 컴포넌트 경계를 잘 정의합니다; 한 부분을 다른 부분으로 교체할 수 있도록 의존성 주입을 사용합니다. 이 중 어느 것도 새로운 것이 아닙니다. 우리는 항상 좋은 아키텍처에 관심이 있다고 말해왔습니다. 하지만 이제 자동화 코딩 에이전트를 사용하고 있기 때문에, 그 아키텍처는 마침내 에이전트가 저지를 실수에 대한 저렴하고 위조하기 어려운 안전망이라는 두 번째 역할을 수행하고 있습니다.
그 안전망은 모델 외부에 존재해야 합니다. 모델이 그것을 제공하지 않을 것이기 때문입니다. 가장 능력이 뛰어난 것으로 느껴지는 코딩 에이전트(Claude Code 및 Codex 등)는 자체 하네스와 도구에 대해 강화 훈련을 받았습니다: 해당 분야의 모든 도구와 관용구에 능숙하지만, 장기 유지보수성과 같은 것에는 능숙하지 않습니다. 우리가 항상 이야기해 온 의도적인 아키텍처는 그 부채를 잡아내는 도구이며, 우리가 그 아키텍처에 투자하는 것은 우리의 자율성을 되찾는 것입니다.
이를 안전한 인프라와 결합하면 감독 없이 실행할 수 있는 확실하고 위험이 적은 루프가 있습니다. Horthy는 최근 게시물에서 하나를 설명했습니다: 야간 GitHub Actions cron 작업이 정확히 하나의 안티패턴(린트 위반 또는 불필요하게 선택적인 prop)을 수정하고, 커밋하고, 자체적으로 하나의 작은 풀 리퀘스트를 열어서 팀이 약간 더 나은 코드베이스와 읽을 수 있을 만큼 짧은 diff와 함께 일어나도록 하는 것입니다. 그러나 이해 관계가 충분히 높은 루프의 경우, 망가진 인증 시스템, 결제 엔진 또는 공개 API 계약과 함께 일어나고 싶지 않을 것입니다. 그곳에서는 조명을 계속 켜두고, 판단력과 시스템에 대한 실제 작업 지식을 가진 사람이 실수를 잡을 것이라고 신뢰하십시오.
무엇이 루프를 다크 상태로 만들 수 있는가
이 규칙은 백프레셔, 검증 또는 조명 스위치라고 부르든 적용됩니다.
루프는 검사가 저렴하고, 높은 빈도로 실행되며, 쉽게 속일 수 없는 것에 의존하는 경우에만 완전 자동화 상태를 얻을 수 있습니다. 녹색-빨강 오라클, 타입 게이트, 속성 기반 테스트, 실제 루브릭과 결합된 검토 에이전트가 모두 해당됩니다. 또한 오라클이 즉시 응답하고 시간이 지나도 변하지 않아야 합니다. 완료가 당신뿐만 아니라 기계에 의해 증명될 수 있을 때, 자동화에 도달한 것입니다.
짧은 루프는 긴 루프보다 검증하기 쉽습니다. Dex의 경험 법칙: 에이전트는 3~10단계까지 잘 유지되다가 20단계를 넘어가면 맥락을 잃기 시작합니다. 그 이유는 컨텍스트 축적입니다. 에이전트가 더 많이 끌고 갈수록 길을 잃을 가능성이 높아집니다. 루프가 짧으면 검증 비용이 저렴합니다. 방대한 루프는 모서리에 실수를 숨기며, 이는 결코 무인 상태를 얻지 못했다는 것을 의미합니다.
조명을 계속 켜두는 것은 반대의 경우입니다. 잘못된 답변의 비용이 많이 들고 사람만이 잡을 수 있는 경우 루프를 검토해야 합니다. 테스트로 잡을 수 없는 미묘한 프로덕션 버그, 큰 폭발 반경, 1년 이상의 작업을 형성할 결정이 모두 해당됩니다. 이러한 경우, 당신의 주의력이 실제 제품 이며, 비용이 많이 들고 필수적인 것입니다.
위험은 각 스위치를 개별적으로 전환하는 것을 잊고 모든 스위치를 동일한 모드로 설정하는 것입니다. 모두 다크로 설정하면 4개월 후에 모든 것을 철거해야 합니다. 모두 라이트로 설정하면 아무도 제때 검토를 완료할 수 없어 거대한 병목 현상에 빠지게 됩니다. 어려운 숙련된 작업은 각 스위치를 어디에 둘지 결정하는 것입니다.
루프, 그래프 또는 상태 머신?
@DavidKPiano 의 "2분 안에 상태 머신"을 읽어보시기 바랍니다.
에이전트에게 작업을 할당할 때, 아마도 그 주변에 그래프를 구축하게 될 것입니다. 그 그래프를 유한 상태 머신 또는 조건부로 연결된 서비스 호출 집합이라고 부르든 상관없습니다. 소프트웨어가 추상적인 규칙을 따르는 것이 아니라 구조화된 워크플로우를 따르는 프레임입니다: 모든 노드는 명시적인 단계이고, 노드 사이의 모든 가장자리는 명시적인 조건입니다.
많은 구조처럼 들리지만, 대부분은 이미 모든 소프트웨어에 존재합니다. 모든 코드는 제어 흐름 그래프로 표현될 수 있기 때문입니다. 따라서 유일한 진정한 참신함은 자율성을 주장하는 에이전트가 실제로 특정 그래프를 따라 걷고 있으며, 그 자유가 노드 내부로 제한된다는 것입니다. 그리고 사람들이 잊는 부분이 있습니다. Dex가 1년 전에 기록 한 것처럼, 소프트웨어는 항상 그 구조를 가질 예정이었습니다. 우리가 예전에 프로그램을 순서도로 그리던 데는 이유가 있습니다.
진정으로 새로운 움직임은 다이어그램을 버리고, 모델이 도구 호출별로 경로를 선택하여 스스로 완료를 선언할 때까지 반복하는 루프에 의존하는 것이었습니다. 그것은 10년 된 코드베이스를 만나기 전까지는 해방처럼 느껴졌습니다. 그리고 지금 모든 사람이 재발견하고 있는 규율, 즉 제어 흐름을 소유하는 것은 실제로 그래프를 루프 주위로 다시 걷는 것입니다. 따라서 루프에서 그래프로 다시 전환해야 하는지에 대한 질문은 사실상 처음부터 순서도가 필요했다는 인정에 가깝습니다.
실제로는 이렇게 보입니다. 수정해야 할 버그가 있다고 가정해 보겠습니다. 순수한 루프로서, 앉아서 생각합니다: 무엇이 잘못되었는지 파악하고, 일부 코드를 변경하고, 테스트를 실행하고, 결과를 확인하고, 해당 라운드가 실행을 종료하지 않으면 다시 루프백하여 다시 시작합니다. 전체 과정은 진행하면서 결정됩니다: 어떤 문제를 쫓을지, 정확히 어떤 코드를 변경할지, 어떤 테스트를 어떤 순서로 실행할지, 테스트를 전혀 실행할지 여부, 다시 시도할지 또는 승리를 선언할지.
그래프로서, 가장 먼저 하는 일은 무엇이 일어나야 하는지 매핑하는 것입니다. 버그를 재현하거나 추가 정보를 요청하고, 원인을 찾고, 수정을 시도하고, 테스트를 실행하고, 실패한 실행은 수정으로 다시 라우팅하고 통과한 실행은 검토로 진행하여 승인만이 완료에 도달하도록 합니다. 에이전트는 여전히 각 상자 내에서 똑똑합니다. 단지 당신이 승인한 경로를 벗어날 수 없을 뿐입니다. Santi는 이 차이점을 명확하게 보여주는 다이어그램으로 이를 설명했습니다.
물론 그래프의 진정한 매력은 다이어그램으로 그려진 백프레셔라는 것입니다. 에이전트의 자유를 일부 포기하는 대신 필수 검사와 읽기 쉬운 실패 지점을 얻습니다. 따라서 실행이 중단되면 이를 중단시킨 노드를 가리킬 수 있습니다. 이것은 대부분의 소위 에이전트가 실제로는 그다지 에이전트적이지 않다는 Dex의 직설적인 발언, "대부분 결정론적 코드이며, 정확한 지점에 LLM 단계가 뿌려져 있다"는 말과 동일한 본능입니다. 그리고 이것은 사람들이 현재 우연히 구축하는 방식의 결과물일 뿐만이 아닙니다. LangGraph 및 LlamaIndex Workflows, 실행될 때 그래프의 일부를 성장시키는 외부 루프를 가진 Jerry Liu의 하이브리드 워크플로우-그래프-오버-에이전트, 그리고 이것이 실제로는 새로운 옷을 입고 나타난 상태 머신과 액터 모델에 불과하다는 David Khourshid의 상기시킴에서 패턴을 볼 수 있습니다.
용어가 심하게 과부하되어 있기 때문에 한 가지 명확히 하자면: 제가 계속 이것을 그래프라고 부를 때, 지식 그래프를 의미하는 것이 아닙니다. 저는 작업이 어떻게 흘러야 하는지에 대한 미리 정의된 방향성 그래프(조건부 가장자리 포함)를 의미하며, 루프에 실제로 신뢰할 수 있는 형태를 부여합니다.
인간이 실제로 가는 곳
사람은 결코 공장을 떠나지 않았다는 점에 유의하십시오. 그들은 이동했습니다.
저는 엔지니어들이 점점 더 외부 루프 를 소유해야 한다고 생각합니다. 에이전트는 버그를 조사하고, 진단을 작성하고, 수정을 구현하고, 테스트를 실행하고, 보고서를 작성할 수 있습니다. 이것이 내부 루프의 실행이며, 그들은 누구보다 효율적으로 수행할 수 있습니다. 그러나 그것은 결코 본질적인 작업이 아니었습니다. 당신이 소유하는 부분은 제가 외부 루프라고 부르는 것입니다: 문제를 해결하는 올바른 방법인지 결정하고, 진단과 구현이 타당한지 확인하며, 변경 사항을 승인하고, 잘못되었을 때의 결과를 감당하는 것입니다. 두 루프 사이의 경계는 증거, diff, 테스트, 로그 및 이를 연결하는 간략한 설명입니다. 타입, 지점 및 루브릭을 사용하면 모든 변경 사항에 대해 많은 작업을 수행하지 않고도 이를 감독할 수 있습니다.
이렇게 표현하는 것이 유용합니다: 당신은 더 이상 라인 아래에서 변경 사항을 작성하는 것이 아닙니다. 당신은 생산 라인의 끝에서 이를 설계하고 게이트를 지키고 있습니다. 모델을 개선하고 하네스의 기능을 향상시키기 위해 할 수 있는 일이 많지만, 장기적으로 비용이 많이 드는 문제를 식별하는 것은 일반적으로 자동화할 수 있는 것이 아니라는 것을 관찰했습니다. 여전히 작업의 핵심은 종이와 컴퓨팅 성능의 흐름보다 더 나은 인간의 판단력을 행사하는 것입니다.
로봇은 어둠 속에서도 잘 작동하지만, 인간은 그들이 무엇을 하고 있는지 볼 수 있어야 합니다. 공장 바닥의 모든 것이 어둡고, 아무것도 볼 수 없으며, 심지어 조명 스위치조차 찾을 수 없다면, 거기에 위험이 있습니다.
Pangram은 이 기사를 100% 인간 작성 으로 평가했습니다.
