Career Hack

“Cuối cùng tôi đã về nhà. Ithaca.”Câu đó tôi giữ trong đầu như một lời thề, giống Odysseus trong bản kể của Christopher Nolan. Không phải vì tôi tính trước được từng bước đi. Mà vì khi đã có đủ thông tin, tôi bỏ mặc. Cứ kệ đi. Để chiếc bè trôi theo số phận của nó. Không bàn thêm. Không đợi ai gật đầu. Và sau rất nhiều năm, tôi về đến nhà.Lần đầu tiên nhìn thấy hồ bơi, tôi đã mang sẵn tinh thần đó, dù lúc ấy chưa biết gọi tên nó là gì. Tôi nhảy xuống ngay. Không hỏi ai. Không đo độ sâu. Máu liều trong tôi luôn vậy, nhưng liều không có nghĩa là không tính toán. Tôi biết mình chưa bơi được. Tôi cũng biết có những người anh đứng gần đó, sẵn sàng nhảy xuống kéo tôi lên nếu tôi đuối. Tôi nhảy vì tin vào phần tính toán đó, không phải vì liều mạng thuần túy.Lúc lao vào vibe code, tôi mang cái máu đó thêm một lần nữa. Có người bảo tôi không làm được đâu. Có người hỏi thẳng tôi biết gì mà làm. Tôi không đôi co. Tôi chỉ đáp lại bằng một câu hỏi ngược, rồi im lặng làm phần còn lại. Có lẽ chính vì lúc đó tôi không biết đủ để sợ, tôi mới dám nhảy xuống. Về sau, khi sản phẩm ra đời thật, có khách hàng thật, có tiền thật, chính những người từng hoài nghi lại nói với tôi một câu khác: hoá ra làm vậy cũng kiếm được tiền. Tôi vẫn không nói nhiều.Nhảy xuống một mình thì dễ. Bơi vào bờ mới là chuyện khác. Và cái bờ đó, tôi chưa bao giờ tự bơi vào một mình.Giờ đây chỉ cần một người là đủ để tạo ra một sản phẩm hoàn chỉnh. Như tôi bây giờ. Nhưng để sản phẩm đó sống được ngoài kia, tôi vẫn phải đứng trên vai người khổng lồ, tức là kinh nghiệm của những người đi trước, những bài học họ đã trả giá bằng dự án thật, không phải bằng lý thuyết. Đó là những người anh từng đứng cạnh hồ bơi năm nào. Chỉ khác, bây giờ họ mang hình hài khác. Một cộng đồng. Một tài liệu kỹ thuật. Một lần trao đổi đúng lúc.Trước khi lao hẳn vào build sản phẩm bằng AI, tôi từng nhìn sang ngành design, và thấy trước một phần câu chuyện của chính mình. Có một giai đoạn tôi ray rứt khi nhìn hình ảnh do AI tạo ra tràn vào những chỗ trước giờ chỉ có con người làm. Tôi nhận ra đâu là sản phẩm của AI gần như ngay từ cái nhìn đầu tiên. Điều đau hơn cả, khách hàng bắt đầu chủ động đòi dùng AI, thay vì tin vào tay nghề người thật. Ai cũng ra được một bản thiết kế trong vài phút. Nhưng thị trường không vì thế mà dễ thở hơn cho người làm design. Ra nhanh hơn. Nhiều hơn. Cạnh tranh khốc liệt hơn. Còn chuyện có ai dùng, có ai trả tiền, có đứng vững được không, vẫn là bài toán cũ chưa ai giải hộ.Rồi có một khoảnh khắc loé sáng. Tôi nhận ra chính mình đang sống nhờ những khách hàng không dùng AI, không muốn dùng AI, ngay trong lòng cái hồ bơi AI mà ai cũng đang nhảy vào. Cái họ trả tiền không phải cho tốc độ. Mà cho việc có một con người thật đứng sau, hiểu chuyện, chịu trách nhiệm. Đó là lúc tôi hiểu, máu liều nhảy xuống hồ bơi năm xưa, và cái nghịch lý sống được nhờ từ chối trào lưu bây giờ, là cùng một bản năng. Dám khác đi, miễn là có tính toán phía sau.Tôi làm trong mảng build sản phẩm bằng AI. Và tôi thấy ngành mình đang đi đúng vòng lặp mà design đã đi qua, chỉ chậm hơn một nhịp. Nhiều người tin AI giúp launch dễ hơn, vì build đã nhanh hơn rồi. Sau hơn một chục dự án thực tế trong gần một năm, tôi nhận ra điều ngược lại. Launch không hề dễ hơn. Nó chỉ đổi loại bài toán liên tục. Và người biết đặt đúng câu hỏi cho AI ở từng giai đoạn mới là người kiểm soát được rủi ro, chứ không phải người gõ prompt nhanh nhất.Giai đoạn đầu: dựa vào cái có sẵn vì chưa đủ tự tinNhững dự án đầu tiên, tôi không build từ đầu. Có dự án tôi tận dụng nền tảng thương mại điện tử có sẵn, rồi sau đó gỡ ra để tự dựng database riêng khi nhu cầu tùy biến vượt quá giới hạn của nền tảng. Có dự án khác, tôi lấy cấu trúc HTML từ một website WordPress đang chạy, dịch và thích nghi lại, thay vì dựng mới hoàn toàn.Cả hai cách đều hợp lý ở thời điểm đó, khi tôi chưa đủ tự tin để tự dựng mọi thứ từ số không. Nhưng càng làm nhiều, tôi càng thấy một nghịch lý nhỏ: dựa vào cái có sẵn tưởng là đường tắt, thực ra tốn thời gian hơn về sau. Gỡ một nền tảng đã tích hợp sâu, hay thích nghi lại cấu trúc của người khác, đều là công việc dọn dẹp trước khi làm được điều mình thực sự muốn.Càng về sau, tôi build từ đầu nhiều hơn. Và nhanh hơn hẳn. Không phải vì AI giỏi hơn theo thời gian. Mà vì khi không bị ràng buộc bởi cấu trúc của người khác, AI mới hỗ trợ hiệu quả nhất. Kiểm soát toàn bộ kiến trúc ngay từ đầu, hoá ra lại là con đường ngắn hơn.Tự tin, hoá ra, cũng là một dạng hạ tầng.Ba lần “launch” cho cùng một sản phẩmBài học rõ nhất về khoảng cách giữa build và launch, đến từ một dự án cho một đơn vị sân khấu có tên tuổi. Dự án này không launch một lần. Nó launch ba lần, cho ba đợt ra mắt khác nhau. Mỗi lần là một bài toán hoàn toàn khác. Mỗi lần tôi lại phải học lại từ đầu, dù đã đi qua lần trước.Lần đầu, chưa có database, sản phẩm gần như tĩnh. Nhưng đó lại là lần áp lực nhất về hạ tầng. Có đồng hồ đếm ngược cần chống việc người dùng chỉnh giờ máy để lách. Có nghệ sĩ nổi tiếng liên quan đến dự án được báo chí đưa tin, kéo lượng người truy cập ập vào cùng lúc. Có video trên trang càng làm nặng băng thông. Bài toán ở đây không phải “code có chạy không”. Mà là “hệ thống có sống nổi khi cả nghìn người vào cùng một giây không”.Có một quyết định trong lần đó tôi nhớ rất rõ. Dữ liệu cho thấy khoảng 0,05% người dùng có thể gặp trải nghiệm không tối ưu ở một luồng phụ nào đó. Tôi có đủ thông tin để biết, cố vá cho bằng hết phần nhỏ đó sẽ ngốn thời gian đáng lẽ nên dồn cho việc quan trọng hơn. Nên tôi kệ đi phần 0,05% ấy. Dồn toàn lực còn lại cho performance. Vì tôi biết chắc, quyết định thắng thua thật sự của ngày ra mắt không nằm ở một trải nghiệm hoàn hảo tuyệt đối. Mà ở việc hệ thống có đứng vững được không, khi cả nghìn người ập vào cùng lúc.Đủ thông tin rồi thì không cần bàn thêm. Cứ vậy mà đi.Lần sau, khi thêm database vào hệ thống, trọng tâm chuyển hẳn sang bảo mật. Có dữ liệu thật cần bảo vệ, nghĩa là có thứ đáng để ai đó cố truy cập trái phép. Tôi phải prompt AI kỹ hơn hẳn về cấu hình phân quyền ở tầng database, để đảm bảo mỗi request chỉ lấy đúng dữ liệu được phép lấy, không hơn. Đây là loại rủi ro mà nếu không chủ động hỏi, AI sẽ không bao giờ tự cảnh báo cho bạn.Ba lần launch, ba loại câu hỏi cần đặt đúng trọng tâm. Nếu tôi mang tư duy của lần đầu áp dụng cho lần cuối, chỉ lo tải và hiệu năng mà quên bảo mật dữ liệu, hệ thống vẫn có thể sập. Chỉ là sập theo một cách khác.Trước khi tự đi một mìnhCó một giai đoạn tôi bị đẩy dần ra khỏi những dự án mình đang làm. Không phải bằng một lời sa thải thẳng thắn. Nó đến từ những phản hồi tiêu cực rải rác. Những lượt thả icon phẫn nộ dưới tin nhắn công việc. Rồi chốt lại bằng một câu, đại loại như ở vai trò đó mà không làm được thì cứ ra khỏi dự án. Có lần khác, câu nhận xét là tôi làm được nhiều thứ, nhưng cái giá trị công ty cần ở tôi thì không có. Có lần HR viết sai tên tôi ngay trong đợt review của chính mình, như thể tôi chưa từng thật sự có mặt ở đó. Và có một giai đoạn, tôi ngồi trong chính bộ phận quản lý dự án, nhận một câu review rằng tôi được đưa vào đó chỉ vì đó là điều họ muốn. Không hơn.Tôi kể lại không phải để than. Tôi kể vì đó chính là giai đoạn dạy tôi hiểu, năng lực làm được việc và việc được công nhận là hai chuyện khác nhau. Giống hệt cái khoảng cách giữa build và launch. Làm ra sản phẩm tốt không tự động khiến người khác thấy giá trị của mình. Cũng như build nhanh không tự động khiến launch dễ dàng. Có một khoảng cách ở giữa mà không ai nói cho bạn biết trước. Bạn chỉ hiểu được khi đã tự đi qua nó, đôi khi bằng những buổi tối ngồi lại một mình, tự hỏi mình đã sai ở đâu.Sau giai đoạn đó, tôi chọn một hướng khác. Tự đứng ra làm. Tự chịu trách nhiệm từ đầu đến cuối. Không phải vì tôi giỏi hơn tất cả những người từng ngồi review tôi. Mà vì tôi muốn giá trị của mình được đo bằng sản phẩm tôi thực sự đưa ra thị trường, được khách hàng thật trả tiền cho nó. Không phải bằng một câu nhận xét trong phòng họp.Vì sao tôi làm đượcCó một điều tôi luôn cố tình làm, không phải tình cờ: tôi lôi khách hàng vào ngay giữa quá trình của mình. Tôi chiếm thời gian của họ. Hỏi liên tục. Kéo họ ngồi suy nghĩ cùng, test cùng. Thay vì âm thầm làm rồi đợi đến ngày launch mới cho họ xem lần đầu. Cách này tốn thời gian của cả hai hơn hẳn so với việc làm một mình rồi giao. Nhưng đổi lại, đến lúc launch, không còn bất ngờ nào cả. Vì khách hàng đã đi cùng tôi suốt hành trình. Đã hiểu vì sao một quyết định như bỏ 0,05% trải nghiệm để ưu tiên performance lại hợp lý, thay vì nghe tôi giải thích sau khi mọi chuyện đã rồi.Cái khác nữa, tôi nghĩ, đến từ việc tôi chưa bao giờ chỉ đứng ở một vị trí. Tôi từng làm end to end trong lập trình. Từng làm BA. Từng đứng ngoài mảng IT ở design và marketing, trực tiếp chạy ads. Tôi đi qua nhiều cấp bậc trong doanh nghiệp, từ thành viên, lên lead, đến quản lý. Tôi cũng từng làm mentor, trainer, đứng ở cương vị diễn giả đại diện cho doanh nghiệp, và trực tiếp đứng lớp chia sẻ dạng workshop.Khi một người đã đi qua từng ấy vị trí, họ không còn nhìn một dự án chỉ bằng con mắt của người viết code. Họ thấy được cả phần khách hàng đang lo lắng. Phần vận hành sẽ vướng ở đâu. Phần con số mà người quản lý sẽ hỏi đến.Đó là lý do tôi build nhanh mà vẫn launch được. Không phải vì tôi build giỏi hơn người khác. Mà vì tôi biết đứng ở những vị trí sẽ dùng, sẽ vận hành, sẽ chịu trách nhiệm cho sản phẩm đó, sau khi nó ra mắt.Launch không có nghĩa là “web đã lên mạng”Từ những trải nghiệm này, tôi hiểu launch theo một nghĩa rộng hơn nhiều so với việc bấm nút deploy. Launch là giai đoạn sản phẩm gặp thế giới thật. Traffic thật. Người dùng thật. Rủi ro bảo mật thật. Áp lực vận hành thật. Build là tạo ra sản phẩm chạy được. Launch là đảm bảo sản phẩm đó sống sót và tạo ra giá trị, khi mọi thứ không còn nằm trong tầm kiểm soát của riêng mình nữa.AI rút ngắn đáng kể thời gian build. Nhưng launch đòi hỏi một loại năng lực khác: khả năng lường trước bài toán sẽ xảy ra tiếp theo, và biết hỏi đúng câu hỏi ở đúng thời điểm. AI không tự nhắc bạn về countdown bị cheat. AI cũng không tự nhắc bạn kiểm tra phân quyền dữ liệu. Trừ khi bạn biết đó là điều cần hỏi.Một góc nhìn khác về câu hỏiĐến đây, tôi muốn chia sẻ thêm một góc nhìn. Không phải để phủ nhận câu hỏi ban đầu, mà để mời mọi người nhìn xa hơn một chút.Những gì tôi vừa kể, việc lôi khách hàng vào cùng làm, việc đi qua nhiều vị trí khác nhau, việc biết đặt đúng câu hỏi ở từng giai đoạn, tất cả đều thật sự giúp các dự án của tôi launch ổn hơn. Nhưng càng thấy rõ điều đó, tôi càng nghĩ build và launch vốn là hai ngôn ngữ khác nhau. Không nằm trên cùng một trục để so sánh nhanh hay chậm, dễ hay khó. Build là công việc của người tạo ra sản phẩm. Launch là công việc của người đưa sản phẩm ra thế giới thật, vận hành nó, chịu trách nhiệm với những gì xảy ra sau đó. Một người có thể làm cả hai, như tôi vẫn làm. Nhưng làm cả hai không có nghĩa là gộp chúng thành một.Và nếu chỉ dừng launch lại ở việc đẩy dự án lên, ở việc web chạy được và có vài con số doanh thu, thì vẫn chưa phải điểm đến cuối cùng.Odysseus không dừng lại khi nhìn thấy bờ biển Ithaca từ xa. Ông còn phải bước lên bờ. Giương cây cung mà chỉ mình mình kéo nổi. Giành lại ngôi nhà. Ôm lấy vợ con. Và không kém phần quan trọng, thu phục lại lòng người dân đã từng nghi ngờ mình suốt hai mươi năm vắng mặt.Với tôi, launch một sản phẩm cũng vậy. Đẩy dự án lên chỉ mới là nhìn thấy bờ biển. Điểm đến thật sự là khi sản phẩm được người dùng tin, được thị trường chấp nhận, và được chính những người từng hoài nghi quay lại công nhận. Đó mới là về đến nhà.Tôi viết những dòng này không phải để bắt bẻ ai. Tôi viết vì tôi thật sự trăn trở cho ngành IT, cho rất nhiều sinh viên đang ngồi trong giảng đường, tin rằng cứ học giỏi code, cứ build nhanh, mọi thứ phía sau sẽ tự khắc trôi chảy. Build là một môn học. Launch, theo nghĩa trọn vẹn nhất, đòi hỏi những năng lực hoàn toàn khác: hiểu vận hành, hiểu bảo mật, hiểu con người sẽ dùng sản phẩm, và biết kiên nhẫn đi cho đến khi thu phục được lòng tin. Chứ không dừng lại ở khoảnh khắc nhìn thấy bờ.Ba lớp của một lần launchNhìn lại các dự án đã làm, tôi thấy launch thường đi qua ba lớp câu hỏi. Không nhất thiết theo thứ tự cố định, nhưng luôn cần được trả lời trước khi sản phẩm thực sự sẵn sàng cho người dùng thật.Hệ thống có chịu được tải đột biến không, khi lượng người dùng tăng vọt ngoài dự kiến. Dữ liệu có được bảo vệ đúng cách không, khi hệ thống bắt đầu lưu trữ thông tin thật của người dùng thật. Và sau khi đã sống sót qua hai lớp trên, sản phẩm có thực sự tạo ra kết quả kinh doanh không, hay chỉ đang chạy mà không ai dùng.Build nhanh giúp bạn đến lớp câu hỏi đầu tiên sớm hơn. Nhưng cả ba lớp đều phải tự mình đối mặt. Không có phím tắt nào cho việc đó.AI build ổn. Điều đó không cần bàn cãi. Nhưng launch có ổn hay không, câu trả lời chưa bao giờ nằm ở AI. Nó nằm ở người đứng sau. Ở việc người đó có chịu ở lại đủ lâu, đủ tỉnh táo, đủ can đảm để đi hết ba lớp câu hỏi đó hay không.Giống như lần đứng trước hồ bơi năm nào, nhảy xuống chưa bao giờ là phần khó nhất. Phần khó là biết ai đứng cạnh mình lúc cần. Biết khi nào nên kệ đi, để dồn sức cho điều quan trọng hơn. Và biết bơi, cho đến khi thật sự về đến nhà, không chỉ nhìn thấy bờ, mà còn giành lại được lòng tin của những người đang chờ mình ở đó.Vương Sĩ NguyênPMO - BDM

Con bug ba ngàyHồi mới vào nghề, tôi từng mất ba ngày cho một con bug.Ba ngày đó, nhìn từ mọi góc độ quản lý, là ba ngày lãng phí. Không có tính năng nào được giao. Không có dòng nào đáng giữ lại trong số hàng trăm dòng tôi viết rồi xóa. Nếu lúc đó có một công cụ giải quyết nó trong ba phút, tôi đã dùng ngay mà không do dự một giây.Nhưng mười năm sau nhìn lại, tôi vẫn nhớ nguyên cảm giác của ngày thứ ba, nhớ chính xác chỗ mình đã nghĩ sai, và nhớ cả cái cách nó khiến tôi từ đó về sau tự động nghi ngờ đúng loại giả định ấy. Trong khi hàng trăm ngày làm việc trơn tru cùng năm đó thì không để lại gì cả.Đó là điều làm tôi bận tâm khi đọc đề bài này. Câu hỏi ai cũng đang tranh luận là "AI có làm fresher tiệm cận senior không?" - và nó là một câu hỏi hợp lý. Nhưng có một câu hỏi khác, tôi nghĩ quan trọng hơn nhiều, mà gần như không ai đặt ra:Nếu ba ngày ấy giờ chỉ còn ba phút, thì thế hệ senior tiếp theo sẽ được tạo ra từ đâu?Câu trả lời hiển nhiên, và lý do nó chưa đủNhìn ở lát cắt hôm nay, câu trả lời cho đề bài khá rõ: có, khoảng cách đang hẹp lại - ít nhất là trên bề mặt.Một bạn mới vào nghề bây giờ có thể dựng một hệ thống hoàn chỉnh, đụng vào công nghệ chưa từng học, xử lý những phần việc mà cách đây vài năm chắc chắn phải chuyển lên cho người có kinh nghiệm. Điều này là thật, và tôi không muốn giảm nhẹ nó. Nó đang mở ra cơ hội cho rất nhiều người mà trước đây rào cản kỹ thuật đã chặn lại từ đầu.Nhưng đó là một bức ảnh chụp. Còn nghề nghiệp không phải bức ảnh - nó là một dòng chảy. Trong dòng chảy đó, câu hỏi tĩnh "hôm nay hai bên cách nhau bao xa" ít quan trọng hơn câu hỏi động:Tốc độ chuyển hóa từ fresher thành senior đang tăng lên hay đang chậm lại?Và khi đặt câu hỏi theo cách đó, tôi thấy một bức tranh đáng lo hơn nhiều.Senior thực ra được tạo ra bằng cách nào?Muốn trả lời, phải mổ xẻ một thứ mà chúng ta hay nói đến nhưng ít khi định nghĩa: kinh nghiệm.Kinh nghiệm không đến từ số năm - ai cũng biết những người mười năm kinh nghiệm thực chất là một năm kinh nghiệm lặp lại mười lần. Nó cũng không đến từ khóa học, vì nếu đọc là đủ thì ta đã có thể sản xuất senior hàng loạt từ lâu.Theo quan sát của tôi, kinh nghiệm được tạo ra từ ba nguyên liệu, và cả ba đều rất khó chịu.Nguyên liệu thứ nhất: sự vật lộn có hậu quả. Tự sai, tự chịu, tự sửa. Điểm mấu chốt nằm ở chữ tự và chữ hậu quả. Não người ghi nhớ theo cảm xúc chứ không theo thông tin. Một bài học được giảng giải rõ ràng sẽ trôi đi sau hai tuần; một bài học đi kèm cảm giác hoảng loạn lúc hai giờ sáng thì ở lại mãi mãi. Trực giác kỹ thuật của senior, phần lớn, là nỗi sợ đã được hệ thống hóa - sợ đúng chỗ, dựa trên những lần từng cháy tay.Nguyên liệu thứ hai: sự tiếp xúc kéo dài với cái tệ. Đọc code xấu của người khác. Sống chung với một hệ thống cũ kỹ do ai đó bỏ lại. Chịu hậu quả của một quyết định kiến trúc sai từ ba năm trước. Không ai học được thế nào là tốt nếu chỉ được đọc những thứ tốt. Khiếu thẩm mỹ kỹ thuật hình thành từ sự tương phản - bạn phải sống trong cái tệ đủ lâu để cơ thể tự phản ứng với nó.Nguyên liệu thứ ba: sự lặp lại đủ nhiều để hình thành mẫu. Trực giác không phải phép màu. Nó là nhận diện mẫu đã được nén lại đến mức không còn ý thức được nữa. Senior nhìn một đoạn code và "thấy có gì đó sai" không phải vì họ thông minh hơn, mà vì họ đã nhìn thấy biến thể của tình huống đó bốn mươi lần. Không có số lượng thì không có trực giác. Không có cách nào đi tắt qua phần số lượng.Bây giờ hãy để ý một điều: cả ba nguyên liệu này đều là sản phẩm phụ của việc làm những công việc mà hôm nay AI làm hộ rất giỏi.Không ai từng thiết kế ra dây chuyền đào tạo này. Nó không nằm trong kế hoạch nhân sự của công ty nào cả. Nó chỉ đơn giản là xảy ra, một cách miễn phí, như một tác dụng phụ của việc người mới buộc phải tự làm những việc nhàm chán và khó chịu. Suốt mấy chục năm, ngành phần mềm đã dựa vào một cỗ máy đào tạo mà không ai trả tiền và cũng không ai để ý.Cỗ máy đó vừa bị rút phích.Thứ AI thực sự lấy đi không phải công việc, mà là quá trìnhĐây là chỗ tôi muốn nói cho thật chính xác, vì rất dễ bị hiểu thành "AI xấu" - mà tôi thì không nghĩ vậy chút nào.AI không lấy đi công việc của fresher. Nó lấy đi quá trình và trả lại kết quả.Với người đã có sẵn kinh nghiệm, đó là một món hời tuyệt đối. Tôi đã có phần hiểu biết rồi; giờ tôi chỉ cần kết quả, và tôi biết cách kiểm tra kết quả đó đúng hay sai. Trao đổi này hoàn toàn có lợi cho tôi.Với người đang trong giai đoạn cần xây kinh nghiệm, cùng một trao đổi ấy lại là một mất mát được gói trong hình dạng của một món quà. Họ nhận được thứ họ tưởng mình muốn - kết quả - và đánh mất thứ họ thực sự cần - quá trình tạo ra nó.Một ví von tôi hay dùng: nó giống như đặt một cái thang máy ngay cạnh cầu thang bộ trong phòng tập. Không ai sai khi chọn thang máy cả. Nó nhanh hơn, đỡ mệt hơn, và đưa bạn đến đúng tầng bạn cần. Chỉ có điều, nếu lý do ban đầu bạn đến đây là để khỏe lên, thì bạn vừa lặng lẽ đánh đổi mục đích lấy phương tiện.Và tôi muốn nói rõ điều này: đây không phải lỗi của người mới. Họ hoàn toàn hợp lý khi dùng AI tối đa. Vì hệ thống xung quanh họ đo lường đầu ra, không đo lường sự trưởng thành. Không có buổi đánh giá cuối quý nào hỏi "quý này em đã tự vật lộn với bao nhiêu vấn đề và học được gì". Người ta hỏi em đã giao được bao nhiêu. Khi cách đo là như vậy thì mọi người sẽ tối ưu đúng theo cách đo - đó là hành vi hợp lý, không phải sự lười biếng.Vấn đề nằm ở chỗ cái giá của sự tối ưu này không rơi vào hôm nay. Nó rơi vào năm năm nữa, và rơi vào một người khác.Hai đường cong đi ngược chiều nhauNếu vẽ ra, tôi nghĩ có hai đường cong đang chạy ngược chiều, và chính sự ngược chiều này khiến câu hỏi của đề bài khó trả lời bằng một chữ có hoặc không.Đường cong thứ nhất - khoảng cách năng lực biểu kiến: đang thu hẹp. Đây là đường mà ai cũng nhìn thấy. Fresher làm được nhiều hơn, nhanh hơn, đụng được vào nhiều thứ hơn. Nhìn vào sản phẩm cuối, khoảng cách giữa hai cấp độ mờ đi rõ rệt.Đường cong thứ hai - nguồn cung senior tương lai: đang cạn dần. Đây là đường không ai nhìn thấy, vì nó chỉ hiện ra sau nhiều năm. Lớp senior đang làm việc hôm nay đều được rèn ra trong thời kỳ chưa có AI. Vốn kinh nghiệm của họ đã được nạp đủ từ trước. Ngành đang tiêu số vốn đó - và không có gì đảm bảo nó đang được nạp lại với tốc độ tương đương.Nói gọn lại: chúng ta đang tiêu thụ senior nhanh hơn tốc độ tạo ra senior.Điều nguy hiểm của loại vấn đề này là nó có độ trễ rất dài. Mọi thứ trông hoàn toàn ổn cho đến khi lớp senior hiện tại nghỉ hưu, chuyển sang quản lý, hoặc đơn giản là rời ngành - rồi người ta mới ngơ ngác nhìn quanh và hỏi lớp kế cận đâu. Và trong mọi lĩnh vực, những khủng hoảng có độ trễ dài luôn bị phớt lờ cho đến lúc quá muộn, vì không có ai chịu trách nhiệm cho một hậu quả nằm ngoài nhiệm kỳ của mình.Một tác dụng phụ nữa: người mới mất la bànCó một hệ quả tinh vi hơn mà tôi chỉ nhận ra khi làm việc cùng các bạn trẻ.Trước đây, năng lực và đầu ra gắn chặt với nhau. Bạn chỉ làm ra được thứ tương xứng với trình độ của mình. Điều đó khó chịu, nhưng nó có một lợi ích lớn: nó là một chiếc la bàn. Nhìn vào thứ mình làm được, bạn biết khá chính xác mình đang ở đâu.Bây giờ hai thứ đó tách rời. Một người có thể tạo ra sản phẩm vượt xa trình độ hiện tại của mình. Nghe thì tuyệt, nhưng nó đồng nghĩa với việc tín hiệu phản hồi bị hỏng. Bạn không còn cách nào tự đánh giá mình đang ở đâu.Và điều này dẫn tới thứ đáng lo nhất: sự tự tin đến trước năng lực, thay vì đến sau.Theo trật tự cũ, sự tự tin là phần thưởng - bạn làm được, nên bạn tin mình làm được. Theo trật tự mới, sự tự tin xuất hiện ngay từ tuần đầu tiên, dựa trên những thứ bạn chưa thực sự hiểu. Rồi đến ngày hệ thống hỏng theo một cách mà AI không gợi ý được, người ta mới phát hiện phần nền móng chưa từng được xây.Tôi nhắc lại: đây không phải lời chê trách thế hệ mới. Đây là mô tả một hệ thống phản hồi bị hỏng. Đặt bất kỳ ai - kể cả tôi ở tuổi hai mươi hai - vào đúng hệ thống đó, kết quả cũng sẽ y hệt.Ba phản biện tôi tự đặt ra cho mìnhNếu chỉ dừng ở đây thì bài này chỉ là một lời than quen thuộc. Nên tôi muốn tự tấn công lập luận của chính mình bằng ba phản biện mạnh nhất tôi nghĩ ra được.Phản biện 1: "Thế hệ nào cũng nói thế hệ sau bị hư bởi công cụ mới."Đây là phản biện đúng nhất và cũng khó chịu nhất. Người ta từng nói y hệt về compiler ("lập trình viên sẽ không còn hiểu máy tính"), về IDE ("không ai còn nhớ nổi cú pháp"), về việc tra cứu trên mạng ("copy dán chứ có hiểu gì đâu"). Và ngành vẫn phát triển rực rỡ. Rất có thể tôi chỉ đang là một phiên bản mới của cùng một ông già cằn nhằn.Nhưng tôi nghĩ có một khác biệt về chất, không phải về mức độ. Mọi lớp trừu tượng trước đây đều che đi phần thi hành và giữ nguyên phần tư duy. Compiler lo việc dịch, nhưng bạn vẫn phải tự nghĩ ra logic. IDE lo việc gõ, nhưng bạn vẫn phải tự quyết định gõ cái gì. Mỗi lần lên một tầng trừu tượng, con người vẫn giữ nguyên vai trò: người hình thành ý tưởng.AI là lớp trừu tượng đầu tiên che đi chính khâu hình thành ý tưởng. Nó không thay bạn gõ - nó thay bạn nghĩ ra phương án. Đó là một loại khác hẳn, và tôi cho rằng so sánh với compiler là một phép so sánh an ủi hơn là chính xác.Phản biện 2: "Nhưng nhờ AI, người mới học nhanh hơn hẳn - có một người thầy kiên nhẫn vô hạn bên cạnh."Điều này đúng, và là mặt tích cực thật sự mà tôi không muốn phủ nhận. Chưa bao giờ việc hỏi một câu ngu ngơ lại dễ dàng và ít xấu hổ đến thế. Với những kiến thức có thể diễn đạt thành lời - khái niệm, nguyên lý, cách một thứ hoạt động - tốc độ học đúng là tăng vọt.Nhưng có một khác biệt lớn giữa được giải thích và tự tìm ra. Phần kiến thức nói được thành lời thì AI dạy rất tốt. Phần không nói được thành lời - trực giác, khiếu thẩm mỹ, cảm giác "chỗ này sắp có chuyện" - thì không ai dạy được, cho cả người lẫn máy. Nó chỉ mọc lên từ va chạm trực tiếp. Và trớ trêu thay, chính phần không dạy được ấy mới là thứ phân biệt fresher với senior.Phản biện 3: "Có thể nghề sẽ đổi, và senior kiểu cũ đơn giản là không còn cần nữa."Đây là phản biện mạnh nhất, và tôi thừa nhận nó có thể đúng. Rất có thể trong mười năm nữa, kỹ năng đọc từng dòng code sẽ cổ lỗ như kỹ năng viết assembly hôm nay.Nhưng kể cả khi nghề đổi hoàn toàn, sẽ vẫn cần người phán đoán - người quyết định nên xây gì, đánh đổi cái gì lấy cái gì, chịu trách nhiệm khi mọi thứ hỏng. Và năng lực phán đoán vẫn hình thành theo đúng một cơ chế duy nhất mà loài người từng biết: thử - sai - chịu hậu quả - điều chỉnh. Cơ chế đó không thay đổi trong suốt lịch sử tiến hóa, và tôi không nghĩ nó sẽ thay đổi trong mười năm tới. Nội dung của kinh nghiệm sẽ đổi. Cách kinh nghiệm được tạo ra thì không.Vậy phải làm gìTôi không muốn kết bài bằng một lời cảnh báo rồi bỏ đó. Có những việc cụ thể, ở cả hai phía.Nếu bạn đang trên đường lênTách bạch hai chế độ làm việc. Chế độ giao hàng: dùng AI tối đa, không áy náy gì cả, vì mục tiêu là kết quả. Chế độ rèn luyện: cố tình không dùng, chấp nhận chậm, vì mục tiêu là chính bạn. Điều quan trọng là chế độ thứ hai phải được lên lịch. Nó sẽ không tự xảy ra - áp lực công việc luôn thắng, mọi lúc, không có ngoại lệ.Đảo thứ tự: tự thử trước, hỏi AI sau. Đây là thay đổi nhỏ nhất nhưng quyết định nhất. Cùng một câu trả lời, nếu bạn nhận nó sau khi đã tự vật lộn hai mươi phút, nó sẽ nằm lại. Nếu nhận nó trước, nó trôi qua. Cùng một thông tin, hai kết quả hoàn toàn khác nhau - vì cái quyết định không phải là thông tin, mà là chỗ trống bạn đã đào sẵn trong đầu để đón nó.Đọc kết quả của AI như đọc code của một đồng nghiệp rất giỏi nhưng đôi khi ẩu. Không nghi ngờ vô cớ, nhưng luôn hỏi "tại sao lại làm theo cách này chứ không phải cách kia". Câu hỏi đó, lặp lại đủ nhiều, chính là con đường tắt gần nhất đến trực giác - nếu như có một con đường tắt nào tồn tại.Chọn nơi có người để học và có hậu quả thật, thay vì nơi trả cao hơn hai mươi phần trăm. Trong giai đoạn đầu, thứ đắt nhất bạn có thể mua bằng lương không phải là tiền, mà là một môi trường nơi sai lầm của bạn có hậu quả và có người đủ giỏi để chỉ ra.Nếu bạn là người xây độiĐây là phần tôi phải tự nhắc mình nhiều nhất.Đào tạo không còn là sản phẩm phụ miễn phí nữa. Nó phải được thiết kế. Trước đây người mới tự trưởng thành chỉ nhờ làm việc. Giả định đó vừa hết hiệu lực. Nếu bạn không chủ động tạo ra những va chạm cần thiết, chúng sẽ không bao giờ xảy ra.Cố tình giao một số việc "kém hiệu quả" cho người mới. Nghĩa là chấp nhận việc họ tự làm chậm hơn, sai nhiều hơn, tốn của công ty nhiều hơn - trong một phạm vi được kiểm soát. Đó là chi phí đào tạo trả bằng tiền thật, thay cho cái dây chuyền miễn phí vừa hỏng. Nó không dễ chịu, nhưng không có bữa trưa nào miễn phí mãi mãi.Đo người mới bằng "hiểu được đến đâu", không chỉ bằng "giao được bao nhiêu". Trong buổi review, hỏi vì sao nhiều hơn hỏi xong chưa. Nếu một người không giải thích được lựa chọn trong code của chính mình, thì đó không phải là code của họ - và điều đó quan trọng hơn nhiều so với việc code ấy có chạy hay không.Và trung thực với chính mình: tất cả những điều trên đều tốn tiền, tốn thời gian, và làm giảm hiệu suất trong ngắn hạn. Đó chính xác là lý do phần lớn công ty sẽ không làm. Cũng chính vì thế, những nơi chịu làm sẽ nắm một lợi thế nhân sự khổng lồ trong năm năm tới - khi mà senior thật trở thành thứ khan hiếm nhất trên thị trường.Trả lời thẳng câu hỏi của đề bàiAI có thu hẹp khoảng cách giữa fresher và senior không?Có - nhưng là khoảng cách về thứ làm ra được, không phải khoảng cách về năng lực chịu trách nhiệm cho thứ đó. Fresher hoàn toàn đảm nhận được đầu việc của senior. Sự khác biệt không lộ ra lúc bàn giao; nó lộ ra vào lúc có sự cố, khi câu hỏi không còn là làm thế nào mà là tại sao lại thành ra thế này, và giờ đánh đổi cái gì để sửa.Và điều quan trọng nhất, cũng là điều tôi muốn để lại:Khoảng cách ngắn lại không có nghĩa là dễ vượt qua hơn. Nó ngắn hơn nhưng dốc hơn - vì mấy nấc thang ở đoạn giữa vừa bị tháo mất. Trước đây bạn leo lên bằng cách bước từng nấc một mà thậm chí không nhận ra mình đang leo. Bây giờ khoảng cách trông gần đến mức ai cũng tưởng chỉ cần với tay là tới, nhưng bên dưới thì không còn gì để đặt chân.Điều tôi thực sự nghĩAI không phá hủy nghề lập trình. Nó phá hủy cơ chế đào tạo ngẫu nhiên mà tất cả chúng ta từng được hưởng miễn phí mà không hề hay biết.Hệ quả là kinh nghiệm không còn là thứ tự động đến theo thời gian nữa. Từ nay nó là một lựa chọn có ý thức, phải trả giá bằng những đoạn cố tình đi chậm, cố tình chịu khó, cố tình không dùng công cụ đang nằm sẵn trong tầm tay. Điều đó khó hơn trước rất nhiều, vì trước đây bạn được trưởng thành một cách thụ động, còn bây giờ bạn phải chủ động chọn nó - mỗi ngày, ngược lại với mọi động lực ngắn hạn xung quanh.Nhưng cũng chính vì thế, đây là cơ hội lớn nhất mà tôi thấy cho những người trẻ chịu đi đường dài.Trước đây, chỉ cần ở lại trong nghề đủ lâu là sớm muộn cũng thành senior. Giờ thì không còn đúng nữa. Và trong một thị trường mà con đường đó không còn tự động, những người tự mình đi hết nó sẽ khan hiếm hơn bao giờ hết.

Sự im lặng sau nút "Launch"Có một khoảnh khắc mà tôi nghĩ nhiều người làm sản phẩm đều từng đi qua, dù không phải ai cũng kể ra.Đó là khoảnh khắc bạn bấm nút phát hành. Sản phẩm chạy được. Landing page sạch sẽ. Onboarding mượt. Bài giới thiệu đã đăng. Và rồi… không có gì xảy ra cả. Không phải là thất bại ồn ào, không phải bị chê, không phải bị đối thủ đè bẹp. Chỉ là sự im lặng. Một thứ im lặng rất lịch sự, rất khó trách ai.Điều kỳ lạ là sự im lặng đó ngày nay đến nhanh hơn trước. Vì chặng đường từ ý tưởng đến sản phẩm đã ngắn lại đáng kể. Thứ trước đây ngốn của tôi vài tháng thì giờ có thể xong trong vài ngày. Việc dựng khung, viết logic, xử lý các phần lặp đi lặp lại — AI làm phần lớn. Cảm giác đầu tiên là phấn khích: cuối cùng thì rào cản kỹ thuật cũng hạ xuống, ý tưởng nào cũng có cơ hội được thử.Cảm giác thứ hai, đến muộn hơn và khó chịu hơn nhiều, là: nếu xây dễ đến vậy thì tại sao bán vẫn khó đến vậy?Đề bài đặt ra một câu hỏi rất đúng chỗ: khi xây sản phẩm ngày càng nhanh và dễ, liệu việc ra mắt, thu hút người dùng và tạo doanh thu có dễ theo không? Câu trả lời của tôi, sau vài lần tự va vào tường, là không — và không chỉ là "không dễ hơn", mà thực sự là khó hơn. Không phải vì con người khó tính hơn, mà vì thứ đang khan hiếm đã thay đổi.Ba khoảng cách, và AI chỉ lấp được mộtNếu chia nhỏ hành trình đưa một sản phẩm đến với người dùng, tôi thấy có ba khoảng cách rất khác nhau về bản chất.Khoảng cách thứ nhất: từ ý tưởng đến sản phẩm chạy được. Đây là khoảng cách mà AI đã lấp gần hết. Nó biến một việc từng đòi hỏi kỹ năng, thời gian và tiền bạc thành một việc gần như ai cũng làm được nếu đủ kiên nhẫn. Đây là tin tốt, và cũng là tin tốt cho tất cả mọi người — điểm mấu chốt nằm ở chữ "tất cả".Khoảng cách thứ hai: từ sản phẩm đến người biết tới nó. AI lấp được một nửa và làm hỏng một nửa. Nó giúp bạn sản xuất nội dung, viết bài, dựng chiến dịch, dịch thuật, làm ảnh — nhanh gấp nhiều lần. Nhưng nó cũng làm điều đó cho tất cả những người khác. Kết quả là kênh nào dễ tự động hóa nhất thì kênh đó mất hiệu quả nhanh nhất. Bạn viết mười bài, thị trường viết mười nghìn bài. Chi phí sản xuất tín hiệu giảm xuống gần bằng không, nên giá trị của tín hiệu cũng giảm theo. Cái vốn là lợi thế trở thành yêu cầu tối thiểu.Khoảng cách thứ ba: từ người biết tới sản phẩm đến người chịu trả tiền. Đây là khoảng cách mà AI không chạm được. Và theo trải nghiệm của tôi, đây mới là chỗ hầu hết sản phẩm chết — chết lặng lẽ, sau khi đã có traffic, đã có người đăng ký, đã có vài lời khen chân thành.Nghịch lý nằm ở chỗ: khi hai khoảng cách đầu co lại, khoảng cách thứ ba không những không co, mà còn giãn ra. Bởi vì giờ đây có nhiều sản phẩm hơn cùng đứng trước mặt một người dùng có ngần ấy sự chú ý, ngần ấy ví tiền, và một mức độ hoài nghi đang tăng lên từng tháng.Người ta không trả tiền cho tính năng, người ta trả tiền để bớt rủi roTôi từng nghĩ bán hàng là việc trình bày giá trị. Nếu sản phẩm giải quyết được vấn đề, và tôi giải thích đủ rõ ràng rằng nó giải quyết được vấn đề, thì việc mua là một kết luận logic.Đó là một cách hiểu sai, và tôi mất khá lâu mới thừa nhận điều đó.Hành vi trả tiền không phải là hành vi đánh giá tính năng. Nó là hành vi quản trị rủi ro. Khi một người rút thẻ ra, trong đầu họ không chỉ có câu hỏi "cái này có tốt không". Họ còn có ba câu hỏi khác, thường không nói thành lời:Thứ này có thật không? Nó có làm được đúng như những gì đang nói không, hay tôi đang nhìn một cái demo được dàn dựng?Nó có còn tồn tại sáu tháng nữa không? Nếu tôi đưa dữ liệu, quy trình, thói quen làm việc của tôi vào đây, rồi một ngày nó biến mất, tôi sẽ mất bao nhiêu?Nếu có chuyện gì, ai chịu trách nhiệm? Tôi sẽ nhắn cho ai? Có người thật ở phía bên kia không?Hãy để ý: AI có thể giúp bạn trả lời phần nào câu hỏi thứ nhất — bằng một sản phẩm chạy tốt, một demo mượt, một trang giới thiệu thuyết phục. Nhưng câu hỏi thứ hai và thứ ba thì nó hoàn toàn bất lực. Không có mô hình nào tạo ra được thâm niên. Không có công cụ nào tạo ra được trách nhiệm.Và trớ trêu thay, hai câu hỏi đó mới là hai câu hỏi đắt tiền nhất.Khi "làm được" không còn là bằng chứng của bất cứ điều gìĐây là phần tôi cho là quan trọng nhất, và cũng là phần dễ bị bỏ qua nhất khi người ta ăn mừng năng suất mới.Mọi thị trường đều vận hành trên tín hiệu tin cậy — những dấu hiệu bên ngoài mà người mua dùng để đoán về chất lượng bên trong, vì họ không có thời gian kiểm chứng tất cả. Vấn đề là: giá trị của một tín hiệu tỉ lệ thuận với chi phí tạo ra nó. Tín hiệu nào rẻ thì tín hiệu đó vô nghĩa.Hãy nhìn lại vài tín hiệu quen thuộc:Một landing page đẹp từng có nghĩa là đội ngũ này có nguồn lực, có gu, có sự nghiêm túc. Giờ nó có nghĩa là: ai đó đã bỏ ra hai mươi phút.Một sản phẩm chạy mượt trong video demo từng có nghĩa là năng lực kỹ thuật vững. Giờ nó có nghĩa là: phần dễ nhất đã xong.Một blog dày đặc bài chuyên môn từng có nghĩa là ở đây có chuyên gia thật. Giờ nó có nghĩa là: ở đây có một API key.Một phản hồi email tức thì, chỉn chu, đúng ngữ điệu từng có nghĩa là đội ngũ chăm sóc khách hàng tận tâm. Giờ thì bạn biết rồi đấy.Chuyện đang xảy ra là một cuộc lạm phát tín hiệu. Khi mọi dấu hiệu bề mặt đều có thể được tạo ra với chi phí gần bằng không, thị trường sẽ tự động phá giá chúng và dồn niềm tin sang những tín hiệu không thể mua bằng công cụ:Thời gian tồn tại. Bạn đã ở đây bao lâu rồi? Đã sống qua bao nhiêu lần sản phẩm hỏng và sửa được?Con người có tên và có mặt. Ai đứng sau cái này? Họ có dám để tên thật lên không?Khách hàng thật nói bằng giọng thật. Không phải năm dòng đánh giá năm sao trơn tru, mà một người cụ thể kể một tình huống cụ thể — kể cả phần chưa hoàn hảo.Sự hiện diện có trách nhiệm khi mọi thứ hỏng. Đây là tín hiệu đắt nhất, vì nó chỉ xuất hiện đúng lúc bạn muốn trốn nhất.Nói cách khác: AI làm rẻ đi mọi thứ trừ uy tín. Và vì mọi thứ khác rẻ đi, uy tín trở thành đắt hơn bao giờ hết.Đây chính là lý do tôi cho rằng bước khó nhất không nằm ở khâu làm sản phẩm, cũng không hẳn ở khâu kéo người vào, mà ở khoảnh khắc thuyết phục một người lạ đưa số thẻ tín dụng cho một cái tên họ mới nghe lần đầu.Vì sao khoảnh khắc đó khó đến vậy: nó là khâu duy nhất không có đòn bẩyNếu nhìn kỹ, gần như mọi khâu khác trong hành trình làm sản phẩm đều có đòn bẩy — tức là có cách bỏ ra một đơn vị công sức để thu về nhiều đơn vị kết quả.Viết code có đòn bẩy: một prompt tốt đổi lấy hàng trăm dòng. Nội dung có đòn bẩy: một bài viết hay có thể được đọc bởi hàng nghìn người. Phân phối có đòn bẩy: thuật toán có thể mang bài của bạn đến những người bạn chưa từng gặp. Vận hành có đòn bẩy: tự động hóa.Riêng niềm tin thì không.Niềm tin tích lũy tuyến tính — từng người một, từng lần một, từng lời hứa được giữ một. Bạn không thể nhân bản nó. Bạn không thể tăng tốc nó bằng cách tăng ngân sách. Bạn không thể thuê ngoài nó. Và điều tàn nhẫn nhất: nó tích lũy chậm nhưng mất nhanh. Mười lần giữ lời để xây được một chút, một lần im lặng đúng lúc khách hàng cần là mất sạch.Đó là lý do khâu này khó. Không phải vì nó phức tạp về mặt kỹ thuật — nó đơn giản đến mức tầm thường. Nó khó vì nó không thể rút ngắn, trong một thời đại mà chúng ta đã quen với việc mọi thứ đều rút ngắn được. Chúng ta trở nên rất giỏi trong việc đi nhanh, rồi bước vào khúc duy nhất không cho phép đi nhanh, và không hiểu vì sao mình bị kẹt.Vậy founder làm gì với điều này?Tôi không tin vào những "mẹo tăng trưởng" cho phần này, vì bản chất vấn đề không phải là kỹ thuật. Nhưng có vài thay đổi trong cách nghĩ đã giúp tôi bớt loay hoay.Một, coi niềm tin là sản phẩm phụ của hành động, không phải là chiến dịch. Không ai xây được niềm tin bằng cách "làm một chiến dịch xây dựng niềm tin". Nó là thứ đọng lại sau nhiều lần bạn chịu trách nhiệm một cách công khai. Nghĩa là: thông báo khi có sự cố thay vì im lặng chờ trôi. Nói rõ mình đã sửa gì. Xin lỗi mà không vòng vo. Những việc này không có chỉ số đo đếm đẹp đẽ trong tuần đó, nhưng chúng là thứ duy nhất cộng dồn.Hai, để tên thật và mặt thật lên sản phẩm. Trong một thị trường ngập sản phẩm ẩn danh được tạo ra hàng loạt, việc có một con người cụ thể đứng ra chịu trách nhiệm đã tự nó là một tín hiệu khan hiếm. Nó nói rằng: tôi không thể chạy trốn khỏi thứ này, vì tên tôi gắn với nó.Ba, công bố giới hạn của sản phẩm rõ như công bố tính năng. Đây là điều phản trực giác nhất nhưng hiệu quả nhất tôi từng thử. Nói thẳng sản phẩm không làm được gì, không dành cho ai. Người mua đã quá quen với việc bị hứa hẹn quá mức; một người dám tự giới hạn mình lập tức trở nên đáng tin hơn — vì họ đang cho đi thứ mà kẻ lừa đảo không bao giờ cho đi: một lý do để bạn đừng mua.Bốn, làm những việc không nhân rộng được, trong giai đoạn đầu. Trả lời từng người. Gọi điện. Ngồi xem họ dùng. Điều này không mới, nhưng nó trở nên quan trọng hơn trong thời đại AI, chứ không phải kém đi. Vì đó chính xác là những việc mà đối thủ đang tối ưu năng suất sẽ không làm.Năm, đừng miễn phí quá lâu. Tôi từng nghĩ miễn phí là cách hạ rào cản. Nhưng miễn phí kéo dài cũng là một tín hiệu — tín hiệu rằng chính bạn cũng không chắc thứ này đáng tiền. Việc định giá sớm, dù ở mức thấp, buộc bạn phải đối diện với câu hỏi thật, và cũng cho khách hàng một khung để đánh giá bạn nghiêm túc.Phản biện: "Nhưng AI cũng giúp xây niềm tin mà?"Tôi nghĩ phản biện này công bằng và cần được trả lời, nếu không bài viết này sẽ chỉ là một câu khẩu hiệu dễ chịu.Đúng là AI giúp bạn phản hồi khách hàng nhanh hơn, cá nhân hóa tốt hơn, chăm sóc chu đáo hơn, tài liệu đầy đủ hơn. Tất cả những thứ đó đều góp phần vào trải nghiệm, và trải nghiệm tốt thì sinh ra thiện cảm.Nhưng tôi cho rằng AI ở đây đóng vai trò khuếch đại, chứ không phải tạo ra. Nếu bên dưới có một sự tử tế thật, một cam kết thật, thì nó khuếch đại điều đó và giúp bạn giữ được chất lượng khi quy mô lớn dần. Còn nếu bên dưới trống rỗng, nó khuếch đại sự trống rỗng — và bị phát hiện nhanh hơn bao giờ hết, vì người dùng bây giờ nhận ra giọng máy chỉ trong vài dòng. Một phản hồi tự động chỉn chu cho một vấn đề chưa được giải quyết còn làm người ta giận hơn là im lặng.Cũng cần thừa nhận một ngoại lệ: có những ngách mà niềm tin ít quan trọng — mua một lần, giá rẻ, dùng xong là thôi, giải trí thuần túy. Ở đó, phân phối thắng uy tín. Nhưng đó cũng thường là những ngách khó có doanh thu bền, dễ bị sao chép, và phải chạy đua mãi mãi. Nếu bạn muốn xây thứ gì đó sống lâu hơn một chu kỳ chú ý, tôi không nghĩ có đường vòng nào tránh được phần niềm tin.Điều an ủi nằm ngay trong chính vấn đềTôi kết bài này bằng thứ đã giúp tôi bớt bi quan.Nếu bạn hỏi tôi bước nào khó nhất, câu trả lời là bước từ người biết đến bạn sang người tin bạn đủ để trả tiền. Nhưng chính vì nó khó, chính vì nó không có đòn bẩy, không rút ngắn được, không mua được bằng ngân sách hay công cụ — nó là hào phòng thủ cuối cùng còn lại.Mọi lợi thế có thể sao chép bằng công cụ thì rồi sẽ bị sao chép. Sản phẩm của bạn, đối thủ dựng lại được trong một tuần. Nội dung của bạn, họ viết lại được trong một buổi chiều. Nhưng ba năm bạn giữ lời với khách hàng thì không ai rút gọn được thành ba ngày.AI đã biến việc xây sản phẩm thành một thứ phổ thông. Và cũng chính vì thế, nó biến việc hiểu và giữ được con người thành thứ khan hiếm. Đó không phải tin xấu cho founder — đó là tin xấu cho những ai chỉ có tốc độ.

Một buổi tối không giải thích đượcCó một buổi tối tôi kết thúc công việc sớm hơn thường lệ. Nhìn lại cả ngày, số việc xong nhiều hơn hẳn so với cùng ngày này của một năm trước. Không có sự cố nào. Không có cuộc họp nào kéo dài. Về lý thuyết, đó là một ngày tốt.Nhưng tôi ngồi đó và không làm nổi bất cứ việc gì khác. Không đọc được sách. Không nghĩ được gì tử tế. Chỉ trôi từ tab này sang tab khác trong trạng thái vừa rỗng vừa nặng.Điều làm tôi bận tâm không phải là sự mệt - làm việc thì mệt là chuyện bình thường. Điều làm tôi bận tâm là tôi không giải thích được nó. Tôi đã làm ít giờ hơn. Tôi đã bỏ được phần lớn những việc tay chân từng ngốn thời gian nhất. Theo mọi thước đo tôi đang dùng, hôm đó lẽ ra phải là một ngày nhẹ nhàng.Tôi nhận ra vấn đề - AI giúp tôi làm nhanh hơn, nhưng có chắc là tôi rảnh hơn không ? - với tôi không còn là một câu hỏi lý thuyết. Nó là câu hỏi tôi đã phải tự trả lời để hiểu chuyện gì đang xảy ra với chính mình.Và câu trả lời của tôi là: AI không làm giảm sự mệt. Nó đổi loại mệt. Loại mới nặng hơn, và tệ nhất là nó vô hình - không hiện lên trong bất kỳ thước đo nào chúng ta đang dùng.Hóa ra những việc lặp lại không hoàn toàn là gánh nặngĐây là điều đầu tiên tôi phải thừa nhận, và tôi thừa nhận một cách khá miễn cưỡng vì nó nghe như đang bênh vực sự kém hiệu quả.Trước đây, một ngày làm việc của tôi có nhịp lên xuống rất rõ. Có những đoạn đòi hỏi tư duy căng thẳng: thiết kế một giải pháp, quyết định hướng đi, xử lý một vấn đề chưa từng gặp. Nhưng xen giữa chúng là những đoạn có nhịp: viết phần khung lặp đi lặp lại, đặt tên cho các thành phần, dọn dẹp dữ liệu, sắp lại tài liệu, làm những thao tác mà tay bận nhưng đầu thì gần như được thả lỏng.Tôi từng gọi những đoạn đó là "công việc rác" và mơ đến ngày không phải làm nữa. Nhưng chúng có một chức năng mà tôi không nhận ra: chúng là những quãng nghỉ được ngụy trang thành công việc.Trong lúc tay làm những việc đó, đầu vẫn đang chạy ngầm. Rất nhiều lần lời giải cho vấn đề khó của buổi sáng đến với tôi vào lúc đang làm một việc buồn tẻ của buổi chiều. Không phải vì việc buồn tẻ đó thông minh, mà vì nó tạo ra một khoảng trống có kiểm soát - đủ nhàm để não không bị chiếm dụng, đủ có việc để tôi không thấy mình đang lãng phí thời gian và bỏ đi làm chuyện khác.Một ngày làm việc lành mạnh không phải là một ngày toàn đỉnh cao. Nó cần cả thung lũng. Và những việc lặp lại chính là thung lũng.AI cắt sạch thung lũng, chỉ để lại đỉnhĐây là chỗ mọi thứ thay đổi.AI giỏi nhất đúng ở phần thung lũng. Nó xử lý phần khung, phần lặp, phần buồn tẻ - nhanh và tốt. Đó là lý do ai cũng ngợi ca nó, và lời ngợi ca đó hoàn toàn xứng đáng.Nhưng hệ quả là: sau khi thung lũng bị lấp đầy, những gì còn lại trong ngày làm việc của tôi toàn là đỉnh.Mỗi phút còn lại đều là một phút phải phán đoán, phải đánh giá, phải chọn, phải chịu trách nhiệm. Không còn đoạn nào để trôi. Không còn khoảng nào để đầu tự sắp xếp lại. Tôi bước từ quyết định này sang quyết định kế tiếp, liên tục, suốt cả ngày.Tôi gọi thứ này là mật độ nhận thức - lượng suy nghĩ thực sự phải bỏ ra trên mỗi đơn vị thời gian làm việc.Và đây là mấu chốt: khối lượng công việc có thể giảm, thời gian có thể giảm, nhưng mật độ thì tăng vọt. Tám tiếng ra quyết định liên tục mệt hơn rất nhiều so với tám tiếng có ba tiếng thi hành xen kẽ - dù nhìn từ bên ngoài, ngày thứ hai trông "nhàn" hơn.Vấn đề là chúng ta đo công việc bằng số giờ và số đầu việc. Không ai đo mật độ. Không có ô nào trong bảng theo dõi cho nó. Nên khi mật độ tăng gấp đôi mà số giờ giảm đi một chút, mọi thước đo đều báo rằng bạn đang khỏe hơn, trong khi cơ thể bạn nói ngược lại. Và vì số liệu nói bạn ổn, bạn kết luận là mình yếu.Từ người làm thành người duyệt - và ba cái giá không ai nóiSự chuyển dịch này còn sâu hơn chuyện nhịp làm việc. Nó thay đổi cả vai trò.Trước đây tôi là người làm ra thứ gì đó. Giờ, phần lớn thời gian, tôi là người duyệt thứ do máy làm ra. Nghe thì có vẻ được thăng chức. Thực tế nó đi kèm ba cái giá mà tôi không thấy ai tính vào.Cái giá thứ nhất: đánh giá khó hơn tạo ra. Bất kỳ ai từng đọc code người khác viết đều biết cảm giác này - đọc một trăm dòng do người khác viết mệt hơn tự viết một trăm dòng. Khi tự làm, sự hiểu biết được xây dần theo từng bước; đến lúc xong, bạn đã hiểu nó từ trong ra. Khi duyệt, bạn nhận về một kết quả hoàn chỉnh và phải ngược dòng để hiểu, mà không có lợi thế của quá trình. Và với thứ do AI tạo ra, sự việc còn khó hơn: nó luôn trông đúng. Sai lầm không nằm ở chỗ lộ liễu, nó nằm ẩn dưới một bề mặt trơn tru và tự tin.Cái giá thứ hai: trách nhiệm không hề giảm theo. AI làm phần việc, nhưng cái tên ký ở dưới vẫn là của tôi. Nếu sai, không ai quan tâm phần đó do máy sinh ra. Nghĩa là tôi đã chuyển giao công sức mà không chuyển giao được rủi ro. Trong mọi cách sắp xếp lao động, đó là cách mệt nhất: mất phần dễ chịu của việc làm ra thứ gì đó, giữ nguyên phần nặng nề của việc chịu trách nhiệm về nó.Cái giá thứ ba: mất điểm dừng tự nhiên. Khi tự làm, có một thời điểm rất rõ ràng gọi là xong. Bạn kiệt sức, bạn đã bỏ ra ngần ấy công, và bạn dừng. Khi duyệt, điểm dừng đó biến mất. Luôn có thể tạo thêm một phương án nữa. Luôn có thể thử một hướng khác trong ba mươi giây. Ranh giới giữa "đủ tốt" và "còn có thể tốt hơn" từng được vẽ bởi giới hạn thể lực của chính bạn; giờ nó phải được vẽ bằng ý chí. Mà ý chí thì cạn nhanh hơn thể lực nhiều.Cái mất âm thầm nhất: thời gian ủCó một thứ nữa biến mất cùng với các quãng chậm, và tôi cho rằng nó là cái mất đáng lo nhất, đặc biệt với người phải ra quyết định.Đó là thời gian ủ - những bản nháp bị vứt đi, những lần viết lại từ đầu, đoạn ngồi nhìn màn hình mà chưa gõ được gì, lần đọc lại thứ ba khi bỗng nhận ra vấn đề thật nằm ở chỗ khác.Nhìn từ góc độ năng suất, tất cả những thứ đó đều là lãng phí. Nhưng chúng không phải là chi phí của việc tạo ra kết quả - chúng là chi phí của việc hình thành hiểu biết. Bản nháp bị vứt đi không vô ích: nó là cách tôi phát hiện mình đang nghĩ sai. Nếu bỏ qua bước đó và đi thẳng đến bản hoàn chỉnh, tôi có kết quả mà không có phần hiểu đi kèm.Và đây là chỗ dễ tự lừa mình nhất: rất dễ nhầm "làm xong" với "hiểu xong".Với một tài liệu, nhầm lẫn đó không sao. Với một quyết định về sản phẩm, về hướng đi, về việc nên bỏ cái gì - nó đắt. Bạn ra quyết định dựa trên một hiểu biết đi mượn, mượt mà và đầy đủ ở bề mặt, nhưng bạn không thực sự sở hữu nó. Đến lần sau gặp vấn đề tương tự, bạn vẫn phải hỏi lại từ đầu. Kinh nghiệm không tích lũy. Bạn đi nhanh mà không đi xa thêm.Và một nghịch lý nữa: làm gì cũng rẻ, nên cái gì cũng mởCòn một nguồn mệt nữa mà tôi chỉ nhận ra khá muộn, và nó thuần túy thuộc về người làm sản phẩm.Khi chi phí thử một ý tưởng giảm mạnh, tôi thử nhiều hơn. Điều đó nghe hoàn toàn hợp lý - thậm chí là khôn ngoan. Nhưng hệ quả là số việc đang dở dang trong đầu tôi tăng lên rất nhiều. Ba nhánh sản phẩm đang thăm dò. Hai thử nghiệm chưa kết luận. Một hướng nữa vừa mở ra tuần trước vì "chỉ mất một buổi để thử thôi".Sự mệt của người làm sản phẩm phần lớn không đến từ việc đang làm. Nó đến từ việc đang mở. Mỗi việc chưa đóng lại chiếm một chỗ thường trú trong đầu, kể cả khi bạn không đụng đến nó suốt hai tuần. AI làm chi phí mở ra giảm gần bằng không, nhưng chi phí giữ trong đầu thì không hề giảm - nó vẫn phụ thuộc vào bộ não bạn, thứ chưa được nâng cấp lần nào.Nói cách khác: AI hạ chi phí bắt đầu, nhưng không hạ chi phí mang vác. Và phần lớn cái nặng nằm ở việc mang vác.Vậy trả lời thẳng câu hỏi của đề bàiAI đã giúp tôi giảm khối lượng công việc hay chỉ thay đổi cách tôi làm việc?Nó giảm khối lượng thao tác, nhưng không giảm khối lượng công việc. Và nó tăng mật độ của phần công việc còn lại.Còn về chuyện "rảnh hơn" - tôi nghĩ chúng ta đang dùng sai định nghĩa. Rảnh không phải là không có việc trong lịch. Rảnh là không có việc trong đầu. Đó là trạng thái bạn có thể ngồi xuống với một cuốn sách và thực sự đọc được, thay vì đọc ba trang rồi nhận ra mình đang nghĩ về chuyện khác.Theo định nghĩa đó thì AI dọn dẹp cái lịch rất giỏi, nhưng nó không dọn được cái đầu. Có những lúc nó còn làm cái đầu đầy hơn - vì cái lịch trống ra thì lập tức có thứ mới được nhét vào, và vì mỗi việc giờ nặng hơn về mặt tư duy so với trước.Tôi đã điều chỉnh gìTôi không có mẹo tăng năng suất nào ở đây, vì vấn đề không nằm ở năng suất. Nhưng có vài điều chỉnh đã giúp tôi.Cố tình giữ lại một ít việc thủ công. Nghe phản logic, nhưng tôi giữ lại một số việc lặp lại mà đáng ra có thể tự động hóa, đơn giản vì tôi cần thung lũng. Đó không phải là kém hiệu quả - đó là bảo trì cho thứ công cụ quan trọng nhất trong ngày làm việc, tức là chính cái đầu của mình.Đo bằng số quyết định, không phải số giờ. Khi nhìn lại một ngày, tôi hỏi "hôm nay mình đã phải phán đoán bao nhiêu lần" thay vì "hôm nay mình làm mấy tiếng". Câu trả lời thường giải thích được sự mệt mà số giờ không giải thích nổi.Đặt trần cho số việc đang mở, thay vì cho số việc phải làm. Danh sách việc cần làm thì ai cũng có. Ít người có danh sách việc đang treo trong đầu và một giới hạn cứng cho nó. Với tôi, con số đó quan trọng hơn nhiều.Với những thứ thực sự quan trọng, cố tình đi chậm ở khâu hiểu. Trước khi nhờ AI, tôi tự viết ra vấn đề bằng ngôn ngữ của mình - thô, xấu, lộn xộn cũng được. Không phải để làm ra kết quả tốt hơn, mà để đảm bảo phần hiểu biết là của tôi chứ không phải đi mượn.Ngừng coi "xong sớm" là tín hiệu để nhận thêm việc. Đây là điều khó nhất, vì phản xạ đã ăn vào người. Nhưng nếu mọi khoảng trống vừa xuất hiện đều bị lấp ngay lập tức, thì không có công cụ nào trên đời làm bạn rảnh hơn được cả.Phản biện: đây có phải là than vãn của người có đặc quyền không?Tôi nghĩ câu hỏi này công bằng, và bài viết sẽ thiếu thành thật nếu né nó.Có rất nhiều công việc mà phần lặp lại chiếm gần như toàn bộ - nhập liệu, xử lý giấy tờ, dịch thuật khối lượng lớn, tổng hợp báo cáo theo mẫu. Với những công việc đó, AI mang lại sự nhẹ nhõm rất thật, và tôi không muốn dùng trải nghiệm của mình để phủ nhận điều đó. Nói rằng "việc lặp lại là quãng nghỉ quý giá" với một người ngồi nhập liệu tám tiếng mỗi ngày thì vừa sai vừa vô duyên.Luận điểm của tôi chỉ đúng trong phạm vi những công việc mà phần ra quyết định vẫn thuộc về con người - nơi AI lấy đi phần thi hành nhưng để lại nguyên phần phán đoán và trách nhiệm. Ở đó, cán cân dịch chuyển theo hướng tôi vừa mô tả.Và ngay cả khi đã thấy hết những điều này, tôi vẫn không muốn quay lại thời chưa có AI. Không một chút nào. Vấn đề không nằm ở công cụ. Vấn đề là chúng ta đã cập nhật cách làm việc nhưng chưa cập nhật cách đo và cách nghỉ - vẫn dùng thước đo của thời mà năng suất tỉ lệ thuận với số giờ ngồi bàn, để đo một kiểu lao động đã hoàn toàn khác về bản chất.Cái khan hiếm mớiNếu phải rút gọn tất cả vào một câu, tôi sẽ nói thế này.Khi tốc độ làm việc tăng lên, thứ khan hiếm không còn là thời gian nữa. Thứ khan hiếm là sự chú ý còn sót lại sau khi làm việc xong.Có thể có thêm ba tiếng trống trong ngày mà vẫn không dùng được chúng vào bất cứ việc gì có ý nghĩa, vì phần đầu óc cần cho ba tiếng đó đã bị tiêu sạch từ buổi sáng. Đó chính là lý do câu hỏi "AI có làm bạn rảnh hơn không" là một câu hỏi đặt sai. Nó hỏi về thời gian, trong khi thứ chúng ta thực sự đang mất là năng lực chú ý.Nên câu trả lời của tôi cho đề bài là: AI không giảm khối lượng công việc của tôi. Nó thay đổi cách tôi làm việc, và cùng với đó, nó thay đổi loại mệt tôi mang về nhà mỗi tối. Loại mệt mới này gọn gàng hơn, ít mồ hôi hơn, nhìn từ ngoài vào thì sạch sẽ hơn nhiều - và không hiện lên trong bất kỳ con số nào, kể cả trong cách tôi tự đánh giá chính mình.

Nhiều người mặc định rằng: Tech stack càng phổ biến, lương càng cao vì nhu cầu thị trường lớn. Nghe thì có vẻ hợp lý, nhưng dưới góc nhìn kinh tế học, đây là một chiếc bẫy thu nhập. Tech stack phổ biến nghĩa là rào cản gia nhập thấp, người học cực đông, và bạn sẽ phải đối mặt với một "Đại dương đỏ" đầy máu nơi các Dev cấu xé nhau bằng cách phá giá lương để có dự án.Muốn có mức thu nhập đột phá, bạn phải biết cách dịch chuyển sang "Đại dương xanh" — nơi bạn kết hợp công nghệ để tạo ra một giải pháp độc bản mà thị trường khan hiếm.Cách mình giải quyết bài toán vị thế: Mình nhận ra nếu chỉ làm IT vận hành hoặc code web dạo thuần túy bằng JavaScript/React, mình sẽ mãi nằm ở nhóm trung bình của xã hội. Vì vậy, mình không chọn đổi stack theo kiểu nhảy từ ngôn ngữ này sang ngôn ngữ khác, mà mình tạo ra một stack ngách độc đáo cho riêng mình: Kết hợp giữa Automation Scripting (Python) + Browser Extension Customization (JS/XPath) + Hạ tầng mạng Linux.Thay vì đi xin việc làm thuê, mình dùng stack này để tự xây dựng các công cụ tự động hóa quy trình cho các dự án cá nhân, đặc biệt là trong các mảng tối ưu hóa dữ liệu và hạ tầng Web3. Việc tự tay build một hệ thống proxy hàng ngàn cổng hoạt động ổn định hay viết extension tự động quản lý cache/cookie để bypass các cơ chế hạn chế của browser đã mang lại cho mình nguồn thu nhập vượt xa mức lương của một Dev chỉ biết làm theo yêu cầu.Sai lầm nhiều người mắc phải: Nghĩ rằng cứ học ngôn ngữ hiếm là lương cao. Thực ra ngôn ngữ hiếm mà không có thị trường thì cũng vô dụng.Giải pháp hiệu quả: Dùng các công nghệ phổ biến (Python, JS) nhưng ứng dụng nó vào một lĩnh vực ngách cụ thể (như Automation & Hạ tầng) để tạo ra giá trị không thể thay thế.Bài học cốt lõi: Mức lương hay thu nhập của bạn không tỷ lệ thuận với độ phổ biến của Tech stack, nó tỷ lệ thuận với độ khó của bài toán bạn giải quyết và số lượng người có thể thay thế bạn. Thay vì cố gắng trở thành người thứ 10.000 biết viết một trang web React cơ bản, hãy là người duy nhất trong phòng biết cách dùng Python và Linux để tự động hóa toàn bộ hệ thống vận hành của doanh nghiệp. Đi vào lối ngách một cách thông minh chính là cách ngắn nhất để làm chủ bảng lương của chính mình.

Hai startup, hai kết cụcStartup A ra mắt MVP trong 6 tuần. Auth bằng JWT tự viết, password hash bằng MD5 vì "nhanh hơn bcrypt", session không có expiry, API endpoint không check authorization — chỉ check authentication. Họ lý luận: "Chưa có user thật, chưa cần lo security."Tháng thứ 4, họ có 8,000 user. Tháng thứ 5, có người tìm ra IDOR (Insecure Direct Object Reference) trong API — chỉ cần đổi user_id trong request là đọc được data của bất kỳ ai. Toàn bộ database 8,000 user bị scrape trong một đêm. Email, số điện thoại, lịch sử giao dịch.Họ mất 3 tháng và gần như toàn bộ runway để xử lý hậu quả — thông báo user, rewrite auth layer, audit lại toàn bộ API. Một co-founder rời đi. Họ không bao giờ recover được trust từ những early adopter quan trọng nhất.Startup B cũng làm nhanh. Nhưng trước khi viết dòng code đầu tiên, họ dành 2 giờ để trả lời một câu hỏi: "Nếu hệ thống của chúng ta bị tấn công, thứ tệ nhất có thể xảy ra là gì?" Từ đó, họ xác định 4 security invariants — những property bắt buộc phải đúng từ đầu — và xây mọi thứ xung quanh đó. Phần còn lại, họ iterate như bình thường.Startup B vẫn ship nhanh. Nhưng họ không bao giờ phải dừng lại để rebuild nền móng.Sự khác biệt không phải là bao nhiêu thời gian họ dành cho security. Sự khác biệt là họ hiểu cái gì không thể sửa sau.Technical Debt — Khái Niệm Bạn Biết Nhưng Chưa Hiểu ĐủWard Cunningham — người đặt ra thuật ngữ "technical debt" — mô tả nó như một khoản vay: bạn viết code chưa hoàn hảo hôm nay để ship nhanh hơn, với ý định sẽ "trả nợ" sau bằng cách refactor.Metaphor này có hai phần quan trọng mà developer hay bỏ qua:Một là: nợ có lãi suất. Code xấu không chỉ là code xấu — nó là code ngày càng khó sửa hơn khi codebase lớn dần, khi có thêm người join, khi có thêm feature build trên nền đó. Lãi suất của technical debt tăng theo thời gian.Hai là: có những khoản nợ không thể trả. Bạn có thể refactor một function xấu. Bạn có thể đổi tên biến, tách class, viết lại module. Nhưng có một số quyết định kiến trúc — một khi đã đi theo hướng đó và build đủ nhiều thứ lên trên — thì chi phí để quay lại gần như tương đương với việc rewrite từ đầu.Security debt thuộc loại thứ hai.Security Debt Khác Technical Debt Thông Thường Ở Điểm GìĐây là điểm mấu chốt mà hầu hết bài viết về chủ đề này bỏ qua.Technical debt thông thường ảnh hưởng đến tốc độ của bạn. Codebase càng nhiều nợ, bạn develop càng chậm, bug xuất hiện càng nhiều, onboarding engineer mới càng mất thời gian. Đau, nhưng là đau từ từ, có thể dự báo được.Security debt ảnh hưởng đến sự tồn tại của bạn. Và nó hoạt động theo cơ chế hoàn toàn khác:Cơ chế 1: Rủi ro không tuyến tínhTechnical debt tích lũy đều đặn — 10 bad function hôm nay, 20 bad function tuần sau. Security debt không hoạt động theo cách đó. Một lỗ hổng duy nhất, dù hệ thống của bạn có 99 thứ khác hoàn hảo, vẫn có thể là điểm vào để toàn bộ hệ thống sụp đổ.Attacker không cần phá vỡ mọi thứ. Họ chỉ cần tìm đúng một điểm yếu.Cơ chế 2: Chi phí tăng theo cấp số nhân theo thời gian phát hiệnIBM Cost of a Data Breach Report (2023) đưa ra con số cụ thể: trung bình một data breach tốn $4.45 triệu USD để xử lý — bao gồm investigation, remediation, notification, legal liability, và reputational damage.Nhưng con số quan trọng hơn là thời gian phát hiện: những breach được phát hiện trong vòng 200 ngày có chi phí trung bình thấp hơn 23% so với những breach phát hiện sau 200 ngày. Lỗ hổng càng tồn tại lâu, thiệt hại càng nhân lên.Với startup giai đoạn đầu, bạn không có $4.45 triệu để xử lý hậu quả. Một breach nghiêm trọng ở scale vài nghìn user đã đủ để:Mất toàn bộ early adopterVi phạm quy định bảo vệ dữ liệu (PDPA tại Việt Nam, GDPR nếu có user EU)Mất khả năng raise funding — không investor nào muốn đổ tiền vào startup vừa bị hackMất nhân sự — engineer giỏi không muốn làm việc với codebase mà họ biết là thiếu an toànCơ chế 3: Trust collapse không có đường quay lạiTechnical debt không ai nhìn thấy từ bên ngoài. Security incident thì ngược lại — nó là public event. Một khi user đã bị breach, họ không quên. Và trong thời đại social media, câu chuyện lan rất nhanh.Đây là thứ không thể mua lại bằng tiền hay refactor bằng code.Barry Boehm và Cái Giá Của Việc Sửa MuộnNăm 1981, nhà khoa học máy tính Barry Boehm công bố một nghiên cứu mà kết quả của nó vẫn còn nguyên giá trị đến hôm nay: chi phí để sửa một lỗi tăng theo hàm mũ theo thời gian phát hiện trong vòng đời phát triển phần mềm.Cụ thể:Sửa lỗi trong giai đoạn requirements/design: chi phí cơ sở = 1xSửa trong giai đoạn coding: 6xSửa trong giai đoạn testing: 15xSửa sau khi đã release: 100xBoehm gọi đây là Cost of Change Curve — và nó là lý do cơ bản nhất tại sao "làm đúng từ đầu" không phải là chủ nghĩa hoàn hảo, mà là kinh tế học thuần túy.Với security, curve này còn dốc hơn. Vì sửa security không chỉ là sửa code — đó là sửa kiến trúc, migrate data, thay đổi cách hệ thống xử lý mọi request, retest toàn bộ, và đôi khi thông báo cho tất cả user về việc thay đổi.Lấy ví dụ cụ thể: Row-Level Security (RLS).Nếu bạn thiết kế database từ đầu với RLS — mỗi query tự động filter theo user_id của người đang đăng nhập — đó là vài dòng config trong PostgreSQL và một số convention trong ORM layer. Chi phí: gần bằng 0.Nếu bạn đã có 50 model, 200 API endpoint, và data của nhiều user đã pha trộn trong cùng table mà không có isolation rõ ràng, việc retrofit RLS là một dự án riêng kéo dài vài tuần, với rủi ro cao là bỏ sót edge case nào đó trong quá trình migration.Đây không phải lý thuyết — đây là câu chuyện xảy ra ở hầu hết mọi startup khi họ bắt đầu nghĩ nghiêm túc về multi-tenancy hoặc data isolation.Ba Quyết Định Kiến Trúc Mà Solo Builder Thường Làm SaiKhông phải mọi security decision đều quan trọng như nhau ở giai đoạn đầu. Nhưng có ba quyết định mà nếu làm sai, chi phí để sửa sau này là không tỷ lệ với công sức làm đúng ngay từ đầu.Quyết định 1: Authentication & Session ManagementĐây là nơi nhiều solo builder tự viết thay vì dùng thư viện đã được kiểm chứng — vì nghĩ là "đơn giản thôi."Auth không đơn giản. Auth là một trong những domain có nhiều edge case và subtle vulnerability nhất trong toàn bộ application security. Chỉ riêng JWT đã có hàng chục cách implement sai: alg: none attack, weak secret, missing expiry, improper invalidation sau logout, không rotate refresh token.Làm đúng từ đầu trông như thế nào:Dùng thư viện auth đã được audit: NextAuth, Passport.js, Auth.js, hoặc managed service như Clerk, Supabase AuthPassword phải hash bằng bcrypt/argon2 — không phải MD5, SHA1, hay SHA256 thuần túySession token phải có expiry hợp lý và phải invalidate được server-side khi logoutImplement rate limiting trên login endpoint từ ngày đầu — brute force là attack cơ bản nhấtChi phí để làm đúng: thêm 2-3 giờ setup ban đầu.Chi phí để fix sau khi đã có user và đang dùng auth sai: migration toàn bộ password hash (buộc user reset password), rewrite session management, audit toàn bộ flow liên quan. Tính bằng tuần.Quyết định 2: Authorization Model — Ai Được Xem GìAuthentication hỏi: "Bạn là ai?" Authorization hỏi: "Bạn được phép làm gì?"Hầu hết solo builder implement authentication tương đối ổn. Authorization thì thường bị bỏ qua hoặc làm không nhất quán.Pattern nguy hiểm phổ biến nhất: check authentication nhưng không check authorization.// ❌ Pattern sai — chỉ check user đã login app.get('/api/documents/:id', requireAuth, async (req, res) => { const doc = await Document.findById(req.params.id) return res.json(doc) }) // ✅ Pattern đúng — check user có quyền với resource cụ thể app.get('/api/documents/:id', requireAuth, async (req, res) => { const doc = await Document.findOne({ _id: req.params.id, owner: req.user.id // Chỉ trả về nếu document thuộc về user này }) if (!doc) return res.status(404).json({ error: 'Not found' }) return res.json(doc) })Lỗi này có tên trong OWASP Top 10: Broken Object Level Authorization (BOLA) — hay còn gọi là IDOR (Insecure Direct Object Reference). Đây là vulnerability phổ biến nhất trong API hiện đại, và là thứ đã hạ gục Startup A trong câu chuyện mở đầu.Làm đúng từ đầu: Mọi query lấy data đều phải có điều kiện filter theo owner/tenant. Đây là convention — một khi đã là convention trong codebase, mọi developer (kể cả bạn trong tương lai) sẽ tự nhiên follow.Fix sau: Audit lại 200 API endpoint, tìm chỗ nào còn thiếu authorization check, test từng cái. Và bạn sẽ không bao giờ chắc chắn 100% mình đã tìm hết.Quyết định 3: Secret ManagementSecrets — API key, database password, JWT secret, third-party credentials — là mục tiêu số một của automated scanner trên GitHub. Có những tool chạy 24/7 scan mọi public repository mới để tìm credentials bị commit nhầm.Pattern sai phổ biến:# .env file bị commit vào git DATABASE_URL=postgresql://admin:supersecret@localhost/prod JWT_SECRET=myverysecretkey123 STRIPE_SECRET_KEY=sk_live_xxxxxHoặc hardcode trong code:const stripe = new Stripe('sk_live_xxxxx') // ❌Làm đúng từ đầu:.env phải có trong .gitignore từ commit đầu tiên — không phải "sẽ thêm sau"Dùng environment variables hoặc secret manager (AWS Secrets Manager, Doppler, Vault)Rotate tất cả credentials nếu bạn không chắc chắn 100% chưa bao giờ commitChi phí để làm đúng: 30 phút setup .gitignore và .env.example đúng cách.Chi phí khi bị lộ: rotate toàn bộ credential, audit xem secret đó đã bị dùng chưa, thông báo cho các bên liên quan. Stripe key bị lộ có thể dẫn đến charge fraudulent hàng nghìn đô trước khi bạn kịp nhận ra.Security Invariants — Khái Niệm Bạn Cần BiếtĐây là framework tôi thấy hữu ích nhất để solo builder tiếp cận security mà không bị overwhelm.Security invariant là một property của hệ thống phải luôn đúng, bất kể codebase phát triển theo hướng nào.Ví dụ:"Không có user nào có thể đọc data của user khác trừ khi được explicit grant.""Mọi input từ bên ngoài đều phải được validate trước khi xử lý.""Không có credential nào được hardcode trong source code.""Mọi action thay đổi data phải được log với timestamp và actor."Điểm mạnh của cách tiếp cận này: thay vì cố gắng implement một checklist security dài vô tận, bạn xác định 4-5 invariant quan trọng nhất với domain của mình, rồi đảm bảo mọi quyết định thiết kế không vi phạm chúng.Và khi onboard người mới hoặc review PR, câu hỏi không phải là "code này có secure không?" (quá mơ hồ) mà là "code này có vi phạm invariant nào không?" (có thể kiểm tra được).Quy trình xác định security invariants cho solo builder:Hỏi: "Data nhạy cảm nhất trong app của tôi là gì?" (PII, payment info, private content)Hỏi: "Thứ tệ nhất có thể xảy ra nếu data đó bị lộ?"Hỏi: "Điều gì phải luôn đúng để điều đó không xảy ra?"Viết ra 4-5 câu khẳng định — đó là invariants của bạnReview lại chúng mỗi khi thêm feature mới có ảnh hưởng đến data modelVibe Coding + Security Debt — Nhân Tố NhânMột yếu tố mới cần nhắc đến trong năm 2025: AI-assisted development đang làm cho security debt tích lũy nhanh hơn bao giờ hết.Lý do không phải AI tạo ra code xấu (dù điều đó cũng xảy ra — nghiên cứu của NYU/Stanford năm 2022 cho thấy ~40% code do Copilot generate trong security-sensitive context chứa lỗ hổng). Lý do sâu hơn là velocity tăng nhưng comprehension không tăng tương ứng.Khi bạn tự viết code, bạn hiểu từng dòng. Khi bạn vibe code với AI, bạn có thể review và hiểu — nhưng dưới áp lực deadline, review trở thành "đọc lướt thấy trông ổn thì ship."Với business logic, đó là acceptable risk — bug có thể fix bằng hotfix.Với security, một authorization check bị bỏ sót, một input validation thiếu, một secret bị log — những thứ này có thể nằm im trong production nhiều tháng trước khi được exploit.Nguyên tắc thực tế: Với mọi code liên quan đến auth, authorization, input handling, hoặc data access — dù do AI hay bạn viết — hãy dành thêm 5 phút để hỏi: "Code này có vi phạm security invariant nào của mình không?"Năm phút đó là khoản đầu tư tốt nhất bạn có thể làm.Minimal Security Baseline Cho Solo BuilderKhông ai expect bạn implement zero-trust architecture hay ISO 27001 từ ngày đầu. Nhưng đây là baseline tối thiểu mà chi phí implement thấp hơn rất nhiều so với chi phí bỏ qua:Trước khi viết dòng code đầu tiên (2 giờ):Xác định 4-5 security invariants cho domain của bạnSetup .gitignore đúng cách, không bao giờ commit .envChọn managed auth solution thay vì tự viếtKhi build data layer:Mọi query lấy data đều filter theo owner — đây là convention, không phải optionDùng ORM với parameterized query — không bao giờ string concatenation trong SQLThiết kế data model với tư duy "ai được phép xem table này?"Khi build API layer:Authentication + Authorization tách biệt và nhất quánValidate input ở layer nhận — không tin tưởng bất kỳ thứ gì từ clientRate limiting trên mọi endpoint public, đặc biệt auth endpointTrước khi go live với user thực:Chạy OWASP ZAP hoặc tương đương để scan một lầnReview tất cả environment variable — không có gì hardcodeCó kế hoạch "nếu bị breach, tôi làm gì trong 24 giờ đầu?"Câu Hỏi Đúng Không Phải Là "Khi Nào Làm Security"Câu hỏi sai: "Nên làm security ở giai đoạn nào?"Câu hỏi đúng: "Quyết định nào hôm nay sẽ không thể sửa lại sau mà không phải trả giá rất đắt?"Với technical debt thông thường — code xấu, thiếu test, architecture chưa tốt — câu trả lời thường là "ship trước, refactor sau." Và đó là quyết định hợp lý trong nhiều trường hợp.Với security debt — auth sai, authorization thiếu, secret bị lộ, data không được isolate — câu trả lời là khác. Vì những thứ này không chỉ làm bạn chậm. Chúng có thể kết thúc mọi thứ bạn đang xây dựng.Solo builder giỏi không phải là người làm security hoàn hảo từ đầu. Mà là người biết phân biệt được: thứ gì có thể sửa sau, và thứ gì không.Đó là tư duy của người build để tồn tại — không chỉ build để ship.

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

Tôi vào nghề với một niềm tin giản dị: code tốt là đủ. Viết clean code, close ticket đúng deadline, không để bug lên production — vậy là một dev giỏi. Hơn năm năm đi làm, tôi dần trở thành người được giao task khó nhất team. Rồi đến lúc tôi nhảy vào một dự án Fintech.Tuần đầu tiên tưởng bình thường. CRUD vẫn là CRUD. API vẫn là API. Nhưng rồi có một buổi chiều, PM hỏi: "Nếu hệ thống xử lý sai số tiền của người dùng, chuyện gì xảy ra?"Tôi định trả lời theo kiểu dev: "Thì mình log lỗi rồi rollback." Nhưng nhìn khuôn mặt mọi người trong phòng — tôi hiểu câu hỏi đó không phải về technical.Trong Fintech, bug không phải là lỗi phần mềm. Bug là ai đó mất tiền thật.Từ "viết code chạy được" đến "viết code đáng tin"Dev 5 năm dạy tôi nhiều thứ: clean architecture, performance, CI/CD pipeline. Nhưng có một thứ tôi chưa từng nghĩ tới — chi phí của sự sai lầm.Trong các project trước, nếu UI hiển thị sai giá sản phẩm, user reload lại là xong. Còn khi số dư tài khoản hiển thị sai vì một race condition không ai kiểm tra — không có chuyện "reload lại là xong".Tôi bắt đầu đọc lại codebase không phải để hiểu logic làm gì, mà để hỏi: cái này sai được không? Nếu sai, sai đến đâu?Ba câu hỏi tôi học được cách đặt ra mỗi ngày:Nếu request này chạy 2 lần cùng lúc thì sao? — Idempotency không còn là khái niệm học thuật, đó là thứ phải code mỗi ngày.Khi nào transaction thực sự "xong"? — Eventual consistency đẹp trên giấy. Trong Fintech, bạn phải biết chính xác moment nào tiền "an toàn".Ai có thể xem dữ liệu này? — Authorization không chỉ là middleware. Đó là kiến trúc, là audit log, là compliance.Cái tôi tưởng là thừa, hoá ra là thiếu5 năm làm full-stack, tôi quen move fast. Nhưng Fintech dạy tôi một bài học kỳ lạ: đôi khi đi chậm mới là tạo ra value thật.Có lần tôi propose một feature tưởng là "quick win" — cho phép user xem lịch sử giao dịch real-time. Tôi tự tin lắm: websocket, 2 ngày là xong.Nhưng senior trong team hỏi: Audit log ở đâu? Nếu user dispute giao dịch, mình chứng minh bằng gì? Hệ thống fraud detection có nhận được event này không?Tôi ngồi im. Hai ngày của tôi hóa thành hai tuần — và feature đó tốt hơn rất nhiều."Làm nhiều hơn task" không phải là code thêm tính năng. Đó là hiểu tại sao task đó tồn tại — rồi làm cho mục đích đó được phục vụ thật sự.Khi dev học nói chuyện với người không biết codeMột trong những thay đổi lớn nhất không liên quan đến keyboard. Đó là học cách giải thích.Trong Fintech, quyết định kỹ thuật ảnh hưởng đến compliance, đến risk, đến tiền thật. Bạn không thể chỉ nói "tôi dùng optimistic locking để handle concurrent write" rồi kết thúc. Bạn phải nói được: "Nếu không có cơ chế này, hai người có thể rút cùng một số tiền lúc 3 giờ sáng và cả hai đều thành công."Kỹ năng dịch technical sang business impact — không ai dạy trong trường. Tôi học được từ những buổi họp awkward, từ những lần bị hỏi ngược mà không trả lời được.Công thức tôi đang tập dùng: [Quyết định kỹ thuật] giúp/ngăn chặn [điều gì xảy ra với người dùng], điều mà nếu không có sẽ gây ra [hậu quả cụ thể].Dấu ấn không nằm ở số dòng codeLần đầu tiên tôi cảm thấy mình thật sự tạo ra giá trị — không phải khi ship một feature phức tạp. Mà là lúc tôi ngồi cùng đội fraud analyst, lắng nghe họ mô tả workflow thủ công làm mỗi buổi sáng, rồi nói: "Mình có thể tự động hoá bước này."Feature đó chỉ tốn 3 ngày code. Nhưng để biết cần làm gì, tôi mất 2 tuần ngồi hiểu bài toán. Đó là thứ 5 năm trước tôi sẽ không làm — vì "đó không phải task của tôi".Fintech không cần thêm người viết code. Fintech cần người hiểu rằng code là phương tiện, không phải đích đến.Hành trình từ "dev hoàn thành task" đến "người tạo ra dấu ấn" bắt đầu bằng một câu hỏi rất đơn giản: Tại sao cái này quan trọng?Khi bạn có câu trả lời cho câu hỏi đó — mọi dòng code bạn viết ra đều có trọng lượng hơn.