React Native

Một Fresher sử dụng AI có thể tạo ra trong 30 phút đoạn code mà trước đây họ cần vài ngày để tự nghiên cứu.Nhưng khi đoạn code đó gây lỗi trên production, ai sẽ biết nên kiểm tra ở đâu, đánh giá mức độ ảnh hưởng như thế nào và lựa chọn giải pháp nào ít rủi ro nhất?Đó là điểm khiến tôi nghĩ rằng AI đang thay đổi khoảng cách giữa Fresher và Senior, nhưng không đơn giản theo hướng “Fresher sắp thay thế Senior”.AI đang thu hẹp khoảng cách về tốc độ viết code, khả năng tiếp cận kiến thức và mức độ hoàn thiện của đầu ra. Đồng thời, nó làm nổi bật một khoảng cách khác khó nhìn thấy hơn: khả năng đặt câu hỏi, đánh giá rủi ro và chịu trách nhiệm cho quyết định kỹ thuật.Những việc từng khó với Fresher giờ đã trở nên dễ tiếp cận hơnKhi mới bắt đầu lập trình, một developer có thể mất nhiều thời gian chỉ để hiểu cấu trúc dự án, cách gọi API, quản lý state hoặc xử lý lỗi.Ngày nay, với AI, một Fresher có thể yêu cầu:Tạo một màn hình React Native từ thiết kế.Viết API service và TypeScript interface từ JSON response.Giải thích một đoạn source code cũ.Chuyển class component sang function component.Viết unit test cho một hàm.Phân tích log lỗi build Android hoặc iOS.Đề xuất cách tối ưu component bị re-render nhiều lần.Tạo tài liệu cho một tính năng vừa hoàn thành.Nếu cung cấp đủ bối cảnh, AI có thể tạo ra kết quả khá tốt. Một Fresher biết sử dụng AI thậm chí có thể hoàn thành những task mà vài năm trước thường được giao cho developer có kinh nghiệm hơn.Đây là một thay đổi rất tích cực.Trước đây, Fresher phải dành nhiều thời gian để vượt qua “rào cản cú pháp”: không biết tên API, không nhớ cách cấu hình hoặc chưa từng gặp một lỗi tương tự. AI giúp giảm rào cản đó và cho phép họ tập trung sớm hơn vào logic của sản phẩm.AI cũng giống như một người hướng dẫn luôn sẵn sàng trả lời. Fresher có thể hỏi những câu rất cơ bản mà không sợ bị đánh giá, yêu cầu giải thích lại nhiều lần hoặc nhờ đưa ra ví dụ phù hợp với trình độ hiện tại.Nhờ vậy, tốc độ học có thể nhanh hơn rất nhiều.Nhưng tạo ra code chỉ là một phần của công việc phát triển phần mềm.Khoảnh khắc khiến tôi nhìn AI và kinh nghiệm khác điTrong một ứng dụng mobile, tôi từng xử lý luồng thanh toán qua trình duyệt và nhận kết quả trả về bằng deep link.Nếu chỉ mô tả yêu cầu chính, AI có thể nhanh chóng viết một đoạn code:Mở trang thanh toán.Lắng nghe deep link.Đọc trạng thái giao dịch.Chuyển tới màn hình thành công hoặc thất bại.Đoạn code trông hợp lý và có thể chạy tốt trong lần thử đầu tiên.Nhưng khi đưa vào sản phẩm thực tế, hàng loạt câu hỏi khác xuất hiện:Điều gì xảy ra nếu người dùng thanh toán xong khi ứng dụng đã bị tắt?Nếu ứng dụng chỉ đang ở background thì có nhận được callback không?Nếu deep link được gửi hai lần, giao dịch có bị xử lý hai lần không?Nếu người dùng sửa tham số status=success trong URL thì sao?Nếu callback của luồng nạp tiền và mua thẻ sử dụng các đường dẫn gần giống nhau thì phân biệt thế nào?Màn hình nào sẽ nhận kết quả nếu navigation chưa khởi tạo xong?Dữ liệu trên thiết bị có được xem là nguồn xác nhận thanh toán hay phải kiểm tra lại từ server?AI có thể trả lời từng câu hỏi này.Nhưng vấn đề là ai sẽ nghĩ ra những câu hỏi đó trước khi sự cố xảy ra?Đó là lúc tôi nhận ra giá trị lớn nhất của kinh nghiệm không nằm ở việc Senior nhớ nhiều cú pháp hơn. AI có thể nhớ cú pháp tốt hơn bất kỳ ai.Kinh nghiệm nằm ở khả năng nhìn một yêu cầu đơn giản và thấy được những tình huống ẩn phía sau nó.Fresher thường hỏi: “Làm thế nào để tính năng này chạy?”Senior thường hỏi thêm: “Nó sẽ hỏng trong trường hợp nào?”AI thu hẹp khoảng cách ở đâu?Theo tôi, AI đang thu hẹp rõ nhất ba khoảng cách.1. Khoảng cách về kiến thức có thể tra cứuFresher không còn phải mất nhiều giờ tìm đúng từ khóa hoặc đọc hàng chục câu trả lời không liên quan. AI có thể tổng hợp kiến thức, giải thích theo ngữ cảnh và đề xuất điểm bắt đầu.Điều này không biến Fresher thành Senior ngay lập tức, nhưng giúp họ tiếp cận kiến thức của Senior nhanh hơn.2. Khoảng cách về tốc độ tạo đầu raVới những task có phạm vi rõ ràng, AI giúp Fresher tạo component, test, tài liệu và code mẫu với tốc độ rất cao.Nếu trước đây Senior nhanh hơn vì đã từng viết đoạn code tương tự, lợi thế đó hiện không còn lớn như trước.3. Khoảng cách về khả năng thử nghiệmFresher có thể nhanh chóng tạo nhiều phương án và so sánh chúng. Thay vì chỉ học lý thuyết, họ có thể yêu cầu AI tạo ví dụ, chạy thử, sửa lỗi và quan sát kết quả.Vòng lặp học tập trở nên ngắn hơn. Một developer có thái độ học đúng có thể tiến bộ với tốc độ mà trước đây rất khó đạt được.Khi cả Fresher và Senior đều có AI, điều gì tạo ra khác biệt?Nếu cả hai cùng sử dụng một công cụ, lợi thế không còn nằm ở việc ai có AI.Lợi thế nằm ở việc ai cung cấp bối cảnh tốt hơn, đặt câu hỏi chính xác hơn và nhận ra khi câu trả lời có vấn đề.Cùng đứng trước một đoạn code do AI tạo ra, Fresher có thể thấy:“Code sạch, không báo lỗi và chạy đúng yêu cầu.”Senior có thể nhìn thấy thêm:Đoạn code này có tạo listener mới mỗi lần component render không?Có rò rỉ bộ nhớ khi màn hình bị unmount không?Có ảnh hưởng tới phiên bản hệ điều hành cũ không?Thư viện được đề xuất có còn được duy trì không?Giải pháp có vi phạm kiến trúc hiện tại của dự án không?Nếu API chậm hoặc trả dữ liệu thiếu thì giao diện sẽ thế nào?Sau sáu tháng, đội ngũ có dễ bảo trì đoạn code này không?Khác biệt không nhất thiết nằm ở câu trả lời. Nó nằm ở số lượng và chất lượng của những câu hỏi được đặt ra trước khi chấp nhận câu trả lời.AI khuếch đại năng lực sẵn có của người sử dụng.Một Fresher có nền tảng tốt và tư duy phản biện sẽ học nhanh hơn. Một Senior có kinh nghiệm và biết dùng AI sẽ xử lý được phạm vi công việc lớn hơn.Ngược lại, nếu quá phụ thuộc vào AI, Fresher có thể tạo ra nhiều code hơn nhưng hiểu ít hơn. Senior cũng có thể mắc sai lầm nếu tin vào câu trả lời chỉ vì nó được trình bày thuyết phục.Những bài học vẫn cần trải nghiệm thực tếCó những kiến thức có thể đọc trong vài phút nhưng cần nhiều lần va chạm mới thực sự hiểu.Bạn có thể đọc rằng không nên chỉnh sửa production vào cuối ngày thứ Sáu. Nhưng cảm giác phải tìm nguyên nhân một lỗi nghiêm trọng khi người dùng đang chờ là một bài học hoàn toàn khác.Bạn có thể hỏi AI cách thiết kế kiến trúc tốt. Nhưng chỉ sau khi từng bảo trì một source code được xây quá phức tạp, bạn mới hiểu vì sao giải pháp đơn giản thường có giá trị.Bạn có thể học quy trình review code. Nhưng cần trải nghiệm làm việc trong đội nhóm để biết khi nào nên bảo vệ quan điểm kỹ thuật, khi nào nên thỏa hiệp và cách phản hồi mà không biến một cuộc thảo luận thành xung đột.Một số năng lực rất khó có được chỉ bằng câu trả lời của AI:Ước lượng công việc khi yêu cầu còn mơ hồ.Đưa ra quyết định khi không có phương án hoàn hảo.Xử lý sự cố production dưới áp lực.Hiểu ảnh hưởng của một thay đổi tới người dùng và hoạt động kinh doanh.Giao tiếp với product, design, backend và khách hàng.Biết lúc nào nên tiếp tục tối ưu và lúc nào sản phẩm đã “đủ tốt”.Chịu trách nhiệm cho kết quả thay vì chỉ hoàn thành phần code được giao.AI có thể mô phỏng tình huống và đưa ra lời khuyên. Nhưng trải nghiệm thật tạo ra trực giác: cảm giác rằng một chi tiết nào đó “có vẻ không ổn” dù chưa xuất hiện lỗi rõ ràng.Trực giác kỹ thuật không phải phép thuật. Nó là kết quả của nhiều lần sai, sửa và ghi nhớ.Senior trong thời đại AI không nên chỉ là người code nhanh hơnNếu giá trị của Senior chỉ nằm ở việc viết code nhanh, AI chắc chắn sẽ làm lợi thế đó giảm đi.Theo tôi, vai trò của Senior cần dịch chuyển từ “người biết nhiều đáp án” sang:Người xác định đúng vấn đề.Người đưa ra tiêu chuẩn để đánh giá đáp án.Người quản lý rủi ro kỹ thuật.Người giúp đội ngũ tránh những sai lầm đắt giá.Người biến kinh nghiệm cá nhân thành kiến thức chung.Người hướng dẫn Fresher hiểu code, không chỉ tạo ra code.Một Senior tốt không nên dùng kinh nghiệm để giữ khoảng cách với Fresher. Họ nên dùng AI và kinh nghiệm để giúp Fresher rút ngắn con đường phát triển.Và Fresher cũng không nên xem AI là đường tắt để bỏ qua nền tảng.AI có thể viết một custom hook, nhưng developer vẫn cần hiểu lifecycle.AI có thể tối ưu một danh sách, nhưng developer vẫn cần hiểu nguyên nhân gây re-render.AI có thể sửa lỗi, nhưng developer cần biết vì sao cách sửa đó đúng và nó có thể tạo ra lỗi mới ở đâu.Nếu chỉ sao chép kết quả, Fresher sẽ hoàn thành task nhanh hơn nhưng không tích lũy được kinh nghiệm. Khi gặp một vấn đề nằm ngoài những gì AI nhìn thấy, họ sẽ tiếp tục bị phụ thuộc.Khoảng cách không biến mất, nó đang đổi hình dạngTrước AI, khoảng cách giữa Fresher và Senior thường thể hiện qua tốc độ viết code, lượng kiến thức ghi nhớ và số vấn đề từng gặp.Sau AI, khoảng cách về code và kiến thức có thể thu hẹp đáng kể.Nhưng khoảng cách về phán đoán, trách nhiệm, hiểu sản phẩm và khả năng ra quyết định vẫn còn. Trong một số trường hợp, nó thậm chí trở nên rõ hơn vì AI cho phép mọi người tạo ra nhiều code với tốc độ cao hơn — bao gồm cả code tốt lẫn code tạo thêm rủi ro.Vì vậy, tôi không nghĩ AI làm kinh nghiệm mất giá.AI làm những kinh nghiệm chỉ dùng để ghi nhớ cú pháp mất giá. Đồng thời, nó làm những kinh nghiệm liên quan đến tư duy hệ thống, đánh giá rủi ro và hiểu con người trở nên giá trị hơn.Kết luậnAI có thể giúp Fresher làm được những task từng cần Senior. Nhưng “làm được một task” và “chịu trách nhiệm cho toàn bộ kết quả” là hai cấp độ khác nhau.Một Fresher dùng AI tốt có thể tiến bộ rất nhanh.Một Senior dùng AI tốt có thể mở rộng đáng kể phạm vi ảnh hưởng.Người gặp khó khăn nhất có lẽ không phải Fresher hay Senior, mà là developer ngừng học vì nghĩ AI đã có thể suy nghĩ thay mình.Theo tôi, ranh giới mới giữa các cấp độ kinh nghiệm không còn là:“Bạn có thể viết đoạn code này không?”Mà là:“Bạn có biết đoạn code này có nên được viết, có thể sai ở đâu và ai sẽ bị ảnh hưởng khi nó sai không?”AI đang thu hẹp khoảng cách giữa đôi tay của Fresher và Senior.Nhưng khoảng cách giữa hai cách tư duy vẫn phải được rút ngắn bằng trải nghiệm, trách nhiệm và sự chủ động học hỏi.Còn bạn nghĩ sao: AI đang giúp Fresher tiến gần Senior hơn, hay đang giúp Senior tiến xa hơn nữa?

Trước khi dùng AI, tôi mất hai giờ để viết một tính năng và một giờ để kiểm tra.Sau khi dùng AI, tôi có thể viết tính năng đó trong 30 phút. Nhưng thay vì được nghỉ sớm hơn 90 phút, tôi thường nhận thêm hai tính năng mới, review nhiều code hơn và phải đảm bảo chất lượng cao hơn trước.Ngày làm việc vẫn đủ tám tiếng.Chỉ có lượng công việc hoàn thành trong tám tiếng đó tăng lên.Là một mobile developer làm việc chủ yếu với React Native, tôi dùng AI gần như mỗi ngày: đọc lỗi build, gợi ý code, tạo cấu trúc màn hình, viết hàm xử lý dữ liệu, giải thích source code cũ và chuẩn bị tài liệu kỹ thuật.Không thể phủ nhận rằng AI giúp tôi làm việc nhanh hơn. Nhưng sau một thời gian sử dụng thường xuyên, tôi nhận ra một nghịch lý:AI tiết kiệm thời gian cho từng công việc, nhưng chưa chắc tiết kiệm thời gian cho người làm công việc đó.Quy trình làm việc của tôi đã thay đổi như thế nào?Trước đây, khi gặp một lỗi Android hoặc iOS, quy trình quen thuộc của tôi thường là:Đọc log → tìm kiếm trên Google → mở nhiều trang Stack Overflow hoặc GitHub Issues → thử từng cách → build lại → tiếp tục sửa.Có những lỗi mất vài giờ chỉ để xác định nguyên nhân.Hiện tại, tôi có thể đưa log lỗi cùng những phần cấu hình liên quan cho AI. Trong vài phút, AI có thể phân tích các khả năng, giải thích mối liên hệ giữa phiên bản thư viện, Gradle, Kotlin, CocoaPods hoặc React Native và đề xuất hướng kiểm tra.Khi cần xây một tính năng mới, tôi cũng không còn bắt đầu hoàn toàn từ trang trắng. AI có thể tạo bộ khung component, TypeScript interface, API service, validation và các trường hợp cần xử lý.Nhưng quy trình không thực sự mất đi nhiều bước. Nó chỉ được thay đổi thành:Mô tả vấn đề → cung cấp bối cảnh → nhận đề xuất từ AI → đọc và kiểm chứng → sửa lại → chạy thử → kiểm tra trên thiết bị thật → review tác động tới phần còn lại của ứng dụng.Một số bước cũ được rút ngắn, nhưng các bước mới xuất hiện: viết yêu cầu đủ rõ, đánh giá câu trả lời và phát hiện những chỗ AI tự tin nhưng không chính xác.Tôi viết code ít hơn, nhưng review nhiều hơn.30 phút tạo code có thể kéo theo hai giờ kiểm traĐiều nguy hiểm nhất ở code do AI tạo ra không phải là code sai hoàn toàn. Nếu sai rõ ràng, chúng ta có thể phát hiện ngay.Nguy hiểm hơn là đoạn code nhìn rất hợp lý, chạy được trong trường hợp thông thường nhưng sai ở những tình huống đặc biệt.Ví dụ, AI có thể đề xuất một API đã bị thay đổi ở phiên bản thư viện tôi đang sử dụng. Nó có thể viết một luồng đăng nhập hoạt động tốt trên Android nhưng thiếu cấu hình cần thiết trên iOS. Nó cũng có thể tạo logic xử lý thanh toán đúng khi giao dịch thành công nhưng bỏ sót trường hợp người dùng hủy, ứng dụng bị đưa xuống background hoặc deep link được mở khi app chưa khởi động.Nếu tôi tin ngay vào kết quả và sao chép vào dự án, thời gian “tiết kiệm” lúc viết code có thể trở thành thời gian sửa lỗi sau khi phát hành.Đặc biệt với mobile app, một đoạn code không chỉ cần chạy trên máy của developer. Nó còn phải hoạt động trên nhiều phiên bản hệ điều hành, kích thước màn hình, trạng thái mạng và vòng đời ứng dụng khác nhau.Vì vậy, AI càng tạo code nhanh, tôi càng phải giữ kỷ luật kiểm chứng:Đọc lại logic thay vì chỉ nhìn kết quả chạy được.Kiểm tra tài liệu chính thức của thư viện.Test cả Android và iOS.Thử các trường hợp mất mạng, bấm nhiều lần hoặc đưa app xuống background.Đảm bảo giải pháp không làm hỏng những tính năng đang hoạt động.Không đưa dữ liệu nhạy cảm hoặc thông tin người dùng vào công cụ AI.AI giúp giảm thời gian gõ code. Nhưng trách nhiệm về chất lượng, bảo mật và trải nghiệm người dùng vẫn thuộc về developer.Khi mọi người đều có AI, “nhanh” trở thành tiêu chuẩn mớiThời gian đầu, hoàn thành một công việc sớm hơn dự kiến tạo ra cảm giác rất tích cực.Nhưng khi tốc độ đó lặp lại đủ nhiều, nó không còn được xem là một thành tích đặc biệt. Nó dần trở thành tốc độ mặc định.Một task từng được ước tính ba ngày có thể được kỳ vọng hoàn thành trong một ngày. Một bản demo trước đây chỉ cần thể hiện luồng chính, nay có thể được yêu cầu thêm giao diện đẹp, xử lý đầy đủ trường hợp lỗi và có tài liệu đi kèm.Khi AI giúp tạo ra ba phương án nhanh chóng, câu hỏi tiếp theo thường không phải là “Bạn có thể nghỉ sớm không?”, mà là:“Có thể làm thêm phương án thứ tư không?”Đây không hẳn là lỗi của AI, cũng không hoàn toàn là lỗi của quản lý hay khách hàng. Nó là kết quả tự nhiên khi năng suất chung tăng lên. Khi công cụ thay đổi, kỳ vọng về tốc độ và chất lượng cũng thay đổi theo.Điều đáng chú ý là AI không chỉ giúp tôi hoàn thành công việc cũ nhanh hơn. Nó còn khiến những công việc từng bị xem là “không đủ thời gian để làm” trở nên khả thi.Tôi có thể viết tài liệu kỹ hơn, thêm test case, phân tích log sâu hơn, thử nhiều phương án UI hơn hoặc chủ động cải thiện những đoạn source code cũ.Kết quả là sản phẩm tốt hơn, nhưng danh sách việc cần làm cũng dài hơn.AI có tạo thêm công việc không?Có, theo một cách khá thú vị.Khi việc tạo prototype trở nên dễ dàng, chúng ta thử nhiều ý tưởng hơn. Mỗi ý tưởng lại cần được đánh giá, chỉnh sửa và quyết định có tiếp tục hay không.Khi AI giúp tìm thấy nhiều vấn đề tiềm ẩn trong source code, chúng ta có thêm một danh sách cần xử lý.Khi AI có thể viết tài liệu nhanh, tiêu chuẩn mới có thể trở thành “mọi tính năng đều phải có tài liệu”.AI không chỉ hoàn thành công việc. Nó còn mở ra những công việc trước đây chúng ta chưa có khả năng hoặc thời gian để nhìn thấy.Có lúc tôi hỏi AI cách tối ưu một màn hình bị giật. Tôi chỉ muốn tìm một nguyên nhân, nhưng nhận lại hàng loạt đề xuất: giảm re-render, tối ưu danh sách, cache dữ liệu, kiểm tra kích thước ảnh, theo dõi memory và đo thời gian render.Câu trả lời giúp tôi tiết kiệm thời gian nghiên cứu, đồng thời tạo ra thêm một danh sách việc phải làm.Tôi gọi đó là “nợ năng suất”: khi có khả năng làm nhiều hơn, chúng ta bắt đầu cảm thấy mình nên làm tất cả.Vậy AI có thật sự giúp tôi làm ít đi không?Nếu xét trên từng task, câu trả lời là có.Nếu xét trên toàn bộ ngày làm việc, câu trả lời của tôi là chưa.AI chưa giúp tôi có thêm nhiều thời gian rảnh. Nó giúp tôi hoàn thành nhiều việc hơn trong cùng một khoảng thời gian. Chất lượng đầu ra cao hơn, khả năng thử nghiệm nhanh hơn và thời gian mắc kẹt với những vấn đề nhỏ giảm đi đáng kể.Điều đó vẫn rất có giá trị.Tuy nhiên, tôi nhận ra rằng thời gian tiết kiệm được chỉ trở thành thời gian rảnh khi chính chúng ta chủ động bảo vệ nó. Nếu không, mọi khoảng trống vừa được AI tạo ra sẽ nhanh chóng được lấp đầy bằng một task mới, một ý tưởng mới hoặc một yêu cầu cao hơn.Tôi đang học cách dùng AI để làm việc tốt hơn, không chỉ nhiều hơnThay vì hỏi “AI có thể giúp tôi làm thêm gì?”, tôi bắt đầu hỏi ba câu khác:Việc này có thực sự cần làm không?Kết quả nào là đủ tốt ở giai đoạn hiện tại?Phần thời gian tiết kiệm được nên dành cho task tiếp theo hay để suy nghĩ kỹ hơn?Tôi cũng cố gắng không đánh giá năng suất chỉ bằng số lượng task hoàn thành. Một giờ dùng để nói chuyện với người dùng, thiết kế kiến trúc đúng hoặc ngăn một lỗi nghiêm trọng có thể giá trị hơn cả ngày tạo ra thật nhiều code.AI giúp tăng tốc đôi tay, nhưng chúng ta vẫn cần dùng kinh nghiệm để chọn hướng đi.Nếu đi sai hướng, chạy nhanh hơn chỉ khiến chúng ta cách mục tiêu xa hơn.Kết luậnAI thực sự giúp tôi làm việc nhanh hơn, nhưng chưa làm tôi làm việc ít hơn.Nó biến thời gian chờ đợi thành thời gian thực hiện, biến những ý tưởng từng mất nhiều ngày thành prototype trong vài giờ và giúp một developer có thể đảm nhận nhiều vai trò hơn.Đổi lại, khối lượng đầu ra tăng, tiêu chuẩn chất lượng cao hơn và trách nhiệm kiểm chứng cũng lớn hơn.Với tôi, câu hỏi quan trọng không còn là:“AI giúp tiết kiệm được bao nhiêu giờ?”Mà là:“Ai sẽ quyết định cách sử dụng những giờ vừa tiết kiệm được?”Nếu câu trả lời luôn là deadline tiếp theo, AI chỉ giúp chúng ta bận rộn hiệu quả hơn.Còn nếu chúng ta dùng khoảng thời gian đó để học hỏi, suy nghĩ sâu hơn, chăm sóc sức khỏe hoặc đơn giản là kết thúc công việc đúng giờ, khi ấy AI mới thật sự giúp con người làm việc ít đi.Còn bạn thì sao? Từ khi dùng AI, bạn có thêm thời gian rảnh hay chỉ có thêm nhiều task đã hoàn thành hơn?

Hai tuần để xây xong một tính năng. Hai tháng để nhận ra mình đã xây sai thứ.Đó là trải nghiệm khiến tôi hiểu rằng: AI có thể rút ngắn đáng kể thời gian phát triển sản phẩm, nhưng không tự động rút ngắn khoảng cách từ một sản phẩm “chạy được” đến một sản phẩm “có người dùng và tạo ra doanh thu”.Tôi là một mobile developer, chủ yếu làm việc với React Native. Khi AI coding ngày càng mạnh, quy trình phát triển của tôi thay đổi rất rõ. Những công việc từng mất nhiều giờ như dựng màn hình, viết API service, xử lý validation, tìm nguyên nhân lỗi build Android/iOS hay viết tài liệu kỹ thuật giờ có thể hoàn thành nhanh hơn rất nhiều.Có lần, tôi cần phát triển một tính năng lập lộ trình cho xe điện: người dùng chọn loại xe, mức pin hiện tại, điểm đến và các trạm sạc phù hợp trên đường đi. AI giúp tôi đề xuất cấu trúc dữ liệu, công thức ước tính mức tiêu thụ pin, cách chia màu tuyến đường theo lượng pin còn lại và cả những trường hợp cần xử lý khi người dùng đi lệch tuyến.Chỉ trong thời gian ngắn, tôi đã có một phiên bản demo khá hoàn chỉnh.Nhìn trên màn hình, mọi thứ đều hợp lý.Nhưng khi đưa cho người dùng thử, câu hỏi đầu tiên tôi nhận được lại là:“Thông tin trạm sạc này có chính xác không?”Không ai hỏi thuật toán chia màu tuyến đường được viết thế nào. Không ai quan tâm tôi đã tối ưu bao nhiêu component hay tiết kiệm được bao nhiêu ngày lập trình. Điều họ cần biết là liệu có thể tin vào sản phẩm khi đang chạy xe ngoài đường, pin sắp hết và trạm sạc gần nhất có thể cách hàng chục kilomet hay không.Khoảnh khắc đó khiến tôi nhận ra bức tường lớn nhất không nằm ở việc viết code.Nó nằm ở niềm tin của người dùng.Xây nhanh hơn không có nghĩa là hiểu người dùng nhanh hơnAI rất giỏi khi yêu cầu đã rõ ràng. Nhưng trong quá trình xây sản phẩm, phần khó nhất thường là xác định yêu cầu nào thực sự đáng để làm.Developer rất dễ bị cuốn vào những tính năng thú vị về mặt kỹ thuật. Chúng ta có thể dành nhiều ngày tối ưu animation, kiến trúc source code hoặc một thuật toán phức tạp, trong khi người dùng chỉ cần ba điều đơn giản:Thông tin có chính xác không?Thao tác có đủ dễ không?Sản phẩm có giải quyết được vấn đề ngay lúc họ cần không?AI có thể tạo ra mười phương án giao diện trong vài phút, nhưng không thể thay tôi quan sát một người dùng loay hoay vì không biết phải nhấn nút nào.AI có thể phân tích dữ liệu phản hồi, nhưng không tự cảm nhận được sự do dự khi người dùng chuẩn bị thanh toán.AI có thể viết nội dung quảng cáo rất hấp dẫn, nhưng không thể tạo ra niềm tin nếu sản phẩm chưa chứng minh được giá trị.Tốc độ phát triển tăng lên đôi khi còn tạo ra một chiếc bẫy: vì làm tính năng mới quá nhanh, chúng ta dễ lựa chọn xây thêm thay vì dừng lại để hỏi xem tính năng cũ có thật sự hữu ích hay không.Phần khó hơn tôi dự kiến: có sản phẩm rồi, tìm người dùng ở đâu?Trước đây, tôi từng nghĩ hành trình phát triển sản phẩm diễn ra theo một đường khá thẳng:Ý tưởng → xây dựng → phát hành → có người dùng → tạo doanh thu.Thực tế lại giống như:Ý tưởng → xây dựng → phát hiện giả định sai → sửa → tìm người dùng → không ai chú ý → thay đổi cách giới thiệu → có vài người dùng thử → họ rời đi → tiếp tục tìm nguyên nhân.Đưa ứng dụng lên App Store hay Google Play chỉ giúp sản phẩm tồn tại. Nó không khiến sản phẩm được khám phá.Một sản phẩm tốt nhưng không có kênh phân phối phù hợp vẫn có thể không có người dùng. Một tính năng hữu ích nhưng được mô tả bằng ngôn ngữ kỹ thuật cũng khó khiến khách hàng hiểu được giá trị. Và nếu người dùng thử một lần rồi không quay lại, việc có thêm lượt tải xuống cũng chưa tạo ra một sản phẩm bền vững.AI có thể giúp tôi viết bài giới thiệu, tạo hình ảnh hoặc đề xuất kế hoạch marketing. Tuy nhiên, những quyết định quan trọng vẫn cần trải nghiệm và hiểu biết thực tế:Nhóm người dùng đầu tiên là ai?Họ đang ở đâu?Vấn đề có đủ lớn để họ thay đổi thói quen không?Vì sao họ nên tin một sản phẩm mới?Điều gì khiến họ quay lại lần thứ hai?Giá trị nào đủ lớn để họ sẵn sàng trả tiền?Đây không còn là bài toán của riêng lập trình. Nó là bài toán về sản phẩm, phân phối, tâm lý và niềm tin.Những việc tôi vẫn chưa thể giao hoàn toàn cho AISau quá trình sử dụng AI để phát triển sản phẩm, tôi thấy có ba việc vẫn phụ thuộc rất nhiều vào con người.Thứ nhất là chọn đúng vấn đề.AI có thể gợi ý hàng trăm ý tưởng, nhưng người xây sản phẩm phải xác định vấn đề nào đang xảy ra đủ thường xuyên, đủ đau và có một nhóm người thực sự muốn giải quyết.Thứ hai là đọc được điều người dùng không nói trực tiếp.Người dùng có thể nói “ứng dụng hơi khó dùng”, nhưng nguyên nhân thật sự có thể là họ không tin dữ liệu, không hiểu lợi ích hoặc sợ thực hiện sai thao tác. Muốn tìm được nguyên nhân, chúng ta phải quan sát, hỏi tiếp và đặt phản hồi vào đúng bối cảnh.Thứ ba là đưa ra sự đánh đổi.Một startup hoặc đội sản phẩm luôn có giới hạn về thời gian, con người và ngân sách. Nên làm thêm tính năng, sửa trải nghiệm hiện tại hay tập trung tìm kênh phân phối? AI có thể phân tích lựa chọn, nhưng người chịu trách nhiệm vẫn phải quyết định và chấp nhận rủi ro.Nếu bắt đầu lại, tôi sẽ làm gì khác?Tôi vẫn sử dụng AI, thậm chí sử dụng nhiều hơn. Nhưng tôi sẽ thay đổi thứ tự ưu tiên.Trước khi viết quá nhiều code, tôi sẽ tìm từ 5 đến 10 người thuộc đúng nhóm khách hàng và trò chuyện với họ. Tôi muốn biết lần gần nhất họ gặp vấn đề là khi nào, hiện tại họ giải quyết bằng cách nào và điều gì khiến giải pháp đó chưa đủ tốt.Sau đó, tôi sẽ tạo phiên bản nhỏ nhất có thể kiểm chứng một giả định quan trọng. Không phải MVP có thật nhiều tính năng, mà là một sản phẩm đủ nhỏ để trả lời câu hỏi: “Người dùng có thật sự cần điều này không?”Tôi cũng sẽ nghĩ về phân phối ngay từ ngày đầu tiên:Ai sẽ là nhóm người dùng đầu tiên?Kênh nào có thể tiếp cận họ?Vì sao họ muốn chia sẻ sản phẩm cho người khác?Sản phẩm tạo ra giá trị trước hay chỉ yêu cầu người dùng đăng ký, cung cấp thông tin và trả tiền?Cuối cùng, tôi sẽ đo lường hành vi thay vì chỉ đếm lượt tải. Người dùng có hoàn thành hành động quan trọng không? Họ có quay lại không? Họ rời đi ở bước nào? Họ có sẵn sàng giới thiệu sản phẩm không?AI làm giảm chi phí xây dựng, nhưng làm tăng giá trị của việc lựa chọn đúngKhi bất kỳ ai cũng có thể tạo ra một ứng dụng nhanh hơn, lợi thế cạnh tranh sẽ không còn chỉ nằm ở khả năng viết code.Lợi thế sẽ thuộc về người hiểu khách hàng sâu hơn, kiểm chứng giả định sớm hơn, xây dựng được niềm tin và tìm ra cách đưa sản phẩm đến đúng người.AI có thể là một developer làm việc không biết mệt, một người hỗ trợ nghiên cứu hay một cộng sự giúp chúng ta thử nghiệm ý tưởng nhanh hơn. Nhưng AI không thể thay chúng ta gặp người dùng, chịu trách nhiệm cho lựa chọn và quyết định điều gì thực sự đáng để xây.Bài học lớn nhất của tôi là:Đừng dùng tốc độ của AI để xây thật nhanh một sản phẩm mà chưa ai cần. Hãy dùng tốc độ đó để học về người dùng nhanh hơn đối thủ.Còn với bạn, bức tường lớn nhất sau khi xây xong sản phẩm là gì: tìm người dùng đầu tiên, khiến họ quay lại hay thuyết phục họ trả tiền?

Chào anh em, dạo gần đây lướt các group tuyển dụng IT hoặc trò chuyện trà đá, chúng ta rất dễ bắt gặp những câu hỏi kiểu: "Bây giờ học Go hay Rust để lương cao hơn?", "Java lỗi thời rồi, chuyển sang Node.js lương có khá hơn không?", hay "Có phải cứ biết Python, AI là auto ngàn đô?"...Tôi từng là một kẻ tin sái cổ vào cái "truyền thuyết" ấy. Tôi từng nghĩ đơn giản: Tech stack càng hot, càng ít người làm được thì lương càng cao.Nhưng sau gần 8 năm lăn lộn từ Outsourcing đến Product, từ các công ty startup quy mô 5 người cho đến tập đoàn lớn, tôi nhận ra: Tech stack chỉ là "bề nổi của tảng băng chìm". Nó có thể quyết định mức lương khởi điểm của bạn ở một công ty mới, nhưng KHÔNG quyết định được trần thu nhập (salary ceiling) của bạn.Dưới đây là câu chuyện xương máu của tôi về một lần "nhảy stack" vì tiền và những bài học đắt giá tôi đúc kết được.1. Cú ngã "trần trụi" khi chạy theo tiếng gọi của "Stack Hot"Cách đây 4 năm, khi làn sóng Blockchain và Web3 bùng nổ, đi đâu tôi cũng nghe thấy những con số giật mình: "Developer viết Rust/Solidity lương 4000 - 5000 USD/tháng". Lúc đó, tôi đang là một Web Developer cứng cựa với Node.js và React, mức lương khá ổn định nhưng nhìn con số kia thì không khỏi lung lay.Nghĩ là làm, tôi lao vào "vibe coding" ngày đêm. Tôi học cú pháp Rust, clone các repo ví mẫu, viết vài cái smart contract cơ bản. Sau 2 tháng học cấp tốc, tôi tự tin apply vào một dự án Web3 của nước ngoài với mức lương deal cao hơn 50% mức cũ.Và... quả đắng xuất hiện ngay từ tháng thử việc thứ hai.Khi dự án bước vào giai đoạn scale up, đòi hỏi tối ưu hóa bộ nhớ, xử lý concurrency cực đoan và bảo mật smart contract để tránh bị hack (vốn là chuyện cơm bữa trong Web3), tôi bắt đầu đuối sức. Tôi chỉ biết viết code cho chạy được, chứ hoàn toàn rỗng tuếch về:Cách hoạt động sâu bên dưới của Memory Management (đặc biệt là cơ chế Borrow Checker cực kỳ nghiêm ngặt của Rust).Kiến thức về cryptography (mã hóa) và bảo mật hệ thống phân tán.Tư duy giải quyết bài toán tài chính phức tạp của hệ thống DeFi.Kết quả là hệ thống liên tục gặp bug nghẽn mạng, code của tôi liên tục bị Senior từ chối merge. Áp lực kinh khủng khiến tôi mất ngủ triền miên. Cuối cùng, tôi chủ động xin dừng lại vì nhận ra mình đang giữ một chiếc áo quá rộng. Tôi chọn đổi stack vì tiền, nhưng năng lực thực tế của tôi chỉ nằm ở mức "biết cú pháp" chứ chưa làm chủ được công nghệ đó.2. Thấu hiểu bản chất: Điều gì thực sự quyết định mức lương IT?Sau thất bại đó, tôi quay lại làm việc với Node.js và hệ sinh thái Web truyền thống nhưng với một tâm thế hoàn toàn khác. Thay vì chạy theo ngôn ngữ mới, tôi tập trung đào sâu những thứ "bất biến" trong công nghệ.Tôi nhận ra mức lương của một Developer được cấu thành từ 3 yếu tố cốt lõi (Tỷ lệ 20-50-30):Tech Stack (20%): Chỉ là công cụ truyền tải giải pháp. Biết Rust hay Java không quan trọng bằng việc bạn biết dùng nó để giải quyết vấn đề gì.Domain Knowledge - Kiến thức nghiệp vụ (50%): Đây mới là thứ hái ra tiền. Một Node.js Dev thông thường lương có thể là $1,500. Nhưng một Node.js Dev hiểu sâu về hệ thống thanh toán điện tử (Payment Gateway), biết cách xử lý đối soát, chống gian lận tài chính và đạt chứng chỉ bảo mật PCI-DSS thì mức lương hoàn toàn có thể là $3,500+. Họ trả tiền cho sự am hiểu ngành nghề của bạn, không phải trả tiền cho số dòng code bạn gõ.Problem Solving & Soft Skills (30%): Khả năng đàm phán, quản lý rủi ro, tối ưu hóa chi phí cloud và trình bày giải pháp kỹ thuật cho những người không làm kỹ thuật hiểu.3. 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ì đã thử học Rust, nhưng tôi sẽ thay đổi cách tiếp cận. Thay vì nhảy stack bạt mạng vì trào lưu, tôi khuyên anh em nên áp dụng chiến lược T-Shape Developer:Trục ngang (Biết rộng): Hiểu nguyên lý hoạt động của các stack khác nhau để khi cần có thể phối hợp hoặc chuyển đổi nhanh chóng.Trục dọc (Sâu sắc): Chọn một stack cốt lõi và biến mình thành chuyên gia trong lĩnh vực đó. Trở thành người "không thể thay thế" ở một mảng thay vì việc gì cũng biết nhưng chỉ ở mức hời hợt.Tập trung vào "Bài toán khó" thay vì "Ngôn ngữ mới": Nếu công ty bạn đang gặp vấn đề về lag database, hãy chủ động đứng ra giải quyết (bằng cách tối ưu index, query, caching...). Việc bạn giải quyết được "nỗi đau" của doanh nghiệp sẽ trực tiếp giúp bạn có vị thế cực lớn khi đàm phán lương (Performance Review), bất kể bạn đang dùng PHP, Java hay Go.Lời kết cho anh em: Đừng thần thánh hóa bất kỳ tech stack nào. Ngôn ngữ lập trình suy cho cùng chỉ là những chiếc tuốc-nơ-vít khác nhau trong hộp đồ nghề của bạn. Người thợ giỏi được trả lương cao không phải vì họ sở hữu chiếc tuốc-nơ-vít đắt tiền nhất, mà vì họ biết cách sửa những cỗ máy phức tạp nhất.Chúc anh em tìm được trục dọc của đời mình và bứt phá thu nhập trong kỳ review sắp tới!