Slow Productivity: Tuyên ngôn cho dev thời đại AI
Mình đã đọc Slow Productivity của Cal Newport và nhận ra việc viết code chậm lại mới là cách sống sót khi AI ngày càng nhanh.
Tuần trước, một đồng nghiệp hỏi mình tại sao dạo này ít commit code hơn hẳn dù đã dùng Cursor. Mình chỉ trả lời ngắn gọn là mình đang chuyển sang chế độ “chậm lại” để không bị AI nuốt chửng.
Năng suất chậm thực sự là gì?
Mình đã đọc cuốn Slow Productivity: The Lost Art of Accomplishment Without Burnout của Cal Newport xuất bản năm 2024. Cuốn sách này ra đời như một câu trả lời cho làn sóng kiệt sức hậu làm việc từ xa. Nó đánh thẳng vào một khái niệm mà Newport gọi là “pseudo-productivity” - năng suất ảo.
Năng suất ảo là khi bạn lấy các hoạt động nhìn thấy được làm thước đo cho công việc. Trả lời email nhanh, chấm xanh trên Slack cả ngày, hoặc tạo ra hàng tá pull request nhỏ lẻ. Trong ngành phần mềm, điều này cực kỳ độc hại. Khi các công cụ AI như Claude Sonnet 4.6 hay GPT-5 có thể nhả ra hàng trăm dòng code trong vài giây, áp lực phải “nhìn có vẻ bận rộn” càng tăng cao.
Nhưng viết code nhanh không có nghĩa là tạo ra giá trị lớn. Theo trang web chính thức của tác giả (https://calnewport.com), có ba nguyên tắc cốt lõi để thoát khỏi cái bẫy này. Làm ít việc hơn. Làm việc theo nhịp độ tự nhiên. Và ám ảnh về chất lượng.
Bỏ bớt việc để làm đúng việc
Bẫy tốc độ của công cụ AI
Khi bạn dùng Windsurf hoặc Cursor, AI gõ code nhanh đến mức bạn ảo tưởng mình có thể gánh gấp ba lần khối lượng công việc bình thường. Mình từng rơi vào trạng thái nhận vô tội vạ các task lặt vặt. Kết quả là cuối ngày mình mệt lả mà hệ thống vẫn đầy lỗi logic.
Làm ít việc hơn không có nghĩa là lười biếng. Nó có nghĩa là bạn dồn sức vào những bài toán khó mà AI không tự giải quyết được. Bạn cần thời gian để ngồi im lặng và suy nghĩ về kiến trúc hệ thống. Nếu bạn nhớ lại bài viết Deep Work đã chết trong kỷ nguyên của Cursor, bạn sẽ thấy ranh giới giữa việc suy nghĩ sâu và việc trở thành một cái máy gõ code đang rất mong manh.
Làm việc theo nhịp độ tự nhiên
Chấp nhận những mùa code chậm
Con người không phải là những máy chủ AWS chạy 24/7. Chúng ta có những giai đoạn làm việc năng suất cao và những lúc cần chậm lại. (Nghe hơi ngược đời trong ngành IT, nhưng để mình giải thích).
Trong các dự án phần mềm, có những tuần bạn cần chạy nước rút để kịp release. Nhưng sau đó, bạn cần một “mùa chậm” để refactor code, đọc tài liệu, hoặc đơn giản là dọn dẹp technical debt. Nếu bạn cố ép mình chạy nước rút quanh năm với sự trợ giúp của AI, bạn sẽ kiệt sức. Sự kiệt sức này không đến từ việc thiếu ngủ, mà đến từ việc não bộ bị quá tải bởi việc liên tục chuyển đổi ngữ cảnh giữa hàng chục file code do AI tạo ra.
Ám ảnh về chất lượng thay vì số lượng
Chất lượng trong kỷ nguyên AI
Ngày nay, ai cũng có thể tạo ra một ứng dụng CRUD cơ bản trong một buổi chiều. Khác biệt giữa một senior developer và một người thợ gõ code nằm ở chất lượng. GPT-5.2 có thể viết boilerplate rất tốt, nhưng nó không hiểu ngữ cảnh kinh doanh đặc thù của công ty bạn.
Thay vì đếm số lượng tính năng hoàn thành, hãy nhìn vào độ ổn định của hệ thống. Bạn có thể dành cả ngày chỉ để review code của AI và tinh chỉnh lại một thuật toán. Chậm nhưng chắc. Đôi khi, việc chọn đúng mô hình AI để giải quyết bài toán phức tạp cũng tốn thời gian. Bạn có thể tham khảo bài Sonnet 4 vs Opus 4: Đừng lãng phí tiền của bạn để hiểu tại sao việc chọn công cụ cẩn thận lại quan trọng hơn việc cắm đầu vào code ngay lập tức.
Slow Productivity - Cal Newport
Xem giá trên Shopee →* Liên kết tiếp thị liên kết - giá không đổi với bạn
Năng suất ảo vs Năng suất chậm
| Tiêu chí | Năng suất ảo (Pseudo) | Năng suất chậm (Slow) | Ghi chú |
|---|---|---|---|
| Thước đo | Số lượng commit, thời gian online | Độ ổn định kiến trúc, tác động thực tế | AI đang làm lạm phát số lượng commit |
| Tốc độ | Cố gắng phản hồi tin nhắn tức thì | Chấp nhận phản hồi chậm để tập trung | Tắt Slack khi đang làm việc khó |
| Tư duy | Hoàn thành càng nhiều task càng tốt | Chọn lọc task cốt lõi để làm thật tốt | Phù hợp cho senior dev và freelancer |
Cách áp dụng Slow Productivity cho Dev
Để đưa triết lý này vào thực tế khi làm việc với AI, mình áp dụng các bước sau.
- Giới hạn số lượng task đang mở. Mình không bao giờ để quá ba task “In Progress” trên Jira. Nếu AI giúp mình làm nhanh, mình sẽ hoàn thiện nó 100% trước khi kéo task mới.
- Tách biệt thời gian suy nghĩ và thời gian prompt. Đừng vừa nghĩ vừa gõ prompt. Vẽ ra giấy hoặc viết pseudo-code trước, sau đó mới yêu cầu AI thực thi.
- Chấp nhận những ngày không có dòng code nào. Có những ngày công việc của bạn chỉ là đọc log, phân tích lỗi, và tìm ra nguyên nhân gốc rễ. Đừng cảm thấy tội lỗi vì điều đó.
Câu hỏi thường gặp
Cuốn sách này có phù hợp cho fresher không?
Fresher thường chưa có đủ quyền tự quyết về lịch làm việc, nên sẽ hơi khó áp dụng toàn bộ. Tuy nhiên, tư duy tập trung vào chất lượng thay vì số lượng vẫn cực kỳ giá trị để xây dựng nền tảng.
Sếp mình đánh giá qua số lượng commit thì sao?
Đó là một môi trường quản lý vi mô. Slow Productivity chỉ ra rằng phương pháp làm việc này sinh ra từ những công việc nhà máy. Nếu không thể thay đổi cách sếp đánh giá, bạn có thể dùng AI để tự động hóa các task nhỏ, và giữ lại năng lượng cho những task quan trọng.
Slow Productivity có đi ngược với Agile không?
Không hề. Agile là việc chia nhỏ công việc để dễ quản lý rủi ro và phản hồi nhanh với thay đổi. Năng suất chậm giúp bạn duy trì chất lượng trong từng sprint mà không bị cháy máy sau vài tháng.
Kết luận
Đọc Slow Productivity giúp mình nhận ra một sự thật phũ phàng. Nếu chúng ta tiếp tục đua tốc độ với máy móc, chúng ta chắc chắn sẽ thua. Giá trị của một kỹ sư phần mềm không còn nằm ở việc gõ chữ nhanh ra sao, mà nằm ở khả năng từ chối những việc vô bổ để tập trung xây dựng những hệ thống vững chắc. Chậm lại một chút, bạn sẽ thấy mình đi được xa hơn nhiều.