- Thực hành phản trực giác nhất trong kỷ nguyên AI là biết khi nào cần chậm lại, và khi chi phí thực thi ngày càng rẻ hơn thì việc ra quyết định ở giai đoạn trước đó càng trở nên quan trọng
- Áp dụng khung System 1 (đối sánh mẫu nhanh) và System 2 (tư duy phân tích chậm) của Daniel Kahneman vào phát triển phần mềm trong thời đại AI
- Yêu cầu sai hoặc giả định thiết kế sai sẽ được AI lan truyền nhanh hơn, nên hiệu quả trên chi phí của giai đoạn chậm trước khi thực thi được tối đa hóa
- Có thể dùng AI không chỉ cho thực thi mà còn để tăng tốc các bước suy xét như rà soát trước, pre-mortem, khám phá edge case
- Để đối phó với văn hóa áp lực tốc độ mới kiểu "Cứ dùng AI là được mà?", cần một chiến lược làm lộ rõ các giai đoạn chậm và đặt timebox cho chúng một cách rõ ràng
Hai tốc độ tư duy
- Áp dụng hai chế độ tư duy được nêu trong Thinking, Fast and Slow của Daniel Kahneman vào phát triển trong kỷ nguyên AI
- System 1: tư duy nhanh, tự động và dựa trên đối sánh mẫu
- System 2: tư duy chậm, có chủ đích và mang tính phân tích
- Trong cuộc trò chuyện với Dwarkesh Patel, Andrej Karpathy ví LLM như ma hay linh thể, một dạng chưng cất thống kê từ văn bản của con người: từ ngữ đi vào, mẫu được đối sánh, rồi từ ngữ đi ra — về bản chất là một thực thể thuộc kiểu System 1
- AI rất giỏi về đối sánh mẫu nhanh ở quy mô lớn, nhưng việc quyết định nên xây gì, vì sao điều đó quan trọng, và liệu ta có đang giải đúng vấn đề hay không vẫn thuộc phạm vi phán đoán của con người
- Điểm mấu chốt phản trực giác: AI không khiến giai đoạn chậm bớt quan trọng mà khiến nó quan trọng hơn
- Khi thực thi rẻ hơn và nhanh hơn, đòn bẩy dịch chuyển sang ra quyết định trước khi thực thi
- Yêu cầu sai, hiểu nhầm vấn đề, hay giả định thiết kế lỗi sẽ lan sang mọi thứ AI xây dựng, và giờ đây chúng lan nhanh hơn
- System 1 càng mạnh thì chi phí của việc làm sai System 2 càng tăng
Ảo giác về tốc độ
- Một câu đùa cũ trong giới học thuật: "Việc đáng lẽ chỉ mất vài giờ ở thư viện thì lại tốn vài tuần trong phòng thí nghiệm", phiên bản phần mềm là: "Vài tuần code giúp tiết kiệm vài giờ lập kế hoạch"
- Điểm cốt lõi là thực tế lại ngược lại — bắt đầu vội vàng thường dẫn tới việc phát hiện lỗi gốc rễ muộn hơn và kéo theo tái làm đau đớn
- Trong kỹ thuật phần mềm có một trực giác rõ ràng rằng lỗi phải được bắt càng sớm càng tốt, nhất là ở giai đoạn yêu cầu hoặc thiết kế
- Sơ đồ hộp thì dễ thay đổi, yêu cầu bị hiểu sai thì khó hơn, còn kiến trúc triển khai sai từ gốc thì ở mức phải viết lại
- Vấn đề của AI: nó có thể tạo ra technical debt nhanh hơn bao giờ hết
- Nếu các quyết định trước khi thực thi bị lỗi, AI sẽ trung thành hiện thực hóa lỗi đó dưới dạng thứ trông như mã tính năng hoàn chỉnh
- Nó có thể tạo ra hàng nghìn dòng mã dựa trên yêu cầu bị hiểu sai, và sẵn sàng xây một lời giải thanh lịch cho một vấn đề sai
- Ảo giác về tốc độ: cảm giác như đang tiến lên, nhưng thực ra là đang đào cái hố sâu hơn
- Câu trả lời không phải là từ bỏ tốc độ mà là phân bổ nó có chủ đích — tốc độ của AI chỉ nên được phát huy sau khi đã xác nhận đúng hướng
Khi sự chậm lại phát huy tác dụng
- Những điểm mà sự chậm lại có chủ đích phát huy hiệu quả về cơ bản không thay đổi
- Yêu cầu có chi phí thay đổi rẻ khi còn là từ ngữ trên tài liệu, và đắt khi đã là mã triển khai phục vụ người dùng thật
- Quyết định thiết kế dễ sửa trên sơ đồ nhưng khó sửa trong hệ thống production
- AI không thay đổi thứ vật lý nền tảng này, mà chỉ làm tăng đòn bẩy khi ta làm đúng
- Giao thức Thinking First: trước khi giao việc cho AI, hãy đầu tư thời gian để làm rõ điều mình thực sự muốn; đây là điểm rẻ nhất để bắt lỗi
- Có một nghịch lý thú vị là AI có thể được dùng không chỉ để tăng tốc thực thi mà còn để tăng tốc chính quá trình suy xét
- Làm rõ yêu cầu trước khi code: dành 10 phút viết ra vấn đề cần giải, tiêu chí thành công và các ràng buộc, rồi cho AI rà soát nội dung đó trước khi sinh mã
- Chạy pre-mortem: trước khi chốt thiết kế, hỏi AI "Điều gì có thể sai với cách tiếp cận này?" để lôi ra những rủi ro chưa được tính tới
- Đảo ngược vấn đề (Invert): hỏi AI "Điều gì sẽ khiến dự án này thất bại?" để phơi bày các giả định ẩn
- Xây prototype để bỏ đi: dùng AI làm trong vài giờ rồi cho stakeholder xem để kiểm chứng mức độ hiểu trước khi đầu tư — dùng tốc độ để đầu tư cho sự chậm lại
- Xây công cụ nội bộ đơn giản: trước khi tốn chi phí cho sản phẩm thật, hãy để AI làm một phiên bản thô nhằm tìm ra cái gì thực sự cần và cái gì không cần
- Khơi ra edge case sớm: trước khi bắt đầu triển khai, yêu cầu AI sinh ra edge case và failure mode của thiết kế để xử lý ngay ở giai đoạn sơ đồ
Cơn gió ngược văn hóa mới
- "Cứ dùng AI là được mà?" là một dạng áp lực tốc độ mới, và đặc biệt nguy hiểm vì nó nhầm lẫn giữa vẻ ngoài của năng suất với throughput thực tế
- AI có thể tạo mã trong vài giây, nhưng sinh mã và giải đúng vấn đề không phải là một
- Chiến lược đối phó:
- Chia sẻ rõ mình đang ở giai đoạn nào: nếu đang ở giai đoạn chậm, hãy nói rõ rằng ta đang làm rõ yêu cầu, suy nghĩ về edge case, hoặc xác nhận rằng đang giải đúng vấn đề
- Kéo stakeholder tham gia: chi phí phản ánh ý kiến stakeholder lúc này là rẻ, về sau sẽ đắt
- Chia sẻ quá trình làm việc: tài liệu yêu cầu, phác thảo thiết kế, kết quả pre-mortem... hãy làm cho đầu ra của giai đoạn chậm trở nên nhìn thấy được để chứng minh công việc đang diễn ra
- Đặt timebox cho giai đoạn chậm: tạo ranh giới rõ như "2 ngày làm rõ yêu cầu trước khi viết code" để sự chậm lại có chủ đích được cảm nhận là có kế hoạch chứ không mở vô thời hạn
- Chia sẻ những gì đã học được: cập nhật ngắn gọn về edge case đã phát hiện, giả định bị chứng minh là sai... để biến giai đoạn chậm thành dòng chảy giá trị có thể nhìn thấy
- Trình diễn quick win: tạo sớm prototype bỏ đi hoặc mockup để cho thấy ta có thể di chuyển nhanh, từ đó xây dựng niềm tin cho công việc chậm và cẩn trọng
- Tương tự với khái niệm Hill Chart trong phương pháp Shape Up của Basecamp
- Leo dốc: giai đoạn chậm với nhiều bất định, nơi ta khám phá bản chất thực sự của công việc
- Xuống dốc: giai đoạn nhanh khi con đường đã rõ và chỉ còn việc thực thi
- Đây không phải cái cớ cho sự trì hoãn mà là lời giải thích về cách công việc tốt thực sự diễn ra — về lâu dài, những đội ra mắt nhanh nhất thường lại là những đội biết chậm lại vào đúng thời điểm
Cách thực hành
- Hãy thử trước nhiệm vụ được AI hỗ trợ tiếp theo:
- Dành 10 phút viết ra vấn đề bạn thực sự muốn giải quyết, định nghĩa thành công trông như thế nào và điều gì nằm ngoài phạm vi
- Trước khi bắt đầu xây, hãy yêu cầu AI chạy pre-mortem cho cách tiếp cận
- Nếu công việc có quy mô đáng kể, hãy xây prototype để bỏ đi trước nhằm kiểm chứng hướng đi
Kết luận
- Tốc độ và sự chậm lại không đối lập nhau mà là công cụ cho các giai đoạn khác nhau
- AI hiệu quả ở cả hai phía: thực thi nhanh khi hướng đi đã rõ, và suy xét được tăng tốc khi còn mơ hồ
- Năng lực cốt lõi là nhận ra mình đang ở giai đoạn nào và áp dụng nhịp độ phù hợp
4 bình luận
Có câu nói: chậm mà nhanh đó.
Đây là câu tôi thường nghe từ giáo sư hồi học cao học,
giờ lâu rồi mới lại thấy PTSD ùa về.
Tôi đã nghe điều đó khi ở trong quân đội.
Tôi đã đọc trong bản nhạc
allegro non troppo (nhanh nhưng không vội vã)