AI & I

Thử thành thật với nhau một câu: Đã bao nhiêu lần tuần này bạn dán cả block code vào Claude rồi ngồi cầu nguyện cho nó chạy?Dạo này lướt đâu cũng thấy thảo luận về "Fresher có AI vs Senior - Ai thắng?". Mọi người hăng hái mổ xẻ như thể đây là một cuộc chiến công nghệ. Nhưng sự thật thì phũ phàng hơn nhiều: AI chẳng giải quyết cuộc chiến nào cả, nó chỉ hạ thấp tiêu chuẩn để sự lười biếng trông giống như hiệu suất.1. Bẫy năng suất: Khi bạn tưởng mình là Kiến trúc sư, nhưng thực chất chỉ là "Máy copy-paste"Fresher bây giờ dùng AI viết CRUD trong 5 phút, dựng sẵn CI/CD trong 10 phút. Rất hào hứng. Cảm giác như mình đã tiệm cận trình độ Senior sau 6 tháng ra trường.Nhưng hãy tự hỏi: Nếu ngắt kết nối Internet, bạn còn lại gì?Bạn có hiểu tại sao AI lại chọn cấu trúc đó thay vì cách khác?Bạn có biết đoạn code "chạy ngon lành" đó sẽ nghẽn (bottleneck) ở đâu khi hệ thống cán mốc 100.000 users?Hay bạn chỉ đang đóng vai một người trung chuyển: nhận file từ BA, ném cho AI, rồi ném đoạn output cho Tech Lead review?Nếu công việc của bạn chỉ là chuyền bóng, thì người ta giữ lại bạn để làm gì khi con Agent có thể tự bấm nút Merge?2. Senior giả tạo & Nỗi sợ bị bóc phốtĐừng nghĩ Senior đứng ngoài cuộc chơi này. Rất nhiều người lấy cớ "kinh nghiệm" để bác bỏ AI, nhưng đêm về lại lén lút hỏi ChatGPT cách tối ưu đoạn query mà mình lỡ quên.Cái bẫy của Senior nằm ở Thói quen cũ. AI có thể không hiểu context lịch sử của một dự án chằng vá từ 5 năm trước, nhưng nó cập nhật chuẩn mới nhanh gấp 100 lần bạn. Khi một bạn Fresher mang đoạn code AI viết ra phản biện, cái làm Senior tự ái không phải là AI đúng, mà là nỗi sợ: Hóa ra kiến thức mình tự hào giữ khép kín bấy lâu nay, giờ một đứa mới vào nghề hỏi AI 30 giây là ra.3. Trận chiến thực sự xảy ra lúc 2h sángProd sập. Token hết quota. AI Server báo lỗi 503.Lúc đó, không có ô chat nào để bạn dán log vào. Không có con Bot nào đứng ra nhận trách nhiệm trước Giám đốc Kỹ thuật.Chỉ còn bạn, màn hình đen chớp tắt, và sự thật trần trụi về năng lực của bạn.Lúc đó mới biết ai là người thực sự hiểu hệ thống, và ai chỉ là kẻ mượn danh AI để làm Senior.Lời nhắn cho cả Fresher lẫn Senior: AI không thay thế bạn. Nhưng một người biết dùng AI và thực sự hiểu những gì họ làm sẽ tiễn bạn ra khỏi ngành này rất nhanh. Đừng để sự tiện lợi tạm thời ru ngủ tư duy phản biện.Còn bạn, lần cuối cùng bạn tự tay debug một case khó mà không cần mở AI là khi nào?

Bạn đã từng thấy tình huống này chưa? Mình ngồi cạnh một bạn Fresher và chứng kiến một màn khá khó xử. Bạn ấy bị anh Senior chỉ ra một lỗi logic, nhưng không sửa ngay. Bạn ấy mở laptop, dán câu hỏi vào Claude Code rồi quay màn hình lại: "Anh xem nè, AI nó bảo cách em làm đúng mà."Anh Senior cười cười, bảo "ừ để lát tao xem". Không khí lúc đó hơi kỳ. Mình ngồi cạnh, không biết nên thấy buồn cười hay thấy lo.Hôm đó về rồi mà mình vẫn nghĩ mãi về chuyện này. Không phải vì bạn Fresher hỗn hay gì — bạn ấy còn trẻ, tự tin, cũng bình thường thôi. Mà vì cái cách bạn ấy coi câu trả lời của AI là bằng chứng để chốt hạ. Càng nghĩ càng thấy nó không đơn giản là "ai đúng ai sai".Trước tiên, AI giúp Fresher thật, cái đó khỏi bànMình từng là đứa bảo thủ, thấy gì mới cũng gân cổ cãi, trả giá kha khá rồi nên giờ mình cố không phủ nhận sạch trơn.Nhiều bạn Fresher bây giờ làm nhanh và sạch hơn tụi mình hồi xưa nhiều. Ít lỗi cú pháp vặt, không còn ngồi cả buổi mò một dấu ngoặc thiếu. Dựng khung project, viết CRUD, config CI/CD cơ bản, AI làm loáng cái xong. Quăng file cả ngàn dòng vào nó cũng tóm tắt được luồng chạy, thứ hồi trước tụi mình dò tay mất mấy ngày. Cái này là thật, mình mừng cho tụi nó.Nhưng tốc độ đó đôi khi giấu đi một lỗ hổng.Cái bẫy "chạy được là xong"Kiểu mình hay thấy: AI đẻ ra một đoạn, chạy thử thấy được, không đỏ, merge. Không đọc lại, không hỏi sao nó viết vậy, không rõ nó xử lý case biên ra sao.Cái đáng sợ là nhìn bên ngoài thì hai trường hợp này chẳng khác gì nhau. Code đều chạy, test đều xanh, PR đều merge. Chỉ tới lúc có chuyện mới biết người viết có thật sự hiểu nó hay không. Mà hậu quả thì không tới ngay, nó nằm im tới hôm gặp đúng cái case không ai ngờ. Lúc mở ra tìm nguyên nhân, cả team ngồi nhìn nhau, không ai giải thích nổi tại sao nó lại được viết như vậy — vì người viết là AI, người merge chỉ thấy nó chạy.Cái mình sợ: tới lúc cần thì không có AIChỗ này mình phải nói thật, mình chưa gặp một ca hết-token-giữa-lúc-prod-sập nào đúng nguyên xi. Nhưng mình hình dung ra được, và mình sợ cái viễn cảnh đó.Một bạn quen dựa hẳn vào AI. Bug hỏi AI, log dán cho AI đọc, query khôi phục dữ liệu cũng nhờ AI. Nhìn vào tưởng làm được hết. Rồi một hôm cần gấp mà AI không xài được — hết quota, mạng công ty chặn, hay bên kia sập server, gì cũng được — thì lấy gì ra chống đỡ?Cái mình sợ không phải bug khó. Mình sợ cảnh một người chưa từng tự tay debug mà không có ai cầm tay, tới lúc phải làm một mình thì không biết bắt đầu từ đâu. Năng lực mà cả team tưởng bạn ấy có, hóa ra nằm trong cái ô chat chứ không nằm trong đầu bạn ấy.Nói cho gọn: tới lúc không có AI bên cạnh mới biết mình thực sự biết làm đến đâu. Mình dùng AI fix bug suốt, không bài xích. Nhưng dùng cho nhanh với dùng để khỏi phải biết là hai chuyện khác nhau.Chỗ rối nhất: khi Fresher cãi Senior mà AI lại đúngQuay lại buổi review. Mình nói thẳng luôn: dùng AI phản biện Senior chẳng có gì sai. Và nhiều khi AI đúng thật, Senior sai thật.Chuyện đó xảy ra chứ. Người làm lâu năm đôi khi quen tay với cách cũ, chưa cập nhật chuẩn mới, hoặc nhớ nhầm. AI có thể tìm ra một cách làm mới, hoặc một API, một documentation mà ông Senior chưa kịp đọc tới. Có lúc nó đúng thật, Fresher mang ra, về lý thuyết là chuẩn.Nhưng đúng lý thuyết chưa chắc đúng trong hoàn cảnh này. Cái này mình phải mất mấy năm mới thấm.Mình từng thấy một ca như vậy. Bạn Fresher chỉ ra một cách viết mới gọn hơn, "chuẩn" hơn theo tài liệu, AI cũng hậu thuẫn bạn ấy. Anh Senior nghe xong mới thủng thẳng: cách cũ xấu hơn thật, nhưng nó viết vậy vì service này đang chạy trên phiên bản hạ tầng cũ, cái thư viện mà chuẩn mới cần thì bên deploy chưa hỗ trợ, đổi sang là gãy nguyên luồng lúc lên prod. Bạn Fresher không biết, AI càng không — nó có bao giờ nhìn thấy cái server thật của tụi mình đâu.Cái khác nhau nằm đúng chỗ đó. AI thường chỉ thấy phần context mình đưa cho nó: hạ tầng ra sao, đang xài thư viện bản nào, hệ thống từng thay đổi những gì... mình không nói thì nó không biết. Còn ông Senior sống trong hệ thống thật, đã chạy mấy năm, vá chằng vá đụp, mỗi dòng code xấu đều có một lý do mà không ở đó đủ lâu thì không biết.Hồi làm công ty cũ, mình từng nghe một anh QC nói về HICCUPPS, có hai chữ History với Conversations. Hồi đó nghe thì biết vậy thôi. Giờ nghĩ lại mới thấy nó đúng với chuyện này: một hệ thống không chỉ có code hiện tại, nó còn có cả đống quyết định cũ và những thứ team từng thống nhất với nhau. Ông Senior giữ trong đầu cái đó, còn AI thì không có mặt trong mấy buổi họp đó để mà biết. Cái quyết định "thôi tạm viết vầy, sau refactor" trong một buổi họp gấp năm nào đó — AI làm sao biết. Nó chỉ thấy dòng code xấu và bảo nên viết lại.Nên bài học không phải "Fresher đừng cãi" hay "AI luôn sai". Lúc đó nếu bạn ấy chỉ hỏi thêm một câu, kiểu "Anh viết vậy vì có constraint gì à?", thì có lẽ cả buổi review đã đi theo hướng khác — bạn ấy học được cái AI không dạy được, mà không khí cũng đỡ căng. Vài câu với FresherHồi mới vào nghề mình cũng đầy tật, cũng tự cao, cũng cãi cố, nên mình không đứng ở thế dạy đời. Chỉ là mấy thứ mình ước có ai nói với mình sớm hơn.Trước khi merge, ráng tự trả lời được "vì sao đoạn này đúng", kể cả khi AI viết. Không trả lời được thì khoan merge. Đơn giản vậy thôi mà cứu mình được nhiều lần.Còn khi AI với Senior mâu thuẫn, đừng vội chọn phe. AI có thể đúng chuẩn mới, Senior có thể đúng hoàn cảnh thật, hai cái đó sống chung được. Hỏi thêm một câu bao giờ cũng đỡ mệt hơn cãi một buổi.Cuối cùng thì khoảng cách Fresher với Senior không bị AI xóa, nó dời chỗ thôi. Hồi xưa hơn nhau ở chỗ ai gõ nhanh và đúng hơn.Giờ AI gõ giùm cả hai rồi, nên nó dời sang chỗ khó thấy hơn: ai hiểu sâu hơn, ai đoán được lúc nào AI đang chém, ai nắm được cái hoàn cảnh thật mà AI không nhìn thấy. Tới lúc prod sập lúc hai giờ sáng thì AI vẫn có thể ngồi viết code với mình. Nhưng người phải hiểu chuyện gì đang xảy ra, quyết định rollback hay không, rồi đứng ra nhận trách nhiệm cuối cùng, vẫn là mình.

Áp Lực Kỷ Nguyên AI: Khi Viết Code Nhanh Gấp 5 Lần Lại Khiến Dev Mệt Hơn Gấp 10Buổi họp Retrospective chiều thứ sáu của Project diễn ra trong một sự tĩnh lặng đáng sợ, không Leader nào lên tiếng, cả buổi chỉ là những câu hỏi tại sao của Director. Trên màn hình Dashboard tracking, biểu đồ burndown chart đi ngang một cách rệu rã, có line còn đi xuống như cổ phiếu. Cạnh bên là báo cáo chi phí: hệ thống AI Agent của dự án vừa đốt hàng chục ngàn USD tuần qua. Tiến độ thì vẫn trễ thảm hại, một loại follow-up tasks được define với deadline sát nút để giải cứu. Đứng ở góc độ tư duy Project Management khi nhìn vào quy trình vận hành, tôi nhận ra team mình vừa ăn một "cú lừa" kinh điển của SDLC 2.0: Đặt cược tất cả vào sự "quy củ" của AI, để rồi bị chính nó vắt kiệt sức.Bi kịch bắt đầu ngay từ khâu design. Dự án của chúng tôi vận hành với một tư duy thoạt nghe rất bài bản: Tuyệt đối không dùng AI tự phát. Mọi tác vụ từ generate tài liệu design đến gen code đều bắt buộc sử dụng các bộ prompt do dự án define sẵn, với đầy đủ context knowledge, đầy đủ skills. Kỳ vọng của cấp quản lý là gom toàn bộ sức mạnh của AI về một mối (centralize), đảm bảo tính nhất quán (consistency) và đưa AI vào một process chuẩn mực, tương lai xa hơn có thể apply cho toàn bộ project còn lại.Và, tuân thủ tuyệt đối quy trình, bạn Junior dùng bộ prompt đã được "chuẩn hóa" ném file requirement của BA cung cấp vào con Agent. Một bản design document trông cực kỳ nguy hiểm, trình bày rất đỉnh, ngập tràn technical keyword, với cách trình bày nặc mùi "AI" lập tức ra lò. Ông anh Senior bận rộn cũng làm đúng process, lấy bộ prompt dành riêng cho reviewer để AI tự động peer-review/upper-review. Kết quả review thật tốt, agent xuất ra một bản checklist trông cũng không khác gì các chuyên gia, với đầy đủ note, item, reference đủ cả, và câu chốt verdict bên dưới PASSED. Tuyệt vời không còn gì bằng, cả hai gật gù chốt phương án vì cỗ máy "chính ngạch" của dự án phán rằng mọi thứ hoàn hảo. MR được tạo, các ticket JIRA được resolve một cách nhanh chóng với đầy đủ evidence được capture một cách chuẩn chỉnh, nice!Cho đến khi release lên môi trường QA, luồng data ghi xuống database lỗi một cách ngớ ngẫn, exception throw ra với msg chả hiểu là gì. Lập tức lôi requirement gốc ra audit, chúng tôi mới tá hỏa: dù chạy bằng prompt chuẩn, con AI viết design vẫn tự động "lược dịch" mất hai business rule quan trọng nhất, và con AI làm nhiệm vụ review cũng ngoan ngoãn bỏ qua luôn. Hoảng loạn, team Solution nhảy vào cứu net. Nhưng thay vì rà soát source code bằng mắt, họ lại bị cuốn vào guồng quay cũ: dùng một loạt prompt "siêu cấp vip pro" khác được gắn mác bởi các SA hàng đầu để AI tự đi audit lại đống code và tài liệu kia. Một vòng lặp "máy chấm điểm máy" vô tận, còn con người thì đứng ngoài rìa, mù tịt về chính kiến trúc sản phẩm của mình.Chuỗi ngày đau khổ nhất rơi vào đội QA. Các bạn dev dùng prompt dự án sinh ra test matrix, gen JUnit test script ầm ầm. Code xanh lè, report coverage luôn đạt ngưỡng 99%~100% nhưng case thì rỗng tuếch, toàn happy case, summary data nhưng lại không có testcase fan-out. Đội function tester thì khốn khổ với con AI Agent trung tâm. Mỗi ngày, Agent này đốt hàng trăm USD tiền token, output luôn tuân thủ đúng định dạng Markdown như đã được define. Nhưng bất kì ai làm testing đều biết, quản lý hàng ngàn testcase bằng Markdown thay vì Excel thuần túy là một cực hình "vô nhân đạo". Không thể filter, không thể tracking, sai context, format gãy vụn, muốn xem tổng quát cũng chả xem được mà phải scroll lên, scroll xuống.Tester phải hì hục đi copy-paste và sửa tay từng dòng. Hệ lụy kéo theo là sự đứt gãy về KPI. Không tìm ra bug vì testcase chuẩn AI đẻ ra quá hời hợt, không đạt chỉ tiêu số bug trên KLOC. Cuối tháng, team phải vò đầu bứt tai viết giải trình: Tại sao team không dùng con Agent đắt đỏ của dự án mà lén lút tự viết cả trăm cái prompt nhỏ lẻ bên ngoài để vá víu output? Project được AI estimate effort rất đẹp, timeline cực kỳ tối ưu, nhưng công sức đi dọn dẹp "bãi rác" output do AI xả ra đã khiến effort thực tế đội lên gấp 10 lần.Từ câu chuyện đẫm máu trên, câu hỏi đặt ra là: Tại sao có process chuẩn, có AI mạnh nhiều tiền, chúng ta lại càng ngày càng kiệt sức hơn?Sự Sụp Đổ Của "Niềm Tin Quy Trình"Việc centralize các prompt và chuẩn hóa AI Agent là bước đi đúng về mặt quản trị. Nhưng sai lầm chí mạng là chúng ta lầm tưởng rằng: Prompt chuẩn sẽ cho ra kết quả đúng tuyệt đối. Sự thật là, tính consistency của máy móc đôi khi chỉ là sự lặp lại một cách kiên định những sai lầm ngớ ngẩn. Giao phó toàn bộ niềm tin vào một "AI process" khiến con người đánh mất đi khả năng hoài nghi và phản biện.Nghịch Lý Năng Suất Và "Bẫy" Kỳ VọngTrong kinh tế học có một khái niệm gọi là Nghịch lý Jevons, hình dung khi bóng đèn trở nên tiết kiệm điện hơn, con người không tắt bớt đi mà thay vào đó thắp sáng nhiều khu vực hơn và bật đèn lâu hơn. Áp dụng vào ngành Software Engineering: Công nghệ càng giúp tiết kiệm tài nguyên, nhu cầu sử dụng tài nguyên đó càng bùng nổ. Khi AI giúp hoàn thành một tính năng trong 1 ngày thay vì 5 ngày, Product Owner sẽ ném thêm 4 tính năng mới vào Sprint với thời hạn ngắn hơn. Thời gian tiết kiệm được không biến thành thời gian rảnh, nó bị lấp đầy bởi những áp lực mới.Sự Dịch Chuyển Sang "Năng Lượng Thẩm Định"Viết code truyền thống tốn sức lực cho việc tư duy logic và gõ phím. Nhưng làm việc với AI, và cho dù ngay cả với một AI đã cấu hình "chuẩn", lại bào mòn Năng lượng thẩm định (Appraisal Energy) của bạn để đánh giá, chọn lọc và ra quyết định. Việc liên tục soi lỗi các security leaks, performance, các vi phạm tiêu chuẩn dự án, đọc hiểu logic do AI sinh ra, rà soát các "hallucinations" ẩn sâu trong context khổng lồ thực chất gây căng thẳng thần kinh hơn nhiều so với tự tay viết. AI không làm bạn rảnh hơn, nó ép bạn từ vai trò "Người xây dựng" sang vai trò "Người dọn rác và kiểm duyệt".Chính quá trình thẩm định liên tục này tạo ra một phản ứng ngược, khiến não bị quá tải nhận thức rất nhanh, đó lý do vì sao dùng AI tạo code đôi khi còn mệt hơn tự viết. Khủng Hoảng "Quá Tải Quyết Định" (Decision Fatigue)Khi tốc độ generate code và tài liệu tăng lên một cách ào ào như thác đổ, mật độ decision points chạm ngưỡng báo động. Sửa đoạn code này hay bắt AI viết lại? Logic này chạy đúng trên môi trường UAT nhưng tạch trên Staging thì sao? File Markdown này copy ra Excel thủ công hay viết script convert? Package này AI suggest có bị deprecated hay dính lỗ hổng bảo mật không?... Chỉ trong một khoảng thời gian ngắn, mật độ ra quyết định quá dày đặc khiến não bộ kiệt quệ ngay từ giữa ngày làm việc dù bề ngoài trông bạn "chỉ ngồi prompt và copy-paste" chứ có làm gì nặng nhọc đâu. Rất dễ bắt gặp cảnh mặc dù sáng ra đã làm một ly coffee đậm đà đầy năng lượng, nhưng tới giờ cơm trưa lại chả buồn ăn.Tốc Độ Mới Trở Thành "Baseline" MớiKhoảng 2 năm trước thôi, việc fix một bug phức tạp tốn cả ngày làm việc (7h-8h đồng hồ) là điều hoàn toàn chấp nhận được. Ngày hôm nay, nếu bạn mất cả ngày cho bug đó, câu hỏi đầu tiên bạn nhận được sẽ là: "Cái này có hỏi AI chưa? Đã quăng log cho AI phân tích chưa mà lâu thế?"AI thật sự đã nâng mức kỳ vọng tối thiểu (Baseline) của toàn bộ ngành công nghiệp lên một tầm cao mới. Cái tốc độ mà trước đây chúng ta được cho là "xuất sắc" thì nay chỉ còn là "mức trung bình đạt chuẩn". Hệ quả dễ dàng nhìn thấy nhất trong những buổi review performance, ông Dev sẽ không còn được thưởng vì làm nhanh, mà bị sẽ đánh giá không tốt nếu làm chậm. Do đó, bạn không thể đi chậm lại, vì cả hệ sinh thái xung quanh đều đang tăng tốc một cách đáng sợ.Sống Sót Thế Nào Trong Kỷ Nguyên SDLC 2.0?Để không bị đống "code siêu tốc" đè bẹp, quy trình thôi là chưa đủ. Chúng ta buộc phải thay đổi vị thế:Tập trung vào Domain Knowledge & Architecture: AI rất giỏi syntax nhưng cực kỳ ngây thơ về business rule. Năng lực sống còn bây giờ là System Thinking, phải hiểu sâu bức tranh tổng thể để biết AI đang lược bỏ sai logic ở điểm nào.Quy trình chuẩn hóa phải đi kèm Verification độc lập: Centralize prompt là tốt, nhưng đừng dùng mắt người để audit hàng triệu dòng code do AI sinh ra. Hãy nên xây dựng một luồng Integration Test độc lập để kiểm soát output của cỗ máy generate kia, tạo ra hàng rào tự động hóa trước khi con người nhúng tay vào rà soát bước cuối.Đo lường bằng Cycle Time, không phải Code Gen Time: Hãy quản trị lại Kỳ vọng (Expectation Management), đừng bao giờ cam kết deadline dựa trên "tốc độ AI generate code". Chục ngàn dòng code sinh ra trong 5 phút theo đúng chuẩn dự án là vô nghĩa nếu mất 1 tuần để tester sửa format và 3 ngày để debug. Hãy cam kết dựa trên Cycle Time ngay từ lúc chốt requirement đến khi test và deploy một cách an toàn.Đơn giản là AI giúp chúng ta đi nhanh hơn, nhưng tuyệt đối không thể nghĩ thay chúng ta. Giao phó toàn bộ tư duy cho các bộ prompt, dù chúng có được thiết kế hoàn hảo và quy củ đến đâu, đó chính là cách nhanh nhất để đánh sập một hệ thống từ sâu bên trong.Và tôi cũng biết rằng ngoài kia, đang có rất nhiều khóa học, nhiều video, nhiều buổi sharing hô hào "Dùng AI để làm việc thay bạn", nhưng thực tế cuộc chơi khốc liệt hơn nhiều. Nếu bạn là một Junior Dev hay một Tester vẫn còn đang bối rối, chưa biết phải định vị mình ở đâu khi AI đang xâm chiếm mọi ngóc ngách của dự án, thì đây là lời khuyên chân thành từ những "vết thương" dự án thực tế:Với anh em Developer: Tốc độ gõ phím không còn là lợi thế cạnh tranh. Đừng cố chạy đua việc sinh ra hàng ngàn dòng code với máy móc. Thay vào đó, hãy đầu tư vào thứ mà AI chưa thể nắm bắt trọn vẹn: Context và System Design. Hãy hiểu sâu Business Logic, luồng dữ liệu, và cách các component tương tác với nhau. Khi bạn nắm vững kiến trúc, AI sẽ là một anh thợ xây siêu tốc dưới quyền bạn. Còn nếu bạn chỉ mãi tập trung vào bề nổi, cưỡi ngựa xem hoa, bạn sẽ sớm trở thành người đi dọn rác cho chính anh thợ xây đó.Với anh em Tester/QA: Sự bùng nổ của AI không phải là dấu chấm hết cho nghề Tester, trái lại, phải nói rằng thời thế của các bạn đang tới, thật đấy. Khi code được đẻ ra ào ào với "tốc độ ánh sáng", số lượng bug tiềm ẩn và những "ảo giác logic" sẽ tăng lên theo cấp số nhân (tất nhiên rồi vì muốn không có bug nào thì chỉ có cách là đừng code dòng nào cả). Từ đây vai trò "người chốt chặn" của QA chưa bao giờ quan trọng đến thế. Đừng tự biến mình thành "thợ sửa format" cho những file testcase vô hồn của AI. Hãy nâng cấp năng lực của mình thành Quality Engineer, hãy dùng tư duy phản biện để bẻ gãy những logic hoàn hảo giả tạo, nịnh bợ của máy móc, đào sâu vào các edge cases, và bắt hệ thống (cũng như mấy con AI) phải chứng minh tính đúng đắn của nó cho mình.Có thể nghĩ về bản chất rằng, AI nó là một chiếc loa phóng thanh. Nó khuếch đại năng lực của bạn từ Junior lên Middle, từ Middle lên Senior, nhưng đồng thời cũng khuếch đại cả những sai lầm và sự hời hợt trong quy trình làm việc.  Đừng sợ AI cướp task của bạn, hãy sợ việc chính bản thân mình đánh mất đi năng lực cốt lõi nhất của một SWE: Khả năng hoài nghi và tư duy giải quyết vấn đề độc lập.  Hãy làm chủ AI, đừng để AI "chơi" và vắt kiệt mình!Anh em đang gặp khó khăn gì nhất khi làm việc cùng AI? Chia sẻ dưới comment để chúng ta cùng tìm hướng giải quyết nhé.

AI có giúp chúng ta nhàn hơn không?Có.---Một lập trình viên có thể viết code nhanh hơn. Một tester có thể tạo test case nhanh hơn. Một BA có thể tổng hợp tài liệu nhanh hơn. Một PM có thể chuẩn bị biên bản họp trong vài phút. Một ứng viên có thể viết CV, chuẩn bị phỏng vấn hay tìm hiểu công ty nhanh hơn rất nhiều so với trước đây.Nhưng tôi nghĩ câu hỏi thú vị hơn không phải là: “AI có giúp chúng ta làm nhanh hơn không?”Mà là:Khi tất cả mọi người đều có thể làm nhanh hơn nhờ AI, công việc có thật sự trở nên nhẹ hơn không?Tôi ngày càng có cảm giác rằng AI làm giảm công sức của từng tác vụ, nhưng không chắc làm giảm tổng khối lượng công việc mà chúng ta phải đối mặt. Bởi khi năng lực của một cá nhân tăng lên, năng lực của những người xung quanh cũng tăng. Sản lượng tăng. Kỳ vọng tăng. Tiêu chuẩn thay đổi. Và cuối cùng, chính luật chơi của công việc cũng thay đổi theo. Tôi muốn bắt đầu câu chuyện này từ một nơi mà hầu như người làm IT nào cũng từng đi qua: tuyển dụng.Khi cả ứng viên và nhà tuyển dụng đều có AITrong những buổi chia sẻ với sinh viên, tôi thường nói về tuyển dụng như một quá trình gồm nhiều lớp đánh giá: hồ sơ, trao đổi ban đầu, bài kiểm tra hoặc đánh giá chuyên môn, phỏng vấn với bộ phận chuyên môn và cuối cùng là quyết định hợp tác. Trước đây, mỗi bước đều cung cấp cho doanh nghiệp một số tín hiệu nhất định.CV cho thấy ứng viên đã làm gì.Bài test cho thấy khả năng chuyên môn.Buổi phỏng vấn cho thấy cách tư duy, giao tiếp và xử lý tình huống.Những tín hiệu đó vốn không hoàn hảo, nhưng ít nhất chúng giúp hai bên hiểu nhau hơn.AI đang làm một việc rất thú vị: nó làm cho việc tạo ra những tín hiệu đẹp trở nên cực kỳ dễ dàng.Một CV bình thường có thể được AI chỉnh thành một CV rất chuyên nghiệp chỉ trong vài phút.Một ứng viên có thể đưa JD vào AI rồi hỏi:“CV của tôi đang thiếu gì?”“Những câu hỏi nào có thể xuất hiện trong buổi phỏng vấn?”“Hãy đóng vai interviewer và phỏng vấn tôi.”“Giúp tôi trình bày project này thuyết phục hơn.”Với vị trí kỹ thuật, ứng viên còn có thể dùng AI để giải thích thuật toán, luyện coding test, review code hay mô phỏng những câu hỏi chuyên môn. Ở phía ứng viên, đây rõ ràng là phần nhàn. Những việc từng mất vài giờ có thể chỉ còn vài chục phút. Nhưng vấn đề bắt đầu xuất hiện khi gần như tất cả ứng viên đều có công cụ tương tự.Một CV được trình bày rất tốt trước đây có thể là tín hiệu của sự chỉn chu. Khi AI có thể giúp hầu hết mọi người tạo ra một CV đẹp, tín hiệu đó yếu đi.Một câu trả lời phỏng vấn trôi chảy từng cho thấy ứng viên chuẩn bị kỹ. Khi ứng viên có thể luyện hàng chục vòng phỏng vấn giả với AI, những câu hỏi quen thuộc cũng dần mất khả năng phân biệt.Một bài assignment hoàn chỉnh cũng không còn đơn giản cho biết “người này làm được hay không”. Nhà tuyển dụng phải bắt đầu hỏi thêm: họ hiểu đến đâu, họ lựa chọn giải pháp vì sao, họ có thể giải thích, thay đổi hoặc bảo vệ quyết định của mình hay không.Điểm đáng chú ý ở đây là:Việc đánh giá ứng viên vốn đã khó từ trước. AI không tạo ra cái khó đó.Cái “nhọc mới” nằm ở chỗ khác.AI làm cho những tín hiệu cũ trở nên dễ tạo ra hơn, vì vậy doanh nghiệp phải tìm những tín hiệu mới có giá trị hơn.Khi nộp hồ sơ trở nên quá dễCâu chuyện còn thú vị hơn nếu chúng ta đi thêm một bước.Nếu AI giúp một ứng viên chuẩn bị hồ sơ nhanh hơn, người đó có thể ứng tuyển nhiều vị trí hơn.Nếu công cụ tự động hóa tiếp tục phát triển, quá trình tìm việc có thể tiến xa hơn nữa: tìm job phù hợp, điều chỉnh CV, viết cover letter, chuẩn bị câu trả lời, thậm chí hỗ trợ theo dõi quá trình ứng tuyển.Từ góc nhìn của từng cá nhân, đó là năng suất.Nhưng nếu hàng nghìn ứng viên cùng tăng năng suất theo cách đó, điều gì xảy ra ở phía doanh nghiệp Số hồ sơ tăng. Recruiter lại phải dùng AI để lọc. Doanh nghiệp phải xây thêm tiêu chí đánh giá. Interviewer phải đặt câu hỏi sâu hơn. Quy trình tuyển dụng phải tìm cách phân biệt giữa một hồ sơ được AI hỗ trợ tốt và một người thực sự phù hợp với công việc. Một vòng lặp bắt đầu hình thành:AI giúp ứng viên làm được nhiều hơn → doanh nghiệp nhận nhiều hơn → doanh nghiệp cần AI để xử lý nhiều hơn.Cả hai phía đều được AI giúp.Nhưng cả hai phía cũng bắt đầu phải chạy nhanh hơn.Tôi nghĩ đây là một ví dụ khá rõ cho câu “Nhàn nhờ AI. Nhọc cũng AI”.Không phải vì AI khiến việc cũ khó hơn.Mà vì khi AI làm một việc trở nên quá dễ, quy mô của hệ thống xung quanh việc đó thay đổi.Và chuyện này không dừng ở tuyển dụngNếu đang làm IT, có lẽ chúng ta đã nhìn thấy cùng một hiện tượng ngay trên bàn làm việc của mình.Một developer trước đây có thể mất vài giờ để dựng một đoạn code, tìm lỗi hoặc đọc tài liệu.Bây giờ AI có thể sinh code, giải thích code cũ, đề xuất refactor, viết unit test hoặc tìm nguyên nhân lỗi rất nhanh.Đó là phần nhàn.Nhưng nếu trước đây một developer xử lý được 5 task trong một khoảng thời gian và bây giờ có thể xử lý 10 task, rất có thể một lúc nào đó 10 task sẽ không còn được xem là “năng suất vượt trội”.Nó trở thành bình thường.Thứ giúp chúng ta nhanh hơn hôm nay có thể trở thành tiêu chuẩn mà chúng ta phải đáp ứng ngày mai.Tester cũng vậy.AI có thể giúp tạo test case, phân tích requirement, sinh dữ liệu kiểm thử hoặc hỗ trợ tìm những trường hợp bất thường. Khối lượng công việc trên từng test case giảm. Nhưng khả năng kiểm thử tăng lên thì kỳ vọng về coverage cũng có thể tăng theo.BA có thể dùng AI để tóm tắt hàng chục trang tài liệu, so sánh yêu cầu, tạo user story hay chuẩn bị câu hỏi. Nhưng vì việc tạo tài liệu trở nên dễ hơn, lượng tài liệu được tạo ra cũng có thể nhiều hơn.PM có thể tóm tắt meeting nhanh hơn, viết report nhanh hơn, phân tích risk nhanh hơn. Nhưng khi mọi báo cáo đều có thể được chuẩn bị nhanh, tổ chức cũng dễ kỳ vọng nhiều báo cáo hơn, cập nhật thường xuyên hơn và phản ứng nhanh hơn.Marketing, sales, HR hay các bộ phận khác cũng không nằm ngoài vòng lặp đó.AI làm giảm cost của một hành động.Khi cost giảm, chúng ta thực hiện nhiều hành động hơn.Khi tất cả mọi người cùng thực hiện nhiều hơn, mặt bằng kỳ vọng lại tăng lên.Đó là lý do tôi không nghĩ câu chuyện AI chỉ nên được nhìn theo công thức:Trước đây mất 4 giờ, bây giờ mất 1 giờ, vậy chúng ta tiết kiệm được 3 giờ.Ba giờ đó không nhất thiết biến thành ba giờ nghỉ.Nó có thể biến thành ba task khác.Và sau một thời gian, ba task khác đó lại trở thành một phần của công việc bình thường.Từ AI hỗ trợ đến AI tham gia công việcCó một thay đổi nữa mà tôi nghĩ người làm IT sẽ ngày càng gặp nhiều hơn: AI không chỉ dừng ở việc trả lời câu hỏi. Chúng ta đang tiến tới những hệ thống có thể được giao mục tiêu, tự thực hiện nhiều bước, sử dụng công cụ, kiểm tra kết quả rồi tiếp tục hành động.Trong AI, chúng thường được gọi là Agent – tác tử.Sự khác biệt nghe có vẻ nhỏ nhưng thực ra khá lớn.Một AI assistant có thể giúp tôi viết email.Một Agent trong tương lai có thể nhận mục tiêu:“Tìm những khách hàng phù hợp, chuẩn bị thông tin, soạn email, theo dõi phản hồi và đề xuất bước tiếp theo.”Một AI assistant có thể giúp recruiter đọc CV.Một Agent có thể hỗ trợ tìm ứng viên, sàng lọc, liên hệ, sắp lịch và cập nhật trạng thái.Một AI assistant có thể giúp developer viết code.Một Agent có thể nhận task, đọc codebase, chỉnh sửa nhiều file, chạy test rồi báo lại kết quả.Lúc này câu hỏi không còn đơn thuần là:“AI giúp tôi nhanh hơn bao nhiêu?”Mà bắt đầu trở thành:“Phần nào con người làm?”“Phần nào Agent được quyền làm?”“Agent được phép tự quyết tới đâu?”“Việc nào bắt buộc con người duyệt?”“Nếu Agent làm sai thì ai chịu trách nhiệm?”“Nếu hai Agent đưa ra hai kết quả khác nhau thì hệ thống xử lý thế nào?”Đó là lúc tôi thấy khái niệm Human–Agent Work System trở nên đáng quan tâm.Không phải vì chúng ta cần thêm một thuật ngữ công nghệ.Mà vì khi AI bắt đầu thực sự tham gia vào quá trình làm việc, doanh nghiệp sẽ phải thiết kế lại cách con người và AI phối hợp với nhau.Và đây có lẽ mới là phần “nhọc” lớn hơn trong những năm tới.Không phải học thêm một prompt.Mà là học cách tổ chức công việc trong một thế giới mà con người không còn là tác nhân duy nhất thực hiện công việc.Nhàn hơn, nhưng chưa chắc rảnh hơnTôi vẫn tin AI là một trong những công cụ giúp chúng ta làm việc hiệu quả nhất mà con người từng tạo ra.Tôi cũng không nghĩ giải pháp là né tránh AI để bảo vệ cách làm việc cũ.Nếu người khác có AI còn mình không dùng, rất có thể mình chỉ đang tự làm khó mình.Nhưng có lẽ chúng ta cũng không nên nhầm lẫn giữa hai khái niệm:làm một việc dễ hơn và công việc trở nên nhẹ hơn.AI chắc chắn đang làm rất nhiều việc trở nên dễ hơn.Nhưng khi hàng triệu người cùng được tăng năng lực, thị trường, doanh nghiệp và chính đồng nghiệp của chúng ta cũng thay đổi theo.CV đẹp hơn.Code nhanh hơn.Test nhiều hơn.Report nhanh hơn.Ứng tuyển nhiều hơn.Phân tích nhiều hơn.Và cuối cùng, chuẩn mực mới lại được thiết lập.Vì vậy, cái nhọc đáng nói không nằm ở những việc vốn đã khó từ trước.Cái nhọc mới nằm ở chỗ: mỗi khi AI làm một việc trở nên quá dễ, luật chơi xung quanh việc đó cũng bắt đầu thay đổi.Nếu bạn là developer, tester, BA, PM, recruiter hay bất kỳ ai đang làm trong ngành công nghệ, có lẽ câu chuyện này không chỉ nằm ở một vòng tuyển dụng. Nó có thể đang xảy ra ngay trong công việc của bạn.---Nếu sau bài viết này, “Agent – tác tử” không còn nghe quá xa lạ, và từ câu chuyện tuyển dụng bạn có thể liên tưởng đến chính công việc mình đang làm, thì với tôi như vậy là đủ.Còn không thì thôi, coi như tôi vừa kể thêm một góc nhìn về AI trong công việc.Alex VuongBusiness Development Manager

AI không làm mình rảnh. Nó giúp mình làm được nhiều việc hơn trong cùng một ngày — lịch vì thế dày hơn, không mỏng hơn.Chủ đề hay gặp trên quán trà đá IT: Có AI thì rảnh hơn hay bận hơn? Câu hỏi nghe như quiz. Trả lời thật thì hơi chướng: lịch mình dày hơn. Inbox không gọn hơn. Sprint không “xong sớm về nhà nấu cơm”. Cái đổi là cùng một ngày mình làm được nhiều việc hơn. Làm được rồi thì việc mới kéo tới cho vừa sức đó — không phải về sớm, mà là phủ thêm.Đó không phải slogan. Đó là hệ quả của throughput.Bốn năm, không phải một promptCông việc mình gắn với AI cũng hơn bốn năm. Ban đầu là ứng dụng nhỏ: phân loại, regress, vài pipeline scikit-learn, feature bảng Excel đội business gửi lúc 17h. Model không “thông minh”. Nó thuộc lòng phân phối hôm qua. Sáng nay Excel đổi tên cột — model vẫn hỏi cột cũ đâu, mặt ngây như khách tới nhầm tiệc.Rồi mình vào lớp thạc sĩ, học tiếp Deep Learning: loss, overfitting, GPU hết VRAM giữa epoch, cái cảm giác “acc trên val đẹp quá thì nghi”. Cơ duyên bắt đầu từ đó. Việc mới tới liên tục vì team cần người đưa model vào chỗ có user, không phải notebook.Mình build app tích hợp AI: gọi API model lớn khi cần chất lượng, kéo open source khi cần kiểm soát chi phí, latency, hoặc data không được ra ngoài. Có giai đoạn mình nhét inference xuống ESP32 — không phải vì thích khổ. Vì edge không có 16GB RAM. Quantize, cắt context, đo miliampe, chấp nhận model “đủ dùng” chứ không “SOTA trên Twitter”. Cái đó dạy một bài: constraint phần cứng là prompt thật, không phải system prompt.Hiện tại mình dùng AI như bộ não thứ hai khi làm việc: phác thảo, đối chiếu, viết test skeleton, soi diff, hỏi “failure mode nào mình quên”. Não thứ nhất vẫn là người pager tìm ra lúc 2 giờ sáng. Model lúc đó đã “ngủ” — hoặc đang bịa thêm một nguyên nhân.Rảnh hơn là ảo ảnh kế toán sai đơn vịAI không xóa việc. Nó dời bottleneck.Trước kia bottleneck là gõ. Gõ chậm thì ý chậm. Giờ gõ nhanh — draft, spec, SQL, PR description — ra một lượt. Bottleneck mới là review, eval, và trách nhiệm. Model không chịu onboard. Nó không nhớ SLA. Nó không biết ticket nào là “khách đang la trên production”.Lấy chuyện gần: mình nhờ model viết adapter gọi tool. Code chạy demo. Đưa lên staging thì timeout vì tool kia idempotent kém — gọi hai lần tạo hai record. Model không đọc runbook. Nó đọc docstring bạn paste. Bạn quên paste là bạn sở hữu bug.Hay chuyện ESP32: mình thử firmware “hỏi model nhỏ on-device”. Token/s thấp, RAM eo. Muốn “thông minh” thì phải round-trip cloud — rồi mất offline, tốn pin, thêm secret trên chip. Trade-off không biến mất vì có LLM. Nó hiện rõ hơn, vì option nhiều hơn.Nên AI không làm người rảnh. Nó giúp người phủ nhiều mặt trận hơn: prototype, so sánh model, viết rubrics eval, làm human-in-the-loop cho chỗ được phép sai. “Xong” ngày hôm nay gồm cả việc hôm qua chưa kịp nghĩ tới. Calendar đầy. Output cũng đầy. Hai thứ đó không mâu thuẫn.Người dễ bị lừa là người đếm giờ ngồi ghế, không đếm blast radius. Một hallucination lọt vào config production tiết kiệm 20 phút gõ và tốn hai ngày rollback. Rảnh cái đầu, bận cái đuôi.Não thứ hai, không phải sếp thứ haiMình vẫn hỏi model. Mình không để nó merge. Prompt hay không thay eval. Context window rộng không thay nguồn sự thật (ticket, metric, log, schema). RAG kém thì model tự tin bịa citation. Fine-tune không có test set thì chỉ là overfit lịch sự.3 nguyên tắc sống còn, không đàm phán:Không cho AI tự cấp bằng khenModel giỏi viết, nhưng người phải giữ luật.“Xanh” hay “đỏ”, DoD ra sao — dev chốt.Giao nó tự chấm thì nó bốc phét cho đẹp lòng bạn; prod sập thì bạn gánh.Prompt không version control là đời không nểPrompt thì commit vào git, soi diff, sẵn sàng rollback.Tiện tay chat vài câu không lưu thì tuần sau AI “biến chất” lúc nào không ai hay.Đừng ăn mừng vì rảnhĐếm số việc khó dám nhảy vào cân (eval, edge cases, tool contracts), đừng đếm số giờ ngồi chơi.Rảnh tay mà bug to bằng cái nhà thì là phá hoại, không phải năng suất.Bạn đang rảnh hơn hay bận hơn? Lịch trống mà chất lượng đứng yên — thắng bài thời gian. Lịch dày mà cùng lúc ship được thứ năm ngoái không dám đụng (edge, agent có tool, pipeline có eval) — không phải fail. Đó là hóa đơn throughput: token rẻ, review đắt, pager vẫn ghi tên người.Não thứ hai sinh candidate. Não thứ nhất chọn cái được phép merge — vì test, idempotent, blast radius không nằm trong loss function. Like nếu sprint này đúng vậy. Comment failure mode tuần này cũng được: hallucination vào config vẫn rẻ 20 phút, rollback thì không.Cảm ơn bạn đã quan tâm. — Sẵn dành ít thời gian ghé qua website của mình nhé :) — trucnguyen.dev

Một góc nhìn về cách AI đang thay đổi hành trình từ Fresher lên Senior trong ngành phát triển phần mềm.Cách làm việc đã thay đổiTrước đây, khi gặp vấn đề khó, việc tìm giải pháp thường bắt đầu từ Google, Stack Overflow, documentation, rồi mới đến một người có kinh nghiệm hơn. Bây giờ, phần lớn thời gian, AI là điểm dừng chân đầu tiên: một đoạn code không hiểu, một error khó đọc, một query chạy chậm, một feature chưa biết triển khai — tất cả đều có thể đưa cho AI trước.Nếu Fresher có một "trợ lý Senior" bên cạnh 24/7, khoảng cách giữa Fresher và Senior còn lớn như trước không?AI đang thu hẹp khoảng cách đó — nhưng không xóa bỏ nó. Nó chỉ làm ranh giới giữa Fresher và Senior thay đổi vị trí.Những việc trước đây phải nhờ Senior, giờ có thể tự làmVí dụ: một API chạy chậm khi dữ liệu tăng lên. Trước đây Fresher có thể phải hỏi "nên kiểm tra từ đâu?". Giờ có thể đưa code và log cho AI, yêu cầu phân tích như một Senior Backend Developer trước khi viết code. AI có thể gợi ý ngay các hướng nghi vấn:N+1 queryQuery quá nhiều recordsThiếu paginationThiếu indexEager loading chưa hợp lýCó thể cacheCó thể giảm số lần query databaseChi phí để tiếp cận kiến thức và thử nghiệm giải pháp đã giảm xuống rất nhiều — đó là nơi AI thực sự thu hẹp khoảng cách.AI giúp Fresher "dám làm" những việc trước đây không dám làmNhiều khi Fresher không làm một task không phải vì task quá khó, mà vì không biết bắt đầu từ đâu. AI có thể đóng vai trò định hướng ban đầu — chia nhỏ task thành roadmap, không cần viết code ngay. Đôi khi thứ Fresher cần nhất không phải là câu trả lời, mà là một điểm bắt đầu.Nhưng ai quyết định giải pháp có phù hợp hay không?Đây là lúc khoảng cách giữa Fresher và Senior vẫn còn rất lớn. Với cùng một gợi ý của AI — ví dụ dùng Redis để cache — Fresher có thể nghĩ "hay quá, vậy dùng Redis", trong khi Senior sẽ hỏi lại:Tại sao phải dùng Redis?Nếu dữ liệu thay đổi liên tục thì sao?Cache invalidation thế nào? TTL bao lâu?Nếu Redis down thì sao?Có thực sự cần cache không, hay bottleneck nằm ở query?AI có thể đưa ra giải pháp. Kinh nghiệm giúp chúng ta đánh giá giải pháp.Khi cả Fresher và Senior đều có AI, Senior còn hơn ở đâu?Lợi thế của Senior nằm ở context: biết hệ thống đã tồn tại bao lâu, biết vì sao một đoạn code "xấu" nhưng chưa thể xóa, biết technical debt ở đâu, biết team từng gặp sự cố gì, biết business muốn gì, biết một giải pháp đẹp về kỹ thuật nhưng không phù hợp với project.AI có thể nhìn thấy code. Nhưng Senior thường nhìn thấy: Code + Business + History + Risk + People + Future.Prompt tốt thực sự quan trọngCùng một vấn đề, một người hỏi "Fix this code" chỉ nhận lại một đoạn code. Một người khác mô tả rõ ngữ cảnh — công nghệ đang dùng, hiện tượng cụ thể, dữ liệu kèm theo, và yêu cầu phân tích nguyên nhân trước khi viết code — sẽ nhận được câu trả lời hữu ích hơn rất nhiều. Prompt tốt phản ánh khả năng hiểu vấn đề của chính người hỏi, không chỉ là kỹ năng dùng AI.Một prompt tốt thường có vài phần:Context: Đang làm gì?Problem: Đang gặp vấn đề gì?Input: Có code / log / data gì?Goal: Muốn đạt được điều gì?Constraint: Không được thay đổi điều gì?Expected output: Muốn AI trả lời theo cách nào?Cái bẫy: AI làm Fresher phụ thuộc vào nóNếu mỗi lần gặp lỗi chỉ copy error, dán vào AI, copy code, xong — task được giải quyết nhưng bản thân chưa chắc đã phát triển. Một cách tiếp cận hiệu quả hơn:Tự suy nghĩ trước: đưa ra giả thuyết của riêng mìnhHỏi AI kiểm tra lại giả thuyết đó, thay vì hỏi thẳng câu trả lờiSo sánh với các cách giải thích khácTự implement trước, rồi mới nhờ AI reviewCách này mất thêm thời gian, nhưng đổi lại học được nhiều hơn.Những điều kinh nghiệm mới thực sự khắc sâuAI có thể giải thích rất hay về race condition, database transaction, hay vì sao nên cẩn thận khi refactor. Nhưng người từng gặp production incident vì race condition, từng xử lý một transaction rollback sai, hay từng thấy một migration lớn khoá database và ảnh hưởng production — sẽ nhớ những bài học đó theo một cách hoàn toàn khác. Đó là kinh nghiệm, không phải kiến thức. Kiến thức có thể đọc. Kinh nghiệm thường phải trải qua.Ranh giới mới giữa Fresher và SeniorNếu trước đây ranh giới là "Fresher: em không biết làm" — "Senior: anh biết làm", thì bây giờ có thể trở thành "Fresher: AI nói em nên làm thế này" — "Senior: tại sao?". Senior không nhất thiết phải biết câu trả lời ngay lập tức, nhưng thường biết câu hỏi nào cần đặt ra tiếp theo.Fresher không cần biết tất cảTrước đây Fresher có thể cảm thấy phải biết rất nhiều: Framework, Database, Git, Linux, Docker, Cloud, Architecture, Design Pattern, Testing, Security... AI làm thay đổi điều này. Không nhất thiết phải nhớ mọi syntax hay thuộc mọi API, nhưng cần hiểu concept: đang giải quyết vấn đề gì, vì sao giải pháp này hoạt động, trade-off là gì, khi nào không nên dùng, và làm sao để kiểm chứng.Bạn có thể biến AI thành Teacher → Pair Programmer → Reviewer → Debugger → Mentor. Nhưng điều quan trọng là: bạn vẫn là người lái.AI không làm Senior trở nên vô dụngNgược lại, AI có thể giúp Senior tập trung vào những việc giá trị cao hơn: Architecture, Technical decision, Mentoring, Code review, Business problem, System design, Performance, Reliability, Security, Planning — thay vì viết CRUD hay boilerplate. Nhưng Senior cũng phải thích nghi, một Senior chỉ giỏi code mà không biết dùng AI có thể mất dần lợi thế.Kết: AI thay đổi vị trí của khoảng cáchAI thu hẹp khoảng cách về tốc độ và khả năng tiếp cận kiến thức. Nhưng khoảng cách vẫn tồn tại ở Context, Judgment, Trade-off, System thinking, Business understanding, Production experience, và đặc biệt là Responsibility.Nếu chọn một kỹ năng quan trọng nhất trong thời đại AI, đó có lẽ không phải "code thật nhanh" hay "biết thật nhiều framework", mà là biết đặt câu hỏi — với AI, với đồng nghiệp, với chính requirement, và với chính mình.Mình có đang sử dụng AI để trở nên giỏi hơn, hay chỉ đang sử dụng AI để làm việc thay mình?AI có thể giúp viết code, tìm bug, học công nghệ mới, thậm chí đưa ra giải pháp tốt hơn bạn nghĩ. Nhưng cuối cùng, AI đưa cho bạn câu trả lời — bạn phải chịu trách nhiệm với câu trả lời đó. Trong thời đại AI, Fresher không cần biết tất cả. Nhưng phải biết hỏi đúng.

AI có đang thu hẹp khoảng cách giữa Fresher và Senior? Câu trả lời ngắn gọn của mình là: có, nhưng chỉ ở phần tốc độ — còn phần tư duy thì gần như không đổi, thậm chí đang bị AI che giấu đi. Nghe có vẻ mâu thuẫn, nhưng đó chính xác là những gì mình quan sát được khi làm việc cùng đồng nghiệp ở nhiều cấp độ trong hơn một năm AI-coding-assistant trở thành công cụ mặc định.1. Những việc trước đây chỉ Senior mới làm được, giờ Fresher đã làm đượcThành thật mà nói, danh sách này khá dài. Viết boilerplate, setup dự án, cấu hình CI/CD cơ bản — trước đây đòi hỏi kinh nghiệm để nhớ hết các bước, giờ chỉ cần mô tả đúng yêu cầu là AI dựng ra gần như hoàn chỉnh. Đọc hiểu codebase lạ cũng không còn là rào cản lớn: Fresher giờ có thể hỏi AI "đoạn code này làm gì, luồng dữ liệu đi đâu" thay vì mất cả ngày dò từng file như trước. Viết unit test, refactor code đơn giản — những việc từng là "đặc quyền" của người có kinh nghiệm vì đòi hỏi sự tỉ mỉ — giờ AI làm nhanh và ít lỗi hơn cả một số Senior lười. Ngay cả debug lỗi phổ biến — stack trace, lỗi cú pháp, lỗi cấu hình — AI cũng xử lý cực nhanh, những thứ mà trước đây Fresher phải hỏi Senior hoặc mất hàng giờ search Stack Overflow.Nhìn vào đây, đúng là ranh giới bị xóa nhòa thật. Một Fresher chăm chỉ, biết dùng AI đúng cách, có thể tạo ra output nhìn "chuyên nghiệp" chỉ sau vài tháng — điều mà trước đây cần 2-3 năm.2. Nhưng khoảng cách thật sự nằm ở đâu?Đây là phần mình muốn nói thẳng, không tô hồng: AI không thu hẹp khoảng cách về năng lực ra quyết định. Và đây mới là thứ phân biệt Fresher với Senior.Thứ nhất, khi AI sai, ai là người nhận ra? AI có thể viết ra một đoạn code chạy được, test pass, nhìn "sạch sẽ" — nhưng lại chọn sai kiến trúc, tạo ra vấn đề về hiệu năng, hoặc vi phạm một ràng buộc nghiệp vụ mà AI không hề biết vì nó không có trong prompt. Senior nhìn vào là thấy ngay "cái này chạy được nhưng sai hướng". Fresher thì thường tin tưởng tuyệt đối vào output vì nó trông có vẻ đúng.Thứ hai, câu hỏi "nên làm gì" quan trọng hơn "làm như thế nào". AI trả lời cực tốt câu hỏi "làm sao để implement X". Nhưng câu hỏi "có nên implement X không, hay vấn đề thực sự nằm ở chỗ khác" thì AI không tự đặt ra được — nó cần người đặt câu hỏi đúng. Đó là kỹ năng chỉ có được từ việc từng bị đấm vào mặt bởi hậu quả của quyết định sai trong quá khứ.Thứ ba — và đây là điều khiến mình phải nói thẳng — khi AI "hết token" hoặc không dùng được, Fresher thường đứng hình. Có không ít Fresher (và cả một số người tự nhận là mid-level), khi bị giới hạn số lượng request/token trong ngày, hoặc gặp sự cố mạng không truy cập được AI, hoặc rơi vào tình huống mà AI liên tục trả lời sai/loop không thoát ra được, thì không biết phải làm gì tiếp theo. Không phải vì họ lười, mà vì họ chưa bao giờ thực sự tự mình đi qua toàn bộ quá trình tư duy — từ đọc lỗi, đặt giả thuyết, kiểm chứng, đến tự tay tra tài liệu gốc. Với họ, AI không phải là "trợ lý" mà đã trở thành "bộ não thay thế". Khi bộ não đó offline, họ mất luôn khả năng tự vận hành.Mình từng chứng kiến một bạn Fresher dùng AI dựng cả một tính năng khá phức tạp trong vài giờ — nhìn rất ấn tượng. Nhưng khi hệ thống gặp sự cố lúc nửa đêm và không thể chờ AI (do rate limit), bạn ấy hoàn toàn không biết bắt đầu từ đâu để đọc log, vì trước giờ mọi lần debug đều là "paste lỗi vào AI, AI trả lời, làm theo". Đó là lúc mình nhận ra: AI không tạo ra Senior nhanh hơn — nó chỉ khiến Fresher trông giống Senior nhanh hơn. Hai điều đó rất khác nhau.Senior thì khác — với họ, AI là một công cụ tăng tốc, không phải nền tảng tư duy. Không có AI, Senior vẫn debug được, chỉ là chậm hơn. Đó chính là khoảng cách thật sự, và nó không hề bị AI thu hẹp — thậm chí còn dễ bị AI che giấu đi, khiến người quản lý lầm tưởng năng lực của Fresher cao hơn thực tế, cho đến khi có sự cố thật xảy ra.3. Vậy điều gì vẫn tạo nên sự khác biệt khi cả hai đều có AI?Khả năng đặt câu hỏi đúng — prompt tốt đến từ hiểu vấn đề tốt, không phải kỹ năng gõ chữ.Trực giác về rủi ro — biết đoạn code nào "trông ổn nhưng sẽ nổ trong production" mà chưa cần chạy thử.Khả năng review chính output của AI — đọc và phản biện, chứ không phải copy-paste.Hiểu bức tranh lớn — AI giỏi giải quyết bài toán cục bộ, nhưng chưa thấy được toàn bộ hệ thống, các ràng buộc nghiệp vụ, lịch sử "tại sao code lại như vậy".Chịu trách nhiệm khi mọi thứ sai — đây là thứ AI không bao giờ làm thay được.Theo mình, kỹ năng mà AI khó thay thế kinh nghiệm thực tế nhất là khả năng chịu đựng sự mơ hồ và tự mình đưa ra quyết định khi thông tin không đầy đủ. Kinh nghiệm thực chất là một tập hợp các "lần đã từng sai" được tích lũy lại. AI có thể cho bạn kiến thức, nhưng không cho bạn "vết sẹo" — và chính vết sẹo đó mới là thứ giúp Senior phản xạ nhanh trong tình huống thực tế căng thẳng, không có thời gian hỏi AI.4. Tổng kết Theo mình, AI đang thu hẹp khoảng cách về tốc độ tạo ra sản phẩm, nhưng khoảng cách về tư duy, phán đoán và khả năng tự vận hành khi không còn AI thì gần như không đổi — thậm chí rủi ro là nó đang bị che giấu, tạo ảo tưởng năng lực cho cả Fresher lẫn nhà tuyển dụng. Bài học thực tế nhất: nếu bạn là Fresher, hãy dùng AI để học nhanh hơn, chứ đừng dùng AI để thay thế việc tự mình tư duy — vì đến một ngày AI "hết token", bạn vẫn phải tự mình biết đường ra.