Claude không chỉ là trình biên dịch – nó còn mạnh mẽ hơn thế

Đầu năm 2025, tôi đã viết bài "Claude có phải là một trình biên dịch không?". Vào thời điểm đó, câu trả lời của tôi là: Tôi không biết.

Giờ đây, tôi khá chắc chắn câu trả lời là "không, đó là một sai lầm về phân loại, nó còn tốt hơn cả một trình biên dịch". Nhưng điều này cần phải được phân tích kỹ hơn một chút.

Các chương trình máy tính vốn nổi tiếng là phức tạp và khó chiều. Một chương trình vận hành ở mức độ chính xác cực cao. Không có khái niệm lệnh CPU kiểu "làm đại khái cho xong". Trong khi đó, các mục tiêu cấp cao lại thường được mô tả rất mơ hồ.

Trong một thế giới được lý tưởng hóa, phần mềm được xây dựng theo từng lớp, mỗi lớp bổ sung các đặc tả và ẩn đi những chi tiết "không cần thiết". Tầm nhìn trở thành chiến lược, kế hoạch sản phẩm trở thành kế hoạch lập trình, và mã nguồn trở thành tệp nhị phân. Mỗi bước được xử lý bởi một vai trò khác nhau: giám đốc điều hành, phó chủ tịch, quản lý sản phẩm (PM), kiến trúc sư, kỹ sư, trình biên dịch.

Quan trọng là, mỗi bước đều liên quan đến việc đưa ra rất nhiều quyết định. Đó chính là ý nghĩa của việc tăng mức độ đặc tả. (Đây là lý do tại sao một trong hai chỉ số chính của tôi khi tuyển dụng kỹ sư là khả năng phán đoán. Chỉ số còn lại là sự hòa hợp).

Lớp dưới cùng, từ mã nguồn đến tệp nhị phân, là công việc của trình biên dịch. Các trình biên dịch đưa ra rất nhiều quyết định! Từ nội dòng (inlining), phân bổ thanh ghi, cho đến việc có nên đưa ra cảnh báo hay từ chối thẳng thừng một chương trình. Và những quyết định này rất quan trọng: Chúng quyết định hiệu năng, độ ổn định của hệ thống, tính dự đoán được và các kiểu lỗi. Công việc của một kỹ sư trình biên dịch là sắp xếp để trình biên dịch đưa ra các quyết định tốt một cách nhất quán.

Một trình biên dịch tốt và đáng tin cậy giúp kỹ sư phần mềm không phải bận tâm đến những quyết định này. Hầu hết các kỹ sư không biết nhiều về cách trình biên dịch hoạt động; họ không cần phải biết để có thể làm việc hiệu quả.

Năm 2025, chúng ta vận hành trong một thế giới nơi chúng ta sử dụng các LLM để tạo ra những đoạn mã nhỏ. Trong mô hình tư duy này, một tác nhân lập trình (coding agent) có thể đóng vai trò như một lớp mới nằm giữa kỹ sư phần mềm và trình biên dịch truyền thống. Nó "biên dịch" ngôn ngữ tự nhiên thành mã nguồn, đưa ra các quyết định để kỹ sư không cần phải làm điều đó. Giá trị của nó tỷ lệ thuận với độ tin cậy và quy mô các quyết định mà nó có thể thực hiện.

Vấn đề là, cái nhìn lý tưởng hóa này về thế giới là sai lầm. Các lớp trừu tượng luôn bị rò rỉ và các tầng luôn cọ xát vào nhau. Và ngay cả khi chúng không như vậy, chúng ta vẫn sẽ tìm cách chọc thủng chúng.

Làm việc xuyên suốt các lớp là cực kỳ giá trị; sự thấu hiểu về cơ chế (mechanical sympathy) là rất quan trọng.

Một phần lý do tòa nhà Empire State được xây dựng trong chưa đầy một năm và không vượt ngân sách (!!) là nhờ làm việc một cách hệ thống xuyên suốt các lớp. Ví dụ, khi quyết định về lớp vỏ thép mạ crôm-niken bên ngoài:

Không kiến trúc sư, nhà thầu xây dựng hay nhà thầu phụ nào cảm thấy đủ năng lực để giải quyết vấn đề xây dựng kỹ thuật phức tạp này mà không có sự tham vấn đầy đủ. Theo đó, sau khi thảo luận sơ bộ kỹ lưỡng, một cuộc họp toàn diện đã được triệu tập với sự tham gia của đại diện chủ sở hữu, kiến trúc sư và nhà thầu, các nhà thầu phụ cán vật liệu, công nhân kim loại chịu trách nhiệm chế tạo và lắp đặt, cùng các thanh tra viên kiểm tra tất cả các tấm thép qua nhiều giai đoạn chuẩn bị.

Điều này nghe có vẻ hiển nhiên khi bạn nói ra.

Thế nhưng trong thực tế, chúng ta lại thất bại một cách hệ thống trong việc này. Tôi chỉ có thể tưởng tượng sự vui mừng của những người thợ kim loại khi có cơ hội hướng thiết kế đến một thứ gì đó không chậm chạp và khổ sở để thực hiện.

Một phần lý do chúng ta thất bại là do thiếu hiểu biết về những gì đáng để hỏi. Có lý do mà những giám đốc điều hành giỏi nhất đều có kiến thức sâu rộng về ngành của họ. Tôi cũng nghi ngờ rằng một phần là do thái độ coi thường ("Một người thợ kim loại thì biết gì mà nói với tôi?"). Nhưng một phần lớn khác là do rào cản giao tiếp và chi phí quản lý tổ chức. Các lớp tồn tại đều có lý do của nó—việc ẩn thông tin giúp tổ chức có thể mở rộng quy mô.

Claude tốt hơn trình biên dịch vì nó có thể làm việc theo chiều dọc xuyên suốt toàn bộ hệ thống (stack). Các LLM hiện nay có thể bàn về chiến lược, sản phẩm, kiến trúc, mã nguồn và cả mã máy. Nó không thể (chưa thể?) thực hiện hầu hết các tác vụ cá nhân tốt như một con người chuyên nghiệp và tận tâm, nhưng nó có thể làm tất cả mọi việc mà không cần phải lên lịch họp hay xin phép.

Đây là một ví dụ cụ thể.

Các máy ảo (VM) của exe.dev có tên miền rất đẹp: vm-name.exe.xyz. Khi chúng tôi khởi tạo một máy ảo mới, chúng tôi thêm một hoặc ba bản ghi CNAME. Dễ dàng, phải không?

Nhưng các máy ảo của chúng tôi khởi động rất nhanh, nhanh đến mức ngay cả khi chúng tôi tạo bản ghi DNS trước khi tạo máy ảo, người dùng vẫn phải ngồi chờ DNS lan truyền, đôi khi mất vài phút chứ không phải vài giây.

Chúng tôi đã làm điều hiển nhiên: Viết máy chủ DNS riêng để DNS luôn khớp ngay lập tức với nguồn dữ liệu gốc. Và mọi thứ đều ổn.

Nhưng độ trễ là vấn đề quan trọng, vì vậy chúng tôi đã thêm các khu vực (regions). Và thế là, DNS lại trở thành điểm nghẽn vì tất cả DNS đều được phục vụ từ Oregon. Ngoài ra, việc triển khai gây ra các sự cố DNS nhỏ. Để khắc phục, tất cả những gì chúng tôi cần lúc này là một máy chủ DNS phân tán về mặt địa lý nhưng hoàn toàn nhất quán.

Chúng tôi đã làm điều mà một kỹ sư khôn ngoan sẽ làm khi đối mặt với một vấn đề khó: gian lận. Chúng tôi đã "vibe-engineered" (tạm dịch: kỹ thuật theo cảm tính) một máy chủ DNS phân tán được tinh chỉnh cho các nhu cầu cụ thể của mình.

Các mục tiêu rất rõ ràng: Giảm độ trễ cho người dùng ở xa Oregon và tăng khả năng phục hồi khi có sự cố. Nhưng những phần còn lại thì không. Chúng tôi phải tìm ra mọi thứ, từ hành vi chính xác mà chúng tôi muốn (đặc biệt là trong các điều kiện lỗi khác nhau), cách nó phù hợp với kế hoạch tổng thể của công ty, cho đến kiến trúc có thể đạt được những mục tiêu đó tốt nhất, cho đến tận các chi tiết triển khai nhỏ nhất.

Chúng tôi đã thảo luận trực tiếp về các quyết định chiến lược và kiến trúc ở cấp độ cao nhất. Chúng tôi sẽ tạo ra một máy chủ DNS đa năng, sau đó thêm vào các tinh chỉnh hành vi đặc thù, sử dụng mô hình hub-and-spoke, sử dụng chiến lược sao chép chỉ thêm (append-only) và duy trì tính bền vững tại các điểm biên.

Tất cả những gì còn lại là bắt tay vào xây dựng.

Tôi đã yêu cầu các LLM nghiên cứu các thiết kế tiêu chuẩn cho hệ thống DNS phân tán, dạy tôi về các cơ chế và đặc thù của DNS, chỉ ra các lỗ hổng bảo mật lịch sử, khám phá các chiến lược triển khai thay thế (AXFR/IXFR? không cần đâu), nghiên cứu các giải pháp mã nguồn mở, giả lập các kiểu lỗi và lập kế hoạch chiến lược kiểm thử.

Khi đã có bản phác thảo thiết kế ban đầu có vẻ khả thi, tôi đã yêu cầu nhiều vòng lặp tác nhân đồng thời cùng xây dựng toàn bộ hệ thống, bao gồm cả kiểm thử và đánh giá mã nguồn đối kháng. Chúng đặt ra hàng loạt câu hỏi—ở mọi cấp độ chi tiết, từ các phương pháp cấu trúc chính cho đến các vấn đề mã nguồn ở từng dòng. Khi tôi trả lời chúng (hoặc đảo ngược các câu trả lời gây hối tiếc), tôi dần dần chuyển đổi những gì đã học thành các hướng dẫn bằng văn bản rất ngắn gọn, hệ thống hóa các quyết định quan trọng.

Sau đó, tôi yêu cầu các tác nhân mới so sánh các bản triển khai đã hoàn thành và tìm kiếm những sai lệch thú vị. Thật sốc khi thấy có bao nhiêu quyết định quan trọng mà các tác nhân không hề hỏi mà tự đưa ra—và đưa ra theo những cách khác nhau.

Đây là một ví dụ. Việc sao chép sử dụng phương pháp khá hiển nhiên: Bắt kịp bằng cách yêu cầu mọi thứ kể từ bản ghi cuối cùng được biết, sau đó thăm dò (long poll) các bản ghi mới. Có một điểm khó chịu: khôi phục cơ sở dữ liệu (database rollbacks). Hiếm khi xảy ra, nhưng chúng vẫn xảy ra và phá vỡ hợp đồng "chỉ thêm".

Các tác nhân đã nhận ra điều này và giải quyết theo những cách hoàn toàn khác nhau. Thiết kế mà cuối cùng tôi chọn là gán cho mỗi hàng một trường "dòng thời gian" (timeline), kiểu như "bạn đang sống trong dòng thời gian nào?". Các giá trị này được tạo ngẫu nhiên và mỗi yêu cầu đồng bộ cho "các bản ghi kể từ hàng N" đều bao gồm giá trị dòng thời gian của máy chủ biên cho hàng N. Nếu có sự sai lệch về dòng thời gian, chúng tôi biết rằng lịch sử đã bị thay đổi và sẽ quay lại thực hiện đồng bộ lại toàn bộ từ đầu.

Cũng có những khác biệt về phong cách rõ rệt giữa các hệ thống do các tác nhân khác nhau xây dựng. Cả Claude và Codex đều đồng ý rằng Claude tạo ra một hệ thống thanh lịch hơn, nhưng Codex lại kỹ lưỡng hơn.

Tôi đã làm việc qua danh sách các khác biệt lớn đã xác định, thử nghiệm và sau đó thêm các hướng dẫn bằng văn bản.

Sau đó, tôi lặp lại toàn bộ quy trình phân tích đặc tả khác biệt đó thêm hai lần nữa. Tôi biết các châm ngôn của mình.

Hãy lên kế hoạch vứt bỏ một phiên bản; dù sao thì bạn cũng sẽ làm vậy thôi.

— Fred Brooks

Nếu bạn lên kế hoạch vứt bỏ một phiên bản, bạn sẽ vứt bỏ hai.

— Craig Zerouni

Vào thời điểm tôi sẵn sàng xây dựng một phiên bản chính thức, tôi đã tích lũy được một tài liệu "vết sẹo" đủ để hướng dẫn một tác nhân thực hiện hầu hết các quyết định quan trọng, ở mọi lớp, từ mục tiêu cấp cao qua kiến trúc cho đến các chi tiết cấp thấp như hình dạng chính xác của kiểu dữ liệu cho các bộ đệm đồng thời chịu tải cao.

Hệ thống cuối cùng bao gồm các bài kiểm thử đơn vị, kiểm thử toàn trình (end-to-end), chế độ shadow để giảm thiểu rủi ro khi triển khai thực tế và một bộ tài liệu ngắn gọn được viết bởi và dành cho các tác nhân.