IT Story

AI đang dần trở thành một phần quen thuộc trong cuộc sống. Từ một công nghệ từng được nhắc đến chủ yếu trong các phòng nghiên cứu, AI nay đã xuất hiện ngay trên chiếc điện thoại, máy tính và trong nhiều công việc thường ngày. Người ta dùng AI để tìm kiếm thông tin, học tập, viết nội dung, tạo hình ảnh, làm video, phân tích dữ liệu hay hỗ trợ kinh doanh. Có thể nói, nhàn cũng nhờ AI mà nhọc cũng nhờ AI.Với những công việc trước đây mất nhiều thời gian, AI có thể trở thành một trợ lý hữu ích. Một người bán hàng trực tuyến có thể nhờ AI viết nội dung giới thiệu sản phẩm, trả lời những câu hỏi thường gặp hoặc hỗ trợ chăm sóc khách hàng. Người làm văn phòng có thể dùng AI để tóm tắt tài liệu, soạn thảo văn bản, phân tích bảng tính hay tìm kiếm thông tin. Học sinh, sinh viên có thể nhờ AI giải thích một khái niệm khó, gợi ý cách học hoặc hỗ trợ tìm hướng giải quyết một bài toán.Sự tiện lợi ấy khiến nhiều công việc trở nên “nhàn” hơn. Thay vì mất hàng giờ để tìm kiếm và tổng hợp thông tin, người dùng có thể nhận được câu trả lời trong thời gian ngắn. Một câu lệnh cụ thể, rõ ràng thậm chí có thể giúp AI tạo ra một bài viết, hình ảnh, bản trình bày hoặc ý tưởng gần như ngay lập tức.Nhưng AI không phải lúc nào cũng làm con người nhàn hơn.Khi đã quen với việc đặt câu hỏi và chờ AI đưa ra câu trả lời, con người có thể trở nên phụ thuộc. Một bài viết do AI tạo ra có thể nhanh nhưng chưa chắc chính xác. Một thông tin được trình bày rất thuyết phục vẫn có thể chứa sai sót. Một bức ảnh đẹp chưa chắc phản ánh đúng sự thật. Nếu chỉ sao chép kết quả mà không kiểm tra, người sử dụng rất dễ biến sự tiện lợi của AI thành một rủi ro.Đáng chú ý hơn, AI còn làm thay đổi chính cách con người làm việc. Những công việc đơn giản có thể được tự động hóa, nhưng đồng thời lại xuất hiện yêu cầu mới: biết đặt câu hỏi, biết kiểm chứng thông tin, biết đánh giá kết quả và biết sử dụng AI đúng mục đích. Vì vậy, AI có thể làm công việc nhẹ đi, nhưng không thể làm thay trách nhiệm của con người.AI cũng đang được ứng dụng ngày càng rộng rãi trong giáo dục, y tế, sản xuất, kinh doanh, giao thông, truyền thông và nhiều lĩnh vực khác. Tại Việt Nam, việc phát triển và ứng dụng AI được xem là một hướng quan trọng trong quá trình chuyển đổi số và phát triển kinh tế số.Tuy nhiên, cùng với cơ hội là những vấn đề cần được quan tâm như nguy cơ mất việc ở một số ngành nghề, thông tin sai lệch, quyền riêng tư, việc sử dụng AI cho mục đích xấu và sự suy giảm khả năng tư duy độc lập nếu con người quá phụ thuộc vào máy móc.Vì vậy, điều quan trọng không phải là có dùng AI hay không, mà là dùng AI như thế nào. Hãy để AI làm những phần việc có thể hỗ trợ con người, nhưng những quyết định cuối cùng vẫn cần dựa trên sự hiểu biết, kinh nghiệm và trách nhiệm của con người.AI có thể giúp chúng ta nhàn hơn trong công việc, nhưng cũng có thể khiến chúng ta “nhọc” hơn nếu sử dụng thiếu hiểu biết. Biết tận dụng AI để tăng năng suất, đồng thời biết kiểm chứng và làm chủ công nghệ, đó mới là cách để con người thực sự hưởng lợi từ AI.

AI đang thay đổi rất nhanh cách các sản phẩm IT được xây dựng. Một ý tưởng trước đây có thể cần nhiều tuần để nghiên cứu, thiết kế, lập trình và kiểm thử, giờ đây một nhóm nhỏ thậm chí một cá nhân có thể tạo ra prototype trong vài ngày với sự hỗ trợ của AI.AI có thể viết code, tạo giao diện, sinh tài liệu, viết test case, phân tích dữ liệu, tìm lỗi và hỗ trợ rất nhiều công việc khác trong quá trình phát triển phần mềm. Rào cản để biến một ý tưởng thành một sản phẩm hoạt động được đang thấp hơn rất nhiều.Nhưng có một điều đáng suy nghĩ:Tạo ra được sản phẩm nhanh hơn không có nghĩa là đưa sản phẩm đến người dùng cũng nhanh hơn.Từ “build được” đến “có người dùng”Trước đây, một trong những vấn đề lớn của startup hay các đội ngũ IT là thiếu nguồn lực để xây dựng sản phẩm. Cần developer, designer, tester, BA, data và rất nhiều thời gian để biến ý tưởng thành thứ có thể sử dụng.AI đang giúp giảm bớt một phần gánh nặng đó.Một developer có thể dùng AI để tạo code khung. Designer có thể nhanh chóng tạo prototype. BA có thể hỗ trợ phân tích yêu cầu và viết tài liệu. Tester có thể dùng AI để tạo các kịch bản kiểm thử ban đầu.Nhưng sau khi sản phẩm được hoàn thành, một câu hỏi quan trọng hơn xuất hiện:Ai sẽ sử dụng nó?Một sản phẩm có thể chạy hoàn hảo về mặt kỹ thuật nhưng vẫn thất bại nếu không giải quyết đúng vấn đề của người dùng.Có thể đội ngũ đã mất rất nhiều thời gian để xây dựng một tính năng mà người dùng không thực sự cần. Có thể sản phẩm tốt nhưng khách hàng không biết nó tồn tại. Cũng có thể người dùng thử một lần rồi không quay lại vì trải nghiệm chưa đủ tốt.Vì vậy, khoảng cách giữa “có sản phẩm” và “có người dùng” vẫn rất lớn.AI có thể giúp marketing, nhưng không thể ép người dùng muaAI không chỉ hỗ trợ việc phát triển sản phẩm. Nó còn có thể hỗ trợ tạo nội dung, viết quảng cáo, phân tích khách hàng, xây dựng email marketing, chăm sóc khách hàng hay phân tích phản hồi.Điều này khiến quá trình đưa sản phẩm ra thị trường cũng nhanh hơn.Nhưng tốc độ tạo nội dung không đồng nghĩa với khả năng thu hút khách hàng.Bạn có thể dùng AI để tạo hàng trăm bài quảng cáo, nhưng nếu thông điệp không chạm đúng nhu cầu thì vẫn không có người mua.Bạn có thể dùng AI để phân tích hàng nghìn phản hồi, nhưng nếu không hiểu vấn đề thực sự phía sau những phản hồi đó thì việc phân tích cũng không tạo ra nhiều giá trị.AI có thể giúp chúng ta làm nhanh hơn, nhưng việc xác định nên làm gì vẫn là một bài toán quan trọng.Khi ai cũng có thể xây sản phẩm nhanhĐây có lẽ là một trong những thay đổi đáng chú ý nhất.Nếu trước đây khả năng xây dựng sản phẩm nhanh là một lợi thế, thì trong tương lai lợi thế đó có thể giảm dần khi ngày càng nhiều người có AI hỗ trợ.Một người có ý tưởng có thể tạo website.Một developer có thể nhanh chóng dựng ứng dụng.Một startup nhỏ có thể thử nghiệm nhiều ý tưởng với chi phí thấp hơn.Điều này rất tốt cho đổi mới sáng tạo. Nhưng nó cũng tạo ra một vấn đề khác:Thị trường có thể xuất hiện ngày càng nhiều sản phẩm hơn, trong khi thời gian và sự chú ý của người dùng không tăng tương ứng.Khi đó, câu hỏi không còn đơn giản là:“Bạn có thể xây dựng sản phẩm này không?”Mà sẽ trở thành:“Tại sao người dùng phải chọn sản phẩm của bạn?”Product-market fit vẫn là bài toán khóAI có thể giúp một đội ngũ tạo ra sản phẩm nhanh hơn, nhưng không thể đảm bảo sản phẩm đó phù hợp với thị trường.Bạn vẫn cần nói chuyện với người dùng.Vẫn phải quan sát cách họ sử dụng sản phẩm.Vẫn phải nhận phản hồi.Vẫn phải thử nghiệm, đo lường và thay đổi.Có những tính năng tưởng rằng rất hữu ích nhưng gần như không ai sử dụng. Ngược lại, có những nhu cầu ban đầu bị xem nhẹ nhưng lại trở thành lý do chính khiến người dùng giữ lại sản phẩm.Đó là lý do một sản phẩm tốt không nhất thiết là sản phẩm có nhiều tính năng nhất.Đôi khi, sản phẩm tốt hơn là sản phẩm giải quyết đúng một vấn đề đủ lớn cho đúng nhóm người dùng.Vậy AI đang thay đổi vai trò của người làm IT như thế nào?Có lẽ AI đang dần chuyển trọng tâm từ “làm thế nào để xây dựng?” sang “nên xây dựng cái gì và tại sao?”Khi AI có thể hỗ trợ ngày càng nhiều phần việc kỹ thuật, khả năng hiểu vấn đề, đặt câu hỏi đúng, hiểu người dùng, xác định ưu tiên và đưa ra quyết định có thể trở nên quan trọng hơn.Developer không chỉ cần biết viết code mà còn cần hiểu sản phẩm.BA không chỉ cần viết requirement mà cần hiểu vấn đề kinh doanh phía sau requirement đó.Product Manager không chỉ cần quản lý backlog mà phải biết tính năng nào thực sự tạo ra giá trị.Marketing không chỉ cần tạo nội dung mà phải hiểu khách hàng nào thực sự cần sản phẩm.Nói cách khác, AI có thể làm giảm giá trị của một số thao tác, nhưng đồng thời làm tăng giá trị của khả năng tư duy và ra quyết định.Từ ý tưởng đến doanh thu vẫn là một hành trình dàiCó thể hình dung hành trình của một sản phẩm như sau:Ý tưởng → Xác định vấn đề → Xây dựng sản phẩm → Ra mắt → Thu hút người dùng → Giữ chân người dùng → Tạo doanh thu → Cải tiến liên tục.AI có thể hỗ trợ rất nhiều ở hầu hết các bước.Nhưng không có bước nào được đảm bảo chỉ vì chúng ta có AI.Một sản phẩm có thể được xây dựng trong vài ngày nhưng mất nhiều tháng để tìm được nhóm khách hàng phù hợp.Một ứng dụng có thể đạt hàng nghìn lượt tải nhưng rất ít người sử dụng thường xuyên.Một sản phẩm có thể có rất nhiều người dùng nhưng vẫn không tạo ra doanh thu.Và đôi khi, vấn đề không nằm ở công nghệ mà nằm ở việc chúng ta chưa hiểu đủ rõ người dùng cần gì.Có lẽ “lợi thế AI” không nằm ở việc làm nhanh nhấtKhi tất cả mọi người đều có thể sử dụng AI để tăng tốc, chỉ nhanh thôi có thể không còn đủ.Lợi thế có thể nằm ở khả năng chọn đúng vấn đề, hiểu đúng người dùng và biến tốc độ của AI thành giá trị thực tế.AI giúp chúng ta đi từ ý tưởng đến sản phẩm nhanh hơn.Nhưng để đi từ sản phẩm đến người dùng, rồi từ người dùng đến doanh thu, vẫn cần rất nhiều thứ mà không thể chỉ giải quyết bằng một câu lệnh cho AI.Và đó có lẽ là một trong những câu hỏi thú vị nhất của ngành IT trong thời đại AI:Khi AI khiến việc xây dựng sản phẩm trở nên dễ dàng hơn, điều gì sẽ trở thành lợi thế cạnh tranh thực sự?Theo bạn, trên hành trình từ ý tưởng → sản phẩm → người dùng → doanh thu, bước nào sẽ là thử thách lớn nhất?

Có một câu mình nghe đi nghe lại suốt mấy tháng nay, ở đủ mọi group founder, mọi buổi demo day: "Giờ code xong sản phẩm chỉ mất một buổi chiều." Nghe thì sướng thật. Nhưng cứ mỗi lần ai đó nói câu này, mình lại thấy thiếu một vế: xong rồi sao nữa?Đó là cái khoảng trống mà bài viết này muốn đào sâu vào.Khi "build" không còn là hàng ràoTrước đây, làm ra một sản phẩm là một cuộc sàng lọc tự nhiên. Bạn cần biết code, cần tiền thuê dev, cần thời gian — và chính những thứ đó đã loại bớt phần lớn ý tưởng dở, người thiếu kiên trì. Build khó, nên ai build ra được sản phẩm cũng đã chứng minh được một phần năng lực.AI phá vỡ cái hàng rào đó. Giờ một người không biết code vẫn có thể có app chạy được trong vài giờ. Điều này tốt — nó dân chủ hoá việc sáng tạo. Nhưng nó cũng có nghĩa là: sản phẩm không còn là thứ khan hiếm. Cái khan hiếm bây giờ chuyển sang chỗ khác.Cái khan hiếm mới: sự chú ý, và niềm tinKhi ai cũng build được, thị trường ngập trong sản phẩm "đủ tốt". Người dùng không thiếu lựa chọn — họ thiếu thời gian và lý do để thử một cái mới. Đây là lúc bài toán chuyển từ "làm sao cho sản phẩm tốt" sang "làm sao cho ai đó biết đến nó, tin nó, và bỏ thời gian ra dùng nó".Ba thứ AI chưa (và có lẽ khó) làm thay bạn:Sự tin tưởng ban đầu — người dùng đầu tiên tin bạn không phải vì sản phẩm hoàn hảo, mà vì họ tin bạn, tin câu chuyện, tin rằng có người thật đứng sau lắng nghe họ.Distribution — kênh phân phối, mối quan hệ, cộng đồng, network — những thứ được xây bằng thời gian và sự nhất quán, không copy-paste được.Timing và ngữ cảnh — hiểu đúng lúc nào thị trường sẵn sàng nghe về sản phẩm của bạn, điều mà không mô hình nào dự đoán chắc chắn.Vậy bước nào khó nhất?Với mình, không phải là "launch" theo nghĩa bấm nút ra mắt — cái đó giờ chỉ là một dòng thông báo trên Product Hunt hay một bài post. Cái khó thật sự nằm ở giai đoạn giữa launch và có doanh thu bền vững — cái khoảng mà nhiều người gọi là "thung lũng chết" của sản phẩm mới.Đó là lúc:Bạn đã có vài chục, vài trăm người dùng đầu — nhưng phần lớn là bạn bè, cộng đồng quen, chưa phải thị trường thật.Bạn phải trả lời câu hỏi khó nhất: người ta có sẵn sàng trả tiền không, hay chỉ dùng thử vì miễn phí và mới lạ?Bạn nhận ra tốc độ build nhanh của AI không hề rút ngắn thời gian để một hành vi mới hình thành trong đầu người dùng — cái đó vẫn tính bằng tuần, bằng tháng, không tính bằng giờ.AI có thể viết landing page, viết email marketing, thậm chí trả lời chat hỗ trợ khách hàng. Nhưng nó không thể đi cà phê với 20 khách hàng tiềm năng để nghe họ thật sự nghĩ gì, không thể tạo ra cảm giác "sản phẩm này được làm bởi người hiểu mình" — thứ quyết định ai đó có quay lại lần hai hay không.Một góc nhìn khác: build rẻ đi, nghĩa là được thử nhiều hơnNhưng cũng phải công bằng: chính vì build rẻ và nhanh, bạn có quyền thử-sai nhiều hơn. Ngày xưa build sai một sản phẩm là mất cả năm. Giờ bạn có thể tung ra 5 phiên bản MVP trong một tháng, để thị trường tự nói cho bạn biết cái nào có sức sống.Vậy nên có lẽ câu trả lời không phải "launch có dễ hơn không", mà là: trọng tâm của người làm sản phẩm đã dịch chuyển. Từ chỗ giỏi kỹ thuật, sang chỗ giỏi lắng nghe, giỏi kể chuyện, giỏi kiên trì đủ lâu để một cộng đồng nhỏ tin bạn trước khi thị trường lớn biết đến bạn.Câu hỏi để mọi người cùng nghĩNếu AI đã gánh gần hết phần build, thì phần còn lại — phần con người phải tự làm — chính là phần khó nhất, chứ không phải phần dễ bị bỏ qua nhất. Vậy bạn nghĩ sao: bước nào trên hành trình đưa sản phẩm ra thị trường đang là điểm nghẽn lớn nhất của bạn — tìm người dùng đầu tiên, giữ chân họ, hay biến họ thành người trả tiền?

Dạo này tôi hay nghĩ về đề bài này theo một hướng hơi khác với cách nó thường được đặt ra.Phần lớn tranh luận đang so tốc độ. Fresher có AI làm xong trong một buổi chiều thứ mà trước đây mất ba ngày. Điều đó đúng, và đáng để công nhận.Nhưng nhìn cách AI thực sự được dùng trong công việc hàng ngày, tôi thấy thứ tạo ra khác biệt giữa hai người không nằm ở chỗ ai lấy được câu trả lời nhanh hơn.Nó nằm ở câu hỏi đã được gõ vào.Và đó là phần AI không giúp được.AI trả lời câu bạn hỏi, không trả lời câu bạn quên hỏiAI đang tốt lên rất nhanh. Tôi không nghĩ lập luận "AI hay sai" sẽ còn đứng vững lâu, nên tôi không muốn dựa vào nó.Thứ không tự tốt lên theo là phạm vi. AI trả lời trong đúng khung được đưa ra, và không tự bước ra ngoài khung đó để hỏi những thứ chưa ai nghĩ tới.Bạn nhờ nó viết hàm xử lý thanh toán, nó viết một hàm đúng yêu cầu. Nó không tự hỏi nếu hai request đến cùng lúc từ hai thiết bị của cùng một user thì sao. Câu đó phải có người đặt ra trước.Senior đặt được câu đó vì họ từng đứng ở đúng chỗ đó rồi. Race condition chỉ lộ khi tải cao. Một job chạy trùng hai lần vì thiếu idempotency key. Một retry tưởng vô hại nhưng nhân đôi bản ghi.Fresher không thiếu công cụ để tìm câu trả lời. AI chính là công cụ đó, và nó rất giỏi. Thứ họ thiếu là danh sách câu cần hỏi.Sẽ có người nói fresher chịu khó đọc blog, đọc postmortem của công ty khác thì cũng biết. Tôi nghĩ điều đó đúng một phần. Nhưng biết một khái niệm tồn tại khác với việc tự nhiên thấy gợn ở đúng dòng code trước mắt, lúc không ai nhắc bạn phải cẩn thận. Cái sau là phản xạ, mà phản xạ thì hình thành qua lặp lại chứ không qua một lần đọc.Hệ thống là một mạng lưới đánh đổiAI giỏi giải bài toán có ranh giới rõ. Viết hàm này. Sửa lỗi kia. Refactor đoạn này.Hệ thống thật hiếm khi có ranh giới rõ như vậy.Thêm cache ở đây thì mất consistency ở kia. Tách service thì scale được nhưng đổi lấy độ trễ mạng và một lớp lỗi hoàn toàn mới. Đồng bộ thì đơn giản nhưng dễ nghẽn, bất đồng bộ thì linh hoạt nhưng khó debug hơn nhiều lần khi có sự cố.Nhận một yêu cầu, senior chạy một phép tính ngầm gần như tự động: cái này đụng vào phần nào, phần nào dễ vỡ, vỡ thì vỡ kiểu gì.Tôi để ý phép tính đó không đến từ tài liệu. Nó đến từ những lần từng thiết kế sai, từng sửa lại kiến trúc lúc hai giờ sáng, từng ngồi họp postmortem giải thích vì sao một quyết định sáu tháng trước lại gây ra sự cố hôm nay.AI liệt kê được năm cách thiết kế caching. Chọn cách nào cho đúng hệ thống của bạn, với đúng pattern truy cập mà đội bạn đang có, thì vẫn là việc của người ra quyết định.Có loại điểm mù chỉ sống trong lịch sử công tyNhiều chỗ nguy hiểm nhất trong một codebase không nằm trong code. Chúng nằm trong lịch sử.Module này viết kỳ lạ vì ba năm trước một khách hàng lớn yêu cầu tính năng đặc biệt, và chẳng ai kịp dọn lại.Trường kia để giá trị mặc định thay vì bắt buộc nhập, vì lần trước bắt buộc, một đợt import dữ liệu lớn bị chặn ngay trước giờ chốt sổ quý.Không tài liệu nào ghi đủ những chuyện này. Chúng sống trong đầu người có mặt lúc đó.Nghĩa là ở đây có một loại kiến thức không nằm trên internet, không nằm trong repo, và cũng không có đường tắt nào để lấy. Nó chỉ tồn tại trong trí nhớ của người từng chịu hậu quả — và đó là người bạn phải hỏi, chứ không phải công cụ.Còn một tầng nữa: công ty đang cố làm gìTầng này ít được nhắc tới hơn, nhưng theo tôi nó quyết định nhiều thứ hơn cả hai tầng trên.Một yêu cầu kỹ thuật luôn gắn với một lý do kinh doanh, dù thường không ai nói ra."Làm nhanh cái này" có thể là nhanh để kịp ra thị trường. Có thể là nhanh về hiệu năng. Có thể chỉ vì tuần sau sếp cần demo cho nhà đầu tư.Ba lý do dẫn tới ba cách làm khác hẳn nhau. Chọn sai thì code vẫn chạy đúng, nhưng hướng đi đã lệch — và loại sai này thường phải vài tháng sau mới lộ ra, lúc sửa đã đắt.Senior gom được bối cảnh đó qua nhiều năm ngồi họp, nói chuyện với sales, nghe khách hàng phàn nàn trực tiếp. Họ biết công ty đang ở giai đoạn nào và đang sợ điều gì nhất. Phần lớn thứ đó chưa từng được viết ra ở đâu, nó chỉ là trực giác kiểu "cái này nhìn nhỏ nhưng động vào là phòng pháp lý nhảy vào".Fresher chưa có nó, không phải vì kém, mà vì chưa đủ thời gian để có.Vài điều cần nói cho sòng phẳngMột bài kết luận rằng bên có nhiều năm hơn thì thắng rất dễ bị đọc thành lời tự khen của người đã ở trong ngành đủ lâu. Nên tôi muốn nói rõ mấy điểm, để lập luận đứng được bằng chính nó.AI có ích thật cho fresher. Nó rút ngắn đường học, cho họ chạm vào những thứ mà trước đây mất hàng tháng mới tiếp cận được. Ai phủ nhận điều đó là không trung thực.Khoảng cách này cũng không cố định. Có những bạn học rất nhanh, chủ động tìm việc có hậu quả thật để tự rèn, và rút ngắn được đáng kể. Nhưng khi làm vậy, họ đang đi đúng con đường senior đã đi, chỉ nhanh hơn. AI giúp đi nhanh hơn trên con đường đó chứ không thay thế nó.Và lập luận này có một điều kiện biên rõ ràng: nó đúng chừng nào AI còn trả lời trong phạm vi được hỏi. Nếu tới ngày agent tự nêu ra được những câu hỏi chưa ai nghĩ tới, phần lớn bài này sẽ hết giá trị. Tôi chưa thấy điều đó, ít nhất là chưa.Câu trả lời của tôi, và câu hỏi tôi thấy đáng bàn hơnSenior thắng. Không phải ở tốc độ, mà ở chỗ họ biết cần hỏi gì trước khi gõ, biết chỗ nào sẽ vỡ, và biết công ty thật sự đang cần gì.Nhưng càng nghĩ tôi càng thấy có một câu hỏi nằm bên dưới đề bài này, và nó đáng bàn hơn: AI đang khuếch đại loại năng lực nào?Nó khuếch đại rất mạnh khả năng biến một ý định rõ ràng thành kết quả. Với việc hình thành ý định đó cho đúng ngay từ đầu thì nó gần như không giúp gì.Phần thứ hai mới là phần lâu nay quyết định ai làm việc tốt. Và nó cũng là thứ duy nhất trong toàn bộ chuỗi này không rút ngắn được bằng công cụ.Không biết mọi người đang làm việc cùng AI mỗi ngày có thấy giống vậy không.

Có dạo tôi tin chắc điều đó. Thấy tin tuyển dụng nào để mức cao là y như rằng đính kèm một cái stack đang trend. Nên tôi nghĩ đơn giản: học cái đang hot, nhảy vào, lương khắc lên. Bun là cái dạy tôi rằng chuyện không dễ vậy.Lần đầu tôi nhắc tới Bun trong buổi review kiến trúc, sếp hỏi đúng một câu: "Cái này ai chạy production chưa?" 1 câu hỏi gần ai cũng sẽ hỏi khi bạn dề xuất 1 cái gì đó mới. Hồi đó Bun mới lắm, ở mình gần như chưa ai dám xài. Mà CTO với Tech lead chỗ tôi không phải kiểu bài xích đồ mới, họ chỉ dị ứng với rủi ro không có lý do rõ ràng thôi.Thứ làm tôi không bỏ cuộc là cái feature realtime đòi hỏi 1 lượng tải lơn. Bên Node tôi phải lôi thêm `ws` vào, tự lo scale connection, config cả mớ. Bun thì WebSocket nằm sẵn trong `Bun.serve`, gõ mấy chục dòng là chạy. Thế là cuối tuần đó tôi ngồi dựng thử một service WebSocket nhỏ, đo bằng đúng lượng connection team cần chứ không phải benchmark cho vui.Số ra khá ổn: cùng một con máy, Bun xử lý được nhiều connection hơn, tin nhắn tới nhanh hơn, mà code thì ít hơn. Buổi meeting sau tôi không đi thuyết phục bằng "Bun mới nè, Bun hay lắm anh" nữa. Tôi đưa số. Tech lead vẫn cản, mà cản đúng: còn thư viện chưa hỗ trợ, còn vài chỗ Bun chạy khác Node. Tụi tôi ngồi list ra từng rủi ro, cái nào chặn thì gạch, cái nào chịu được thì ghi rõ. Cuối cùng chốt: cho Bun chạy thử đúng cái service nội bộ này, lỡ hư thì rollback trong một buổi là xong.Nó chạy ngon. Mấy tháng sau tụi tôi nhân rộng ra. Và tới kỳ review, mọi thứ đánh giá tốt.Nhưng nhích không phải vì tôi biết Bun. Bun ai học chả được, tài liệu đầy ra. Cái làm sếp gật là tôi dám đưa một thứ chưa ai xài vào, tự đo, tự chỉ ra chỗ nó dễ vỡ, và chịu trách nhiệm cho nó chạy. Đó mới là thứ khó thuê, và là thứ họ trả tiền.Nên nếu bạn hỏi stack có quyết định lương không, tôi nói thật: stack chỉ là cái cớ. Người ta trả cho việc bạn biến một cái stack thành thứ chạy được trong công ty, gánh được rủi ro của nó. Chạy theo trend mà không làm được chuyện đó thì học bao nhiêu framework lương vẫn dậm chân. Còn làm được, thì dùng stack cũ mèm lương vẫn lên.

Có một ngày, người quản lý giao cho tôi một tính năng mới.Anh ấy chỉ nói rất đơn giản:"Em thử thiết kế phần này trước nhé."Tôi ngồi trước màn hình gần cả buổi sáng.Không phải vì bài toán quá khó.Mà vì tôi không biết phải bắt đầu từ đâu.Suốt nhiều năm trước đó, công việc của tôi là đọc requirement, tạo vài file mới rồi bắt đầu viết code. Khi gặp bug thì debug, khi thiếu tài liệu thì đọc datasheet, khi hiệu năng chưa tốt thì tối ưu.Tôi khá tự tin với khả năng lập trình của mình.Nhưng lần đầu tiên phải tự thiết kế một hệ thống, tôi mới nhận ra mình hoàn toàn lúng túng.Tôi không biết nên chia module như thế nào.Không biết module nào nên chịu trách nhiệm cho việc gì.Không biết có bao nhiêu state trong hệ thống.Càng không biết vì sao nên chọn một kiến trúc này thay vì một kiến trúc khác.Điều đáng buồn là... không ai dạy những điều đó.Tôi làm trong lĩnh vực Embedded Software.Ở trường đại học, chúng tôi học cấu trúc dữ liệu, giải thuật, vi điều khiển, hệ điều hành...Đi làm, chúng tôi học framework, protocol, RTOS, Linux...Nhưng rất ít nơi dạy cách biến một yêu cầu của khách hàng thành một bản thiết kế có thể triển khai.Trong nhiều năm, tôi từng nghĩ:"Chắc mình code chưa đủ giỏi."Thế là tôi tiếp tục học.Học ngôn ngữ mới.Học framework mới.Học cách tối ưu từng dòng code.Nhưng càng học, tôi càng nhận ra vấn đề của mình không nằm ở coding.Một lập trình viên có thể viết một hàm rất đẹp - Nhưng trước đó, phải có ai quyết định rằng hàm đó nên tồn tại.Một lập trình viên có thể tối ưu bộ nhớ rất tốt - Nhưng trước đó, phải có ai quyết định cách chia dữ liệu.Một lập trình viên có thể implement state machine hoàn hảo - Nhưng trước đó, phải có ai xác định hệ thống có những state nào.Code luôn là bước cuối cùng.Điều khó hơn nhiều là những quyết định diễn ra trước khi dòng code đầu tiên được viết.Khoảng một năm trở lại đây, tôi thay đổi hoàn toàn cách học.Tôi bắt đầu đọc về software architecture thay vì framework.Tìm hiểu state machine thay vì chỉ học API.Quan tâm đến trách nhiệm của từng module thay vì chỉ quan tâm hàm nên viết ở file nào.Thậm chí tôi còn tự xây cho mình một checklist để mỗi khi nhận một feature mới, tôi có thể tự hỏi:Hệ thống này thực sự đang giải quyết vấn đề gì?Có những actor nào?Những state nào sẽ xuất hiện?Event nào làm hệ thống chuyển trạng thái?Module nào nên chịu trách nhiệm?Thành phần nào có thể thay đổi trong tương lai?Ban đầu, việc trả lời những câu hỏi này mất rất nhiều thời gian.Nhưng càng làm, tôi càng nhận ra mình không còn lao vào code ngay nữa.Tôi dành nhiều thời gian hơn để suy nghĩ.Và điều thú vị là tổng thời gian hoàn thành công việc lại ngắn hơn.Ít bug hơn.Ít phải sửa đi sửa lại hơn.Ít tranh luận hơn khi review.Rồi AI xuất hiện.Nhiều người hỏi:"AI viết code tốt như vậy thì lập trình viên còn giá trị gì nữa?"Tôi nghĩ AI khiến tôi nhận ra một điều.Nếu giá trị của tôi chỉ nằm ở việc viết code nhanh, thì sớm hay muộn AI cũng sẽ làm tốt hơn.Nhưng AI vẫn cần một người xác định đúng bài toán.Nó cần ai đó hiểu sản phẩm.Hiểu người dùng.Hiểu những ràng buộc về hiệu năng, bộ nhớ, chi phí và khả năng bảo trì.Nó có thể đề xuất nhiều giải pháp.Nhưng người chịu trách nhiệm chọn một giải pháp phù hợp vẫn là kỹ sư.Có lẽ đó mới là giá trị khó thay thế nhất.Nhìn lại chặng đường của mình, tôi không còn tin rằng chỉ cần code giỏi là đủ.Coding rất quan trọng.Nó là nền tảng.Nhưng nó không phải là tất cả.Khi sự nghiệp phát triển, chúng ta sẽ dành ít thời gian hơn để gõ bàn phím và nhiều thời gian hơn để phân tích, thiết kế, giao tiếp, đưa ra quyết định và chịu trách nhiệm cho những quyết định đó.Có một câu mà tôi rất thích:Code is easy. Deciding what to build is hard.

Trong ngành IT, có một câu hỏi mà mình thấy xuất hiện khá thường xuyên:"Học công nghệ nào để lương cao?"Mỗi khi có một công nghệ mới nổi lên, rất nhiều bài viết bắt đầu xuất hiện với những tiêu đề như:Học AI để tăng gấp đôi thu nhập..Học Rust vì đây là tương lai của ngành lập trình.Fullstack React + Next.js đang được săn đón với mức lương hấp dẫn.Điều đó khiến nhiều người tin rằng mức lương của lập trình viên phụ thuộc gần như hoàn toàn vào tech stack mà họ đang sử dụng. Nhưng sau nhiều năm làm việc, mình nhận ra rằng câu chuyện không đơn giản như vậy.Tech Stack Có Ảnh Hưởng Đến Thu NhậpMình không phủ nhận điều đó. Thị trường luôn có những giai đoạn mà một công nghệ nào đó trở nên "hot" hơn những công nghệ khác.Ví dụ:AI và Machine Learning đang được đầu tư mạnh.Cloud Computing ngày càng phổ biến.Golang được nhiều công ty sử dụng cho hệ thống backend hiệu năng cao.React, Next.js hay TypeScript gần như đã trở thành tiêu chuẩn ở nhiều dự án frontend hiện đại.Khi nhu cầu tuyển dụng tăng nhưng nguồn nhân lực chưa đủ, mức lương cho những vị trí này thường cao hơn mặt bằng chung. Đó là quy luật cung và cầu rất bình thường.Tuy nhiên...Tech Stack Không Phải Là Yếu Tố Duy NhấtMình từng gặp những trường hợp rất thú vị. Có người sử dụng một tech stack được xem là "cũ", nhưng mức lương vẫn cao hơn nhiều người đang làm công nghệ mới. Ngược lại, cũng có những người liên tục chạy theo trend công nghệ nhưng thu nhập lại không cải thiện đáng kể.Tại sao?Bởi vì doanh nghiệp không chỉ trả tiền cho việc bạn biết sử dụng một framework hay một ngôn ngữ lập trình.Họ trả tiền cho:Khả năng giải quyết vấn đề.Tư duy thiết kế hệ thống.Kinh nghiệm thực chiến.Kỹ năng giao tiếp và làm việc nhóm.Khả năng dẫn dắt dự án.Mức độ ảnh hưởng đến sản phẩm và doanh nghiệp.Một lập trình viên có thể học React trong vài tháng. Nhưng để trở thành người có thể thiết kế kiến trúc hệ thống, tối ưu hiệu năng, mentoring cho đội nhóm và chịu trách nhiệm cho một sản phẩm lớn thì cần nhiều năm kinh nghiệm. Và chính những giá trị đó thường tạo nên khoảng cách lớn về thu nhập.Mình Đã Từng Muốn Đổi Tech Stack Vì TiềnMình nghĩ rất nhiều người trong ngành cũng từng như vậy. Khi thấy một công nghệ nào đó đang được trả lương cao hơn, chúng ta dễ có cảm giác rằng: "Nếu mình chuyển sang công nghệ đó thì thu nhập sẽ tăng nhanh hơn." Điều đó không sai, nhưng mình nhận ra một điều:Chỉ đổi tech stack thôi chưa đủ.Nếu chỉ học cú pháp mới, framework mới nhưng không nâng cao năng lực giải quyết vấn đề, thì mức lương có thể tăng trong ngắn hạn nhưng rất khó tạo ra sự khác biệt lớn trong dài hạn. Ngược lại, khi có nền tảng kỹ thuật tốt, việc chuyển đổi giữa các công nghệ thường dễ dàng hơn rất nhiều.Điều Quan Trọng Hơn Là Giá Trị Bạn Tạo RaSau cùng, mình cho rằng tech stack chỉ là một công cụ. Giống như một người thợ mộc, chỉ với một chiếc búa tốt có thể giúp công việc hiệu quả hơn, nhưng giá trị thực sự vẫn nằm ở tay nghề của người sử dụng nó. Trong ngành IT cũng vậy. Tech stack có thể mở ra cơ hội mới. Tech stack có thể giúp bạn tiếp cận những dự án tốt hơn. Tech stack có thể giúp mức lương khởi điểm cao hơn. Nhưng thứ quyết định sự phát triển lâu dài vẫn là khả năng học hỏi, thích nghi và tạo ra giá trị cho sản phẩm, khách hàng và doanh nghiệp.Góc Nhìn Cá NhânNếu bây giờ có người hỏi mình:"Nên chọn tech stack nào để lương cao?"Có lẽ mình sẽ trả lời:Hãy chọn một công nghệ có nhu cầu thực tế trên thị trường, phù hợp với định hướng của bạn và đầu tư đủ sâu để trở thành người giỏi trong lĩnh vực đó.Bởi vì một lập trình viên giỏi trong một tech stack "bình thường" thường có giá trị hơn một lập trình viên chỉ biết sơ qua nhiều công nghệ đang là xu hướng.Còn bạn thì sao?Tech stack bạn đang làm có thực sự tác động đến mức lương của bạn không?Bạn đã từng đổi công nghệ vì lý do thu nhập chưa?Và nếu nhìn lại, quyết định đó có mang lại kết quả như bạn kỳ vọng không?Mình rất muốn nghe thêm góc nhìn và trải nghiệm của mọi người.

Chào các đồng nghiệp solo builder! Bạn biết cảm giác đó: một ý tưởng tuyệt vời, code chảy tràn, và bạn muốn đưa nó ra thị trường ngay lập tức. Đó là thời kỳ "Vibe Coding" — giai đoạn hưng phấn khi sản phẩm hình thành với tốc độ ánh sáng. Nhưng khi sản phẩm bắt đầu đi xa hơn, một bóng ma bắt đầu xuất hiện: an toàn thông tin (Cybersecurity). Vậy bạn dung hòa tốc độ và an toàn thế nào?Câu Chuyện Thật: Khi Vibe Sụp Đổ Trước Dữ Liệu ThựcHai năm trước, tôi bắt đầu xây dựng dự án solo đầu tiên: một công cụ phân tích SEO nhỏ cho các blogger. Giai đoạn đầu, tôi hoàn toàn 'vibe'. Tôi ưu tiên giao diện, tính năng chính và tốc độ release. "Lúc đầu ai cũng vậy," tôi tự nhủ, "chỉ cần hoạt động là được, security tính sau."Sản phẩm được release trong 2 tháng, và tôi rất tự hào. Cho đến khi người dùng đầu tiên — một người dùng trả phí — báo cáo một vấn đề. Anh ấy đã vô tình truy cập vào bảng điều khiển của một người dùng khác chỉ bằng cách thay đổi một số trong URL. Đó là lỗ hổng IDOR (Insecure Direct Object Reference) kinh điển.Sự hưng phấn biến mất, thay vào đó là sự sợ hãi. Tôi phải đóng cửa dịch vụ ngay lập tức, sửa lỗi, và liên lạc với người dùng để xin lỗi. Tôi đã build quá nhanh mà không kiểm tra quyền truy cập cơ bản. Đó là một bài học đắt giá về việc 'nợ an toàn' sẽ phải trả giá đắt như thế nào.Giải Quyết: Xây Dựng Khung An Toàn Từ Số 0Tình huống đó buộc tôi phải thay đổi toàn bộ quy trình build. Tôi không thể để security là một yếu tố phụ nữa. Tôi đã làm gì để giải quyết nợ an toàn mà vẫn giữ được tốc độ cần thiết?1. Bắt Đầu Quan Tâm Đến Security Ngay Từ Giai Đoạn Build: Thay vì để sang giai đoạn sau, tôi đưa an toàn vào ngay quy trình phát triển:Nguyên tắc "Mặc Định An Toàn": Ngay từ khi viết function đầu tiên, tôi đã xác thực quyền truy cập. Nếu function đó tương tác với dữ liệu, nó phải được bảo vệ bởi default.Tự Động Hóa Kiểm Tra: Tôi sử dụng các tool static code analysis (SAST) và dynamic analysis (DAST) cơ bản trong CI/CD pipeline để phát hiện các lỗi phổ biến (SQLi, XSS) ngay khi commit code. Nó chỉ mất 5 phút để tích hợp, nhưng đã ngăn chặn vô số lỗi sau này.2. Không Cần Hoàn Hảo, Chỉ Cần Chắc Chắn: Tôi không cố gắng xây dựng một hệ thống bảo mật cấp ngân hàng. Thay vào đó, tôi tập trung vào:Top 10 OWASP: Tôi học và nắm vững 10 lỗ hổng bảo mật web phổ biến nhất. Điều này giúp tôi tránh được 80% rủi ro với 20% nỗ lực.Xác Thực và Phân Quyền Mạnh: Đây là cốt lõi. Tôi đã build lại hệ thống auth, đảm bảo quyền truy cập được kiểm tra ở mọi endpoint và API.Giá Trị Cho Bạn: Insight Có Thể Áp Dụng LạiNếu bạn là solo builder, đừng để security là "nỗi sợ" mà là một "công cụ hỗ trợ" cho sự phát triển.Bài học 1: Bắt đầu ngay, không cần lớn. Tích hợp security audit tool cơ bản hoặc nắm vững Top 10 OWASP không tốn quá nhiều thời gian nhưng có thể ngăn chặn 90% các lỗ hổng cơ bản. Nó giúp bạn tự tin hơn khi đưa sản phẩm ra thị trường.Bài học 2: 'Dung hòa' không phải là 'đánh đổi'. Tốc độ và an toàn có thể đi cùng nhau. Xây dựng một quy trình build an toàn ngay từ đầu sẽ giúp bạn build nhanh hơn trong dài hạn, vì bạn không phải mất hàng tuần để sửa lỗi sau này.Bài học 3: Xem an toàn là lợi thế cạnh tranh. Việc có một sản phẩm an toàn và minh bạch về bảo vệ dữ liệu sẽ giúp bạn chiếm được lòng tin của người dùng nhanh hơn, đặc biệt là người dùng doanh nghiệp.Tôi có thay đổi cách build của mình không? Hoàn toàn có. Tôi vẫn 'vibe', nhưng 'vibe' của tôi hiện tại đã có một lớp bảo vệ. Và bạn, bạn quan tâm đến an toàn sản phẩm từ lúc nào?