Một điều tôi nhận thấy trong các tổ chức kỹ thuật mà tôi từng làm việc là khi nhận được một vấn đề, bước đầu tiên của mọi người thường là mở editor, tạo branch mới và bắt đầu viết code. Tôi luôn cảm thấy đây là hướng đi sai.
Sau hơn hai mươi năm xây dựng phần mềm trong nhiều lĩnh vực khác nhau, tôi nhận ra rằng những kỹ sư mang lại giá trị lớn nhất cho dự án và công ty không phải là những người viết code nhiều nhất. Những người tạo ra giá trị cao nhất là những người bắt đầu bằng việc suy nghĩ, đặt câu hỏi, phản biện yêu cầu, phân tích và lập kế hoạch. Đôi khi, trong quá trình đó, họ nhận ra rằng thậm chí không cần viết code. Và đó mới là kết quả tốt nhất.
Thói quen này rất có giá trị. Và trong năm nay, khi AI có thể viết code nhanh hơn con người, việc tạo ra giá trị mà không chỉ dựa vào code lại càng trở nên quan trọng hơn.
Cụ thể, chúng ta sẽ nói về:
- Cái bẫy danh tính (identity trap). Sai lầm phổ biến là coi kỹ sư phần mềm là người tạo ra code. Điều này làm lệch trọng tâm khỏi mục tiêu, ý định và tác động thực sự của công việc.
- Code là một khoản nợ, không phải tài sản. Mỗi dòng code đều cần được bảo trì, hiểu và thay đổi. Mục tiêu thực sự không phải là viết nhiều hơn, mà là giải quyết vấn đề với ít code nhất.
- Điều gì xảy ra khi bạn bỏ qua việc suy nghĩ. Rất dễ giải quyết sai vấn đề nếu nhảy thẳng vào triển khai.
- Tại sao chúng ta lại mặc định viết code. Incentive, deadline, cách tổ chức... đều thúc đẩy hành vi code-first.
- AI khiến điều này tệ hơn. Khi code trở nên rẻ, chúng ta dễ tạo ra nhiều code không cần thiết hơn.
- “Thinking-first” thực sự trông như thế nào. Cách làm rõ vấn đề trước khi code bằng note ngắn, tài liệu nhẹ, feedback và prototype.
- Công việc thực sự của một kỹ sư. Không phải viết code, mà là phán đoán, đánh đổi, kiến trúc và quyết định cái gì không nên xây.
Hãy đi sâu hơn.
1. Cái bẫy danh tính
Ý tưởng cho rằng một kỹ sư phần mềm chỉ giỏi khi họ viết nhiều code là hoàn toàn sai. Nhiều người đánh giá dựa trên số dòng code, số pull request, hay số feature đã ship. Nếu theo cách này, một chương trình có thể viết code cũng đã là kỹ sư phần mềm — và trong thời đại AI, điều đó càng vô lý.
Một kỹ sư phần mềm không bắt đầu bằng việc chọn công cụ. Họ bắt đầu bằng câu hỏi:
- Chúng ta đang cố giải quyết vấn đề gì?
- Ai là người bị ảnh hưởng?
- Tại sao việc này quan trọng?
- Nếu không làm, điều gì sẽ xảy ra?
Developer thì viết code. Kỹ sư phần mềm thì suy nghĩ về kết quả.
Viết code là làm cho nó chạy. Nhưng engineering là làm cho hệ thống có thể chịu được vấn đề, dễ hiểu, dễ sửa, và người khác có thể tiếp tục phát triển. Đó là việc nhìn toàn bộ hệ thống, không chỉ từng dòng code riêng lẻ.
Code chỉ là một phần của giải pháp
2. Code là một khoản nợ, không phải tài sản
Chúng ta cần hiểu điều này ngay từ đầu. Dù công việc xoay quanh code, chúng ta cần code — chứ không phải muốn code. Vì mỗi dòng code đều phải được bảo trì, hiểu và thay đổi trong tương lai. Không có gì là miễn phí.
Code chỉ có giá trị khi thứ nó tạo ra mang lại nhiều hơn chi phí duy trì nó.
Phần lớn code không đạt tới mức đó. Capability là tài sản, nhưng code là cái giá phải trả để có capability đó. Mục tiêu là đạt được giá trị kinh doanh với ít code nhất.
Jeff Atwood từng nói: “Code tốt nhất là không có code.”
Code bạn không viết sẽ không có bug, không cần test, không cần bảo trì. Nếu bạn giải quyết vấn đề bằng cách xóa code, thay đổi quy trình hoặc dùng tool có sẵn — bạn đã làm rất tốt.
Đây không phải là chống lại việc viết code. Mà là biết khi nào nên viết.
Viết nhiều code không phải là mục tiêu
3. Điều gì xảy ra khi bạn bỏ qua việc suy nghĩ
Ví dụ: ticket ghi “checkout chậm, cần tối ưu performance”.
Kỹ sư A mở code, tối ưu query DB, thêm index. Xong.
Ba tuần sau, ticket mở lại. Người dùng vẫn bỏ checkout.
Vấn đề thực sự không phải là tốc độ — mà là form quá dài.
Kỹ sư A giải quyết đúng thứ… nhưng sai vấn đề.
Kỹ sư B thì khác. Trước khi code, họ kiểm tra data, đọc feedback, nói chuyện với support. Họ viết:
“Người dùng rời bỏ ở bước thanh toán vì form quá dài. Nếu rút gọn form, tỷ lệ hoàn tất sẽ tăng.”
Kết quả: +18% conversion, chỉ 40 dòng code.
Kỹ sư A code nhanh. Kỹ sư B giải quyết đúng vấn đề.
💡 Hàng tuần code có thể tiết kiệm vài giờ suy nghĩ.
4. Tại sao chúng ta lại mặc định viết code
Thực tế là chúng ta thường bắt đầu bằng code vì đó là cách công việc kỹ thuật được đo lường và khen thưởng.
Chúng ta đo bằng việc hoàn thành task nhanh đến đâu, không phải bằng việc tránh được bao nhiêu vấn đề. Việc thăng tiến thường dựa trên số lượng feature đã ship, hơn là mức độ đơn giản hóa hệ thống. Không ai được khen vì xóa code hay làm mọi thứ đơn giản hơn — dù điều đó tốt hơn cho hệ thống.
Đây là một ví dụ điển hình của Goodhart's Law: khi một chỉ số trở thành mục tiêu, nó không còn là chỉ số tốt nữa.
Đây không chỉ là vấn đề cá nhân, mà là vấn đề tổ chức. “Tiến độ” thường được hiểu là đang viết code. Thời gian bắt đầu tính từ lúc nhận task, nên kỹ sư lao vào code trước khi hiểu rõ vấn đề. Tổ chức thưởng cho hành vi đó, và cuối cùng chúng ta có những thứ không giải quyết đúng vấn đề.
AI chỉ làm điều này diễn ra nhanh hơn.
Ngược lại, ở những team có giao tiếp tốt và hiểu rõ người dùng, vấn đề thường được hiểu đúng ngay từ đầu. Điều này khó hơn trong các tổ chức lớn, nơi một dòng code phải đi qua nhiều tầng để thấy được tác động thực tế.
Chỉ tập trung vào code
5. AI khiến vấn đề này nghiêm trọng hơn
Các công cụ AI giúp việc tạo code trở nên cực kỳ dễ dàng. Một kỹ sư giỏi có thể tạo ra bản prototype trong vài phút — thứ trước đây mất hàng giờ.
Nghe có vẻ tốt, nhưng điều quan trọng là: điều gì xảy ra trước khi bạn dùng AI?
Hãy tưởng tượng AI như một người thực thi cực nhanh. Nếu bạn đưa yêu cầu rõ ràng, họ sẽ làm rất tốt. Nếu bạn không rõ mình muốn gì, họ vẫn sẽ làm — nhưng là làm sai.
AI không thể biết nó đang làm đúng hay sai. Chỉ kỹ sư mới có thể đánh giá điều đó.
Một nghiên cứu năm 2025 của METR cho thấy: các developer nghĩ họ nhanh hơn 24% khi dùng AI, sau đó cảm thấy nhanh hơn 20%, nhưng thực tế lại chậm hơn 19%. Nguyên nhân chính là kỳ vọng quá mức và độ tin cậy chưa cao của AI.
Nghiên cứu về năng suất developer với AI
Ngoài ra, GitClear phân tích 153 triệu dòng code và phát hiện rằng khi dùng AI, lượng code copy tăng gấp 4 lần và code bị thay đổi thường xuyên hơn.
Chúng ta đang tạo ra nhiều code hơn — nhưng không chắc đó là code cần thiết.
AI ngày càng tốt hơn, nhưng việc quyết định code nào nên tồn tại vẫn là trách nhiệm của con người.
Khi kỹ sư suy nghĩ kỹ trước khi dùng AI, kết quả sẽ khác. AI giúp kỹ sư giỏi trở nên mạnh hơn — chứ không làm mọi người ngang nhau.
6. “Thinking-first” thực sự trông như thế nào
Nói “nghĩ trước khi code” dễ bị hiểu sai thành nhiều họp và tài liệu dài dòng. Nhưng vấn đề không phải là paperwork — mà là hiểu đúng vấn đề.
Nếu bạn giao việc giải quyết vấn đề cho AI, bạn đang bỏ qua phần “tại sao” và nhảy thẳng vào “làm thế nào”. Khi đó, AI chỉ giúp bạn đi nhanh hơn theo hướng sai.
Các nghiên cứu gần đây từ Anthropic cũng xác nhận điều này.
Hiện tại, mọi người đang quá tập trung vào execution, mà quên mất thinking và decision-making. Trong tương lai, việc định nghĩa vấn đề và sản phẩm sẽ quan trọng hơn implementation.
Cách tôi thường làm:
Trước khi code, tôi viết một đoạn ngắn trả lời:
- Vấn đề thực sự là gì?
- Ai bị ảnh hưởng?
- Khi nào thì coi là đã giải quyết xong?
Một nửa số lần, chỉ cần viết ra là tôi phát hiện ra vấn đề mình chưa hiểu đúng.
Với project lớn hơn, tôi viết một tài liệu ngắn để:
- Xác định vấn đề: hiểu rõ mình đang giải cái gì
- Hiểu business: quyết định kỹ thuật cũng là quyết định kinh doanh
- Phân rã (decompose): loại bỏ chi tiết không cần thiết
- Lập kế hoạch: suy nghĩ trước khi hành động
- Giao tiếp: đảm bảo mọi người hiểu giống nhau
- Prototype: test giả định nhanh với chi phí thấp
Amazon có quy trình Working Backwards, yêu cầu viết press release trước khi viết code. Mục tiêu là loại bỏ những ý tưởng không đáng làm — và phần lớn ý tưởng nên bị loại bỏ.
7. Công việc thực sự của một kỹ sư
Năm 2026, công việc của kỹ sư phần mềm không phải là viết nhiều code nhanh hơn. Mà là hiểu vấn đề và xác định thứ thực sự cần xây.
Điều này bao gồm:
- Chuyển ý tưởng thành yêu cầu kỹ thuật rõ ràng
- Đặt câu hỏi mà người khác không nghĩ tới
- Quyết định build hay buy
- Biết khi nào nên bỏ qua
Mỗi feature đều là một rủi ro. Bạn phải cân nhắc lợi ích có đáng với chi phí bảo trì không.
Tiếp theo là judgment về kiến trúc. Nếu sai ở giai đoạn này, chi phí sửa rất lớn.
Kỹ sư cũng cần kiểm tra code do AI tạo ra — giống như review code của một junior. AI không hiểu context, nên vẫn cần con người validate.
Đôi khi, việc tốt nhất bạn có thể làm là xóa code.
AI có thể viết code, nhưng không thể quyết định nên viết gì. Nó không thể cân nhắc trade-off hay hiểu business. Đó là phần khó — và vẫn là việc của con người.
Kỹ năng coding vẫn quan trọng. Nhưng giờ đây, nó là:
- Biết khi nào cần code
- Biết code nào có giá trị
- Hiểu hệ thống hoạt động như một tổng thể
Nhìn rộng hơn, vai trò của kỹ sư đang dịch chuyển từ “người thực thi” sang “người ra quyết định”. Bạn không còn được đánh giá chỉ bằng tốc độ viết code, mà bằng chất lượng của những quyết định bạn đưa ra trước khi viết bất kỳ dòng code nào.
Điều này cũng đồng nghĩa với việc trách nhiệm tăng lên. Bạn không chỉ chịu trách nhiệm về việc “code có chạy hay không”, mà còn về việc “có nên viết đoạn code đó ngay từ đầu hay không”.
Trong bối cảnh AI ngày càng mạnh, sự khác biệt giữa một kỹ sư giỏi và một kỹ sư trung bình không còn nằm ở khả năng viết code nhanh, mà nằm ở:
- Khả năng đặt đúng câu hỏi
- Khả năng hiểu đúng vấn đề
- Khả năng đưa ra quyết định hợp lý
- Khả năng nói “không” với những thứ không cần thiết
Đây là những kỹ năng mà AI chưa thể thay thế.
Vì vậy, nếu bạn vẫn nghĩ rằng công việc của mình là “viết code thật nhanh”, bạn đang tối ưu cho một thứ ngày càng ít giá trị hơn.
Thứ có giá trị thực sự là:
- Hiểu rõ hệ thống và người dùng
- Giảm thiểu độ phức tạp
- Tối ưu trade-off giữa tốc độ, chi phí và chất lượng
- Đưa ra quyết định đúng ngay từ đầu
Viết code vẫn là một phần quan trọng — nhưng nó không còn là trung tâm nữa.
Bạn không được trả tiền để viết code.
Bạn được trả tiền để giải quyết vấn đề.