Hãy tưởng tượng một kho mã của dự án cá nhân có số thứ tự Issue và Pull Request trên GitHub sắp đạt bốn chữ số.
Phản ứng đầu tiên rất dễ là:
“Một người đã làm gần một nghìn việc phát triển rồi sao?”
Gần đúng về cảm giác, nhưng không thể quy đổi trực tiếp như vậy. Trong hệ thống đánh số của GitHub, mỗi Pull Request được xem là một dạng Issue, và số Issue với số Pull Request trong cùng một kho mã không trùng nhau. Vì vậy, số gần 1000 không có nghĩa là đã hoàn thành 1000 Pull Request.[1]
Câu hỏi thú vị hơn vẫn còn nguyên:
Nếu quy mô sửa đổi, kiểm tra, khắc phục, xuất bản và vận hành như vậy phải do con người làm chủ yếu bằng tay, không dùng AI, thì tốn bao nhiêu và có còn hiệu quả kinh tế không?
Đây là một câu hỏi cốt lõi của phát triển cá nhân có AI hỗ trợ.
1. Số GitHub không phải bộ đếm số lần tập gym
Số thứ tự trong kho mã không phải máy đo khối lượng công việc.
Một lập trình viên có thể đưa 2000 dòng thay đổi vào một Pull Request. Người khác có thể mở Pull Request chỉ để sửa một dòng CSS. Các Issue như báo lỗi, ghi chú thiết kế, yêu cầu tính năng, điều tra và nhiệm vụ vận hành cũng dùng chung không gian số.
Vì vậy:
gần số 1000 không tương đương với lao động của 1000 người.
Cũng không có nghĩa là:
gần 1000 tính năng đã hoàn tất.
Con số giống bộ đếm người qua cổng hơn là cái cân.
Tuy nhiên, nếu nhiều thay đổi nhỏ được tích lũy trong thời gian ngắn, lịch sử đó vẫn cho thấy một điều: vòng lặp thiết kế → triển khai → xác minh → sửa chữa đã được chạy rất nhiều lần.
Khi tính chi phí con người, biến quan trọng không phải chính số thứ tự mà là thời gian trung bình cho mỗi vòng lặp thực chất.
2. Chi phí con người dễ bị đánh giá thấp nhất khi mỗi việc trông rất nhỏ
Một báo cáo công bố tháng 9/2026 dựa trên các dự án kỹ sư tự do được niêm yết tại Nhật Bản cho biết mức giá dự án trung bình theo tháng trong tháng 8/2026 là 789.000 yên.[2]
Đó không phải lương của mọi lập trình viên, cũng không phải đơn giá theo giờ của một cá nhân cụ thể. Nó chỉ là mức trung bình của thị trường dự án được đăng.
Dù vậy, có thể dùng nó làm một mốc chi phí thay thế: nếu mua năng lực kỹ thuật tương đương từ bên ngoài thì quy mô chi phí khoảng bao nhiêu?
Chia cho 160 giờ mỗi tháng, con số khoảng 4930 yên mỗi giờ.
Bây giờ giả sử có 1000 đơn vị thay đổi thực chất. Đây chỉ là ví dụ giả định, không phải ý nghĩa của GitHub #1000.
| Thời gian trung bình mỗi thay đổi | Tổng thời gian | Người-tháng ở 160 giờ/tháng | Chi phí ở mức 789.000 yên/tháng |
|---|---|---|---|
| 15 phút | 250 giờ | 1,56 | khoảng 1,23 triệu yên |
| 30 phút | 500 giờ | 3,13 | khoảng 2,47 triệu yên |
| 45 phút | 750 giờ | 4,69 | khoảng 3,70 triệu yên |
| 1 giờ | 1000 giờ | 6,25 | khoảng 4,93 triệu yên |
| 2 giờ | 2000 giờ | 12,5 | khoảng 9,86 triệu yên |
| 3 giờ | 3000 giờ | 18,75 | khoảng 14,79 triệu yên |
| 4 giờ | 4000 giờ | 25 | khoảng 19,73 triệu yên |
Ngay cả 1000 thay đổi chỉ mất 15 phút mỗi cái cũng thành 250 giờ.
“Mỗi việc nhỏ” không có nghĩa là “tổng chi phí nhỏ”.
Những việc nhỏ vẫn có chi phí cố định: điều tra, tạo nhánh, review, kiểm thử, hợp nhất, kiểm tra triển khai và cân nhắc rollback.
Nếu một người làm thủ công mọi thứ, danh thiếp sớm phải gập nhiều lớp: người viết, người dịch, frontend, backend, QA, hạ tầng và tổng biên tập.
3. “Tôi tự làm nên chi phí lao động bằng 0” có thể đúng trong dòng tiền, nhưng khác khi so sánh kinh tế
Một trang cá nhân có thể tốn 1000 yên mỗi tháng cho hosting và kiếm 5000 yên quảng cáo.
Xét tiền mặt, đó là thặng dư 4000 yên.
Nhưng nếu chủ trang dành 50 giờ mỗi tháng, khi so sánh như một doanh nghiệp cần thêm một góc nhìn.
Ít nhất hãy tách hai con số:
Lợi nhuận tiền mặt = doanh thu − chi phí tiền mặt
Lợi nhuận sau điều chỉnh lao động = doanh thu − chi phí tiền mặt − số giờ của chủ × giá trị giờ thay thế đã chọn
Nếu là sở thích, định giá thời gian của mình bằng 0 hoàn toàn hợp lý. Không ai thường nói chơi game 50 giờ tạo ra khoản lỗ nhân công.
Vấn đề chỉ xuất hiện khi kế toán của sở thích được dùng làm bằng chứng rằng mô hình kinh doanh rất có lãi.
Học hỏi, niềm vui, danh tiếng và sự hài lòng khi tạo ra thứ gì đó đều là lợi ích thật. Chúng chỉ không giống lợi nhuận kinh doanh.
Khi so sánh kinh tế, thời gian không biến mất chỉ vì không có hóa đơn.
4. Mô hình quảng cáo có thể cần một mẫu số lớn hơn tưởng tượng
Có thể bắt đầu bằng công thức đơn giản:
Doanh thu quảng cáo = lượt xem trang ÷ 1000 × RPM hiệu dụng
RPM thay đổi mạnh theo quốc gia, thiết bị, định dạng, mùa, chủ đề, đối tượng và hệ thống quảng cáo.
Vì vậy ở đây không khẳng định có một RPM thị trường duy nhất. Chỉ dùng các giá trị giả định để thấy quy mô.
Nếu phải thu hồi 789.000 yên mỗi tháng chỉ từ quảng cáo:
| RPM hiệu dụng giả định | PV cần để đạt 789.000 yên/tháng |
|---|---|
| 100 yên | khoảng 7,89 triệu PV |
| 300 yên | khoảng 2,63 triệu PV |
| 500 yên | khoảng 1,58 triệu PV |
| 800 yên | khoảng 0,99 triệu PV |
Đây không phải dự báo doanh thu của trang nào cụ thể.
Bảng cho thấy rằng khi lao động thủ công được định giá theo chi phí thay thế chuyên nghiệp, việc hoàn vốn chỉ bằng quảng cáo có thể đòi hỏi lượng truy cập rất lớn.
Vì thế nhiều trang thủ công kết hợp quảng cáo với tiếp thị liên kết, bán sản phẩm, tìm khách hàng, hội viên, tài trợ, giá trị thương hiệu hoặc đơn giản là giá trị sở thích.
5. AI thay đổi nhiều hơn tốc độ viết
Nếu thu gọn giá trị AI thành “viết một bài trong 30 giây”, ta sẽ bỏ lỡ phần lớn kinh tế học.
Vận hành một ấn phẩm web có nhiều công đoạn xung quanh:
- tìm đề tài,
- nghiên cứu,
- viết,
- kiểm chứng,
- sửa mã,
- kiểm thử,
- bản địa hóa,
- xuất bản,
- xác minh kết quả thật trên production,
- sửa sự cố,
- phân phối lên mạng xã hội và bản tin,
- đo lường rồi cải tiến.
Trong vận hành thủ công, mỗi công đoạn thêm vào thường làm tăng chi phí lao động biến đổi.
Với AI và tự động hóa, chi phí xây hệ thống ban đầu có thể cao hơn, nhưng chi phí biên của sản phẩm thứ hai, thứ mười và thứ một trăm có thể giảm.
Đây không chỉ là “người viết nhanh hơn”.
Nó gần với việc:
một người có thể sở hữu hệ điều hành của một ban biên tập nhỏ và một đội kỹ thuật nhỏ.
Con người không biến mất.
Vai trò chuyển sang đầu vào, quyết định, đặc tả, tiêu chuẩn chất lượng, ngoại lệ và quản trị.
Từ người tự tay làm từng sản phẩm sang người thiết kế nhà máy kiêm tổng biên tập.
6. AI không phải bình nitro thần kỳ luôn làm phát triển nhanh hơn
Kết quả nghiên cứu đáng chú ý chính vì không cùng hướng.
Một thí nghiệm có đối chứng công bố năm 2023 cho thấy nhóm được dùng GitHub Copilot hoàn thành một nhiệm vụ máy chủ HTTP JavaScript cụ thể nhanh hơn nhóm đối chứng 55,8%.[3]
Ngược lại, thử nghiệm ngẫu nhiên của METR năm 2025 cho thấy 16 lập trình viên nguồn mở giàu kinh nghiệm, làm việc trên những kho mã trưởng thành mà họ đã quen nhiều năm, trung bình mất nhiều hơn 19% thời gian khi được phép dùng công cụ AI đầu năm 2025.[4]
Tháng 2/2026, METR giải thích rằng thí nghiệm tiếp theo trở nên khó diễn giải. Nhiều lập trình viên không muốn tham gia nếu phải làm việc không có AI, và việc đo thời gian cũng khó hơn với người chạy nhiều tác nhân song song. Các công cụ mới có thể tăng tốc nhiều hơn so với đầu 2025, nhưng dữ liệu mới chưa cho phép ước lượng một con số chắc chắn do vấn đề chọn mẫu và đo lường.[5]
Vì thế kết luận không phải:
AI luôn nhanh hơn 55%.
Cũng không phải:
AI làm chuyên gia chậm hơn 19%.
Tác động phụ thuộc nhiệm vụ, mức quen thuộc với codebase, quy trình dùng tác nhân, gánh nặng review, mức song song và môi trường kiểm thử.
AI có thể tạo ra kết quả đúng rất nhanh. Một hệ thống tệ cũng có thể tạo bug rất nhanh.
Chỉ số hữu ích là chỉ số đo trong quy trình thực tế của chính mình.
7. Trang thủ công không tự động thua
Một hệ thống AI tự động hóa mạnh không được đảm bảo sẽ sinh lời hơn trang làm thủ công.
Làm thủ công có thể hợp lý khi:
- mỗi tháng chỉ đăng vài bài,
- văn phong cá nhân của chuyên gia chính là sản phẩm,
- một bài có thể bán dịch vụ hoặc sản phẩm giá trị cao,
- không cần nhiều ngôn ngữ hay phân phối quy mô lớn,
- cập nhật hiếm,
- chủ trang thích việc sản xuất như một sở thích,
- hoặc xây tự động hóa tốn hơn lượng lao động tiết kiệm được.
Tự động hóa hấp dẫn hơn khi:
- cùng một quy trình lặp lại liên tục,
- duy trì nhiều ngôn ngữ,
- số lượng nội dung tăng,
- mỗi lần xuất bản đều cần QA và xác minh thật,
- kênh phân phối tăng,
- và con người phải lặp lại cùng một kiểm tra.
Về bản chất, đây là bài toán chi phí cố định và biến đổi.
Nhà máy AI có thể đắt lúc đầu. Xưởng thủ công có thể đắt trên mỗi sản phẩm.
Và cần nhớ: một nhà máy tự động cực kỳ hiện đại nhưng không có độc giả không phải tương lai của truyền thông. Nó chỉ là một kho hàng rất tinh vi.
8. Muốn hiểu hiệu quả kinh tế của một trang thủ công không AI, hãy hỏi những con số này
Không cần đánh giá con người.
Để so sánh hệ thống, chỉ cần vài số vận hành:
- Số giờ chủ trang làm mỗi tháng
- PV hoặc người dùng duy nhất mỗi tháng
- Doanh thu và chi phí tiền mặt mỗi tháng
- Tổng số bài và số bài mới mỗi tháng
- Số ngôn ngữ hỗ trợ
- Số năm vận hành và thời gian xây dựng ban đầu ước tính
Từ đó có thể tính:
Lợi nhuận tiền mặt = doanh thu − chi phí tiền mặt
Thu nhập tiền mặt theo giờ của chủ = lợi nhuận tiền mặt ÷ số giờ
Lợi nhuận sau điều chỉnh lao động = lợi nhuận tiền mặt − số giờ × mức giá giờ so sánh
Chi phí biên mỗi bài = thời gian và chi phí tăng thêm cho viết + dịch + QA + xuất bản + phân phối
Chỉ số cuối đặc biệt quan trọng.
Đã từng tốn 1000 giờ trong quá khứ ít nói về tương lai hơn hiện tại cần bao nhiêu giờ để xuất bản bài tiếp theo.
9. Sức mạnh thực sự của AI trong phát triển cá nhân không phải số lượng, mà là tính lặp lại
Tạo một núi tệp trong một đêm giờ không còn là phần khó nhất.
Phần khó là xây hệ thống sao cho:
- lần sau vẫn áp dụng cùng tiêu chuẩn chất lượng,
- chỉ phạm vi thất bại phải làm lại,
- tránh xuất bản trùng,
- xác định được phiên bản hiện hành,
- xác minh kết quả thật trên production,
- một kênh bị chặn không đóng băng phần việc độc lập,
- chỉ xác thực thực sự cần người mới trả lại cho người,
- và lịch sử vẫn kiểm toán được.
Đó không chỉ là khối lượng tạo sinh.
Đó là tài sản vận hành.
Trang thủ công cũng có thể xây tài sản tương tự bằng quy trình, mẫu, CMS, sao lưu và checklist.
Điểm khác của thời đại AI là một người giờ có thể xây các lớp vận hành này sâu hơn rất nhiều.
10. Kết luận: câu hỏi thú vị không phải “đã tới 1000 chưa?” mà là “đơn vị tiếp theo tốn bao nhiêu?”
Số thứ tự Issue và Pull Request sắp đạt bốn chữ số trông rất ấn tượng.
Nhưng đừng dùng nó làm điểm năng suất.
Các con số hữu ích hơn là:
giờ lao động, chi phí mỗi thay đổi, chi phí biên mỗi bài, tỷ lệ làm lại trước xuất bản, sản lượng trên mỗi giờ của chủ, và lợi nhuận sau điều chỉnh lao động so với doanh thu.
Trang thủ công hoàn toàn có thể có lãi.
Trang dùng AI hoàn toàn có thể lỗ.
Nhưng đường chi phí khác hẳn giữa mô hình bắt con người lặp lại việc viết, dịch, phát triển, QA, xuất bản, giám sát và phân phối bằng tay mỗi lần với mô hình đầu tư xây hệ thống trước rồi hạ chi phí biên về sau.
Số gần 1000 thú vị không phải vì nó là huy chương.
Câu hỏi quan trọng là:
trong tất cả các vòng thử và sửa đó, có bao nhiêu vòng đã biến thành cơ chế khiến lần sau con người không phải lặp lại cùng một việc?
Đó là nơi kinh tế học của phát triển cá nhân có AI thực sự thay đổi.
- GitHub Docs — Issue event types / REST API. GitHub states that every pull request is an issue, but not every issue is a pull request, and that issue and pull-request numbers do not overlap within a repository docs.github.com
- En Japan / Freelance Start, 2026-09-03. August 2026 freelance-engineer listings averaged ¥789,000 per month; 445,327 listings were included at month end. This is a marketplace listing statistic, not a universal salary or an observed cost for any person discussed in this article prtimes.jp
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” In a controlled JavaScript HTTP-server task, the treatment group completed the task 55.8% faster arxiv.org
- Becker, J., Rush, N., Barnes, B., & Rein, D. / METR (2025-07-10). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” Sixteen experienced developers completed 246 tasks in mature repositories; allowing early-2025 AI tools increased completion time by 19% on average in this study metr.org
- METR (2026-02-24). “We are Changing our Developer Productivity Experiment Design.” METR reports that later productivity experiments suffered from participant-selection and time-measurement problems, especially as developers became reluctant to work without AI and used multiple agents in parallel; the newer data are weak evidence for the size of current speedup metr.org
