Một thay đổi phần mềm khá lớn được giao cho một AI agent.
Ban đầu trông như việc vài chục phút. Nhưng GitHub cứ tiếp tục có thêm commit, test, thay đổi tích hợp và sửa lỗi. Nhiều giờ sau, code thật vẫn tiếp tục thay đổi.
Trong lúc đó, con người đã hoàn thành các việc ngoài đời, thậm chí xong cả một lần chuyển nhà.
Sự kiện đời sống xong trước, còn refactor vẫn chạy.
Khung cảnh đã khá giống tương lai.
Điều lạ hơn là thiết bị ra lệnh chỉ là smartphone. Người dùng không cần tự hiểu từng module TypeScript, chi tiết CI/CD hay quy tắc học graph. Họ có thể mô tả mục tiêu, invariants, quyền được phép, điều cấm thay đổi và tiêu chí hoàn tất bằng ngôn ngữ tự nhiên; agent đọc repository, thiết kế, viết code, thêm test, mở PR và tích hợp thay đổi.
Vậy đây có phải là “trở thành senior engineer chỉ với điện thoại” không?
Không hoàn toàn. Nhưng nó gần hơn nhiều so với hình dung cũ về phát triển phần mềm.
1. Điện thoại không phải thứ thực hiện tính toán cấp senior
Smartphone không tự tạo hàng trăm dòng production code tại máy. Nó là bảng điều khiển.
Phía sau là AI model, GitHub, CI, cloud, production environment, tìm kiếm và development tools. Điện thoại chỉ truyền ý định và ràng buộc.
Vì vậy mô tả chính xác hơn không phải “lập trình bằng điện thoại”, mà là:
“điều phối tài nguyên nhận thức và tính toán từ xa bằng điện thoại.”
Data center không chui vào túi.
Túi chỉ có thêm remote control cho data center và agent.
2. Vì sao đây là công việc gần cấp senior
Độ khó không chỉ nằm ở số dòng code.
Loại thay đổi này đòi hỏi hiểu kiến trúc hiện tại, tránh cài đặt trùng, bảo vệ đường production, hiểu biên giữa scheduler/GitHub/CI/publishing, nối logic mới vào central loop, bảo vệ privacy, không coi dữ liệu thiếu là số 0, thêm test, phân biệt lỗi code với lỗi hạ tầng CI và quyết định khu vực nào không được đụng vào.
Đây không chỉ là làm một ticket nhỏ. Nó là quản lý blast radius của thay đổi trong một hệ thống đang sống.
Nếu là con người, nó gần với senior backend hoặc Platform Engineer. Nếu chịu trách nhiệm kiến trúc toàn hệ thống, một phần judgment tiến gần Staff Engineer.
Cái khó không chỉ là viết code thông minh.
Mà là biết code thông minh được phép nằm ở đâu mà không gây tai nạn.
3. Thay đổi thực tế lớn đến đâu
Trong một ví dụ đã ẩn danh, PR chính có 11 file thay đổi, 13 commit, khoảng 895 dòng thêm mới, cùng runtime germination tự động, bảo vệ Article DNA, behavioral learning, feedback có giới hạn vào tối ưu internal link, test và định nghĩa CI riêng.
Sau merge vẫn còn việc. Các gate bổ sung ngăn behavioral learning tự sửa graph production trước khi xác minh, còn telemetry thiếu được giữ là UNKNOWN thay vì âm thầm thành 0.
Vì vậy đây không phải “công việc 895 dòng”.
Mà là hiểu hệ thống trước khi viết 895 dòng, rồi làm thêm một cái lồng để 895 dòng đó không chạy loạn sau đó.
Số dòng code là thước đo rất kém. Một trăm dòng có thể xóa database. Mười nghìn dòng có thể chỉ là một máy tính cực kỳ nhiệt tình.
4. Con người sẽ mất bao lâu
Với một kỹ sư giỏi nhưng lần đầu vào repository, ước lượng 5–15 person-days cho cùng phạm vi trách nhiệm là hợp lý.
Bao gồm đọc code và quy tắc vận hành, thiết kế, implementation, test, chẩn đoán CI/hạ tầng, review và kiểm tra ảnh hưởng production.
Gõ code có thể nhanh hơn.
Nhưng trong production, chứng minh rằng bạn không làm hỏng thứ gì đôi khi tốn hơn cả viết thay đổi.
IPA của Nhật giải thích rằng nếu không có định nghĩa khác, một person-month có thể quy đổi thành 160 person-hours: 8 giờ × 20 ngày.[1]
Do đó 5–15 person-days tương đương khoảng 0,25–0,75 person-month.
5. Nếu thuê người thì giá bao nhiêu
Không có giá duy nhất. Loại hợp đồng, phạm vi trách nhiệm, hiểu biết hệ thống, review và bảo đảm production đều ảnh hưởng.
Nhưng giá công khai cho thấy quy mô.
Levtech cho biết thuê IT consultant freelance toàn thời gian 5 ngày/tuần ở mức khoảng 1,0–1,1 triệu yên/tháng, dựa trên dữ liệu tháng 7/2025.[2]
Chia đơn giản cho 20 ngày làm việc là khoảng 50.000–55.000 yên/ngày. Với 5–15 person-days, chi phí lao động trực tiếp khoảng 250.000–825.000 yên.
Hợp đồng thực tế có thể cao hơn vì PM, review, rủi ro làm lại, bảo hành, overhead và margin.
Vì vậy khó có thể gọi đây là “việc nhỏ vài nghìn yên”.
Nhưng nói “AI kiếm được 800.000 yên” cũng sai. Tốc độ, song song, kiểu thất bại, chi phí giám sát và tool của AI khác con người.
Kết luận hữu ích hơn là: công việc có thể ngốn nhiều ngày hoặc nhiều tuần của kỹ sư trình độ cao giờ có thể được khởi động bởi một người từ thiết bị rất nhỏ.
6. AI chạy 6 giờ có bằng senior engineer 6 giờ không
Không.
AI không nghỉ, không bị kéo vào họp, không mất thời gian bởi notification và không nhìn trần nhà hỏi ai đã duyệt architecture này.
Nhưng nó có thể đi rất nhanh theo giả định sai, hiểu sai production state, nhầm lỗi runner với lỗi code, mở rộng quyền hoặc nhầm “có test” với “test thật sự pass”.
Vì vậy hãy đánh giá thay đổi hoàn tất, bằng chứng, xác minh và production readback, không chỉ theo đồng hồ.
“Chạy 6 giờ mà vẫn làm, khá bền” thì được.
“Chạy 6 giờ nên đúng suốt 6 giờ” thì không.
7. Nếu người dùng không tự code được thì sao
Vai trò thay đổi.
Trước đây, một ý tưởng thường đòi hỏi học Git, ngôn ngữ, framework, deploy và testing trước khi trở thành software.
AI agent giảm ma sát triển khai đó.
Công việc giá trị cao của con người dịch chuyển sang: xây gì, vì sao, thứ gì tuyệt đối không được hỏng, cho phép tự động sửa tới đâu, thế nào là thành công, cái gì phải giữ UNKNOWN và khi nào một lỗi nên dừng toàn hệ thống hay chỉ bị cô lập.
“Có thể tự viết mọi dòng code” không còn là tấm vé duy nhất.
Nhưng hiểu kỹ thuật vẫn quan trọng. Càng hiểu mục tiêu, rủi ro, dependency và verification, chỉ dẫn càng tốt.
Không cần tự đúc động cơ để lái xe.
Nhưng vẫn phải biết đèn đỏ nghĩa là gì.
8. Vì sao “cứ giao hết cho AI” nguy hiểm
Lỗi đáng sợ nhất không phải màn hình error.
Mà là sai trong khi trông như đã thành công.
PR có thể merged nhưng chưa lên production; file CI có thể tồn tại nhưng runner chưa bắt đầu step nào; dữ liệu unavailable có thể bị coi là 0; logic mới và cũ có thể chạy cùng lúc; “safety” có thể tắt toàn bộ automation; “autonomy” có thể mở quyền quá rộng.
Automation tốt không chỉ là thứ tiếp tục chạy.
Nó phải phân biệt fact và trạng thái chưa verify trong khi vẫn chạy.
9. Cách ủy quyền an toàn hơn từ điện thoại
Xác định kết quả trước
Đừng chỉ nói “sửa file này”. Hãy nói điều gì phải đúng khi hoàn tất.
Viết invariants
Chức năng hiện có, privacy, quy tắc hình ảnh, đường publish, SEO và những gì không được phá.
Xác định quyền
Có được overwrite, mở PR, merge hay sửa production không.
Đọc trạng thái hiện tại trước
Ưu tiên current main, runtime thật và public state thật hơn cuộc trò chuyện cũ.
Tính verification vào deliverable
“Đã viết code” không phải hoàn tất. Test, CI và production readback có thể là điều kiện.
Cho phép UNKNOWN
Đừng ép thứ chưa biết thành PASS hoặc FAIL.
Màn hình điện thoại nhỏ.
Trách nhiệm của specification thì không.
10. Kết luận — có lẽ thứ bị phá là rào cản gia nhập cũ
Một người không thể tự viết advanced production code giờ có thể điều khiển AI agent hàng giờ từ điện thoại và tích hợp thay đổi có judgment cấp senior vào GitHub.
Vài năm trước câu này nghe rất lạ.
Giờ nó có thể là thực tế vận hành.
Điều đó không có nghĩa kỹ sư hết cần thiết.
Một phần giá trị engineering đang dịch chuyển từ implementation thủ công sang architecture, constraints, verification và ranh giới trách nhiệm.
AI không xóa giá trị.
Nó đổi vị trí của giá trị.
Và thay đổi lớn nhất có thể là người từng dừng ở “về kỹ thuật tôi không làm được” giờ có thể bắt đầu sớm hơn một câu hỏi:
“Vậy chúng ta nên xây cái gì?”
Smartphone vẫn chỉ là một tấm kính.
Nhưng tấm kính đó có thể trở thành remote control cho tài nguyên engineering cấp senior.
Đúng là thế giới hơi “hỏng”.
Nhưng theo một cách khá thú vị.
- IPA, FAQ Software Development Data White Paper. Quy đổi mặc định 1 person-month=160 person-hours (8×20) ipa.go.jp
- Levtech, hướng dẫn chi phí IT consultant, cập nhật 2026-08-18. Khoảng ¥1,0–1,1 triệu/tháng cho freelance IT consultant full-time dựa trên dữ liệu 7/2025 levtech.jp
