Khi AI viết code: Hiểu mã nguồn mới là nút thắt cổ chai thực sự

Ý kiến cá nhân: Tôi cho rằng việc hiểu được mã nguồn mà các agent của chúng ta viết ra vẫn là điều rất quan trọng!

Trong bài nói chuyện này, tôi sẽ giải thích lý do tại sao lại như vậy, đồng thời đưa ra một vài ý tưởng để hiểu mã nguồn một cách hiệu quả. Được rồi, chúng ta cùng bắt đầu nhé.

Các agent đang viết ngày càng nhiều mã nguồn cho chúng ta, và tất cả chúng ta đều biết rằng việc theo kịp tiến độ này đang trở nên khó khăn hơn.

Nhưng tin tốt là: có rất nhiều cách để hiểu mã nguồn! Đọc từng dòng diff không phải là cách duy nhất.

Phần lớn bài nói chuyện này sẽ xoay quanh các kỹ thuật mà tôi thấy hữu ích để hiểu các hệ thống mà các agent của tôi đang xây dựng:

Nhưng trước hết, chúng ta phải đặt ra một câu hỏi cơ bản hơn…

Tại sao phải hiểu?

Tại sao chứ? Tại sao phải hiểu?

Chẳng phải bây giờ chúng ta nên tự tách mình ra khỏi vòng lặp và để các agent tự vận hành sao? Khi các agent ngày càng thông minh hơn, chẳng phải việc chúng ta nắm bắt các chi tiết trở nên ít quan trọng hơn sao?

Tôi nghĩ nhiều người — ngay cả những người ủng hộ việc phải hiểu — lại có câu trả lời hơi sai lệch cho câu hỏi này!

Một câu trả lời khả dĩ: chúng ta hiểu để xác minh. Chúng ta kiểm tra công việc của agent, xem liệu nó có chính xác hay không.

"Chính xác" có thể mang nhiều nghĩa: liệu nó có khớp với đặc tả kỹ thuật không, kiến trúc có tốt không… nhưng về cơ bản, đó là câu hỏi kiểu đồng ý hay không đồng ý (thumbs-up / thumbs-down).

Vấn đề là ở chỗ này: các agent đang ngày càng giỏi hơn trong việc tự xác minh công việc của chính mình. Và điều này rất tốt! Tôi thích việc agent của mình không mắc lỗi.

Nhưng hừm. Vậy thì con người chúng ta đứng ở đâu?

Đó là lúc một câu trả lời khác xuất hiện: chúng ta có thể hiểu để tham gia.

Bạn có thể tìm hiểu những gì agent đang làm để đảm bảo rằng bạn có thể là một người tham gia tích cực trong quá trình sáng tạo. Đây là lý do tại sao điều này quan trọng…

Nó không bao giờ chỉ là một vòng lặp đơn lẻ! Một dự án là tập hợp của rất nhiều, rất nhiều vòng lặp với agent.

Và sự hiểu biết của bạn về hệ thống chính là một phần khả năng giúp bạn nảy ra ý tưởng tiếp theo để phát triển nó.

Bạn cần một tập hợp các khái niệm phong phú trong đầu để suy nghĩ một cách sáng tạo và trôi chảy về cách thúc đẩy mọi thứ tiến lên. Nếu thiếu sự trôi chảy đó, khả năng tham gia vào dự án của bạn sẽ bị hạn chế đáng kể.

Nhân tiện, điều này liên quan mật thiết đến khái niệm "nợ nhận thức" (cognitive debt), được phổ biến bởi Margaret Storey và Simon Willison.

Nó giống như nợ kỹ thuật (tech debt): bạn có thể tạm thời không hiểu chuyện gì đang xảy ra trong ngắn hạn, nhưng cuối cùng nó sẽ gây rắc rối cho bạn.

OK, được rồi, sự hiểu biết là quan trọng.

Nhưng điều này đặt ra câu hỏi tiếp theo: bằng cách nào? Làm thế nào để chúng ta xây dựng sự hiểu biết của con người khi làm việc với AI và di chuyển với tốc độ nhanh?

Chà, hóa ra đây không phải là lần đầu tiên có người suy nghĩ về cách truyền đạt sự hiểu biết. Tôi nghĩ chúng ta có thể lấy giáo dục làm nguồn cảm hứng. Liệu chúng ta có thể "vay mượn" những ý tưởng hay nhất từng được phát minh cho giáo dục và áp dụng chúng vào vấn đề này không?

Kỹ thuật 1: Giải thích

Hôm nay tôi muốn chia sẻ ba kỹ thuật cho thấy cách chúng ta có thể thử nghiệm điều này.

Đầu tiên: giải thích. Điều gì tạo nên một lời giải thích tốt?

Bất cứ khi nào một agent hoàn thành công việc, đó là cơ hội cho một lời giải thích — một sản phẩm (artifact).

Cách đơn giản nhất là chúng ta đọc một code diff: nguyên liệu thô đã thay đổi.

Nhưng nếu chúng ta đặt câu hỏi:

Lời giải thích tốt nhất sẽ như thế nào? Nếu bạn có một đội ngũ — dù là con người hay AI — thực sự chú tâm vào việc giải thích cặn kẽ mọi thứ cho bạn, bạn sẽ cảm thấy thế nào?

Đây là một câu trả lời. Tôi đã tạo ra một kỹ năng gọi là /explain-diff, thứ mà tôi sử dụng hàng ngày và nhiều đồng nghiệp của tôi thấy rất giá trị.

Nó xuất ra các phần giải thích mã nguồn được cấu trúc chu đáo dưới dạng HTML, markdown hoặc tài liệu Notion. Notion là một nơi tốt để cộng tác và thảo luận về các phần giải thích này theo nhóm. (Lưu ý: Tôi làm việc tại Notion nên tôi có phần thiên vị.)

Hãy xem bên trong một trong những phần giải thích này có gì, sử dụng ví dụ về việc chỉnh sửa góc nhìn của một trò chơi điện tử.

Nguyên tắc đầu tiên: cung cấp cho tôi thông tin nền tảng!

Trước khi đi vào những gì đã thay đổi, hãy giúp tôi hiểu những gì đã có sẵn ở đó. Trong trường hợp này, hãy dạy tôi về game engine.

Nguyên tắc thứ hai: trực giác trước chi tiết.

Trước khi đi vào bất kỳ đoạn mã nào, nó nêu rõ mục tiêu — "làm cho khu vườn có cảm giác ba chiều bằng các thủ thuật vẽ 2D" — và giải thích các khái niệm liên quan, chẳng hạn như phép chiếu đẳng cự (isometric projection) là gì.

Tất cả những điều này xây dựng trực giác của tôi về bản chất của sự thay đổi. Nó giúp tôi — với tư cách là con người — bắt kịp để có thể trở thành một người tham gia bình đẳng trong việc thấu hiểu hệ thống.