Patrick Collison kể Stripe dùng Claude Code thế nào

1. Trạm thời tiết ở nhà và câu hỏi về dev box

Video là một cuộc trò chuyện trên kênh Claude giữa Patrick Collison, CEO của Stripe, và Boris Cherny, người dẫn chương trình, ngồi đối diện nhau quanh một bàn họp dài. Chủ đề là cách Stripe build phần mềm với Claude Code.

Đoạn mở đầu là một câu chuyện riêng của Patrick. Ở nhà anh, gia đình đã lắp một trạm thời tiết. Với Claude, anh có thể tự thiết kế từ con số không một model đa phương thức (multimodal model), và model đó dự báo thời tiết buổi chiều tốt hơn cả National Weather Service, cơ quan khí tượng quốc gia của Mỹ.

Câu hỏi đầu tiên của Boris đi thẳng vào hạ tầng phát triển của Stripe. Rất nhiều công ty trong ngành đang cố chuyển sang VM trên cloud, sang những môi trường làm việc từ xa (remote environments), nơi kỹ sư không còn code trên máy của mình nữa mà làm trong một dev box dựng sẵn, dùng xong có thể vứt. Stripe đã làm điều đó. Boris hỏi: điều gì cho Stripe niềm tin chắc chắn để đi con đường này?

2. Năm rưỡi số chín mà vẫn continuous deployment

Patrick trả lời rằng reliability và security cực kỳ quan trọng với Stripe. Stripe vận hành ở mức năm rưỡi số chín (five and a half nines) về độ tin cậy, tức độ tin cậy cực cao cho các API lõi. Nhưng đồng thời, Stripe muốn phát triển và ra mắt sản phẩm mới, thêm feature mới cực kỳ nhanh. Stripe muốn có continuous deployment cho API của mình.

Anh so sánh với cả ngành dịch vụ tài chính. Ở đó, cách mọi thứ thường vận hành là có lẽ mỗi tháng deploy một lần, mỗi quý một lần, có nơi nửa năm một lần. Làm vậy đem lại một kiểu ổn định cục bộ, nhưng phải trả hai cái giá rất lớn.

• Cái giá thứ nhất: bạn không có phản hồi nhanh từ khách hàng. Bạn không ship được thứ gì một cách đều đặn.
• Cái giá thứ hai: những thời điểm chuyển đổi (migration) trở nên cực kỳ căng thẳng và đáng sợ, vì bạn mang theo cả một đống "rác" tích tụ từ nhiều tháng tiến triển dồn lại một lần.

Stripe coi điều đó là hoàn toàn không chấp nhận được. Thực tế, khi đang phát triển một thứ gì đó, Stripe muốn có phản hồi từ khách hàng nhiều lần trong một ngày. Nên công ty thật sự không chịu thoả hiệp ở điểm này. Muốn đạt năm rưỡi số chín về reliability, nhưng vẫn giữ được quy trình liên tục tiến hoá và phát triển feature, Stripe thấy mình buộc phải đầu tư vào toàn bộ quy trình phát triển và đảm bảo chất lượng từ đầu tới cuối (end-to-end).

3. Dev box chỉ là mắt xích đầu: rollout từng bước

Theo Patrick, dev box chỉ là phần đầu tiên của quy trình end-to-end ấy. Ở đó Stripe có thể gắn instrumentation, observability, các đặc tính vận hành và nhiều thứ khác. Sau đó là cả một quy trình deploy tăng dần (incremental deployment): đầu tiên rollout lên một nhúm máy, rồi 1% số máy, rồi một chiến lược rollout tăng dần (progressive rollout) nào đó từ đấy trở đi.

Nói chung, lý do cho niềm tin chắc chắn của Stripe là: công ty cần reliability và security ở mức cực đoan, đồng thời cần tốc độ (velocity) ở mức cực đoan, và Patrick nghĩ đây là cách duy nhất để có được cả hai.

Boris khen rằng mức chuẩn Stripe đạt được thật sự rất ấn tượng, và anh có cảm giác cả ngành đều nhìn vào Stripe như công ty đặt chuẩn cho reliability. Patrick đáp lời khen đó thật dễ nghe, và tất nhiên Stripe đã làm việc cực kỳ vất vả để giữ được mức ấy.

4. AI là gió xuôi hay gió ngược: 600 pull request, đúng một revert

Patrick nói thời kỳ agentic development là một giai đoạn thú vị với Stripe, vì rõ ràng có một câu hỏi đặt ra: AI sẽ là gió xuôi (tailwind) hay gió ngược (headwind) cho reliability? Có rất nhiều lo ngại kiểu: nếu mọi người viết code nhanh hơn nhiều như vậy, và có thể họ không còn soi xét từng dòng code kỹ như trước, thì sao? Có rất nhiều suy đoán xem chuyện này sẽ nghiêng về phía nào.

Anh kể một dữ kiện cụ thể. Ngay sáng hôm đó anh nói chuyện với một kỹ sư ở Stripe. Trong suốt nửa đầu năm (H1), kỹ sư này đã có hơn 600 pull request được merge. Từng cái một đều được viết bằng AI. Và trong số đó, đúng một pull request phải revert. Theo Patrick, điều đó ít nhất cho thấy hoàn toàn có thể có tốc độ phát triển tăng vọt như vậy mà về mặt thực nghiệm vẫn giữ được reliability khá cao.

5. Minions: giao việc bằng một prompt, nhận lại một pull request

Patrick giới thiệu Minions, một lớp nằm phía trên dev box. Minions là cách để orchestrate các VM bằng prompt: từ Slack, từ một giao diện web, hay về nguyên tắc là từ bất kỳ công cụ nào, bạn chỉ cần yêu cầu implement một feature nào đó, hoặc hoàn thành một task nào đó.

Minions sẽ tạo một VM hoàn toàn mới cho yêu cầu đó, rồi đi làm tất cả các task dọc đường. Sau đó nó đóng gói lại, submit, build, chạy qua test suite của Stripe, đi hết toàn bộ quy trình end-to-end.

6. Chất lượng mỗi pull request tăng, độ tin cậy tổng giữ nguyên

Về số liệu, Patrick cho biết Stripe đã thấy chất lượng tính trên mỗi pull request (quality per pull request) tăng lên trong 18 tháng qua.

Vẫn còn một thách thức: số sự cố tính theo đơn vị thời gian (incidence per unit time) đã tăng nhẹ. Nhưng giờ đây phần lớn là những sự cố rất nhỏ, và toàn bộ các cơ chế thứ cấp của Stripe để bắt lỗi trước khi chúng thành vấn đề đã giúp reliability tổng thể về cơ bản không thay đổi. Stripe coi đó là một kết quả khá đáng mừng.

Rồi Patrick nói tới phần anh thấy hay: với LLM, với AI và mọi thứ khác, giờ đây đương nhiên có khả năng build những loại observability mới, instrumentation mới, harness mới, những kiểu soi xét tự động (automated scrutiny) mới mà trước đây không thể build được. Vì vậy anh khá tự tin rằng trong một hai năm tới, xét tổng thể (on net), AI sẽ làm Stripe đáng tin cậy hơn đáng kể.

7. Guardrail là infrastructure: dựa vào bảo đảm, không dựa vào xác suất

Boris hỏi cụ thể hơn, đi vào phần "ốc vít" (nuts and bolts): làm sao Stripe ship nhanh hơn nhờ AI mà không phải đánh đổi reliability và chất lượng? Những guardrail cụ thể là gì? Anh nói thêm từ phía Anthropic: họ muốn ship một model thật sự aligned, và có cả một loạt cơ chế bảo vệ ở đó, như bảo vệ chống prompt injection. Nhưng ngoài ra, khi số pull request cứ tích tụ lại, làm sao bảo đảm mọi thứ vẫn đáng tin cậy và chất lượng code đi lên?

Patrick nói về cơ bản tất cả quay về một ý: dựa vào bất biến (invariants) và những rào chắn cứng (hard barriers), thay vì những thứ mang tính chủ quan hơn, tuỳ ý hơn hay dựa trên xác suất. Đương nhiên sẽ tốt nếu model được align và có nhiều khả năng viết code đúng hơn, code an toàn hơn, hay gì đi nữa. Nhưng không có gì là hoàn hảo cả. Bạn thật sự muốn dựa vào những bảo đảm (guarantees).

Boris tóm lại điều anh nghe được: ngay cả trước thời AI, đã có rất nhiều lợi ích khi mã hoá guardrail và ràng buộc thành infrastructure, vì nhờ đó kỹ sư mắc ít lỗi hơn. Patrick xác nhận: đúng vậy. Boris nói tiếp: cũng có lợi ích từ việc phân tách dữ liệu (data segregation), bảo đảm rằng người ta đơn giản là không thể truy cập dữ liệu họ không được phép truy cập. Patrick: đúng. Boris kết lại: và giờ những thứ đó đang trả cổ tức.

8. Gắn nhãn dữ liệu từ 2017 và cán cân tấn công, phòng thủ

Patrick hoàn toàn đồng ý với tất cả những điều đó. Thực ra Stripe đã bắt đầu đầu tư nghiêm túc vào phần lớn bộ máy này từ năm 2017: hệ thống, việc gắn nhãn (tagging), và những guardrail "hiểu ngữ nghĩa" (semantically aware guardrails) quanh dữ liệu. Đó là một hành trình nhiều năm, vì có rất nhiều thứ phải chú thích (annotating), rất nhiều phân quyền chi tiết (granular permissioning) phải làm, và còn nữa.

Stripe làm tất cả những việc đó vì công ty cho rằng các bảo đảm về security là cực kỳ quan trọng. Nhưng Boris nói đúng: tình cờ điều đó lại đặt Stripe vào một vị thế tốt hơn khi agentic development xuất hiện.

Boris nói thêm: và may là Claude cũng rất giỏi viết guardrail. Patrick đồng ý: đúng thế, đúng thế.

Patrick mở rộng ra một câu hỏi chung mà cả thế giới đang đặt ra: xét tổng thể, AI và LLM sẽ có lợi cho phía tấn công (offense-advantaging) hay phía phòng thủ (defense-advantaging)? Phỏng đoán của anh là ở trạng thái cân bằng sau vài năm nữa, tất cả sẽ nghiêng đáng kể về phía có lợi cho phòng thủ.

9. Claude Code trên mọi dev box, và câu chuyện Stripe Projects

Boris muốn quay lại chuyện Stripe dùng Claude Code thế nào: dùng Claude ra sao, đã ship những sản phẩm gì?

Patrick cho biết mọi dev box ở Stripe đều cài sẵn Claude Code. Đó là nơi đầu tiên người ta tìm tới khi một người bình thường (median person) ở Stripe cần hoàn thành một task nào đó. Nó thật sự đã đem lại sự tăng tốc đáng kể.

Một ví dụ anh thấy khá có tính thông tin: đầu năm, Stripe có ý tưởng build một thứ gọi là Stripe Projects. Ý tưởng này phần nào được truyền cảm hứng từ chính Claude Code. Khi bạn build một project bằng Claude Code, với bất cứ thứ gì có chút quy mô hay thực chất, bạn luôn luôn cần nối nó với một nhóm dịch vụ khác. Tôi muốn PostHog để log, hoặc muốn host trên Vercel, hoặc muốn một database, hay gì đó.

Vì gần như tất cả những công ty này vốn đã là khách hàng của Stripe, Stripe nghĩ mình có thể làm việc với họ để mở năng lực của họ theo một cách mới, và làm cho việc một agent tự tạo một tài khoản với họ trở nên cực kỳ dễ dàng.

Stripe có ý tưởng này đầu năm, quyết định đi build nó. Đội làm là từ hai tới ba kỹ sư, trong khoảng hai tháng, tính từ ý tưởng đầu tiên tới khi ra mắt công khai. Và trong đó không chỉ có việc build các API nội bộ, dịch vụ, harness và mọi thứ, mà còn tích hợp với tới giờ là khoảng 50 dịch vụ khác nhau. Mỗi dịch vụ lại có những đặc thù riêng và thỉnh thoảng có bug. Patrick không nghĩ có thể làm được điều đó với hai ba người trong tám tuần ở "thời trước" (the before times).

Theo trang tài liệu chính thức, Stripe Projects hiện đang ở giai đoạn public preview, là một CLI giúp cấp phát và quản lý các dịch vụ bên thứ ba (hosting, database, auth, AI, observability) ngay từ terminal, và có sẵn skill cho Claude Code cùng các coding agent khác.

10. Nhanh hơn ít nhất 6 lần: phép tính của Patrick

Boris hỏi: trước đây việc đó sẽ mất bao lâu?

Patrick đã hỏi một trong những kỹ sư tham gia, và ước tính của người đó là: một đội lớn hơn. Anh ấy không nói chính xác lớn hơn bao nhiêu, chỉ nói một đội lớn hơn, và sáu tháng. Patrick đề nghị: cứ cho là một đội lớn gấp đôi, "tôi cũng không biết nữa".

Và anh đoán như vậy thì sẽ lâu hơn 3 lần. Tức là một thay đổi tương đối 6 lần. Nhưng lại nữa, có thể đó là ước tính thấp. Ai mà biết được, vì kỹ sư phần mềm vốn nổi tiếng là lạc quan khi ước lượng các project phần mềm. Nên có lẽ có thể nói là tăng tốc ít nhất 6 lần.

Patrick nói tiếp: Stripe có hàng nghìn kỹ sư phần mềm, và ai biết được liệu mọi project có được tăng tốc ở mức đó không. Anh nghi là có một phân phối: có thứ nhanh hơn rất nhiều, có thứ thì không. Nhưng một lần nữa, kể cả khi thật bi quan, cứ cho là AI chỉ đem lại cải thiện 2 lần trên toàn bộ những gì Stripe làm, thì đó rõ ràng vẫn là một chuyện lớn tới mức phi lý. Boris đồng tình: đúng vậy, rất lớn.

11. Kỹ sư làm gì với thời gian dư: nhiều sản phẩm hơn ở Sessions

Boris tóm lại: cần ít kỹ sư hơn, họ làm nhanh hơn. Patrick chen vào: và lại với chất lượng cao hơn, ít nhất là tính trên mỗi pull request. Boris nhắc lại: với chất lượng cao hơn, giữ được mức chuẩn reliability. Vậy kỹ sư làm gì? Họ chỉ làm nhiều project hơn, thử nhiều thí nghiệm hơn?

Patrick nghĩ Stripe chắc chắn đang tạo ra nhiều sản phẩm hơn và thử nhiều thí nghiệm hơn, và có thể thấy điều đó trong các con số. Stripe vừa tổ chức hội nghị thường niên Sessions, và anh nhìn vào số sản phẩm mới, số feature mới được công bố.

Anh thừa nhận "một đơn vị feature" (the quantum of the feature) được định nghĩa phần nào chủ quan và định tính. Nhưng Stripe cố giữ cách đếm khá nhất quán từ năm này qua năm khác. Số sản phẩm và feature mới ở Sessions năm nay vượt xa bất kỳ năm nào trước đó. Tổ chức kỹ thuật có lớn hơn đôi chút, nhưng rõ ràng có một hiệu ứng năng suất nào đó đang diễn ra.

12. Mọi codebase giờ là prompt cho một codebase khác

Vậy là Stripe chắc chắn đang build nhiều hơn cho khách hàng. Nhưng một điều khác Patrick thấy khá thú vị, và đi ngược với một số lo ngại về "slop" (code AI kém chất lượng), là Stripe giờ đang làm nhiều project hơn để cải thiện kiến trúc và cải thiện codebase của chính mình.

Có một câu của một người bạn mà người ở Stripe hay nhắc: mọi codebase giờ là prompt cho một codebase khác (every code base is now the prompt for another code base). Và tất nhiên, Jarred Sumner, người từng làm ở Stripe, đã chứng minh điều đó với bản viết lại Bun.

Patrick đặt câu hỏi: với AI và LLM, có thể có một câu hỏi là ta nên kỳ vọng chất lượng code ở Stripe sau ba năm nữa cao hơn hay thấp hơn? Và anh nghĩ câu trả lời phải là cao hơn.

Boris thấy điều này thú vị: có một kiểu "tính lỏng" giữa token và infrastructure. Bạn có thể dùng token để viết code sản phẩm. Bạn có thể dùng token để viết infrastructure. Bạn có thể dùng nó để viết guardrail. Và anh nghĩ người ta hơi quá tập trung vào việc dùng nó để trực tiếp build sản phẩm. Patrick đồng ý: đúng vậy. Boris nói tiếp: chính những use case trung gian ấy mới là một số use case mạnh nhất.

13. Rào cản thật sự: hiểu cái gì giờ đã làm được

Boris hỏi: Stripe đã gặp những rào cản nào khi đưa AI lên quy mô này trong nội bộ?

Patrick trả lời rằng nói chung AI được đón nhận rất hào hứng, rất trọn vẹn và rất nhanh. Nên theo một nghĩa nào đó, hỏi về rào cản nghe hơi buồn cười khi mức độ hăng hái áp dụng cao như vậy.

Những lần "đổi pha" (phase changes) chắc chắn là: thứ nhất, bản thân Claude Code như một phương thức làm việc (modality), và anh quay sang cảm ơn Boris vì điều đó. Thứ hai, những cải tiến model cuối năm ngoái là một điểm bước ngoặt nữa.

Trong suốt năm nay, theo anh, điều chính mà mọi người phải làm quen trong đầu là có cảm nhận về những gì giờ đã khả thi, và về cách giờ đây một người có thể làm việc.

14. Một plan thật kỹ, rồi mười dev box chạy song song

Patrick kể về một người ở Stripe và cách người đó thích làm việc. Anh ta sẽ làm việc với model thông minh nhất đang có để dựng một plan rất phức tạp, rất chi tiết, thật sự đầu tư nhiều vào quá trình lập plan. Rồi có thể phân việc cho 10 dev box khác nhau, mỗi cái có agent thực thi một phần khác nhau của plan. Và chúng có thể làm cả ngày, hoặc trong trường hợp cực đoan là nhiều ngày liền, để implement plan đó.

Đó là một cách làm việc rất khác, phải không? Không chỉ rất khác so với cách mọi thứ vận hành trước thời AI, mà nó còn không hiển nhiên, ngay cả khi đã có Claude Code: rằng "à, mình có thể", rằng khối lượng công việc giao một lần (the quantum of labor) thực ra có thể lớn đến vậy. Và lại nữa, nếu được orchestrate và dẫn dắt đúng cách, model có khả năng tự kiểm chứng (self-verification) ở mức rộng như vậy.

Patrick tự nhận gần đây chính anh đã đánh giá thấp chế độ plan (plan modality), tức plan mode trong Claude Code. Mọi thứ cũng đã tiến bộ rất nhiều trong suốt năm nay, và anh đã thay đổi cách mình dùng model.

Tóm lại, theo anh, vấn đề chỉ là xây được trực giác cho một phương thức làm việc liên tục thay đổi, một mục tiêu luôn di chuyển.

15. Nghĩa địa project, sự tò mò, và 70% startup viết 100% code bằng AI

Boris kể chuyện của mình: anh có một "nghĩa địa" khổng lồ những project đã bắt đầu mà không bao giờ làm xong. Và giờ chuyện đó gần như không còn nữa. Bạn hoàn thành mọi project, rồi mới quyết định: mình có muốn cái này hay không? Patrick: đúng, chính xác.

Patrick nói chắc chắn là những ý nghĩ chợt đến lúc tắm (shower thoughts) giờ được biến thành thứ tồn tại thật với tỷ lệ cao hơn nhiều. Anh nghĩ lợi ích thu về từ việc tò mò (the returns to being curious) đã tăng lên rất nhiều.

Boris chuyển sang phía Stripe: AI đang thay đổi kinh doanh thế nào. Một điều anh hay nghĩ là với AI, các đội nhỏ dễ cạnh tranh với các đội lớn hơn nhiều theo cách trước đây không thể.

Anh kể mình làm những buổi nói chuyện ở Y Combinator khoảng ba tháng một lần. Trước đây anh hay hỏi: ai dùng Claude Code, giơ tay lên. Khi Claude Code mới ra, vài cánh tay giơ lên; rồi tới một lúc, mọi cánh tay đều giơ. Giờ anh hỏi một câu khác, vì câu kia không còn hữu ích nữa: ai viết 100% code bằng AI? Và bây giờ, ở những startup rất nhỏ này, khoảng 70% người viết 100% code bằng AI.

Boris nghĩ có nhiều startup hơn trước. Họ đi nhanh hơn trước. Họ giải những bài toán tham vọng hơn. Anh tò mò liệu Patrick có thấy điều này trong dữ liệu không.

16. Dữ liệu của Stripe: số doanh nghiệp mới tăng gấp đôi

Patrick giải thích nguồn dữ liệu. Stripe ra mắt 15 năm trước, nên có một chuỗi thời gian dọc (longitudinal time series) dài một thập kỷ rưỡi về việc thành lập doanh nghiệp. Stripe cũng đã khá phổ biến với developer trong một số năm đáng kể, nên anh nghĩ những gì thấy được trong chuỗi số liệu của Stripe là một kiểu chỉ báo đại diện (proxy) cho những gì đang diễn ra trong cả hệ sinh thái.

Ví dụ, vào tháng 3 năm 2020, Stripe thấy số doanh nghiệp mới thành lập trên Stripe tăng tốc đáng kể, vì những lý do khá hiển nhiên. Anh nhắc tới mốc này vì sự tăng tốc Stripe thấy trong năm qua, xét tương đối, lớn hơn nhiều so với bất kỳ đợt tăng tốc nào trước đó Stripe từng thấy. Số doanh nghiệp mới ra mắt trên Stripe trên mỗi đơn vị thời gian đã tăng khoảng gấp đôi.

Và lại nữa, như một chỉ số đại diện cho độ phủ: khoảng một phần tư tổng số công ty Delaware giờ được thành lập qua Stripe. Trong số những công ty không qua Stripe, rất nhiều là những công ty con lặt vặt của một tập đoàn đa quốc gia hay gì đó. Nên Patrick nghĩ trong số các startup thực thụ, tỷ lệ còn lớn hơn 25%. Vì vậy anh cho rằng những gì Stripe thấy khá đại diện, và điều Stripe thấy là một sự tăng tốc rất lớn.

17. Anh Quốc, doanh thu mỗi doanh nghiệp, và một nền kinh tế phân tán hơn

Điều thú vị, theo Patrick, là sự tăng tốc này khá rộng khắp, theo nghĩa Stripe thấy điều tương tự ở hầu hết các quốc gia. Thậm chí trong nhiều trường hợp, dữ liệu của chính phủ còn chưa "tỉnh dậy" trước hiện tượng này.

Gần đây Stripe đã đăng một bài trên substack Stripe Economics về việc số liệu doanh nghiệp chính thức của Anh Quốc cho thấy số công ty mới thành lập giảm so với cùng kỳ năm trước. Trong khi trên thực tế, và bài viết có đi qua phương pháp luận, Stripe cho rằng Anh Quốc đang chứng kiến một làn sóng khởi nghiệp mới rất lớn.

Và điều Stripe thấy là doanh thu trung bình của mỗi doanh nghiệp mới đang tăng chứ không giảm. Nên đây là nhiều công ty hơn hẳn và kết quả trung bình đang tốt lên. Nếu chia nhỏ ra để nhìn các doanh nghiệp đạt 100 nghìn đô, hay một triệu đô, hay lại nữa, bất kỳ ngưỡng doanh thu tuỳ chọn nào, thì những con số đó cũng đều tăng rất đáng kể.

Vì vậy Patrick nghĩ đơn giản là giờ là thời điểm tốt hơn cho khởi nghiệp so với quá khứ tương đối gần, và điều đó khá phấn khích.

Anh nói thêm: một trong những lo ngại về AI là nó sẽ dẫn tới một nền kinh tế tập trung hơn. Nhưng trong dữ liệu vi mô (micro data) Stripe quan sát được, chắc chắn có bằng chứng cho điều ngược lại: có nhiều doanh nghiệp mới được thành lập hơn, những doanh nghiệp đó có nhiều khả năng thành công hơn, và tốc độ tăng trưởng nói chung đang cải thiện. Nên Stripe khá phấn khởi.

18. Khi agent trả tiền cho agent

Boris hỏi: điều này có thay đổi loại sản phẩm Stripe đang build không? Có thay đổi cách Patrick nghĩ về sản phẩm của chính mình không?

Patrick nói Stripe đang nghĩ về chuyện tất cả các agent và các instance Claude Code sẽ tự dùng Stripe trực tiếp như thế nào, cả với sản phẩm Stripe lẫn việc chúng giao dịch nói chung ra sao. Stripe đang nghĩ rất nhiều về một thế giới mà trong phần lớn giao dịch, agent là đối tác ở cả hai phía.

Từ đó là một loạt câu hỏi Stripe đang tự đặt ra:

• Một agent đăng ký Stripe thế nào? Một agent dùng Stripe thế nào?
• MCP đã đủ chưa?
• Stripe CLI nên làm được gì? Làm sao bảo đảm mọi thứ trong Stripe đều có thể được orchestrate và thực hiện từ CLI, hoặc theo một cách nào khác mà agent tiếp cận được?
• Các agent sẽ trả tiền cho nhau thế nào, và dùng loại tiền tệ nào?

Boris nhận xét: vậy không chỉ là nền kinh tế agent, mà là nền kinh tế agent với agent (agent to agent economy). Patrick: đúng, đúng.

Patrick nói quan điểm chung của Stripe (the Stripe house view) là phần lớn giao dịch sẽ diễn ra giữa các agent trong vòng, cứ gọi là, ba năm. Có thể phần lớn giá trị tính bằng đô la sẽ không trực tiếp diễn ra giữa các agent, nhưng anh sẽ khá ngạc nhiên nếu không có một "cơn lốc xoáy" những khoản thanh toán agent với agent khá nhỏ.

Boris cảm ơn Patrick rất nhiều vì đã ghé qua. Patrick cảm ơn vì được mời, nói buổi trò chuyện rất vui. Boris đáp rằng buổi nói chuyện thật tuyệt, và đùa rằng anh mới hỏi được khoảng một nửa số câu hỏi đã chuẩn bị.