Khi AI viết code nhanh hơn, dev còn làm nghề sáng tạo không?
AI viết code nhanh hơn, nên nhiều người hỏi phần sáng tạo của nghề lập trình đi đâu. Bài suy ngẫm này tách việc của dev thành năm lớp, xem lớp nào AI nhận và lớp nào còn lại, đặt cạnh các số liệu về niềm vui, kỹ năng và năng suất, rồi nêu những rủi ro và thói quen giữ nghề.
Đây là bài suy ngẫm, tức là mình lập luận và đặt câu hỏi, không phải báo cáo nghiên cứu. Phần nào là số liệu mình dẫn nguồn, phần nào là ý kiến của mình, mình ghi rõ.
Nhiều số liệu là khảo sát tự báo cáo hoặc do hãng công bố, nên cần đọc thận trọng. Hình ảnh người thợ mộc là cách ví von của mình để dễ hình dung.
Tóm tắt nhanh#
- Câu trả lời ngắn của mình: vẫn còn sáng tạo, nhưng phần sáng tạo dịch chuyển, từ "gõ code" sang "chọn việc, chọn hướng, và chịu trách nhiệm cho kết quả".
- Mình chia việc của dev thành năm lớp: tìm vấn đề, định hình lời giải, viết code, kiểm chứng, chăm sóc. AI đang nhận mạnh nhất lớp thứ ba.
- Khi sinh ra phương án rẻ, cái quý lên là gu và khả năng chọn, không phải tốc độ gõ.
- Có rủi ro thật: giao hết phần viết thì có thể mất khả năng đánh giá điều AI làm ra. Một thử nghiệm nhỏ cho thấy dấu hiệu đó.
- Có thể chủ động giữ nghề bằng vài thói quen nhỏ, và bằng một câu hỏi tự đo mỗi tuần.
Từ khó, nói dễ#
| Thuật ngữ | Nói dễ hiểu |
|---|---|
| Tay nghề (craft) | Kỹ năng làm ra thứ tốt bằng chính đôi tay và sự chú ý, tích lũy qua thực hành. |
| Gu (taste) | Khả năng nhận ra cái nào tốt, cái nào chỉ tạm được, khi có nhiều lựa chọn. |
| Đánh đổi (trade-off) | Chọn cái này nghĩa là chịu thiệt ở cái kia, ví dụ nhanh hơn nhưng khó bảo trì hơn. |
| Trạng thái tập trung (flow) | Lúc đang làm việc say sưa, không bị ngắt quãng. |
| Mai một kỹ năng (deskilling) | Vì ít làm nên dần mất khả năng làm. |
| Tự báo cáo | Số liệu từ việc người ta tự nói mình cảm thấy thế nào, không phải đo trực tiếp. |
1. Hình ảnh: người thợ mộc và chiếc cưa điện#
Hình dung xưởng mộc ngày xưa. Mỗi tấm ván đều được cưa tay. Rồi cưa điện xuất hiện. Nghề mộc có chết không?
Mình nghĩ là không, nhưng nó đổi chỗ đặt sự khéo léo. Người thợ ít mất công cưa, nên dành nhiều tâm sức hơn cho thiết kế, cho mối ghép, cho đường hoàn thiện. Cùng lúc đó, có một thứ mất đi thật: cảm giác của đôi tay khi cưa, và với một số người, đó chính là niềm vui của nghề.
Hình ảnh này giúp mình đặt câu hỏi cho chính xác. Đừng hỏi "AI có lấy mất sáng tạo không", mà hỏi: sự khéo léo đang dịch chuyển đi đâu, và mình đang mất gì cùng lúc? Và hình ảnh cũng có giới hạn: cưa điện không "tự quyết định" làm cái bàn gì, còn AI có thể đề xuất cả thiết kế. Nên đừng áp dụng nó một cách máy móc.
2. Năm lớp việc của một dev#
Khi nói "viết code", ta hay gộp nhiều việc làm một. Mình tách thành năm lớp:
| Lớp | Việc | AI hiện giúp được đến đâu (ý kiến của mình) |
|---|---|---|
| 1. Tìm vấn đề | Hiểu người dùng cần gì, vấn đề nào đáng giải | Giúp tóm tắt, gợi ý câu hỏi. Quyết định vấn đề nào đáng thì ít |
| 2. Định hình lời giải | Thiết kế, chọn đánh đổi, quyết định bỏ gì | Đề xuất phương án. Chịu trách nhiệm cho lựa chọn thì không |
| 3. Viết code | Biến thiết kế thành chương trình | Mạnh nhất, nhất là phần lặp lại và rõ ràng |
| 4. Kiểm chứng | Đọc, kiểm thử, gỡ lỗi, biết khi nào "đúng" | Hỗ trợ được, nhưng dễ tự tin quá mức |
| 5. Chăm sóc | Bảo trì, làm việc với người, chịu trách nhiệm lâu dài | Hỗ trợ lặt vặt |
Bảng này là ý kiến của mình, không phải kết quả đo. Nhưng nó giúp thấy một điều: khi lớp ba rẻ đi, bốn lớp còn lại không biến mất, chúng trở nên quan trọng hơn.
3. Gu và sự chọn lọc trở nên quý#
Khi viết một phương án mất một tuần, bạn chỉ có vài phương án để chọn. Khi AI viết một phương án trong vài phút, bạn có thể có mười. Lúc đó, thứ khan hiếm là khả năng nhìn mười cái và nhận ra cái nào đáng giữ.
Đây là phần mình thấy sáng tạo nhất của nghề, và nó cần gu, thứ chỉ có được khi từng làm, từng hỏng, từng sửa. Một câu chuyện cũ minh họa: đầu năm 1982, một kỹ sư ở Apple, theo kể lại, thay một đoạn mã đồ họa bằng thuật toán đơn giản hơn, nhanh hơn khoảng sáu lần và bớt khoảng 2000 dòng, và ghi vào mẫu báo cáo năng suất là âm 2000 dòng. Giai thoại này kể qua nhiều nguồn nên đừng coi từng chi tiết là chính xác, nhưng nó nhắc rằng sáng tạo trong code thường nằm ở việc bỏ bớt, và chuyện đó càng đúng khi sinh code ra gần như miễn phí. Bài Đừng đo năng suất bằng số dòng code nói kỹ hơn.
4. Số liệu nói gì về niềm vui và cảm giác làm nghề#
Có vài mảnh dữ liệu, và chúng không cùng chiều.
- Niềm vui và tập trung (GitHub, tự báo cáo). Nghiên cứu của GitHub về Copilot ghi nhận 87% người dùng nói công cụ giúp giữ sức nghĩ cho việc lặp lại và 73% nói giúp giữ trạng thái tập trung. Một nhóm 60 đến 75% nói cảm thấy công việc trọn vẹn hơn và bớt bực bội khi viết code. Đây là khảo sát tự báo cáo của chính hãng làm công cụ, không phải phép đo trực tiếp.
- Điều làm dev hài lòng (Stack Overflow 2025). Theo các bản tóm tắt khảo sát, những yếu tố đứng đầu là quyền tự chủ và sự tin cậy, lương cạnh tranh và giải quyết vấn đề thật, còn việc tích hợp AI xếp thấp. Tỉ lệ dev "hạnh phúc" tăng nhẹ so với năm trước (24% so với 20%), nhưng vẫn thấp. Mình dựa vào các bài tóm tắt, chưa đọc từng câu của khảo sát gốc.
- Lo lắng về việc làm. Cũng theo các bản tóm tắt, 64% dev không coi AI là mối đe dọa việc làm, giảm từ 68% năm trước.
Đọc chung, mình rút ra một ý thận trọng: AI có thể làm bớt phần nhàm, nhưng niềm vui nghề của nhiều người đến từ tự chủ và giải quyết vấn đề thật, và hai thứ này nằm ở các lớp 1, 2, 5. Nếu AI chỉ làm bớt lớp ba mà không để bạn có thêm tự chủ ở các lớp kia, niềm vui chưa chắc tăng.
5. Rủi ro: mất khả năng đánh giá thứ mình không còn làm#
Phần này mình lo nhất. Muốn chọn đúng thì phải từng làm. Một người chưa từng tự gỡ lỗi khó nhận ra khi AI gỡ sai.
Anthropic công bố (1/2026) một thử nghiệm ngẫu nhiên với 52 lập trình viên, phần lớn còn trẻ, học một thư viện Python lạ. Nhóm dùng AI đạt khoảng 50% bài kiểm tra kiến thức, nhóm tự viết khoảng 67%, chênh nhiều nhất ở câu gỡ lỗi. Mẫu nhỏ (26 người mỗi nhóm), và mình mới đọc bản tóm tắt chứ chưa đọc kỹ bài gốc.
Một nghiên cứu khác của METR (7/2025), với 16 lập trình viên giàu kinh nghiệm làm 246 việc thật, thấy họ chậm hơn khoảng 19% khi dùng công cụ AI đầu 2025 dù tin mình nhanh hơn khoảng 20%. Công cụ đã đổi nhiều, nhưng nó nhắc: cảm giác về việc mình đang làm tốt và việc mình thực sự làm tốt có thể lệch nhau.
Ngoài ra là hai nỗi lo mình chưa có dữ liệu để khẳng định, nên đưa ra như giả thuyết: (1) nếu ai cũng nhận phương án đầu tiên AI đưa, sản phẩm có thể dần giống nhau; (2) nếu việc học nghề bỏ qua phần "tự làm", thế hệ sau có thể thiếu người đủ gu để duyệt.
6. Bối cảnh lớn hơn: AI là cái khuếch đại#
Báo cáo DORA 2025 của Google đi tới một kết luận mà mình thấy hợp với câu chuyện này: AI chủ yếu là một chất khuếch đại. Nó làm điểm mạnh của tổ chức giỏi mạnh thêm và làm điểm yếu của tổ chức đang loạn lộ rõ hơn. Theo báo cáo, lợi ích lớn không đến từ riêng công cụ, mà từ chất lượng nền tảng, độ rõ của quy trình và sự đồng thuận của nhóm. (Mình dựa vào các bản tóm tắt, chưa đọc kỹ toàn bộ báo cáo.)
Áp vào nghề: AI cũng có thể khuếch đại cách làm nghề của bạn. Người có gu và thói quen kiểm chứng sẽ đi nhanh hơn. Người chưa có thể sinh ra nhiều thứ trông ổn nhưng không biết thứ nào hỏng.
7. Năm thói quen để giữ nghề#
Đây là gợi ý của mình, chưa được kiểm chứng trên nhiều người.
- Phác ý tưởng trước khi hỏi. Dành 15 phút vẽ hoặc viết thiết kế của riêng bạn. Rồi so với điều AI đề xuất.
- Đọc như người chấm bài. Đừng chỉ chạy thử. Hỏi "vì sao chọn cách này, thiếu gì, ai sẽ bảo trì".
- Tập xóa. Mỗi tuần tìm một đoạn code có thể bỏ hoặc đơn giản hóa. Sáng tạo thường nằm ở chỗ ít hơn.
- Giữ một khoảng thời gian không dùng AI. Để luyện tay, và để biết mình còn làm được gì.
- Làm đồ nhỏ cho vui. Một công cụ nhỏ cho chính bạn, không vì KPI. Niềm vui làm nghề cần được nuôi.
Nếu bạn mới vào nghề, kế hoạch 12 tháng cho fresher cụ thể hóa thói quen tự viết trước. Và bài Vì sao không nên tin AI tuyệt đối nhắc vì sao cần kiểm chứng.
8. Một câu hỏi để tự đo mỗi tuần#
Tuần này mình đã đưa ra bao nhiêu quyết định mà AI không thể đưa thay mình?
Quyết định ở đây là những chọn lựa có người chịu trách nhiệm: làm vấn đề nào trước, bỏ tính năng nào, chấp nhận đánh đổi nào, nói "không" với yêu cầu nào. Nếu con số cứ giảm, có thể bạn đang trượt khỏi nghề sáng tạo sang nghề duyệt và bấm "chấp nhận". Nếu tăng, có thể AI đang giải phóng bạn cho phần thú vị hơn.
9. Nhìn cân bằng#
- Đây là suy ngẫm, không phải kết luận. Năm lớp việc và các thói quen là ý kiến của mình.
- Dữ liệu còn mỏng và không cùng chiều. Phần lớn là tự báo cáo hoặc do hãng công bố, mẫu nghiên cứu nhỏ, công cụ thay đổi rất nhanh.
- Có người sẽ mất thật. Với một số người, niềm vui là chính việc viết code từng dòng. Nếu phần đó thu hẹp lại, nỗi tiếc là chính đáng, và mình không muốn gạt nó đi bằng câu "nghề chỉ dịch chuyển thôi".
- Hình ảnh người thợ mộc có giới hạn. AI không chỉ là công cụ cầm tay, nó còn có thể đề xuất thiết kế.
- Mình không biết tương lai. Có thể AI sẽ làm tốt cả các lớp 1, 2. Khi đó câu hỏi phải đặt lại.
10. Kết luận#
Dev vẫn làm nghề sáng tạo khi AI viết code nhanh hơn, nếu họ giữ được phần sáng tạo của mình: chọn vấn đề, định hình lời giải, kiểm chứng bằng gu và chịu trách nhiệm. Rủi ro là ở chỗ có thể trượt dần thành người bấm chấp nhận. Cưa điện không lấy mất nghề mộc, nhưng người thợ không còn luyện tay cũng khó thiết kế ra thứ đáng làm.
Việc nhỏ làm ngay: tuần này, trước khi hỏi AI một việc, hãy viết ra ba dòng về cách bạn sẽ làm. Rồi so sánh.
Nguồn tham khảo#
- GitHub: Research, quantifying GitHub Copilot's impact on developer productivity and happiness
- Stack Overflow Developer Survey 2025, phần AI
- Anthropic: AI assistance and coding skills (1/2026)
- Simon Willison về nghiên cứu năng suất của METR
- DORA 2025: State of AI-assisted Software Development
- Negative 2000 Lines Of Code, folklore.org
- Bài liên quan trong blog: Đừng đo năng suất bằng số dòng code, Fresher thời AI: kế hoạch 12 tháng thành junior, Vì sao không nên tin AI tuyệt đối
Câu hỏi thường gặp
- Khi AI viết code nhanh hơn, phần sáng tạo của dev đi đâu?
- Dịch lên các lớp việc khác: tìm vấn đề đáng giải, thiết kế và chọn đánh đổi, kiểm chứng và gỡ lỗi, rồi bảo trì và làm việc với người. Khi tạo ra code rẻ hơn, khả năng chọn đúng giữa nhiều phương án và nhận ra cái nào đáng giữ trở nên quý hơn. Đây là lập luận của tác giả, chưa phải kết luận đã được kiểm chứng rộng.
- AI có làm dev vui hơn hay buồn hơn?
- Dữ liệu chưa đồng nhất. Nghiên cứu của GitHub về Copilot (tự báo cáo) ghi nhận 87% người dùng nói giữ được sức nghĩ cho việc lặp lại, 73% nói giữ được trạng thái tập trung. Khảo sát Stack Overflow 2025 lại cho thấy yếu tố làm dev hài lòng nhất là quyền tự chủ, được tin cậy và giải quyết vấn đề thật, còn AI xếp thấp. Cả hai đều là khảo sát tự báo cáo.
- Dùng AI nhiều có làm dev mất tay nghề không?
- Có khả năng, nếu giao cho AI chính phần mình cần học. Thử nghiệm ngẫu nhiên của Anthropic (1/2026, 52 người học một thư viện mới) thấy nhóm dùng AI đạt khoảng 50% bài kiểm tra so với khoảng 67% nhóm tự viết, chênh nhiều nhất ở câu gỡ lỗi. Mẫu nhỏ nên chỉ nên coi là lời cảnh báo.
- Làm sao giữ sự sáng tạo khi dùng AI hằng ngày?
- Tự phác thiết kế trước khi hỏi AI, đọc code AI viết như người chấm bài, tập xóa bớt code thay vì chỉ thêm, giữ một khoảng thời gian không dùng AI để luyện tay và làm những dự án nhỏ cho vui. Đo bằng câu hỏi: mỗi tuần mình đưa ra bao nhiêu quyết định mà AI không thể đưa thay mình.