Is Being Good at Coding Enough to Grow in the IT Industry?

Một sáng thứ Hai bình thường của năm 2026Bạn mở máy lên. Trước mặt là một task: viết API endpoint xử lý upload file, validate định dạng, lưu vào S3, trả về presigned URL.Năm 2020, task này mất của bạn nửa buổi sáng — tra docs, viết boilerplate, debug edge case.Năm 2025, bạn mở Claude Code, gõ một đoạn mô tả ngắn, nhận lại code hoàn chỉnh trong 40 giây. Review qua, chỉnh vài dòng business logic, done.Câu hỏi đặt ra không phải là "AI có thay thế developer không?" — câu đó đã được tranh luận quá nhiều và quá nhàm. Câu hỏi thực sự là:Khi phần "code" trong công việc của bạn ngày càng được AI hỗ trợ nhiều hơn, thứ gì còn lại mới thực sự là giá trị của bạn? "Code Giỏi" Từng Có Nghĩa Là GìHãy thành thật với nhau một chút.Trong suốt hai thập kỷ trước, "code giỏi" đồng nghĩa với một tập hợp kỹ năng rất cụ thể:Thuộc lòng syntax của ngôn ngữViết algorithm nhanh, sạch, ít bugDebug được những lỗi khó hiểuNhớ được API của các thư viện phổ biếnTối ưu performance theo bản năngNhững kỹ năng này có giá trị thật. Và chúng được thị trường trả giá tốt — vì chúng khan hiếm, vì không phải ai cũng bỏ công học được.Nhưng "khan hiếm" là từ khóa quan trọng ở đây.Giá trị của một kỹ năng gắn liền với mức độ khan hiếm của nó. Và trong năm 2025, khả năng viết code thuần túy — đặc biệt là code có tính chất boilerplate, lặp đi lặp lại, theo pattern — đang dần trở nên kém khan hiếm hơn. Không phải vì developer giỏi hơn. Mà vì AI đang làm được phần đó.AI Đang Làm Tốt Chính Xác Những GìĐể không rơi vào cực đoan — hoặc "AI thay thế tất cả" hoặc "AI chỉ là công cụ đơn giản" — hãy nhìn thẳng vào thực tế.Những gì AI làm tốt (và đang ngày càng tốt hơn):Viết code theo pattern đã biết. CRUD endpoint, form validation, database query cơ bản, unit test, boilerplate config — đây là địa phận AI thống trị. Nếu task của bạn có thể mô tả bằng một paragraph rõ ràng và có câu trả lời "đúng" tương đối xác định, AI làm được.Debug lỗi phổ biến. Stack trace rõ ràng? Error message có nghĩa? AI đọc và giải thích nhanh hơn hầu hết junior developer.Chuyển đổi format và refactor cơ học. Đổi từ callback sang async/await. Migrate từ class component sang hook. Format lại JSON. Viết regex. Những task mà trước đây mất hàng giờ vì nhàm chán và cần sự tỉ mỉ — AI làm trong giây lát.Tra cứu và tổng hợp tài liệu. Thay vì đọc 5 trang docs để hiểu một API, bạn hỏi AI và nhận lại đúng phần mình cần, kèm ví dụ.Và đây là con số đáng chú ý:Theo khảo sát của Stack Overflow Developer Survey 2024, hơn 76% developer đang sử dụng hoặc có kế hoạch sử dụng AI tools trong workflow. GitHub Copilot báo cáo developer viết code nhanh hơn 55% khi dùng tool của họ.55% nhanh hơn. Nghĩa là công việc mà trước đây bạn làm trong 2 giờ, giờ mất 1 giờ 20 phút. Thời gian còn lại bạn làm gì?Đây chính là câu hỏi quan trọng nhất.Vùng AI Chưa Chạm Tới — Và Có Lẽ Không Bao Giờ Chạm Tới Hoàn ToànĐây là phần nhiều người bỏ qua khi tranh luận về AI và developer.AI rất giỏi trả lời câu hỏi. Nhưng AI không tự đặt ra câu hỏi đúng.1. Hiểu Business Context để Đặt Vấn Đề ĐúngMột khách hàng đến gặp bạn và nói: "Tôi cần một cái form để người dùng submit yêu cầu."Developer bình thường sẽ hỏi: form cần những field gì, validate thế nào, lưu vào đâu.Developer giỏi sẽ hỏi: "Submit yêu cầu xong thì chuyện gì xảy ra? Ai review? Có SLA không? Người dùng cần track status không? Volume dự kiến bao nhiêu submission/ngày?"Và sau khi nghe câu trả lời, developer giỏi có thể nói: "Thực ra cái bạn cần không phải là một form. Bạn cần một mini workflow engine."AI không làm được điều này — không phải vì thiếu thông minh, mà vì AI không có skin in the game. AI không biết rằng cái form đó sẽ ảnh hưởng đến 500 nhân viên kế toán. AI không cảm nhận được sự căng thẳng trong giọng khách hàng khi nhắc đến deadline cuối quý.Đặt câu hỏi đúng — không phải trả lời đúng — là kỹ năng phân biệt người xây hệ thống với người thực thi task.2. Phán Đoán Trade-off Trong Bất ĐịnhMọi quyết định kỹ thuật thực sự đều là trade-off:Dùng microservice hay monolith cho startup 5 người?Cache aggressive để tăng tốc độ, hay chấp nhận stale data một phần?Viết abstraction layer đẹp, hay ship nhanh rồi refactor sau?Thuê thêm người hay dùng serverless để scale?Không có câu trả lời "đúng" tuyệt đối cho những câu hỏi này. Câu trả lời phụ thuộc vào: team size hiện tại, runway của công ty, technical debt có thể chịu được, ưu tiên của business tuần này.AI có thể liệt kê pros/cons của mỗi lựa chọn. Nhưng AI không thể chịu trách nhiệm cho quyết định. Và chính sự chịu trách nhiệm đó — khả năng nói "tôi chọn cái này, vì lý do này, và tôi đứng sau quyết định đó" — là thứ tạo ra trust trong team.3. Giao Tiếp Với Người Không Phải DeveloperMột trong những kỹ năng được underrate nhất trong ngành IT: giải thích kỹ thuật cho người không kỹ thuật.Không phải giải thích theo kiểu "à thực ra cái này đơn giản lắm..." rồi tiếp tục dùng jargon. Mà là thực sự dịch được vấn đề kỹ thuật sang ngôn ngữ của business: rủi ro, chi phí, thời gian, impact."Nếu chúng ta không refactor cái module này bây giờ, mỗi feature mới sẽ tốn thêm 30% thời gian develop. Trong 6 tháng tới với roadmap hiện tại, điều đó nghĩa là chúng ta chậm khoảng 3 tuần so với kế hoạch."Câu đó có giá trị hơn nhiều so với: "Technical debt đang tăng và codebase khó maintain."AI có thể giúp bạn soạn câu đó. Nhưng AI không biết roadmap 6 tháng tới của công ty bạn. Không biết sếp của bạn quan tâm đến metric nào nhất. Không biết rằng 3 tuần chậm là ngưỡng mà sếp sẽ bắt đầu lo lắng thật sự.4. Ownership — Thứ Không Thể OutsourceOwnership là gì?Ownership không phải là "tôi viết code cho feature này." Ownership là "feature này có chạy đúng không là trách nhiệm của tôi — từ lúc bắt đầu thiết kế đến lúc user không còn complain nữa."Developer có ownership sẽ:Hỏi lại requirement khi thấy ambiguous, không làm theo hiểu sai rồi đổ lỗi sauProactive monitor sau khi deploy, không chờ bị báo bugNghĩ đến edge case mà không ai yêu cầu phải nghĩKhi có vấn đề, đến với giải pháp thay vì chỉ đến với vấn đềĐây là thứ mà không AI nào làm thay được. Và đây cũng là thứ phân biệt rõ nhất những người được thăng tiến với những người không được.Vậy "Code Giỏi" Năm 2026 Có Nghĩa Là GìĐây là luận điểm cốt lõi của bài này.Định nghĩa của "code giỏi" không biến mất. Nó đang được nâng tầm.Trước đây: Code giỏi = viết được code chạy đúng, nhanh, ít bug.Bây giờ: Code giỏi = dùng AI nhân lên năng lực của mình để tạo ra impact lớn hơn nhiều lần.Đây là sự khác biệt:Developer thời cũDeveloper thời AITự viết mọi thứ từ đầu | Biết cái gì nên tự viết, cái gì để AI làmGiá trị = số dòng code | Giá trị = chất lượng quyết địnhNgại dùng tool vì "mất đi cảm giác coding" | Xem AI là force multiplierDeep expert trong một stack | T-shaped: deep + broadCode là đích đến | Code là phương tiệnNói cách khác: developer giỏi năm 2025 không phải là người code nhiều nhất. Mà là người tạo ra kết quả tốt nhất với nguồn lực ít nhất — và AI là một trong những nguồn lực đó.Ba Kỹ Năng Bạn Cần Đầu Tư Ngay Bây GiờNói lý thuyết đủ rồi. Cụ thể bạn cần làm gì?Kỹ năng 1: System Thinking — Tư Duy Hệ ThốngHọc cách nhìn vấn đề ở nhiều tầng cùng lúc:Tầng code: cái này implement thế nàoTầng system: cái này ảnh hưởng đến các component khác thế nàoTầng business: cái này giải quyết được vấn đề gì của người dùng cuốiDeveloper hay bị mắc kẹt ở tầng code. Để lên senior và xa hơn, bạn phải di chuyển được giữa cả ba tầng một cách tự nhiên.Cách luyện: Khi nhận một task, trước khi code, hãy tự hỏi: "Task này tồn tại vì business reason gì? Nếu tôi làm sai, điều tệ nhất có thể xảy ra là gì?"Kỹ năng 2: Communication — Không Phải Nói Hay, Mà Là Nói ĐúngHọc cách viết rõ ràng: ticket, PR description, comment trong code, email update cho stakeholder.Học cách đặt câu hỏi thay vì đưa ra giải pháp ngay. Câu hỏi tốt thường có giá trị hơn câu trả lời tốt.Học cách nói "không" — hoặc đúng hơn là "có, nhưng" — khi deadline không thực tế hoặc requirement mâu thuẫn nhau.Cách luyện: Viết. Mọi thứ. PR description đầy đủ thay vì "fix bug". Comment giải thích tại sao thay vì cái gì. Retrospective note sau mỗi sprint.Kỹ năng 3: Prompt Engineering + Critical Review — Cộng Sinh Với AIĐây là kỹ năng mới nhất nhưng đang trở thành yêu cầu bắt buộc.Biết cách prompt AI để ra output có ích. Không phải hỏi "viết cho tôi một cái API" mà là: "Tôi cần một REST endpoint với những constraints này, edge cases này, phải tương thích với codebase đang dùng pattern này..."Nhưng quan trọng hơn: biết review code AI tạo ra một cách phê phán. AI không sai hoàn toàn, nhưng AI hay:Bỏ sót edge case trong domain cụ thểDùng pattern cũ hoặc không phù hợp với contextViết code chạy được nhưng không maintainableTự tin quá mức vào giải pháp không tối ưuDeveloper giỏi dùng AI như một junior developer rất nhanh — cần review kỹ, cần hướng dẫn rõ, nhưng có thể delegate những task routine để tập trung vào việc quan trọng hơn.Một Cảnh Báo Quan TrọngCó một bẫy mà nhiều developer đang rơi vào khi tiếp cận AI: dùng AI để tránh né sự khó chịu của việc tư duy.Khi gặp vấn đề khó, reflex tự nhiên là hỏi AI ngay. AI trả lời. Bạn copy-paste. Done.Nhưng bằng cách đó, bạn đã bỏ lỡ đúng cái phần quan trọng nhất: quá trình vật lộn với vấn đề, hiểu tại sao nó khó, và xây dựng mental model để lần sau gặp vấn đề tương tự bạn tư duy được mà không cần công cụ.AI nên là công cụ để nhân lên năng lực sau khi bạn đã hiểu vấn đề — không phải công cụ để né tránh việc hiểu vấn đề.Nếu bạn không hiểu tại sao đoạn code AI viết ra lại đúng, bạn đang tích lũy nợ kiến thức. Và nợ đó sẽ đến hạn vào đúng lúc bạn không muốn nhất.Câu Hỏi Bạn Nên Tự Hỏi Mỗi TuầnKhông phải: "Tôi đã viết bao nhiêu dòng code tuần này?"Mà là: "Tuần này tôi đã ra được những quyết định nào? Tôi đã giải quyết được vấn đề gì mà nếu không có tôi thì sẽ không được giải quyết — hoặc giải quyết kém hơn?"Đó là thứ tạo ra giá trị thực sự. Và đó là thứ — cho dù AI có tiến bộ đến đâu — vẫn cần đến bạn.Code giỏi không còn là đích đến. Nó là ngưỡng cửa.Câu hỏi là: sau khi bước qua ngưỡng cửa đó, bạn mang theo gì?

AI có thể code.AI có thể generate workflow.AI có thể viết SQL.Nhưng AI chưa thể khiến một đội sales bỏ Excel để dùng CRM.Tôi chưa từng học IT.Nhưng tôi đã triển khai CRM, hệ thống đặt lịch và LMS cho startup của mình.Hồi làm cho một start-up, tôi ở vị trí vận hành (back office) kiêm đủ thứ vai trong đó có quản lý đội sales. Điều làm tôi đau đầu nhất ngoài việc ra các chính sách bán hàng còn là quản lý các đơn hàng, doanh số. File excel dùng chung hay gặp sự cố khi ai cũng điều chỉnh được, số liệu thiếu, sai ở đâu khó mà truy vết. Bao nhiêu đội sales là bấy nhiêu file phải đối chiếu đến mờ mắt, vào lúc flash sales thì đó là ác mộng.Tôi không muốn quản lý thủ công vậy nữa. Việc quản lý ngày càng nhiều càng cần hệ thống tự động.Rồi tôi tìm đến CRM. Ai làm start-up đều hiểu, ngân sách hạn chế, nhân lực kiêm nhiệm, một phần mềm rẻ, đơn giản, ít tốn công là ưu tiên. Tôi tìm thấy một CRM mini thỏa đủ các yêu cầu sau khi tìm hiểu không ít loại trên thị trường. Nó đáp ứng đủ tiêu chí: rẻ - đơn giản - có giao diện tiếng Việt - ít cài đặt. Một mình tôi cân hết từ thiết lập hệ thống, quy trình, hướng dẫn sử dụng, chạy thử, đưa vào vận hành, tinh chỉnh cho đến khi dùng mượt mà. Không đụng đến một dòng code.Thay đổi một thói quen không dễ. Ứng dụng công nghệ vào công việc cũng vậy.“Vẫn thấy dùng Excel ổn mà,” “Gì mà phải nhập liệu lại từ đầu mắc công vậy?” “Mình không quen dùng,…”Dựng hệ thống không mệt bằng thuyết phục người dùng dùng hệ thống.CRM triển khai tuần đầu gần như không ai dùng.Tôi nghiên cứu, tìm kiếm bằng chứng để thuyết phục đội sales, cho họ dùng thử, hỏi cảm nhận, rồi lại trấn an. Một tuần, hai tuần có lai rai vài phản ánh, rồi một tháng, ai cũng thấy hiệu quả khi quản lý được doanh số, khách hàng và đội nhóm, hệ thống dần được chấp nhận.Tôi còn thêm vào quy trình gửi thư xác nhận thanh toán tự động cho kế toán, mô phỏng theo quy trình có sẵn trên hệ thống.Bạn nghĩ tôi học IT mới biết cách làm vậy sao? Không, tôi học Công nghệ Thực phẩm ra.Theo đà phát triển, start-up tôi mở phòng khám trị liệu online. Tránh việc quản lý thủ công đặt lịch trên Excel hay Calendar cho cả khách hàng và trị liệu viên, tôi lại muốn tự động hoá càng nhiều càng tốt. Không chỉ cho quản lý mà còn tăng trải nghiệm khách hàng nữa.Tôi lại lao vào tìm kiếm, demo và chọn được cái ưng ý. Phần mềm tiếng Anh, tôi đọc nát hướng dẫn sử dụng, FAQ để thiết lập đúng với yêu cầu mà mình cần. Chạy thử, sửa, làm video hướng dẫn cho cả khách hàng và trị liệu viên, điều chỉnh cho đến khi hệ thống ổn định.Cũng may là lần thứ hai ứng dụng công nghệ và mọi người thấy được lợi ích cho công việc nên phản đối thay bằng chấp nhận và làm theo.Vấn đề vẫn chưa hết.Chúng tôi có năm phòng Zoom để chạy năm lớp, tôi nắm account và thiết lập toàn bộ. Cho đến khi số lượng lớp học tăng lên, việc mở phòng, đăng ghi âm cho học viên trở nên quá tải và cồng kềnh trong khi nhân sự còn mỏng. Thế là tôi lại muốn tự động hoá.Lúc chưa có đội IT vào, tôi thử một hệ thống LMS và thất bại vì có những rủi ro, những lỗi hệ thống tôi không lường được. Quá nhiều yếu tố chi phối khiến tôi hoang mang. Nó không đơn giản như hai hệ thống trước.Lúc có đội IT vào, tôi đỡ việc hơn và hệ thống cũng đi vào hoạt động nhanh hơn. Tôi học được nhiều điều về triển khai từ các bạn ấy.Nắm thông tin lớp học, giảng viên, nội dung giảng dạy, tôi thiết kế bộ khung từng lớp.IT hỏi tôi rất nhiều về hệ thống Zoom cũ, khó khăn của đội admin, trải nghiệm của học viên và giảng viên nên như thế nào, người dùng có rành công nghệ hay không.Tôi không viết một dòng code nào trong dự án đó. Tôi chỉ thử nghiệm, nêu ý kiến cải thiện, và một số yêu cầu.Khi làm việc cùng đội ngũ IT, tôi nhận ra một điều thú vị:Những kỹ sư giỏi luôn dành nhiều thời gian để hiểu sâu vấn đề trước khi xây giải pháp phù hợp.Tôi từng nghĩ giá trị nằm ở công cụ. Sau đó tôi nhận ra giá trị nằm ở khả năng nhìn thấy vấn đề, kết nối con người và biến công nghệ thành thói quen làm việc.Lần triển khai LMS thành công cho lớp đầu tiên, tôi vừa run vừa háo hức.Run vì không biết mọi chuyện có chạy ổn thoả không? Học viên và giáo viên có thấy thoải mái không?Tôi thử dùng nhiều loại account để đảm bảo không có sai sót.Háo hức thật sự vì tôi được giải phóng khỏi công việc admin cồng kềnh, tốn nhiều thời gian. Giờ tôi có thêm khoảng không để sáng tạo thêm những hạng mục khác, nhằm tăng trải nghiệm cho khách hàng và cải tiến dịch vụ.“Chị có học IT không mà biết triển khai hệ thống vậy?” câu khen này tôi nhớ mãi.Ừ thì đâu cần biết dòng code nào, ngôn ngữ lập trình gì mà vẫn đưa công nghệ vào đời sống đó thôi.Khoảng cách giữa người dùng và người code không phải vì kiến thức khác biệt mà là chưa tìm được ngôn ngữ chung để hiểu, để dung hoà được ngôn ngữ lập trình với cách con người vận hành công việc hằng ngày.Con đường phát triển của IT không nhất thiết tuyến tính từ lập trình viên Dev lên Ops rồi Lead. Đôi khi đó chỉ là những con người phiên dịch được ngôn ngữ kỹ thuật thành một thứ hữu dụng và thân thiện với đời sống.Khi AI ngày càng giỏi viết code, tôi càng tin rằng giá trị của con người không nằm ở việc gõ nhanh hơn máy.Giá trị nằm ở việc nhìn thấy vấn đề nào đáng giải quyết, hiểu người dùng nào đang gặp khó khăn và biến công nghệ thành một phần tự nhiên trong công việc hằng ngày.

Khi nhắc đến ngành IT, nhiều người thường nghĩ ngay đến code.Biết nhiều ngôn ngữ lập trình, xử lý được những bài toán khó, viết ra những đoạn code tối ưu — đó chắc chắn là một lợi thế rất lớn.Bản thân tôi cũng từng nghĩ rằng: muốn phát triển trong ngành IT thì điều quan trọng nhất là phải thật giỏi kỹ thuật.Nhưng khi làm QA/Tester, góc nhìn của tôi dần thay đổi.Tôi không phải người viết code nhiều nhất trong team, nhưng để kiểm thử một sản phẩm tốt, tôi nhận ra mình vẫn cần hiểu những gì đang diễn ra phía sau dòng code.Một lỗi có thể không nằm ở giao diện.Nó có thể xuất phát từ logic xử lý, dữ liệu, API hoặc cách các thành phần trong hệ thống kết nối với nhau.Vì vậy, tôi bắt đầu học thêm các kiến thức kỹ thuật như API, SQL và cách hệ thống vận hành.Không phải để trở thành Developer, mà để có thể trao đổi tốt hơn với Developer, hiểu vấn đề sâu hơn và tìm ra nguyên nhân thay vì chỉ nhìn thấy kết quả.Tôi nhận ra một người IT giỏi không chỉ được đánh giá bằng số dòng code viết ra.Một đoạn code tốt cần đi cùng với khả năng hiểu yêu cầu.Một tính năng tốt cần đi cùng với trải nghiệm người dùng.Một sản phẩm tốt cần đi cùng với tư duy giải quyết vấn đề.Đặc biệt khi AI ngày càng phát triển, tôi nghĩ vai trò của kỹ năng kỹ thuật cũng đang thay đổi.AI có thể hỗ trợ viết code nhanh hơn, gợi ý cách xử lý hoặc giúp tự động hóa nhiều công việc.Nhưng AI vẫn cần con người xác định:Bài toán thật sự là gì?Giải pháp nào phù hợp?Kết quả tạo ra có đúng với mục tiêu không?Trong công việc QA, tôi thấy điều này rất rõ.Một công cụ có thể giúp tạo test case nhanh hơn, nhưng việc hiểu sản phẩm, dự đoán rủi ro và đặt đúng câu hỏi vẫn cần tư duy của con người.Tôi cũng nhận ra những kỹ năng tưởng như không liên quan đến code lại ảnh hưởng rất nhiều đến sự phát triển:Khả năng giao tiếp để trao đổi vấn đề.Khả năng học hỏi để thích nghi với công nghệ mới.Khả năng nhìn sản phẩm dưới góc độ người dùng.Theo tôi, code giỏi là một nền tảng quan trọng.Nhưng để thăng tiến trong IT, bạn cần nhiều hơn thế.Bạn cần biết cách biến kiến thức kỹ thuật thành giá trị thực tế.Vì cuối cùng, một người được đánh giá không chỉ bởi việc họ viết được bao nhiêu code, mà bởi họ giúp sản phẩm và đội nhóm tiến lên như thế nào.

Một buổi sáng, cả team dev chỗ tôi nhận thông báo: công cụ AI đang dùng đổi cách tính tiền. Trước đó mỗi người 300 request/tháng, dùng thả ga. Giờ chuyển sang trả theo token — dùng tới đâu tính tiền tới đó. Công ty tính lại chi phí, nên đã chuyển sang một AI agent khác có cách tính tương tự nhưng được đánh giá tốt hơn.Nghe chỉ là chuyện đổi công cụ. Nhưng suy nghĩ đầu tiên trong đầu của tôi là sao lại tăng giá rồi, nó làm tôi nhớ đến một hình ảnh không mấy dễ chịu: rau hẹ được nuôi rồi cắt cũng như gà được nuôi béo chuẩn bị làm thịt.Giai đoạn vỗ béo: khi mọi thứ rẻ đến mức đáng ngờHãy nhớ lại vài năm qua. Công cụ AI rẻ như cho, hào phóng, gần như miễn phí. Hạn mức rộng rãi, model xịn cho dùng thoải mái. Chúng ta vui vẻ "ăn no": mọi task đều mở agent ra trước, code tay thưa dần, và năng suất tăng đều.Nhưng không hãng nào đốt tiền mãi vì lòng tốt. Giá rẻ giai đoạn đầu là để làm một việc: khiến chúng ta quen, rồi lệ thuộc. Khi cả một quy trình làm việc, cả một thói quen tư duy đã gắn chặt vào công cụ, thì việc gỡ ra tốn kém hơn so với việc cắn răng trả thêm tiền. Đó là lúc con gà đã đủ béo.Giai đoạn làm thịt: hóa đơn bắt đầu nói chuyệnVà rồi giá đổi. Với người dùng agent nhiều, chi phí có thể nhảy lên gấp nhiều lần chỉ sau một thông báo. Không cần ai làm gì sai — đơn giản là giai đoạn trợ giá kết thúc, đến lượt thu hồi vón từ các công ty. Đây là quy luật của mọi làn sóng công nghệ, không riêng gì AI.Câu hỏi đáng sợ không phải "công cụ nào rẻ nhất bây giờ", mà là: nếu mai nó tăng giá gấp ba, hoặc công ty cắt quyền truy cập, mình còn code được không?Vậy giỏi code thôi đã đủ để sống sót trong ngành chưa?Tôi nghĩ là chưa — nhưng có lẽ không theo cách nhiều người tưởng.Trước đây "giỏi" nghĩa là viết được code tốt. Giờ AI viết được phần lớn code tốt đó. Nếu năng lực của bạn chỉ là gõ ra dòng lệnh, thì thứ đó đang rẻ đi từng ngày, và bạn cũng đang bị "vỗ béo" để một ngày dễ bị thay thế — bởi công cụ, hoặc bởi người dùng công cụ giỏi hơn.Những thứ không thể rẻ đi, và cũng không ai cắt giá hay thay thế được của bạn, là những thứ AI chưa làm thay: khả năng đọc hiểu một hệ thống, debug khi mọi thứ cháy, đánh giá một giải pháp đúng hay sai, và biết khi nào không nên tin output của agent. Càng dùng AI nhiều, kỹ năng thẩm định này càng quý, chứ không phải càng thừa.Nên định hướng của tôi gói trong ba điều: giữ vững nền tảng (AI viết hộ, nhưng người chịu trách nhiệm khi nó sai vẫn là bạn); tránh khoá cứng vào một nhà cung cấp (ưu tiên giải pháp cho đổi model, mã nguồn mở); và coi AI là đòn bẩy chứ không phải nạng — đòn bẩy giúp người mạnh đi xa hơn, còn nạng khiến người ta quên cách tự đi.Chuyện đổi công cụ ở công ty tôi rồi cũng xong, team thích nghi được. Nhưng câu hỏi nó để lại thì vẫn còn nguyên. Trong một ngành mà công cụ có thể đổi giá sau một đêm, giỏi code là cần, nhưng chưa đủ. Thứ quyết định bạn còn đứng vững hay không, là khi con gà đã được vỗ béo xong, bạn là người cầm dao — hay là người nằm trên thớt.

Lại một chủ đề kinh điển nhưng chưa bao giờ lỗi mốt, đặc biệt là trong cái thời buổi AI bùng nổ đến mức viết code còn giỏi hơn cả tôi. "Nắm vững Python, Java, C++,..." có còn là tấm vé vàng bảo chứng cho sự thăng tiến?Góc nhìn của tôi? Thẳng thắn mà nói: KHÔNG. Code giỏi chỉ là điều kiện CẦN, nhưng điều kiện ĐỦ để bứt phá, để thăng tiến từ một Senior Developer lên Software Architect, Engineering Manager hay xa hơn nữa, lại nằm ở những thứ... không hề liên quan đến dòng code.1. "Dính Bẫy" Chuyên Môn: Code Rất Giỏi, Nhưng Lương Chỉ Tăng Theo... Niên HạnThú thật với anh em, 5-6 năm đầu sự nghiệp, tôi là một kẻ cuồng kỹ thuật. Tôi tự hào mình nắm Java như lòng bàn tay, tối ưu hiệu năng SQL "bá đạo", và luôn xung phong giải quyết các bug kỹ thuật khó nhất. Tôi nghĩ chỉ cần code thật nhanh, thật sạch, mọi người sẽ tự khắc công nhận và thăng tiến tôi.Kết quả? Lương tôi tăng, nhưng theo... niên hạn và lạm phát, chứ không hề có một cú bứt phá thực sự. Tôi cứ ở mãi mức Senior, nhìn những người khác (mà tôi tự đánh giá là code... bình thường) thăng chức lên Project Lead, Manager. Tôi tự ái, nghĩ rằng mình bị "underrated" (đánh giá thấp).2. "Cú Tát" Từ AI Và "Dự Án Tỉ Đô": Khi Code Giỏi Trở Thành... Kỹ Năng Giá RẻRồi AI đến. Các công cụ như Copilot, ChatGPT bắt đầu viết code chuẩn chỉnh, nhanh hơn tôi gấp 10 lần. Tôi bắt đầu hoang mang: "Nếu chỉ cần code chạy được, thì mình khác gì một cỗ máy đắt tiền?""Cú tát" thực sự khiến tôi tỉnh ngộ là khi tôi được giao vai trò Tech Lead cho một dự án di chuyển hệ thống sang Cloud. Tôi nghĩ đơn giản: "Vấn đề gì khó, tớ nhảy vào code là xong."Nhưng...Vấn đề: Đội ngũ Outsourcing không hiểu rõ thiết kế, code rối tung lên.Cách giải quyết của tôi (sai): Tự mình nhảy vào refactor (viết lại code).Hậu quả: Tôi kiệt sức, deadline vẫn trễ, team Outsourcing thì ỷ lại. Kỹ năng code của tôi vô dụng trong việc quản lý con người.Vấn đề: Khách hàng (người không rành kỹ thuật) yêu cầu một tính năng... phi thực tế vì tốn quá nhiều tài nguyên, chi phí Cloud.Cách giải quyết của tôi (sai): Cố giải thích bằng thuật ngữ kỹ thuật, REST API, Database schema.Hậu quả: Khách hàng chán ngán, dự án bế tắc. Kỹ năng code của tôi vô dụng trong việc đàm phán thương mại.Insight xương máu của tôi: Khi bạn đi xa hơn, vấn đề không còn là "Làm thế nào để viết code?". Nó là "Chúng ta đang giải quyết bài toán gì cho kinh doanh? Tại sao chúng ta lại dùng Cloud mà không dùng Server vật lý? Tại sao chúng ta lại ưu tiên tính năng A hơn tính năng B?".3. "Giải Phóng" Bản Thân: Học Cách Giao Tiếp Bằng... Ngôn Ngữ Của Tiền Và Vấn ĐềThất bại đó buộc tôi phải thay đổi. Tôi nhận ra: Thăng tiến nghĩa là tầm ảnh hưởng (impact) của bạn ngày càng lớn, và code giỏi chỉ là một phần rất nhỏ trong tầm ảnh hưởng đó.Đây là những thứ tôi tập trung giải quyết:Cái gì hiệu quả?Giao tiếp & Tư duy Kinh doanh (Business Acumen):Tôi học cách nói chuyện với khách hàng bằng ngôn ngữ của họ: Giá trị, Chi phí, Doanh thu. Thay vì nói: "Chúng tôi cần refactor Database vì nó bị nghẽn (瓶頸)", tôi nói: "Nếu không tối ưu, hệ thống sẽ chậm 30% vào dịp Sale Tết, có thể làm giảm 20% doanh thu. Chi phí tối ưu chỉ bằng 1/5 số doanh thu đó."Insight: Học cách kết nối dòng code của bạn với số tiền mà doanh nghiệp kiếm được hoặc chi ra.Kỹ năng Làm việc Nhóm & Lãnh đạo (Leadership & Soft Skills):Thay vì tự refactor, tôi tổ chức các buổi Code Review kỹ lưỡng, chia sẻ tài liệu thiết kế chuẩn. Tôi học cách ủy quyền, cố vấn (mentoring) cho Juniors.Insight: Thăng tiến lên làm sếp không phải là code giỏi hơn sếp, mà là làm cho cả team code giỏi hơn khi có bạn.Tư duy Hệ thống & Giải quyết Vấn đề (System Thinking):Thay vì chỉ code cho tính năng chạy, tôi bắt đầu đặt những câu hỏi lớn hơn: "Hệ thống này có dễ scale không? Nếu AI ngày càng thông minh, thì phần logic nào trong hệ thống sẽ lỗi thời?"Insight: Học cách nhìn toàn cảnh, dự đoán tương lai và thiết kế các giải pháp bền vững.Ngoại ngữ: Không chỉ để đọc tài liệu, mà là để đàm phán, trình bày, làm việc với các team đa quốc gia. Mở ra vô số cơ hội thăng tiến ở các công ty Global.Bài học xương máu: Cách định vị bản thân để bứt phá thu nhậpNếu nhìn lại, tôi không hối hận vì đã code giỏi. Nhưng tôi sẽ thay đổi cách tiếp cận:Trở thành một "T-Shape Engineer" càng sớm càng tốt:Trục dọc (Biết sâu): Giữ vững chuyên môn kỹ thuật một stack cốt lõi (Go, Java, Python...). Đây là nền tảng.Trục ngang (Biết rộng): Tích cực mở rộng kỹ năng mềm, kiến thức kinh doanh, ngoại ngữ. Đây là bệ phóng.Và hãy nhớ: Trò chơi thăng tiến trong ngành IT không phải là cuộc đua xem ai code nhanh nhất. Nó là cuộc đua xem ai giải quyết được các vấn đề quan trọng nhất của doanh nghiệp. Bạn code giỏi, nhưng chỉ dùng nó để giải quyết các bug kỹ thuật thì impact của bạn rất hạn chế. Bạn code giỏi, và biết dùng nó kết hợp với kỹ năng mềm để giải quyết các vấn đề về Scale, về Chi phí, về Trải nghiệm Người dùng, về Quy trình... thì trần thăng tiến của bạn là không có giới hạn.Chúc anh em tìm được trục dọc và trục ngang của đời mình và sớm bứt phá thu nhập trong kỳ review sắp tới!