Cloudflare xây dựng OAuth cùng Claude và công khai toàn bộ prompt

• Cloudflare đã công bố framework provider OAuth 2.1 dưới dạng thư viện TypeScript cho Cloudflare Workers
• Phần lớn việc triển khai được viết với sự hỗ trợ của Claude LLM từ Anthropic, sau đó được các kỹ sư bảo mật của Cloudflare rà soát kỹ lưỡng
• Thư viện này cung cấp tự động hóa xác thực cho các endpoint API và tự động xử lý quản lý token
• Hỗ trợ các tính năng chính như chuẩn OAuth mới nhất và PKCE, đăng ký client động, thiết lập phạm vi truy cập
• Nhấn mạnh thiết kế bảo mật như mã hóa end-to-end ở các điểm quan trọng và refresh token dùng một lần

---

Giới thiệu và tầm quan trọng của framework provider OAuth 2.1 cho Cloudflare Workers

Dự án mã nguồn mở này là một thư viện TypeScript được thiết kế để dễ dàng triển khai máy chủ xác thực OAuth 2.1 trong môi trường Cloudflare Workers.
So với các dự án cùng loại, điểm mạnh của nó nằm ở khả năng mở rộng và tích hợp mượt mà tối ưu cho nền tảng Cloudflare, cùng với thiết kế lấy bảo mật làm trung tâm
Trọng tâm được đặt vào thuật toán, việc tuân thủ các tiêu chuẩn giao thức (RFC-8414, RFC-7591, v.v.) và cấu trúc thư viện rõ ràng
Đặc biệt, thư viện được thiết kế chi tiết để tăng độ an toàn, như lưu token và các giá trị bí mật chính dưới dạng hash, cùng với mã hóa end-to-end cho props
Đáng chú ý, phần lớn mã lõi và tài liệu của thư viện được viết với sự cộng tác của Claude LLM, cho thấy một ví dụ phát triển thú vị

Các tính năng và ưu điểm chính

• Bọc mã Worker bằng OAuthProvider để tự động thêm chức năng xác thực cho các endpoint API
• Quản lý token (tạo, lưu, xác thực, thu hồi, v.v.) được xử lý tự động, không cần tự triển khai
• Người dùng có thể nhận trực tiếp thông tin người dùng đã được xác thực dưới dạng tham số để sử dụng ngay trong fetch handler
• Không áp đặt ràng buộc về cách quản lý người dùng, xác thực hay triển khai UI (nhà phát triển có thể tự do chọn cấu trúc và framework mong muốn)
• Kho lưu trữ của thư viện chỉ lưu thông tin hash, không lưu bản thân secret như khóa bí mật

Những điểm cốt lõi trong cách sử dụng

• Có thể export instance OAuthProvider làm entrypoint của Worker để đảm nhiệm vai trò fetch handler
• Với các tùy chọn apiRoute và apiHandler, có thể chỉ định riêng khu vực endpoint API cần xác thực và handler thực tế
• Có thể định nghĩa đường dẫn cho từng endpoint OAuth tiêu chuẩn như authorizeEndpoint, tokenEndpoint, clientRegistrationEndpoint
• Khi cần, có thể tinh chỉnh chính sách như scope hoặc đăng ký public client
• Qua defaultHandler, cũng có thể xử lý linh hoạt các request ngoài API và các request xác thực thất bại

Helper object và API

• Có thể dùng env.OAUTH_PROVIDER trong fetch handler để phục vụ việc phân tích request liên quan đến OAuth, tra cứu thông tin client, hoàn tất phê duyệt, v.v.
• Trong xử lý request API, nếu access token hợp lệ thì có thể truy cập trực tiếp thông tin props theo từng người dùng đã được cấp quyền qua ctx.props
• Các API chính thức cũng hỗ trợ đăng ký client, danh sách quyền cấp phát (authorization grant), xem và thu hồi grant của một người dùng cụ thể

Token Exchange Callback

• Hỗ trợ callback (tokenExchangeCallback) cho phép cập nhật động giá trị props khi cấp mới hoặc làm mới token
• Có thể hỗ trợ các kịch bản phức tạp như trao đổi token bổ sung với OAuth client (upstream token exchange)
• Trong callback, có thể trả về accessTokenProps, newProps, accessTokenTTL để triển khai hành vi tùy chỉnh
• Thông qua tùy chỉnh accessTokenTTL, có thể đồng bộ thời điểm hết hạn token với hệ thống OAuth cấp trên
• props có thể chứa thông tin nhạy cảm, vì vậy toàn bộ giá trị này được lưu bằng mã hóa end-to-end

Phản hồi lỗi tùy chỉnh

• Dùng tùy chọn onError để thực hiện các biện pháp đối ngoại như gửi thông báo hoặc logging tùy chỉnh khi phát sinh lỗi
• Nếu tự định nghĩa Response trả về, có thể ghi đè phản hồi lỗi mà OAuthProvider cung cấp cho người dùng theo hình thức mong muốn

Thiết kế chi tiết liên quan đến bảo mật

Mã hóa end-to-end

• Dữ liệu và secret liên quan đến token chỉ được lưu dưới dạng hash, còn thông tin grant props được mã hóa và lưu bằng chính token, giúp nâng cao khả năng ứng phó khi xảy ra rò rỉ
• userId, metadata v.v. không được mã hóa để phục vụ audit và ghi nhận cho mục đích thu hồi; nếu cần, nhà phát triển có thể áp dụng mã hóa bổ sung

Thiết kế refresh token dùng một lần

• Theo yêu cầu của OAuth 2.1 về điều kiện "ràng buộc với client hoặc dùng một lần", thư viện này chọn thiết kế thỏa hiệp là cho phép tối đa 2 refresh token song song
• Nhờ đó, ngay cả khi việc lưu token mới thất bại do sự cố mạng, vẫn có cơ chế an toàn cho phép dùng lại token trước đó thêm một lần

Quy trình phát triển dựa trên Claude

• Phần lớn thư viện và tài liệu này được tạo bản nháp bằng Anthropic Claude LLM, sau đó được các kỹ sư Cloudflare rà soát kỹ càng để phù hợp với RFC và tiêu chuẩn bảo mật
• Ban đầu họ hoài nghi về việc tạo mã bằng AI, nhưng quan điểm đã thay đổi thông qua trải nghiệm thực tế về chất lượng và năng suất được cải thiện
• Toàn bộ luồng phát triển, prompt của Claude và quá trình cải thiện mã đều được công khai minh bạch trong lịch sử commit Git

Thông tin khác

• Bắt buộc phải áp dụng binding Workers KV namespace (OAUTH_KV), tham khảo storage-schema.md
• Toàn bộ API và helper có thể tham khảo định nghĩa interface OAuthHelpers
• Thư viện hiện đang ở giai đoạn beta/pre-release và API có thể thay đổi trong tương lai

---

[GN⁺]

Ý kiến trên Hacker News

• Trích từ README. Thư viện này (và tài liệu schema) phần lớn được viết với sự hỗ trợ của mô hình AI Claude của Anthropic. Các kỹ sư Cloudflare đã rà soát rất kỹ và chú ý đến bảo mật cũng như việc tuân thủ tiêu chuẩn. Ngay từ các kết quả đầu tiên cũng đã có nhiều cải thiện, chủ yếu bằng cách tiếp tục đưa thêm prompt cho Claude rồi lặp đi lặp lại việc xem xét kết quả. Có thể trực tiếp kiểm tra trong lịch sử commit xem họ đã prompt cho Claude như thế nào và đoạn mã nào đã được tạo ra. Ban đầu, quan điểm hoài nghi truyền thống là “không nên để LLM viết thư viện xác thực”. Tính đến tháng 1 năm 2025, bản thân tôi cũng rất hoài nghi AI, cho rằng LLM chỉ là một kiểu “trình tạo chuỗi Markov hào nhoáng”, không thể tạo ra thứ gì mới mẻ hay mã thực sự hữu ích. Tôi bắt đầu dự án này cho vui, nhưng đã bị sốc khi thấy mã tạo ra tốt hơn mong đợi. Nó không hoàn hảo, nhưng chỉ cần yêu cầu AI sửa thì nó đã sửa khá đúng. Tôi đã đối chiếu từng dòng với nhiều RFC khác nhau và cùng các chuyên gia bảo mật rà soát. Tôi định kiểm chứng sự hoài nghi của mình, nhưng kết quả lại chứng minh chính tôi đã sai. Nhất định nên xem lịch sử commit, đặc biệt là các commit đầu tiên, để thấy rõ quá trình này

  • Tôi kỳ vọng rằng khi được một kỹ sư lành nghề prompt đúng cách, LLM hoàn toàn có thể tạo ra cỡ mã như thế này. OAuth không phải công nghệ mới, và hẳn đã có vô số ví dụ mã nguồn mở cùng nhiều cách triển khai ở các ngôn ngữ khác nhau được dùng làm dữ liệu. Nhưng tôi vẫn hoài nghi trước những tuyên bố rằng LLM sẽ đóng góp mang tính đột phá cho nghiên cứu hoàn toàn mới, khoa học vật liệu, kinh tế hay phát minh. Đó là những lĩnh vực thực sự cần “khả năng học theo thời gian thực”, trong khi các LLM hiện tại chỉ thể hiện năng lực dựa trên thông tin cũ mà chúng đã biết. Những kết quả có ý nghĩa phần lớn vẫn chỉ là các ví dụ cherry-pick trong môi trường rất hạn chế. Nếu có kỹ sư giỏi thì việc sinh mã mới dựa trên dữ liệu quá khứ là điều đương nhiên có thể làm được, nhưng tôi vẫn nghi ngờ rằng gánh nặng môi trường và xã hội do việc áp dụng LLM mang lại có đang quá lớn so với hiệu quả thực tế hay không

  • Tôi thấy bối rối với cách diễn đạt “Cho đến tháng 1 năm 2025 tôi cũng có suy nghĩ giống (@kentonv)”. Vì kentonv là một người dùng khác. Tôi thắc mắc đây có phải tài khoản phụ của tác giả không, hay chỉ là lỗi gõ hoặc hiểu nhầm. Chỉnh sửa: Tôi nhận ra phần lớn bài viết là trích từ README. Nếu dùng ký hiệu > và * để làm rõ phần trích dẫn thì có lẽ sẽ bớt gây nhầm lẫn hơn. Đính kèm liên kết hồ sơ kentonv

  • "Tôi nghĩ LLM là một trình tạo chuỗi Markov hào nhoáng" và "Tôi ngạc nhiên khi AI tạo ra mã khá ổn" không phải là hai ý kiến mâu thuẫn nhau. Tôi thấy LLM cực kỳ hữu ích, nhưng về bản chất nó vẫn gần với một bộ máy tạo mẫu hình. Điểm quan trọng là mức độ đó đã đủ hữu dụng, và con người có khi cũng không khác biệt quá nhiều về cấu trúc

  • Dạo này tôi nghiêng về phía hoài nghi hơn là pro-AI, nhưng dù sao vẫn đang tiếp tục thử đưa AI vào workflow. Trên thực tế, việc giải thích cho AI còn khó hơn nên tôi thường thấy tự làm còn dễ hơn. Cũng không vui lắm, nhưng vì đây là công cụ của “tương lai” nên tôi nghĩ học cách dùng nó là điều khôn ngoan. Hiện tại tôi vẫn xem tooling AI thực thụ chỉ đang ở giai đoạn rất sớm. Tôi vẫn tiếp tục quan tâm đến những ví dụ UX thú vị sẽ xuất hiện sau này

  • Có hướng dẫn xem trực tiếp lịch sử commit để biết ở giai đoạn đầu Claude đã được prompt như thế nào và thực sự tạo mã ra sao. Có liên kết đi thẳng tới trang các commit đầu tiên. Có rất nhiều chỉ dẫn rõ ràng và cụ thể, và cũng đáng xem cả ví dụ commit 1, ví dụ commit 2

• Trích từ commit về vấn đề này trong workers-oauth-provider của Cloudflare. Claude đã gây ra lỗi ở một commit trước đó, và dù đã nhiều lần cố sửa bằng prompt thì vẫn thất bại. Cuối cùng con người phải tự sửa và còn ghi lại cả vấn đề trong đặc tả OAuth 2.1 vào README. Trải nghiệm này cá nhân tôi cũng rất đồng cảm khi dùng AI. Nó thường làm tốt đến khoảng nửa chặng đường rồi vật lộn với phần còn lại

  • Tôi chú ý đến điểm là AI làm khá tốt đến giữa chừng, nhưng một khi đã mắc sai lầm thì về sau mọi thứ đều hỏng hết. Khi phát hiện lỗi, phải ngay lập tức viết lại prompt từ đầu và bắt đầu lại toàn bộ cuộc trò chuyện. Sau khi đã phạm một lỗi, dù có cố chỉnh lại thế nào thì kết quả vẫn tiếp tục sai. Vì thế cần gói mọi thứ thật rõ vào thông điệp mở đầu đúng đắn và dựng lại từ đầu thì mới tránh lặp lại sai lầm

  • Để giảm bớt vấn đề này, có thể chuẩn bị test hoặc đặc tả rõ ràng để AI tự giải. Vài tháng trước, AI còn mất nhiều thời gian để giải các bài toán dạng đặc tả như vậy, và chất lượng đầu ra còn thấp hơn so với việc cho câu trả lời nhanh. Nhưng gần đây năng lực mô hình đã cải thiện rất nhiều, nên những công việc kiểu này trở nên khá thú vị và càng hữu dụng hơn khi có thể đặc tả hóa. Cá nhân tôi thấy sonnet 3.7 là bước tiến lớn so với 3.5, còn Gemini 2.5 Pro thì còn gây ấn tượng hơn. sonnet 4 mắc lỗi ít hơn, nhưng xét từ góc độ kỹ thuật phần mềm (chốt yêu cầu, khám phá giải pháp kỹ thuật, thiết kế kiến trúc, viết user story và đặc tả, viết mã), vẫn phải dẫn dắt AI đúng cách thì mới có đầu ra chất lượng. Ngoài ra, nếu bổ sung thêm ví dụ tốt cho AI thì hiệu quả sẽ tăng mạnh. Gần đây khi làm ứng dụng với OpenAI Realtime API, lúc đầu tôi thất bại hoàn toàn, nhưng sau khi thêm hai trang tài liệu và một dự án demo vào workspace thì lập tức có được kết quả mong muốn (trong trường hợp của tôi, dù phải dùng API theo cách khác đi thì nó vẫn khớp tốt)

  • Trong nội dung nhắc đến ở các dòng 163~172 của commit, tôi thấy có những khẳng định rõ ràng là sai về mặt thực tế hoặc còn tùy cách diễn giải giữa các triển khai A/S. Máy chủ xác thực của Auth0 có thiết lập “leeway” để tính đến điều kiện mạng, nhưng một số máy chủ xác thực khác thì nghiêm ngặt hơn nhiều. Chi tiết thiết kế khác nhau giữa từng implementation, nên tôi nghĩ xác suất để LLM triển khai an toàn chỉ từ tiêu chuẩn (RFC) và mã nguồn mở công khai, rốt cuộc vẫn đòi hỏi mức độ giám sát của con người tương đương với việc tự xây dựng trực tiếp

  • Tôi tò mò liệu về dài hạn sẽ có nghiên cứu nào cho thấy công cụ dựa trên LLM thực sự giúp tiết kiệm nhân lực đầu vào, hay chỉ tạo ra ảo giác về năng suất

  • Từ những trải nghiệm như thế này, tôi cho rằng các công cụ AI không thật sự hiểu, mà chỉ tạo ra đầu ra mang tính ngẫu hiện dựa trên một tập dữ liệu mẫu hình khổng lồ

• Tương lai của AI coding có lẽ không phải kiểu huyễn tưởng LinkedIn/X rằng kỹ sư phần mềm sẽ biến mất và doanh nhân chỉ cần bấm nút là xong mọi thứ, mà sẽ là những kỹ sư lành nghề dùng AI để tạo một phần mã rồi rà soát, kiểm thử thật kỹ. Câu hỏi thực sự quan trọng là: “Liệu kentonv có thể tự làm thư viện này nhanh hơn nếu không dùng AI không?”

  • Phải mất vài ngày để làm thư viện cùng với AI. Nếu tự tay làm hoàn toàn thì có lẽ phải mất vài tuần, thậm chí vài tháng. Tuy nhiên, đây là một trường hợp rất lý tưởng. Nó chỉ khả thi vì có tiêu chuẩn rõ ràng, đặc tả API rõ ràng, và một nền tảng vốn đã rất quen thuộc. Khi thử dùng AI để thay đổi chính Workers Runtime thì hiệu quả tiết kiệm thời gian không đáng kể. Nhưng với các codebase của người khác mà tôi không quen, AI thực sự rất hữu ích. Giờ đây việc bước vào những mê cung mã lạ và phức tạp đã dễ hơn nhiều; trước đây tôi tránh những việc như vậy, còn bây giờ tôi có thể dễ dàng tự thực hiện các thay đổi mình cần

  • Với câu hỏi liệu tự làm một mình không có AI có nhanh hơn không, tôi khá chắc là không. Với bộ công cụ hiện tại và kinh nghiệm sử dụng ngày càng tốt lên, tôi nghĩ trong vòng 3-6 tháng tới việc tự code các giải pháp mới bằng AI sẽ còn nhanh hơn nữa. Tuy vậy, một codebase được tài liệu hóa tốt, cấu trúc rõ ràng và có vòng phản hồi nhanh (lint/unit test tốt) là điều rất quan trọng. Chúng ta đang tiến dần về phía đó

  • Theo kinh nghiệm của tôi, khi AI tạo một phần mã, tôi phải review và test rất kỹ, và quá trình này còn <i>chậm</i> hơn việc tự tôi viết mã. Vì vậy ở giai đoạn hiện tại, AI không giúp tôi được nhiều. Giống như câu ngạn ngữ rằng có trợ lý tệ còn tệ hơn không có trợ lý, AI hiện giờ vẫn là một “trợ lý tệ”

  • Nếu mô hình là “kỹ sư giàu kinh nghiệm dùng AI tạo một phần mã rồi kiểm thử thật kỹ”, vậy chẳng phải chỉ cần 2 người thay vì 20 kentonv là đủ sao? Liệu sẽ còn đủ việc làm cho 18 người còn lại không? Trường hợp của tác giả là dự án khó về mặt kỹ thuật, nhưng tôi tò mò chuyện gì sẽ xảy ra với việc phát triển các ứng dụng LoB tương đối nhạt nhẽo

  • Nếu các kỹ sư giàu kinh nghiệm chỉ còn làm nhiệm vụ review và test kỹ lưỡng, thì nếu tất cả vị trí lập trình viên junior bị AI thay thế, các kỹ sư kỳ cựu tương lai sẽ đến từ đâu? Tôi cho rằng ngay cả các công việc lặp đi lặp lại đơn giản cũng có giá trị riêng của nó

• Việc thấy đủ loại luận điểm và ý kiến như thế này tự nó đã rất thú vị. Tôi cảm ơn Cloudflare, đúng với vị thế một công ty dẫn đầu về bảo mật Internet, đã cho thấy nỗ lực kết nối thế giới bằng một kiểu ‘vibe coding’ mới. Tôi cảm nhận được rằng những prompt AI, đoạn mã này v.v. cũng đang khơi dậy ý chí khám phá lập trình ở các nhà phát triển khác. vibe programming là một phương tiện rất có ý nghĩa, giúp tôi vượt qua sự u uất và quay lại viết code theo cách phù hợp với mình. Tôi hy vọng trải nghiệm này cũng có thể giúp ích cho người khác. Tôi kỳ vọng cả thế hệ hiện tại lẫn tương lai đều sẽ tận dụng cách làm này. Tuy nhiên, tôi cũng nghĩ cần thảo luận về việc cách làm này có thể liên quan tới sức khỏe tinh thần hay các vấn đề tâm lý của con người. Cuối cùng, cần ghi nhớ rằng các công cụ như vậy là phương tiện hỗ trợ cho con người, và suy nghĩ xem nên dùng chúng thế nào để chúng ta có thể trưởng thành với đam mê. Tôi hy vọng trong lĩnh vực mã nguồn mở sẽ có thêm nhiều ví dụ cho thấy không chỉ năng lực kỹ thuật mà còn cả tư duy logic và cách tiếp cận dự án thận trọng. Một lần nữa xin dành lời khen cho Cloudflare

• Có tổng hợp các ví dụ trao đổi prompt tiêu biểu. Trong ví dụ transcript prompt, họ còn công khai cả chi phí thực tế (tổng cộng $6.45). Cũng có hướng dẫn tới các tài liệu như commit liên quan 1, commit 2. Thật ngạc nhiên khi có quá ít bài chia sẻ trải nghiệm đúng nghĩa về workflow AI (đặc biệt từ những người nhiều kinh nghiệm), vì phần lớn đều bị chìm trong làn sóng hype. Tôi đang muốn biết thêm các trường hợp live coding thực tế chứ không chỉ là todo list. Có lẽ cũng nên tham khảo bài của antirez và tptacek (trường hợp của antirez, bài của tptacek)

  • Tôi không theo dõi chính xác, nhưng ước tính chi phí dùng Claude vào khoảng $50. So với thời gian tiết kiệm được thì đây là mức chi phí không đáng kể

• Tôi cho rằng “vibecoding” rốt cuộc sẽ không thể tồn tại lâu. Vẫn cần lập trình viên giỏi xác minh và sửa lỗi, và cũng có những lỗi mà AI không sửa nổi. Cuối cùng, các công cụ kiểu này chỉ là công cụ hỗ trợ để tăng tốc cho những người vốn đã hiểu rất rõ công việc mình đang làm. Trừ những trang web cực kỳ cơ bản, còn kiểu công cụ tự tạo như vậy đã tồn tại từ nhiều năm trước rồi

  • vibecoding hiện giờ phù hợp nhất với các công việc có mức độ rủi ro thấp. GUI, ứng dụng CRUD, thí nghiệm dùng một lần, v.v. rất hữu ích ở khía cạnh trao quyền mới cho những người ít quyền năng hơn. Tôi nghĩ trường hợp này không phải vibecoding mà là LLM-assisted coding

  • Trên thực tế, tôi có cảm giác từ vibecoding thường bị dùng như một con rối rơm để công kích. Chẳng phải phần lớn việc nhận mã từ LLM rồi sửa lại đôi chút để dùng cũng có thể xem là vibe coding sao?

• Tôi thực sự biết ơn OP vì đã công khai không chỉ đoạn mã do AI tạo mà cả prompt. Cá nhân tôi khi phát triển mã không phải web bằng LLM (đặc biệt gần đây là reverse engineering SAP ABAP để làm phần triển khai .NET đưa dữ liệu vào Snowflake) thì lần nào cũng khổ sở với vấn đề “ảo giác”. Thấy người khác có nhiều ca thành công nên tôi cứ nghĩ có lẽ prompt của mình có vấn đề, nhưng nhìn vào ví dụ được công khai lần này tôi nhận ra mình cũng không cách quá xa. Tôi kết luận rằng LLM không hợp với tôi lắm vì bài toán tôi tạo ra hơi hiếm và mới. Nếu không phải một mục tiêu đã được học rất nhiều như trường hợp OAuth được công khai trên GitHub, thì LLM sẽ theo không nổi

• Loại mã lặp đi lặp lại như thế này, vốn đã được triển khai hàng trăm lần, là thứ hoàn toàn phù hợp với AI. Tổng mã chỉ khoảng 1200 dòng nên quy mô nhỏ. Điều khiến tôi ngạc nhiên hơn là dù dùng AI mà vẫn mất hơn 2 ngày

• Trong vài tháng gần đây, khi làm dự án greenfield của riêng mình bằng Claude qua Cursor, tôi rút ra vài điều. Thứ nhất, năng suất tăng lên rất nhiều. Thứ hai, tôi mệt mỏi về tinh thần hơn hẳn trước đây. Thứ ba, ngay cả trong ngắn hạn, các công cụ cũng đang bắt đầu cải thiện rất nhanh, và hai hiệu ứng trên cũng đang được khuếch đại

  • Trải nghiệm của tôi và của các lập trình viên khác cũng y hệt vậy. LLM-assisted coding thực sự giúp tăng năng suất rất nhiều, nhưng mức tiêu hao năng lượng cũng lớn tương ứng. Thậm chí còn thấy khá lạ

  • Có người hỏi thêm về điểm “mệt hơn như vậy”. Tôi đang dùng agent của mình (Devstral) theo kiểu “pair programming” hơn là cách làm cũ, và việc review dễ hơn nhiều so với việc phải tự tay gõ toàn bộ mã. Xét về thời gian, đây là lợi thế lớn. Với vibe coding, bối cảnh của codebase bị đánh mất nên về sau việc review và tiếp cận lại trở nên khó hơn nhiều. Trong khi đó, với pair programming thì bối cảnh được tích lũy dần trong quá trình làm nên tôi thấy review nhanh hơn nhiều

  • Còn tôi thì hoàn toàn ngược lại. Vì AI lo hết mọi chi tiết lặt vặt nên tôi cảm thấy nhẹ nhõm rất nhiều. Nó giải phóng tôi để tập trung vào các mục tiêu ở tầng cao hơn như kiến trúc

• Việc một công ty như Cloudflare lại hiện lỗi "Too Many Requests" nghe khá buồn cười

  • Tôi cũng vậy