Hãy cùng整理 lại câu chuyện ra đời của Claude Code, chủ yếu dựa trên bài phỏng vấn của blogger công nghệ Gergely Orosz với các thành viên cốt lõi của Claude Code. Claude Code thực sự ấn tượng, với doanh thu hàng năm 500 triệu đô la, số lượng người dùng đã tăng gấp 10 lần chỉ trong ba tháng, và hiện tại cũng là công cụ Coding Agent được nhiều lập trình viên ưa chuộng. Công cụ này ban đầu chỉ là một món đồ chơi dòng lệnh có thể cho bạn biết "bây giờ đang nghe bài hát gì". 🧵

Gergely Orosz đã phỏng vấn ba thành viên cốt lõi của Claude Code: • Kỹ sư sáng lập Boris Cherny (17 năm kinh nghiệm, cựu kỹ sư trưởng của Meta) • Kỹ sư số hai Sid Bidasaria (tác giả của tính năng Subagents) • Và quản lý sản phẩm Cat Wu. Họ đã nói về cách Claude Code từ nguyên mẫu trở thành sản phẩm, những lựa chọn kỹ thuật mà họ đã thực hiện, và cách mà đội ngũ nhỏ chỉ mười mấy người này có thể phát hành 5 PR mỗi ngày cho mỗi người. Đây có thể là mẫu gần nhất với "đội ngũ kỹ sư ưu tiên AI" hiện tại. Họ sử dụng AI để viết mã, viết thử nghiệm, thực hiện kiểm tra mã, khắc phục sự cố, thậm chí sử dụng Claude Code để phát triển chính Claude Code. 90% mã là do nó tự viết. Điều tôi muốn làm là tổng hợp những phần thú vị nhất trong cuộc phỏng vấn này, nói về cách mà đội ngũ này làm việc, có gì có thể học hỏi, và có gì là điều kiện đặc biệt của họ quyết định, không thể sao chép. Dưới đây được chia thành 7 câu chuyện nhỏ, mỗi câu chuyện đều có thể xem độc lập, nhưng khi kết hợp lại sẽ tạo thành một bức tranh hoàn chỉnh.

【1】Một công cụ nghe nhạc nhỏ, làm thế nào để trở thành một sản phẩm có doanh thu 500 triệu đô la mỗi năm Vào tháng 9 năm 2024, Boris Cherny vừa gia nhập Anthropic, rảnh rỗi đã viết một món đồ chơi dòng lệnh nhỏ. Cái này có thể làm gì? Nó có thể sử dụng AppleScript để cho bạn biết hiện tại đang nghe bài hát gì, và còn có thể đổi bài hát theo chỉ dẫn của bạn. Đơn giản vậy thôi. Đánh giá của chính Boris là: "Một bản demo khá hay, nhưng không có gì đặc biệt."

Bước ngoặt thực sự xảy ra sau khi anh ấy nói chuyện với đồng nghiệp Cat Wu. Lúc đó, Cat đang nghiên cứu khả năng sử dụng máy tính của AI Agent, trong lúc trò chuyện, Boris nảy ra một ý tưởng: nếu cho công cụ dòng lệnh này nhiều quyền hơn thì sao? Chẳng hạn như cho phép nó đọc và ghi tệp, có thể thực thi lệnh?

Anh ấy đã thử. Sau đó, khoảnh khắc chứng kiến điều kỳ diệu đã đến. Boris đã ném công cụ nâng cấp này vào kho mã của Anthropic và hỏi vài câu hỏi ngẫu nhiên. Claude bắt đầu tự khám phá hệ thống tệp - đọc một tệp, thấy câu lệnh import bên trong, rồi tiếp tục đọc các tệp được tham chiếu, lần lượt đi sâu xuống cho đến khi tìm thấy câu trả lời. "Điều này đã làm tôi sốc," Boris nhớ lại, "Tôi chưa bao giờ sử dụng một công cụ như vậy."

Trong lĩnh vực AI có một khái niệm gọi là "product overhang", dịch ra là "sản phẩm thừa". Ý nghĩa là mô hình thực sự đã có khả năng nào đó, nhưng hình thức sản phẩm hiện tại không giải phóng được khả năng này. Boris phát hiện ra, chính là một "product overhang" khổng lồ, Claude đã có thể làm những điều này từ lâu, chỉ là không ai tạo cho nó một cái vỏ.

Boris bắt đầu sử dụng công cụ này hàng ngày và sau đó chia sẻ với một vài đồng nghiệp. Hai tháng sau, vào tháng 11, họ đã phát hành một phiên bản nội bộ. Dữ liệu rất ấn tượng: Ngày đầu tiên, 20% kỹ sư đã sử dụng; Ngày thứ năm, 50%.

Lúc này xuất hiện một cuộc tranh luận thú vị: có nên công bố ra ngoài không? Lý do phản đối rất thực tế: nếu thứ này thực sự mạnh mẽ như chúng ta nghĩ, thì giữ lại làm "vũ khí bí mật" chẳng phải tốt hơn sao? Tại sao phải để lợi thế cạnh tranh rơi vào tay người khác? Cuối cùng, Anthropic đã chọn công bố. Logic là như thế này: sứ mệnh cốt lõi của Anthropic là nghiên cứu an toàn mô hình, và cách tốt nhất để nghiên cứu an toàn là để mọi người thực sự sử dụng những công cụ này. Vì đã xác minh nội bộ rằng Claude Code sẽ được sử dụng rộng rãi, nên việc công bố nó sẽ mang lại nhiều hiểu biết hơn về khả năng và an toàn của mô hình.

Vào tháng 5 năm 2025, Claude Code chính thức được công bố. Ba tháng sau, lượng sử dụng tăng gấp 10 lần, doanh thu hàng năm vượt quá 500 triệu đô la. Thú vị là, Boris ban đầu chỉ nghĩ đến việc dành cho lập trình viên sử dụng - nên mới gọi là "Claude Code". Nhưng một ngày nọ, khi đi qua chỗ ngồi của các nhà khoa học dữ liệu, ông phát hiện ra rằng màn hình của họ cũng đang chạy Claude Code. "Bạn dùng cái này để làm gì?" "Tôi để nó giúp tôi viết truy vấn, làm trực quan hóa mà." Bây giờ, các nhà khoa học dữ liệu của Anthropic ai cũng có một cái, có người còn mở nhiều cái cùng lúc. Một công cụ nghe nhạc nhỏ, vì được cấp thêm một vài quyền, đã trở thành một sản phẩm trị giá hàng trăm triệu đô la. Đây có lẽ là minh chứng tốt nhất cho "product overhang", khả năng của mô hình luôn ở đó, chỉ chờ ai đó giải phóng nó.

【2】90% mã là do chính mình viết - Triết lý lựa chọn công nghệ của Claude Code Claude Code có 90% mã là do nó tự viết. Nghe có vẻ như một chiêu trò, nhưng thực ra điều này nhờ vào logic quyết định công nghệ của họ. Trước tiên, hãy xem công nghệ: TypeScript viết phần chính, React kết hợp với framework Ink để làm UI terminal, Yoga mã nguồn mở của Meta làm hệ thống bố cục, Bun chịu trách nhiệm xây dựng và đóng gói. Tại sao lại chọn những công nghệ này? Bởi vì chúng "trong phân phối". "Trong phân phối" (on distribution) là một thuật ngữ trong lĩnh vực AI. Nghĩa là mô hình đã thấy rất nhiều mã loại này và giỏi trong việc xử lý chúng. TypeScript và React chính là thế mạnh của Claude. Nếu chọn một framework ít phổ biến, mô hình sẽ phải "học", hiệu quả sẽ bị giảm sút. Sự lựa chọn này tạo ra một vòng lặp tuyệt vời: sử dụng công nghệ mà Claude giỏi để viết Claude Code, sau đó dùng Claude Code để viết thêm nhiều Claude Code. 90% tự viết cho chính mình, là như vậy. Lựa chọn của họ ở cấp độ kiến trúc cũng đơn giản không kém. Claude Code chạy trên máy tính cục bộ. Không có container Docker, không có sandbox trên đám mây, chỉ đơn giản là đọc và ghi tệp trên máy tính của bạn, thực hiện lệnh.

Về lý do tại sao thiết kế như vậy? Câu trả lời của Boris là: "Mỗi khi đưa ra quyết định thiết kế, chúng tôi gần như luôn chọn phương án đơn giản nhất. Chạy cục bộ chính là câu trả lời đơn giản nhất." Sự đơn giản này kéo dài đến toàn bộ triết lý sản phẩm: viết ít logic kinh doanh nhất có thể, để mô hình trở thành nhân vật chính. "Điều này có thể nghe có vẻ kỳ lạ," Boris nói, "nhưng chúng tôi muốn người dùng có thể cảm nhận mô hình một cách "nguyên bản" nhất có thể. Nhiều sản phẩm AI sẽ thêm vào một đống khung xương - các yếu tố UI bổ sung, các chức năng hỗ trợ khác nhau - kết quả là lại hạn chế khả năng của mô hình. Điều chúng tôi muốn làm là làm cho UI càng đơn giản càng tốt." Để giữ cho sự đơn giản, mỗi khi Claude phát hành mô hình mới, họ sẽ tinh giản mã nguồn một cách đáng kể. Chẳng hạn, khi phát hành Claude 4.0, họ đã xóa khoảng một nửa các từ gợi ý hệ thống, vì mô hình mới không còn cần những "cái nạng" đó nữa. Số lượng công cụ cũng đang được tinh giản liên tục - cái nào có thể xóa thì xóa, cái nào có thể hợp nhất thì hợp nhất. Toàn bộ kiến trúc Claude Code có thể được tóm tắt thành ba điều: định nghĩa UI và mở ra giao diện cho mô hình chỉnh sửa, mở ra công cụ để mô hình gọi, rồi lùi sang một bên. Tất nhiên, sự đơn giản không có nghĩa là không có phần phức tạp. Hệ thống quyền là một ngoại lệ. Dù sao thì việc để AI thực hiện lệnh trên máy tính của bạn cũng có rủi ro. Giải pháp của Claude Code là hỏi bạn trước khi thực hiện: Bạn có muốn phê duyệt thao tác này không? Bạn có thể chỉ phê duyệt cho lần này, hoặc phê duyệt cho những lần sau, hoặc từ chối. Hệ thống quyền hỗ trợ cấu hình nhiều lớp - theo dự án, theo người dùng, theo công ty. Nhóm có thể chia sẻ tệp cấu hình, đưa các lệnh an toàn thường dùng vào danh sách trắng. Nguyên tắc đằng sau thiết kế quyền này là: Nếu bạn khởi động Claude Code, nó không nên thay đổi bất cứ điều gì mà không có sự đồng ý của bạn. Nhưng đồng thời, cũng phải cho người dùng lựa chọn "trao quyền" - trong những tình huống mà bạn tin tưởng, có thể bỏ qua bước xác nhận. Đơn giản, nhưng không thô thiển. Kiềm chế, nhưng không thiếu chức năng.

【3】Hai ngày 20 mẫu nguyên mẫu - Sự phát triển sản phẩm trong thời đại AI trông như thế nào Trước đây, khi làm nguyên mẫu sản phẩm, hai ngày có thể làm ra hai cái đã được coi là hiệu suất cao. Boris đã mất hai ngày để làm ra 20 cái. Đây không phải là phóng đại, mà là ghi chép thực tế khi anh phát triển tính năng danh sách việc cần làm của Claude Code. Anh thậm chí đã chia sẻ từng bước với các từ gợi ý và ảnh chụp màn hình. Hãy cùng xem 20 mẫu nguyên mẫu này đã được phát triển như thế nào. Phiên bản đầu tiên, anh muốn danh sách việc cần làm hiển thị dưới công cụ được gọi gần đây nhất. Từ gợi ý rất ngắn: "Để danh sách việc cần làm không xuất hiện cùng với đầu vào, mà hiển thị một danh sách việc cần làm cố định ở trên ô nhập, tiêu đề hiển thị bằng màu xám '/todo (1 trong 3)'". Nhìn vào hiệu ứng, không hài lòng lắm. Phiên bản thứ hai, thay đổi thành hiển thị nội tuyến khi mỗi việc cần làm được cập nhật. Từ gợi ý: "Thực ra không cần hiển thị danh sách việc cần làm, thay vào đó khi mô hình bắt đầu xử lý một việc cần làm, hãy làm cho tên công cụ được hiển thị dưới dạng tiêu đề in đậm. Giữ lại hiển thị tiến độ như 'bước 2 trong 4'". Vẫn không đúng. Phiên bản thứ ba và thứ tư, anh thử làm một "viên thuốc tương tác" - một ô vuông nhỏ ở dưới cùng màn hình, nhấp vào có thể xem tiến độ. "Thêm một viên thuốc việc cần làm dưới ô nhập văn bản, giống như kiểu nhiệm vụ nền, hiển thị 'todos: 1 trong 3'". Sau đó: "Làm cho viên thuốc này có thể tương tác, giống như viên thuốc nhiệm vụ nền". Có chút thú vị, nhưng vẫn chưa đủ tốt. Phiên bản thứ năm và thứ sáu, anh đổi cách tiếp cận: làm một "ngăn kéo" trượt ra từ bên phải. "Hủy bỏ viên thuốc và tiêu đề trước đó, thay vào đó hiển thị danh sách việc cần làm ở bên phải ô nhập, căn giữa theo chiều dọc, ngăn cách bằng đường kẻ màu xám." "Có chút nhảy, có thể làm thành hoạt ảnh ngăn kéo không?" Trông có vẻ khá ngầu, nhưng tính thực tiễn còn nghi vấn. Từ phiên bản thứ bảy đến thứ chín, anh lại di chuyển danh sách việc cần làm lên trên ô nhập, thử nghiệm các cách cắt khác nhau và kiểu tiêu đề. "Nếu vượt quá 5 cái thì hiển thị '... và 4 cái nữa'", "Thêm một tiêu đề màu xám 'Todo:'". Gần đến câu trả lời hơn rồi. Từ phiên bản thứ mười đến hai mươi, anh bắt đầu suy nghĩ cách kết hợp danh sách việc cần làm với hoạt ảnh tải. Giải pháp cuối cùng là đặt thông tin tiến độ bên cạnh spinner (chỉ báo tải), tối đa hóa khả năng hiển thị. Sau khi phát hành, người dùng phản hồi rằng họ muốn xem danh sách việc cần làm đầy đủ. Vì vậy, lại thêm một lần phát triển: nhấn Ctrl+T để mở rộng tất cả các bước. Đây là phiên bản hiện tại trên mạng.

Trong toàn bộ quá trình, các từ gợi ý của Boris thật sự ngắn gọn - hầu hết chỉ một hoặc hai câu. Nhưng mỗi phiên bản đều là một nguyên mẫu có thể chạy thực tế, không phải là hình tĩnh, không phải là PPT. Anh ấy có thể thực sự kiểm tra và xác minh chức năng này, cảm nhận xem nó có thuận tiện hay không. Quy trình phát triển sản phẩm truyền thống là: ý tưởng → thảo luận → vẽ khung hình → làm thiết kế độ trung thực cao → phát triển → kiểm tra → ra mắt. Mỗi bước đều cần thời gian, mỗi bước đều có thể bị kẹt lại. Giờ đây, quy trình đã trở thành: ý tưởng → từ gợi ý một câu → nguyên mẫu có thể chạy → nếu cảm thấy không đúng thì làm lại một phiên bản khác. Điều này thực sự yêu cầu các nhà phát triển thay đổi cách suy nghĩ để thích ứng với quy trình phát triển này. Trước đây, vai trò của nguyên mẫu là "xác minh ý tưởng" - vì việc làm nguyên mẫu tốn kém, bạn phải suy nghĩ rõ ràng trước khi bắt tay vào làm. Bây giờ, nguyên mẫu trở thành "khám phá khả năng" - vì việc làm nguyên mẫu tốn ít chi phí, bạn có thể làm trước rồi nói sau, nếu không tốt thì vứt đi. Boris nói, khi sử dụng Claude Code, anh ấy thường bỏ qua giai đoạn vẽ thiết kế, trực tiếp làm một phiên bản có thể chạy, trực quan hơn bất cứ điều gì. Nhịp độ hàng ngày của đội ngũ Claude Code là: mỗi kỹ sư đẩy khoảng 5 PR mỗi ngày, nội bộ phát hành 60-100 phiên bản mỗi ngày, bên ngoài phát hành 1 phiên bản mỗi ngày. 5 PR mỗi ngày, điều này thật khó tưởng tượng ở hầu hết các công ty. Uber trong giai đoạn tái cấu trúc căng thẳng nhất, một ngày có thể đẩy một PR trung bình cũng đã là tốt rồi. Công cụ đã thay đổi, nhịp độ cũng thay đổi, cách suy nghĩ cũng phải thay đổi theo.

【4】Thiết kế lại giao diện dòng lệnh sau khi tích hợp AI Giao diện dòng lệnh đã tồn tại hàng chục năm, tại sao bây giờ cần phải thiết kế lại? Bởi vì trước khi LLM xuất hiện, giao diện không quá chú trọng đến trải nghiệm tương tác. Giao diện dòng lệnh truyền thống là hỏi và đáp: bạn nhập lệnh, nó trả về kết quả, xong. Không có đối thoại, không có ngữ cảnh, không có phản hồi trong lúc chờ đợi. Bạn nhìn vào con trỏ nhấp nháy, không biết phía sau đang làm gì. Claude Code là một trong những sản phẩm đầu tiên thực sự cần suy nghĩ về "UX của giao diện dòng lệnh". Họ đã thêm một vài chi tiết nhỏ, trông có vẻ không đáng kể, nhưng cảm giác sử dụng hoàn toàn khác biệt. Đầu tiên: gợi ý tải ngữ cảnh. Khi mô hình đang suy nghĩ, màn hình có thể hiển thị các gợi ý liên quan đến nhiệm vụ hiện tại: chẳng hạn như "Đang đọc cấu trúc mã của bạn" hoặc "Đang suy nghĩ về giải pháp". Đây là một cảm giác rất nhỏ, nhưng nó khiến công cụ có "nhân cách". Bạn sẽ cảm thấy nó đang làm việc chăm chỉ, chứ không phải bị kẹt lại. Boris nói, lần cuối cùng anh thấy một tương tác nhỏ thú vị như vậy là trong quy trình hướng dẫn người mới của Slack. Thứ hai: gợi ý hướng dẫn trong lúc chờ đợi. Khi Claude đang thực hiện một nhiệm vụ dài, phần dưới màn hình sẽ lần lượt hiển thị các mẹo sử dụng, chẳng hạn như "Bạn có thể nhấn Esc để ngắt nhiệm vụ hiện tại" hoặc "Thử /help để xem tất cả các lệnh". Giao diện dòng lệnh dùng để dạy giao diện dòng lệnh, đơn giản và thông minh. Câu chuyện thứ ba còn thú vị hơn: Trình biên dịch Markdown. Vào ngày trước khi phát hành, một kỹ sư đã phàn nàn rằng danh sách lồng ghép hiển thị rất xấu, khoảng cách giữa các đoạn cũng không đúng. Vấn đề nằm ở trình biên dịch Markdown. Boris đã thử tất cả các trình biên dịch có sẵn trên thị trường, không cái nào đẹp trong giao diện dòng lệnh. Vì vậy, anh đã dùng Claude Code và dành một ngày để viết lại một trình phân tích cú pháp và trình biên dịch Markdown từ đầu. Đúng, vào ngày trước khi phát hành. Đúng, viết từ đầu. Đúng, sử dụng chính Claude Code. Kết quả là trình biên dịch "gấp rút" này đẹp hơn tất cả các giải pháp có sẵn. Họ đã phát hành ngay lập tức. Boris tin rằng hiện tại không có giao diện dòng lệnh nào khác có trình biên dịch Markdown chất lượng tương tự. Câu chuyện này cho thấy một điều: khi bạn có một công cụ lập trình AI đủ tốt, chi phí "tự chế" sẽ giảm đáng kể. Trước đây, sự thỏa hiệp "chỉ cần có thể sử dụng" giờ có thể biến thành "vậy thì hãy làm một cái tốt hơn". Giao diện dòng lệnh cổ điển này đang được hồi sinh nhờ sự tham gia của LLM. Giao diện vẫn là giao diện, chỉ là nhờ có sự tham gia của AI, chúng ta cần suy nghĩ nghiêm túc: làm thế nào để con người và AI trong giao diện có thể đối thoại tốt hơn.

【5】AI thâm nhập vào mọi khía cạnh - một thử nghiệm "toàn diện AI hóa" của một đội ngũ kỹ sư Đội ngũ kỹ sư của Anthropic có thể là một trong những đội ngũ sử dụng công cụ AI một cách triệt để nhất hiện nay. Không chỉ thể hiện ở việc viết mã, mà còn ở từng giai đoạn của dự án. Xem xét mã: Tất cả các PR đều được Claude Code thực hiện lần xem xét đầu tiên, kỹ sư sẽ thực hiện lần xem xét thứ hai. Boris nói, Claude Code có thể phát hiện nhiều vấn đề ngay từ lần xem xét đầu tiên. Chức năng này ban đầu chỉ được sử dụng nội bộ, sau đó họ đã công khai, mọi người đều có thể sử dụng Claude Code để thực hiện kiểm tra an toàn. Viết kiểm thử: Bộ kiểm thử của Claude Code hầu như hoàn toàn do Claude Code viết. Boris nói: "Trước đây, nếu có ai đó gửi PR mà không viết kiểm thử, tôi sẽ do dự không biết có nên nói gì không - cảm giác như đang chê bai. Nhưng bây giờ có Claude, việc viết kiểm thử chỉ là một câu nhắc nhở, không có lý do nào để không viết." Phản ứng sự cố: Kỹ sư oncall sẽ nhờ Claude Code giúp phân tích Nguyên Nhân Gốc (nguyên nhân cơ bản gây ra vấn đề). Nó có thể kéo các cuộc thảo luận liên quan từ Slack, kéo nhật ký lỗi từ Sentry, kéo dữ liệu từ các hệ thống giám sát khác nhau, và sau đó phân tích tổng hợp. Boris nói Claude Code có thể tìm Nguyên Nhân Gốc nhanh hơn cả con người trong một số tình huống. Phân luồng vấn đề GitHub: Mỗi khi có vấn đề mới được gửi đến, Claude Code sẽ thực hiện một phân tích trước, sau đó kỹ sư hỏi nó "có thể thực hiện được không". Boris nói, khoảng 20%-40% trường hợp, nó có thể hoàn thành ngay từ lần đầu tiên. Biểu đồ và truy vấn: Dữ liệu sản phẩm được lưu trữ trong BigQuery, hầu như tất cả các truy vấn và hình ảnh hóa đều được tạo ra bằng Claude Code. Kỹ sư thậm chí sẽ yêu cầu nó xuất ra biểu đồ ASCII trực tiếp.

Điều khiến tôi ngạc nhiên nhất là sự phục hưng của TDD (Phát triển dựa trên kiểm thử). TDD là một khái niệm cũ: trước tiên viết kiểm thử, sau đó viết mã để làm cho kiểm thử đó thành công. Về lý thuyết thì rất đẹp — buộc bạn phải nghĩ rõ ràng về những gì bạn muốn. Nhưng trong thực tế, hầu hết mọi người cảm thấy nó quá chậm và rắc rối, vì vậy phương pháp này đã dần bị gạt sang bên lề trong suốt hơn một thập kỷ qua. Nhưng Boris nói, sau khi sử dụng Claude Code, anh ấy đã thực hiện rất nhiều TDD: "Tôi sẽ để mô hình viết một kiểm thử trước, đồng thời nói với nó rằng kiểm thử này sẽ thất bại, đừng cố gắng làm cho nó thành công. Sau đó, tôi sẽ để nó viết mã để thực hiện chức năng và làm cho kiểm thử thành công, nhưng không được thay đổi chính kiểm thử đó." "Khi mô hình có một mục tiêu rõ ràng để lặp lại — chẳng hạn như một kiểm thử đơn vị hoặc một mock — nó hoạt động rất tốt." Anh ấy đặc biệt nhấn mạnh rằng Claude 4.0 là dòng mô hình đầu tiên có thể để mô hình viết phần lớn các kiểm thử. Các phiên bản trước có thể viết một phần, nhưng cần rất nhiều can thiệp từ con người. Còn một khái niệm mới: multi-clauding. Có nghĩa là chạy nhiều phiên bản Claude Code cùng một lúc, để chúng xử lý các nhiệm vụ khác nhau song song. Sid nói anh ấy thường làm như vậy — khởi động vài agent trong cuộc họp, sau đó quay lại xem kết quả. Anthropic phát hiện rằng, 25% người dùng đăng ký Max (người dùng cao cấp với phí hàng tháng từ 100-200 đô la) đang sử dụng multi-clauding hàng ngày. Đây là một sự thay đổi rất thú vị. Lập trình luôn là một hoạt động "đơn luồng": bạn chỉ có thể làm một việc tại một thời điểm, chỉ chuyển đổi nhiệm vụ khi chờ xem xét mã hoặc triển khai. Nhưng bây giờ, "lập trình song song" trở nên khả thi — bạn có thể tiến hành nhiều việc cùng một lúc. Tất nhiên, có rất nhiều điều chưa biết: làm việc song song có thực sự hiệu quả hơn, hay chỉ là cảm giác hiệu quả hơn? Loại nhiệm vụ nào phù hợp với việc song song? Sự chú ý của mỗi agent bị phân tán sẽ có vấn đề gì không? Những câu hỏi này vẫn chưa có câu trả lời. Nhưng chúng ta đã có một công cụ mới để thử nghiệm. Cuối cùng, tôi sẽ kể một trường hợp. Có một công ty cần thực hiện chuyển đổi khung, ban đầu ước tính cần hai năm kỹ sư — một kỹ sư làm trong hai năm, hoặc mười kỹ sư làm trong hai tháng rưỡi. Họ đã sử dụng Claude Code, và một kỹ sư đã hoàn thành trong hai tuần. Boris nói rằng trước đây anh ấy sẽ hoài nghi về những tuyên bố như vậy, nhưng họ đã nghe quá nhiều câu chuyện tương tự.

【6】Hackathon ba ngày - Chức năng Subagents được hình thành như thế nào Chức năng Subagents được lấy cảm hứng từ một bài viết trên Reddit. Có người nói rằng anh ta đã mở năm phiên bản Claude Code cùng lúc, đặt ra các vai trò khác nhau cho mỗi phiên bản, sau đó sử dụng hệ thống tệp để chúng giao tiếp với nhau. Khi Sid Bidasaria thấy bài viết này, phản ứng đầu tiên của anh là: cách chơi này thật tuyệt, nhưng người dùng không nên phải vất vả như vậy. Chúng ta nên biến nó thành một chức năng tích hợp trong sản phẩm. Công ty vừa có một hackathon nội bộ kéo dài ba ngày, Sid quyết định sử dụng ba ngày này để thực hiện điều đó. Ngày đầu tiên, đội ngũ hào hứng vẽ ra nhiều cấu trúc Agent phức tạp: các Agent giao tiếp với nhau qua bus tin nhắn, chế độ bất đồng bộ, tương tác nhiều-một… Bức tranh rất đẹp, khái niệm rất tiên tiến. Ngày thứ hai, họ nhận ra rằng cách làm này có vẻ không khả thi. Vấn đề không phải là việc thực hiện kỹ thuật - những mô hình phức tạp đó đều có thể thực hiện được. Vấn đề là người dùng không thể hiểu. Giao diện người dùng của Claude Code chỉ là một terminal đơn giản, làm thế nào để bạn giúp người dùng hiểu những mô hình giao tiếp Agent phức tạp trong một giao diện đơn giản như vậy? Họ quyết định bắt đầu lại từ đầu, quay về một vấn đề cơ bản: hình thức đơn giản nhất mà các nhà phát triển bình thường có thể sử dụng là gì? Họ tự đặt ra hai ràng buộc: Thứ nhất, không phát minh ra bất cứ điều gì mới. Chỉ sử dụng khả năng đã có của Claude Code - lệnh “/” và tệp .md. Thứ hai, không thực hiện giao tiếp giữa các Agent. Thay vào đó, chuyển sang một chế độ sắp xếp đơn giản: có một Agent chính, nó có thể gọi các Agent con, các Agent con hoàn thành nhiệm vụ và trả lại kết quả, chỉ đơn giản như vậy. Họ cũng đã trò chuyện với nhóm nghiên cứu của Anthropic. Các nhà nghiên cứu đang nghiên cứu mô hình đa Agent, nhưng kết luận là: liệu cấu trúc Agent phức tạp có thực sự hiệu quả hay không, hiện vẫn chưa có kết luận. Điều này đã mang lại cho họ thêm sự tự tin: nếu ngay cả nhóm nghiên cứu cũng nói rằng phức tạp chưa chắc đã tốt, thì càng nên làm phiên bản đơn giản. Khi kết thúc ngày thứ ba, họ đã tạo ra một phiên bản có thể sử dụng. Người dùng có thể định nghĩa vai trò và khả năng của các Agent con trong tệp .md (ví dụ: “Agent con phía trước: sử dụng React 19 và Next.js”), Claude Code sẽ gọi chúng vào thời điểm thích hợp, hoặc người dùng có thể kích hoạt thủ công. Sau khi hackathon kết thúc, họ đã tinh chỉnh một chút và chức năng đã được ra mắt. Bây giờ bạn có thể định nghĩa nhiều Agent con chuyên dụng: Agent phía sau có chuyên môn về kiểm toán bảo mật, Agent phía trước quen thuộc với các framework cụ thể, Agent QA chuyên viết kiểm thử… Chúng có thể làm việc song song trong nền, mỗi người đảm nhận một nhiệm vụ. Nhiều đội trong hackathon sẽ không muốn từ bỏ kế hoạch phức tạp của mình, dù sao họ cũng đã dành cả ngày để vẽ và thảo luận, có tình cảm với nó. Có thể thừa nhận rằng "con đường này không khả thi" và bắt đầu lại từ đầu cần có dũng khí, cũng như niềm tin vào "sự đơn giản". Sự đơn giản không phải là lười biếng. Sự đơn giản là tìm ra hình thức mà người dùng thực sự có thể sử dụng trong vô số khả năng.

【7】Đội ngũ kỹ sư trong tương lai sẽ như thế nào? Một số điều có thể tham khảo, và một số điều không thể sao chép. Boris nói: "Lập trình bây giờ thật thú vị. Lần cuối cùng tôi có cảm giác như vậy là khi còn học trung học, lần đầu tiên viết mã trên máy tính đồ họa. Cảm giác kỳ diệu đó, tôi đã không trải nghiệm trong một thời gian dài, nhưng giờ nó đã trở lại." Cảm nhận của Sid cũng tương tự: "Có hai điều khiến tôi phấn khích. Một là tốc độ phát hành của chúng tôi - đôi khi thậm chí cảm thấy quá nhanh. Hai là không gian thử nghiệm rất nhiều - công việc trước đây mặc dù cũng nhanh, nhưng những gì làm thì khá theo khuôn mẫu, biết câu trả lời là gì, chỉ cần thực hiện thôi. Bây giờ thì khác, mô hình thay đổi mỗi ba tháng, chúng tôi phải liên tục suy nghĩ lại cách làm việc." Những cảm nhận này rất chân thực và có sức lan tỏa. Nhưng trước khi thảo luận về "đội ngũ kỹ sư trong tương lai sẽ như thế nào", cũng đừng quên sự đặc thù của Anthropic. Thứ nhất, Anthropic là một phòng thí nghiệm nghiên cứu, không phải công ty sản phẩm. Sứ mệnh cốt lõi của nó là nghiên cứu an toàn và khả năng AI, sản phẩm chỉ là phương tiện chứ không phải mục đích. Điều này có nghĩa là họ có mức độ chấp nhận "thí nghiệm nhanh" cao hơn nhiều so với các công ty thông thường. Thứ hai, sản phẩm chính của họ là mô hình Claude. Claude Code chỉ là một "vỏ bọc" của mô hình. Vì vậy, "xóa mã để mô hình làm nhiều việc hơn" là lựa chọn tự nhiên đối với họ, nhưng đối với các công ty khác có thể có nghĩa là giao logic kinh doanh cốt lõi cho một hộp đen. Thứ ba, tất cả nhân viên đều có quyền truy cập không giới hạn vào Claude, bao gồm cả mô hình Opus đắt nhất. Ở hầu hết các công ty, phí đăng ký AI là một khoản ngân sách cần phải tranh đấu, không thể để ai cũng sử dụng thoải mái. Thứ tư, đội ngũ chỉ có vài người, quy trình cực kỳ đơn giản. Họ hầu như không sử dụng feature flag (công tắc tính năng), vì "quá chậm". Điều này là điều không thể tưởng tượng trong các sản phẩm có số lượng người dùng lớn và chi phí sai sót cao. Vì vậy, sao chép trực tiếp cách làm của đội ngũ Claude Code không nhất thiết là thực tế đối với hầu hết các đội ngũ. Nhưng có một số điều có thể tham khảo. Cách tư duy nguyên mẫu nhanh: ngay cả khi bạn không thể làm 10 nguyên mẫu trong một ngày, liệu có thể từ "một nguyên mẫu hai tuần" chuyển thành "ba nguyên mẫu một tuần" không? Công cụ đã thay đổi, kỳ vọng về "nguyên mẫu nên nhanh như thế nào" cũng cần được cập nhật. Kiểm tra mã hỗ trợ AI: để AI thực hiện lần kiểm tra đầu tiên, con người thực hiện lần kiểm tra thứ hai. Quy trình này không phụ thuộc vào quyền truy cập API không giới hạn, hầu hết các đội ngũ đều có thể thử nghiệm. Sự phục hưng của TDD: nếu việc viết kiểm tra trở nên đủ dễ dàng, thì "không có thời gian để viết kiểm tra" sẽ không còn là cái cớ. Đây có thể là một điểm khởi đầu chi phí thấp để cải thiện chất lượng mã. Giá trị của kỹ sư có tư duy sản phẩm (Product-minded engineer) được khuếch đại: đội ngũ Claude Code không có nhà thiết kế, không có PM, chỉ dựa vào một vài kỹ sư có tư duy sản phẩm. Công cụ AI đã mở rộng đáng kể những gì mà "nhân tài toàn diện" này có thể làm.

Tất nhiên, cũng có những thứ mà công cụ không thể thay thế được. Boris có thể chọn ra cái tốt nhất trong 20 nguyên mẫu, vì anh ấy có khả năng phán đoán - anh ấy biết cái gì "cảm thấy đúng", cái gì chỉ "trông có vẻ hữu ích". Gu thẩm mỹ này là sự tích lũy của 17 năm kinh nghiệm phát triển phần mềm, không phải là điều mà AI có thể mang lại. Đội ngũ đã làm ra một kế hoạch phức tạp trong ngày đầu tiên, và có thể quyết định mạnh mẽ để làm lại từ đầu vào ngày thứ hai, quyết định này cũng là sự phán đoán của con người. Biết khi nào nên xóa mã, khi nào nên giữ lại, trực giác kiến trúc này cũng tương tự như vậy. AI đã làm cho việc thực hiện trở nên nhanh hơn, nhưng nó không làm cho việc "biết phải làm gì" trở nên đơn giản hơn. Ngược lại, vì chi phí thực hiện giảm, quyết định về "làm gì" trở nên quan trọng hơn - bạn có thể nhanh chóng tạo ra 20 phiên bản, nhưng bạn phải biết cái nào là đúng. Kỹ thuật phần mềm sẽ như thế nào trong vài năm tới? Không ai có thể dự đoán chính xác. Nhưng hôm nay của đội ngũ Claude Code có thể là một dạng diễn tập cho nhiều đội ngũ trong tương lai - vòng lặp nhanh hơn, ít "chuyển gạch" hơn, nhiều phán đoán và quyết định hơn. Công cụ đang thay đổi. Điều không thay đổi là, cuối cùng, người vẫn là người quyết định.