AI đang xóa cái giả định đó, và code nhanh hơn chỉ là một phần nhỏ của chuyện này. Bây giờ một người có thể giữ toàn bộ product trong đầu, từ lý do tại sao nó tồn tại, đến trải nghiệm người dùng, đến implementation chi tiết, rồi tự ship nó ở tốc độ trước đây chỉ team mới đạt được. Garry Tan nói rằng đã viết hơn 600.000 dòng code trong 60 ngày trong khi vẫn là CEO của YC. Số dòng code chưa bao giờ là thước đo tốt cho giá trị của phần mềm, nên tôi không để ý nhiều đến con số đó. Cái tôi để ý là một người đang giữ được cả vòng lặp mà trước đây cần một team. Với tôi đó là một cách làm việc khác, và gọi nó là năng suất cao hơn thì chưa tả hết.

Sự khác biệt quan trọng nhất

Hình mẫu cũ có hai vai trò tách biệt: người biết phải làm gì (product, business) và người biết làm như thế nào (kỹ thuật). Hai vai trò này giao tiếp qua spec document, ticket, và meeting.

Hình mẫu mới xóa cái khoảng cách đó. Người làm sản phẩm trong thời đại AI không cần spec document vì họ đồng thời là người viết spec và người implement nó, nên ý tưởng đi vào code mà không bị rơi rớt qua bước chuyển giao nào.

Nghe thì giống "full-stack developer", nhưng full-stack developer vẫn cần team: PM để quyết định ưu tiên, designer để làm UI, DevOps để deploy. Người làm sản phẩm trong thời đại AI có thể một mình giữ toàn bộ vòng lặp đó.

Thứ AI không thể thay thế

Hình mẫu này hoạt động được nhờ taste, tức là khả năng biết thứ gì đáng build, thứ gì nên bỏ, và thứ gì đủ tốt để ship. Khả năng code nhanh thì đứng sau.

AI viết code theo hướng dẫn. Nó không biết liệu feature này có cần thiết không, liệu UX này có confusing không, liệu đây có phải là vấn đề thực sự người dùng gặp không. Những câu hỏi đó vẫn cần người trả lời.

Vì vậy, người làm sản phẩm trong thời đại AI cần product sense tốt nhất, còn kỹ thuật thì chỉ cần đủ để không bị implementation chặn lại.

Điều này thay đổi gì

Tôi nghĩ đây là một trong những dịch chuyển lớn nhất trong nghề xây dựng phần mềm, nhưng nó không được nói đến đủ nhiều vì người ta đang tập trung vào câu chuyện "AI thay thế developer".

Theo tôi, chuyện đang xảy ra giống mở rộng hơn là thay thế. Những người trước đây không thể build vì thiếu kỹ năng kỹ thuật thì nay build được, còn developer từng bị giới hạn bởi bandwidth thì nay không còn bị giới hạn như vậy. Đồng thời có một lớp người mới đang xuất hiện, không hẳn là developer cũng không hẳn là founder: người làm sản phẩm có thể ship một mình.

Nếu phải chọn người đáng gờm nhất trong tech hiện tại, tôi sẽ chọn người vừa có product taste vừa biết đủ để ship, hơn là kỹ sư giỏi nhất hay CEO có tầm nhìn nhất.

Đầu tôi vẫn chạy, mắt vẫn theo từng dòng code hiện ra, nên gọi là rảnh hay chán thì đều không đúng. Gần nhất có lẽ là cảm giác đang đọc. Chỉ có điều tôi đang đọc một thứ mình chưa từng viết, và nó được viết ra nhanh hơn tốc độ tôi đọc kịp, nên tôi phải chọn chỗ nào đọc kỹ, chỗ nào lướt qua, như lúc phải review một PR vài nghìn dòng trước giờ họp.

Ai từng ngồi ghế phụ cạnh một người đang tập lái chắc nhận ra cảm giác này. Tay không cầm vô lăng, chân không đạp ga, vậy mà xuống xe thì mệt hơn cả tự lái. Người cầm lái là người đang tập, còn người chịu trách nhiệm cho chiếc xe lại là người ngồi bên. Mắt phải nhìn xa hơn người cầm lái một đoạn, còn chân thì lúc nào cũng hờ trên một cái phanh không có thật.

Trước đây tôi quen định nghĩa mình qua việc gõ phím. Code có mặt vì tôi viết ra nó, từng ký tự một. Giờ phần ấy đã có người làm thay, còn việc của tôi là nhìn kết quả và biết nó đúng chưa, còn thiếu gì, lúc nào thì phải hỏi lại. Vai trò vẫn còn đó, chỉ dời sang một chỗ khó nhìn thấy hơn.

Nhịp làm việc vì thế cũng đổi. Thời gian gõ phím ít đi, thời gian đọc nhiều lên: đọc diff, rồi đọc lại yêu cầu mình đã viết để xem agent có hiểu đúng ý không. Đọc code vốn khó hơn viết, vì người đọc phải dựng lại trong đầu những lựa chọn mà người viết đã làm mà không ghi ra. Khi người viết là một thực thể không biết mệt, toàn bộ sức nặng của việc đọc và ngẫm ấy đổ dồn về phía tôi.

Trên công trường, người thợ cả nhiều khi chẳng cầm bay. Họ đi dọc bức tường mới xây, nheo mắt một chút, rồi chỉ vào chỗ lệch mà người khác phải đặt thước mới thấy. Người mới học việc nhìn bức tường ấy chỉ thấy gạch và vữa, còn họ thấy cả những chỗ sẽ nứt sau mùa mưa đầu tiên. Công của họ nằm ở đôi mắt ấy, và đôi mắt ấy có được từ những năm họ tự tay đặt từng viên gạch.

Có một chữ tôi cứ nghĩ tới mãi là taste, khả năng phân biệt thứ tốt với thứ chỉ trông có vẻ tốt. Nó khác với kỹ năng viết code, cũng khác với tốc độ làm xong một tính năng. Một đoạn code chạy được và qua được test vẫn có thể là một lựa chọn sai cho cái hệ thống sẽ phải sống với nó vài năm. Tôi không nghĩ có thể khoán việc này cho AI, và càng ngày tôi càng tin đây là thứ đáng giữ, đáng mài nhất lúc này.

David Hume có một bài luận về chuẩn mực của thị hiếu, viết vào giữa thế kỷ mười tám. Theo ông, người thẩm định đáng tin cần một sự tinh tế được rèn qua luyện tập và hoàn thiện qua so sánh. Tôi thích chữ so sánh ở đó. Muốn biết một abstraction gọn thật hay chỉ gọn ngoài mặt, người ta phải từng thấy đủ nhiều cái gọn thật và cái gọn giả để đặt chúng cạnh nhau.

Vì thế tôi không thấy những năm viết code bằng tay trở nên vô ích. Chính vì từng viết đủ nhiều, tôi mới phân biệt được abstraction tốt với abstraction chỉ trông gọn gàng, và nhờ vậy mới đọc được những gì agent viết ra. Những lần ngồi lần một lỗi do chính mình gây ra, hay viết lại một module vì thiết kế ban đầu không chịu nổi yêu cầu mới, giờ hiện ra ở một chỗ tôi không ngờ, là lúc đọc code của người khác. Thứ kinh nghiệm ấy để lại hoá ra là phán đoán, nhiều hơn là ngón tay gõ nhanh.

Aristotle có nói tới một loại hiểu biết ông gọi là phronesis, thường được dịch là sự khôn ngoan thực tiễn, tức là biết nên làm gì trong một tình huống cụ thể. Ông nhận xét người trẻ có thể giỏi hình học và toán, nhưng khó có được thứ khôn ngoan này, vì nó cần kinh nghiệm với rất nhiều trường hợp riêng lẻ. Đọc đoạn ấy, tôi nghĩ tới việc review code. Thuộc các nguyên tắc thiết kế thì nhanh, còn biết nguyên tắc nào nên phá ở đúng chỗ này thì phải mất nhiều năm.

Michael Polanyi có một câu hay được nhắc: chúng ta biết nhiều hơn những gì ta nói ra được. Taste trong code có lẽ thuộc loại hiểu biết ấy. Nhiều khi tôi thấy một đoạn code có gì đó không ổn trước khi giải thích được vì sao. Lời giải thích chỉ tới sau vài lượt đọc lại, khi tôi chỉ ra được cái mà người trong nghề hay gọi là "có mùi", như một hàm biết quá nhiều về những thứ xung quanh nó, hay một điều kiện bị lặp lại ở vài chỗ.

Cái khó nhất với tôi hoá ra lại là những lúc mọi thứ êm. Khi agent làm đúng nhiều lần liền, tôi bắt đầu đọc nhanh hơn, lướt hơn, và có khi gật đầu trước cả lúc đọc hết. Người ngồi ghế phụ cũng thế, người tập lái chạy êm được một quãng dài là lúc họ bắt đầu nhìn ra cửa sổ. Chiếc xe thì không biết người ngồi cạnh đã thôi để ý.

Để giữ con mắt ấy, thỉnh thoảng tôi vẫn tự viết một đoạn khó từ đầu, dù biết agent làm nhanh hơn. Thường đó là một chỗ xử lý đồng thời, hoặc một đoạn migrate dữ liệu mà sai một dòng là phải khôi phục từ backup. Viết xong, tôi đem so với bản agent viết, và thường thấy ít nhất một chỗ hai bên chọn khác nhau. Những chỗ khác nhau ấy chính là kiểu so sánh Hume nói tới, chỉ là giờ nó nằm gọn trong một cái diff.

Cũng có lúc tôi thấy hơi bất an. Người thợ cả có con mắt ấy nhờ những năm đặt gạch, còn một người mới vào nghề hôm nay, bắt đầu từ ghế phụ, sẽ học nhìn từ đâu? Tôi không lo cho mình nhiều, vì con mắt của tôi đã được mài từ trước khi có agent. Tôi chỉ hơi lo cho những người vào nghề sau này, những người sẽ quen nhìn code tốt hiện lên ngay từ đầu, trước khi kịp nếm trải thế nào là viết ra những dòng code dở.

Người vào nghề trước đây học nhìn qua những lần PR bị trả về với cả chục comment. Có những lỗi chỉ thấm khi chính mình viết ra rồi bị người khác chỉ vào, như một vòng lặp gọi database ở từng lượt, hay một biến dùng chung khiến hai request giẫm nhau. Những bài học ấy đến từ code dở do chính tay mình viết. Tôi nghĩ phần viết dở ấy là chỗ không bỏ được, và tôi chưa biết nghề mình sẽ giữ nó lại bằng cách nào.

Có một thứ thì không dời đi đâu cả, là cái tên trên commit. Agent viết, nhưng người bấm merge là tôi, và khi hệ thống lỗi lúc nửa đêm thì người bị gọi dậy cũng là tôi. Lịch sử git sẽ ghi tên tôi ở dòng approve, và một năm sau, ai đọc lại đoạn code ấy sẽ tìm tới tôi để hỏi vì sao nó được viết như thế. Cái tên ấy làm việc ngồi nhìn nặng hơn nhiều so với vẻ ngoài của nó.

Một người review code giỏi có lẽ gần nhất với việc tôi đang làm bây giờ. Họ không có tên trong phần lớn commit, nhưng một codebase tốt thường mang dấu tay của họ ở những chỗ người dùng không thấy, như một abstraction bị gỡ đi trước khi kịp lan ra, hay một trường hợp biên được hỏi lại. Họ đọc code của người khác kỹ hơn cả người viết đọc code của chính mình, vì trong đầu họ không có sẵn điều người viết định làm. Người dùng chỉ thấy sản phẩm chạy, còn những lần nó suýt hỏng thì chỉ người review biết.

Nên giờ, khi ngồi nhìn agent viết code, tôi biết mình đang làm phần việc khó nhất của nghề này, là nghĩ. Việc ấy khó thấy hơn gõ phím, và mệt theo một kiểu khác. Màn hình vẫn chạy chữ, tôi vẫn ngồi yên, và mắt tôi luôn nhìn trước người cầm lái một đoạn.

Đợt này mình tìm hiểu về Protocol Buffers (proto), định dạng gRPC dùng để định nghĩa service. Mình mở Claude Code lên và prompt: "Help me to learn proto quickly." Claude bắt đầu giới thiệu sơ lược, từ syntax cơ bản đến cách định nghĩa service. Mình đọc, và rồi bắt đầu thắc mắc. Tại sao phải define schema trước? Điều gì xảy ra nếu client và server dùng version proto khác nhau? Mình hỏi lại, Claude giải thích, mình hỏi tiếp.

Lúc đó mình mới để ý rằng phần có ích nhất là những câu hỏi mình tự đặt ra, nhiều hơn là câu trả lời của Claude.

Đặt câu hỏi là một kỹ năng. Mỗi kiến thức được đưa ra, nếu mình chỉ đọc và gật đầu thì nó sẽ trôi qua. Nhưng nếu mình nhìn nó từ nhiều góc độ, đặt nó vào bối cảnh khác nhau, tự hỏi "cái này liên quan thế nào đến thứ mình đã biết" hay "trong trường hợp nào thì cách này không dùng được", thì kiến thức đó bắt đầu có cấu trúc trong đầu.

Mình cũng làm tương tự khi tìm hiểu một tài liệu thiết kế hệ thống. Thay vì đọc từ đầu đến cuối, mình đọc từng phần nhỏ rồi mở Claude lên nói chuyện. "Tại sao họ chọn message queue ở đây thay vì gọi thẳng?" "Nếu service này down thì phần còn lại bị ảnh hưởng thế nào?" Mục đích là buộc mình tự hỏi trước, rồi mới để Claude trả lời.

AI làm cho việc suy nghĩ dễ bắt đầu hơn, còn suy nghĩ thì mình vẫn phải tự làm. Khi học một mình, đôi lúc mình không biết mình nên hỏi cái gì. Có AI ở đó, mình có nơi để nói ra những thứ còn mơ hồ, và từ câu trả lời của nó, mình mới biết mình cần hỏi tiếp cái gì.

Cách học này không nhanh hơn đọc docs, nhưng những gì ở lại trong đầu sau đó thì nhiều hơn hẳn.

Khi chưa chắc nên làm một tính năng theo cách nào, tôi hay mở một branch cho cách này, một branch cho cách kia, rồi đọc thêm vài bài, hỏi thêm vài người. Nhìn từ ngoài vào thì rất kỹ lưỡng. Thực ra, phần lớn những lần như vậy tôi đã mang máng biết từ đầu cách nào khả năng cao sẽ đúng. Chỉ là tôi cố tình chưa chịu chọn, vì chọn rồi mà lỡ sai thì trách nhiệm hoàn toàn thuộc về mình.

Chữ "decide" trong tiếng Anh có gốc Latin nghĩa là cắt bỏ. Tôi thích cách hiểu ấy, vì nó giải thích được tại sao quyết định vẫn khó cả khi lựa chọn đã khá rõ. Chọn một cách đồng nghĩa với việc bỏ những cách kia lại, mà tôi thì không giỏi bỏ thứ gì lại.

Những chiếc branch bỏ dở có một đặc điểm buồn cười là chúng chẳng bao giờ biết đến thất bại. Những chiếc branch dừng lại ngay khi vừa qua phần dễ lúc nào trông cũng đầy hứa hẹn, bởi nó chưa hề phải chạm mặt dữ liệu thật hay chịu cảnh chạy chung với code của người khác. Người ta cũng hay giữ những phiên bản khác của đời mình theo kiểu ấy, chẳng hạn cái nghề lẽ ra đã theo hay thành phố lẽ ra đã sống. Mấy phiên bản đó đẹp một phần vì chưa bao giờ phải sống thử một ngày thứ Hai nào.

Triết gia Kierkegaard từng ví von rằng lo âu thực chất là cơn chóng mặt của sự tự do ("Anxiety is the dizziness of freedom"). Tôi nghĩ tới câu đó mỗi khi ngồi trước một màn hình trống và biết mình làm theo cách nào cũng được. Khi còn chưa chọn, tôi chưa phải chịu trách nhiệm cho cách nào cả. Cảm giác đó dễ chịu thật (tôi không giả vờ là không), và có lẽ vì thế mà tôi kéo dài nó.

Cái giá của nó là tôi cũng chẳng biết thêm được gì. Một cách làm chỉ lộ ra nó đúng hay sai khi đi gần tới cuối, lúc nó gặp những trường hợp không ai vẽ lên bảng. Ba branch dừng giữa chừng cho tôi ba lần cùng một thứ hiểu biết, loại hiểu biết có được ngay từ buổi đầu.

Thợ sửa đồ lâu năm làm việc theo một kiểu mà người ngoài thấy chậm. Gặp cái quạt hỏng, họ thử từng chỗ một, vì thay ba thứ cùng lúc mà quạt chạy lại thì cũng chẳng biết nó hỏng ở đâu. Ai từng thức khuya lần ra lỗi chỉ hiện ra trên máy khách hàng đều quen cách làm này, và biết nó nhanh hơn vẻ ngoài của nó.

Cân nhắc vẫn có chỗ của nó. Người đi thuê nhà phải xem vài căn, vì nắng buổi chiều với tiếng ồn ban đêm đâu có hiện lên trong ảnh. Chỉ là tới một lúc nào đó, so sánh thêm chẳng cho tôi biết gì mới, và tôi vẫn tiếp tục so sánh vì nó cho tôi một chỗ để trốn.

Để biết mình đã tới lúc đó chưa, tôi hay tự hỏi: nếu sáng mai phải trả lời thì mình nói gì? Nếu câu trả lời bật ra ngay, nghĩa là việc so sánh đã xong từ lâu rồi, tôi chỉ chưa chịu nhận.

Một điều giúp tôi can đảm chọn hơn, đó là chẳng có quyết định nào mang tính vĩnh viễn. Một module viết theo cách sai, nếu đã đi tới cùng, thường chỉ mất vài tuần để thay, và lúc thay thì tôi đã biết rõ nó sai ở đâu. Đổi việc hay chuyển nhà cũng vậy, mỗi lần như thế người ta đứng ở một chỗ khác và nhìn bước tiếp theo rõ hơn một chút.

Có một chuyện nữa tôi để ý. Người ta chỉ thật sự dồn tâm sức chăm chút khi đã chốt xong một ngả rẽ, giống như căn nhà thuê, phải dọn vào rồi mới thong thả treo rèm cửa. Với code cũng thế, branch tôi biết sẽ được giữ lại mới là branch tôi chịu viết test và đặt tên cho đàng hoàng. Mấy branch còn lại thì viết tạm cho xong, vì biết đâu ngày mai lại bỏ.

Nhà Thiền có câu "khi đi thì đi, khi ngồi thì ngồi". Tôi từng nghĩ câu đó dành cho người tu, chẳng liên quan gì tới một ngày ngồi viết code. Giờ tôi thấy nó tả khá đúng những ngày làm việc mà tôi thấy ổn nhất, những ngày tôi chỉ làm một việc và làm cho tới khi xong.

Con lừa của Buridan chết đói giữa hai đống cỏ mà đống nào cũng đủ cho nó sống. Nó chờ một lý do để chọn, và lý do đó không bao giờ tới. Mỗi lần thấy mình đứng giữa hai branch quá lâu, tôi lại nhớ tới nó, rồi chọn cái mình đã nghiêng về từ đầu.

1. Cache-Control là gì?

Cache-Control là HTTP header chỉ định cách một response được lưu cache và khi nào được phép dùng lại. Server gửi header này cho client (browser, CDN, proxy).

Ví dụ:

Cache-Control: public, max-age=0, must-revalidate

2. Các directive quan trọng

2.1 public vs private

• public cho phép mọi cache lưu lại, gồm browser, CDN và proxy.
• private chỉ cho cache ở browser của user, không cache ở CDN.

Quy tắc chung: static assets dùng public, data cá nhân dùng private.

2.2 max-age

Cache-Control: max-age=3600

Response được coi là fresh trong 3600 giây (1 giờ). Trong thời gian này không cần gọi server, cache được dùng trực tiếp. Đây là cách tối ưu performance mạnh nhất.

2.3 no-cache

Cache-Control: no-cache

Cái tên dễ làm hiểu nhầm thành "không cache". Thực ra response vẫn được cache, chỉ là phải kiểm tra với server trước khi dùng.

2.4 no-store

Cache-Control: no-store

Không lưu cache ở bất kỳ đâu. Dùng cho thông tin nhạy cảm như banking, auth.

2.5 must-revalidate

Cache-Control: must-revalidate

Khi cache hết hạn, bắt buộc phải hỏi lại server, không được dùng cache cũ.

2.6 s-maxage và stale-while-revalidate

Khi có CDN đứng giữa, hai directive này rất hay dùng:

Cache-Control: public, max-age=60, s-maxage=600, stale-while-revalidate=30

• s-maxage là thời gian fresh riêng cho cache dùng chung (CDN, proxy), ghi đè max-age ở đó.
• stale-while-revalidate cho phép trả bản cũ thêm 30 giây sau khi hết hạn, trong lúc cache lấy bản mới ở background.

Với ví dụ trên, browser giữ 60 giây, CDN giữ 10 phút, và người dùng không phải chờ khi CDN làm mới.

3. Hiểu sâu qua ví dụ thực tế

Cache-Control: public, max-age=0, must-revalidate

Ý nghĩa:

• public: cache được lưu ở mọi nơi
• max-age=0: hết hạn ngay lập tức
• must-revalidate: phải check server trước khi dùng

Gộp lại: response có thể cache, nhưng mỗi lần dùng phải hỏi server xem có bản mới không.

4. Cơ chế revalidation

Khi cache cần kiểm tra lại, nó dùng ETag hoặc Last-Modified.

ETag

Server trả:

ETag: "abc123"

Client gửi lại:

If-None-Match: "abc123"

Nếu không thay đổi:

HTTP 304 Not Modified

Server không cần gửi lại body, nên tiết kiệm được bandwidth.

Last-Modified

Tương tự:

Last-Modified: Thu, 26 Mar 2026 10:00:00 GMT

Client:

If-Modified-Since: ...

5. Các chiến lược cache phổ biến

5.1 Static assets (JS, CSS, images)

Cache-Control: public, max-age=31536000, immutable

Cache 1 năm và không bao giờ revalidate, dùng kèm filename hash (app.abc123.js). Đây là cấu hình cho performance tốt nhất.

5.2 HTML (dynamic content)

Cache-Control: public, max-age=0, must-revalidate

Luôn check server, nhưng vẫn tận dụng được 304. Phù hợp với SSR và content thay đổi thường xuyên.

Nếu HTML chứa dữ liệu của từng user (dashboard, trang tài khoản) thì không dùng public: CDN có thể lưu trang của người này và trả cho người khác. Dùng:

Cache-Control: private, no-cache

5.3 API responses

Trường hợp real-time

Cache-Control: no-store

Trường hợp có thể cache nhẹ

Cache-Control: public, max-age=60

Ví dụ list sản phẩm, hoặc data không thay đổi liên tục.

5.4 User-specific data

Cache-Control: private, max-age=300

Cache ở browser và không leak qua CDN.

6. Những sai lầm phổ biến

1. Dùng no-cache khi muốn "không cache"

no-cache vẫn cache. Muốn không cache thì phải dùng no-store.

2. Không version static assets

Người dùng bị kẹt với file cũ. Luôn đặt hash vào tên file:

app.[hash].js

3. Cache API mà không nghĩ về consistency

User thấy dữ liệu cũ, và bug kiểu này rất khó debug.

4. Không hiểu CDN cache

CDN có thể cache ngay cả khi bạn không để ý, nên cần đặt rõ public hay private.

5. Dùng public cho trang có dữ liệu user

CDN trả dashboard của user này cho user khác. Trang nào phụ thuộc vào người đang đăng nhập thì dùng private.

7. Best Practices (tóm tắt)

Static assets

public, max-age=31536000, immutable

HTML

public, max-age=0, must-revalidate

API

• Real-time: no-store
• Semi-static: max-age=60

Sensitive data

no-store

Luôn dùng versioning

Hash filename để tránh cache bug.

8. Ví dụ: site tĩnh trên Cloudflare Pages

Phần trên khá lý thuyết, nên mình thêm một ví dụ cụ thể: một site Next.js export tĩnh deploy lên Cloudflare Pages. Cloudflare Pages đọc header tuỳ chỉnh từ file _headers đặt trong thư mục output (với Next.js là public/_headers, khi build sẽ được copy ra output).

Next.js đặt mọi JS và CSS đã build trong /_next/static/, và tên file có hash. Nội dung đổi thì tên file đổi, nên các file này cache được rất lâu:

# public/_headers
/_next/static/*
  Cache-Control: public, max-age=31536000, immutable

HTML thì ngược lại: tên file không đổi (/index.html, /posts/abc/index.html), nên phải luôn kiểm tra lại với server. Mình không thêm rule /* cho HTML vào file này. Cloudflare Pages gộp header của mọi rule khớp với một URL, và nếu hai rule cùng đặt Cache-Control thì hai giá trị bị nối bằng dấu phẩy. Một file trong /_next/static/ khớp cả /* lẫn /_next/static/* sẽ nhận header kiểu public, max-age=0, must-revalidate, public, max-age=31536000, immutable.

Nếu thật sự cần đặt header cho mọi đường dẫn, dùng cú pháp ! để gỡ header của rule rộng hơn trước khi đặt lại:

/*
  Cache-Control: public, max-age=0, must-revalidate

/_next/static/*
  ! Cache-Control
  Cache-Control: public, max-age=31536000, immutable

Sau khi deploy, kiểm tra header thực tế bằng curl:

curl -sI https://example.com/ | grep -i cache-control
curl -sI https://example.com/_next/static/chunks/main-abc123.js | grep -i cache-control

Thay example.com bằng domain của bạn và đường dẫn file JS bằng một file thật lấy từ tab Network của trình duyệt.

Kết

Cache-Control nhìn thì đơn giản nhưng ảnh hưởng rất lớn đến hệ thống. Đặt đúng thì giảm load cho server và app chạy nhanh hơn, đồng thời tránh được hàng loạt bug khó chịu kể trên.

Một ngày của tôi có thể gồm debug một bug khó, thiết kế một flow mới, đọc tài liệu và thử một công nghệ. Việc nào cũng có giá trị, việc nào cũng dạy tôi một điều. Nhưng xong việc là tôi chuyển sang việc khác và gần như không bao giờ quay lại. Không có gì được tổng hợp hay đóng gói, nên cũng chẳng có gì thành tài sản.

Tôi đang tiêu thụ tri thức nhiều hơn là tích luỹ nó. Tôi vẫn học đều, chỉ chưa có cách nào giữ lại những gì đã học.

Lúc đầu tôi nghĩ đơn giản là mình lười ghi lại. Càng để ý, tôi càng thấy chuyện sâu hơn thế. Công việc có điểm kết thúc rõ ràng, task xong là xong. Tri thức thì chẳng bao giờ được đánh dấu là xong, nên nó cứ lơ lửng một thời gian rồi biến mất.

Chuyện thường được kể là Kurt Lewin và học trò của ông, Bluma Zeigarnik, để ý thấy người phục vụ ở một quán ăn tại Berlin nhớ rất kỹ những đơn chưa thanh toán, rồi quên gần như ngay khi khách trả tiền. Zeigarnik sau đó làm thí nghiệm và thấy người ta nhớ những việc bị bỏ dở tốt hơn những việc đã làm xong. Những năm ấy là cuối thập niên 1920.

Tôi nghĩ đầu óc mình cũng làm y như người phục vụ đó. Task đóng lại là một đơn đã thanh toán, và những gì học được trong lúc làm bị gạch đi cùng với nó. Cái cảm giác "xong rồi" dễ chịu ấy lại đúng là lúc tôi bắt đầu quên.

Mỗi lần định ghi lại, tôi lại phải nghĩ từ đầu: ghi gì, ghi kiểu gì, ghi cho ai. Quá nhiều quyết định nhỏ, và đầu óc chọn cách dễ hơn là bỏ qua. Việc ghi lại cũng không giúp task đang làm xong sớm hơn, nên lúc nào nó cũng bị xếp sau.

Người hay quên chìa khoá thường tự nhủ lần sau phải nhớ cho kỹ, rồi lần sau vẫn quên. Người hết quên thường là người đóng một cái móc ngay cạnh cửa. Trí nhớ của họ chẳng tốt hơn trước, chỉ là việc treo chìa khoá giờ không cần ai phải quyết định nữa. Chuyện ghi chép của tôi cũng vậy, vấn đề nằm ở hệ thống nhiều hơn là ở động lực hay kỷ luật.

Niklas Luhmann, một nhà xã hội học người Đức, giữ một hộp phiếu ghi chép suốt mấy chục năm, tới cuối đời có khoảng chín mươi nghìn tấm. Mỗi tấm ghi một ý, được đánh số và trỏ sang những tấm có liên quan. Ông viết khoảng bảy mươi cuốn sách, và có lần nói rằng ông không tự nghĩ hết mọi thứ, phần lớn việc nghĩ diễn ra trong cái hộp ấy.

Điều tôi để ý ở Luhmann là cái hộp không đòi ông phải có hứng. Mỗi tấm phiếu nhỏ tới mức viết xong trong vài phút, và chỗ của nó trong hộp đã có sẵn. Ông không phải quyết định lại từ đầu mỗi lần muốn ghi một điều gì.

Nhận ra những điều đó, tôi bắt đầu nhìn việc mình làm theo cách khác. Trước đây làm xong task là xong. Bây giờ làm xong task nghĩa là tôi vừa có thêm nguyên liệu, có thể là một insight, một cách giải quyết, hay một pattern dùng lại được. Nếu không giữ, vài tuần sau nó chỉ còn là một cảm giác mơ hồ rằng mình từng làm được việc này.

Nhiều nhà có một cuốn sổ chép tay công thức nấu ăn, mép giấy ố vàng, vài trang dính dầu mỡ. Người chép không định in nó thành sách. Họ chép để lần sau nấu món ấy không phải gọi điện hỏi lại ai, và nhờ thế cuốn sổ cứ dày dần qua nhiều năm.

Tôi cũng đổi lý do để viết. Trước đây cứ nghĩ tới chuyện viết là tôi thấy áp lực, viết có hay không, có ai đọc không. Bây giờ tôi viết để lần sau không phải nghĩ lại từ đầu. Mục tiêu thực dụng hơn thì việc viết nhẹ đi rất nhiều, và chia sẻ chỉ còn là chuyện đến sau.

Tôi không mong mọi thứ đổi ngay. Nếu giữ được thói quen này vài tháng, tôi hy vọng có một kho kiến thức của riêng mình, những vấn đề đã giải quyết không phải làm lại từ đầu, và cách nghĩ rõ hơn nhờ viết. Điều tôi muốn nhất là bắt đầu tích luỹ được từ những gì mình đã làm.

Tôi hình dung nó như một vòng quay: làm, ghi lại, lọc bớt, chia sẻ, rồi lặp lại. Làm mà không ghi thì những gì học được trôi đi. Ghi mà không lọc thì kho ghi chép nặng dần tới mức chẳng muốn mở ra, còn lọc xong mà chỉ giữ cho riêng mình thì nó khó lớn thêm.

Bài này cũng là một bước nhỏ trong vòng quay ấy. Viết xong, tôi đánh dấu nó là xong, một trong số ít lần tri thức của tôi được đánh dấu như vậy.

Lúc đầu tôi nghĩ giữ lại là để tích luỹ. Một thời gian sau tôi mới thấy, những điều cứ giữ khư khư cho mình thì không bao giờ thật sự sống. Nó giống nước, chảy thì trong, đứng lâu một chỗ thì đục. Kiến thức giữ quá lâu cũng vậy, càng để lâu càng nặng, mà chưa chắc đã sâu thêm chút nào.

Ai từng giảng bài cho một đứa em chắc đều nhớ cảm giác này. Bài toán mình làm được từ lâu, tưởng giảng năm phút là xong, vậy mà tới bước thứ ba thì đứng lại, vì đứa em hỏi "sao lại thế" và mình không trả lời được. Hoá ra mình biết làm, nhưng chưa biết vì sao.

Seneca từng viết trong một lá thư rằng người ta học được nhiều nhất là khi đi dạy. Đến khi bắt đầu chia sẻ, tôi mới thấm câu nói ấy. Tôi tưởng mình đang cho đi, rồi nhận ra mình đang hiểu lại. Lúc viết ra, những chỗ từng mơ hồ bắt đầu rõ nét, còn những chỗ tưởng đã hiểu thì hoá ra vẫn còn hổng, và phải đến tận khi viết xong, điều đó mới thực sự thành của mình.

Rào cản lớn nhất vẫn là câu "cái này đơn giản quá". Mất một thời gian tôi mới hiểu, câu nói ấy thực ra chỉ vạch ra khoảng cách của người đã đi trước, chứ chẳng nói lên việc kiến thức đó nông hay sâu. "Đơn giản" là cách nhìn của người đã biết. Người đã biết hay quên rằng mình từng không biết, vì chính sự hiểu đã xoá mất những chỗ vướng ban đầu.

Năm 1990, Elizabeth Newton, khi đó là nghiên cứu sinh ở Stanford, làm một thí nghiệm nhỏ. Một người gõ nhịp một bài hát quen thuộc lên mặt bàn, người kia đoán tên bài. Người gõ đoán khoảng một nửa số bài sẽ được nhận ra, còn thực tế thì chỉ ba trên một trăm hai mươi bài. Người gõ nghe cả giai điệu vang trong đầu mình, trong khi người nghe chỉ có tiếng cộc cộc trên bàn.

Trong kinh tế học và tâm lý học, người ta gọi đây là "lời nguyền của tri thức": khi đã biết rõ một điều, ta gần như quên mất cảm giác của chính mình lúc chưa hề biết đến nó. Cái "đơn giản quá" của tôi nhiều khi chỉ là giai điệu trong đầu người gõ.

Người địa phương chỉ đường cho khách lạ cũng hay vướng đúng chỗ ấy. "Cứ đi thẳng, tới chỗ cây xăng cũ thì rẽ trái", trong khi cây xăng đã dẹp từ mấy năm trước và chỉ người trong xóm còn nhớ. Với người lạ, câu chỉ đường được nói chậm và rõ từng ngã rẽ mới là thứ giúp họ tới nơi.

Với người chưa biết, cùng một điều ấy có thể là cánh cửa đầu tiên. Thứ họ cần thường chỉ là một điều thật, nói ra từ chỗ người viết đang đứng. Có khi chỉ một dòng suy nghĩ cũng mở ra cho ai đó một hướng đi.

Người ta hay nói về chuyện xây dựng cộng đồng như một chiến lược. Tôi lại thấy nó giống một xóm cũ hơn, nơi nhà này có rổ ổi chín thì mang sang nhà kia, nhà kia nấu nồi chè thì để phần một bát. Chẳng ai lên kế hoạch cho những lần qua lại ấy. Cái xóm thành hình từ những điều giản dị thế thôi: người ta cứ đều đặn chia nhau những thứ nhỏ nhặt mình đang có.

Trên mạng cũng vậy. Một cộng đồng thường hình thành quanh một người nói điều mình đang nghĩ, làm việc mình đang làm, và không cố tỏ ra hơn chính mình. Những người hợp nhau sẽ tự tìm đến. Thứ giữ họ ở lại là sự chân thật, chứ không phải vì người viết nói đúng hay sai.

Lão Tử viết rằng điều thiện cao nhất giống như nước. Nước làm lợi cho muôn vật mà không tranh giành, và chịu ở những chỗ thấp mà người ta không ưa. Tôi hay nghĩ tới câu ấy mỗi khi ngại đăng một bài vì sợ nó tầm thường, và thường thì sau đó tôi vẫn đăng.

Tôi cũng từng đợi đến lúc mình "đủ giỏi" mới dám chia sẻ. Nhưng cái mốc ấy chẳng bao giờ đến, vì cứ mỗi lần mình giỏi hơn một chút, thì giới hạn của chữ "đủ" lại tự động lùi xa thêm một đoạn. Thứ duy nhất tôi có là chỗ mình đang đứng, nên hôm nay biết gì thì nói điều đó, hiểu tới đâu thì viết tới đó.

Tôi cũng thôi nghĩ nhiều về số người đọc hay số người theo dõi. Những con số ấy đến sau. Điều tôi quan tâm là liệu mình có giữ được nhịp chảy ấy không, tuần này mình có viết ra được điều gì mới không. Mỗi lần chia sẻ là một lần mở ra một lối đi, cho người khác và cho cả chính mình.

Có những thứ càng giữ càng nặng, và kiến thức là một trong số đó. Tôi không cần thành ai khác mới có quyền chia sẻ. Nên hôm nay biết được điều gì, dù nhỏ, tôi viết nó ra, rồi bấm đăng trước khi kịp hỏi lại mình xem nó có đơn giản quá không.

Trên giấy, mọi thứ đều rõ ràng và hợp lý. Ngoài thực tế thì có chỗ không chạy, và có những chuyện chẳng cuốn sách nào nhắc tới. Lúc đó tôi mới thấy mình đã gọi chung hai thứ khác nhau bằng một chữ "hiểu".

Triết gia Gilbert Ryle từng tách bạch hai loại hiểu biết này từ giữa thế kỷ trước: "biết rằng" và "biết cách". Biết rằng muốn giữ thăng bằng trên xe đạp thì phải bẻ lái về phía mình sắp ngã là một chuyện. Đạp được xe là chuyện khác, và đứa trẻ tám tuổi đạp xe vòng quanh xóm vốn đang nắm giữ cái thứ hai, dù chẳng mảy may cần đến cái thứ nhất.

Tôi hay nghĩ về chuyện này bằng hình ảnh tấm bản đồ. Đọc giống như nhìn bản đồ, thấy được đường đi và toàn cảnh. Làm thì giống tự đi trên con đường ấy, với những đoạn vòng và những ngã rẽ bản đồ không vẽ. Người ở thành phố hay mưa đều biết, bản đồ chẳng bao giờ cho biết con hẻm nào ngập sau một trận mưa chiều.

Alfred Korzybski có một câu mà giới làm khoa học hay nhắc: bản đồ không phải là vùng đất. Nghe thì hiển nhiên tới mức hơi buồn cười. Có điều, khi đang cầm bản đồ trong tay, người ta rất dễ quên.

Cái khó là từ bên trong, hai kiểu hiểu ấy cho cùng một cảm giác. Đọc xong một bài về cách xử lý một lỗi, tôi thấy chắc chắn y như lúc đã tự tay xử lý nó. Chỉ khi đặt chân xuống đường tôi mới biết cảm giác nào có nền bên dưới.

Người xem nhiều video dạy bơi có thể giảng lại khá đúng cách thở, cách đạp chân. Xuống tới nước thì cơ thể không chịu nghe theo những gì cái đầu biết. Có những thứ chỉ học được sau vài ngụm nước, và nhiều lỗi trong code cũng thế, tôi phải gặp nó và sai với nó thì mới đi qua được.

Có lẽ vì vậy mà có người nói về nghề rất đúng nhưng làm thì lúng túng, còn có người ít nói mà làm rất chắc tay. Người thứ hai chưa chắc đã biết nhiều hơn. Họ đã đi qua nhiều đoạn đường hơn, và những đoạn đường ấy ở lại trong tay họ.

Làm thì chậm hơn đọc, và mệt hơn. Bù lại, những gì có được khi làm thường ở lại lâu. Mỗi lần debug một lỗi hay viết lại một đoạn code, ngoài việc xong việc, tôi còn có thêm một lớp hiểu mà lần sau gặp lại tôi nhận ra ngay.

Vương Dương Minh, một nhà Nho đời Minh, chủ trương "tri hành hợp nhất", biết và làm là một. Ông cho rằng biết mà không làm thì chỉ là chưa biết. Hồi đầu đọc, tôi thấy ý đó có phần cực đoan. Giờ thì ngẫm lại, tôi hiểu ông đang gọi tên cái cảm giác "tưởng mình đã biết" rất dễ nảy sinh sau mỗi lần đọc sách.

Đứng trước một thứ mới, tôi để ý mình hay muốn đọc thêm một bài, xem thêm một video nữa. Tôi đã học được rằng đó thường là lúc việc đọc đã đủ. Việc còn lại là mở editor ra và làm.

Có thể tôi sẽ làm sai, sẽ mất thêm thời gian. Đổi lại tôi có thứ mà việc đọc không cho được, là biết mọi thứ thật sự chạy ra sao. Kinh nghiệm dạy chậm và hơi khắt khe, nhưng những gì nó dạy thì thường đúng.

Tôi vẫn đọc, vẫn xem bản đồ trước khi đi. Chỉ là bây giờ xem xong thì tôi gấp nó lại, rồi bước ra đường.

"That is not a typo. We are at the dawn of something real — one person shipping at a scale that used to require a team of twenty."

gstack là bộ công cụ ông dùng để đạt được điều đó, và ông đã mã nguồn mở toàn bộ.

Ý tưởng cốt lõi: một đội ngũ, không phải một trợ lý

Cách dùng Claude Code thông thường coi AI như một trợ lý thụ động chờ lệnh. Khác biệt lớn nhất của gstack là nó mô hình hóa AI thành một đội ngũ chuyên biệt, mỗi vai trò rõ ràng:

• CEO (/plan-ceo-review): thách thức scope và giả định trước khi build
• Eng Manager (/plan-eng-review): khóa kiến trúc, data flow, test matrix
• Designer (/design-review, /design-consultation): phát hiện "AI slop" về mặt visual
• Staff Engineer (/review): code review cấp senior với auto-fix
• QA Lead (/qa): mở trình duyệt thật, click qua từng flow, tìm bug
• Release Engineer (/ship, /land-and-deploy): tạo PR, verify test coverage, deploy

Khi bạn có 10–15 phiên agent chạy song song, cấu trúc vai trò này là thứ ngăn mọi thứ khỏi trở thành hỗn loạn.

Triết lý đằng sau

Phần tôi thấy đáng đọc nhất trong repo là file ETHOS.md, bộ nguyên tắc được tự động inject vào mọi skill. Có hai nguyên tắc nổi bật.

Boil the Lake

Nguyên tắc đầu tiên: với AI, chi phí cận biên của sự hoàn chỉnh gần bằng không. Vì vậy, hãy luôn chọn giải pháp đầy đủ thay vì giải pháp "đủ dùng".

Nguyên tắc này dùng hình ảnh "lake vs ocean". Một cái hồ thì đun sôi được, như viết test 100%, implement đầy đủ edge case, xử lý hết error path. Một đại dương thì không, ví dụ viết lại toàn bộ hệ thống từ đầu. Nên cứ đun sôi hồ, đừng cố đun đại dương.

Có một bảng so sánh khá thú vị:

Nhìn bảng này thì quyết định "bỏ qua test vì tốn thời gian" không còn đứng được nữa. 10% cuối cùng mà các đội thường bỏ qua giờ chỉ tốn thêm vài phút.

Search Before Building

Nguyên tắc thứ hai: trước khi build bất cứ thứ gì, hãy tìm kiếm xem nó đã tồn tại chưa. Triết lý này chia nguồn kiến thức thành ba tầng:

• Tầng 1 (Tried and true): pattern chuẩn, cách tiếp cận đã được kiểm chứng. Rủi ro ở tầng này là bạn mặc định câu trả lời hiển nhiên luôn đúng.
• Tầng 2 (New and popular): best practice hiện tại, blog posts, xu hướng. Tìm kiếm, nhưng đọc có phê phán, vì đám đông có thể sai về những thứ mới cũng dễ như với thứ cũ.
• Tầng 3 (First principles): quan sát gốc rễ từ lý luận về bài toán cụ thể. Đây là loại kiến thức có giá trị nhất.

Mục tiêu của việc tìm kiếm là hiểu tại sao mọi người làm theo cách thông thường, rồi lý luận xem cách thông thường đó có thực sự đúng không, chứ không phải tìm code để copy.

Toàn bộ 25 skills

Bắt đầu từ đâu?

25 skills là nhiều, nhưng thực tế bạn chỉ cần 5 cái đầu tiên để thấy được giá trị ngay:

1. /office-hours: dùng trước khi bắt đầu bất kỳ feature nào. Nó sẽ reframe lại vấn đề theo cách bạn chưa nghĩ tới.
2. /plan-ceo-review + /plan-eng-review: chạy lần lượt để có một bản kế hoạch được thách thức cả về product lẫn kỹ thuật.
3. /review: chạy sau khi AI viết code xong, bước này không nên bỏ qua.
4. /ship: tạo PR kèm verify test coverage, thay thế hoàn toàn việc tự tạo PR thủ công.

Phần còn lại (/qa, /investigate, /benchmark...) thêm vào khi bạn đã quen với flow cơ bản.

Suy nghĩ của tôi

gstack và Superpowers đang giải quyết cùng một bài toán theo hai góc nhìn khác nhau. Superpowers tập trung vào kỷ luật quy trình, buộc agent đi từng bước có thứ tự. gstack tập trung vào cấu trúc vai trò, mỗi skill là một chuyên gia với góc nhìn riêng. Bạn hoàn toàn có thể dùng cả hai trên cùng một project: Superpowers để giữ agent đi đúng quy trình, gstack để gọi đúng chuyên gia vào đúng thời điểm.

Cái tôi thích nhất ở gstack là triết lý này thay đổi cách ra quyết định trước khi bạn mở terminal. Khi bảng tỉ lệ nén cho thấy viết test chỉ tốn 15 phút thay vì một ngày, lý do để bỏ qua nó biến mất hoàn toàn.

Garry Tan gọi đây là "live experiment" và muốn chia sẻ với cả thế giới. Tôi nghĩ việc chia sẻ đó quan trọng hơn con số 600,000 dòng code. Ông công khai mọi thứ để chứng minh rằng một kỷ nguyên mới đang thực sự bắt đầu.

Superpowers là một dự án mã nguồn mở giải quyết đúng vấn đề này. Nó cung cấp một bộ 14 "kỹ năng" (skills) có cấu trúc, buộc agent phải đi qua các bước bài bản trước khi chạm vào code.

Bộ quy trình 7 bước

Các skill trong Superpowers nối với nhau thành một quy trình, mỗi skill là một mắt xích:

1. Brainstorming: Trước khi làm bất cứ điều gì, agent phải hỏi, thảo luận, và đề xuất 2–3 hướng giải quyết để bạn chọn.
2. Using git worktrees: Tạo môi trường làm việc riêng biệt, tránh làm bẩn nhánh chính.
3. Writing plans: Lên kế hoạch chi tiết với các task nhỏ 2–5 phút, bao gồm đường dẫn file chính xác và bước kiểm tra.
4. Subagent-driven development: Triển khai bằng cách dispatch các subagent độc lập cho từng task, kèm review hai tầng.
5. Test-driven development: Bắt buộc theo chu trình RED–GREEN–REFACTOR, tức viết test trước rồi mới viết code.
6. Requesting code review: Review có hệ thống, phân loại mức độ nghiêm trọng của từng vấn đề.
7. Finishing development branch: Kiểm tra toàn bộ, dọn dẹp branch, đề xuất merge hoặc tạo PR.

Quy trình này là bắt buộc, agent không được bỏ qua bước nào.

Những chi tiết thú vị bên trong

Đọc kỹ từng skill thì tôi mới thấy từng quyết định thiết kế đã được nghĩ kỹ đến mức nào.

HARD-GATE trong Brainstorming

Skill brainstorming có một nguyên tắc cứng:

"Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity."

Và nó còn xử lý trực tiếp cái tâm lý "task này quá đơn giản, không cần design":

"Simple projects are where unexamined assumptions cause the most wasted work."

Quy trình brainstorming bao gồm 9 bước từ khám phá project context, hỏi từng câu một (không hỏi nhiều câu cùng lúc), đề xuất 2–3 hướng tiếp cận, trình bày design theo từng phần để lấy phê duyệt, viết spec document, cho subagent review spec, rồi mới chuyển sang lên kế hoạch. Agent chỉ được phép chuyển sang writing-plans sau khi bạn đã approve spec.

Iron Law trong Debugging

Skill systematic-debugging gọi nguyên tắc của nó là "Iron Law":

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

Quy trình debug được chia thành 4 phase: điều tra nguyên nhân gốc rễ, phân tích pattern, đặt giả thuyết và kiểm tra, rồi mới implement fix. Điểm hay nhất là phần xử lý "3+ lần fix thất bại":

"If 3+ fixes failed: Question the architecture — each fix reveals new shared state/coupling/problem in a different place. Stop and discuss with your human partner before attempting more fixes."

Đến lúc đó, skill này yêu cầu agent dừng lại và đặt câu hỏi về kiến trúc thay vì thêm fix thứ 4. Đọc là biết quy tắc này đến từ người đã debug nhiều.

Skill còn liệt kê các "red flag", tức những dấu hiệu cho thấy agent đang debug sai cách, ví dụ: "Quick fix for now, investigate later", "Just try changing X and see if it works", "I don't fully understand but this might work". Khi agent bắt đầu nghĩ như vậy, nó phải dừng lại và quay về Phase 1.

Kế hoạch viết cho người không biết gì

Skill writing-plans có một tiêu chuẩn rất cụ thể cho chất lượng của một bản kế hoạch:

"Clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow."

Mỗi task trong kế hoạch phải có đường dẫn file chính xác, code hoàn chỉnh (không phải "add validation" chung chung), lệnh chạy cụ thể kèm output mong đợi. Mỗi task chỉ làm một việc, theo đúng thứ tự: viết test, chạy test để xác nhận nó fail, viết code, chạy test để xác nhận nó pass, rồi commit.

Toàn bộ 14 skills

Triết lý đằng sau

Thứ Superpowers thêm vào cho agent là kỷ luật. Bốn nguyên tắc cốt lõi của dự án là: test trước code, có hệ thống thay vì tự phát, đơn giản là mục tiêu hàng đầu, và bằng chứng thay vì tuyên bố.

Tôi thấy triết lý này quen thuộc, vì một senior developer có kinh nghiệm vẫn làm đúng như vậy theo thói quen. Superpowers chỉ đang encode những thói quen đó thành các rule để agent không được phép bỏ qua.

Có một câu trong README mà tôi thích: "It's not uncommon for Claude to be able to work autonomously for a couple hours at a time without deviating from the plan." Theo tôi, agent làm được vậy là nhờ có một bản đồ rõ ràng để đi theo.

Sau một thời gian sử dụng Gmail SMTP để gửi email cho các hệ thống, nay mình quyết định chuyển sang sử dụng AWS SES.

Mình cũng cân nhắc lựa chọn khác là SendGrid, tuy nhiên vì vấn đề giá nên mình đã quyết định sử dụng SES.

Cài đặt

1. Kích hoạt SES

Trước hết chúng ta sẽ vào AWS Console → SES để thiết lập. Chú ý là chọn khu vực (region) muốn sử dụng, ở đây mình chọn ap-southeast-1.

Quá trình thiết lập khá dễ dàng, chỉ cần thực hiện theo các bước. Mình sẽ cần cung cấp 1 email và một domain.

Sau khi quá trình thiết lập hoàn tất thì AWS show cho chúng ta các bước phải làm tiếp theo:

1. Xác minh email: chỉ cần check email và click và link để xác minh
2. Xác minh domain: AWS sẽ show cho chúng ta các bản ghi DNS, chúng ta copy sang domain provider là được, sẽ mất vài phút để việc xác minh được hoàn tất.

Ban đầu, tài khoản SES thường ở sandbox mode, chỉ gửi được tới các địa chỉ đã xác minh. Sau quá trình testing, chúng ta có thể gửi yêu cầu "Production access" trong phần Account dashboard → Sending limits để gỡ giới hạn này.

2. Tạo IAM Policy và Access Key

Bây giờ chúng ta cần tạo một user và tạo một cặp key để sử dụng trong app của chúng ta.

1. Vào IAM → Users → Create user.

2. Gán policy sau cho user: đoạn này mình muốn tìm policy có sẵn chỉ cung cấp quyền gửi email và lấy dữ liệu thống kê email, tuy nhiên mình không tìm thấy policy như vậy. Nên mình đã tạo một policy mới:

   json

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "ses:SendEmail",
           "ses:SendRawEmail",
           "ses:GetSendQuota",
           "ses:GetSendStatistics"
         ],
         "Resource": "*"
       }
     ]
   }

   Nếu muốn chặt hơn, có thể thay "Resource": "*" bằng ARN của identity (domain hoặc email) đã xác minh.

3. Sau khi tạo user, chọn Security credentials → Create access key. Lưu lại Access Key ID và Secret Access Key, cặp thông tin chúng ta sẽ dùng trong ứng dụng.

Triển khai

Cài đặt AWS SDK

npm install @aws-sdk/client-ses

Tạo module gửi email

import { SESClient, SendEmailCommand } from "@aws-sdk/client-ses";

// SDK tự đọc AWS_ACCESS_KEY_ID và AWS_SECRET_ACCESS_KEY từ biến môi trường
const ses = new SESClient({ region: "ap-southeast-1" });

export async function sendEmail({ to, subject, html }) {
  const params = {
    Source: "noreply@myapp.com",
    Destination: {
      ToAddresses: [to],
    },
    Message: {
      Subject: { Data: subject },
      Body: { Html: { Data: html } },
    },
  };

  try {
    await ses.send(new SendEmailCommand(params));
    console.log("✅ Email sent to", to);
  } catch (err) {
    console.error("❌ Email send failed:", err);
    throw err;
  }
}

Mình throw lại lỗi sau khi log để nơi gọi biết là gửi thất bại, thay vì lặng lẽ bỏ qua.

Gọi trong ứng dụng

await sendEmail({
  to: "user@example.com",
  subject: "Welcome to MyApp!",
  html: "<h1>Hello 👋</h1><p>Thanks for joining!</p>",
});

Kết luận

AWS SES cài đặt ban đầu phức tạp hơn một chút, đặc biệt là ở bước xác minh domain và cấu hình DNS. Bù lại, SES đáng tin cậy, chi phí thấp và mở rộng tốt.

Có khá nhiều tình huống mình cần format json trên console cho dễ đọc. Một trong những ví dụ cụ thể là muốn xem api response được trả ra bởi curl.

Phương án

Nếu đã có nodejs, có thể sử dụng một dòng này:

alias jsp="node -e 'let s=\"\"; process.stdin.on(\"data\", (c) => s += c).on(\"end\", () => console.log(JSON.stringify(JSON.parse(s), null, 2)));'"

Alias gom hết input rồi mới parse. Với response lớn, stdin đến thành nhiều khúc, nếu parse ngay từng khúc thì sẽ gặp lỗi SyntaxError. Sau đó chúng ta có thể gọi

echo '{"a": 1}' | jsp

curl -s http://localhost:3000/api/v1/projects | jsp

Nếu không có nodejs thì macOS có sẵn python:

curl -s http://localhost:3000/api/v1/projects | python3 -m json.tool

Ngoài ra mình cũng dùng fx, một công cụ chuyên cho việc này của tác giả Anton Medvedev https://fx.wtf/. Có điều fx không cho copy json content, nên mình gặp vướng khi dùng nó.

Mình đang sử dụng khá nhiều tài khoản git, cả github và gitlab. Cá nhân mình cũng có nhiều profile, và cũng có profile riêng cho công việc ở công ty. Trong quá trình làm việc có một số rắc rối như sau:

• Mỗi lần chuyển repo là phải remove ssh key để add lại cho đúng
• Với các project mới cần phải thiết lập lại user.name và user.email cho đúng với tài khoản

Mình muốn mọi thứ tự động: repo nào thì dùng đúng key và đúng tên/email tương ứng, không cần nhớ hay đổi tay nữa.

Giải pháp

1. Sử dụng SSH config: host match

SSH hỗ trợ config ssh key theo từng host, nếu chỉ có 2 tài khoản ở hai host khác nhau thì chỉ cần thiết lập host là đáp ứng được yêu cầu:

Match Host github.com
  IdentityFile ~/.ssh/id_rsa_github
  IdentitiesOnly yes

Match Host gitlab.com
  IdentityFile ~/.ssh/id_rsa_gitlab
  IdentitiesOnly yes

2. Sử dụng SSH config: host alias

Trong trường hợp có nhiều tài khoản của cùng một host thì phương án trên không khả thi, mình cần sử dụng phương án mới: host alias.

# Tài khoản cá nhân
Host github-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_personal
  IdentitiesOnly yes

# Tài khoản công ty
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_work
  IdentitiesOnly yes

Sau đó mình sẽ clone git về với alias host github-personal, github-work thay vì github.com

# Repo công ty
git clone git@github-work:company/project.git

# Repo cá nhân
git clone git@github-personal:me/my-repo.git

SSH sau đó sẽ tự động chọn ssh key dựa trên host mình đã đặt.

3. Sử dụng SSH config: custom match

Với phương án trên vấn đề được giải quyết ổn thoả, tuy nhiên dần dần mình cảm thấy phiền với việc phải đổi host cho remote url. Mình chuyển qua sử dụng phương án mới:

Match Exec "[[ $(git config --get remote.origin.url) =~ .*git@github.com:my-username.* ]]"
  IdentityFile ~/.ssh/hailerity_rsa
  IdentitiesOnly yes

Trên đây sử dụng Match Exec để thực hiện câu lệnh check xem git remote url khớp với một tài khoản không, nếu khớp sẽ dùng ssh key tương ứng, không khớp sẽ bỏ qua.

Cách này rất linh hoạt, và không cần phải đổi remote url host. Tuy nhiên có một hạn chế với phương án này là không thể áp dụng cho câu lệnh git clone: lúc clone, repo chưa tồn tại nên git config --get remote.origin.url chưa trả về gì. Mục 5 bên dưới giải quyết hạn chế này.

4. Sử dụng Git config để tự chọn user/email

Sau nhiều lần commit project dùng sai user.name và user.email, mình tìm cách thiết lập để tránh sai lầm đó.

Git có hỗ trợ set config file theo điều kiện trong ~/.gitconfig:

[user]
  name = Tram Dev
  email = gactram@tramdev.io

[includeIf "gitdir:~/Workspaces/personal/**"]
  path = ~/Workspaces/personal/.gitconfig

[includeIf "gitdir:~/Workspaces/work/**"]
  path = ~/Workspaces/work/.gitconfig

Với config trên, các project ở trong ~/Workspaces/personal sẽ sử dụng file gitconfig ở trong thư mục đó, tương tự với ~/Workspaces/work. Như vậy mình chỉ cần viết .gitconfig cho từng thư mục và đặt project vào đúng thư mục là được.

Ví dụ ~/Workspaces/work/.gitconfig:

[user]
  name = Tram Dev
  email = tramdev@congty.com

5. Gộp SSH key vào Git config theo thư mục

Mục 4 đã chọn đúng user/email theo thư mục. Git cũng có core.sshCommand để chỉ định lệnh SSH, nên mình đặt luôn SSH key vào cùng file .gitconfig của thư mục đó:

# ~/Workspaces/work/.gitconfig
[user]
  name = Tram Dev
  email = tramdev@congty.com

[core]
  sshCommand = ssh -i ~/.ssh/id_ed25519_work -o IdentitiesOnly=yes

# ~/Workspaces/personal/.gitconfig
[user]
  name = Tram Dev
  email = gactram@tramdev.io

[core]
  sshCommand = ssh -i ~/.ssh/id_ed25519_personal -o IdentitiesOnly=yes

Bây giờ key và email cùng đi theo thư mục. Repo nằm trong ~/Workspaces/work dùng key công ty, repo trong ~/Workspaces/personal dùng key cá nhân, remote url vẫn giữ nguyên git@github.com:.... Cách này thay được cả mục 2 và mục 3.

Điều mình quan tâm nhất là git clone có dùng đúng key không. Với git 2.50, includeIf "gitdir:..." được áp dụng ngay trong lúc clone nếu thư mục đích nằm trong ~/Workspaces/work, nên lệnh clone dùng đúng core.sshCommand của thư mục đó:

cd ~/Workspaces/work
git clone git@github.com:company/project.git

Để chắc chắn trên máy của bạn, bật GIT_TRACE khi clone. Git in ra lệnh SSH thực sự được chạy, trong đó có đường dẫn key:

cd ~/Workspaces/work
GIT_TRACE=1 git clone git@github.com:company/project.git 2>&1 | grep run_command
# trace: run_command: ... ssh -i ~/.ssh/id_ed25519_work -o IdentitiesOnly=yes ... git@github.com

Hoặc kiểm tra repo đã clone đang nhận cấu hình nào:

cd ~/Workspaces/work/project
git config --show-origin core.sshCommand

Nếu dùng phiên bản git cũ hơn mà clone không nhận cấu hình, có thể chỉ định key ngay trong lệnh clone. Option -c cũng được ghi vào config của repo mới, nên các lần pull/push sau vẫn dùng đúng key:

git clone -c core.sshCommand="ssh -i ~/.ssh/id_ed25519_work -o IdentitiesOnly=yes" \
  git@github.com:company/project.git

Nếu tạo key mới, mình dùng Ed25519 thay cho RSA vì key ngắn hơn và được GitHub, GitLab hỗ trợ đầy đủ:

ssh-keygen -t ed25519 -C "tramdev@congty.com" -f ~/.ssh/id_ed25519_work

Có thể bạn đã để ý, email liên hệ của Trạm Dev là gocua@tramdev.io. Thông thường để có một email như vậy thì có thể trả vài đô để dùng Google Workspace. Tuy nhiên, phương án đó xem chừng hơi đao to búa lớn so với một blog còn đang xếp từng viên gạch. Sau khi tìm hiểu qua, mình xác định thực hiện phương án sử dụng dịch vụ miễn phí quen thuộc: Cloudflare và Gmail.

Sơ lược bài toán: bạn sở hữu một domain, ví dụ mydomain.com, và bạn muốn sử dụng email với domain của mình, chẳng hạn hello@mydomain.com, để nhận và gửi email, và bạn cần một phương án đơn giản, không mất phí.

Phương án

Trước hết mình sẽ muốn sử dụng gmail để nhận và gửi email, lý do đơn giản, mình đã quá quen thuộc với gmail rồi.

Vấn đề đầu tiên, mình sẽ cần thiết lập để khi người khác gửi email vào hello@mydomain.com thì mình sẽ nhận được trong gmail của mình, chẳng hạn mình có tài khoản gmail là myemail@gmail.com. Vấn đề này mình sẽ sử dụng tính năng Email routing của Cloudflare.

Vấn đề tiếp theo là cho phép gửi email từ gmail với tư cách của hello@mydomain.com. Cái này thì gmail cũng đã hỗ trợ, mình chỉ cần thiết lập là được.

Triển khai

Thiết lập trong cloudflare

Trước hết, domain của bạn cần setup để chuyển sang sử dụng DNS của Cloudflare. Sau khi setup xong, Cloudflare sẽ tạo sẵn cho mình các bản ghi MX, và TXT phục vụ cho việc nhận gửi email. Đoạn này nếu bạn nào chưa sử dụng Cloudflare thì sẽ cần tìm hiểu cách trỏ domain sang Cloudflare.

Tiếp theo mình sẽ vào mục Email > Email Routing. Chuyển sang tab Routing rules. Ở đây mình sẽ thấy danh sách các email đã được thiết lập.

Click vào Create address để thêm email mới, sau đó bạn nhập email custom và gmail của bạn vào. Save là xong.

Bây giờ bạn có thể gửi thử một email tới hello@mydomain.com rồi vào gmail để kiểm tra xem nó có xuất hiện ở trong gmail của bạn hay không. Trong trường hợp không nhận được thì có gì đó sai sai rồi.

Sau khi chắc chắn là bạn đã nhận được email thì chuyển qua bước tiếp theo.

Tạo App password

Quá trình thiết lập tiếp theo sẽ cần sử dụng đến App password, vì Gmail không cho sử dụng trực tiếp password của tài khoản gmail.

Bạn click vào avatar tài khoản Gmail, rồi click Manage your Google Account để vào phần quản lý. Hoặc vào link https://myaccount.google.com/. Bạn search App passwords trên thanh search để tìm đến tính năng App passwords.

Ở đây bạn nhập một cái tên cho password sẽ tạo rồi nhấn Create. Nó sẽ hiện ra cho bạn một password. Hãy copy nó để tạm đâu đó rồi chuyển sang bước tiếp theo. Sau khi đã xong bước tiếp theo, bạn có thể xóa bản copy tạm đó đi, không cần lưu lại. Lưu ý là đừng xóa app password trong Google Account, vì Gmail cần nó để gửi email.

Thiết lập trong gmail

Bạn vào tài khoản gmail. Vào Settings. Vào tab Accounts and Import. Kéo xuống mục Send mail as: và click vào Add another email address. Một popup sẽ hiện lên và bạn sẽ nhập thông tin domain của bạn vào:

Đoạn này bạn bỏ tick Treat as alias nhé. Lý do tại sao thì bạn có thể click vào Learn more để đọc.

Click Next step. Tiếp theo bạn nhập thông tin về tài khoản gmail của bạn như trên ảnh.

Thông tin:

• SMTP Server: smtp.gmail.com
• Port: 587
• Username: là username tài khoản gmail của bạn
• Password: chính là app password đã tạo ở bước trên, bạn hãy paste vào đây

Chú ý: ô Username bạn chỉ nhập username thôi nhé, không nhập phần @gmail.com

Click Add Account, gmail sẽ kiểm tra xác thực và thông báo thành công nếu không có gì bất thường. Sau đó gmail sẽ gửi một email xác thực tới hello@mydomain.com. Lúc này bạn chỉ cần vào Inbox của gmail, mở email vừa nhận được và click vào link xác thực là xong.

Cập nhật SPF trong cloudflare

Đến đây đã gửi được email, nhưng email gửi đi rất dễ bị đánh dấu spam. Lý do là bản ghi SPF mà Cloudflare tạo cho Email routing chỉ cho phép máy chủ của Cloudflare, trong khi email bây giờ được gửi đi từ máy chủ của Google.

Vào DNS > Records, tìm bản ghi TXT bắt đầu bằng v=spf1 và thêm include:_spf.google.com vào trước ~all:

v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com ~all

Chú ý là sửa bản ghi đang có, không tạo thêm bản ghi SPF thứ hai, vì mỗi domain chỉ được có một bản ghi SPF.

Để kiểm tra, gửi thử một email từ hello@mydomain.com tới một tài khoản gmail khác, mở email đó, chọn Show original và xem dòng SPF có báo PASS hay không.

Kết quả

Bây giờ mình đã có email xịn xò để sử dụng hello@mydomain.com. Việc đọc email và gửi email sẽ được thực hiện bằng tài khoản gmail quen thuộc.

Bạn có thể thực hiện tương tự để tạo nhiều email custom (xinchao@mydomain.com, hola@mydomain.com, ..) cùng forward về một tài khoản gmail, hoặc về các tài khoản gmail khác nhau.

Một chút lưu ý khi gửi email đi là bạn sẽ cần xác định đúng tài khoản email dùng để gửi đi trong trường hợp bạn đã thêm nhiều tài khoản email. Gmail cũng có phần thiết lập này bạn có thể cài theo mục đích sử dụng của mình:

Một chi tiết nhỏ: ngay sau khi nâng cấp, Copilot Chat trong VS Code ngừng hoạt động với lỗi Copilot took too long to get ready. Please review the guidance in the Chat view. Đăng xuất rồi đăng nhập lại tài khoản GitHub trong VS Code là Chat chạy lại.

Nhìn lại chặng đường từ đó, tôi thấy mình đã đi qua bốn cấp độ, theo dòng phát triển của AI và theo kinh nghiệm của chính tôi với AI. Mỗi cấp là một mức tin tưởng: tôi giao cho Copilot bao nhiêu, và tôi phải kiểm tra lại bao nhiêu.

Level 1 - Hỏi đáp kỹ thuật

Tôi dùng Copilot như việc sử dụng Google trong những năm về trước. Gặp khúc mắc về syntax, thư viện, hay cách triển khai một logic, đặt một câu hỏi và Copilot sẽ đưa ra câu trả lời nhanh chóng. Vẫn cần xác minh lại câu trả lời hoặc chất vấn thêm, nhưng so với việc lướt qua 10 kết quả của Google thì Copilot nhanh hơn rất nhiều.

Level 2 - Viết function/script ngắn

Ở cấp này tôi bắt đầu "giao việc" cho AI. Với những logic độc lập và ít dính tới nghiệp vụ, tôi viết prompt và để Copilot viết. Nhận kết quả, tôi đọc để hiểu cách triển khai, phát hiện những điểm bất thường, rồi tinh chỉnh lại theo phong cách code của mình.

Level 3 - Tham gia vào dự án thật

Lúc này Copilot trở thành "đồng đội" trong project. Tôi yêu cầu nó fix bug, refactor code, hoặc implement một tính năng nhỏ. Copilot đã ở ngay trong dự án nên tôi không còn phải copy/paste code qua lại nữa.

Level 4 - Viết nguyên một dự án từ đầu

Khi cảm nhận được sức mạnh của Copilot, tôi bắt đầu một số dự án mới từ đầu và giao cho Copilot thực hiện toàn bộ. Công việc của tôi gần như chỉ còn là viết yêu cầu và kiểm tra kết quả.

Tôi đã xây dựng một web app hoàn toàn bằng Copilot, và dựng một project quản lý hạ tầng dùng Docker Swarm cùng các dịch vụ chạy trên đó như Traefik, Prometheus, Grafana. Có những khoảnh khắc thực sự wow, nhưng cũng có những tình huống ức chế.

Cấu trúc dự án rất tốt, làm theo đúng quy chuẩn, không có gì phải lăn tăn. Giao diện thì quá xịn, có lẽ đây là việc coding agent đang làm tốt nhất. Logic khá tốt, nhưng có những vấn đề nó bế tắc và mãi không giải quyết được. Những lúc đó tôi buộc phải nhảy vào tìm hiểu và đề xuất giải pháp cho nó.

Model quyết định cấp độ

Hai dự án trên tôi dùng Claude Sonnet 4, và kết quả khá bất ngờ, tốt hơn hẳn thời điểm tôi dùng bản miễn phí để làm blog này. Khi hết premium requests, tôi chuyển sang GPT-4.1 và thấy rõ sự khác biệt. Nếu ví Sonnet 4 như một senior developer thì GPT-4.1 chỉ như một middle developer.

Cùng một công cụ, cùng một cách làm việc, nhưng cấp độ tôi dám giao việc phụ thuộc vào model đang chạy bên dưới. Lên được Level 4 với model này không có nghĩa là sẽ giữ được Level 4 với model khác.

Làm việc với một cộng sự

Từ Level 3 trở đi, tôi bắt đầu xem coding agent như một cộng sự. Tùy model và tùy bài toán, cộng sự đó có thể là một senior hoặc một junior. Khi đã xem nó như một người thật, tôi chấp nhận rằng:

• Nó cần được chỉ dẫn cụ thể phải làm gì.
• Đôi khi nó code sai so với yêu cầu.
• Đôi khi nó tư duy lòng vòng và không tìm được giải pháp tối ưu.
• Đôi khi nó để lại bug.
• Không thể kỳ vọng nó luôn được việc, vì đôi khi nó là senior, đôi khi là junior.
• Luôn nghi ngờ kết quả của nó.

Từ đó tôi đặt ra vài nguyên tắc làm việc với coding agent:

• Mô tả yêu cầu đầy đủ, chi tiết nhất có thể.
• Thực hành pair programming.
• Luôn review code và đánh giá những thay đổi mới tác động đến hệ thống hiện tại như thế nào.
• Giải thích và đề xuất giải pháp cho những vấn đề mà coding agent gặp khó khăn.

Tôi đang dừng ở đâu

Dù thấy coding agent làm chủ được một dự án hoàn toàn mới, đó vẫn là những dự án tương đối nhỏ. Với những dự án lớn hơn, hoặc khi nghiệp vụ nhiều hơn và phức tạp dần theo thời gian, tôi chưa thực sự yên tâm đặt niềm tin vào nó. Tôi đang ở Level 4 cho dự án nhỏ, và vẫn ở Level 3 cho mọi thứ còn lại.

Nhưng tôi tin nghề viết code sẽ thay đổi hoàn toàn. Coding agent sẽ trở thành công cụ không thể thiếu với developer, như framework hay IDE bây giờ. Đến lúc đó gọi nó là cộng sự thì đúng hơn, và một developer có thể có rất nhiều cộng sự là AI agent.

Thay vì cặm cụi viết từng dòng lệnh, công việc chính của developer sẽ giống một "nhạc trưởng": điều phối các agent bằng ý tưởng tổng thể, bài toán và những giới hạn cần giải quyết. Những nguyên tắc ở trên (mô tả yêu cầu cho rõ, review mọi thay đổi, nhảy vào khi agent bế tắc) chính là phần việc đó. Ngoài viết code, kỹ sư phần mềm sẽ cần thêm tư duy hệ thống, am hiểu nghiệp vụ và khả năng đặc tả yêu cầu cho AI. Dùng thành thạo các công cụ AI sẽ trở thành một kỹ năng căn bản.

Ai từng học triết ở trường chắc còn nhớ câu "lượng đổi thì chất đổi". Lúc học, câu ấy nghe khô và xa, giống một dòng phải thuộc để đi thi. Với người viết code, nó lại hiện ra khá cụ thể. Có một ngày người ta đọc một đoạn code lạ và hiểu nó định làm gì trước khi đọc hết, mà không chỉ ra được mình học điều đó từ lúc nào.

Từ hồi mới học lập trình, tôi có thói quen gặp đoạn code nào trong sách hay bài hướng dẫn là gõ lại ngay. Ban đầu thì nhìn mà chép. Sau đó chạy thử, sửa một chỗ, chạy lại xem kết quả đổi ra sao, rồi sửa chỗ khác. Đến khi thấy đã thấm, tôi xoá hết và viết lại từ đầu mà không nhìn mẫu.

Trẻ con tập viết cũng đi đúng con đường ấy. Lúc đầu tô theo nét chấm, rồi chép theo chữ mẫu, rồi tới một ngày viết được chữ của riêng mình, hơi nghiêng và hơi xấu. Không ai giảng được cho bàn tay một nét chữ. Bàn tay phải viết đủ nhiều cho tới khi nó tự biết.

Sách Luận Ngữ mở đầu bằng câu "Học nhi thời tập chi, bất diệc duyệt hồ", học rồi thường xuyên luyện tập, chẳng vui lắm sao. Tôi để ý chữ "tập" đứng ngay sau chữ "học". Tôi đọc nó như thể học mà chưa tập thì việc học vẫn chưa xong.

Khi gặp một bài toán, tôi chỉ dành vừa đủ thời gian để nghĩ ra một giải pháp tạm ổn, rồi bắt tay vào viết. Giải pháp đầu tiên ít khi là giải pháp tốt nhất. Có điều, phải viết thì tôi mới gặp những chỗ lúc nghĩ chưa thấy, và mới biết giả định nào của mình hoá ra sai. Dòng code đầu tiên dẫn tới mười dòng tiếp theo, và mười dòng ấy thường quay lại cho tôi biết dòng đầu tiên nên viết khác đi thế nào.

Người học đi xe đạp ngã nhiều lần trước khi giữ được thăng bằng, và chẳng ai coi những cú ngã đó là thời gian phí. Bug với tôi cũng vậy. Có viết thì mới có bug, và mỗi lần lần ra một bug là một lần tôi hiểu thêm về cái hệ thống mình tưởng đã hiểu. Tôi ngờ rằng thứ tích lại sau một triệu dòng code chủ yếu là những lần như thế.

Gladwell lấy con số 10.000 giờ từ nghiên cứu của Anders Ericsson về những người chơi violin. Về sau chính Ericsson nói con số ấy bị hiểu sai. Điều ông quan sát được là luyện tập có chủ đích, mỗi buổi nhắm vào một chỗ còn yếu, và số giờ chỉ là thứ đi kèm.

Tôi nghĩ dòng code cũng thế. Một triệu dòng gõ cho xong việc có lẽ chẳng dạy được bao nhiêu. Thói quen sửa một chỗ rồi chạy lại xem điều gì thay đổi, nhìn lại thì, gần với kiểu luyện tập Ericsson nói tới hơn tôi tưởng. Lượng vẫn cần, chỉ là phải là lượng mà mình có nhìn vào.

Có viết thì mới có code dở, và phải có code dở thì sau này mới có code tốt hơn. Người nấu ăn lâu năm hẳn cũng từng làm hỏng không ít nồi canh, mặn quá hoặc nhạt quá, trước khi nêm được bằng cảm giác. Những nồi canh hỏng ấy chẳng ai còn nhớ, nhưng cái lưỡi thì nhớ.

Làm nghề này đủ lâu, ai cũng có lúc mở lại code của mình từ vài năm trước và lẩm bẩm "hồi đó code ngu thật". Để thấy đoạn code cũ dở, mình phải đứng ở một chỗ khác với lúc viết ra nó. Nên mỗi lần lẩm bẩm câu đó, tôi thấy ngượng thì ít mà vui thì nhiều, vì nó cho tôi biết mình đã đi được một đoạn kể từ hôm viết những dòng ấy.

Như đã kể lần trước, mình đã chạy một proxy server trên con EC2 để truy cập được vào Google Stitch. Tiện thể mình cũng dùng để truy cập Telegram luôn.

Nhưng mình gặp một vấn đề. Với cách thiết lập proxy cũ cho máy Mac, tất cả các request đều được proxied. Đó là điều không hay cho lắm. Một số ứng dụng bắt đầu gửi cảnh báo về hành vi bất thường, cụ thể là có người truy cập từ Singapore.

Mình hỏi Github Copilot để tìm cách thiết lập proxy cho một số domain nhất định mà thôi. Và phương án được đưa ra là sử dụng file PAC (Proxy Auto-Configuration).

File PAC

File PAC là một file JavaScript có một hàm FindProxyForURL. Trình duyệt gọi hàm này cho mỗi request, và hàm trả về đi qua proxy nào hoặc đi thẳng (DIRECT).

Dưới đây là một file mẫu: chỉ Telegram và Stitch đi qua proxy, còn lại đi thẳng. Thay <ip-ec2> bằng IP của server chạy proxy, và thêm bớt domain theo nhu cầu.

// proxy.pac
function FindProxyForURL(url, host) {
  var proxied = ['telegram.org', 't.me', 'stitch.withgoogle.com'];
  for (var i = 0; i < proxied.length; i++) {
    if (host === proxied[i] || dnsDomainIs(host, '.' + proxied[i])) {
      return 'PROXY <ip-ec2>:3128';
    }
  }
  return 'DIRECT';
}

dnsDomainIs(host, '.telegram.org') khớp với mọi subdomain như web.telegram.org, còn host === 'telegram.org' khớp với chính domain đó.

File PAC không chứa được username và password. Nếu proxy có xác thực, trình duyệt sẽ tự hỏi tài khoản ở lần đầu đi qua proxy.

Serve file PAC qua HTTP

Đây là chỗ mình mất hơn một tiếng. Lúc đầu mình khai báo đường dẫn tới file trên máy, file:///Users/me/proxy.pac, và Chrome không hề nhận proxy config. Trên các bản macOS gần đây, cấu hình PAC bằng đường dẫn file:// không được hỗ trợ, nên phải serve file qua HTTP.

Mình chạy một static server ngay trong thư mục chứa file PAC:

npx http-server -p 4040

Kiểm tra file đã được serve:

curl http://127.0.0.1:4040/proxy.pac

Server này cần chạy mỗi khi dùng proxy. Nếu tắt nó đi, macOS không lấy được file PAC.

Khai báo trong macOS

Vào System Settings → Network → (Wi-Fi hoặc Ethernet) → Details → Proxies, bật Automatic proxy configuration và điền URL:

http://127.0.0.1:4040/proxy.pac

Bấm OK để lưu.

Khởi động lại Chrome

Sau khi đổi sang URL HTTP, mình vẫn chưa thấy Chrome dùng proxy ngay. Mình đoán là do chưa khởi động lại Chrome sau khi đổi cấu hình. Vì vậy sau mỗi lần đổi URL file PAC, mình thoát hẳn Chrome (Cmd + Q) rồi mở lại. Khi đã nhận cấu hình, Chrome hỏi tài khoản proxy ở lần đầu vào Telegram, nhập xong là vào được.

Muốn xem Chrome đang dùng cấu hình proxy nào, mở chrome://net-internals/#proxy. Trang này cũng có nút Re-apply settings để Chrome đọc lại cấu hình mà không cần khởi động lại.

Lần đầu mình tưởng thành công là do may, vì Chrome bỗng dưng hỏi tài khoản trong lúc mình đang đọc tài liệu. Kiểm tra lại mới thấy nguyên nhân chính nằm ở đường dẫn file PAC: đổi từ file:// sang URL HTTP thì Chrome mới nhận cấu hình.

Lưu ý

• Cấu hình PAC áp dụng cho các ứng dụng dùng proxy hệ thống như Chrome, Safari. Lệnh trong terminal như curl không đọc file PAC; muốn đi qua proxy thì đặt https_proxy cho lệnh đó.
• Ứng dụng Telegram cho desktop có phần cài proxy riêng trong Settings → Advanced → Connection type, không dùng file PAC.

Mình nghĩ đến proxy. Tuy nhiên hiện tại mình đang không dùng công cụ proxy nào. Cơ bản mình cũng không thích dùng proxy. Để kiểm chứng việc dùng proxy có thể vào được Stitch, mình nhờ một đứa em kiểm tra, và đúng là có vào được sau khi thiết lập proxy. Mình quyết định tự tạo proxy server để dùng thay vì cài công cụ.

Giải pháp của mình là chạy một proxy server (forward proxy) trên một con server nằm ở nước ngoài. Hiện tại mình đang có một con EC2 nằm ở Singapore. Còn phần mềm proxy, sau khi cân nhắc mình quyết định sử dụng squid.

Quá trình thiết lập cũng khá đơn giản. Đầu tiên là chạy và thiết lập squid. Mình chọn docker để chạy vì đã có sẵn docker trên server rồi. Và đây là câu lệnh mình dùng để chạy squid:

docker run --name squid -d --restart=always \
  --publish 3128:3128 \
  --volume ./squid.conf:/etc/squid/squid.conf \
  --volume ./passwords:/etc/squid/passwords \
  --volume /srv/docker/squid/cache:/var/spool/squid \
  sameersbn/squid:3.5.27-2

Lệnh trên mount hai file từ thư mục hiện tại: squid.conf là cấu hình của squid, passwords là danh sách tài khoản được phép dùng proxy. Proxy mở trên Internet mà không có xác thực sẽ bị người khác dùng ké rất nhanh, nên mình bật xác thực ngay từ đầu.

Dưới đây là một squid.conf tối thiểu có xác thực:

# squid.conf
http_port 3128

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic realm proxy
acl authenticated proxy_auth REQUIRED

http_access allow authenticated
http_access deny all

Đường dẫn tới basic_ncsa_auth có thể khác tuỳ image. Nếu squid không khởi động được, kiểm tra đường dẫn đúng trong container:

docker exec squid sh -c 'ls /usr/lib/squid*/basic_ncsa_auth'

File passwords tạo bằng htpasswd, có trong gói apache2-utils trên Ubuntu:

sudo apt install apache2-utils
htpasswd -c passwords <ten-dang-nhap>

Lệnh sẽ hỏi mật khẩu rồi ghi vào file. Sau khi sửa squid.conf hoặc passwords, chạy docker restart squid để squid đọc lại.

Cuối cùng, mở cổng 3128 trong Security Group của EC2, và chỉ mở cho IP của mình thay vì 0.0.0.0/0. Có xác thực rồi nhưng giới hạn IP vẫn bớt được rất nhiều request dò quét.

Kiểm tra proxy từ máy của mình:

curl -x http://<ten-dang-nhap>:<mat-khau>@<ip-ec2>:3128 https://ifconfig.me

Nếu lệnh trả về IP của EC2 thì proxy đã chạy.

Sau khi chạy được squid thì thiết lập proxy cho máy của mình. Mình dùng macOS: vào System Settings → Network → Wi-Fi → Details → Proxies, bật Web proxy (HTTP) và Secure web proxy (HTTPS), điền IP của EC2 và cổng 3128 cho cả hai, bật Proxy server requires password rồi điền tài khoản vừa tạo.

Thiết lập xong proxy thì mình đã vào được stitch thành công. Mình bắt đầu trải nghiệm với một prompt để thiết kế một website. Khá ấn tượng với kết quả ban đầu mà nó đưa ra. Tuy nhiên mình chưa rõ khả năng của nó như thế nào khi cần phải tùy chỉnh thêm các chi tiết nhỏ. Stitch cho phép tải code về hoặc chuyển code sang Figma.

Bài này chỉ ghi lại lần thử đầu tiên. Proxy cho toàn bộ máy cũng có nhược điểm, mọi request đều đi qua Singapore; cách chỉ proxy cho một số domain mình viết ở bài Thiết lập PAC proxy trên MacOS.