Cuộc trò chuyện với người sáng lập Instagram: Anthropic ra mắt Fable 5 — Thời đại viết mã thủ công thuần túy đã qua đi mãi mãi
Tuyển chọn TechFlowTuyển chọn TechFlow
Cuộc trò chuyện với người sáng lập Instagram: Anthropic ra mắt Fable 5 — Thời đại viết mã thủ công thuần túy đã qua đi mãi mãi
Sonnet và Fable 5 hoàn toàn khác biệt về mức độ cảm nhận.
Chuyên sâu báo cáo Web3Biên tập & Dịch: TechFlow
Khách mời: Mike Krieger, đồng sáng lập Instagram
Dẫn chương trình: Dan Shipper
Nguồn podcast: Every
Tựa đề gốc: Mike Krieger Lets Fable 5 Code While He Sleeps
Ngày phát sóng: Ngày 11 tháng 6 năm 2026
Tóm tắt trọng tâm
Mike Krieger từng là đồng sáng lập Instagram – một trong những ứng dụng tiêu dùng có ảnh hưởng nhất thế giới trong hai thập kỷ qua. Còn hôm nay, ông đang ở tuyến đầu tiên của việc phát triển sản phẩm “nguyên sinh AI” (AI-native), với vai trò người đứng đầu Anthropic Labs, dẫn dắt đội ngũ lao vào giải bài toán cuối cùng: Khi trao những mô hình AI mạnh nhất thế giới vào tay các nhà phát triển thực thụ, thì giới hạn khả năng công nghệ rốt cuộc có thể được đẩy tới đâu?
Năm tháng trước khi Fable chính thức ra mắt, ngay từ lần đầu tiên được trải nghiệm nội bộ mô hình này, cảm giác choáng ngợp và mất kiểm soát đã khiến ông nhớ mãi đến tận ngày nay. “Ồ, tôi lại trở thành một tân binh hoàn toàn,” ông tự đùa với đội ngũ lúc ấy. Ông bỗng nhận ra rằng mọi nguyên tắc kinh nghiệm tích lũy suốt mấy chục năm qua – từ nâng cao hiệu suất, chiến lược phát triển phần mềm đến quản lý thời gian – đều bất ngờ trở nên lỗi thời. Tốc độ tiến hóa của mô hình đã vượt xa hoàn toàn luồng công việc quen thuộc của ông.
Trong tập podcast này, người dẫn chương trình đã có cuộc trò chuyện sâu sắc với Mike Krieger, để cùng khán giả khám phá: Việc làm việc song hành và cùng xây dựng phần mềm với một mô hình mang tính cách mạng như Fable – một mô hình vượt bậc cả về độ cứng cỏi lẫn tầm vóc – thực chất là một trải nghiệm như thế nào? Trong trạng thái mới của sự cộng sinh giữa con người và máy móc này, những nhịp điệu phát triển mới, những thách thức nghiêm trọng và những tiềm năng cuối cùng đầy sức tưởng tượng nào đang được khơi dậy?
Tóm tắt các quan điểm nổi bật
Fable đã tái định hình hoàn toàn luồng công việc của Mike như thế nào
- “Sự nâng cấp nhận thức thực sự đến từ vài tuần sử dụng liên tục và cường độ cao – chứ không phải chỉ từ trải nghiệm ban đầu. … Khi thời gian tương tác kéo dài, mọi người bỗng nhiên nhận ra: ‘Tôi chưa khai thác hết tiềm năng của nó. Tôi cần đẩy mạnh hơn nữa, suy ngẫm lại xem ranh giới khả năng thật sự của thế hệ mô hình này nằm ở đâu.’”
- “Cách vận hành đúng hiện nay là: Truyền đạt cho nó một ý định tổng quát và đầy đủ hơn, sau đó hoàn toàn buông tay để nó tự xử lý. Nó không chỉ đưa ra kết quả gây kinh ngạc trong một lần duy nhất, mà điều đáng sợ hơn là nó hiểu rõ hướng phát triển tiếp theo của chức năng này cũng như toàn cảnh ngữ cảnh dự án.”
- “Điều khiến tôi thực sự khâm phục nhất chính là khả năng tự đóng vòng (auto-closure) của nó. Ví dụ, nó sẽ tự suy luận như thế này: ‘Mike giao cho tôi chạy một tác vụ phức tạp tối nay. Nhưng tôi bị kẹt vì máy chủ từ xa đã sập. Vậy thì tôi sẽ tự viết một mock backend để tạm thay thế…’ Với tôi, việc có thể ủy thác mức độ nhiệm vụ như vậy và hoàn toàn tin tưởng vào kết quả cuối cùng do nó tạo ra – đó là một trải nghiệm cực kỳ chấn động.”
- “Trước đây chúng ta thường so sánh loại mô hình này với ‘trợ lý’ hay ‘người bạn đồng hành’, nhưng giờ đây, nó giống hơn với một ‘đồng đội cứng cỏi’ thực sự – người có thể chịu trách nhiệm, và đảm nhận khối lượng công việc cốt lõi rất lớn.”
Khi nào dùng Sonnet, khi nào dùng Fable
- “Cảm giác hoàn toàn khác biệt về cấp độ. Điều này thậm chí còn chẳng liên quan gì đến số token mỗi giây, mà là vấn đề ‘cần bao nhiêu dung lượng tư duy’ để giải quyết bài toán này. Đôi khi, một câu trả lời đơn giản hoàn toàn không cần quá nhiều suy luận sâu sắc kiểu ‘đóng phim’.”
- “Hầu hết thời gian tôi lướt ứng dụng iOS trên điện thoại, chắc chắn không phải để làm những công việc nặng nề đến mức phải ‘động đến Fable’. … Gần đây tôi thực sự cảm nhận rõ tâm lý tinh tế này: ‘Vấn đề này căn bản không xứng đáng để gọi Fable ra, tôi nên gọi Sonnet thôi.’”
- “Fable cũng là mô hình đầu tiên khiến tôi chủ động điều chỉnh ‘mức độ cố gắng’ (Reasoning Effort – độ sâu suy luận). … Trước đây khi dùng Opus, tôi hầu như không điều chỉnh thông số này, bởi khoảng đàn hồi khả năng mở rộng của mô hình lúc ấy chưa lớn như vậy, nhưng với Fable, khoảng biến thiên thực sự rất rộng.”
Cấu trúc kiến trúc Agent-native do Fable 5 thúc đẩy
- “Cấu trúc kiến trúc Agent-native, ở giai đoạn đầu tiên, yêu cầu: Mỗi thành phần cốt lõi và dữ liệu trong sản phẩm đều phải hoàn toàn mở cho Agent, đồng thời đều phải có giao diện API tương ứng để gọi công cụ. Điều này đang nhanh chóng trở thành ‘nền tảng sống sót’ của ngành phần mềm – dù buồn thay, hiện nay đa số phần mềm trên thị trường thậm chí còn chưa đạt được mức cơ bản này.”
- “Chỉ cần nhấn giữ nút trò chuyện trong ứng dụng, bạn sẽ đánh thức Agent được quản lý của chúng tôi để nhận lệnh ‘sửa mã’. … Khi tôi đang chơi ngoài trời với con, nhận thấy ‘nút nổi này trên iOS đặt quá thấp’, tôi chỉ cần nói thẳng trong ứng dụng, và nó tự chạy về nền để sửa mã ngay lập tức.”
- “Claude rốt cuộc nên được nhúng vào phần mềm như thế nào? Nó không nên chỉ dừng ở mức ‘sử dụng’, mà cần ăn sâu vào tận ‘xương tủy’ của quy trình ‘xây dựng’ phần mềm.”
Chi phí xây dựng đã sụp đổ
- “Nhớ lại phiên bản V1 của Instagram – chức năng thực tế vẫn nhiều hơn một chút so với công cụ theo dõi phương tiện truyền thông tôi vừa làm cuối tuần này, nhưng tuyệt đối không tồn tại sự khác biệt mang tính cấp số nhân. Còn để xây dựng phiên bản V1 ấy ngày xưa, Kevin và tôi đã phải thức trắng năm đêm liên tiếp… Còn bây giờ thì sao? Thời gian xây dựng thực sự đã bị rút ngắn đến mức kinh hoàng.”
- “Khoảng cách giữa ‘ý định’ và ‘thực thi’ – vốn từng là vực sâu ngăn cách những người không biết lập trình với thế giới kỹ thuật số – nay đã bị san bằng. … Đây là lần đầu tiên trong đời tôi cảm nhận rõ ràng rằng: Những điều mình nghĩ trong đầu và những thứ hiện hữu trong thế giới thực – giữa chúng giờ đây không còn khoảng cách nào.”
- “Sức sáng tạo của con người là vô tận, và điều tuyệt vời nhất mà chúng ta đang làm hôm nay chính là mở rộng vô hạn ranh giới của nhóm người ‘có khả năng biến ý tưởng trong đầu thành hiện thực’.”
Kỹ thuật phần mềm đã chết chưa?
- “Bản chất của kỹ thuật phần mềm đã hoàn toàn thay đổi. Nó đang trải qua một cuộc biến đổi triệt để. … Thời đại của những nghệ nhân thuần túy chỉ gõ code có lẽ thực sự đã vĩnh viễn đi vào dĩ vãng.”
- “Vai trò của kỹ sư cấp cao vẫn không thể thay thế: Bạn cần dựa vào kinh nghiệm phản ứng sự cố nhiều năm để giữ bình tĩnh tuyệt đối, thu thập toàn bộ dữ liệu nhật ký, thực hiện các biện pháp khẩn cấp để cầm máu, rồi mới tiến hành phân tích để tìm ra giải pháp sửa chữa lâu dài và căn bản.”
- “Trước đây ở Thung lũng Silicon từng phổ biến câu nói: ‘Code wins arguments’ (Mã nguồn thắng tranh luận), cá nhân tôi luôn khá dè dặt với quan điểm này, bởi hàm ý ngầm của nó là: Ai biết viết code thì người đó nắm quyền lực phát ngôn. Nhưng giờ đây, xu hướng phát triển lại diễn ra theo chiều ngược lại một cách thú vị: Đôi khi chúng ta tranh luận mãi không thống nhất được định hướng sản phẩm, thì bỗng một PM không viết code nào đó chạy tới nói: ‘Tôi vừa tự tay làm xong một bản demo…’ – khoảnh khắc ấy lập tức mở ra một cuộc đối thoại cao cấp hoàn toàn mới.”
- “Đặc điểm rõ ràng nhất chính là mức độ song song trong phát triển kinh khủng, và nhu cầu tuyệt đối về việc trừu tượng hóa luồng công việc ở cấp độ cao. Nhưng duy nhất một điều chưa bao giờ thay đổi, đó chính là ‘quyền sở hữu và tinh thần trách nhiệm’ của con người đối với sản phẩm.”
Cơ chế xác minh và chi phí
- “Hiện nay, ‘chi phí’ đã tiến hóa thành một khái niệm đa chiều – bạn không chỉ tính ‘chi phí cho mỗi lần hỏi’, mà còn phải tính ‘chi phí tổng hợp để hoàn tất một việc một cách triệt để’. Điều khiến tôi kinh ngạc nhất ở Fable chính là khía cạnh sau: Nó luôn hướng tới việc làm đúng ngay từ lần đầu tiên, chứ không bắt tôi ngồi trước máy tính đấu tranh với nó suốt tám chín hiệp.”
- “Thích nghi với trạng thái bình thường mới này, hiểu rõ cách cộng tác với nó – đó là điều tất cả chúng ta đều cần học. … Mỗi khi tôi xây dựng thứ gì đó, tôi luôn đảm bảo mỗi PR (pull request) của Claude đều kèm theo ảnh chụp màn hình hoặc video – bất kể đó là PR cho iOS hay thay đổi ở tầng UI. Điều này giúp tôi có được rất nhiều niềm tin.”
- “Video là một công cụ cực kỳ chưa được khai thác hết tiềm năng dành cho Claude. Gần đây tôi đang làm một bản mẫu: Quay video ghi lại những thứ Claude xây dựng được, gửi cho nó kèm FFmpeg, rồi xem nó tự phân tích từng khung hình và nói: ‘Animation này bị giật, để tôi sửa.’ Chụp ảnh màn hình sẽ không bao giờ bắt được điều này, bởi ảnh chụp đã bỏ lỡ khoảnh khắc ấy.”
Luồng công việc động
- “Ở ‘mức sống tối thiểu’ của các thế hệ mô hình trước, dự án thường tồn tại một ‘trần độ phức tạp’. Một khi mã nghiệp vụ hoặc logic của bạn tích tụ đến một khối lượng nhất định, mô hình lớn sẽ bắt đầu ‘chỉ lo đầu mà quên đuôi’… Nhưng hiện nay, người đồng nghiệp nữ không biết lập trình của chúng tôi, dưới sự hỗ trợ của mô hình ở cấp độ Fable, đã nuôi dưỡng hệ thống của cô ấy trong nền suốt vài tháng liền. Bạn có thể rõ ràng nhìn thấy phần mềm ấy như một sinh vật sống, không ngừng phát triển, phát triển và tiến hóa điên cuồng dưới sự ‘tưới tắm’ của AI.”
- “Luồng công việc là một vùng trung gian tốt: Bạn dùng chat để dàn dựng nó, nhưng nó được biểu đạt bằng code, sau đó được thực thi trong một giao diện người dùng sạch sẽ, từng bước đều hiển thị rõ điều gì đang xảy ra. Tôi nghĩ rằng trong tương lai, chúng ta sẽ dùng cách tương tự để kết nối các công việc tầm nhìn dài hạn với chat.”
Fable đã tái định hình hoàn toàn luồng công việc của Mike như thế nào
Dẫn chương trình Dan Shipper: Khách mời của tập hôm nay là Mike Krieger – vừa là người đứng đầu Anthropic Labs, vừa là đồng sáng lập Instagram. Mike, tôi đặc biệt muốn nghe anh chia sẻ cảm nhận thực tế sau khi sử dụng sâu mô hình này. Khi một mô hình mạnh mẽ như vậy ra mắt, nếu có một người dùng hàng ngày, dày dạn kinh nghiệm lên tiếng: “Nó mạnh đến mức khó tin ở những điểm này, thực sự thay đổi luồng công việc ở những mặt này, còn ở những khía cạnh khác thì cũng chỉ ‘vậy thôi’” – điều này sẽ giúp mọi người thực sự hiểu rõ cách công nghệ nên hòa nhập vào đời sống thường nhật của mình.
Mike Krieger:
Đúng vậy. Chính trải nghiệm này đã rất thú vị. Trong vài tháng trước khi Fable chính thức ra mắt, bên trong chúng tôi đã bắt đầu sử dụng một số mô hình cấp Mythos. Lúc ấy tôi rất háo hức chờ xem các nhà phát triển bên ngoài sẽ làm được điều gì với chúng, nhưng như anh vừa nói, sự nâng cấp nhận thức thực sự đến từ vài tuần sử dụng liên tục và cường độ cao – chứ không phải chỉ từ trải nghiệm ban đầu.
Chúng tôi từng trải qua sự tái định hình nhận thức này trên các mô hình trước. Từ cuối tháng Mười Hai năm ngoái đến đầu tháng Một năm nay, mọi người tập trung sử dụng Opus 4.5 và 4.6; khi thời gian tương tác kéo dài, mọi người bỗng nhiên nhận ra: “Tôi chưa khai thác hết tiềm năng của nó. Tôi cần đẩy mạnh hơn nữa, suy ngẫm lại xem ranh giới khả năng thật sự của thế hệ mô hình này nằm ở đâu.”
Dẫn chương trình Dan Shipper: Đội ngũ Every của chúng tôi bên trong đã có một số đồng nghiệp bắt đầu sử dụng. Có người phản hồi: “Tôi cảm thấy mình cần một hệ thống kỹ năng hoàn toàn mới để làm chủ mô hình này”, đặc biệt là những đồng nghiệp không chuyên về kỹ thuật, thiên về công việc tri thức – họ thậm chí còn cảm thấy bối rối không biết bắt đầu từ đâu; còn những người làm công việc biên排 Agent (trí tuệ nhân tạo) thì than thở: “Cần học quá nhiều thứ mới.”
Mike Krieger: Anh vừa nhắc đến “chuyển đổi luồng công việc” – điều này chạm đúng trọng tâm: Không chỉ là thay đổi các bước thao tác cụ thể, mà còn là sự chuyển dịch trong tư duy. Nói cũng lạ, sự xuất hiện của mô hình này lại trùng khớp với thời điểm tôi thay đổi vai trò công việc: Tôi vừa chuyển từ vị trí CPO (Giám đốc Sản phẩm) sang Labs, trở lại chế độ nhà phát triển. Khoảng một tháng rưỡi đến hai tháng sau khi chuyển, chúng tôi lần đầu tiên chạy thành công mô hình này trong nội bộ. Tôi ngồi trước máy tính và nghĩ: “Ồ, tôi lại trở thành một tân binh.” Bởi tôi nhận ra thói quen viết prompt trước đây của mình, thậm chí cả cách phân tích và chia nhỏ nhiệm vụ, đều đã hoàn toàn lỗi thời trước mô hình này.
Cảm giác về quy mô thời gian và mô thức tương tác của bạn đều phải tiến hóa. Trước đây, tôi có thể nói: “Tôi có một ý tưởng chức năng, hãy bắt đầu từ bước đầu tiên…” Giờ đây tuyệt đối không thể làm như vậy nữa. Cách vận hành đúng hiện nay là: Truyền đạt cho nó một ý định tổng quát và đầy đủ hơn, sau đó hoàn toàn buông tay để nó tự xử lý. Tôi nhớ vào tháng Ba–tháng Tư, khả năng của nó đã khiến tôi kinh ngạc: Nó không chỉ đưa ra kết quả gây kinh ngạc trong một lần duy nhất, mà điều đáng sợ hơn là nó hiểu rõ hướng phát triển tiếp theo của chức năng này cũng như toàn cảnh ngữ cảnh dự án.
Và quá trình tiến hóa này hoàn toàn chưa hề dừng lại. Sáng nay tôi còn đang trò chuyện với người khác về công việc – trên máy bay, tôi chợt nhận ra: “Hầu hết công việc tôi thực ra đều có thể làm từ xa.” Tôi thậm chí không còn lo lắng về việc Wi-Fi có bị ngắt hay không, bởi chỉ cần thiết lập đúng ngữ cảnh và chỉ thị (ví dụ một lệnh lặp) trước khi mất kết nối, nó sẽ tự theo dõi và hoàn tất công việc đến cùng.
Trong hai tháng qua, tôi thường xuyên trải qua những khoảnh khắc đỉnh cao như thế này: Trước khi ngủ, tôi chào tạm biệt Claude và giao cho nó một nhiệm vụ phức tạp; sáng hôm sau thức dậy, tôi phát hiện nó đã hoàn tất – thường thì vào khoảng 2 giờ sáng nó đã hoàn thành phần chủ yếu, còn bốn giờ còn lại dành trọn để mài giũa chi tiết.
Điều khiến tôi thực sự khâm phục nhất chính là khả năng tự đóng vòng của nó. Ví dụ, nó sẽ tự suy luận như thế này: “Mike giao cho tôi chạy một tác vụ phức tạp tối nay. Nhưng tôi bị kẹt vì máy chủ từ xa đã sập. Vậy thì tôi sẽ tự viết một mock backend để tạm thay thế, ghi chú vấn đề vào tài liệu, chạy thông toàn bộ quy trình trước, lưu lại, rồi đợi ngày mai dịch vụ khôi phục sẽ sửa lại.” Với tôi, việc có thể ủy thác mức độ nhiệm vụ như vậy và hoàn toàn tin tưởng vào kết quả cuối cùng do nó tạo ra – đó là một trải nghiệm cực kỳ chấn động.
Tất nhiên, bạn chắc chắn sẽ cần kiểm tra lại kết quả sau – điều này liên quan đến một cơ chế xác minh đầy đủ, mà chúng ta sẽ bàn sâu hơn sau, bởi đó là mắt xích then chốt trong vòng khép kín. Nhưng điều này thực sự buộc tôi phải suy ngẫm lại: Trước một mô hình như thế này, rốt cuộc thế nào mới gọi là “hiệu quả”? Trước đây chúng ta thường so sánh loại mô hình này với “trợ lý” hay “người bạn đồng hành”, nhưng giờ đây, nó giống hơn với một “đồng đội cứng cỏi” thực sự – người có thể chịu trách nhiệm, và đảm nhận khối lượng công việc cốt lõi rất lớn.
Dẫn chương trình Dan Shipper: Vậy luồng công việc hàng ngày của anh hiện tại trông như thế nào? Tôi nhận ra một hiện tượng: Nếu bạn giao cho nó một nhiệm vụ lớn, viết dài dòng giải thích, rồi để nó tự chạy vài giờ hoặc qua đêm – lúc đó hiệu suất của nó mạnh nhất. Nhưng khi đối mặt với những việc nhỏ lặt vặt hàng ngày, nó lại tỏ ra quá chậm, quá tốn kém, khiến người ta ngại dùng. Trong thực tiễn công việc, anh cân bằng điều này như thế nào? Nó nằm ở vị trí nào trong hệ thống công nghệ của anh?
Mike Krieger:
Bây giờ tôi chủ yếu dùng nó trong giai đoạn lập kế hoạch kiến trúc và thống nhất phương án. Đây là một sự chuyển dịch thú vị, cũng là bài toán “khó nhằn” mà tất cả các mô hình hiện nay đều cần tiếp tục giải quyết.
Ở khía cạnh này, tôi rất biết ơn kinh nghiệm khi làm Instagram – từ việc sơ khởi dựng bản tối giản nhất trên một máy chủ ở Los Angeles, đến việc xử lý tải đồng thời khổng lồ, mở rộng quy mô, rồi cuối cùng tích hợp toàn bộ vào hạ tầng cơ sở của Facebook. Quá trình này giúp bạn rèn luyện trực giác: “Ở giai đoạn nào của dự án, ta nên áp dụng mức độ trừu tượng hóa và độ phức tạp kiến trúc nào?”
Vì vậy, tôi vẫn duy trì sự trao đổi thường xuyên với Fable. Đôi khi nó đưa ra một giải pháp triển khai trông có vẻ hoàn hảo, tôi sẽ nhắc nhẹ: “Tôi thực sự dự định sẽ đưa cái này lên sản xuất sớm – chúng ta cần cân nhắc khả năng chịu tải ngoài phạm vi máy đơn.” Sự tương tác hai chiều này rất quan trọng. Nhưng khi lập kế hoạch kiến trúc, tôi thường trực tiếp yêu cầu nó tạo một trang HTML để trực quan hóa nội dung thảo luận, nhằm chia sẻ với đội ngũ. Dù chỉ là một file Markdown cũng được, nhưng tôi thích dạng có biểu đồ hơn.
Điều này tạo nên một khuôn mẫu thú vị: Cùng nó suy ngẫm thấu đáo, lập kế hoạch chu đáo, rồi tạo ra một tài liệu để thống nhất với đội ngũ. Vì tốc độ xây dựng nguyên mẫu hiện nay đã bị nén cực mạnh, bạn càng cần sự đồng thuận và thống nhất ở giai đoạn tiền sản xuất – ngay cả khi bạn định “bước nhỏ, chạy nhanh” để làm một bản demo trước, rồi suy ngược ra kiến trúc hệ thống nghiêm ngặt hơn, thì việc giao tiếp tiền sản xuất vẫn cực kỳ quan trọng. Và đây chính là nơi tư duy và hợp tác của con người vẫn ăn sâu vào toàn bộ quy trình.
Ở giai đoạn thực thi, dù là tận dụng thời gian ban đêm hay những khoảng thời gian dài ban ngày, việc để nó chia nhỏ và xử lý riêng lẻ các module nhiệm vụ khác nhau nghĩa là tôi đồng thời duy trì nhiều cuộc hội thoại song song hơn hẳn trước đây. Đôi khi tôi thích mở một phiên Claude Code kéo dài, để nó fork (phân nhánh) toàn bộ nhiệm vụ cho các sub-Agent chạy nền, nhờ đó luồng chính có thể luôn sẵn sàng đáp ứng lệnh mới của tôi; đôi khi tôi thậm chí mở năm sáu tab trình duyệt cùng lúc, để mỗi tab xử lý một nhiệm vụ phức tạp có chu kỳ dài.
Loại mô hình vận hành có tầm nhìn dài hạn, với tinh thần “Đừng lo, cứ giao cho tôi, cần chút thời gian” này thực sự chứa đựng tiềm năng to lớn. Hiện nay chúng tôi cũng đang nghiên cứu trên sản phẩm làm sao hỗ trợ tốt hơn trải nghiệm này – bạn chắc chắn muốn cân bằng cả hai trạng thái “phản hồi tức thì” và “chạy nền dài hạn”, và cách tương tác giữa chúng thực sự rất thú vị. Cá nhân tôi ưa thích: Luôn giữ ít nhất một cửa sổ Claude có ngữ cảnh cao và phản hồi cực nhanh, tạo cảm giác “Tôi luôn sẵn sàng, chỉ cần anh nói một câu là tôi lập tức khởi động hoặc phân nhánh nhiệm vụ con.”
Khi nào dùng Sonnet, khi nào dùng Fable
Dẫn chương trình Dan Shipper: Ví dụ như anh đang đi đường, bỗng nảy ra một câu hỏi – anh sẽ lấy Fable ra dùng ngay không? Cảm giác này có giống như “dùng tên lửa bắn muỗi” không? Hay anh thường xuyên chuyển đổi giữa các mô hình khác nhau?
Mike Krieger:
Gần đây tôi thực sự dùng Fable cho mọi việc, rồi cảm giác giống như anh miêu tả – bạn dán mắt vào màn hình, nhìn nó cứ “cố gắng suy nghĩ” mãi không thôi.
Cho đến tuần trước, tôi muốn tra một câu hỏi đơn giản đến mức hơi ngại, liên quan đến Chung kết NBA. Lúc ấy tôi chuyển sang Sonnet trên thiết bị di động, và lập tức nhận ra: “Ồ đúng rồi! Trước đây tôi tra những câu hỏi nhanh như thế này toàn dùng Sonnet.” Cảm giác hoàn toàn khác biệt về cấp độ. Điều này thậm chí còn chẳng liên quan gì đến số token mỗi giây, mà là vấn đề ‘cần bao nhiêu dung lượng tư duy’ để giải quyết bài toán này. Đôi khi, một câu trả lời đơn giản hoàn toàn không cần quá nhiều suy luận sâu sắc kiểu “đóng phim”.
Với đội ngũ sản phẩm của chúng tôi, đây cũng là một vấn đề rất đáng suy ngẫm. Tổng quan mà nói, bạn chắc chắn không muốn người dùng phải day dứt mỗi ngày về việc chọn mô hình nào ở phía trước. Trong lý tưởng dài hạn, chúng ta có thể gom chúng vào vài “thùng tình huống” cực kỳ trực quan, dễ dùng ngay lập tức; hoặc thậm chí phân luồng trực tiếp theo giao diện tương tác – bởi thực tế mà nói, hầu hết thời gian tôi lướt ứng dụng iOS trên điện thoại, chắc chắn không phải để làm những công việc nặng nề đến mức phải “động đến Fable”. Vì vậy, việc cố định mô hình một cách vô cảm ở tầng giao diện có thể là một hướng đi. Chúng ta sắp tới cần nghiên cứu kỹ điều này thực chất có nghĩa gì trên phương diện sản phẩm. Nhưng tâm lý tinh tế “vấn đề này căn bản không xứng đáng để gọi Fable ra, tôi nên gọi Sonnet thôi” – gần đây tôi thực sự cảm nhận rõ ràng.
Anh nói đúng, với những nhiệm vụ tương tác tần suất cao, chi tiết và mang tính tương tác, Fable sẽ có xu hướng tự động suy luận sâu. Thực tế, Fable cũng là mô hình đầu tiên khiến tôi chủ động điều chỉnh “mức độ cố gắng” (Reasoning Effort – độ sâu suy luận) – đôi khi tôi ngồi đó nghĩ: “Tôi chỉ muốn sửa một chút kiểu dáng UI, vậy điều chỉnh mức độ cố gắng xuống ‘trung bình’ để xem hiệu quả là được.” Trước đây khi dùng Opus, tôi hầu như không điều chỉnh thông số này, bởi khoảng đàn hồi khả năng mở rộng của mô hình lúc ấy chưa lớn như vậy, nhưng với Fable, khoảng biến thiên thực sự rất rộng.
Một công cụ theo dõi phương tiện truyền thông do Mike làm cuối tuần tiết lộ điều gì về kiến trúc agent-native
Dẫn chương trình Dan Shipper: Anh có thể cho chúng tôi xem những thứ anh đã làm với nó không?
Mike Krieger:
Khi loạt mô hình mới này ra mắt, chúng tôi đã làm một việc – khuyến khích toàn bộ đội ngũ sử dụng nó trên tài khoản cá nhân, đặc biệt là tận dụng thời gian cuối tuần. Điều này khá thú vị, bởi bên trong Anthropic có rất nhiều công cụ năng suất tùy chỉnh, nên thỉnh thoảng lùi một bước, trở về trạng thái thuần túy nhất: “Tôi chỉ dùng Claude Code thuần túy, cuối tuần tự làm vài thứ vui cho riêng mình.” Cảm giác này tuyệt vời lắm.
Dẫn chương trình Dan Shipper: Anh chạy nó trên ứng dụng terminal hay ứng dụng desktop?
Mike Krieger:
Câu hỏi hay. Phần lớn thời gian tôi vẫn “ngâm” trong terminal. Nhưng điều thú vị là vợ tôi – bà ấy không phải kỹ sư chuyên nghiệp, nền tảng thiên về nhà thiết kế UX (trải nghiệm người dùng) và PM (quản lý sản phẩm) – lại hoàn toàn say mê Claude Code thông qua ứng dụng desktop. Tôi nghĩ ứng dụng desktop giúp bà ấy tránh được nhiều khái niệm trừu tượng cao cấp ở tầng nền. Còn riêng tôi khi làm dự án này, vẫn dùng Ghostty và terminal.
Lúc ấy tôi chỉ muốn một “công cụ theo dõi tiến độ phương tiện truyền thông” hoàn hảo – tôi thường chơi game, xem phim, lại còn nhận được đủ thứ gợi ý từ bạn bè, nên cần một công cụ hoàn toàn phù hợp với thói quen lưu trữ của riêng mình. Hai tiêu chuẩn cốt lõi của tôi là: Một, việc thêm nội dung phải cực kỳ dễ dàng – chỉ cần nói hoặc gõ một câu với Claude, nó tự đi tìm kiếm toàn mạng, bổ sung đầy đủ thông tin và phân loại cẩn thận; Hai, đẩy thông tin chủ động – ví dụ có mùa mới hoặc phần tiếp theo của trò chơi, nó tự động tìm kiếm.
Hầu hết giao diện người dùng là Fable hoàn thành một lần duy nhất – điều này đã rất tuyệt rồi. Nhưng trong năm nay tại Labs, tôi luôn kiên trì theo đuổi một hướng đi: Làm sao để đội ngũ phần mềm – giờ đây đội ngũ này chính là Claude – gắn bó gần hơn với phần mềm đó?
Đó là một buổi sáng thứ Bảy, thực ra cả cuối tuần tôi đều xếp kín lịch chăm con, nên việc phát triển chủ yếu mang tính “đứt quãng”: Cùng con leo núi, về nhà, viết vài dòng, rồi lại ra ngoài. Đôi khi giữa lúc leo núi tôi cũng không kiềm được mà liếc xem tiến độ – dù không nên nhìn điện thoại khi đang chơi với con, nhưng việc theo dõi từ điện thoại xem nó đang chạy đến đâu thực sự rất đã.
Lúc ấy tôi nảy ra một ý tưởng: Liệu có thể thử nghiệm một cách táo bạo, để phần mềm tự sửa đổi chính nó từ bên trong?
Tôi yêu cầu nó đồng thời làm cả phiên bản di động và phiên bản web. Tôi vốn đã làm một giao diện trò chuyện, có thể trực tiếp nói với Claude: “Giúp tôi thêm URL này vào danh sách theo dõi.” Nhưng tôi muốn mọi phần mềm đều có khả năng tiến hóa như thế – tôi sẽ không bao giờ phải lặn sâu vào các menu phức tạp nhiều cấp để tìm chức năng nữa.
Dan, ở nhiều khía cạnh, thực ra tôi đang cố gắng đẩy kiến trúc nguyên sinh Agent (Agent-native) tới giới hạn tuyệt đối.
Định nghĩa về kiến trúc Agent-native, ở giai đoạn đầu tiên, là: Mỗi thành phần cốt lõi và dữ liệu trong sản phẩm đều phải hoàn toàn mở cho Agent, đồng thời đều phải có giao diện API tương ứng để gọi công cụ. Điều này đang nhanh chóng trở thành “nền tảng sống sót” của ngành phần mềm – dù buồn thay, hiện nay đa số phần mềm trên thị trường thậm chí còn chưa đạt được mức cơ bản này.
Tôi có một ví dụ điển hình tích cực: Gần đây có người giới thiệu cho tôi một bộ phim thần thánh của Brazil, kể về sự cố rò rỉ chất phóng xạ ở Goiânia. Tên phim dài ngoằng và khó nhớ kinh khủng, lúc ấy tôi chỉ nói mơ hồ với hệ thống một câu, Claude lập tức tìm ra và phân loại chính xác. Trải nghiệm này tốt hơn nhiều so với việc tôi tự mò mẫm Google bằng trực giác.
Nhưng điều tôi thực sự say mê ở bước tiếp theo là: Trong môi trường di động, việc trực tiếp sửa đổi phần mềm từ bên trong phần mềm đó sẽ diễn ra như thế nào?
Việc tôi làm – chính xác hơn là tôi ra lệnh cho Claude làm – là một dạng tương tác như thế này: Trong ứng dụng, nhấn giữ nút trò chuyện sẽ đánh thức Agent được quản lý của chúng tôi để nhận lệnh “sửa mã”, sau đó tận dụng chức năng xem trước trực tiếp (Live Preview) của Vercel để xem ngay hiệu quả. Toàn bộ module chức năng này cũng gần như chạy thông một lần – rất tuyệt, sau đó tôi còn liên tục thêm một số ý tưởng mới. Nếu bạn là người chơi hardcore, bạn cũng có thể xem view Diff (sự khác biệt mã nguồn), hoặc click vào lịch sử hội thoại của Agent được quản lý để xem nó thực sự đã sửa gì ở tầng nền – tuy nhiên tôi gần như chẳng bao giờ xem, bởi với dự án đồ chơi cá nhân, tôi hoàn toàn không quan tâm đến khả năng bảo trì lâu dài (cười).
Thứ này dùng thực sự khiến người ta “nghiện”. Khi tôi đang chơi ngoài trời với con, nhận thấy “nút nổi này trên iOS đặt quá thấp”, tôi chỉ cần nói thẳng trong ứng dụng, nó tự chạy về nền để sửa mã ngay lập tức. Kết hợp với chuỗi công cụ phát triển Expo, nó thậm chí trực tiếp thực hiện tái tải nóng (Hot Reload) trên điện thoại của tôi – khoảnh khắc ấy thực sự tuyệt vời.
Thứ này cần đạt đến mức độ sản xuất có thể chịu tải hàng triệu người dùng đồng thời không? Hoàn toàn không cần. Nhưng nó mang lại cho tôi cảm giác kiểm soát tuyệt vời: Bạn không cần phải để dự án “đình trệ” khi cuối tuần kết thúc và bạn đóng máy tính – bạn có thể vừa sử dụng nó một cách sâu sắc, vừa tùy chỉnh nó bất cứ lúc nào trong quá trình sử dụng. Chu kỳ khép kín thời gian thực từ đầu đến cuối này cho phép bạn lặp lại vô hạn.
Đây không chỉ là một màn “khoe cơ bắp” tuyệt vời về khả năng xây dựng kỹ thuật cứng cỏi của Fable, mà còn là biểu tượng thu nhỏ của vấn đề cốt lõi mà chúng ta luôn tranh luận: Claude rốt cuộc nên được nhúng vào phần mềm như thế nào? Nó không nên chỉ dừng ở mức ‘sử dụng’, mà cần ăn sâu vào tận ‘xương tủy’ của quy trình ‘xây dựng’ phần mềm.
Chi phí xây dựng đã sụp đổ
Dẫn chương trình Dan Shipper: Tôi đặc biệt muốn mọi người nhận ra một điều: Những công cụ tương tự như thế này, bạn có thể cũng đã từng “vật lộn” để làm ra cách đây mười, hai mươi năm – nhưng tuyệt đối không phải theo cách này. Chi phí xây dựng phần mềm đã sụp đổ theo cấp số nhân. Hãy nghĩ lại thời kỳ làm Instagram, để đưa một dự án lên mức độ hoàn thiện như thế này cần đầu tư bao nhiêu nguồn lực? Còn bây giờ thì cần bao nhiêu? Hãy giúp chúng tôi định lượng sự biến đổi mang tính thời đại này.
Mike Krieger:
Tôi thường xuyên nhớ lại khoảng thời gian ấy. Trong giai đoạn đầu của Instagram, tôi luôn tự coi mình là một kỹ sư hiệu suất cực cao – đam mê phát triển ứng dụng di động, có trực giác mạnh mẽ về định hướng sản phẩm. Nhưng ngay cả vậy, từ một ý tưởng trong đầu đến khi hiện thực hóa đầy đủ, tôi vẫn phải thức trắng ít nhất bốn đến năm đêm. Lúc ấy thức khuya là chuyện thường ngày: thức tới 4 giờ sáng, rồi ngủ đến trưa – nhịp sinh học này hoàn toàn tách rời khỏi đời sống gia đình, nhưng đó thực sự là “chế độ Xây dựng (Builder)” của tôi ngày ấy.
Nhớ lại phiên bản V1 của Instagram – chức năng thực tế vẫn nhiều hơn một chút so với công cụ theo dõi phương tiện truyền thông tôi vừa làm cuối tuần này, nhưng tuyệt đối không tồn tại sự khác biệt mang tính cấp số nhân. Còn để xây dựng phiên bản V1 ấy ngày xưa, Kevin và tôi đã phải thức trắng năm đêm liên tiếp: Tôi đảm nhận toàn bộ frontend và backend, còn Kevin phụ trách phần lọc ảnh ban đầu. Và điều này còn dựa trên nền tảng cả hai chúng tôi đều có nhiều năm kinh nghiệm phát triển iOS.
Chưa kể nhịp độ lặp lại ngày xưa còn tệ hơn nhiều. Sau khi sản phẩm ra mắt và gây tiếng vang, trong đầu chúng tôi tích lũy vô số ý tưởng mới, nhưng toàn bộ năng lượng lúc ấy chỉ có thể dồn vào việc đảm bảo máy chủ không sập dưới tải lớn, hoặc cố gắng giành ra chút thời gian để thêm một chức năng nhỏ lẻ. Ví dụ chức năng Hashtag (thẻ hashtag), lúc ấy tôi phải mất cả tuần chỉ để viết xong, trong khi thực tế bạn còn hàng vạn việc khác đang bị kẹt cứng trong lịch trình.
Vì vậy, đây không chỉ là việc thời gian bị nén lại – dù thời gian xây dựng thực sự đã bị rút ngắn đến mức kinh hoàng – mà điều quan trọng hơn ở mặt còn lại là: Bạn giờ đây có thể dùng một cách thức trơn tru và linh hoạt đến mức tuyệt vời để lặp lại tức thì những thứ bạn đã có.
Hơn nữa, lợi ích này đã bắt đầu lan tỏa ra ngoài, vượt xa phạm vi của những kỹ sư phần mềm chuyên nghiệp và các nhà sáng lập như tôi. Trước đây, nếu bạn có một ý tưởng kinh doanh tuyệt vời nhưng không biết viết code, bạn chỉ có hai lựa chọn: Hoặc tìm nhà thầu ngoài – điều này dẫn đến mất mát thông tin nghiêm trọng và kết quả giao hàng không như mong đợi; hoặc phải đi kêu gọi vốn điên cuồng. Nhưng bây giờ, khoảng cách giữa ‘ý định’ và ‘thực thi’ – vốn từng là vực sâu ngăn cách những người không biết lập trình với thế giới kỹ thuật số – nay đã bị san bằng.
Vài ngày trước tôi nhận được tin nhắn nội bộ từ một đồng nghiệp. Chúng tôi đã giúp cô ấy cấu hình một công cụ nội bộ, kết nối khả năng của Fable với quyền truy cập MCP (Giao thức Ngữ cảnh Mô hình) nội bộ. Cô ấy làm công việc tuyển dụng (HR), và hào hứng nói với tôi: “Đây là lần đầu tiên trong đời tôi cảm nhận rõ ràng rằng: Những điều mình nghĩ trong đầu và những thứ hiện hữu trong thế giới thực – giữa chúng giờ đây không còn khoảng cách nào. Tôi có thể trực tiếp biến nó thành hiện thực.”
Khoảnh khắc ấy đối với cô ấy chắc chắn là một cú sốc mang tính cột mốc. Nếu đổi lại cách đây bốn năm, nếu cô ấy muốn dùng một công cụ nghiệp vụ riêng, cô ấy chỉ có thể lắp ghép lặt vặt từ các phần mềm sẵn có, hoặc phải van nài kỹ sư đội công cụ nội bộ – trong khi trong kho yêu cầu Jira của họ có thể còn xếp 50 yêu cầu ưu tiên cao hơn. Còn bây giờ thì sao? Cô ấy đang vui vẻ khai phá thế giới code một cách say mê.
Đây cũng là điều tôi cho là đáng mong đợi nhất trong tương lai: Sức sáng tạo của con người là vô tận, và điều tuyệt vời nhất mà chúng ta đang làm hôm nay chính là mở rộng vô hạn ranh giới của nhóm người ‘có khả năng biến ý tưởng trong đầu thành hiện thực’.
Kỹ thuật phần mềm đã chết chưa?
Dẫn chương trình Dan Shipper: Tôi hoàn toàn đồng ý với quan điểm của anh. Nhưng tôi đoán hiện nay rất nhiều người trong lòng đều treo một câu hỏi cuối cùng. Nghe anh vừa mô tả tất cả những điều này: Ngành kỹ thuật phần mềm – liệu đã thực sự chấm dứt?
Mike Krieger:
Phải nói rằng, bản chất của kỹ thuật phần mềm đã hoàn toàn thay đổi. Nó đang trải qua một cuộc biến đổi triệt để.
Nếu bạn hỏi tôi vào thời kỳ làm Instagram: “Rốt cuộc kỹ thuật phần mềm là gì?”, tôi có thể trả lời: “Là việc suy ngẫm thấu đáo những bài toán thiết kế nan giải, xây dựng kiến trúc hệ thống, rồi tiêu tốn hàng đống thời gian trong TextMate hoặc Xcode để khắc phục các chi tiết底层 của Django ORM (Object-Relational Mapping), triển khai lên máy chủ và đau đầu sửa lỗi.” Hầu hết các khâu trong quy trình này hiện nay đã bị đảo lộn hoàn toàn, và đang ngày càng tiến sát hơn về ranh giới quản lý sản phẩm. Hiện nay, ranh giới giữa Product Manager và Engineer đã trở nên cực kỳ mờ nhạt. Điều này thể hiện rõ ràng trong đội ngũ R&D của chính chúng tôi.
Nhưng nếu bạn thoát ra khỏi định nghĩa quá cứng nhắc “kỹ thuật phần mềm”, mà nhìn rộng hơn vào “sản xuất phần mềm” hoặc “phát triển phần mềm” nói chung – chứ không chỉ tập trung vào mảng nhỏ “lập trình viên thuần túy viết code” – bạn sẽ thấy ngành này không những vẫn tồn tại tốt đẹp, mà còn đang ở vị trí then chốt chưa từng có.
Sự xuất hiện của Fable thực sự đưa mức độ tin tưởng của tôi vào mô hình AI lên một tầm cao mới – tôi bắt đầu tin tưởng để nó “chạy toàn bộ vòng khép kín tự động, thậm chí thiết kế kiến trúc hệ thống hợp lý”. Về mặt thực thi kỹ thuật, AI đã tiến rất, rất xa. Nhưng “kiểm soát linh hồn nghề phần mềm” – ví dụ như bạn thực sự đang giải quyết nỗi đau nào của người dùng, trải nghiệm sản phẩm bạn làm ra có đủ ấn tượng hay không – những phán đoán cấp cao này vẫn là đặc trưng thuần túy của con người, không thể thay thế bằng máy móc.
Tất nhiên, sự chuyển đổi mang tính chấn động này không hề dễ dàng đối với nhiều người.
Trên thế giới này, có quá nhiều người từng say mê mãnh liệt “nghệ thuật thủ công thuần túy viết code”. Bản thân tôi ngày xưa cũng vậy. “Bug này làm tôi bí ba ngày, hôm nay tôi giải xong thật đẹp!” – cảm giác sảng khoái ấy là không thể thay thế. Trước đây bạn thậm chí còn tranh luận với code trong giấc mơ – nếu bạn từng trải qua điều này, trong mơ toàn là logic đang cố gắng giải quyết, và khoảnh khắc tỉnh dậy bỗng nhiên linh cảm bắt được lời giải. Thời đại nghệ nhân thuần túy này, có lẽ thực sự đã vĩnh viễn đi vào dĩ vãng.
Gần đây tôi trò chuyện với một số kỹ sư cứng cỏi nhất trong ngành mà tôi biết, và họ đều bày tỏ một cảm xúc phức tạp mạnh mẽ: Một mặt là nỗi thất vọng lớn khi chứng kiến nghề thủ công truyền thống dần tiêu vong, mặt khác là sự phấn khích tột độ khi “trời ơi, năng suất đồng thời của tôi giờ đây mạnh đến mức kinh hoàng”.
Đội ngũ kỹ sư của Anthropic làm việc như thế nào hôm nay
Dẫn chương trình Dan Shipper: Nếu mệnh đề này đúng – kỹ thuật phần mềm không chỉ còn sống, mà còn sống rất tốt – thì trong nội bộ Anthropic, đội ngũ R&D của các anh thực tế hàng ngày làm việc như thế nào?
Mike Krieger:
Có vài dấu hiệu rất rõ ràng, tôi có thể kết hợp toàn bộ vòng đời phần mềm và thực tế phát triển hàng ngày mà tôi chứng kiến để chia sẻ.
Thứ nhất, vẫn tồn tại rất nhiều “sự thống nhất bằng con người”. Mọi người tụ họp trong phòng họp, cùng “động não” thảo luận định hướng phát triển tiếp theo của Cowork, rồi chia bản đồ ra thành các khu vực trách nhiệm khác nhau cho từng thành viên. Bước này vẫn cực kỳ quan trọng, bởi nhiều ngữ cảnh toàn cảnh chỉ con người mới nắm bắt được – ví dụ như mục đích thương mại thực sự của sản phẩm, các “đường dây ngầm” phát triển hiện tại, cũng như những dòng sản phẩm nào sắp bị loại bỏ, hoặc đang chuẩn bị tích hợp theo một cách vô cùng tinh tế vào hệ sinh thái.
Mặc dù đội ngũ chúng tôi trang bị cho mỗi người nhiều “tháp Claude”, nhưng về mặt quản lý, mỗi người vẫn mang danh hiệu DRI (Directly Responsible Individual – Cá nhân Trực tiếp Chịu Trách nhiệm), chịu trách nhiệm riêng về một module cụ thể của sản phẩm. Tôi cho rằng cơ chế này trong ngắn hạn sẽ không biến mất, bởi “việc hợp tác phân tán để cùng hoàn thiện sản phẩm” ở tầm vĩ mô và “việc tôi hôm nay nên để Claude chạy thông nhiệm vụ cụ thể nào” ở tầm vi mô – giữa hai điều này tồn tại một khoảng cách bản chất. Mặc dù chúng tôi đang hết sức thúc đẩy văn hóa họp tối giản, nhưng các buổi “động não” và thống nhất tiền sản xuất này vẫn không thể thiếu.
Thứ hai, là rất nhiều “ủy nhiệm bất đồng bộ”. Nhiều kỹ sư ở đây tự phát triển một bảng điều khiển cá nhân để giám sát “đội quân Claude” của mình đang làm gì: “Claude Code của tôi đang chạy đến đâu?”, “Có việc nào kẹt trong hàng đợi chờ tôi phê duyệt?”, “Có PR nào cần tôi can thiệp sửa – vì bị đồng nghiệp hoặc một mô hình lớn khác review code từ chối?”
Hiện nay, một phần lớn năng lượng của kỹ sư dành cho việc duy trì công việc này. Một số công cụ cộng tác ở đây chúng tôi đang đẩy mạnh chuẩn hóa, nhưng phần lớn vẫn giữ màu sắc cá nhân đậm chất “geek” – giống như trước đây lập trình viên thích tùy chỉnh giao diện cửa sổ máy tính cá nhân, thì giờ đây họ đang tùy chỉnh luồng công việc mô hình lớn của riêng mình.
Thứ ba, là việc hiểu rõ trạng thái vận hành thực tế của mã nguồn trong môi trường sản xuất. Đây là một lĩnh vực tiên phong khác mà mô hình lớn đang hết sức nỗ lực chinh phục. Fable đã thể hiện tiến bộ đáng kể ở khía cạnh này, nhưng vẫn còn rất dài để đi: Ví dụ như việc hiểu sâu sắc mã nguồn sau khi triển khai lên máy chủ, thực tế sẽ xảy ra điều gì. Hệ thống có thể sập, có thể xuất hiện vô số sự cố kỳ lạ không lường trước – thực lòng mà nói, trong những năm 2012–2016 với Instagram, tôi gần như mất nửa mạng để xử lý các sự cố trực tuyến và mở rộng kiến trúc. Trong việc ứng phó với sự cố khẩn cấp, vai trò của kỹ sư cấp cao vẫn không thể thay thế: Bạn cần dựa vào kinh nghiệm phản ứng sự cố nhiều năm để giữ bình tĩnh tuyệt đối, thu thập toàn bộ dữ liệu nhật ký, thực hiện các biện pháp khẩn cấp để cầm máu, rồi mới tiến hành phân tích để tìm ra giải pháp sửa chữa lâu dài và căn bản.
Điểm cuối cùng tôi muốn nhấn mạnh là: “Nguyên mẫu kỹ thuật” (engineering prototype) ngày nay có vai trò hoàn toàn khác.
Bạn phải cực kỳ tỉnh táo để phân định rõ: Thứ bạn đang nắm trong tay rốt cuộc là một bản demo, hay là mã nguồn sản xuất sẵn sàng lên máy chủ. Trước đây ở Thung lũng Silicon từng phổ biến câu nói “Code wins arguments” (Mã nguồn thắng tranh luận), cá nhân tôi luôn khá dè dặt với quan điểm này, bởi hàm ý ngầm của nó là: Ai biết viết code thì người đó nắm quyền lực phát ngôn. Nhưng giờ đây, xu hướng phát triển lại diễn ra theo chiều ngược lại một cách thú vị: Đôi khi chúng ta tranh luận mãi không thống nhất được định hướng sản phẩm, thì bỗng một PM không viết code nào đó chạy tới nói: “Tôi vừa tự tay làm xong một bản demo, dù còn thô ở tám chi tiết – nhưng các anh xem, con đường này chắc chắn chạy được!” – khoảnh khắc ấy lập tức mở ra một cuộc đối thoại cao cấp hoàn toàn mới.
Nhìn lại, hầu hết mọi tư thế phát triển của chúng ta ngày nay đều đã thay đổi hoàn toàn so với sáu tháng trước. Đặc điểm rõ ràng nhất chính là mức độ song song trong phát triển kinh khủng, và nhu cầu tuyệt đối về việc trừu tượng hóa luồng công việc ở cấp độ cao.
Nhưng duy nhất một điều chưa bao giờ thay đổi, đó chính là “quyền sở hữu và tinh thần trách nhiệm” của con người đối với sản phẩm.
Cơ chế xác minh
Dẫn chương trình Dan Shipper: Fable cũng rất đắt. Khi tôi thử nghiệm nó, tôi cảm thấy mình như một đứa trẻ bước vào tiệm kẹo, hào hứng hét lên: “Tôi muốn cái này, cái này, và cả cái này nữa!” Nhưng đến lúc thanh toán, mỗi lần tôi nhấn Enter đều phải run rẩy trong lòng: “Lần này có khi cháy hết trăm đô hoặc hơn?” Tôi nghĩ giá cao như vậy thực tế sẽ tạo ra một rào cản vô hình về “ai được dùng nó” và “dùng nó để làm gì”. Anh nhìn nhận thế nào về hiệu quả kinh doanh của nó?
Mike Krieger:
Trong lĩnh vực kỹ thuật phần mềm chuyên nghiệp, con số này thực ra tính rất rõ ràng. Về định giá, bên trong chúng tôi thực sự cân nhắc nhiều chiều. Nó thực sự đắt hơn Opus nhiều, nhưng nếu bạn đo lường khối lượng công việc đáng kinh ngạc mà nó giao mỗi lần, thì trên nhiều phương diện thương mại, nó rẻ đến mức như đang tặng, dĩ nhiên mỗi người đều có một cuốn sổ kế toán riêng.
Xét từ góc độ đội ngũ phần mềm, nếu giai đoạn đầu là công ty khiến nhân viên chấp nhận lập trình AI – mô hình còn non, công cụ chưa sẵn sàng; giai đoạn hai là tổ chức bảng xếp hạng xem ai dùng nhiều nhất, điều này tạo ra cơ chế khuyến khích không lý tưởng; thì giai đoạn ba là hiểu rõ ai dùng hiệu quả nhất, để những người này có thể chi tiêu càng nhiều càng tốt, đồng thời có một quy trình rõ ràng để tránh lãng phí.
Mô hình ở tầm Fable hoàn toàn phù hợp với logic giai đoạn ba. Nếu bạn có thể liên tục đưa ra thành quả cứng cỏi, và thực sự dùng nó tạo ra giá trị thực tiễn trong kinh doanh, công ty nội bộ tự nhiên sẽ hình thành một cơ chế ngân sách xoay vòng tích cực để hỗ trợ bạn vô hạn.
Với việc sử dụng cá nhân, tôi tự kiểm tra bằng thẻ tín dụng cá nhân để mua dịch vụ của chính công ty mình. Lúc này bạn thực sự sẽ trở nên keo kiệt và cẩn trọng hơn. Nhưng điều thú vị là, công cụ theo dõi phương tiện truyền thông tôi làm cuối tuần, tính ra thực tế chỉ tốn thêm chút tiền, làm một dự án đồ chơi cá nhân hoàn toàn không đến mức cháy hàng nghìn đô.
Hiện nay, điều thực sự bị giá cả kìm hãm là những người yêu thích mã nguồn mở hoặc nhà phát triển độc lập (Indie Hackers) không nằm dưới bóng của các hãng lớn, và cực kỳ nhạy cảm với giá cả. Lời khuyên của tôi dành cho họ là: Hãy thoải mái chạy thử, xem nó rốt cuộc có thể giao một lần được bao nhiêu thứ mà không cần “giằng co vô tận”.
‘Chi phí’ hiện nay đã tiến hóa thành một khái niệm đa chiều – bạn không chỉ tính ‘chi phí cho mỗi lần hỏi’, mà còn phải tính ‘chi phí tổng hợp để hoàn tất một việc một cách triệt để’. Điều khiến tôi kinh ngạc nhất ở Fable chính là khía cạnh sau: Nó luôn hướng tới việc làm đúng ngay từ lần đầu tiên, chứ không bắt tôi ngồi trước máy tính đấu tranh với nó suốt tám chín hiệp, tuyệt vọng hét lên: “Không đúng! Tôi không có ý đó!”
Dẫn chương trình Dan Shipper: Điều khiến tôi kinh ngạc nhất ở nó là: bạn giao cho nó một nhiệm vụ tổng quát, khi nó nộp bài, bạn phát hiện nó đã suy luận kỹ lưỡng từng chi tiết nhỏ nhất – cảm giác tỉ mỉ nghẹt thở này trước đây chưa từng có ở bất kỳ mô hình nào.
Mike Krieger:
Ở nhiều khía cạnh, đây là sự tiếp nối công việc của đội ngũ – tôi chỉ biết kính phục đội tiền huấn luyện và RL của chúng tôi. Đối với tôi, sự tiến hóa rõ ràng nhất là “sự cảm nhận toàn hệ thống”, chứ không chỉ là cảm nhận công việc hiện tại.
Tôi thường bị những thao tác “thần tiên” của nó làm kinh ngạc. Ví dụ, vừa viết xong một đoạn code, nó bỗng nhiên chủ động bật lên một câu: “Anh bạn, tôi biết trong môi trường sản xuất thực tế, cấu hình ở đây có thể khác. Công tắc chức năng của anh đã bật chưa? Nếu chưa bật, thứ tôi vừa viết sẽ không có hiệu lực khi lên máy chủ.”
Hoặc khi nó phản ứng với phản hồi review code – dù đến từ con người hay từ Claude khác – nó không đơn giản nói: “Ồ đúng, đây là vấn đề, tôi đi sửa.” Nó thực sự suy nghĩ xem có nên chấp nhận rủi ro ở mức độ trung thực hiện tại, hoặc phản bác người review khác – thường là một mô hình Fable khác – nói: “Tôi hiểu ý anh, nhưng tôi phản bác, tôi cho rằng anh sai.”
Việc trang bị cho mô hình khả năng phán đoán như thế này cực kỳ quan trọng. Nếu tôi phải chỉ ra nơi nó tiến bộ nhất, đó chính là việc nó không lập tức phản xạ kiểu “đúng đúng đúng, tôi đi sửa” – mà giống hơn là “để tôi suy nghĩ đã. Tôi vẫn không đồng ý.” Khả năng này rất hữu ích.
Có sản phẩm như Claude Code trên thị trường là điều vô cùng quý giá, bởi bạn có thứ thực tế để người ta nói: “Đây là chỗ mô hình làm tốt, đây là chỗ mô hình làm chưa tốt.” Chúng tôi xếp các đối tác của Every vào vị trí rất cao trong danh sách các nguồn phản hồi đáng tin cậy nhất, bởi họ cho mô hình trải qua các nhiệm vụ cường độ cao liên tục trong nhiều ngày, điều này cực kỳ quan trọng để chúng tôi suy ngẫm về điều cần cải tiến ở thế hệ tiếp theo.
Dẫn chương trình Dan Shipper: Chat có phải là giao diện tương tác phù hợp nhất cho mô hình này không? Nó không phải kiểu “luân phiên”, mà giống hơn việc “ủy nhiệm việc gì đó cho một người”. Điều này sẽ ảnh hưởng thế nào đến cách bạn nên dùng nó, hoặc cách bạn nhìn nhận giao diện này?
Mike Krieger:
Mô hình gửi và nhận tin nhắn cơ bản không hoàn toàn sai, nhưng chúng ta cần tiến hóa theo một số hướng.
Thứ nhất: Máy tính xách tay của bạn có phải là nơi đúng đắn không? Đây chính là nơi tôi vừa đề cập về việc ứng dụng di động tuyệt vời đến mức nào cho các dự án cá nhân. Người sáng tạo Claude Code luôn đi trước nửa bước về cách sử dụng các mô hình này, khoảng chín tháng trước tôi trò chuyện với anh ấy, anh ấy nói: “Tôi đã chuyển phần lớn công việc Claude Code của mình sang thiết bị di động.” Lúc ấy tôi còn hoài nghi, nhưng đặc biệt với Fable ở cấp độ này, vì nó có thể duy trì hội thoại, và chúng tôi có máy chủ phát triển từ xa tại Anthropic, nên điểm đầu tiên là: Tách rời nơi công việc diễn ra với nơi bạn thảo luận công việc.
Điểm thứ hai tiếp nối điều tôi vừa nói: Làm sao để bạn khiến mọi thứ mà Fable đã thảo luận, quyết định và đề xuất trở nên dễ hiểu? Đây là lĩnh vực chúng tôi đang suy ngẫm. Một số skill có thể khiến nó vẽ biểu đồ, nhưng giao diện chat hiện tại chưa đủ, Fable đôi khi đưa ra lượng văn bản khổng lồ, bạn phải đi dạo một vòng mới sẵn sàng để hiểu nó. Một việc tôi bắt đầu làm là: “Anh nắm ngữ cảnh về việc này nhiều hơn tôi nhiều. Chúng ta có thể quay lại – tiết lộ độ phức tạp một cách dần dần hơn không?”
Điểm thứ ba là chế độ nhiều người, lĩnh vực này chúng tôi vẫn đang ở giai đoạn đầu tìm tòi. Ở một mức độ nào đó, vì chúng tôi có cấu trúc DRI và khu vực sở hữu, thường một việc quan trọng sẽ luân chuyển giữa một người và vài Claude. Nhưng một số tình huống lại không rõ ràng – ví dụ như phản ứng sự cố, nhiều người cùng suy nghĩ; hoặc các dự án hội tụ nhiều lĩnh vực giao thoa. Chia sẻ chat có thể giải quyết một phần, nhưng tôi nghĩ trong tương lai sẽ xuất hiện nhu cầu như thế này: Bạn có một Claude độc lập, do một người khởi tạo và làm rất nhiều việc, nhưng nó có thể đồng bộ với toàn bộ công việc đang được làm bởi các thành viên khác trong đội không? Đây là một lĩnh vực thú vị và chưa được khai phá đầy đủ tiếp theo. Điều đáng phấn khích là mô hình hiện nay đã có khả năng trở thành một đồng đội thực sự, trong khi chúng ta gần như đang kìm hãm chúng do thiếu các trừu tượng hóa đúng đắn.
Dẫn chương trình Dan Shipper: Điều này khiến tôi nghĩ đến việc phần lớn thời gian tôi dùng mô hình này để làm các dự án “vibe coding” cá nhân, nhưng khi dùng trong tổ chức sẽ nảy sinh một vấn đề: Tôi thực sự hiểu tất cả các phần mà mô hình vừa làm không? Làm sao để tôi chuyển ngữ cảnh của thứ mô hình vừa làm xong vào đầu mình? Đây là một nút thắt lớn. Anh nghĩ thế nào về việc xác định “rốt cuộc tôi cần biết bao nhiêu” và làm sao đảm bảo mình có đủ ngữ cảnh để cảm thấy yên tâm?
Mike Krieger:
Hai mảng lớn. Mảng đầu tiên là xác minh. Đầu năm nay tôi hoàn toàn bị thuyết phục bởi xác minh, điều này liên quan đến một việc tôi từng làm khi viết code toàn thời gian: Tìm ra vòng lặp phát triển chặt chẽ nhất để xoay quanh ý tưởng của bạn. Thời kỳ Instagram, đôi khi điều này nghĩa là tạo một mục tiêu build mới trong Xcode, chỉ chứa màn hình đó và dữ liệu tổng hợp, chỉ lặp lại vòng này. Tôi từng huấn luyện các kỹ sư mới: “Nếu tôi chỉ dạy một điều, đó là giúp anh tạo ra cái này cho dự án của anh, mọi việc sẽ nhanh hơn nhiều.”
Hiện nay tình hình là: Mỗi khi tôi xây dựng thứ gì đó, tôi làm sao đảm bảo mỗi PR của Claude đều kèm theo ảnh chụp màn hình hoặc video – bất kể đó là PR cho iOS hay thay đổi ở tầng UI. Điều này giúp tôi có được rất nhiều niềm tin. Fable có thể tự đi làm vài giờ, rồi quay lại nói: “Tôi làm xong rồi”, sau đó bạn thấy “đây là thư viện ảnh chụp toàn bộ giao diện người dùng”, điều này cực kỳ hữu ích. Bạn sẽ nói: “Ảnh chụp thứ tám ở đây có trạng thái lỗi – tôi chưa từng thấy bao giờ, nhưng tôi có thể nhìn ra nếu người dùng gặp phải sẽ ra sao. Chúng ta sửa cái này đi.” Việc xác minh toàn diện là điều chúng tôi luôn đẩy mạnh bên trong.
Mảng thứ hai: Cuối cùng bạn vẫn phải chịu trách nhiệm về công việc mình làm. Rất nhiều người dùng Claude mỗi ngày, nhưng vẫn giữ được tính trách nhiệm – “Claude có thể viết code, nhưng bạn cần hiểu những quyết định vĩ mô nào đã được đưa ra.” Tôi thấy khá nhiều kỹ sư bắt đầu thực hành một cách: Claude làm xong việc, nhưng ngay sau đó có một cuộc trò chuyện tiếp theo – “Tôi có thể đảm bảo mình hiểu thấu đáo mọi lựa chọn mà anh đã đưa ra không?” Dù kết quả là bất kỳ artifact nhỏ nào, miễn là giúp nó dễ hiểu hơn, thì đều đáng làm.
Trong họp rất thú vị – có người nói: “PR này tôi đã sẵn sàng”, người khác hỏi: “Anh làm X hay Y?”, rồi có khoảnh khắc lặng im: “Thành thật mà nói, tôi không chắc lắm – tôi sẽ kiểm tra kỹ trước khi merge.” Thích nghi với trạng thái bình thường mới này, hiểu rõ cách cộng tác với nó – đó là điều tất cả chúng ta đều cần học.
Dẫn chương trình Dan Shipper: Cái “vòng lặp xác minh” mà anh vừa đề cập thực sự giàu tiềm năng tưởng tượng. Ngoài chụp ảnh tự động và chia sẻ màn hình, các anh còn đang khám phá những hướng đi “cứng cỏi” hơn nào?
Mike Krieger:
Điểm tiếp cận cốt lõi của chúng tôi là: Liệu bạn có thể khiến nó chạy quy trình thực tế, chứ không chỉ chèn dữ liệu tĩnh? Khi hệ thống ngày càng phức tạp, điều này trở nên ngày càng khó khăn. Ví dụ, chúng ta phải đảm bảo ứng dụng iOS do Fable tạo ra có thể đăng nhập một cú vào môi trường mô phỏng của chúng tôi, sử dụng toàn bộ tài khoản kiểm thử thực tế nhất và luồng dữ liệu chân thực với độ trung thực cao. Nhưng đồng thời, chúng ta lại không muốn nó mỗi lần kiểm thử một điều chỉnh nhỏ ở nút bấm nào đó đều phải khổ sở chạy hết toàn bộ quy trình đăng ký người dùng mới gồm tám bước phiền phức. Vì vậy, chúng tôi đã phát triển riêng cho AI một hệ thống đặc quyền nâng cao và khóa chia sẻ mã hóa đặc biệt, để AI có thể một lần vượt qua các cổng kiểm soát ban đầu, trực tiếp tiếp cận hiện trường nghiệp vụ cốt lõi nhất, khiến trải nghiệm kiểm thử của nó gần như khớp pixel với trải nghiệm người dùng thực tế.
Mảng thứ hai là sự kết hợp giữa đường dẫn đã biết và đường dẫn thay đổi hiện tại – đường dẫn đã biết cực kỳ giá trị cho kiểm thử hồi quy. Chúng tôi đã biểu đạt một số quy trình làm việc lý tưởng bằng văn bản, Claude có thể kiểm tra lại nhiều lần. Còn Claude cũng làm rất tốt trong việc biểu đạt ý định của nó về phần thay đổi hiện tại, nên phần này sẽ được luyện tập sâu. Sự kết hợp của hai yếu tố này rất quan trọng.
Xác minh thị giác cũng rất quan trọng, và video là một công cụ cực kỳ chưa được khai thác hết tiềm năng dành cho Claude. Gần đây tôi đang làm một bản mẫu: Quay video ghi lại những thứ Claude xây dựng được, gửi cho nó kèm FFmpeg, rồi xem nó tự phân tích từng khung hình và nói: “Animation này bị giật, để tôi sửa.” Chụp ảnh màn hình sẽ không bao giờ bắt được điều này, bởi ảnh chụp đã bỏ lỡ khoảnh khắc ấy.
Với những phần khó kiểm thử end-to-end, việc để Claude xây dựng một backend mô phỏng đáng tin cậy, hoặc dùng backend có sẵn, cũng rất thú vị. Trong thời đại Artifact, chúng tôi đã có hệ thống kiểm thử toàn diện từ thời tiền-LLM. Mỗi thành phần hạ tầng đều có một triển khai bộ nhớ tốt, có thể chạy nhanh trong kiểm thử đơn vị. Hiện nay mở rộng điều này sang lĩnh vực Claude: Tôi đang làm một thứ có backend khá vững chắc, nhưng khó khởi động trên máy chủ phát triển của tôi, thế là nó lập tức tạo ra một phiên bản thay thế tuyệt vời. Theo thời gian, phiên bản thay thế này cũng tiến hóa cùng với chính mã nguồn. Trước đây tôi sẽ nói: “Đồng bộ cái này quá tốn công.” Bây giờ tôi chỉ nghĩ: “Claude sẽ đọc thay đổi, điều chỉnh phiên bản thay thế, giữ hai bên đồng bộ. Thế là xong.”
Dẫn chương trình Dan Shipper: Có một số kiến trúc rất thú vị: Khi bạn nhận được một bug, một agent tự động đi sửa, sửa xong gửi tin nhắn cho khách hàng nói “đã sửa xong”. Anh có nhận ra quy trình này có thay đổi trên Fable không?
Mike Krieger:
Một vài khía cạnh. Ở tầng con người và Claude, có một việc tôi liên tục thấy: Nếu có người báo cáo một bug trong kênh phản hồi Slack của chúng tôi, chuỗi hội thoại đó sẽ được truyền vào phiên Claude Code. Nhờ Slack MCP, nó thực sự có thể kéo chuỗi hội thoại đó, rồi gửi lại với danh nghĩa tôi: “Đây là Claude của Mike, tôi đã sửa xong, đây là link PR.” Nhưng sau đó nó sẽ nói: “Đừng vội – chưa lên máy chủ. Tôi sẽ thông báo lại khi đã lên máy chủ.” Vài giờ sau: “Lần triển khai này đã được phát hành. Anh nên thử xem đã sửa chưa?” Việc theo dõi khép kín như thế này là tương đối mới. Tôi đã có vài phiên Claude Code chạy liên tục trong thời gian dài, tương tác với danh nghĩa tôi. Tôi cũng đặt một số tuyên bố miễn trừ trách nhiệm trong đó.
Mảng thứ hai quay lại với cái “gu thẩm mỹ và phán đoán” mà chúng ta vừa nói. Một mặt là “có báo cáo bug nên phải đi sửa”, mặt khác là có phán đoán tốt. Cuối tuần tôi gặp một tình huống: Chúng tôi có một hệ thống nội bộ chạy một thời gian dài mà không khởi động lại, dẫn đến rò rỉ bộ nhớ. Phán đoán tốt là: “Mike, đây là cuối tuần. Anh khởi động lại máy chủ ngay bây giờ là giải quyết được, tôi sẽ mở PR bất đồng bộ để sửa chữa lâu dài.” Nếu bạn muốn Claude can thiệp vào quy trình từ bug đến sửa chữa, bạn thực sự mong muốn nó hiểu bất kỳ SRE hay kỹ sư giỏi nào cũng hiểu: Giải quyết vấn đề trước mắt, còn việc đổi nền tảng hay tái cấu trúc thì để sau. Việc hiểu được sự cân bằng này cực kỳ quan trọng.
Con người nên dùng mô hình này để xây dựng điều gì
Dẫn chương trình Dan Shipper: Điều khiến thế hệ mô hình mới này thực sự khiến người ta hào hứng là: Chúng không chỉ nâng cao đáy – giúp bất kỳ người bình thường nào không có nền tảng cũng có thể một cú click tạo ra ứng dụng riêng, mà quan trọng hơn, chúng đồng thời phá vỡ trần của các chuyên gia. Nếu bạn hiện là một kỹ sư chuyên nghiệp hoặc nhà sáng lập một nhóm khởi nghiệp, bạn hoàn toàn có khả năng đơn thương độc mã giải quyết những dự án “cứng cỏi” mà trước đây bạn thậm chí còn không dám mơ tới. Theo anh, có những lĩnh vực tiên phong nào mà mọi người hiện nay có thể chưa kịp nhận ra, nhưng thực tế hoàn toàn có thể lao vào “mắt nhắm mắt mở” bằng thế hệ mô hình này?
Mike Krieger:
Vài ý tưởng, có thể bắt đầu từ những điều vui vẻ. Con người luôn có rất nhiều ý tưởng sáng tạo về cách biểu đạt độ phức tạp của thế giới riêng mình, mỗi lĩnh vực đều có một thứ mà bạn đặc biệt am hiểu, và luôn tồn tại một phiên bản nào đó là ‘làm sao tôi giải thích điều này cho người khác? Tôi có thể áp dụng kỹ thuật từ nơi khác vào lĩnh vực này không?’ Lấy vợ tôi làm ví dụ, gần đây bà ấy đang lao vào lĩnh vực kỹ thuật môi trường – chuyên về năng lượng địa nhiệt, nơi tràn ngập các mô hình toán học phức tạp và mô phỏng cơ học chất lỏng khiến người ta đau đầu. Nhưng với sự nâng cấp đột phá của thế hệ mô hình suy luận như Fable, bà ấy thực sự thành công trong việc kết hợp hoàn hảo những kỹ thuật “cứng cỏi” hoàn toàn nằm ngoài phạm vi chuyên môn của mình vào công trình nghiên cứu riêng. Hiện nay, bà ấy thậm chí có thể ra lệnh cho Fable giúp bà ấy xây dựng một hệ thống mô phỏng học sâu end-to-end toàn bộ PyTorch – điều này trước đây, với một học giả không chuyên về khoa học máy tính như bà ấy, thực sự là điều không tưởng.
Mảng thứ hai là khả năng kết hợp phần mềm để giải quyết những vấn đề cực kỳ riêng biệt đối với bạn. Bên trong chúng tôi làm rất nhiều việc để biến càng nhiều hệ thống nội bộ thành MCP càng tốt, kết hợp với cấu trúc quyền và thiết lập triển khai đúng đắn. Bên ngoài cũng có các nền tảng PaaS tuyệt vời, bạn chỉ cần hỏi Claude là được, nó sẽ giúp bạn dựng xong. Nhưng tôi đặc biệt thích cảm giác “làm ra thứ bạn luôn muốn có”.
Còn một điều gần đây thực sự làm tôi kinh ngạc. Trong đội ngũ thương mại hóa của chúng tôi có một đồng nghiệp, bà ấy không xuất thân kỹ thuật, nhưng đã tích hợp sâu Claude vào từng mạch máu trong quy trình nghiệp vụ hàng ngày. Điều kinh khủng nhất là, bà ấy không dừng lại ở phiên bản V1 – bà ấy đã cầm công cụ này, cùng mô hình lớn làm việc trong nền, liên tục lặp lại cường độ cao trong vài tháng.
Điều này chính xác tiết lộ điểm bị đánh giá thấp nhất – và cũng hấp dẫn nhất – của thế hệ mô hình suy luận này: Ở “mức sống tối thiểu” của các thế hệ mô hình trước, dự án thường tồn tại một “trần độ phức tạp”. Một khi mã nghiệp vụ hoặc logic của bạn tích tụ đến một khối lượng nhất định, mô hình lớn sẽ bắt đầu “chỉ lo đầu mà quên đuôi”, bạn muốn thêm chức năng mới, nó sẽ báo lỗi điên cuồng, thậm chí phá hỏng kiến trúc hiện có của bạn.
Nhưng hiện nay, người đồng nghiệp nữ không biết lập trình của chúng tôi, dưới sự hỗ trợ của mô hình ở cấp độ Fable, đã nuôi dưỡng hệ thống của cô ấy trong nền suốt vài tháng liền. Bạn có thể rõ ràng nhìn thấy phần mềm ấy như một sinh vật sống, không ngừng phát triển, phát triển và tiến hóa điên cuồng dưới sự “tưới tắm” của AI. Hiện nay, cô ấy đã bắt đầu triển khai toàn bộ hệ thống tự xây dựng cực kỳ lớn và phức tạp này cho toàn bộ đội ngũ thương mại hóa của công ty chúng tôi.
Một người bình thường hoàn toàn không có nền tảng lập trình, giờ đây có thể chỉ bằng một mình, đẩy trần độ phức tạp của phần mềm chu kỳ dài lên mức độ kinh hoàng như thế – điều này trong lịch sử công nghệ nhân loại, là một kỳ tích chưa từng có.
Luồng công việc động
Dẫn chương trình Dan Shipper: Điều anh vừa nói về “luồng công việc động” cũng rất mạnh mẽ, hãy nói thêm cho tôi nghe nhé?
Mike Krieger:
Bên trong chúng tôi thường tự phát triển một số công cụ tiên phong như thế này, rồi tôi sẽ “đòi update” điên cuồng các kỹ sư viết công cụ trong văn phòng: “Cái này rốt cuộc bao giờ mới được công bố?” Đôi khi thực sự do một số giới hạn cơ sở hạ tầng cứng cỏi khiến nó chỉ có thể chạy nội bộ trước, nhưng chúng tôi đang nỗ lực hết sức để sớm đưa những “báu vật” này ra thị trường. Đối với tôi, luồng công việc động thực sự là một sản phẩm có thể làm kinh ngạc toàn cầu.
Fable và những mô hình tương tự đặc biệt mạnh mẽ vì hai lý do lớn. Thứ nhất, nó giúp bạn tạo khung xương (scaffolding) cho những công việc sâu sắc và có ý nghĩa. Việc điên rồ nhất tôi từng làm với nó là trực tiếp ném cho Fable một dự án Python nội bộ khá phức tạp, và yêu cầu nó giúp tôi chuyển toàn bộ logic nghiệp vụ cốt lõi sang phiên bản TypeScript – lúc ấy chúng tôi có một cân nhắc triển khai trực tuyến rất cụ thể.
Ngày xưa ở Instagram, cấp cao từng thảo luận nghiêm túc: “Chúng ta có nên viết lại toàn bộ mã nền tảng IG bằng ngôn ngữ Hack để tích hợp liền mạch vào hạ tầng cơ sở của Facebook không?” Kết luận của chúng tôi lúc ấy là: Chết tiệt, tuyệt đối không làm, điều này hoàn toàn không khả thi trong thực tế.
Nhưng vào cuối tuần trước, tôi đối mặt với một kho mã cốt lõi cũng rối rắm không kém, tôi trực tiếp ném cho nó một luồng công việc động, rồi tôi ung dung đi nghỉ cuối tuần. Tôi đặt luồng công việc cho nó là: Hiểu sâu mã hiện tại, tạo một tài liệu giống spec giải thích mọi thứ vận hành thế nào, sau đó dịch từng module, kiểm thử tăng dần, kiểm tra đối kháng, rà soát các mục bị thiếu. Đến thứ Hai khi tôi quay lại tập trung và mở máy tính, một điều kỳ diệu đã xảy ra – nó đã trở thành một hệ thống mới tinh chạy trên chuỗi công cụ phát triển TypeScript và Bun, và ở một số tầng kiến trúc, nó thậm chí còn viết đẹp hơn, nhanh hơn phiên bản Python gốc của tôi.
Lý do dài hạn hấp dẫn hơn nữa là: Khi luồng công việc động trở nên phổ biến, trong tương lai không xa, chúng ta có thể phân phối các tác vụ con có độ khó khác nhau một cách liền mạch cho đội mô hình tương ứng với độ phức tạp của chúng.
Dẫn chương trình Dan Shipper: Với người chưa từng dùng, hãy kể tôi nghe anh làm ra luồng công việc đó như thế nào. Anh thiết kế nó ra sao? Làm sao đảm bảo nó tốt?
Mike Krieger:
Toàn bộ quá trình điều chỉnh thực sự đầy thú vị mang tính “geek” lặp lại. Tôi bắt đầu bằng việc mở Claude Code, nói với nó: “Anh bạn, tôi hiện có một công việc tái cấu trúc cực kỳ nan giải – nào, chúng ta cùng thiết kế một giải pháp luồng công việc tự động hoàn toàn.”
Nó đưa ra kế hoạch, tôi nói: “Gần đúng rồi, nhưng tôi cần thêm ba đến bốn lớp xác minh để kiểm tra các chức năng bị thiếu.” Sau đó nó trả lời: “Đây là phương án của anh. Sẵn sàng chưa?” Luồng công việc được biểu đạt bằng code, và tôi cho rằng điều này rất có giá trị, bởi bạn có thể thấy rõ nó định làm gì.
Sau khi nó hoàn thành việc di chuyển toàn bộ, tôi có một vài điều chỉnh nhỏ, tôi coi chúng như các luồng công việc mini, tiếp tục từ đầu ra của luồng công việc trước. Điều này quay lại vấn đề: Chat có phải là giao diện đúng không. Luồng công việc là một vùng trung gian tốt: Bạn dùng chat để dàn dựng nó, nhưng nó được biểu đạt bằng code, sau đó được thực thi trong một giao diện người dùng sạch sẽ, từng bước đều hiển thị rõ điều gì đang xảy ra. Tôi nghĩ rằng trong tương lai, chúng ta sẽ dùng cách tương tự để kết nối các công việc tầm nhìn dài hạn với chat.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
深潮TechFlow
