Bài viết này như một phần phụ lục / nhánh rẽ của loạt bài gần đây. Nó không hoàn toàn phù hợp để đưa vào bài chính nên tôi đăng riêng. Bài này được đề cập ngắn gọn trong phần 2 của Why Software Factories Fail: Turning the lights back on.
Tìm kiếm Đòn bẩy
Ngay cả trước thời đại AI, chỉ có 25-50% thời gian để hoàn thiện một tính năng là dành cho việc viết code. Phần còn lại là căn chỉnh/lên kế hoạch, review code/làm lại, và kiểm thử/xác minh giải pháp.
Nếu bạn chỉ dùng AI để viết code, thì bạn đang giảm 2-4 giờ viết code xuống còn 10-20 phút, nhưng bạn chưa tăng tốc bất kỳ phần nào khác.
Nhưng nếu bạn dùng AI để giúp lên kế hoạch và căn chỉnh, thì bạn thực sự có thể nhanh hơn gấp 2-3 lần.
Nguyên tắc 80/20 trong đòn bẩy code AI
Giả sử nếu bạn tùy tiện đưa một prompt hai câu vào factory của mình, khả năng bạn nhận được kết quả hoàn toàn có thể merge là ~50%, khả năng bạn phải làm lại là 50%.
Bây giờ giả sử bạn là một kỹ sư chính với 10 năm kinh nghiệm. Bạn có toàn bộ codebase qua 100 repo trong đầu. Vì vậy, bạn dành cả buổi chiều để viết một spec chi tiết hoàn hảo bằng tay. Lúc này, tỷ lệ của bạn tốt hơn, nhưng có lẽ bạn vẫn có khoảng 10% khả năng phải làm lại \*một điều gì đó* quan trọng.
Và ở đầu kia: viết từng dòng code một mình. Không còn gì để agent sai sót, vì vậy khả năng làm lại về không.
\\ghi chú\\ Trong ví dụ này, tôi sẽ làm mờ
"khả năng bạn sẽ phải thay đổi thứ gì đó" được cân nhắc với "mức độ đau đớn của sự thay đổi"
thành một tỷ lệ phần trăm duy nhất, nhưng rõ ràng chúng là hai biến số riêng biệt. Nếu model có 50% khả năng sai kiểu nút, nhưng cách sửa chỉ là một prompt rẻ, thì "mức độ đau đớn dự kiến" kết hợp của chúng ta thấp.
mức độ đau đớn dự kiến = P(bạn sẽ phải thay đổi nó) × mức độ đau đớn của sự thay đổi
Nếu bạn vẽ điều này ra, có một mối quan hệ nghịch đảo giữa công sức đầu tư ban đầu và mức độ đau đớn dự kiến.
Điều bạn không muốn làm là dành 6 giờ lên kế hoạch cho một nhiệm vụ mà bạn có thể loại bỏ 80% mức độ đau đớn dự kiến chỉ trong 10 phút đầu tiên.
Bạn cần làm điều này mà không sa đà vào những câu hỏi bạn sẽ không thể trả lời nếu không đi sâu vào một cấp độ. Ví dụ, nếu bạn đã làm một số công việc ở cấp độ "Sản phẩm" và chưa trả lời hết các câu hỏi mở, có thể bạn cần kết thúc ở đó và phóng to xuống một cấp độ để xem xét chi tiết kỹ thuật nhằm hiểu điều gì khả thi. Không có quy trình hoàn hảo cho việc này.
Đây là điều chúng tôi muốn nói đến khi nhắc tới đòn bẩy - và nó đòi hỏi sự thực tế. Nếu bạn đang thực hiện nhiều giai đoạn lập kế hoạch, từ tầm nhìn 50.000 feet xuống đến 10.000 feet, bạn muốn thực hiện một chút định hướng ở mỗi giai đoạn để đảm bảo rằng bạn đang loại bỏ càng nhiều mức độ đau đớn dự kiến càng tốt.
Chúc bạn may mắn.
