이전 게시물에서 검증이 제가 에이전트로 하는 모든 일의 기초이며, 직접 검증 스킬을 만드는 방법을 보여드렸습니다. 핵심 교훈은 에이전트가 자신의 작업을 검증할 수 없다면 다른 모든 것은 의미가 없다는 것이었습니다. 여러분이 병목 현상이 되어 하루 종일 에이전트를 돌보느라 시간을 보내게 될 것입니다.
https://x.com/poteto/status/2094457600259842065
하지만 검증이 작동하게 되면 다음 질문은: 실제로 무엇을 구축할지 어떻게 파악할 것인가입니다.
https://x.ai/bot/plugin/9717366
이번 게시물에서는 pstack을 사용하여 리서치, 계획, 프로토타이핑, 아키텍처를 어떻게 수행하는지 단계별로 안내해 드리겠습니다. 이것이 바로 제가 코드 품질을 매우 높게 유지하면서 한 달에 수천 개의 PR을 프로덕션에 배포할 수 있게 해주는 정확한 워크플로우입니다.
8월을 프로덕션에서 2,462개의 PR로 마무리하며
나보다 똑똑한 사람을 감독하는 기술
2024년의 옛날에는 시스템을 변경하려면 먼저 코드를 충분히 읽어서 무슨 일이 일어나고 있는지에 대한 멘탈 모델을 구축해야 했습니다. 코드베이스의 크기와 복잡성에 따라 몇 시간에서 며칠, 심지어 몇 달이 걸릴 수도 있었습니다. 작은 변경이라면 작은 하위 시스템에 대한 국지적인 이해만으로도 충분했을 수 있습니다. 하지만 코어를 리팩토링하는 경우라면, 리팩토링을 정확하고 효과적으로 수행하기 위해 전체 시스템이 어떻게 작동하는지에 대한 멘탈 모델이 필요했을 것입니다.
에이전트는 분명히 이 장벽을 제거합니다. 코드에 대해 얼마나 많이 알든 적게 알든, 에이전트에게 프롬프트만 주면 에이전트가 알아서 시스템을 쉽게 변경할 수 있습니다. 하지만 코드 품질과 사용자 경험을 높게 유지하는 것은 여전히 어렵습니다. 특히 무엇을 찾고 질문해야 할지 아는 도메인 전문가가 아니라면 더욱 그렇습니다.
프론티어 모델이 매우 강력해졌음에도 불구하고, 제가 지속적으로 관찰하는 두 가지 실패 모드가 있습니다:
- 에이전트가 사양이 부족하거나 잘못 지정되어 사용자의 의도를 완전히 이해하지 못합니다.
- 작업을 올바르게 수행하는 방법에 대한 충분한 컨텍스트가 없습니다.
이 두 문제는 모두 관련되어 있습니다. 에이전트를 잘 사용하는 것은 에이전트의 컨텍스트 윈도우에 고품질 컨텍스트를 얼마나 잘 제공할 수 있는지에 달려 있습니다. 이렇게 하지 않고도 작동하는 코드를 작성할 수는 있지만, 에이전트가 고품질 작업을 수행하는 데 필요한 모든 것을 제공하기 위해 노력했을 때 결과물과 품질이 훨씬 더 좋다는 것을 알게 되었습니다.
자신의 언어로
프론티어 모델은 매우 능숙한 코더입니다. 이전 모델에서는 내가 원하는 것을 매우 구체적으로 프롬프트하여 거의 마이크로 매니징하는 경향이 있었지만, 최신 모델은 나나 당신보다 더 나은 코드를 작성할 수 있습니다. 따라서 에이전트에게 달성하고자 하는 바를 알려주면서도, 내가 생각하지 못한 방식으로 문제를 해결할 자유를 주는 미묘한 균형을 유지하고 싶습니다.
이것이 바로 자신보다 똑똑한 사람을, 자신이 직접 작성하지 않은 코드베이스에서, 그리고 인간이 더 이상 코드베이스의 전체 멘탈 모델을 머릿속에 담을 수 없는 상황에서 감독하는 기술입니다.
제가 좋아하는 기법 중 하나는 간접 프롬프트입니다. 에이전트에게 내가 원하는 것을 정확히 알려주는 대신, 에이전트 스스로가 자신의 언어로 표현하도록 유도하는 것입니다.
예를 들어, 누군가 Slack에서 이슈를 보고하면, 저는 종종 에이전트에게 다른 작업을 하기 전에 먼저 스레드를 읽고 문제를 자신의 언어로 다시 진술하도록 요청합니다.
예를 들어, 이렇게 말할 수 있습니다:
/poteto-mode 이 slack 스레드를 읽어봐. 네 자신의 언어로, 평범한 영어로 근본적인 문제가 무엇이라고 생각하는지 다시 말해줘
이것은 세 가지를 달성합니다:
첫째, 에이전트가 시끄러운 대화를 구조화된 문제 설명으로 압축하도록 강제합니다. 둘째, 오해를 즉시 발견할 수 있게 해줍니다. 에이전트가 스레드에서 잘못된 단서에 집착한다면, 코드 작성을 시작하기 전에 빠르게 수정할 수 있습니다.
셋째, 제 자신의 가정과 가설을 제시함으로써 잠재적으로 잘못된 길로 에이전트를 이끌 가능성을 줄입니다. 제 가정이 틀렸거나 에이전트가 달성할 수 있는 것을 제한할 수 있기 때문입니다.
멘탈 모델 구축하기
에이전트가 자신보다 똑똑한 사람과 함께 일할 때, 에이전트가 이해할 수 있는 방식으로 스스로를 다시 진술하도록 요청하는 것은 중요한 부분입니다. 이것이 바로 에이전트가 직관적인 방식으로 사물을 설명하도록 도와주는 스킬인 /teach의 영감이었습니다. 저는 에이전트가 제게 이해가 되는 작업을 하고 있는지 확인해야 할 때마다 이 스킬을 사용합니다.
내부적으로 /teach는 /how와 /why를 호출합니다.
/how는 런타임 메커니즘을 추적합니다. /how를 요청하면 에이전트는 하위 시스템의 복잡성을 평가합니다. 하위 시스템이 여러 디렉토리나 서비스에 걸쳐 있는 경우, Grok과 같은 빠르고 효율적인 모델에서 병렬 탐색 에이전트를 생성합니다.
/how 가상화는 어떻게 구현되어 있나요?
/why는 동기와 의도를 조사합니다. 코드는 무엇이 일어나는지 알려줍니다. 누군가가 왜 그렇게 작성했는지는 거의 알려주지 않습니다. /why를 실행하면 pstack은 Git 히스토리 및 PR 리뷰 코멘트, Linear 티켓, Notion 디자인 문서, Slack 대화, Datadog 모니터, Sentry 오류, 코드 계보, 분석 웨어하우스 이벤트 등 여러 소스에서 병렬로 과거 증거를 쿼리합니다.
/why 우리는 왜 아직도 오래된 node.js 버전에 갇혀 있나요?
저는 에이전트가 어떤 것을 다시 진술하여 더 잘 이해하고 신뢰할 수 있도록 하고 싶을 때마다 /teach를 사용합니다.
/teach 왜 이렇게 구현했고 <다른 방법>으로는 하지 않았는지 알려줘. 어떤 트레이드오프를 했고 그 이유는 무엇인가요?
실제로 저는 /teach 스킬이 수행하는 리서치가 인간에게만 유용한 것이 아니라 에이전트에게도 유용하다는 것을 발견했습니다. 최신 프론티어 모델을 사용하더라도 (이것은 하네스의 품질에 따라 달라지기도 하지만), 일반적으로 에이전트는 데이터로 뒷받침하거나 실제로 코드를 읽어서 작동 방식에 대한 멘탈 모델을 구축하지 않고 자신 있게 진술하는 경우가 많다는 것을 알게 되었습니다. 따라서 에이전트가 무엇을 할 것인지, 왜 그렇게 할 것인지를 가르쳐주는 이 행위는 결국 에이전트에게도 도움이 됩니다.
역사로부터 배우기
제 프로젝트 중 상당수는 여러 대화에 걸쳐 있습니다. 예를 들어, 몇 달 전 저는 Cursor에서 사람들이 보고하던 가상화 버그와 성능 문제를 수정하는 작업을 하고 있었습니다. 새로운 채팅을 시작할 때마다 이전에 비슷한 문제를 해결할 때 에이전트가 가지고 있던 풍부한 컨텍스트를 기본적으로 처음부터 다시 구축해야 한다는 것을 깨달았습니다.
제가 깨달은 것은 과거의 대화 기록이 종종 풍부한 컨텍스트의 금광이라는 것입니다. pstack에는 채팅 기록에서 최근 컨텍스트를 가져오는 /recall 스킬이 포함되어 있어, 새로운 에이전트라도 좋은 상태로 돌아가는 데 필요한 올바른 컨텍스트를 가질 수 있습니다.
/recall 내가 어제 가상화에 대해 했던 작업을 불러오고, 이 slack 버그 리포트를 읽어봐
/teach, /recall, /how, /why를 사용하는 것은 제가 코드베이스에 대한 자신의 멘탈 모델을 최신 상태로 유지하고, 쉽게 이해하고 기억할 수 있는 형태로 압축하는 방법입니다. 그리고 에이전트에게도 도움이 됩니다!
거꾸로 작업하기
문제를 이해했다면, 어떻게 솔루션을 지정할까요?
제 생각에, 플랜 모드가 있는 대부분의 하네스는 구현 세부 사항을 과도하게 지정하고 다른 모든 것은 과소 지정하는 경향이 있습니다. 그렇기 때문에 pstack에서 저는 "나는 계획을 믿지 않는다"고 건방지게 말했습니다. 사실 저는 계획을 세우지만, 코드를 통해 계획을 세웁니다.
다른 사람들이 사용할 공유 코드나 패키지를 만드는 것과 같은 특정 종류의 작업의 경우, 저는 readme 주도 개발을 강력히 믿습니다. 이에 익숙하지 않다면, 옛날에 유행했던 개발 기법으로, 먼저 readme를 작성하는 것부터 시작하는 것입니다. 이렇게 하면 개발자 경험 모자를 쓰게 되어, 가상의 사용자에게 API를 설명하는 것부터 시작하여 구현과 아키텍처로 거꾸로 작업하게 됩니다.
예를 들어, 데스크톱 앱용 사내 클라이언트 프레임워크인 Dune을 구축할 때, 먼저 튜토리얼을 작성하여 이 프레임워크로 앱을 빌드하는 것이 어떤 느낌일지 이해하려고 했습니다. 적어도 시도는 했습니다. 에이전트가 좋은 것이나 읽을 수 있는 것을 만들어내도록 하는 것은 정말 힘든 싸움이었습니다. 그래서 먼저 /technical-writing 스킬을 만들어서 제 도구를 갈고 닦는 데 시간을 투자해야 했습니다.
/technical-writing 스킬 없이 첫 번째 버전의 readme는 읽기가 고통스러웠습니다. 튜토리얼, 방법 가이드, 아키텍처 설명, API 참조를 모두 하나의 문서에 섞어 놓았고, 평소의 AI 슬롭과 매너 있는 산문으로 작성되었기 때문입니다.
/technical-writing은 Diátaxis 프레임워크를 사용하여 문서를 네 가지 뚜렷한 모드로 분리합니다:
- 튜토리얼: 직접 해보면서 배우기. 신규 사용자가 눈에 보이는 무언가를 만들기 위해 일련의 단계를 따라가는 수업입니다.
- 방법 가이드: 숙련된 사용자를 위한 구체적이고 실제적인 문제를 해결하는 단계입니다.
- 참조: 기계, API, 구성 플래그에 대한 건조하고 완전하며 권위 있는 기술 설명입니다.
- 설명: 배경, 디자인 선택, 트레이드오프를 명확히 하고 조명하는 높은 수준의 논의입니다.
또한 /unslop을 사용하여 매우 읽기 쉬운 문서를 생성합니다.
이런 식으로 계획을 작성하는 것은 에이전트에게 자신의 작업을 확인할 수 있는 구체적인 목표와 목적을 제공하기 때문에 매우 유용합니다. 그리고 물론 에이전트가 정확히 무엇을 구축할 것인지 이해하기도 훨씬 쉽습니다.
pstack의 많은 스킬은 설계 단계에서 여기서 결합됩니다. 예를 들어:
(1) /recall 지난 7일 동안 가상화 버그 및 성능 이슈를 수정한 내 작업을 불러와. /how와 /why를 사용하여 현재 가상화 구현이 어떻게 작동하는지 이해해.
(2) 그런 다음 /poteto-mode planning과 /technical-writing을 사용하여 깜빡임과 떨림을 완전히 제거하는 새로운 가상화 엔진을 구상해 보자. 이 새로운 패키지를 사용하여 React 앱을 가상화하는 방법에 대한 튜토리얼을 작성하는 것부터 시작하자.
(3) 계획을 작성한 후, /teach me를 사용하여 이 새로운 접근 방식이 현재 엔진보다 왜 우수한지 증명해 봐.
여기서 핵심 기술은 에이전트가 문제를 당신과 같은 방식으로 볼 수 있게 해주는 흥미롭고 풍부한 컨텍스트를 이끌어내는 것입니다. 단지 작은 조각으로 보는 것이 아니라:
- 프롬프트의 첫 번째 부분은 내 앱에서 가상화가 어떻게 구현되는지에 대한 관련 과거 및 현재 컨텍스트를 불러옵니다.
- 두 번째 부분은 에이전트가 해당 컨텍스트(예: 이전에 수정한 버그)를 사용하여 이러한 문제를 완전히 제거하는 새로운 설계를 도출하도록 안내합니다.
- 마지막 부분은 에이전트에게 이 새로운 패키지가 우수하다는 것을 증명하도록 요청하는 것입니다. 이것이 바로 검증 스킬과 같은 고품질 도구가 중요한 이유입니다.
백 번 재고, 한 번 자르라
계획을 세울 때 제가 가장 자주 보는 두 가지 실수는 다음과 같습니다:
- 에이전트의 첫 번째 설계를 수용하는 것.
- 경험적 증거 없이 계획을 과도하게 다듬는 것.
인간이 코드를 작성할 때, 우리는 종종 디자인 문서를 통해 서로 협력했습니다. 이러한 문서는 높은 수준의 아키텍처, 고려된 대안, 트레이드오프, 특이한 구현 노트에 대해 논의했습니다. 최종 설계에 도달하기 전에 이러한 문서를 여러 번 반복하는 것은 매우 흔한 일이었습니다.
에이전트를 사용할 때는 디자인 문서의 형식을 생략할 수 있지만, 에이전트가 처음으로 제시한 것을 그대로 받아들이는 실수를 자주 봅니다. pstack을 사용하면 병렬 에이전트를 사용하여 "두 번 재고, 한 번 자르라"는 접근 방식을 극한까지 활용할 수 있습니다.
우리는 프로토타이핑 플레이북을 사용하여 이 작업을 수행합니다.
pstack에서 플레이북은 스킬이 아니라 /poteto-mode 내부의 참조 파일입니다. 이러한 플레이북은 작업 중인 작업 유형에 따라 조건부로 로드됩니다(토큰 효율성을 위해). 이 23개의 플레이북(0.15.0 기준) 각각에는 제가 작업을 수행할 때 사용하는 워크플로우가 포함되어 있습니다.
스킬과 달리 플레이북은 /poteto-mode의 일부로 에이전트에 의해 자동으로 사용됩니다. 예를 들어:
/poteto-mode 새 드롭다운 메뉴에 대한 몇 가지 옵션을 프로토타이핑해 줘 /poteto-mode 이 버그를 수정해 줘 /poteto-mode 이 스킬 변경 사항을 평가해 줘
프로토타이핑은 제가 가장 좋아하는 pstack 플레이북 중 하나입니다. 목표에 대한 여러 시도를 제공하고 에이전트가 최상의 옵션을 추론하도록 돕습니다. 이는 시각적 프로토타이핑뿐만 아니라 기능, 버그 수정 등을 위한 다양한 솔루션을 프로토타이핑하는 데에도 유용합니다.
/poteto-mode <기능 요청>에 대한 몇 가지 옵션을 프로토타이핑해 줘. /control-app*을 사용하고 제가 검토하고 선택할 수 있도록 비디오/스크린샷을 찍어 줘
\ 참고: /control-app은 [1부]([https://x.com/poteto/status/2094457600259842065](https://x.com/poteto/status/2094457600259842065))에서 만든 검증 스킬입니다*
시각적 변경 사항을 프로토타이핑할 때, 에이전트는 앱이나 스크래치 디렉토리에 일회용 스케치를 만듭니다. UI 상호 작용을 테스트하는 경우, 간단한 스위처 뒤에 두세 가지 변형을 배치합니다. 그런 다음 /control-app 스킬로 상호 작용을 구동하고, 각 변형의 스크린샷을 찍고, 실제 타이밍이나 레이아웃을 측정합니다.
프로토타이핑은 계획이지만 코드를 사용합니다. 에이전트가 문제 공간을 탐색할 자유를 주고, 스스로 생각하지 못했던 무언가로 당신을 놀라게 할 기회를 제공합니다. 프로토타입을 통해 에이전트는 내 입력을 기다리는 대신 경험적 증거를 사용하여 자신의 질문에 답할 수 있습니다.
더 큰 변화를 아키텍처링하기
에이전트 시대의 엔지니어로서, 제 시간을 아키텍처, 올바른 데이터 구조 선택, 구축하는 시스템이 어떻게 함께 작동할지 생각하는 데 사용하는 것이 더 중요합니다. 제 에이전트가 구현 세부 사항을 채워줍니다.
pstack에 포함된 또 다른 유용한 스킬은 /architect입니다. 설계를 뚜렷하고 규율 있는 단계로 구조화합니다:
- 문제를 파악합니다. 에이전트는 영향을 받는 시스템에 대해 /how와 /why를 실행하여 기존 소유권과 제약 조건에 대한 정확한 멘탈 모델을 구축합니다.
- 스케치합니다. 에이전트는 아키텍처 경기장에 들어갑니다. 종종 다른 모델 제품군에서 병렬로 독립적인 후보 실행기를 생성합니다. 각 실행기는 파악 브리핑을 받고 완전한 설계 패키지를 초안합니다: 호출자의 사용 스케치, 핵심 타입 정의, 공개 함수 시그니처, 간결한 근거. 이는 일반적으로 호출 사이트가 어떻게 보이길 원하는지에서 파생된 타입 시그니처만 스케치하여 수행됩니다. 각 실행기는 인터페이스 깊이를 평가하고, 약한 모델에서의 실패 모드를 검사하며, 설계 위험 신호 카탈로그와 대조해야 합니다.
- 상호 평가 및 종합합니다. 주 에이전트와 다른 모델을 사용하는 상호 평가 에이전트가 엄격한 루브릭에 따라 후보를 평가합니다.
- 스케치에 따라 구현합니다. 에이전트는 스케치의 플레이스홀더 본문을 실제 로직으로 대체합니다. 구현 중에 함수에 예상치 못한 매개변수나 추가 상태가 필요하다는 것을 발견하면 차이점을 표면화합니다.
- 설계가 잘못된 경우 폐기합니다. 구현 중에 스케치가 잘못되었다는 것을 발견하면 에이전트는 모든 것을 버리고 처음부터 다시 시작합니다.
여기서 요점은 에이전트에게 여러 모델 제품군의 경쟁 설계를 하나의 최적 접근 방식으로 종합하고, 엄격함을 유지하며, 경험적 증거에 기반하여 도출한 아키텍처가 잘못된 것으로 판명되면 설계를 폐기하는 것을 두려워하지 않는 자체 포함된 미니 루프를 제공하는 것입니다. 관련 없는 호출 사이트에서 동일한 해결 방법이 나타나거나, 타입에 𝚊𝚗𝚢 또는 강제 캐스트와 같은 탈출구가 필요한 경우, 이는 아키텍처가 잘못되었다는 경험적 증거입니다.
/architect 이 새로운 <기능 요청>을 아키텍처링해 줘
여기서 큰 교훈은 /poteto-mode 프로토타이핑과 /architect를 사용하여 코드로 계획하는 것이 훨씬 더 효과적이라는 것입니다.
또한 이것이 제가 추상적인 계획을 적대적으로 검토하는 데 신경 쓰지 않는 이유이기도 합니다. 에이전트는 이론적인 위험을 환각하기 시작하고, 결코 발생하지 않을 문제로부터 보호하기 위해 복잡한 엣지 케이스를 발명합니다. 계획이 여전히 추상적일 때 과도하게 다듬지 마십시오. 에이전트가 프로토타이핑과 자체 작업 검증을 통해 스스로 열린 질문에 답하도록 하십시오.
좋아, 하지만 난 정말 계획 문서를 원해
pstack에는 계획 스킬이 포함되어 있지 않지만, 다단계 계획 플레이북이 포함되어 있습니다. 저는 일반적으로 에이전트가 마음에 드는 설계를 도출한 후, 전술적 실행 계획을 생성하는 방법으로 이 플레이북을 사용합니다.
/poteto-mode 이 설계를 계획으로 바꿔 줘
계획의 모든 단일 작업은 증명과 검증을 중심으로 구조화됩니다. 플레이북은 에이전트에게 테스트만으로는 충분한 검증이 아니라고 알려줍니다. 실제로 코드를 실행하고 작동하는지 확인했을 때만 검증된 것입니다.
모든 계획은 구조와 형식을 검증하는 자동화된 스크립트에 의해 확인됩니다. 승인되면 계획은 항목별로 실행됩니다. 각 PR은 작고, 자체 포함되어 있으며, 쉽게 검토할 수 있습니다.
정말 큰 프로젝트(예: 일주일 내내 걸릴 수 있는 프로젝트)의 경우, 다른 에이전트가 진행 중인 작업을 인식할 수 있도록 계획을 코드베이스에 임시로 커밋하기로 결정할 때도 있습니다. 하지만 일반적으로 완료되면 삭제하여 코드베이스를 혼란스러운 상태로 두지 않습니다. 계획을 영구적으로 유지하는 것이 가치 있다고 생각하지 않습니다.
실제 워크플로우
이 모든 조각들이 어떻게 함께 맞물리는지 확인하기 위해, 제가 이러한 워크플로우를 어떻게 프롬프트하는지에 대한 세 가지 구체적인 예를 살펴보겠습니다.
예시 1: 모호한 버그 조사
프로덕션에서 이슈가 나타나고 근본 원인이 불분명할 때:
/poteto-mode 백그라운드 워커가 주기적으로 타임아웃 오류로 실패하는 이유를 조사해 줘. 우리가 알고 있는 것, 사용한 데이터, 그리고 최선의 가설을 분석해 줘.
에이전트는 코드를 탐색하고, 메트릭과 과거 커밋을 병렬로 확인하며, 문제가 있을 수 있는 위치에 대한 최선의 추정을 제공합니다.
예시 2: 새로운 서비스 경계 설계
다른 모듈이 의존할 새로운 하위 시스템을 도입할 때:
/poteto-mode 외부 웹훅에 대한 속도 제한을 추가해야 해. 먼저 /architect로 이 부분을 아키텍처링하고, 열린 질문은 프로토타입으로 답해 줘. 진행하기 전에 내가 검토할 수 있게 해 줘.
에이전트는 기존 웹훅 아키텍처를 파악하고, 여러 모델에서 경쟁 설계 실행기를 생성하며, 일회용 프로토타입으로 벤치마킹하고, 깔끔하고 검증된 인터페이스를 생성합니다.
예시 3: 다중 PR 마이그레이션 실행
여러 파일에 걸친 복잡한 리팩토링을 실행할 때:
/poteto-mode 전체 UI 라이브러리를 StyleX로 마이그레이션하는 계획을 세워 줘. 마이그레이션을 작고 검증 가능한 PR로 나눠 줘. 각 PR에는 시각적 회귀 테스트와 라이브 검증 단계가 있어야 해. 최종 결과물이 원본과 100% 동일하기를 원해 - 버그도 포함해서
에이전트는 작업을 독립적인 단계로 나누고, 감사 가능한 체크리스트를 작성하며, 각 유닛을 안전하게 빌드, 검증, 배포할 수 있도록 준비합니다.
예시 4: Slack에서 사람들이 보고하는 문제 수정
Slack의 이슈 또는 피드백 채널에서 저를 본 적이 있다면, 아마 이런 고전적인 문구를 보셨을 것입니다:
# 스레드에 이미 충분한 컨텍스트가 있습니다
/poteto-mode 해 줘
/poteto-mode /control-app으로 이걸 재현해 봐. main에서 재현되면 수정하고 증명으로 비디오를 보여 줘
제가 여기서 이야기한 많은 스킬들은 이미 /poteto-mode에 의해 자동으로 사용되므로, 대부분의 경우 /poteto-mode를 사용하고 계속 일상을 이어가면 됩니다!
계획의 기술
플랜 모드는 종종 에이전트가 올바른 일을 할 것이라고 스스로를 설득하는 방법으로 사용됩니다. 하지만 현실은 추상적인 계획이 진전의 환상만을 제공한다는 것입니다. 길고 상세한 계획은 당신과 당신의 에이전트가 매우 생산적이었다는 인상을 주지만, 내용은 부족할 가능성이 높습니다.
pstack은 철저한 조사, 경험적 증거, 엄격한 검증을 결합하는 도구를 제공합니다. 이런 방식으로 계획하면, 에이전트와 함께하는 엔지니어링이 더 이상 도박처럼 느껴지지 않습니다. 예측 가능하고 반복 가능해집니다.
https://x.ai/bot/plugin/9717366
읽어주셔서 감사합니다. 3부를 기대해 주세요!
