Kiến thức nền: cách công cụ xây dựng suy nghĩ

Kế hoạch bạn bỏ qua chính là sự cố bạn phải gỡ rối sau này

Mọi triết lý trong kỹ thuật phần mềm đều khuyên bạn di chuyển nhanh, phát hành sớm, lặp lại trong môi trường thực tế. Với các trang web do AI tạo, điều đó ngược lại. Công cụ xây dựng ở đây từ chối phát trực tiếp mã nguồn ngay từ prompt của bạn — nó dừng lại, viết một kế hoạch, và chờ bạn xem xét — và sự từ chối đó chính là quyết định duy nhất mà toàn bộ pipeline còn lại được xây dựng xoay quanh. Chậm hơn ở đầu, rẻ hơn ở mọi bước sau đó. Tôi sẽ chọn cách đánh đổi đó mọi lúc, và tôi nghĩ hầu hết những người phản đối điều này chưa thực sự chứng kiến một phỏng đoán sai gây tốn kém như thế nào ở các bước sau.

Đây là kiểu thất bại mà kế hoạch tồn tại để ngăn chặn. Bạn gõ "một trang đặt lịch cho studio của tôi" và nhấn chạy. Hệ thống phải đoán "đặt lịch" nghĩa là gì — một widget lịch, một tiện ích nhúng từ bên thứ ba, hay một hệ thống đặt chỗ thật với kiểm tra xung đột — và nó phải đoán trước khi viết bất cứ dòng nào, vì không có thứ tự nào khác để thực hiện. Đoán sai trong một kế hoạch thì cách sửa chỉ là một câu, năm giây, xong. Đoán sai trong mã đã sinh ra thì bạn không còn chỉnh sửa một câu nữa, mà đang gỡ rối mười tệp đã phụ thuộc vào giả định sai đó. Tôi đã chứng kiến cả hai trường hợp. Sửa lỗi ở giai đoạn lập kế hoạch chỉ là một lần trao đổi. Xoay chuyển sau khi đã tạo sinh với cùng một sự mơ hồ đó là bỏ đi và xây lại từ đầu.

Kế hoạch cũng không chỉ là một danh sách việc cần làm, và đây là phần mọi người thường bỏ lỡ. Nó là một bản cam kết, và hệ thống tự ràng buộc mình vào đó: một trình xác minh kiểm tra tính tuân thủ, một trong các agent phải phê duyệt trước khi bản build được phát hành, sẽ so sánh trang web hoàn thiện với kế hoạch bạn đã duyệt. Mọi trang đã lên kế hoạch có được xây dựng không? Danh sách tính năng có khớp với những gì đã phát hành không? "Hoàn thành" ở đây không phải là cảm tính — nó tương ứng với một cam kết bằng văn bản, có thể kiểm tra từng dòng. Đó là một sự đảm bảo mạnh mẽ hơn "mã chạy được", và bạn chỉ có được điều này vì có một tài liệu để đối chiếu. Bỏ kế hoạch đi là bỏ luôn cả thước đo.

Nơi điều này thực sự phát huy tác dụng

Đòn bẩy của bạn với tư cách người điều khiển quá trình xây dựng được dồn về giai đoạn đầu, dù bạn có tận dụng nó hay không. Nếu bạn quan tâm đến kiến trúc thông tin, cấu trúc trang, tính năng nào nên đưa vào v1 so với v2 — sự tỉ mỉ đó đáng giá gấp mười lần khi xem xét kế hoạch so với sau khi đã tạo sinh lần đầu. Bốn phút thêm để đọc lại kế hoạch còn tốt hơn một vòng qua lại để sửa một bản build đã đi lệch hướng.

Ví dụ rõ ràng nhất là loại sản phẩm — trang tĩnh đơn giản, ứng dụng có thể cài đặt, bản build theo framework, ứng dụng có backend với khả năng lưu trữ dữ liệu thật. Nó trông như một menu thả xuống. Nhưng không phải vậy. Đó là lựa chọn mang tính cấu trúc nhất trong toàn bộ quy trình, vì nó âm thầm quyết định hàng chục thứ không liên quan gì đến giao diện của trang web.

Và bạn không thể tùy tiện nâng cấp loại sản phẩm sau này. Chuyển từ trang tĩnh đơn giản sang ứng dụng có backend không phải là bật một tùy chọn cài đặt — mà gần như là xây lại từ đầu lần thứ hai, vì một nửa các giả định của kế hoạch (cách trang tải, dữ liệu nằm ở đâu, "phát hành" nghĩa là gì) đã được thiết lập theo loại cũ. Vì vậy hãy nói rõ điều này ngay ở giai đoạn lập kế hoạch, kể cả khi bạn chỉ chắc chắn một nửa: "có khả năng tôi sẽ cần tài khoản người dùng." Lập kế hoạch cho một ứng dụng có backend rồi chỉ dùng phần tĩnh chẳng tốn kém gì. Phát hiện ra bạn cần nó sau khi đã hoàn thành thì phải xây lại từ đầu.

Những điểm mà người chỉ trích có lý

Không có gì trong số này là miễn phí, và tôi sẽ không giả vờ như vậy. Không gian làm việc riêng biệt cho mỗi lần chạy nghĩa là các tệp kiến thức của bạn được sao chép mới hoàn toàn, không có gì kết nối ngược về máy của bạn — tốt cho bạn nếu laptop của bạn chết giữa chừng khi build, nhưng tệ cho độ trễ, vì việc cấp phát một không gian làm việc và, đối với các bản build framework, chạy cài đặt dependency thực sự bên trong ranh giới container sẽ tốn thời gian thực sự. Ranh giới container đó tồn tại vì một bản build framework chạy `npm install` và các script build tùy ý — mã bạn không viết, thực thi với đặc quyền build-time — và làm điều đó trên một host dùng chung mà không có cách ly nào thì chỉ cách một cuộc tấn công dependency-confusion là chạm vào dữ liệu của một tenant khác. Nhanh-nhưng-không-an-toàn là một lựa chọn khả thi. Chỉ là nó không đáng để đánh đổi.

Câu chuyện tương tự với việc xác minh. Một bản build hoàn thiện không rời khỏi pipeline khi việc tạo dừng lại; nó rời đi khi một tập hợp các bộ xác minh độc lập ngừng tìm thấy điều gì đáng để chặn lại:

• Review mã
• Bảo mật
• Liên kết và SEO
• Khả năng tiếp cận
• Tuân thủ
• Một lần chạy thực tế trên trình duyệt

Đó không phải một lượt duy nhất, mà là gắn cờ-sửa-kiểm tra lại, lặp lại cho đến khi không ai còn gì để nói, vì một lượt kiểm tra linter đơn lẻ có thể bỏ sót một lỗi hồi quy mà chính bản sửa lỗi đó gây ra. Sửa một liên kết hỏng và vô tình phá vỡ cấu trúc heading trên cùng một trang chính là kiểu điều mà một lần kiểm tra duy nhất bỏ lỡ và một lần kiểm tra lại phát hiện ra. Cái giá thực sự của vòng lặp đó là thỉnh thoảng một bản build mất thêm một phút ngay ở cuối mà không có lý do rõ ràng. Người ta để ý đến phút đó. Họ không để ý đến sáu agent vừa tranh luận xong về trang web của họ. Đó là một lời phàn nàn hợp lý về trải nghiệm — tôi chỉ không nghĩ đó là một lý do tốt để phát hành mà không có cuộc tranh luận đó diễn ra.