AI hứa giúp làm ít việc hơn, nhưng tôi chưa bao giờ làm nhiều đến thế

Lời hứa ban đầu rất hấp dẫn: AI sẽ trả lại thời gian cho chúng ta. Viết ít mã khuôn mẫu hơn, giao những phần nhàm chán cho máy, về nhà sớm hơn. Nhưng một kỹ sư phần mềm cấp cao vừa chia sẻ một nghịch lý đáng suy ngẫm: càng dùng tác tử AI (AI agent) nhiều, anh càng làm việc nhiều hơn, và cảm giác mệt mỏi cũng nặng nề hơn.

Điều đáng chú ý là anh không hề phàn nàn về công cụ. Anh dùng tác tử AI cho gần như toàn bộ công việc kỹ thuật, và vẫn đọc lại mã nguồn do chúng tạo ra. Nhờ AI, anh có thể điều tra và triển khai những việc mà hai năm trước chẳng đáng để bắt tay vào. Nhưng cũng chính vì thế, số lượng việc cần làm tăng lên chóng mặt.

Từ hai ba việc mỗi tuần đến nhiều tác tử chạy song song

Trước đây, một tuần điển hình của một kỹ sư full-stack là hai đến ba nhiệm vụ lớn: một tính năng mới, một lỗi hóc búa, có thể là một đợt di trú dữ liệu. Mỗi việc cần tập trung cao độ, nhưng anh có thể giữ trọn một vấn đề trong đầu, làm xong rồi chuyển sang việc kế tiếp.

Ngày nay, bức tranh đã khác hoàn toàn. Nhiều tác tử chạy song song: một con đang triển khai thay đổi, một con điều tra sự cố trên môi trường thật, một con xử lý phần đánh giá mã, một con nghiên cứu thứ anh sẽ cần sau này. Không con nào cần anh liên tục, nhưng con nào cũng cần anh vào một thời điểm nào đó.

Chính cái "thời điểm nào đó" ấy mới là vấn đề.

Mỗi tác tử rồi sẽ quay lại với một câu hỏi, một kế hoạch chờ duyệt, một bản diff chờ đọc hoặc một kết quả cần diễn giải. Để phản hồi, anh phải chuyển ngữ cảnh: nạp lại một bài toán khác, một kho mã khác, một bộ quyết định khác. Làm hai ba việc mỗi tuần thì mệt theo kiểu quen thuộc. Làm việc với nhiều tác tử cùng lúc thì mệt theo kiểu mới, khi sự chú ý bị chia nhỏ và việc chuyển đổi qua lại giữa các vấn đề ngốn sức hơn hẳn.

Biểu đồ số lượng đóng góp theo tháng

Dữ liệu GitHub nói gì

Để hiểu rõ hơn, tác giả kéo toàn bộ lịch đóng góp GitHub của mình từ tháng 1/2019 đến nay và đối chiếu với các vai trò tại Bold.org: kỹ sư full-stack đến tháng 8/2022, kỹ sư chính (Principal Engineer) đến tháng 8/2025, và Phó Chủ tịch Công nghệ từ đó đến nay. Đây là số đóng góp GitHub gồm cả kho riêng tư, tức là trộn lẫn commit, pull request, đánh giá mã và issue — một tín hiệu thô về mức độ hoạt động chứ không phải thước đo giá trị. Năm 2019 là mốc nền không đầy đủ vì công việc trước đó dùng GitLab tự vận hành.

Phần đầu của đường cong diễn ra đúng như dự đoán:

• Những năm code nhiều nhất tại Bold.org là những năm đầu. Năm 2020 cao nhất với 2.711 đóng góp, rồi giảm còn 1.839 vào năm 2021 và 1.498 vào năm 2022.
• Giai đoạn kỹ sư chính bằng phẳng và thấp hơn: trung bình 114 đóng góp mỗi tháng, so với 173 khi còn làm full-stack. Năm 2023 là năm thấp nhất với 1.189.
• Những tháng đầu làm Phó Chủ tịch Công nghệ cũng tương tự: trung bình 111 mỗi tháng từ tháng 8 đến tháng 12/2025, và tháng 12/2025 là tháng yên ắng nhất kể từ khi vào Bold.org với 50 đóng góp.

Rồi năm 2026 xuất hiện, và mọi thứ đảo lộn:

• Tác giả quay lại nhịp của thời full-stack. Đến ngày 27/10 đã có 2.102 đóng góp, nhiều hơn cả một năm trọn vẹn bất kỳ từ 2021 đến 2025. So với cùng kỳ năm 2020 là 2.371, con số của 2026 áp sát năm bận rộn nhất nhưng chưa vượt qua.
• Tháng 8/2026 là tháng bận nhất trong toàn bộ chuỗi thời gian: 427 đóng góp, so với mức cao trước đó là 319 vào tháng 4/2020.
• Ngày làm việc trung vị tăng từ 3–4 đóng góp mỗi năm giai đoạn 2022–2025 lên 7 trong năm 2026, gần với mức 8 của năm 2020.
• Số ngày làm việc không có hoạt động GitHub giảm mạnh: chỉ 18 ngày tính đến 27/10, so với 40–46 ngày mỗi năm trong giai đoạn 2022–2025.
• Những ngày "nặng" trở lại thành chuyện thường ngày. Giai đoạn 2022–2025 chỉ có đúng một ngày mỗi năm đạt từ 24 đóng góp trở lên. Năm 2026 đã có 16 ngày như vậy, gần bằng 17 ngày của cả năm 2020.

Điều trớ trêu nằm ở vai trò. Năm 2020, tác giả là kỹ sư full-stack làm tính năng toàn thời gian, và biểu đồ GitHub phản ánh đúng điều đó. Hôm nay anh lãnh đạo bộ phận kỹ thuật tại Bold.org và làm tính năng ít hơn nhiều. Trên lý thuyết, biểu đồ phải giống giai đoạn kỹ sư chính hoặc thấp hơn. Thay vào đó, nó quay về đúng mức khi viết mã còn là toàn bộ công việc của anh.

Điều thay đổi là số việc cảm thấy đáng để nhận. Khi việc viết mã trở nên rẻ, anh có thể sửa những lỗi mà trước kia để mặc, cải thiện các mẫu thiết kế trên toàn kho mã, nhận thêm dự án mới và biến nhiều ý tưởng thành sản phẩm thật. Tác tử AI không chỉ giúp hoàn thành công việc cũ nhanh hơn — chúng khiến việc tự giao cho mình một khối lượng lớn hơn trở nên dễ dàng.

Bùng nổ rồi kiệt sức, theo chu kỳ

Nhìn vào tổng số theo tháng, năm 2026 không phải một đường leo dốc đều mà là chuỗi những đợt bùng nổ.

Tháng 1 và tháng 2 là đợt đầu tiên, với 277 và 233 đóng góp. Đây là lúc tác giả bắt đầu làm việc nghiêm túc với tác tử, và cũng là lúc thử nghiệm về khả năng quan sát hệ thống phát triển thành trợ lý AI nội bộ của công ty. Tuần nào cũng lộ ra thứ mới có thể giao phó, và anh muốn thử tất cả.

Từ tháng 3 đến tháng 6, nhịp độ hạ dần, từ 203 xuống còn 77 vào tháng 6. Nhưng tháng 4 là một đợt nhỏ giữa đường, khi những cải thiện của mô hình tiếp thêm năng lượng. Đợt tháng 8 mới là lớn nhất: sau kỳ nghỉ hè với cả tuần không có đóng góp, mọi ngày làm việc từ 10 đến 27/8 đều đạt 14 đến 43 đóng góp. Tháng 9 vẫn cao với 301.

Mỗi chu kỳ đều bắt đầu giống nhau. Một mô hình mới hoặc một quy trình mới mở ra thứ mà tháng trước chưa làm được, và đầu óc anh tràn đầy ý tưởng. Vì triển khai giờ đã rẻ, không còn ma sát tự nhiên nào ngăn anh theo đuổi tất cả cùng lúc. Và anh làm thật. Rồi sau vài tuần, việc đánh giá mã và chuyển ngữ cảnh đuổi kịp, buộc anh lùi về một nhịp ổn định hơn — cho đến khi có thứ gì đó hào hứng xuất hiện, hoặc một kỳ nghỉ nạp lại năng lượng để anh lao vào đợt bùng nổ tiếp theo. Từ tháng 1 đến nay đã có ba chu kỳ như vậy.

Mùa thấp điểm không còn thấp nữa

Điều khiến tác giả bất ngờ nhất không phải những đỉnh cao, mà là anh làm được bao nhiêu việc ở giữa các đỉnh.

Tháng 3 không hề giống các đợt bùng nổ của tháng 1, tháng 2 hay tháng 8, nhưng vẫn là 203 đóng góp, so với mức trung bình 114 mỗi tháng thời kỹ sư chính. Anh vẫn đang theo đuổi ý tưởng, nhưng mức hoạt động đó không còn mang cảm giác là một nỗ lực đặc biệt nữa. Ngay cả khi nghĩ mình đang làm chậm lại, vẫn còn kết quả tác tử cần xử lý, đánh giá mã cần hoàn tất, và những việc nhỏ giờ chỉ là "một câu lệnh nhanh".

Tháng 6 thực sự thấp với 77 đóng góp, tương đương những tháng yên ắng thời kỹ sư chính — có lẽ là lúc sự mệt mỏi bắt kịp. Không phải tháng yên ắng nào cũng cao hơn trước. Nhưng ngoài các đợt bùng nổ, tác giả vẫn thấy mình nhận nhiều việc hơn xưa. Đó chính là điều anh muốn nói khi bảo mùa thấp điểm không còn cảm giác thấp nữa.

Vậy điều này dẫn đến đâu?

AI đã mở ra chỗ cho những việc mà trước kia không ai nghĩ đến. Tác giả thích việc có thể sửa nhiều thứ hơn và biến nhiều ý tưởng thành hiện thực. Nhưng khả năng triển khai ý tưởng đã tăng nhanh hơn nhiều so với khả năng suy nghĩ về chúng. Cuối cùng, anh không còn muốn khởi động thêm tác tử nào và quay về làm công việc bình thường. Anh chưa tìm ra điểm cân bằng. Hiện tại, anh chỉ nhận ra rằng khả năng làm nhiều hơn cứ biến thành việc làm nhiều hơn. Và anh đang mệt.

Với người làm công nghệ ở Việt Nam, câu chuyện này khá quen thuộc. Sau làn sóng ứng dụng AI ồ ạt vào công việc lập trình, nhiều đội ngũ nhận ra rằng năng suất tăng không tự động đồng nghĩa với thời gian rảnh tăng. Khi chi phí triển khai giảm, kỳ vọng về khối lượng công việc cũng tăng theo, và phần việc đánh giá, kiểm chứng, chịu trách nhiệm với mã do AI sinh ra lại dồn về con người. Bài học rút ra không phải là từ bỏ công cụ, mà là đặt ra giới hạn rõ ràng cho số luồng công việc song song và giữ lại khoảng thời gian không bị chia nhỏ cho việc suy nghĩ sâu.

Tác giả ghi chú rằng AI đã hỗ trợ anh kéo và phân tích dữ liệu đóng góp GitHub, dựng biểu đồ và viết nháp bài viết này. Trải nghiệm, quyết định và quan điểm là của chính anh.