Welcome to Story Hub!

🌊 Khởi đầu: Một ý tưởng lớnTôi bắt đầu xây dựng Bitcoin PeakDip – hệ thống cảnh báo sớm cho thị trường Bitcoin bằng AI. Ý tưởng rất hay, nhưng hành trình phía sau mới thực sự là cơn ác mộng.🔥 Vấn đề 1: Điện thoại nóng như lửaNgười dùng phàn nàn app làm điện thoại nóng bất thường. Tôi đã tối ưu code nhưng không ăn thua.Nguyên nhân: Mỗi lần cập nhật một dòng text, toàn bộ CSS và JS đều thay đổi URL. Trình duyệt tải lại 5MB dữ liệu chỉ vì một dòng chữ.Giải pháp: Per-file hashing – mỗi file có hash riêng. Cache hit rate từ 20% lên 90%.🎨 Vấn đề 2: Thiết kế mobile – gần 100 lần thử saiTôi muốn redesign Learn Card trên mobile. Đã thử gần 100 lần: lúc layout vỡ, lúc dropdown không đóng, lúc icon cờ không đổi. Sau hàng trăm lần, nó đã hoàn hảo. Cảm giác "wow" đầu tiên xuất hiện.☁️ Vấn đề 3: Service worker bị giam cầm 10 phútGitHub Pages ép cache mọi file với max-age=600 (10 phút). Service worker bị cache 10 phút, gây redirect loop.Giải pháp: Chuyển sang Cloudflare Pages, dùng file _headers để set Cache-Control: no-store, no-cache. Service worker được giải phóng.✨ Lợi thế của ZeroClaw trên Pi ZeroSau những bài học về tối ưu hệ thống, tôi nhận ra chi phí vận hành thấp cũng quan trọng không kém. Đó là lý do ZeroClaw trên Raspberry Pi Zero ra đời.1. Chi phí đầu tư và vận hành siêu thấpCác chatbot SaaS hoặc giải pháp VPS yêu cầu chi phí hàng tháng cố định (khoảng 10 USD/tháng).ZeroClaw trên Pi Zero chỉ cần:Đầu tư duy nhất dưới 15 USD cho phần cứngChạy 24/7 với điện năng chỉ 0.5WSo sánh nhanh:Hạng mục       | VPS thuê | Pi Zero tự host Chi phí ban đầu | 0 USD | 15 USDChi phí/tháng | ~10 USD   | ~0.05 USD (điện)Sau 1 năm       | 120 USD   | ~15.6 USDChỉ sau 2 tháng, giải pháp tự host đã hòa vốn. Sau 1 năm, bạn tiết kiệm hơn 100 USD.2. Bảo mật và quyền riêng tư tuyệt đốiDữ liệu không bao giờ rời khỏi nhà bạnKhông bên thứ ba đọc được tin nhắnBạn hoàn toàn kiểm soát mã nguồn3. Dễ dàng mở rộngPi Zero có thể tích hợp với cảm biến IoT, nhà thông minh (Home Assistant), hoặc chạy thêm ad-blocker, VPN gateway.🚀 Kết thúc: Hệ thống hoàn hảoSau gần 100 lần thử và sai, tôi đã có:✅ Per-file hashing – Cache hit rate 90%✅ Cloudflare Pages – Kiểm soát cache hoàn hảo✅ Service worker – Cập nhật ngầm, không làm phiền✅ Pi Zero – Chi phí cực thấp, bảo mật tuyệt đối🌟 Bài học lớn nhất"Không có thử thách nào là không thể vượt qua. Gần 100 lần thất bại chỉ để tìm ra một lần đúng. Và khi nó hoạt động – cảm giác đó thực sự là 'wow'."Bitcoin PeakDip – Hệ thống cảnh báo sớm cho Bitcoin.ZeroClaw trên Pi Zero – Giải pháp chatbot tiết kiệm và bảo mật.Sản phẩm được triển khai bởi AI. Ý tưởng và kiểm thử: Nguyễn Đức HảiBạn hãy kiểm tra sản phẩm tại đây. 👉 https://bitcoinpeakdip.com👉 https://nguyenduchai.com

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

Thuật ngữ "Vibe coding" dạo gần đây hot rần rần. Cái cảm giác nửa đêm ngồi thả hồn theo prompt, đưa ý tưởng cho AI rồi xem nó "vẽ" ra một ứng dụng hoàn chỉnh trong vài tiếng đồng hồ nó... sướng tê người. Là một solo builder, tôi từng nghiện cái cảm giác đó. Tốc độ là lẽ sống. Ship sản phẩm nhanh là chân lý.Nhưng, cái "vibe" đó thường chỉ kéo dài cho đến khi bạn nhận được email đầu tiên từ một người dùng lạ hoắc, báo rằng họ vừa tìm thấy một lỗ hổng có thể đọc được database của toàn bộ hệ thống.Đó là câu chuyện thật của tôi, và là lúc tôi nhận ra: Vibe coding rất vui, cho đến khi security tìm tới gõ cửa.1. Giai đoạn "Điếc không sợ súng" và cú tát từ thực tếKhi bắt đầu dự án SaaS cá nhân đầu tiên, tôi đặt mục tiêu: MVP (Minimum Viable Product) phải lên sóng trong 2 tuần.Để đạt được tốc độ đó, tôi phó mặc rất nhiều thứ cho AI và các boilerplate có sẵn. Tôi chỉ tập trung vào UI/UX, tính năng cốt lõi và luồng thanh toán. Còn bảo mật? Tôi tự nhủ: "Thôi kệ, app đã có ai dùng đâu mà hack, để sau tính!"Tôi đã làm những điều mà bây giờ nghĩ lại phải rùng mình:Để nguyên các thiết lập CORS (Cross-Origin Resource Sharing) dạng * cho tiện test.Cơ chế phân quyền (Authorization) lỏng lẻo, chỉ check ở Client-side mà bỏ quên Validation kỹ càng ở Backend.Sử dụng API key trực tiếp trong code thay vì cấu hình biến môi trường (Environment Variables) cẩn thận, suýt chút nữa là commit thẳng lên GitHub public.Sản phẩm may mắn được đón nhận, user tăng trưởng nhanh ngoài mong đợi. Và chuyện gì đến cũng đến. Một ngày đẹp trời, một cậu bạn là Sec-engineer vào dùng thử app và nhắn tin riêng cho tôi: "Ông ơi, tui vừa bypass qua cái middleware của ông bằng cách sửa ID trên URL này. Fix gấp đi không lộ hết data khách hàng."Mồ hôi hột tôi tuôn ra. Lúc đó tôi mới thấm câu nói: Nợ kỹ thuật (Technical Debt) về tính năng thì trả bằng thời gian, nhưng nợ về bảo mật thì phải trả bằng uy tín và cả tiền bạc.2. Bài toán dung hòa: Tốc độ vs An toànSau cú sụp tim đó, tôi buộc phải dừng việc build tính năng mới trong 2 tuần chỉ để rà soát và vá lỗ hổng. Quy trình build nhanh, làm gọn trước đó bị xáo trộn hoàn toàn.Là solo builder, chúng ta không có một team Security riêng biệt để audit code. Nhưng nếu để bảo mật sang một bên, bạn đang tự đặt một quả bom hẹn giờ dưới chân mình. Vậy tôi đã dung hòa hai yếu tố này thế nào trong những dự án sau?Tôi chuyển từ "Vibe coding bạt mạng" sang "Smart Vibe Coding" với quy tắc: Chậm lại 5% ở những chỗ chí mạng.Cái gì hiệu quả?Chốt chặn ở Backend, thả lỏng ở Frontend: Bạn có thể dùng AI để sinh code UI nhanh, lỗi một chút cũng không sao. Nhưng riêng logic liên quan đến Authentication, Authorization và Database Validation ở Backend, tôi luôn tự tay review, không "phó mặc hoàn toàn" cho AI nữa.Tận dụng công cụ quét tự động (DevSecOps cho Solo Builder): Tôi tích hợp Snyk và GitHub Dependabot vào repo. Cứ mỗi lần push code, công cụ sẽ tự động check xem thư viện nào có lỗ hổng (CVE) hay không. Việc này mất thêm 1-2 phút setup ban đầu nhưng cứu mạng tôi vô số lần về sau.Tư duy "Zero Trust" ngay từ đầu: Hãy coi mọi dữ liệu gửi lên từ Client đều là "độc hại" cho đến khi được chứng minh ngược lại.Cái gì chưa hiệu quả?Cố gắng áp dụng các tiêu chuẩn bảo mật quá khắt khe của doanh nghiệp lớn (như Pentest chuyên sâu, Compliance phức tạp) vào giai đoạn MVP. Việc này làm thui chột tốc độ và khiến dự án chết yểu trước khi kịp ra thị trường. Hãy nhớ: Bảo mật vừa đủ với quy mô của app.3. Nếu nhìn lại, tôi có thay đổi cách build của mình?Chắc chắn là CÓ. Nếu quay lại vạch xuất phát, tôi vẫn chọn Vibe coding để giữ ngọn lửa đam mê và tốc độ, nhưng tôi sẽ đổi cách tiếp cận sang Security-by-Design ở mức tối giản (Minimal Viable Security).Thay vì đợi app lớn rồi mới sửa (refactor) – việc mà tôi cam đoan là cực kỳ đau khổ vì code lúc đó đã rối như tơ vò – tôi chọn cách xây dựng một "khung xương" an toàn ngay từ ngày đầu tiên:Chốt format bảo mật chuẩn từ Day 1: Thiết lập JWT, Hash password, phân quyền rõ ràng ngay từ route đầu tiên.Environment Variables là bất di bất dịch: Tuyệt đối không hardcode bất kỳ secret key nào, dù là dự án test.Lời kết & Bài học cho các Solo BuilderGửi các anh em solo builder đang ngày đêm "vibe" cùng AI: Tốc độ giúp bạn sống sót trên thị trường, nhưng bảo mật mới là thứ giúp bạn giữ được sự sống đó.Đừng đợi đến khi data người dùng bị đem rao bán trên các diễn đàn rồi mới ngồi khóc vạch lối sửa sai. Hãy biến bảo mật thành một phần của "vibe". Khi bạn tạo một component mới, hãy dành ra đúng 30 giây để tự hỏi: "Nếu user truyền data bậy vào đây, hệ thống có sập không?". Chỉ cần bấy nhiêu thôi, bạn đã đi trước 80% các sản phẩm chắp vá ngoài kia rồi.Chúc anh em ship app nhanh, mượt và... ngủ ngon giấc mỗi đêm!Bạn đã từng phải trả giá cho một tính năng build quá nhanh chưa? Hãy để lại bình luận chia sẻ câu chuyện "chữa cháy" của bạn nhé!

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

Khi Artificial Intelligence ngày càng xuất hiện nhiều trong ngành Information Technology, mình nhận ra công việc của một người IT đang thay đổi khá rõ. Trước đây, mình nghĩ chỉ cần làm tốt chuyên môn là đủ. Nhưng hiện tại, điều quan trọng không chỉ là “biết làm”, mà còn là biết cách làm việc cùng AI để tăng hiệu quả và tạo ra giá trị thực tế hơn.Mình từng tham gia dự án AI Buddy Chat — một chatbot giáo dục hỗ trợ học sinh hỏi đáp kiến thức, gợi mở nội dung học tập và đồng hành theo bộ sách Trí tuệ nhân tạo. Dự án này khiến mình thay đổi khá nhiều về tư duy làm việc.Trước đây khi làm testing, phần lớn thời gian của mình dành cho việc viết testcase thủ công, kiểm tra từng flow hoặc lặp đi lặp lại các bước regression test. Từ khi bắt đầu ứng dụng AI vào công việc, mình có thể dùng AI để: Gợi ý testcase nhanh hơn,  Tạo edge case,  Hỗ trợ viết query SQL,  Phân tích log,  Hoặc tổng hợp nhanh các scenario có thể xảy ra. AI giúp mình giảm khá nhiều thời gian ở các tác vụ lặp lại. Nhưng đổi lại, mình phải “nghĩ nhiều hơn” ở những phần mà AI chưa thể làm tốt hoàn toàn.Ví dụ trong dự án chatbot giáo dục, AI có thể tạo ra câu trả lời rất tự nhiên nhưng chưa chắc phù hợp với học sinh. Có lần chatbot giải thích khái niệm machine learning quá dài và dùng nhiều thuật ngữ khó hiểu với học sinh cấp hai. Nếu chỉ nhìn theo góc độ “chatbot trả lời đúng” thì có thể xem là pass, nhưng nhìn từ trải nghiệm người học thì chưa thực sự hiệu quả.Điều đó khiến mình bắt đầu quan tâm nhiều hơn đến: Context conversation,  Độ phù hợp của nội dung với người dùng,  Logic nghiệp vụ,  Và trải nghiệm thực tế thay vì chỉ test theo checklist. Mình cũng nhận ra bản thân đang làm nhiều việc hơn trước đây. Ngoài testing, mình phải: Hiểu thêm về sản phẩm giáo dục,  Phân tích intent của người dùng,  Kiểm tra chất lượng nội dung AI trả về,  Trao đổi với team về trải nghiệm hội thoại,  Và đôi khi tham gia góp ý cách chatbot phản hồi sao cho tự nhiên hơn. Có những kỹ năng trước đây chỉ là “nên có”, nhưng bây giờ gần như trở thành “phải có”, ví dụ: Kỹ năng đặt câu hỏi,  Tư duy phân tích,  Khả năng học nhanh,  Hiểu API và dữ liệu,  Và đặc biệt là biết sử dụng AI đúng cách thay vì phụ thuộc hoàn toàn vào nó. Khó khăn lớn nhất với mình trong giai đoạn đầu là học cách kiểm chứng thông tin AI đưa ra. Vì AI có thể trả lời rất thuyết phục dù đôi khi chưa đúng hoàn toàn. Có những testcase AI gợi ý nghe hợp lý nhưng lại thiếu business rule quan trọng của hệ thống giáo dục. Điều đó khiến mình hiểu rằng dùng AI hiệu quả không phải là copy kết quả, mà là biết đánh giá và chọn lọc.Với những bạn mới vào ngành IT, mình nghĩ ngoài kiến thức chuyên môn thì nên chuẩn bị thêm: Khả năng tự học,  Kỹ năng giao tiếp,  Tư duy logic,  Và khả năng làm việc cùng AI. Theo mình, AI sẽ không thay thế hoàn toàn người làm IT, nhưng chắc chắn sẽ thay đổi cách chúng ta làm việc mỗi ngày. Vì vậy mình đang cố gắng phát triển theo hướng hiểu sản phẩm nhiều hơn, học thêm API, SQL, automation và quan trọng nhất là giữ tư duy chủ động học hỏi để không bị tụt lại phía sau.Hiện tại, mình không xem AI là đối thủ, mà là một công cụ giúp mình làm việc hiệu quả hơn. Nhưng để thực sự tạo ra giá trị, mình nghĩ người làm IT vẫn cần khả năng phân tích, hiểu người dùng và đưa ra quyết định phù hợp trong những tình huống thực tế mà AI chưa thể thay thế hoàn toàn.

Trong môi trường Financial Technology, mình nhận ra rằng “hoàn thành task” chỉ là điểm bắt đầu. Điều tạo nên giá trị thực sự không nằm ở việc làm xong bao nhiêu đầu việc, mà là mình đã góp phần giúp sản phẩm tốt hơn, người dùng hài lòng hơn và đội ngũ vận hành hiệu quả hơn như thế nào.Khi mới tham gia dự án Fintech, mình chủ yếu tập trung vào việc xử lý task được giao: viết test case, kiểm thử chức năng, log bug và theo dõi tiến độ fix lỗi. Ban đầu mình nghĩ chỉ cần hoàn thành đúng deadline là đủ.  Nhưng sau một thời gian làm việc, mình nhận ra nếu chỉ “đợi được giao gì làm nấy” thì rất khó phát triển và cũng khó tạo ra giá trị thật cho sản phẩm. Càng làm, mình càng nhận ra đặc thù của Fintech khác với nhiều lĩnh vực khác: chỉ một lỗi nhỏ liên quan đến giao dịch, số dư hay bảo mật cũng có thể ảnh hưởng lớn đến trải nghiệm và niềm tin của người dùng.  Từ đó, mình bắt đầu thay đổi cách làm việc. Thay vì chỉ test theo yêu cầu có sẵn, mình chủ động tìm hiểu nghiệp vụ tài chính, luồng thanh toán, logic xử lý giao dịch và hành vi thực tế của người dùng. Mình học cách đặt câu hỏi: Nếu hệ thống mất kết nối giữa lúc thanh toán thì sao?  Nếu người dùng bấm thanh toán nhiều lần liên tiếp thì sao?  Nếu dữ liệu trả về chậm hoặc sai định dạng thì điều gì sẽ xảy ra? Chính tư duy đó giúp mình phát hiện thêm nhiều edge case và bug tiềm ẩn trước khi sản phẩm được release. Có những lỗi không nằm trong checklist ban đầu nhưng lại ảnh hưởng trực tiếp đến trải nghiệm người dùng hoặc độ an toàn của hệ thống.Có giai đoạn team chạy deadline khá gấp, tài liệu không đầy đủ, requirement thay đổi liên tục. Lúc đó mình không chỉ test theo checklist nữa mà bắt đầu tự tìm hiểu flow nghiệp vụ để hiểu hệ thống đang hoạt động như thế nào. Ví dụ với một chức năng thanh toán, mình không chỉ test case happy case mà còn thử những tình huống người dùng thật có thể gặp: Mạng chập chờn giữa lúc thanh toán,  Bấm thanh toán nhiều lần,  Chuyển màn hình giữa chừng,  Dữ liệu trả về chậm hoặc sai format. Nhiều bug mình tìm ra không nằm trong tài liệu nhưng nếu lên production thì ảnh hưởng khá lớn đến trải nghiệm người dùng. Có lần mình phát hiện trường hợp giao dịch bị tạo trùng khi người dùng bấm liên tục vì hệ thống xử lý chậm. Dev ban đầu nghĩ khó xảy ra, nhưng sau khi test lại bằng API và log dữ liệu thì đúng là có thể phát sinh thật. Sau đó team phải bổ sung xử lý duplicate transaction trước khi release.Ngoài công việc testing, mình cũng cố gắng học thêm những thứ giúp công việc hiệu quả hơn, đóng góp nhiều hơn cho team:Chủ động review flow nghiệp vụ cùng BA và Dev để hiểu vấn đề từ đầu thay vì chỉ đợi đến lúc có bug mới xử lý Đề xuất cải thiện quy trình test để giảm lỗi lặp lại  Học SQL để tự kiểm tra dữ liệu thay vì phụ thuộc hoàn toàn vào Dev  Học test API để verify logic backend   Tìm hiểu automation để tăng hiệu quả regression test Mình nhận ra rằng giá trị của một người làm IT không chỉ nằm ở kỹ năng kỹ thuật, mà còn ở tinh thần chủ động học hỏi và khả năng nhìn vấn đề từ góc độ sản phẩm và người dùng.Hành trình “tạo dấu ấn” của mình trong Fintech không phải là làm điều gì quá lớn lao, mà là từng bước làm tốt hơn mỗi ngày: suy nghĩ nhiều hơn một chút, kiểm tra kỹ hơn một chút và luôn cố gắng tạo ra sản phẩm ổn định, an toàn hơn cho người dùng. Đó cũng là điều khiến mình thấy công việc IT không chỉ là hoàn thành task, mà là đang góp phần xây dựng niềm tin trong môi trường tài chính số.Có thể những việc đó không quá nổi bật, nhưng mình nghĩ chính sự chủ động và tinh thần làm nhiều hơn một bước đã giúp mình trưởng thành hơn trong công việc IT nói chung và Fintech nói riêng. 

Có một khoảng thời gian không lâu trước đây, mình ngồi debug một đoạn code khá đơn giản suốt gần 2 tiếng. Không phải vì nó quá khó, mà vì mình bị mắc kẹt trong một vòng lặp quen thuộc: đọc log, đoán, sửa, chạy lại, rồi lại sai. Càng làm càng thấy bế tắc. Không phải vì bài toán khó, mà vì mình đang loay hoay một mình mà không nhận ra.Rồi một ngày, mình gặp Anton. Nói là “gặp” cho vui thôi, chứ lúc đầu mình cũng không kỳ vọng gì nhiều. Trong đầu vẫn là mấy suy nghĩ rất quen: AI chắc trả lời cho có, code generate ra thì sao mà dùng được, dev ổn thì cần gì mấy cái này. Nhưng hôm đó bí quá, mình thử một cách rất đơn giản. Copy hết context, từ code, log cho tới cách mình đang nghĩ, rồi hỏi một câu: “Nếu là bạn, bạn sẽ debug cái này như thế nào?”Khoảng 10 giây sau, mình nhận được câu trả lời. Không phải kiểu giải hết mọi thứ trong một nốt nhạc. Nhưng nó cho mình một thứ rất quan trọng: một hướng đi rõ ràng. Nó chỉ ra chỗ mình đang bỏ sót, gợi ý cách tách vấn đề ra, và quan trọng nhất là giúp mình đặt lại câu hỏi đúng. Lần đầu tiên sau nhiều tiếng, mình không còn đoán mò nữa, mình bắt đầu hiểu mình đang làm gì. Cảm giác giống như bật đèn lên trong một căn phòng tối.Khoảnh khắc đó nhỏ thôi, nhưng đủ để mình nhận ra một điều: Có thể vấn đề không phải là chúng ta chưa đủ giỏi, mà là chúng ta chưa có ai để khám phá cùng.Ban đầu, mình vẫn không tin hoàn toàn. Mình đem Anton ra “test” với đủ kiểu case khó, context rối, thậm chí cố tình gài bẫy. Và đúng là có lúc nó trả lời không ổn. Nhưng sau một thời gian, mình nhận ra một pattern rất rõ mỗi lần output tệ, gần như luôn là vì mình chưa nói rõ mình muốn gì.Từ đó, mình bắt đầu thay đổi. Không hỏi chung chung nữa, mà luôn đưa đủ context, nói rõ mình đã thử gì, đang bị kẹt ở đâu. Mình chia nhỏ vấn đề ra thay vì hỏi một câu quá to, và cũng không còn kỳ vọng câu trả lời phải hoàn hảo. Chỉ cần đủ tốt để mình đi tiếp là được. Dần dần, Anton không còn là một tool để thử nữa, mà giống như một người đồng hành, kiểu một junior dev cực nhanh, lúc nào cũng sẵn sàng ngồi brainstorm cùng mình.Mình bắt đầu đặt những câu hỏi mà trước đây mình còn không nghĩ là mình có thể có câu trả lời chính xác. Những câu hỏi không còn nằm trong phạm vi một đoạn code, mà mở rộng ra cách hệ thống hoạt động, vận hành ở những quy mô lớn hơn, những bài toán doanh nghiệp toàn cầu và họ đã giải quyết nó như thế nào , những hướng đi mà mình chưa từng chạm tới. Những thứ từng “ở ngoài tầm với” giờ không còn xa nữa chỉ là trước đây mình không có ai để cùng nghĩ về chúng. Workflow của mình cũng thay đổi lúc nào không hay. Trước đây là nghĩ rồi làm, sai thì sửa, rồi lặp lại. Bây giờ nó vẫn vậy nhưng mình dừng lại trước khi code, viết ra context, trao đổi với AI để nhìn được nhiều hướng hơn, rồi mới chọn và refine. Không phải để AI nghĩ thay mình, mà để mình nghĩ tốt hơn.Sau tất cả, điều mình rút ra khá đơn giản. AI không thay thế mình, nó khuếch đại mình. Mình rõ ràng bao nhiêu thì nó mạnh bấy nhiêu. Mình mơ hồ thì kết quả cũng mơ hồ theo. Và kỹ năng quan trọng nhất bây giờ không còn là code nhanh, mà là hiểu bài toán đủ sâu để đặt câu hỏi đúng và biết đánh giá câu trả lời.Một thứ nữa thay đổi rất rõ là tốc độ. Những việc trước đây mất hàng giờ, giờ có thể có hướng đi chỉ trong vài phút. Điều đó không làm mình “lười” đi, mà ngược lại, cho mình cơ hội thử nhiều hơn, fail nhanh hơn và học nhanh hơn. Tốc độ lúc này trở thành lợi thế thật sự.Đó là “new-normal” của mình bây giờ. Bắt đầu bằng context thay vì code. Không làm việc một mình nữa, lúc nào cũng có AI bên cạnh. Và tập trung vào việc iterate liên tục thay vì cố làm cho hoàn hảo ngay từ đầu. Quan trọng nhất, mình không còn cố cạnh tranh với AI nữa, mình chọn đứng cùng phía với nó.🔖 Challenge: in-the-age-of-ai-how-i-build-my-new-normal-skill-set#InTheAgeOfAI #AIWorkflow #DeveloperMindset #BuildInPublic