Codex 책임자: 「모든 사람이 builder 다」는 매우 나쁜 아이디어입니다
작성자: Founder Park
Andrew Ambrosino 는 OpenAI Codex 팀의 책임자입니다. 디자이너 출신으로 엔지니어로도 일했고, 제품 관리도 했으며, 창업 경험도 있습니다. 현재 담당하는 Codex 의 주간 활성 사용자는 500 만 명을 넘었습니다. 그는 현재 'AI 시대 제품을 어떻게 만들어야 하는가'라는 질문에 가장 적합하게 답할 수 있는 사람 중 하나일 것입니다.
그의 견해에 따르면, 회사 내 거의 모든 사람이 빠르게 기능 프로토타입을搭建할 수 있게 된 지금, 진정한难题는 '만들 수 있는가'가 아니라 '이것을 만들어야 하는가'입니다.
Lenny 와의 대담에서 Andrew Ambrosino 는 OpenAI 내부의 개발 프로세스를 자세히 소개했습니다. 구현 비용이 AI 로 인해 크게 압축된 후, 제품 개발의 모든 단계, 즉 프로젝트 착수, 문서, 프로토타입, 디자인부터 역할 분담, 팀 협업, 제품 기획에 이르기까지 변화하고 있습니다. 어떤舊 규칙이 무효화되고 있는가? 어떤 새로운 기준이 형성되고 있는가? 구현이 더 이상 희귀하지 않을 때, 무엇이 진정한 희귀 자원인가?
몇 가지 핵심觀點:
- 90 명이 모두 출시 가능한 90 개의 제품 프로토타입을 만들 수 있을 때, 가장 귀한 것은 taste 입니다.
- Codex 팀의 채용硬性 기준 중 하나는 취향으로, 방대한 콘텐츠에서 신호와 노이즈를 구별할 수 있어야 합니다. '무제한 tokens'를 보유한 세상에서 그들은 쓰레기 콘텐츠를 생산하고 싶지 않습니다.
- Codex 가 3 개월 일찍 출시되었다면 완전히 실패했을 것입니다. 유일한 변수는 모델이 발전했다는 점입니다. 기능을 섣불리 나쁘다고 판단하지 마십시오. 단지 때가 아직이지 않았을 뿐입니다.
- 기능이 최종적으로 충분히 좋은지 여부는 기능 자체의 형태보다는 모델이 충분히 똑똑한지에 달려 있는 경우가 많습니다.
- Codex 가 ChatGPT 를 뒤집었던 것처럼 Codex 도 새로운 시도로 뒤집힐 수 있습니다. 바텀업 탐색 문화를 유지해야 하며, 같은 팀이 디테일을 다듬으면서 동시에 자신을 뒤집기를 기대해서는 안 됩니다.
이하是对담의 핵심 내용입니다.
구현 비용이 낮아지면 taste 가 더 중요해집니다
Lenny: AI 가 제품 작업의 형태를 바꾸고 있다고 말씀하신 적이 있습니다. 현재 글로벌에서 가장 최전선에 있는 AI 제품 팀에서 일하고 계십니다. 구체적으로 제품 팀의 작업 방식은 2 년 전과 비교해 어떤 변화가 있습니까?
Andrew Ambrosino: 현재 팀 책임자로서 가장 어려운 일은 프로세스가 뒤집혔다는 점입니다.
과거에 제품을 만드는 방식은 모두 잘 압니다. 먼저 조사하고, 아이디어를 내고, 프로토타입을 만듭니다. 워터폴 개발 시대를 오래전에 지났더라도底层 논리는 동일했습니다. 구현은 비쌌습니다. 따라서 구현 전에 문서, 조사, 프로토타입을 통해 모든 리스크를 미리 제거해야 했습니다. 프로토타입과 디자인이 개발보다 저렴하다는 것이 과거의 기본 가정이었다.
이제 이 가정은 완전히 변했습니다. 누구나 무엇이든 만들 수 있습니다. 저는 정말로 믿습니다. 처음부터 이러한 모델과 대화하면, 우리 모델이든 다른 회사의 모델이든 원하는 어떤 기능도搭建할 수 있습니다. 이것이 소프트웨어 개발에서 가장 어려운 부분은 아닐 수 있지만, 확실히 cool 합니다.
사람들에게 무제한의 tokens 를 주면, OpenAI 의 모든 사람은 주체적이고 좋은 아이디어를 가지고 있습니다. 그래서ทุกคน가 다양한 것들을 만들고 있습니다. 현재 회사에 우리가 긴급하게 필요한 기능이 있다고 가정해 봅시다. 동시에 조정되지 않은 90 개의 다른 소팀이各自 구현하고 시도하고 있다고 확신합니다. 그 90 개의 시도 중에서 어떤 것이 좋은가? 어떤 부분을 다른 측면으로 접어야 하는가? 어떻게 정의해야 하는가? 이것이 다른 기능의 일부여야 하는가? 스위치에 몇 개의 옵션이 있어야 하는가? 바로 이런 일들입니다.
따라서 짧은 답변은 다음과 같습니다. 뒤집혔습니다. 사람들이 근본적으로 다른 역할을 하는 것도 아니고, 기술이 사라지거나 역할이 존재하지 않는 것도 아닙니다. 구현이 더 이상 가장 비싼 부분이 아닙니다. 감히 말하자면, 가장 비싼 것은品味 (taste) 입니다.
Lenny: 그래서 이전에는 사람들이 PRD, 전략 문서를 작성했지만, 이제는 사람들이 직접 프로토타입을 만듭니다. 회사 내 많은 사람이 비슷한 아이디어를 가지고 있으면 90 개의 다른 것이 나타나고, 그중에서 방향을 선택한다는 말씀입니까?
Andrew Ambrosino: 네, 이런 일이大量으로 발생합니다. OpenAI 뿐만 아니라 이미 많은 제품 책임자가 'PRD 는 죽었다, 프로토타입이 대세다'라고 말하는 것을 보셨을 것입니다. 하지만 저는 실제로 이觀點에 완전히 동의하지 않습니다.
구현이 모든 매체에서 저렴해졌기 때문에, 생각을 건너뛰고 직접 프로토타입을 만드는 것이 매우 유혹적입니다. 특히 엔지니어가 아니라면, 코드를写过 적이 없거나 관심이나 시간이 없다면 다음과 같이 말하게 될 것입니다. 'PRD 는 죽었다, 내가 원하는 것을 바로 보여줄게.'
하지만 저는 반대 현상도 noticing 했습니다. 엔지니어에게大量의 문서를 작성하는 것이 매우 유혹적이 되었습니다. 읽을 가치가 없는大量의 문서입니다. 문서를 작성하는 사람이 나쁘다는 말이 아니라, 구현이 풍부해질 때 의견을 표현할 형식을 선택하는 것이 진정으로 중요해진다는 것입니다.
모호한 영역의 제품 명확성을 표현하려는 것이라면 문서를 작성하는 것이 맞을 수 있습니다. 사람들이 직접 사용해 보고 인터랙션 패턴을 스트레스 테스트하기를 원한다면 프로토타입을 만드십시오. 핵심은 올바른 매체를 선택하는 것입니다.
Lenny: primal mark(原始标记) 라는 개념이 있습니다. 화가가 캔버스에落笔하는 첫 번째 붓질로, 이후의 모든 것이 그 붓질에서 확장됩니다.您的意思是，有时候原型是错误的第一笔？因为大家会锚定在上面，而不是去想更大的方案？
Andrew Ambrosino: 네. 과거에는 암묵적인 신호가 있었습니다. 어떤 것이 어떻게 보이는지는 그것이 프로세스의 어떤 단계에 있는지를 의미했습니다. 어떤 것이 정식 출시 제품처럼 보인다면, 그것은 이미 후기 단계이며 리스크는 제거되었고, 디자인은 검토되었으며, 비즈니스 목표는 합리적임을 의미했습니다.
이제 이러한 것들은脫鉤되었습니다. 이유는 과거에 구축하기 위한 자원을 얻으려면 리스크를 충분히 낮춰야 했지만, 이제 이 문턱이 사라졌기 때문입니다. 따라서 본래 탐색 단계에 불과한 것이 출시 가능한 것처럼 보입니다. 시각적으로 준비된 상태입니다. 하지만 그것은 올바른 방향이 아닐 수 있으며, 조사 결론과 일치하지 않을 수 있고, 사용자가 진정으로 필요로 하는 것이 아니며, 비즈니스에 최적의 선택이 아닐 수 있습니다.
品味이라는 것을 과도하게 강조하려는 것은 아닙니다. 하지만 다시 한 번 말하자면, 무엇을 해야 하는지, 어떻게 제시할지, 어떻게 목표를 달성할지, 어떤 매체를 사용할지 아는 것이 모든 분야에서 가장 중요한 능력이 되고 있습니다.
Lenny: 品味이라는 단어는 이제 유행어입니다. 구체적으로 말씀하시는 '좋은 品味'은 정확히 무엇입니까?
Andrew Ambrosino: 品味은 분리해서 봐야 합니다.
확실히 심미적인 부분이 있지만, 시스템 사고의 부분도 있습니다. 이것이 전체 시스템에서 어떻게 배치되는지; 방향性的인 부분도 있습니다. 우리가 어디로 가는가, 이 일이 어떤 테마의 일부인지; 표현의 부분도 있습니다. 이 정보를 어떻게呈现할지; 그리고 品味의 일부는 인터랙션层面입니다. 이 애니메이션이 전달하려는 의미와 일치하지 않습니다. 너무 급하고, 표현하려는 의미와 매치되지 않습니다.
이것들은 확실히 매우 중요하지만, 진정한 品味의 문제는 우리가 무엇이든 할 수 있다면 목표는 무엇인가? 어떻게 그곳에 도달할 것인가? 입니다.
Lenny: AI 가越来越强、做越来越多的事，人类大脑在哪些地方会继续有价值？品味感觉是其中之一。但 AI 的设计产出还是不太行，为什么顶尖模型做不好设计？
Andrew Ambrosino: 몇 가지 실제적인 이유와 해결하기 어려운 문제들이 있습니다. 디자인은 소프트웨어보다 평가하기 어렵습니다. 모델에게什么是好设计인지를 훈련하기 위한 피드백 루프를 만드는 것은 코드가 컴파일되는지 훈련하는 것보다 훨씬 번거롭습니다. 인간의 品味이 피드백 메커니즘의 일부이기 때문입니다.
또한, 실험실은 역사적으로 AI 연구를 가속화할 수 있는 것에 모델이 능숙하도록 우선순위를 두었습니다. 모델이 올바른 코드를 작성할 수 있는 것은 확실히 연구를 가속화하지만, 디자인은 같은 논증을 할 수 없습니다. 디자인이 중요하지 않다는 말이 아니라, 그 플라이휠 안에 있지 않다는 것입니다.
이것들은 실제적인 이유이며, 사라질 것입니다. 모델은 디자인에서 상당히 좋아질 것이지만, 몇 가지 더 다루기 어려운 것들이 있습니다.
첫째, 디자인에는 문화적 속성이 있습니다. 작년마다 새로운 웹사이트가 Linear 의 디자인을 복사하던 것을 기억하십니까? 모델이 매번 Linear 웹사이트를 출력한다면 그것은 도전 과제가 아닙니다. 디자인에서 참신성의 중요성은 소프트웨어 엔지니어링보다 훨씬 높습니다. 소프트웨어 엔지니어링에서는 모델이 알려진 패턴을 완전히 따르기를 원하지만, 디자인은 어느 정도의 무작위성과 참신성이 필요합니다.
둘째, 비주얼 디자인과 코드 간의 상호 작용입니다. 내일 회사가 브랜드를 변경한다면, 얕은 방법은 263 개의 컴포넌트를 하나씩 업데이트하는 것입니다. 깊은 방법은看起来不一样的这两个东西其实都属于一个列表样式，传达的是同一种交互模式를 이해하는 것입니다. 이 추상화 레이어는 현재 기술로는 도달할 수 없습니다.
Lenny: Jenny Wen(Anthropic Claude Code 디자인 책임자) 은 디자인 프로세스는 죽었으니 바로 구축하면 된다고 말했습니다. 어떻게 생각하십니까?
Andrew Ambrosino: 저는 Jenny 와 많은 일에서 일치할 수 있습니다. 정규 디자인 프로세스에 대해서는 그녀가 말하는 것에 동의합니다. 그것은 죽었습니다.而且我在 AI 之前就不是那个流程的粉丝。
수년 전 스타트업을 할 때 '사례 연구 공장'이라는 기사가 있었습니다. 디자이너가 고정된 프로세스 세트를 따르도록 훈련받고 점차 프로세스 자체를 결과보다 더 중요하게 여기게 된다는 내용이었습니다. 어떤 것이 이 프로세스를 거치면 기본적으로 두 가지 결론이 내려집니다. 첫째, 그것은 좋을 것이다. 프로세스가 품질을 보장한다. 둘째, 아무도 사용하지 않더라도 그것은 좋다.因为它走了流程。
사용자 조사, 발산, 수렴. 프레임워크는 맞지만 항상 약간 학문적입니다. 그 프로세스의 전제는 구현이 비싸다는 것입니다. 한 번만 만들 수 있으므로 만들기 전에 모든 문제 공간과 솔루션 공간을穷尽해야 합니다.
나중에 Figma 와 Origami 가 나타났고, 우리는 인터랙션 프로토타입을 프로세스에 끌어왔습니다. 현재의 문제는 모든 구현을 프로세스의 가장 앞으로 끌어올 수 있다는 것입니다. 완벽하게 정제된 프로토타입은 바로 출시 가능한 것처럼 보입니다. 회사 내 충분히 많은 사람이 본 후 묻습니다. '지금 출시할 수 있습니까?' 하지만 실제로는 아직 초기 디자인 탐색 단계에 있을 뿐이며, 아무도 명시적으로 말하지 않을 뿐입니다.
따라서 디자인 프로세스가 죽었다는 것은 맞기도 하고 틀리기도 합니다. 특정 도구와 특정 일상 작업에 바인딩한다면 그것은 확실히 죽었습니다. 하지만 '우리가 현재 프로세스의 어떤 단계에 있는가'에 대한 인식은 그 어느 때보다 중요해졌습니다.
디자인 프로세스를 특정 매체에 바인딩하는 것이 위험한 곳입니다. 디자이너는 이제 더 많은 도구를 가지고 있습니다. 기존 제품에 직접 넣을 수 있고, A/B 테스트를 할 수 있습니다. 많은 회사에 제품의 baby 버전이 있습니다. baby Cursor, baby Codex. 공식 제품의 모든 인터랙션을 시뮬레이션할 수 있는 크게 단순화된 코드베이스입니다. 이를 통해 vibe code 할 수 있습니다. '사이드바가 이렇게 되면 어떨까? 패널이 팝업되면 어떨까?' 이것은 디자이너의 새로운 도구이지만, 오래된 인식과配合해야 합니다. 당신이 현재 프로세스의 어디에 있는지.
직무와 역할이 융합되고 있지만 PM 은 사라지지 않습니다
Lenny: 많은 회사가 '역할 소멸'이라고 말합니다. PM, 엔지니어, 디자이너의 분업이 완전히 사라질 것이라고 생각하십니까?
Andrew Ambrosino: 일부 회사는 유행을 쫓고 극단적으로 가는 것을 좋아합니다. 역할 개념을 없애는 것의 위험성은 '이 분야에는 배울 수 있는 모범 사례가 있는 전문직이다'라는 인식을 동시에 없앨 수 있다는 점입니다.
많은 회사가 '제품 역할을 없앨 것이다'라고 말하는 것을 듣습니다. 저는 이것이 매우 나쁜 아이디어라고 생각합니다. 그리고 '모든 사람이 builder 다'라고 말합니다. 결과는 제품 관리라는 실제로 모범 사례가 축적되고 실제로 함정을踩어본 학문이 직접 폐기된다는 것입니다. 누군가가 몇 줄의 코드를 작성했다고 해서万事大吉이라고 생각하는 것은 좋은 상태가 아닙니다.
저는 '이것은 당신의 영역이다, 당신은 건드릴 수 없다'는 경계가 사라지는 것을 환영하지만, 균형이 필요합니다. 누구나 모든 일을 할 수 있는 것은 아닙니다.广度나 深度 측면에서도 그렇습니다. 이것이 매니저가 사라지지 않는 이유이기도 합니다.
또한 모든 학문에는 기술 구성 요소가 있습니다. 많은 엔지니어가 이를 인정하지 않습니다. 엔지니어링에는 기술이 있지만 다른 직무 역할은 '분위기'일 뿐이라고 생각합니다. 그렇지 않습니다. Excel 을 사용할 수 있다고 해서 재무 팀에서 일할 수 있는 것은 아닙니다.
제가 생각하기에 현재 일어나는 일은 사람들이 역할 간 협업이 더 쉬워지고, 다른 분야의 모범 사례를 배우기 더 쉬워지며, 특정 역할에서의 효율성을 특정 도구 사용 능력과 바인딩하지 않아도 된다는 것입니다.
저는 오랫동안 자신이 소프트웨어 엔지니어가 되어서는 안 된다고 느꼈습니다. 어셈블리 언어에 관심이 없었고 TypeScript 의 타입 시스템을 기억하고 싶지 않았기 때문입니다. 이러한 역할에는 항상 '이 역할을 잘한다는 것은 이 도구를 능숙하게 다룬다는 것과 같다'는ような 장벽이 존재했습니다. 이것이 해체되기 시작했다고 생각하지만 사람들은 이를 과장했습니다.
Lenny: 여러분 Codex 팀内确实有更多角色融合，具体是什么样的？
Andrew Ambrosino: 우리는 Codex 팀에서 회사 내 다른 팀이나 다른 산업보다 더 많은 역할 융합을确实 보고 있습니다. 부분적인 이유는 이것이 엔지니어를 대상으로 하는 기술 제품이기 때문입니다. 따라서 우리의 디자이너는 엔지니어의 언어를 말하고, 우리의 제품 관리자는 기술 언어를 말하며 코드를 작성합니다.
우리 내부에는 협업 방식을 설명하는 말이 있습니다. 오늘날 역할 간의 중복은 과거보다 훨씬 큽니다.一个人을 정의하는 것은 '디자인이 어디에서 끝나고 엔지니어링이 어디에서 시작되는가'와 같은 책임 경계를 보는 것이 아니라, 그의 모든 작업_CONTENTS의 평균 분포를 보는 것입니다.
디자인 팀의 어떤 사람이 하는 모든 일을 펼쳐보면 그중에는大量의 코드 작성 작업과大量의 제품 관련 작업이 포함될 수 있습니다. 하지만 이러한 작업을 '평균'을 내면 그는 결국 더 디자인에 치우친 영역에落在하게 됩니다.
Lenny: 제품 관리자의 작업이 더 zone defense(区域防守) 와 같다고 말씀하셨는데, 구체적으로 무엇을 의미합니까?
Andrew Ambrosino: 두 제품 관리자가 너무 밀접하게 협력한다면 일반적으로 좋은 신호가 아닙니다. 힘 기반 레이아웃처럼 팀을 펼쳐서 봐야 합니다. 어디에 공백이 있는가, 어디를 아직 아무도 커버하지 않았는가?
오늘날의 세계에서 큐레이션, 가이드, 얼라인먼트가 가장 중요한 작업이 되었습니다. 모든 사람이 끊임없이 아이디어를 던지고 있으며, 전체 환경은 노이즈로 가득 차 있습니다. 과거의 탑다운 방식, 연간 계획 수립 방식은 더 이상 통하지 않습니다. 우리는 品味의 게이트키퍼로서 어떤 일을 컨셉에서 제품으로 이끌 사람이 필요합니다. 이는 당신이 회사의 모든 구석을 커버해야 함을 의미합니다.
따라서 팀을 펼쳐서 봐야 합니다. 누가 무엇을 잘하는가? 서로 일정 거리를 유지하여 커버리지가 충분히 포괄적인지 확인하십시오. 그런 다음 격차를 메우십시오. 예를 들어 '제품 사고가 강한 엔지니어를 채용하고 싶습니다.' 우리는 다음과 같은 상황을 원하지 않습니다. 한 무리의 사람이 먼저大量의 코드를 작성하고 마지막으로 전체 제품 팀이 제품의 일관성을 검토하고 보정해야 하는 상황. 우리는 모든 사람이 이러한 능력을 갖추기를 원하지만, 각자가 깊이 파고드는 방향은 변화해야 합니다.
Lenny: 그래서 현재 가장 가치 있는 사람은 아이디어부터 완료까지全程 추진할 수 있고, 品味을 가지고 '이것은 훌륭하다'는 것을 아는 사람입니까?
Andrew Ambrosino: 네, 이것이 현재 가장 핵심적인 변화라고 생각합니다. 이는 IC(개인 기여자) 와 매니저의 관계에 대한 저의 이해를 반영하기도 합니다. 관리가 사라진다는 것도 아니고, 모두가 단지 IC 일 뿐이라는 것도 아닙니다.而是现在每个人在某种程度上同时承担着这两种角色。
당신이 IC 라면 더 이상 한 문자씩 코드를 타이핑하는 것이 아닙니다. 당신은 무언가를 관리하고 있습니다. agents 를 관리하고, 작업을 함께 완료하도록 조직된 것들을 관리합니다. 당신이 팀 매니저라면 본질적으로 같은 일을 하는 것입니다. 다만 관리의 세밀도가 다를 뿐입니다.
제가 일반적으로 찾는 사람은 탄탄한 전문 능력 외에도 반드시 品味을 가지고 있어야 합니다. '무제한 tokens'를 보유한 세상에서 우리는 쓰레기 콘텐츠를 생산할 수 없기 때문입니다. 당신은 방대한 콘텐츠에서 신호와 노이즈를 구별할 수 있는 능력을 가져야 합니다.
Codex 팀에 몇 명이 있는지 묻는 사람이 있을 때마다 제 답변은 항상 다음과 같습니다. '대략 10 명에서 몇 천 명 사이입니다.' 농담처럼 들리지만 실제로 모든 사람의 작업이 이 제품에汇聚됩니다. 모델 연구, 브라우저 사용, 모델 페르소나, 프론트엔드 인프라, 사용자 경험, 이 모두가 제품의 일부입니다.
하지만 동시에 우리는 매일 몇 천 명이 제출한 PR(코드 제출 요청) 을接收하는 것도 아닙니다. 팀에는 두 자릿수 규모의 엔지니어가 있고, 디자이너 수는 엔지니어의 약 절반이며, 몇 명의 제품 관리자가 있습니다.绝大多数人都是 IC。팀의 영향 범위는 크지만 관리 계층은 두껍지 않습니다. 여기에는 회사를 창업해 본 사람이 많고, 대기업에서 '파운더 마인드셋'으로 일하는 사람도 많으며, 品味이 뛰어난 사람도 많습니다.
전체 Codex 애플리케이션은 dogfooding 루프에 의해 형성되었습니다. 우리 모두에게는 공통된 소원이 있습니다. 애플리케이션 내에서 가능한 한 많은 작업을 완료하는 것입니다. 비록 그것이暫時 최고의 도구가 아니더라도,只有这样，它最终才有机会成为最好的工具。우리는 종종 일부 내부 프로세스를 개선하지 않고 제품 자체가 더 좋아져서 이러한 프로세스를 지원할 수 있도록刻意 합니다. 이것은 실제로 매우 불편한 상태입니다. 하지만 주마다 그것은确实在持续发生变化。
Codex 가 3 개월 일찍 출시되었다면 죽었을 것입니다. 유일한 차이는 모델이 발전했다는 점입니다
Lenny: 일이 이렇게 빠르게 변화하는 리듬 속에서你们怎么做规划？看多远？
Andrew Ambrosino: 우리는 기획에서 혁명적인做法는 없습니다. 기본 원칙은 현재에 가까울수록 기획은 더 구체적이어야 한다는 것입니다. 9 개월 계획을 하지 않는 것이 아니라, 그 계획은 매우模糊하게 유지되어야 합니다. 현재 9 개월 계획에 추가하는 어떤 정밀도도 가상의 정밀도이며 시간을 낭비할 뿐이기 때문입니다.
애플리케이션 제품 측면에서 11 월에 기획할 수 있는 것은 12 월에도 맞을 수 있지만, 2 월이 되면 완전히 다른 일이 됩니다.
이전 회사에서 모델 능력을 기반으로 기능 개발을 추진하기 시작했을 때 기존의 제품 프로세스는 기본적으로 붕괴되었습니다.後來变成了把所有感兴趣的方向都列出来，给它们做原型，判断哪些现在已经可行，然后把其他的暂时搁置。每当模型能力出现新的跃升，就把那些搁置的东西重新拿出来再试一遍。因为一个功能最终是否足够好，前提往往不是功能本身的形态，而是模型到底够不够聪明。많은 사람들이 저의 기획 방식에 불만을 품었습니다. 하지만 이 일은确实 매우 어렵습니다.
Lenny: 타이밍이 얼마나 중요한지 보여주는 구체적인 예가 있습니까?
Andrew Ambrosino: Codex 에 관한 좋은 이야기가 있습니다. 저는 2 월에 출시한 Codex 애플리케이션이 11 월에 준비되어 출시되었다면 시장에서 완전히 실패했을 것이라고 매우 확신합니다. 유일한 차이는 11 월에서 2 월 사이에 모델이 발전했다는 점입니다. 동일한 제품, 완전히 동일한 형태, 결과는 완전히 다릅니다. 불과 몇 개월 차이입니다.
Lenny:所以现在不行的东西以后可能行？要保持更大的野心？
Andrew Ambrosino: 네. 저는 사람들이 '이것은 현재 안 되므로 나쁜 기능이다'라고 쉽게 판단하지 않기를 추천합니다. 그것은 단지 때가 아직이지 않았을 뿐입니다.
Codex 의 초기 출시인 Codex web 으로 돌아가 봅시다. 기본적으로 모델에 작업을 주면它去干，干完了回来给你结果。激进的听起来不，但问题是它干得不够好，那个形态太超前了。
그런 다음 Claude Code 가 나왔습니다. 완전히 로컬화되었으며, 클라우드에 연결되지도 않고 자신이 얼마나 AGI 인 척하지도 않습니다. 그것은 당신에게 질문을 하고 거기서 기다립니다. 당신은 전체 인생을 그것에 위임할 수 없습니다. 그것은当时 모델의 능력 수준과 매치되었기 때문에 훨씬 더好用했습니다.
우리는当时 너무 'AGI'였습니다. 저는 종종 이 교훈을 생각합니다. 과거에 시장에서 제품의 실패는 종종 제품 형태나 커뮤니케이션 방식에 대한 많은 것을 알려주었습니다. 이제 다릅니다. 당신은 동일한 것을 6 번 출시해야 할 수도 있습니다.直到它成功，形态可能完全不变。
애플리케이션 내 브라우저도 이러한 상황입니다. 우리는曾经 작동하는 버전이 있었습니다. Atlas 시대로 돌아가면 우리는 이미 브라우저에서 작업을 수행하는 agent 가 있었습니다. 그 이전에는 ChatGPT 의 Operator 가 있었는데, 그것은 성공하지 못했습니다. 하지만 Operator, Atlas, Codex, ChatGPT 를 연결해 보면它们之间其实可以画出一条连续的演进路线。本質上是同一个功能，只是随着智能水平的变化，被不断重新发布，而结果也因此彻底改变。
一旦一个产品或功能已经存在，人们很容易把注意力放在各种细节问题和微优化上，而且他们确实应该这么做。但这也是为什么我们始终保留一种自下而上的探索文化。因为有时候，就像 Codex 应用曾以某种方式颠覆 ChatGPT 一样，Codex 自己未来也可能被新的尝试所颠覆。你不能指望同一个团队既持续产出颠覆性的创新，又始终专注于产品质量和细节打磨。在某个阶段，你必须设计出一种机制，让这两种能力能够同时存在。
Lenny: Codex 의 비전은 무엇입니까? 어디로 가져갈 계획입니까?
Andrew Ambrosino: 올해 1 월과 2 월에 우리는 내부 자체 테스트 과정에서 엔지니어링 및 연구 워크플로우에서 매우清晰的 PMF 가 형성되었음을 발견했습니다. 하지만 동시에 마케팅, 커뮤니케이션, 재무, 법무 사람들도 Codex 를 사용하고 있습니다. 비록 이 애플리케이션이 그들에게 친숙하지는 않지만, 그것은 그들에게 코드를 보여주고 명령줄 검색 도구의 실행을 승인하게 합니다.
우리는 Codex 의 능력을 다른 제품에 추가해 보았습니다. ChatGPT 데스크톱 앱, Atlas 브라우저. 결과적으로 가장 성가신 일이 발생했습니다. 아무도 Codex 애플리케이션을 떠나 그들이 위해 특별히 제작되었다는 제품을 사용하려 하지 않았습니다.
이것은 우리에게 영감을 주었습니다. 개발자 도구와 일반 지식 작업 도구 사이에는 실제로 많은 미묘한 공통점이 있다는 것입니다. 우리는确实相信，我们正在构建的这种产品形态，是承载各种深度垂直场景的正确形态。从简单开始，再根据需要逐步增加复杂度。
그것은 '화면에 사각형을 그린 다음 모든 일을 그 안에서 완료해야 하는' 제품이 아닙니다. 더像一个大本营，你在这里开始工作、结束工作、管理自动化流程，而它会调用你所需要的一切工具。有人把这种形态称作「super app」，我真希望他们当时没这么叫，因为现在我几乎每天都得听到这个词。
Dan Shipper 는 매우 흥미로운 아이디어를 가지고 있습니다. 그는 미래에 우리가 Codex 내부에서 '안에서 밖으로'SaaS 도구를 사용할 것이라고 생각합니다. Notion, Linear, Salesforce 는 당신이 브라우저에서 여는 것이 아니라 agent 가 Codex 에서 당신을 위해 조작하는 것입니다. 우리는确实 이를 하고 있습니다. 애플리케이션 내 브라우저, Chrome 확장, computer use, 이 모든 것은 Codex 가 외부 도구와 상호 작용할 수 있는 방법입니다.
가장 좋은 예 중 하나는 내부 비디오 제작자 Brent 가 Codex 를 사용하여 Codex 출시 비디오를 편집했다는 것입니다. Codex 는 비디오 편집기가 아니며 해당 UI 가 없습니다. 하지만 그것은 Brent 가 Premiere Pro 를 사용하고 있다는 것을 이해하며, Premiere Pro 배후의 파일을 편집하여 일부 수정을 할 수 있습니다. 그것이 모든 일을 할 수 없다는 것을 발견했을 때, 그것은 스스로 Premiere Pro 확장 플러그인을 작성하여 Premiere Pro 에 설치한 다음 이 플러그인을 통해 Premiere Pro 와 대화했습니다. 이것을 볼 때 우리는 모두 충격받았습니다.
이것은 좋은 패턴입니다. 전문 도구가 전문적인 일을 합니다. Codex 는 더 나은 비디오 편집기가 될 필요가 없으며, 전문 도구와 원활하게 상호 작용하기만 하면 됩니다.
코드 작성은 중요하지 않습니다. 코드 삭제가 중요합니다
Lenny: 수동 코드 작성에서 AI 가 100% 의 코드를 작성하는 것, 그리고 현재의 agents 와 loops 로. 최전선 팀은现在到底怎么工作？
Andrew Ambrosino: Loops(循环)? 그것은 지난주의 일입니다.
우리는 항상 '제품의有多少比例是 AI 写的代码'라는 문제를 논의해 왔습니다.去年的标准来看，我们现在 100% 的代码都是 AI 写的。所以问题不再是「多少是 AI 写的」，而是「代码是在监督下写的还是无监督写的」，这是一个完全不同的维度。我欢迎这种标准不断被刷新，因为这意味着我们在取得产品进展。
우리는 자율 소프트웨어 개발方面做了很多探索，比如大量的 harness engineering，比如「如果模型在夜里自动做代码库的垃圾回收和清理呢？」
하지만 현재 모든 모델에는 하나의 문제가 있습니다. 그것들은 항상 복잡성을 증가시킵니다. 연구를 하는 사람이 듣고 있다면: 제발, 모델에게 코드 삭제를 배우게 해주세요. 개발을 완전히 자율 주행에 맡기려고 할 때 이것은 사람层面에서나 코드베이스层面에서나 심각한 문제가 됩니다.
Feature requests(기능 요청) 도 마찬가지입니다. 모델에게 어떤 기능이 가치 있는지, 어떤 것을 무시해야 하는지, 어떤 것을 병합하여 재정의해야 하는지 어떻게 판단하도록 가르칠 수 있습니까? 또 모델에게 올바른 추상화를 구축하도록 어떻게 가르칠 수 있습니까?
이러한 능력은 지속적으로進步하고 있습니다. 하지만 저는 우리가 이미 이러한 단계에 도달했다고 생각하지는 않습니다. 루프를 설정하고 모델이 자동으로 '애플리케이션을 개선'하도록 하며, Twitter, Slack, 이메일을 지속적으로 모니터링한 다음 자율적으로 반복을 완료하도록 하는 단계입니다. 비록 우리는确实正在尝试把这件事变成现实。
Lenny: 우리는 그 단계에 도달할 것이라고 생각하십니까? 즉 목표를 설정하는 것입니다: '이기는 것'?
Andrew Ambrosino: '/goal 내게 10 억 달러를 벌어줘.'我不知道。我不会说永远不会或者永远会怎样。
Lenny: 제품 및 엔지니어링 책임자로서你自己是怎么用 AI 工作的？
Andrew Ambrosino: 저는 현재 세계에서 가장 좋은 직업을 가지고 있을지도 모릅니다.
처음 Codex 를 만들 때 저의 개인적인 목표는 그것을 Codex 의 코드를 작성하는 데 사용할 수 있을 정도로 좋게 만드는 것이었습니다. 그것은 매우 긴밀한 자체 사용 제품 루프였습니다. 저는 어떤 일을 할 수 없었습니다. 그러면 그것을 고쳤습니다. 그리고 저는 할 수 있게 되었습니다. 그리고 더 많은 일을 할 수 있게 되었습니다.
나중에 제 역할이 변했습니다. 저는 더 많은 제품 발견을 하고, 팀이 무엇을 하고 있는지 파악하고, 방향에서 벗어난 것을 수정해야 했습니다.于是 Codex变成了我做这些事的工具。「帮我建一个电子表格把这些数据整理出来。」「帮我做一个内部深度调研，看看过去在这个方向上做过哪些探索。」
5 월의 일련의 출시, 애플리케이션 내 브라우저, computer use, artifact creation, 그것은 우리가 처음으로 vibe coordination(氛围式协调) 으로 출시를 관리한 것이었습니다. 저는 모든 할 일 목록을 기록하는 Notion 문서를 가지고 있었고, Codex 를 사용하여 자동으로 PR, Slack 채널에서 진행 상황을 수집하고 상태 추적기를 업데이트했습니다.当时觉得这是管理产品发布方式的最前沿。
이제 저는 매일 아침 일어나서 Codex 가帮我生成的日报를 봅니다. 제가 가입한 3000 개의 Slack 채널에서 제가 주목해야 할 일을 선별합니다. 저는 '나에게 5 개의 질문을 주세요. 제가 답변하겠습니다.'라고 답할 수 있습니다. 그것은 스스로 조정합니다. 저는 '다음에 실행할 때 이 워크플로우에 덜 주목하세요' 또는 '이 일이 발생했지만 일일 보고서에 나타나지 않았습니다.以后能抓到도록 확보하세요'라고 말합니다. 그러면 그것은 알림 방식을 업데이트하고 주목 초점을 조정합니다.
Lenny: 이것은 어떻게 설정합니까? 워크플로우是什么？
Andrew Ambrosino: 아직 발견 단계입니다.定时任务를 만드는 것입니다: '내 Slack 채널을一遍하세요. 이것이 제가 관심 있는 일입니다. 이러한 분류로 정리하세요. 여기에 일부 컨텍스트가 있습니다.'처음 몇 번 실행하려면 가이드가 필요할 수 있습니다. 다행히 저는 명령을 편집하는 방법을 찾을 필요가 없습니다. 저는 직접 대화하여 '다음에 이것을帮我改一下'라고 말합니다. 그러면 그것이 업데이트됩니다.
하지만 저는 이것이 챗봇 형태의 핵심 문제라고 생각합니다. 저는 어떻게 설정하는지 압니다. 저에게 이것은 제품 발견이기 때문입니다. 하지만 당신이 OpenAI 에서 일하지 않거나, 이것을 개발하지 않는다면 당신은 이것을 figure out 하고 싶지 않을 것입니다. 우리는 이러한 것이 일반인에게도 사용 가능한 형태가 되도록 생각해야 합니다.
Lenny: 저 자신도 Codex 를 사용하여 스팸 메일 필터링 자동화를 만들었습니다. 그중 한 단계는 Google Cloud 콘솔에서一堆 API 트리거를 설정하는 것이었습니다. 그 인터페이스는特别烦。저는 Codex 에게帮我做라고 했습니다. 그것은 직접 내 컴퓨터를 장악하고 computer use 기능을 사용하여 조작했습니다.
Andrew Ambrosino: 그것은 다음과 같습니다. '커넥터가 있는지与否는 상관없습니다. 형제, 나는直接 클릭을 시작합니다.'
커넥터, 애플리케이션 내 브라우저, Chrome 확장 및 computer use 간의 경계를 어떻게 나누는지는 매우 흥미로운 일입니다. 많은 경우 이러한 경계는 실제로 느낌으로摸索出来的。
저는 이러한 개인 워크플로우가特别 흥미롭다고 생각합니다. 모두는 다양한 것들을 시도하고 있으며, 각자는 완전히 다른 시스템을 구축할 것입니다. 하지만 서서히 일부 공통 패턴이浮现할 것입니다. 그러면 우리는 깨닫게 될 것입니다. '이것은 제품 내의 일급 경험이 되어야 합니다.'
예를 들어 memory(기억), 많은 사람이 Obsidian 지식베이스나 Notion 공간을 설정하여 자신의 기억의 궁전을 구축하고 있습니다. 당신은 스스로 이것을 할 필요가 없어야 합니다. 당신을 위해 해줄 충분히 일반적인 기억 기능이 있어야 합니다. 우리는一直在筛选，什么对个人有效但应该留在个人层面、什么应该进入产品成为基础组件。
Lenny: 바깥 사람들은 당신이 이기고 있는 것만 봅니다. 하지만 확실히 성공하지 못한 일도 있었습니까?
Andrew Ambrosino: 당신이 이렇게 설명하는 것을 듣는 것은 꽤 웃깁니다. 이것은 실제로 제가 처음으로 실패하고 있지 않다고 느낀 lần입니다.
이전에 저는 수년 동안 스타트업을 했고, 결국 회사를 분해하여 매각했습니다. 규제가 엄격한 산업에서 일했으며, 전체 과정은 지속적인 실패와 같았습니다.后来去了另一家创业公司，在另一个封闭的受管制行业里做 AI 工具，也是一次又一次地不行。我实际上失败了很多。有时候只是一个时间点，技能、热情和市场窗口恰好对齐了。
비록 현재 Codex 와 ChatGPT 를 결합하는 이 프로젝트에서도 셀 수 없는 작은 실패가 있습니다. 우리는 '이렇게 되어야 한다'고 말하고 Slack 에 게시합니다. 아래에는 우리가 얼마나 어리석은지에 대한 2000 개의 메시지가 있습니다. 이것이 제가 OpenAI 를 좋아하는 곳입니다. 사람들은 우리에게 직접 말해줍니다. 내부 제품의 실패에 대해容赦없습니다. 이것이 외부 제품이 잘 되는 이유입니다. 제가 현재 이 위치에 도달하기 전에 저는 대략 10 에서 15 년 동안 실패했습니다. 따라서 저는 매일 여전히 약간 놀랍습니다. 일이 순조롭게 진행되고 있다는 것이.
Lenny: 독자들에게 마지막 조언이 있습니까?
Andrew Ambrosino: 현재 워크플로우와 '평생 바인딩'하지 마십시오. 정말로 고수해야 할 것은 당신만이 독특하게 전달할 수 있는 결과입니다. 그런 다음 지속적으로 프로세스를 변경해 보십시오. 당신이 가장 자랑스럽게 여기는 기술이 '내가 Figma 의 auto layout(自动布局) 을 가장 잘 안다'라면 당신은 무엇을 하고 있는 것입니까? AI 도 당신보다 더 잘하게 될 것입니다. 가치 있는 일을 찾은 다음 그 일을 할 방법을 찾으십시오.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
