AI

Khi nhắc đến ngành IT, nhiều người thường nghĩ ngay đến code.Biết nhiều ngôn ngữ lập trình, xử lý được những bài toán khó, viết ra những đoạn code tối ưu — đó chắc chắn là một lợi thế rất lớn.Bản thân tôi cũng từng nghĩ rằng: muốn phát triển trong ngành IT thì điều quan trọng nhất là phải thật giỏi kỹ thuật.Nhưng khi làm QA/Tester, góc nhìn của tôi dần thay đổi.Tôi không phải người viết code nhiều nhất trong team, nhưng để kiểm thử một sản phẩm tốt, tôi nhận ra mình vẫn cần hiểu những gì đang diễn ra phía sau dòng code.Một lỗi có thể không nằm ở giao diện.Nó có thể xuất phát từ logic xử lý, dữ liệu, API hoặc cách các thành phần trong hệ thống kết nối với nhau.Vì vậy, tôi bắt đầu học thêm các kiến thức kỹ thuật như API, SQL và cách hệ thống vận hành.Không phải để trở thành Developer, mà để có thể trao đổi tốt hơn với Developer, hiểu vấn đề sâu hơn và tìm ra nguyên nhân thay vì chỉ nhìn thấy kết quả.Tôi nhận ra một người IT giỏi không chỉ được đánh giá bằng số dòng code viết ra.Một đoạn code tốt cần đi cùng với khả năng hiểu yêu cầu.Một tính năng tốt cần đi cùng với trải nghiệm người dùng.Một sản phẩm tốt cần đi cùng với tư duy giải quyết vấn đề.Đặc biệt khi AI ngày càng phát triển, tôi nghĩ vai trò của kỹ năng kỹ thuật cũng đang thay đổi.AI có thể hỗ trợ viết code nhanh hơn, gợi ý cách xử lý hoặc giúp tự động hóa nhiều công việc.Nhưng AI vẫn cần con người xác định:Bài toán thật sự là gì?Giải pháp nào phù hợp?Kết quả tạo ra có đúng với mục tiêu không?Trong công việc QA, tôi thấy điều này rất rõ.Một công cụ có thể giúp tạo test case nhanh hơn, nhưng việc hiểu sản phẩm, dự đoán rủi ro và đặt đúng câu hỏi vẫn cần tư duy của con người.Tôi cũng nhận ra những kỹ năng tưởng như không liên quan đến code lại ảnh hưởng rất nhiều đến sự phát triển:Khả năng giao tiếp để trao đổi vấn đề.Khả năng học hỏi để thích nghi với công nghệ mới.Khả năng nhìn sản phẩm dưới góc độ người dùng.Theo tôi, code giỏi là một nền tảng quan trọng.Nhưng để thăng tiến trong IT, bạn cần nhiều hơn thế.Bạn cần biết cách biến kiến thức kỹ thuật thành giá trị thực tế.Vì cuối cùng, một người được đánh giá không chỉ bởi việc họ viết được bao nhiêu code, mà bởi họ giúp sản phẩm và đội nhóm tiến lên như thế nào.

Chào mọi người, mình là Richard, Hiện tại mình là Lead của một Builder Lab tại Unikorn.vn . Chúng mình là một Research labs tập trung vào nghiên cứu và phát triển các mô hình Agentic hiện hành và ứng dụng của nó vào thực tế. Trong quá trình làm việc với các builder, founder và developer, mình thường xuyên bắt gặp một cuộc tranh luận quen thuộc: Tốc độ hay bảo mật quan trọng hơn? Đây là một câu hỏi mà mình tin rằng không chỉ các builder, mà bất kỳ ai đang trong quá trình xây dựng sản phẩm, startup hay thậm chí là thương hiệu cá nhân trong kỷ nguyên AI đều từng đặt ra ít nhất một lần. Chúng ta đang sống trong thời đại mà một cá nhân có thể làm được khối lượng công việc từng cần đến cả một đội ngũ. AI giúp việc nghiên cứu nhanh hơn, phát triển nhanh hơn, thử nghiệm nhanh hơn và đưa sản phẩm ra thị trường nhanh hơn bao giờ hết. Nhưng chính vì tốc độ đó, một câu hỏi mới bắt đầu xuất hiện: Liệu chúng ta có đang đi quá nhanh so với khả năng kiểm soát những gì mình tạo ra? Khi sản phẩm bắt đầu có người dùng, khi dữ liệu bắt đầu được lưu trữ, khi những quyết định của chúng ta ảnh hưởng trực tiếp đến trải nghiệm của khách hàng, thì tốc độ không còn là yếu tố duy nhất cần được quan tâm. Đó là lý do vì sao cuộc tranh luận giữa tốc độ và bảo mật ngày càng trở nên phổ biến trong cộng đồng builder. Tuy nhiên, sau nhiều năm xây dựng sản phẩm, từ những dự án thất bại cho đến những sản phẩm thực sự được người dùng đón nhận, mình nhận ra đây có lẽ đây chưa phải là câu hỏi đúng mà là một insight đang hình thành. Với chúng mình, vấn đề không nằm ở việc chọn bên nào. Mà là hiểu rõ sản phẩm của mình đang ở giai đoạn nào. Bởi mỗi giai đoạn của một sản phẩm đều có những bài toán khác nhau cần giải quyết. Chúng mình không chọn giữa tốc độ và bảo mật, chúng mình chọn thời điểm thích hợp. Qua bài viết này chúng mình chia sẻ về góc nhìn hiện tại của team đối với quá trình xây dựng sản phẩm và vận hành trong kỉ nguyên AI. Build Fast, Harden Later Tìm kiếm cơ hội và xác thực giá trị. Khi mới bắt đầu xây dựng một sản phẩm, thứ chúng ta đang thiếu không phải là bảo mật, khả năng mở rộng hay một kiến trúc hoàn hảo. Thứ chúng ta thiếu là sự xác thực từ thị trường. Chúng ta chưa biết liệu vấn đề mình đang giải quyết có thực sự tồn tại hay không hay liệu giải pháp của mình có đủ hấp dẫn để người dùng thay đổi thói quen hiện tại. Rủi ro lớn nhất là dành hàng tháng, thậm chí hàng năm để xây dựng một thứ mà không ai thực sự cần. Mỗi sản phẩm đều bắt đầu bằng những giả định. Chúng ta giả định rằng khách hàng đang gặp một vấn đề. Chúng ta giả định rằng giải pháp của mình là phù hợp. Chúng ta giả định rằng người dùng sẵn sàng thay đổi thói quen để sử dụng sản phẩm mới. Nhưng suy cho cùng, tất cả vẫn chỉ là giả định cho đến khi được thị trường xác nhận. Đó là lý do mình luôn xem tốc độ là một lợi thế chiến lược ở giai đoạn đầu. Không phải tốc độ để viết nhiều code hơn. Không phải tốc độ để ra mắt nhiều tính năng hơn. Mà là tốc độ để học nhanh hơn. Một tính năng được hoàn thành sớm hơn có thể mang lại một phản hồi giá trị sớm hơn. Một ý tưởng được đưa ra thị trường sớm hơn có thể giúp chúng ta phát hiện sai lầm sớm hơn. Một tuần tiết kiệm được trong quá trình phát triển có thể giúp tránh lãng phí nhiều tháng đi sai hướng. Trong kỷ nguyên AI, bất kỳ ai cũng có thể tạo ra sản phẩm nhanh hơn trước đây rất nhiều. Nhưng điều thú vị là công nghệ không làm thay đổi bài toán cốt lõi. Nó chỉ rút ngắn khoảng thời gian từ "Tôi nghĩ đây là một ý tưởng hay" đến "Thị trường xác nhận liệu nó có thực sự là một ý tưởng hay hay không." Và theo mình, đó mới là giá trị lớn nhất của vibe coding. Bởi một builder không phải là người xây được nhiều thứ nhất. Mà là người dùng công cụ hiệu quả để tìm ra đúng thứ tạo ra giá trị thực sự. Nhưng đó chỉ mới là giai đoạn đầu hãy cùng chúng mình tiếp tục trong cuộc hành trình này nhé :> Earn Trust, Protect It khi đã có người dùng, hãy bảo vệ niềm tin mà bạn đã tạo dựng. Nếu tốc độ giúp chúng ta tìm thấy cơ hội, thu hút những người dùng đầu tiên và chứng minh rằng sản phẩm thực sự tạo ra giá trị, thì điều gì sẽ quyết định liệu cơ hội đó có trở thành tăng trưởng bền vững hay chỉ là một khoảnh khắc ngắn ngủi ? Liệu chúng ta đã sẵn sàng để gánh vác niềm tin mà người dùng trao cho mình hay chưa ? Đằng sau mỗi tài khoản là một con người và mỗi dữ liệu được lưu trữ là một sự tin tưởng. Mỗi lần họ quay lại sử dụng sản phẩm là một sự kỳ vọng rằng những gì chúng ta xây dựng sẽ luôn ở đó khi họ cần. Càng nhiều dữ liệu, càng nhiều trách nhiệm. Những quyết định kỹ thuật từng có thể tạm chấp nhận ở giai đoạn MVP bắt đầu bộc lộ giới hạn của chúng. Và đó là lúc mình bắt đầu nhìn nhận bảo mật theo một cách khác. Không phải như một checklist kỹ thuật. Mà như một lời cam kết của người xây dựng với những người đã lựa chọn tin tưởng sản phẩm của mình. Nó không tạo ra những con số tăng trưởng ấn tượng. Nhưng nó là thứ âm thầm bảo vệ tất cả những gì bạn đã mất rất nhiều thời gian để xây dựng. Và khi sản phẩm bước vào giai đoạn phát triển, bảo vệ niềm tin đó trở thành một trong những trách nhiệm quan trọng nhất của một builder. Đây là lúc nâng cấp bảo mật, tập trung vào các tính năng bảo vệ hệ thống, tránh rò rỉ dữ liệu và đảm bảo tuân thủ các quy định về bảo mật thông tin. Một câu hỏi mà nhiều người có thể đặt ra là: "Nếu bảo mật quan trọng như vậy, tại sao không đầu tư mạnh ngay từ ngày đầu tiên ? " Theo mình, câu trả lời nằm ở nguồn lực. Đặc biệt đối với các builder, startup hay những đội ngũ nhỏ. Thời gian, nhân lực và ngân sách luôn là hữu hạn. Mỗi giờ dành cho một việc cũng đồng nghĩa với việc không thể dành cho một việc khác. Trong giai đoạn đầu, thứ cần được chứng minh không phải là hệ thống của chúng ta có hoàn hảo hay không. Thứ cần được chứng minh là sản phẩm có thực sự tạo ra giá trị hay không. Bởi nếu không giải quyết được một vấn đề thực sự của người dùng, thì dù kiến trúc có đẹp đến đâu hay bảo mật có tốt đến đâu, sản phẩm vẫn khó có thể tồn tại. Nhưng khi sản phẩm bắt đầu có người dùng, mọi thứ thay đổi. Lúc này chúng ta không còn bảo vệ một ý tưởng. Chúng ta đang bảo vệ dữ liệu, công việc và niềm tin của những con người thực sự. Đây cũng là thời điểm mà chi phí của một sự cố bắt đầu lớn hơn rất nhiều so với chi phí phòng ngừa. Một lỗi nhỏ ở giai đoạn chưa có người dùng thường chỉ ảnh hưởng đến builder. Nhưng cùng lỗi đó ở giai đoạn tăng trưởng có thể ảnh hưởng đến hàng trăm hoặc hàng nghìn người. Đó là lý do vì sao mình cho rằng đây là thời điểm lý tưởng để đầu tư mạnh hơn vào bảo mật. Không phải vì bảo mật đột nhiên trở nên quan trọng. Mà vì lúc này cuối cùng đã có một thứ đủ giá trị để bảo vệ. Kết luận Sau tất cả, mình không nghĩ đây là cuộc tranh luận giữa tốc độ mà vibe coding đem lại và bảo mật. Bởi vì một sản phẩm thành công cần cả hai. Tốc độ giúp chúng ta khám phá cơ hội, nó giúp chúng ta học hỏi nhanh hơn, biến những ý tưởng trên giấy có cơ hội trở thành giá trị thực tế. Nhưng khi cơ hội đó xuất hiện, khi người dùng bắt đầu tin tưởng sản phẩm và khi những giá trị thực sự được tạo ra, bảo mật trở thành một phần không thể thiếu của hành trình. Không phải vì chúng ta sợ rủi ro. Mà vì chúng ta tôn trọng những gì mình đã xây dựng và những người đã đặt niềm tin vào nó. Là một builder, điều quan trọng không phải là chọn giữa tốc độ hay bảo mật. Điều quan trọng là hiểu sản phẩm của mình đang ở đâu trên hành trình phát triển. Biết khi nào cần tăng tốc. Biết khi nào cần củng cố nền móng. Biết khi nào cần theo đuổi cơ hội và biết khi nào cần bảo vệ những cơ hội đó. Đó cũng là cách mà team chúng mình đang tiếp cận việc xây dựng sản phẩm trong kỷ nguyên AI. Không ngừng đổi mới, học hỏi. Nhưng cũng không quên trách nhiệm đi kèm với sự tăng trưởng. Bởi cuối cùng: Tốc độ tạo ra cơ hội. Bảo mật giúp bạn bảo vệ cơ hội đó. Cảm ơn các bạn đã quan tâm <3 

Một buổi sáng, cả team dev chỗ tôi nhận thông báo: công cụ AI đang dùng đổi cách tính tiền. Trước đó mỗi người 300 request/tháng, dùng thả ga. Giờ chuyển sang trả theo token — dùng tới đâu tính tiền tới đó. Công ty tính lại chi phí, nên đã chuyển sang một AI agent khác có cách tính tương tự nhưng được đánh giá tốt hơn.Nghe chỉ là chuyện đổi công cụ. Nhưng suy nghĩ đầu tiên trong đầu của tôi là sao lại tăng giá rồi, nó làm tôi nhớ đến một hình ảnh không mấy dễ chịu: rau hẹ được nuôi rồi cắt cũng như gà được nuôi béo chuẩn bị làm thịt.Giai đoạn vỗ béo: khi mọi thứ rẻ đến mức đáng ngờHãy nhớ lại vài năm qua. Công cụ AI rẻ như cho, hào phóng, gần như miễn phí. Hạn mức rộng rãi, model xịn cho dùng thoải mái. Chúng ta vui vẻ "ăn no": mọi task đều mở agent ra trước, code tay thưa dần, và năng suất tăng đều.Nhưng không hãng nào đốt tiền mãi vì lòng tốt. Giá rẻ giai đoạn đầu là để làm một việc: khiến chúng ta quen, rồi lệ thuộc. Khi cả một quy trình làm việc, cả một thói quen tư duy đã gắn chặt vào công cụ, thì việc gỡ ra tốn kém hơn so với việc cắn răng trả thêm tiền. Đó là lúc con gà đã đủ béo.Giai đoạn làm thịt: hóa đơn bắt đầu nói chuyệnVà rồi giá đổi. Với người dùng agent nhiều, chi phí có thể nhảy lên gấp nhiều lần chỉ sau một thông báo. Không cần ai làm gì sai — đơn giản là giai đoạn trợ giá kết thúc, đến lượt thu hồi vón từ các công ty. Đây là quy luật của mọi làn sóng công nghệ, không riêng gì AI.Câu hỏi đáng sợ không phải "công cụ nào rẻ nhất bây giờ", mà là: nếu mai nó tăng giá gấp ba, hoặc công ty cắt quyền truy cập, mình còn code được không?Vậy giỏi code thôi đã đủ để sống sót trong ngành chưa?Tôi nghĩ là chưa — nhưng có lẽ không theo cách nhiều người tưởng.Trước đây "giỏi" nghĩa là viết được code tốt. Giờ AI viết được phần lớn code tốt đó. Nếu năng lực của bạn chỉ là gõ ra dòng lệnh, thì thứ đó đang rẻ đi từng ngày, và bạn cũng đang bị "vỗ béo" để một ngày dễ bị thay thế — bởi công cụ, hoặc bởi người dùng công cụ giỏi hơn.Những thứ không thể rẻ đi, và cũng không ai cắt giá hay thay thế được của bạn, là những thứ AI chưa làm thay: khả năng đọc hiểu một hệ thống, debug khi mọi thứ cháy, đánh giá một giải pháp đúng hay sai, và biết khi nào không nên tin output của agent. Càng dùng AI nhiều, kỹ năng thẩm định này càng quý, chứ không phải càng thừa.Nên định hướng của tôi gói trong ba điều: giữ vững nền tảng (AI viết hộ, nhưng người chịu trách nhiệm khi nó sai vẫn là bạn); tránh khoá cứng vào một nhà cung cấp (ưu tiên giải pháp cho đổi model, mã nguồn mở); và coi AI là đòn bẩy chứ không phải nạng — đòn bẩy giúp người mạnh đi xa hơn, còn nạng khiến người ta quên cách tự đi.Chuyện đổi công cụ ở công ty tôi rồi cũng xong, team thích nghi được. Nhưng câu hỏi nó để lại thì vẫn còn nguyên. Trong một ngành mà công cụ có thể đổi giá sau một đêm, giỏi code là cần, nhưng chưa đủ. Thứ quyết định bạn còn đứng vững hay không, là khi con gà đã được vỗ béo xong, bạn là người cầm dao — hay là người nằm trên thớt.

🌊 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

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

AI has become an essential partner in my workflow, refining my technical writing and expanding my graphic design capability. However, this efficiency has forced a deeper realization: my content is no longer just for human consumption - it is increasingly being ingested as raw data to feed my readers' AI agents. This transformation has redefined my role. I am moving from being a mere content creator to a 'data architect.' While AI has simplified my tactical tasks, it has introduced a more complex, work: I must now ensure my work is structured, verified, and optimized to serve as a reliable foundation for the intelligent systems of tomorrow.Best,

Context một xíu thì hồi mới đi làm, mình vẫn còn là kiểu thuần developer. Mọi thứ đều làm bằng tay: đọc documentation, lục Stack Overflow, debug từng dòng log. Rồi kiểu có những hôm ngồi debug mà tìm mãi không ra vấn đềThời điểm đó, công ty mình và đồng nghiệp thì không prefer AI, nên AI gần như không tồn tại trong workflow. Viết một feature là một quá trình khá tuyến tính: nghĩ → code → lỗi → sửa → lại lỗi → sửa tiếp. Nếu bí quá thì hỏi đồng nghiệp, không thì… ngồi mò =)))) chứ có khi 2 ngày chưa tìm ra vấn đề Rồi thời điểm anh lead mình bắt đầu khuyến khích dùng thử ChatGPT, ban đầu thì mình tò mò. Mình không kỳ vọng nhiều, chỉ nghĩ dùng để hỏi mấy câu kiểu syntax này viết sao, hoặc lỗi này là gì. Nhưng cái cảm giác khi nó trả lời gần như ngay lập tức, lại còn giải thích khá rõ ràng, làm mình thấy hơi… sai sai. Nó giống như Google, nhưng là Google biết nói chuyện và hiểu mình đang hỏi gì.Dần dần, mình bắt đầu dùng nhiều hơn. Không chỉ hỏi syntax nữa, mà hỏi cách thiết kế API, cách xử lý input, thậm chí hỏi cả về mấy lỗ hổng như XSS khi làm một project web. Lúc đó mình nhận ra một điều mà sau này đọc lại thread trên VOZ thấy nhiều người cũng nói giống: GPT đúng kiểu cái gì cũng làm được. Không hẳn là xuất sắc nhất ở mọi thứ, nhưng đủ tốt ở gần như mọi thứ.Nhưng rồi khi project lớn dần lên, code không còn vài chục dòng nữa mà lên tới vài trăm, vài nghìn dòng, mình bắt đầu thấy GPT hơi đuối trong việc giữ context. Lúc đó mình thử qua Claude, và đúng là có sự khác biệt. Mình quăng cho nó một file dài, nó vẫn đọc được, giải thích lại flow khá mạch lạc, thậm chí refactor lại code cho dễ đọc hơn. Cảm giác giống như có một người review code ngồi cạnh, kiên nhẫn đọc từng dòng và giải thích lại cho mình.Song song đó, mình cũng cài Copilot (sau này chuyển sang dùng Cursor). Và đây có lẽ là thứ thay đổi cách mình code rõ nhất. Trước đây, viết một API CRUD cũng phải gõ từng đoạn, giờ chỉ cần viết comment hoặc vài dòng đầu, phần còn lại gần như được gợi ý sẵn. Có lúc mình chỉ việc “tab tab tab” là xong cả một function. Nó không thông minh kiểu giải thích như GPT hay Claude, nhưng lại cực kỳ hữu dụng trong việc tăng tốc.Trong một dự án web mà mình làm gần đây, có phần demo về XSS, kiểu stored và reflected XSS trong một hệ thống chat đơn giản. Mình nhận ra mình đang dùng AI theo kiểu rất chia việc. Mình dùng ChatGPT để nghĩ kiến trúc, hỏi về các case tấn công, cách thiết kế sao cho vừa có lỗ hổng để demo vừa có thể fix lại. Khi code bắt đầu dài và rối, mình chuyển qua Claude để nhờ nó đọc lại, chỉ ra chỗ nào code smell, chỗ nào nên tách function. Còn trong lúc ngồi viết từng endpoint, từng component, Copilot/Cursor gần như luôn bật để hỗ trợ gõ nhanh.So với trước đây, tốc độ làm việc tăng lên thấy rõ. Những việc trước kia mất vài tiếng, giờ có thể rút xuống còn một nửa, thậm chí hơn. Nhưng đổi lại, mình cũng nhận ra một thứ hơi rủi ro: nếu không cẩn thận, rất dễ tin AI một cách mù quáng. Có những đoạn code nhìn rất hợp lý, chạy cũng không lỗi, nhưng logic bên trong lại sai. Đặc biệt là mấy phần liên quan tới security như XSS, nếu chỉ copy-paste mà không hiểu thì rất dễ dính bẫy.Có 1 vài thông tin mà anh em trong ngành có bàn trên VOZ cũng khá đúng. GPT đúng là lựa chọn an toàn và đa năng nhất, kiểu cái gì cũng làm được ở mức ổn. Claude thì mạnh ở việc đọc và xử lý code dài, viết lại cho sạch. Gemini thì có, nhưng không phải thứ mà dev nghĩ tới đầu tiên khi cần code. Và nếu nói về trải nghiệm làm việc hằng ngày, thì mấy tool như Copilot hay Cursor mới là thứ mình đụng tới nhiều nhất.Nên tóm lại: Với mình khi AI ra đời, việc tiếp thu kiến thức và học là một chuyện khá thú vị, nhưng mình nghĩ mọi người có thể tiếp cận nó theo trình tự Tư duy trước -> Xong sau đó đưa ra định hướng -> Giao việc cho nó kêu nó hoàn thành. Thì công việc mọi người sẽ vừa nhanh, mà mọi người còn nắm bắt được tiến độ cũng như những gì nó đang làm. Nên là chúc mọi người may mắn :D 

AI Agent là gì? Cuộc đua với Chatbot AI Online 2026?-> Như tên gọi. AI Agent ~ Self-host + Chatbox AI offline ngay trên devices đã cài agent + chọn LLM free hay paid.=> AI Build + chatbox AI nhưng giờ chạy trên devices cá nhân bạn thay vì phải truy cập vào các ông lớn Google, Microsoft online.Vậy AI agent nó khác gì với Chatbox AI Online của các ông lớn?=> KHÁC HAY KHÔNG, PHỤ THUỘC VÀO CÁCH CHÚNG TA SỬ DỤNG NÓ Ở MỨC ĐỘ BẢO MẬT HOẶC CHẤP NHẬN RISK LEVEL NÀO.vd khi bạn làm việc với Chatbox AI online cho mục đích thông báo telegram. bạn sẽ gợi ý 1 token giả:local botToken "754545dff5:ddfdfffdfdfvD4":local chatId "-343444fff":local guestName "dollar"và sau đó chúng ta viết native code hoặc tích hợp nó vào môi trường của chúng ta bằng token thật.=> Nhưng với AI Agents, bạn có thể cho phép token thật chạy bên trong build và thực thi luôn.=> Thậm chí có bạn # vẫn thực thi token thật bên trong chatbox AI/Build Online là bình thường vì mức độ risk level phụ thuộc vào quan điểm nhìn nhận của người sử dụng và thực thi.Ưu điểm của AI Agent so với Chatbox AI Online=> Mức độ nhớ history của AI agent cao hơn so với online. Nhưng không phải 100%. Vì nó sẽ ngáo khi số lượng code/prompt lớn dần. ít nhất là 8000 dòng là thấy loạn.=> Ngoài ra, khoảng token mất đi tương ứng cũng đỡ hơn, đặc biệt là LLM Free. Trong khi bản free Chatbox AI Online thường giới hạn max token trong ngày hoặc tháng đó.Nhược điểm của AI Agent so với Chatbox AI Online=> tốn tiền cho thiết bị vd Mac Mini...Tóm lại bạn có đến 3 cách làm hiện nay:1/ Chatbox AI/Build Online (Blackbox/GAS/Google Antigravity/DeepSeek/Grok/Gemini/Copilot/Claude/P series)2/ AI Agent (OpenClaw/NanoBot/PicoClaw/ZeroClaw...)3/ Native code (Python, C#, Java, JS...)=> Nếu bạn thấy 1 người deploy AI và ra kết quả nhanh hơn nhiều lần, không hẳn là risk không có dù người ta có sử dụng prompt bảo mật project. Thậm chí các AI dễ dàng nhận ra tông màu code/prompt của nhau. Đặc biệt là risk từ database.=> Trong khi, nếu bạn đi theo con đường Native code, mức độ trusted mà bạn tin vào dự án của mình tăng lên đến 95%, vì bạn đã hiểu rõ rủi ro nằm ở chỗ nào và vá trước rồi. Tổng hợp AI MODEL/LLM/NONE-LLM 2026{"Image": [{ "name": "Midjourney V6", "focus": "concept art, design" },{ "name": "DALL·E 3", "focus": "text-to-image, creative ads" },{ "name": "Adobe Firefly", "focus": "image & video generation" },{ "name": "Ideogram", "focus": "text-in-image, branding" },{ "name": "Flux Krea", "focus": "general image generation" },{ "name": "Nano Banana Pro", "focus": "advanced creative rendering" },{ "name": "Imagen 4.0", "focus": "high-quality text-to-image" },{ "name": "Nano Banana", "focus": "basic creative rendering" },{ "name": "Seedream 4.0", "focus": "stylized image generation" },{ "name": "Seedream 4.5", "focus": "enhanced stylized image generation" }],"Music": [{ "name": "Suno AI", "focus": "full songs from text prompts" },{ "name": "AIVA", "focus": "soundtracks, film & game music" },{ "name": "Boomy", "focus": "quick music creation for non-experts" },{ "name": "Riffusion", "focus": "diffusion-based audio generation" }],"Video": [{ "name": "Runway ML", "focus": "text-to-video, motion editing" },{ "name": "Pika Labs", "focus": "short video generation" },{ "name": "Adobe Firefly Video", "focus": "video from text prompts" },{ "name": "Seedance1Pro", "focus": "video generation" },{ "name": "Seedance1.5Pro", "focus": "video generation" },{ "name": "Veo3", "focus": "video AI model" },{ "name": "Veo3.1", "focus": "video AI model" },{ "name": "Viduq2", "focus": "video AI model" }],"Text & LLM": [{ "name": "GPT-4o", "focus": "text, image, audio, coding" },{ "name": "Claude 4", "focus": "reasoning, safe AI assistant" },{ "name": "Gemini 2.5", "focus": "multimodal, text+image+code" }],"Voice": [{ "name": "ElevenLabs", "focus": "natural voice synthesis, voice cloning" },{ "name": "OpenAI TTS", "focus": "real-time speech generation" },{ "name": "Microsoft Azure Speech", "focus": "TTS, STT, customizable voices" },{ "name": "Google Cloud TTS", "focus": "multi-language, natural voices" },{ "name": "Meta Voicebox", "focus": "research model, diverse voice generation" }]}