Sửa lỗi hiệu năng PPPoE chậm trên UniFi bằng phương pháp PPPoE Half-Bridge

Tại ArcBox Labs, văn phòng của chúng tôi sử dụng kết nối PPPoE tốc độ 5 Gbps phía sau cổng gateway UniFi, nhưng chúng tôi chưa bao giờ đạt được tốc độ gần với mức đó. Mẫu UDM Pro Max thậm chí đang bắt đầu quá tải và làm ảnh hưởng đến sự ổn định của hệ thống:

Điều này tương tự như hiện tượng mà nhiều người dùng UniFi khác gặp phải:

• https://community.ui.com/questions/a6f24f8c-6b83-4617-ad33-b5af0b32d8dc?replyId=2808b654-e4be-4ac2-b199-09c1b1a0fbac
• https://community.ui.com/questions/What-is-the-max-performance-for-PPPOE-on-UDM-Pro-With-Solution/67057f47-509e-4f8b-8edd-5dc29f380759
• https://www.reddit.com/r/Ubiquiti/comments/1dto912/story_time_investigating_slow_pppoe_speeds_on/
• https://forum.level1techs.com/t/unifi-and-bad-pppoe-speeds-any-solutions/224548
• https://community.ui.com/questions/ETA-on-bugfix-for-UDM-Pro-bad-PPPoE-performance/9119aa98-412f-41c7-9188-a30036c2e4c2
• https://www.reddit.com/r/Ubiquiti/comments/1buqkx1/max_speed_pppoe_on_udm_pro_with_10gbit_wan/
• https://www.reddit.com/r/Ubiquiti/comments/1hctxjk/efg_with_pppoe_uk_testing/

Đại đa số các gateway UniFi, từ UDM Pro/SE/Pro Max, UXG Pro cho đến EFG, đều sử dụng CPU không hỗ trợ tăng tốc phần cứng cho cả PPPoE lẫn NAT. Do đó, bất cứ khi nào bạn sử dụng kết nối mạng PPPoE đằng sau các thiết bị này, băng thông đều bị giảm nghiêm trọng và không bao giờ đạt tới tốc độ cam kết của nhà mạng. Điều này đã được ghi nhận rất nhiều trong cộng đồng UniFi.

Tóm lại, hiệu năng PPPoE trên các gateway UniFi khá thất vọng:

• UDM Pro/SE: Tốc độ đo được qua PPPoE thường chỉ đạt từ 1200 Mbps đến 1500 Mbps.
• UDM Pro Max: Thường đạt từ 1400 Mbps đến 1800 Mbps.
• EFG: Thường đạt từ 1400 Mbps đến 2400 Mbps.
• UCG Fiber: Nhờ trang bị SoC MediaTek Filogic 880 có hỗ trợ tăng tốc phần cứng PPPoE, tốc độ có thể vượt quá 5000 Mbps qua PPPoE.

PPPoE

PPPoE (Point-to-Point Protocol over Ethernet) là giao thức mạng đóng gói các khung PPP bên trong khung Ethernet; các nhà mạng (ISP) sử dụng giao thức này để xác thực và tính cước người dùng băng thông rộng. Mặc dù PPPoE thêm 6 byte header PPPoE và 2 byte header giao thức PPP giữa khung Ethernet và gói tin IP, nhưng 8 byte chi phí phát sinh đó là không đáng kể. Lý do thực sự khiến PPPoE làm suy giảm hiệu năng nằm ở chính bản chất của giao thức này.

Với kết nối PPPoE, router phải thêm header PPPoE vào mọi gói tin gửi đi và gỡ bỏ header PPPoE khỏi mọi gói tin nhận về. Với lưu lượng gói tin lớn, việc này đòi hỏi sức mạnh CPU rất cao hoặc phải có mạch tăng tốc phần cứng chuyên dụng (ASIC).

Đối với các router không có tăng tốc phần cứng PPPoE, mọi thứ còn tồi tệ hơn: hầu như tất cả các triển khai PPPoE hiện nay đều là đơn luồng (single-threaded). Ngay cả với CPU đa nhân, quá trình đóng/giải đóng gói PPPoE thường chỉ chạy trên một nhân duy nhất. Mặc dù tính năng if_pppoe của pfSense triển khai RSS độc lập với NIC và module pppoe của Linux kernel hỗ trợ RPS/XPS, nhưng những giải pháp này chỉ phát huy hiệu quả khi có nhiều phiên (session) PPPoE. Đối với một phiên PPPoE đơn lẻ (trường hợp phổ biến nhất của một đường truyền băng thông rộng), quá trình xử lý vẫn bị gán cố định vào một nhân CPU.

Tính đến tháng 4 năm 2026, chỉ có một vài gateway UniFi như UCG Fiber (với SoC MediaTek Filogic 880) là được tích hợp sẵn khả năng tăng tốc phần cứng PPPoE. Đáng mỉa mai là gateway UniFi càng cao cấp thì nền tảng OEM của nó lại càng ít hỗ trợ tăng tốc PPPoE: ví dụ như EFG sử dụng dòng chip Marvell OCTEON TX2 Infrastructure hoàn toàn không hỗ trợ tính năng này.

Do hầu hết gateway UniFi sử dụng nền tảng OEM thiếu tăng tốc phần cứng PPPoE, nên không bản cập nhật firmware nào có thể sửa triệt để vấn đề này. Và với định hướng kỹ thuật hiện tại của UniFi, ngay cả những tối ưu hóa PPPoE ở cấp độ phần mềm có thể làm được cũng bị bỏ ngỏ.

Tăng tốc PPPoE Half-Bridge ngoại vi

Đến năm 2026, rất nhiều ISP vẫn phụ thuộc vào PPPoE, bao gồm Bell Canada, AT&T Fiber, Xfinity tại Mỹ và đại đa số các nhà mạng ở Châu Âu, Châu Á. Nếu gateway UniFi không thể tự đáp ứng hiệu năng PPPoE, chúng ta có thể chuyển nhiệm vụ quay số PPPoE cho một thiết bị chuyên dụng. Thiết bị này sẽ quay số PPPoE, lấy địa chỉ IP công cộng, gỡ bỏ IP đó khỏi giao diện ảo PPPoE (như ppp0) và chuyển tiếp cho gateway UniFi thông qua DHCP. Gateway UniFi sẽ nhận địa chỉ IPv4 công cộng qua DHCP mà không phải gánh tải xử lý PPPoE, từ đó tập trung toàn bộ tài nguyên cho định tuyến, IDS/IPS và NAT.

Phiên PPPoE -> Cấp IPv4 công cộng

ISP <===============> [Tải PPPoE qua OpenWrt] ========================> [UniFi Gateway]

Không giữ IPv4 công cộng -> Giữ IPv4 công cộng từ DHCP WAN

Kỹ thuật này được gọi là PPPoE Half-Bridge (hoặc Zero IP Bridge). Thiết bị giảm tải PPPoE thực hiện quay số, tước địa chỉ IPv4 khỏi giao diện ảo, khởi chạy DHCP server trên giao diện vật lý và cấp địa chỉ IPv4 công cộng đó cho gateway UniFi phía sau qua DHCP. Bằng cách này, thiết bị ngoại vi xử lý PPPoE, còn gateway UniFi nhận IPv4 công cộng trực tiếp mà không tốn tài nguyên CPU.

Trong thực tế, một số modem ONU/ONT do nhà mạng cung cấp đã tích hợp tính năng này (như Advanced DMZ, IP Passthrough hoặc DMZplus). Khi bật lên, ONU/ONT (vốn đã có tăng tốc phần cứng PPPoE) sẽ tự quay số và chuyển IPv4 công cộng cho router phía sau. Tuy nhiên, rất nhiều modem nhà mạng không hỗ trợ tính năng này, buộc người dùng phải tự thiết lập.

Triển khai PPPoE Half-Bridge với OpenWrt

Tại đây, chúng tôi sử dụng cơ chế hotplug.d của OpenWrt để triển khai phương pháp tăng tốc PPPoE half-bridge. Mã nguồn đầy đủ và cấu hình mẫu được lưu trữ tại repository GitHub arcboxlabs/pppoe-half-bridge.

Thành phần cốt lõi của arcboxlabs/pppoe-half-bridge gồm hai tệp: 99-half-bridge và start-half-bridge.sh. Tệp 99-half-bridge nằm trong đường dẫn /etc/hotplug.d/iface/ và sẽ tự động kích hoạt mỗi khi quay số PPPoE thành công (khi OpenWrt tạo giao diện ảo ppp0); sau đó nó gọi start-half-bridge.sh để hoàn tất cấu hình. Tệp start-half-bridge.sh chứa logic thực thi và sẽ tiến hành các bước sau:

1. Tắt NAT/MASQUERADE ở phía WAN của firewall OpenWrt.
2. Đọc địa chỉ IPv4 vừa quay số từ giao diện ảo PPPoE (ví dụ: ppp0).
3. Tính toán subnet /24 chứa địa chỉ IPv4 công cộng đó, sử dụng IP đầu tiên trong dải (ví dụ: x.x.x.1) làm gateway cho DHCP server của OpenWrt, đồng thời đặt offset chính xác để DHCP server cấp địa chỉ IPv4 công cộng (ví dụ: x.x.x.114) cho gateway UniFi.
4. Thay thế route mặc định và bổ sung định tuyến theo chính sách (policy-based routing) để thực hiện "source-based routing": gửi gói tin ra giao diện ảo PPPoE tương ứng với IP nguồn. Điều này cho phép tăng tốc nhiều đường truyền PPPoE cùng lúc.
5. Áp dụng các thông số gateway và offset vào cấu hình DHCP server của OpenWrt rồi khởi động lại dịch vụ DHCP.
6. Khởi động lại giao diện vật lý trên OpenWrt (ifdown && ifup) để kích hoạt thay đổi trạng thái kết nối, buộc gateway UniFi gửi yêu cầu xin cấp mới IPv4 công cộng từ OpenWrt.
7. Do lỗi triển khai ARP trên các gateway UniFi, cần thêm các bản ghi ARP tĩnh trên OpenWrt (ip neigh replace) để đảm bảo kết nối ổn định giữa OpenWrt và gateway UniFi.

Bạn có thể tham khảo tệp EXAMPLE.md trong kho lưu trữ GitHub arcboxlabs/pppoe-half-bridge. Trong thử nghiệm thực tế với Banana Pi BPI-R4 Pro chạy OpenWrt làm thiết bị giảm tải, tốc độ PPPoE đã vượt mốc 5000 Mbps.

TOÁN HỌC THUẦN TUÝ LÀ "MÓN ĐỒ CHƠI VÔ NGHĨA" HAY CHÌA KHÓA GIẢI MÃ TƯƠNG LAI?

Khi nhắc đến Toán học, đa phần chúng ta thường liên tưởng ngay đến những phép tính khô khan, những bảng tính ngân hàng hay các mô hình dự báo thời tiết. Nhưng bạn có bao giờ tự hỏi: Tại sao thế giới lại chia Toán học thành hai nửa hoàn toàn trái ngược — "Toán ứng dụng" và "Toán lý thuyết"?

• Toán ứng dụng (Applied Mathematics): Đứng ở mặt đất. Mọi công thức sinh ra đều để phục vụ trực tiếp cuộc sống: từ tính toán kết cấu cầu đường, tối ưu thuật toán Logistics, cho đến dự đoán biến động thị trường chứng khoán.

• Toán lý thuyết (Pure Mathematics): Bày trò ở trên mây. Mấy ông nhà toán học tự nghĩ ra các hệ đề chân, chơi đùa với những khái niệm trừu tượng như không gian $n$ chiều hay cấu trúc đại số... chỉ vì nó "đẹp" và thỏa mãn trí tò mò, bất chấp việc nó có dùng được vào việc gì hay không.

Thế nhưng, lịch sử loài người đã chứng minh một sự thật hài hước: Toán lý thuyết chỉ "vô nghĩa" cho đến khi con người tiến đủ xa để cần đến nó.

Dưới đây là 3 "món đồ chơi vô nghĩa" từng bị mỉa mai là quái dị, nhưng ngày nay lại đang âm thầm vận hành toàn bộ thế giới hiện đại của chúng ta.

1. Hình Học Phi Euclid: Từ "Trò Vẽ Chuyện" Đến Chiếc Chìa Khóa Định Vị GPS

Thế kỷ 19, nhà toán học Bernhard Riemann đưa ra một câu hỏi nghe rất "rảnh rỗi": Nếu không gian không phẳng mà bị cong, thì các quy tắc hình học sẽ ra sao? Khi đó, ông chứng minh rằng trong không gian cong, tổng 3 góc tam giác có thể lớn hơn $180^\circ$ và hai đường song song hoàn toàn có thể cắt nhau.

Giới khoa học thời đó nhếch mép: Mặt đất dưới chân phẳng lỳ, bầu trời trước mắt bao la, ai rảnh mà đi nghiên cứu không gian cong?

💥 Cú bẻ lái của lịch sử:

Đầu thế kỷ 20, Albert Einstein loay hoay tìm ngôn ngữ toán học để mô tả vũ trụ. Ông nhận ra: Khối lượng lớn như Trái Đất hay Mặt Trời làm bẻ cong không gian - thời gian xung quanh nó. Để viết nên Thuyết Tương Đối Tổng Quát, Einstein buộc phải "mượn" trọn vẹn bộ hình học không gian cong của Riemann.

• Ứng dụng sinh tử ngày nay: Các vệ tinh GPS bay ở độ cao $20.000\text{ km}$, nơi có lực hấp dẫn yếu hơn mặt đất, khiến thời gian trên vệ tinh trôi nhanh hơn $38\text{ microgiây}$ mỗi ngày.

• Nếu không áp dụng công thức hình học không gian cong để hiệu chỉnh sai số này, bản đồ Google Maps trên điện thoại của bạn sẽ bị lệch khoảng $11\text{ km}$ mỗi ngày!

2. Số Phức ($i = \sqrt{-1}$): Bản Hợp Tấu Của "Số Ma" Và Kỷ Nguyên Bán Dẫn

Thế kỷ 16, các nhà toán học vò đầu bứt tai khi gặp phải $\sqrt{-1}$ trong khi giải phương trình. Theo quy tắc thông thường, làm gì có số nào nhân với chính nó lại ra số âm? Tạm thời không gạt đi được, họ gán cho nó ký hiệu $i$ (imaginary - tưởng tượng) và gọi nó là "số ảo" hay "số ma".

Suốt nhiều thế kỷ, số phức bị coi là một khái niệm khiên cưỡng, vô thực và chỉ tồn tại trên giấy.

💥 Cú bẻ lái của lịch sử:

Số thực chỉ biểu diễn được độ lớn trên một đường thẳng. Nhưng tự nhiên lại tràn ngập những hiện tượng có mặt xoay, chu kỳ và dạng sóng (điện xoay chiều, sóng âm, sóng vô tuyến). Số phức $z = a + bi$ lại sở hữu đặc tính kỳ diệu: nó biểu diễn được cả độ lớn lẫn góc xoay trong không gian.

• Ứng dụng sinh tử ngày nay:

  • Nếu không có số phức, việc tính toán phương trình dòng điện xoay chiều hay sóng 5G/Wi-Fi sẽ phức tạp và dài hàng trang giấy.

  • Trong Cơ học lượng tử, phương trình Schrödinger mô tả chuyển động của các hạt cơ bản bắt buộc phải chứa đơn vị ảo $i$. Không có số phức, con người không bao giờ hiểu được cơ chế hạt để tạo ra chip bán dẫn — trái tim của toàn bộ máy tính và smartphone hiện nay.

3. Lý Thuyết Số: Nhánh Toán "Nhàn Rỗi" Trở Thành Nền Tảng Bảo Mật Toàn Cầu

G.H. Hardy — một nhà toán học lừng danh từng tự hào viết trong cuốn sách của mình rằng: "Lý thuyết số là nhánh toán học thuần khiết nhất, đẹp đẽ nhất, hoàn toàn vô dụng và sẽ không bao giờ bị vấy bẩn bởi các ứng dụng thực tế."

Các nhà lý thuyết số dành cả đời chỉ để chơi đùa với các số nguyên tố ($2, 3, 5, 7, 11...$) và các phép chia hết — những thứ tưởng chừng như bài tập toán đố của học sinh tiểu học.

💥 Cú bẻ lái của lịch sử:

Khi Internet bùng nổ, thế giới đối mặt với bài toán tối quan trọng: Làm sao để chuyển tiền, gửi mật khẩu mà không bị hacker đánh cắp trên đường truyền?

Giải pháp nằm ở tính chất bất đối xứng kỳ lạ của số nguyên tố (Thuật toán mã hóa RSA):

• Máy tính nhân 2 số nguyên tố cực lớn để ra số $N$ chỉ tốn $0.0001\text{ giây}$.

• Nhưng nếu cho trước số $N$ (dài 600 chữ số) và bắt máy tính tìm lại 2 số nguyên tố ban đầu, ngay cả siêu máy tính mạnh nhất thế giới hiện nay cũng phải mất hàng tỷ năm!

• Ứng dụng sinh tử ngày nay: Mọi giao dịch ngân hàng qua Internet, mật khẩu mạng xã hội, tin nhắn mã hóa end-to-end hay công nghệ Blockchain/Bitcoin... đều đang dùng "trò chơi số nguyên tố" làm lá chắn bảo mật vững chắc nhất.

LỜI KẾT

Nhà vật lý từng đoạt giải Nobel Eugene Wigner từng gọi đây là "Sự hiệu quả đến mức phi lý của Toán học trong Khoa học Tự nhiên".

Toán học lý thuyết không hề xa rời thực tế. Nó giống như việc các nhà toán học đang âm thầm đúc sẵn những chiếc chìa khóa quái dị. Có thể hôm nay chưa có cánh cửa nào vừa vặn với chiếc chìa khóa đó, nhưng $100$ hay $200$ năm sau, khi khoa học tiến đến một biên giới mới, con người sẽ ngỡ ngàng nhận ra: "Hóa ra đáp án đã được ai đó chuẩn bị sẵn từ thế kỷ trước rồi!"

Hardcore IndieWeb: Vận hành website độc lập hoàn toàn chỉ với 0,01 USD mỗi ngày

Hardcore IndieWeb: Tự vận hành trang web độc lập 100% chỉ với $0.01/ngày

Adam Newbold
Ngày 18 tháng 7 năm 2026

Nếu bạn chưa quen với phong trào IndieWeb, thì đây là một cách tiếp cận thực tế để duy trì sự hiện diện của bạn trên mạng internet, trong đó nhấn mạnh vào việc sở hữu hoàn toàn danh tính và nội dung của chính bạn. Điều này đặc biệt có ý nghĩa vào thời điểm hiện tại, khi ngày càng có nhiều tập đoàn muốn sở hữu và kiểm soát những thứ đó thay bạn. Tinh thần của IndieWeb nhằm mục đích loại bỏ ảnh hưởng và sự kiểm soát từ bên ngoài đối với cả bạn và tài sản của bạn.

Và cũng như bất kỳ phong trào nào khác, có rất nhiều dịch vụ khác nhau ngoài kia nhằm giúp bạn kết nối vào mạng lưới độc lập hiện đại này. Tôi thậm chí còn tự mình vận hành một dịch vụ như vậy! Nhưng tôi luôn đặt các giá trị của mình lên trên lợi nhuận, vì vậy tôi không ngần ngại chia sẻ một sự thật đơn giản rằng bạn không cần một dịch vụ viết blog trả phí đắt đỏ để tham gia IndieWeb. Trên thực tế, khi bạn sử dụng một trong những dịch vụ đó, bạn thực sự đang đi lùi một bước so với sự độc lập thực sự, bởi vì nội dung của bạn thường sẽ nằm trong cơ sở dữ liệu của người khác trên máy chủ của người khác. Họ sẽ nói với bạn rằng điều đó không sao cả vì bạn luôn có thể xuất dữ liệu đó ra bất cứ khi nào bạn muốn, dưới các định dạng mở, và tất nhiên điều đó rất tốt. Nhưng bạn vẫn không hoàn toàn sở hữu và kiểm soát nội dung của mình khi bạn phụ thuộc vào dịch vụ của người khác.

Để làm rõ thì không có gì sai khi sử dụng các dịch vụ đó. Và nếu bạn đã và đang sử dụng chúng và cảm thấy hạnh phúc, điều đó thật tuyệt vời! Hướng dẫn này không dành cho bạn. Nhưng nếu ý tưởng có sự độc lập và kiểm soát hoàn toàn đối với nội dung của bạn trên mạng internet hấp dẫn bạn, hãy đọc tiếp. Bởi vì đó chính là tất cả những gì mà Hardcore IndieWeb hướng tới.

Định nghĩa Hardcore IndieWeb

Hardcore IndieWeb đón nhận đầy đủ các nguyên tắc hiện có của IndieWeb; thực sự không có gì mới hay khác biệt ở đây cả. Các khía cạnh cốt lõi của Hardcore IndieWeb là khả năng kiểm soát đối với nội dung và tính linh hoạt của trang web của bạn:

• Nếu nội dung của bạn không chủ yếu tồn tại trên ổ cứng của chính bạn, bạn không hoàn toàn kiểm soát nội dung đó.
• Nếu bạn không có một bản sao mã nguồn HTML đã xuất bản và các tài nguyên web trên ổ cứng của riêng mình, trang web đó không thực sự linh hoạt để di chuyển.

Tại sao điều này lại quan trọng? Hãy nghĩ xem điều gì sẽ xảy ra nếu dịch vụ blog IndieWeb bạn đang sử dụng đột ngột đóng cửa vào một ngày nào đó. Khả năng chuyển sang một dịch vụ mới phụ thuộc hoàn toàn vào việc bạn có xuất được dữ liệu của mình ra hay không. Nếu bạn không thể xuất được thì sao? Nhà cung cấp dịch vụ có thể đã nói rằng bạn sở hữu nội dung của mình, nhưng điều đó có ích gì nếu bạn không thể truy cập vào nó?

Từ góc độ linh hoạt, hãy xem xét điều gì xảy ra nếu bạn phát hiện ra chủ sở hữu của dịch vụ blog IndieWeb mà bạn đang dùng có những hành vi đáng ghét hoặc đơn giản là khiến bạn cảm thấy không thích nữa (điều này đã từng xảy ra trước đây!). Chắc chắn, bạn có thể xuất dữ liệu của mình dưới định dạng mở và chuyển đi. Nhưng bây giờ bạn phải tìm một dịch vụ khác có thể hoạt động với định dạng đó, hoặc chuyển đổi mọi thứ và áp dụng một bộ công cụ hoặc quy trình hoàn toàn mới. Và bạn phải chuyển nhà, một việc cực kỳ phiền phức.

Nếu bạn tuân theo Hardcore IndieWeb, không tình huống nào trong số này có thể ảnh hưởng đến bạn. Nội dung của bạn luôn nằm trong tầm kiểm soát hoàn toàn của bạn và trang web của bạn luôn tồn tại ở định dạng xuất bản đầy đủ. Sự độc lập này là hữu hình và bạn có thể hưởng lợi từ nó bất cứ khi nào cần thiết.

Phương pháp thực hiện

Theo nhiều cách—không, thực ra là theo mọi cách—Hardcore IndieWeb phản chiếu chính các phương thức xuất bản web từng được sử dụng vào những năm 90 khi mạng internet còn sơ khai. Đó là những việc chính tôi đã tự làm hồi đó, mỗi ngày, và chúng hoạt động rất tuyệt vời! Và tất nhiên chúng vẫn hoạt động tốt vào ngày nay, nhưng rất ít người nhận ra cách tiếp cận này vì hiện tại chúng ta đang chìm sâu trong nhiều tầng giải pháp lai giữa SaaS CMS/SSG gắn liền với hàng tá ngôn ngữ đánh dấu và số lượng hệ thống template nhiều gấp đôi. Chúng ta đang sống trong một thế giới web lộn xộn và phức tạp, nhưng không nhất thiết phải như vậy. Sự phức tạp là một lựa chọn, và sự đơn giản của Hardcore IndieWeb là một lựa chọn khác.

Quy trình sẽ như thế này:

1. Soạn thảo nội dung web trên ổ cứng của bạn.
2. Xem trước nội dung đó trong trình duyệt web của bạn.
3. Khi bạn hài lòng với những gì mình có, hãy tải nó lên máy chủ lưu trữ web của bạn. Lặp lại việc này thường xuyên tùy thích.

Chỉ vậy thôi. Nó thực sự đơn giản như thế. Ngoài một tên miền, đây là những gì bạn cần:

• Một trình chỉnh sửa văn bản
• Một công cụ truyền tệp tin
• Một máy chủ lưu trữ web (web host)

Một lần nữa, chỉ có thế thôi. Bạn không cần bất kỳ phần mềm đặc biệt nào khác. Không cần môi trường lập trình hay IDE, không cần framework hay shell hay công cụ CLI. Và chắc chắn không có đăng ký trả phí hàng tháng. Trong phần tiếp theo, tôi sẽ hướng dẫn cách chọn các mục này và tôi sẽ gợi ý một nhà lưu trữ web rất tốt với chi phí thực tế chỉ $0.01/ngày, trả tiền đến đâu dùng đến đó (vì vậy không cần đăng ký định kỳ).

(Bạn cũng cần biết một chút về HTML, nhưng ai cũng có thể học HTML. Và trên thực tế, bạn chỉ cần biết vài thẻ cơ bản rồi sao chép và dán là chủ yếu, vì vậy đừng lo lắng!)

Bắt đầu

Đầu tiên, bạn cần tìm một trình chỉnh sửa văn bản mà bạn thích. Hy vọng bạn đã có sẵn một cái, nhưng nếu chưa, bạn có thể thử các trình chỉnh sửa khác nhau cho đến khi tìm được cái phù hợp với mình. (Bản thân tôi sử dụng Nova của Panic.) Bạn có thể sử dụng hầu như bất kỳ trình chỉnh sửa nào, vì nó chỉ cần hỗ trợ lưu tệp vào đĩa cứng của bạn (và tất cả chúng đều làm được điều đó).

Tiếp theo, bạn sẽ cần một cách để truyền tệp tin. Một phần lý do tôi chọn Nova làm trình chỉnh sửa là vì nó cũng xử lý luôn việc truyền tệp. Nhưng có rất nhiều lựa chọn khác ngoài kia. FileZilla là một ứng dụng đa nền tảng rất tốt. Bạn có thể sử dụng bất cứ thứ gì có khả năng truyền tệp qua giao thức SSH (hoặc SFTP).

Cuối cùng, bạn cần một nơi để lưu trữ nội dung web của mình. Có hàng triệu nhà lưu trữ ngoài kia với đủ loại tính năng và lợi ích. Nhưng đối với Hardcore IndieWeb, bạn chỉ cần những thứ cơ bản nhất và hoàn toàn không cần tốn nhiều tiền. Chỉ với $0.01/ngày, bạn có thể vận hành một trang web tĩnh tại NearlyFreeSpeech.net, và đó là nơi tôi khuyên dùng. Tôi đã có một tài khoản hoạt động với họ từ năm 2008 và họ thực sự tuyệt vời!

Tuy nhiên, bạn có thể sử dụng bất kỳ nhà lưu trữ nào bạn muốn. Nếu bạn muốn sử dụng NearlyFreeSpeech, hãy đăng ký, nạp tiền vào tài khoản (bạn có thể bắt đầu chỉ với $0.25), thêm một trang web (tĩnh, phi sản xuất) và bạn đã sẵn sàng. Bạn sẽ tìm thấy thông tin đăng nhập của trang web (để truyền tệp) trong tab Sites sau khi nhấp vào tên trang web của mình. Bạn sẽ nhận được một tên miền phụ miễn phí để làm việc, nhưng bạn có thể thêm tên miền cá nhân của riêng mình trong tab Domains nếu muốn (và bạn hoàn toàn nên làm điều đó).

Quy trình thực hiện

Một khi bạn đã có trình chỉnh sửa, cách truyền tệp và một tài khoản hoạt động tại nhà lưu trữ web, bạn đã sẵn sàng bắt đầu. Tại thời điểm này, thế giới là của bạn. Bạn có thể vận hành bất kỳ loại trang web nào bạn thích, nhưng đối với hướng dẫn này, chúng ta giả định rằng bạn muốn vận hành một blog.

Hầu hết thời gian, một blog bao gồm các thành phần sau:

• Một trang chủ (landing page)
• Các bài viết/bài báo
• Một trang lưu trữ (archive)
• Một nguồn cấp dữ liệu (feed)

Nếu bạn luôn cho rằng mình cần một dịch vụ hoặc phần mềm viết blog đặc biệt để duy trì các mục này, điều đó hoàn toàn có thể hiểu được. Nhưng bạn không cần đâu! Bạn thực sự có thể tự mình quản lý chúng, và nó thực sự siêu dễ dàng. Lúc này bạn có thể (một cách dễ hiểu) tự hỏi "loại người nào lại đi quản lý nguồn cấp dữ liệu RSS của riêng họ trong một trình chỉnh sửa văn bản chứ?" Và câu trả lời là bạn. Bạn chính là kiểu người hoàn toàn có khả năng quản lý nguồn cấp dữ liệu RSS của riêng mình trong trình chỉnh sửa của chính mình.

Chúng ta sẽ nói về điều đó ngay sau đây. Trước tiên, hãy nói về các trang HTML.

Lưu ý nhanh về các trang web

Nếu bạn đã có sẵn trang web hoặc blog hiện tại của mình ở định dạng HTML, bạn đang ở một vị thế tuyệt vời để bắt đầu với Hardcore IndieWeb. Nếu chưa có, không sao cả. Tùy thuộc vào nơi blog của bạn đang nằm hiện tại, có thể có nhiều cách để xuất nó ra định dạng HTML hoặc chuyển đổi nó sang HTML. Nếu blog của bạn lớn, có lẽ bạn sẽ muốn dùng một công cụ để làm việc này dễ dàng hơn. Nếu nó nhỏ, có thể bạn sẽ thích thú khi tự mình tạo các tệp HTML mới (đây luôn là một cách thú vị để xem lại các bài viết của mình).

Nếu bạn không biết nhiều về HTML, bạn hoàn toàn có thể học được. Thậm chí tôi sẽ dạy bạn nếu bạn muốn. Học HTML siêu vui, và việc sử dụng HTML đưa bạn đến gần hơn với nội dung web của mình theo những cách mà các công cụ hiện đại không thể mang lại. Markdown có thể là cách soạn thảo nội dung ưa thích của nhiều người, nhưng HTML mới là ngôn ngữ của web, và cá nhân tôi có thể chứng thực rằng có rất nhiều trường hợp việc thực hiện một việc gì đó bằng HTML thuần túy hóa ra lại dễ dàng hơn nhiều so với việc phải vật lộn với một trình phân tích cú pháp Markdown.

Dù sao đi nữa, nếu bạn muốn bắt đầu ngay với một số tài liệu web có sẵn để làm nền tảng cho trang web của mình, có vô số thiết kế và template web miễn phí ngoài kia. Bạn có thể tải xuống thứ gì đó bạn thích, mở nó trong trình chỉnh sửa văn bản và biến nó thành của riêng bạn.

Trang chủ

Trang chủ là ngôi nhà của bạn trên mạng internet, và bạn có thể làm bất cứ điều gì bạn muốn với nó. Nó có thể hiển thị bài viết mới nhất của bạn, hoặc một vài bài viết, hoặc không bài nào cả. Nó có thể hiển thị toàn bộ bài viết hoặc chỉ một vài câu đầu tiên. Bạn có toàn quyền kiểm soát ở đây và bạn có thể đặt bất cứ thứ gì bạn muốn lên trang đó. Nếu bạn muốn hiển thị bài viết mới nhất của mình, chỉ cần sao chép và dán nó vào đó và thêm một liên kết đến trang độc lập của nó. Nếu bạn muốn hiển thị năm bài viết gần đây nhất, hãy dán bài mới vào đầu trang và xóa bài cũ nhất ở cuối trang. Lúc này bạn đang làm việc trực tiếp với nội dung của mình trên trang chủ của riêng bạn, và bạn có thể làm bất cứ điều gì bạn muốn, theo bất kỳ cách nào bạn thích.

Điều này nghe có vẻ điên rồ nếu bạn đã hoàn toàn quen với các hệ thống quản lý nội dung và blog dựa trên template hiện đại ngày nay. Và đó là một cảm nhận hoàn toàn hợp lý. Nhưng hãy cân nhắc rằng cách tiếp cận này mang lại một số khả năng độc đáo mà thực tế lại khó thực hiện hơn với các giải pháp dựa trên template. Với cách này, bạn có thể đi chệch khỏi các quy chuẩn thông thường. Bạn có thể đưa mọi thứ theo các hướng đi khác nhau. Bạn có thể áp dụng sự sáng tạo của mình theo những cách vui nhộn và thú vị, và bạn sẽ không bao giờ thấy mình phải chiến đấu với CMS/SSG/công cụ tạo template/v.v. bởi vì bạn không hề sử dụng chúng. Nó hoàn toàn tự do.

Trang chủ của bạn nên được đặt tên là index.html và nằm ở thư mục gốc của web (thường là /home/public nếu bạn sử dụng NearlyFreeSpeech).

Các bài viết trên Blog

Các bài viết trên blog thực chất cũng chỉ là các trang web. Chúng siêu dễ để duy trì và xuất bản. Bạn có thể thực hiện theo bất kỳ quy trình nào bạn thích, nhưng cách tiếp cận đơn giản nhất là chỉ cần tạo một bản sao của trang web dành cho bài đăng blog trước đó của bạn, đặt cho nó một tên tệp duy nhất, rồi chỉnh sửa nó với nội dung bài viết mới.

Đây là thời điểm tốt để nghĩ về cấu trúc trang web của bạn và cách bạn muốn sắp xếp các tệp tin của mình. Các URL dẫn đến bài viết của bạn sẽ phản ánh cấu trúc tệp trên đĩa cứng. Bạn có muốn tất cả các bài viết blog của mình nằm trong một mục /blog/ không? Vậy thì hãy tạo một thư mục blog trong thư mục gốc của web và lưu trữ các tệp blog của bạn ở đó. Bạn có thể đặt tên cho các bài viết của mình bằng đường dẫn mong muốn, ví dụ: the-best-lunch-i-ever-had.html, hoặc bạn có thể tạo các thư mục riêng cho chúng và lưu trữ bài viết bên trong mỗi thư mục dưới dạng tệp index.html để ẩn phần mở rộng tệp .html (nhưng trái với suy nghĩ của nhiều người, đó là một phần mở rộng tệp rất đẹp và trung thực).

Đây cũng là thời điểm tốt để xem xét một lợi ích khác của Hardcore IndieWeb. Khi các bài viết của bạn là các tệp HTML riêng lẻ (không phải tệp Markdown hay các hàng trong cơ sở dữ liệu), cuối cùng chúng có thể được nhìn nhận như những trang web độc lập thực sự. Và điều đó có nghĩa là bạn có thể thực sự đầu tư để làm cho tất cả các bài viết của mình trở nên độc nhất! Chúng không nhất thiết phải là những bản sao rập khuôn của nhau; đó chỉ là sản phẩm phụ của các công cụ xuất bản web hiện đại và tầm ảnh hưởng văn hóa mà chúng có đối với khái niệm về một "blog" của chúng ta. Giờ đây, bạn có thể tiếp tục và làm cho mỗi bài viết blog trở nên đặc biệt và mang tính cá nhân tùy thích. Mỗi bài đăng có thể có cá tính riêng, được tích hợp ngay vào mã HTML của nó. Phong cách riêng, giao diện riêng, thậm chí cả bố cục riêng. Về mặt lý thuyết, mọi thứ đều có thể với cách tiếp cận này.

Trang lưu trữ

Quản lý trang lưu trữ của bạn rất đơn giản. Hãy tạo một thư mục tên là archive (hoặc bất cứ tên gì bạn muốn gọi), thêm một trang index.html ở đó và liệt kê các bài viết blog của bạn trên trang này. Bạn có thể sắp xếp chúng theo bất kỳ cách nào bạn muốn. Bạn có thể làm nổi bật các bài viết yêu thích của mình ở đầu trang. Bạn có thể làm bất cứ điều gì—đó là trang lưu trữ của bạn để bạn quản lý theo ý muốn.

Nguồn cấp dữ liệu (Feed)

Một nguồn cấp RSS không phải là một loại mã web thần bí hay cao siêu nào cả; nó chỉ là một tệp tin trên đĩa cứng. Và nó là một tệp có định dạng khá đơn giản để phân tích và làm việc, và bạn hoàn toàn có thể làm điều đó trong trình chỉnh sửa văn bản của mình. Nó thực sự không khó.

Bạn có thể bắt đầu với một nguồn cấp Atom đơn giản (tương thích 100% với RSS và được hỗ trợ toàn cầu) bằng cách truy cập trang Atom feed trên Wikipedia, sao chép nguồn cấp dữ liệu ví dụ được hiển thị ở giữa trang và dán nó vào một tệp feed.xml (hoặc bất cứ tên nào bạn muốn đặt). Sau đó, chỉ cần thay đổi tất cả các tham chiếu example.com và các giá trị <title>, <subtitle>, v.v. để phản ánh tên miền và thông tin của riêng bạn. Cuối cùng, chỉ cần bao gồm một mục <entry> cho mỗi bài viết mà bạn muốn đưa vào nguồn cấp dữ liệu của mình. Thiết lập dữ liệu liên quan trong mỗi mục (ngày/giờ, tiêu đề, tóm tắt, v.v.). Đối với <id>, chỉ cần lấy một mã UUID mới. Và khi bạn hoàn thành, hãy sao chép và dán nguồn cấp dữ liệu của bạn vào Dịch vụ xác thực nguồn cấp dữ liệu của W3C để đảm bảo rằng nó có thể được phân tích cú pháp chính xác. Nếu có bất kỳ vấn đề nào, trình xác thực sẽ cho bạn biết những gì cần được sửa chữa.

Tải lên (Uploading)

Đây là phần dễ dàng nhất! Khi bạn đã sẵn sàng xuất bản trang web của mình, chỉ cần sử dụng chương trình truyền tệp để kết nối với máy chủ và kéo các tệp của bạn vào máy chủ từ xa. Lần đầu tiên bạn xuất bản lên nhà lưu trữ web, bạn sẽ muốn sao chép mọi thứ qua. Nhưng trong các lần tải lên tiếp theo, bạn có thể chỉ cần truyền bất cứ thứ gì mới hoặc thay đổi (ví dụ: trang chủ của bạn, bài viết blog mới, nguồn cấp dữ liệu và trang lưu trữ).

Các bước tiếp theo

Tại thời điểm này, bạn đã có một trang web hoạt động đầy đủ, tồn tại chủ yếu trên máy tính của riêng bạn và hoàn toàn linh hoạt. Đây là con đường của Hardcore IndieWeb. Bạn đã sẵn sàng cho mọi tình huống: nếu nhà lưu trữ của bạn biến mất, bạn chỉ cần sử dụng một nhà lưu trữ khác và tải trang web của mình lên đó. Bạn không phải lo lắng về các lỗ hổng bảo mật nghiêm trọng trong phần mềm viết blog hay các phụ thuộc SSG hoặc bất cứ điều gì tương tự. Bạn có quyền kiểm soát hoàn toàn đối với mọi khía cạnh của nội dung web của mình và bạn không phụ thuộc vào ai khác.

Bạn sẽ đi đâu từ đây? Điều đó tùy thuộc vào bạn. Bạn không nhất thiết phải đi đâu cả. Bạn có thể làm theo chính xác quy trình này mãi mãi và bạn sẽ luôn có một trang web tuyệt vời hoàn toàn là của riêng bạn và hoàn toàn độc lập.

Bạn cũng có thể chọn khám phá các công cụ và quy trình bổ sung để hỗ trợ quy trình làm việc của riêng mình. Hãy nhớ rằng mỗi thứ bạn thêm vào đều tạo ra sự phụ thuộc vào một thứ khác, nhưng miễn là nội dung của bạn tiếp tục tồn tại chủ yếu trên thiết bị của riêng bạn và bạn có một bản sao đầy đủ của trang web sẵn sàng xuất bản, bạn vẫn hoàn toàn ổn đối với tiêu chuẩn của Hardcore IndieWeb.

Kết luận

"Có phải tôi vừa đọc 2.500 từ chỉ để bảo tôi tự viết mã HTML của riêng mình rồi tải nó lên một máy chủ web không?" Đúng vậy. Bạn vừa làm thế đấy.

Nếu điều này có vẻ như là một lời khuyên nực cười vào năm 2026, tôi nghĩ phần lớn là do chúng ta đã đi quá xa so với sự đơn giản ban đầu mà chúng ta từng có khi làm việc với web. Các tầng phức tạp kỹ thuật được đưa vào trong 30 năm qua, các quy trình bổ sung mới, và những kỳ vọng đi kèm với tất cả những điều đó kết hợp lại thành một cách tiếp cận hiện đại nhường lại nhiều sự kiểm soát và độc lập của chúng ta cho người khác hơn bất kỳ thời điểm nào khác trong lịch sử của web. Ngay cả dưới chiếc ô "IndieWeb", rất nhiều người đã giao phó bản sao duy nhất cho toàn bộ sự hiện diện trên web của họ cho một anh chàng nào đó trên internet, người đã hứa sẽ chăm sóc nó. Đó không phải là sự độc lập thực sự, và chúng ta nên ngừng giả vờ rằng nó là như vậy.

Hardcore IndieWeb có thể không dành cho tất cả mọi người. Nhưng nếu bạn quan tâm đến câu chữ của mình, ai là người giữ chúng, và chúng xuất hiện trực tuyến ở đâu và như thế nào, thì bạn có thể thấy rằng nó dành cho bạn. Và nếu trong quá trình đón nhận cách tiếp cận cụ thể này, bạn tình cờ kết nối lại với mạng web theo cách mà nhiều người trong chúng ta đã từng thích thú trong thời kỳ đầu, trải nghiệm điều kỳ diệu và niềm vui khi làm việc trực tiếp với HTML và sao chép các tệp vào không gian của riêng bạn trên một nhà lưu trữ web, thì đó là một phần thưởng bổ sung tuyệt vời. Hardcore IndieWeb nghe có vẻ dữ dội, nhưng thực tế là nó mang lại sức mạnh, sự vui thích và xứng đáng. Và bạn xứng đáng nhận được điều đó.

Chúng ta có thực sự cần các trợ lý lập trình mã nguồn (code agents) không?

Việc viết bài viết này xuất phát từ một vài yếu tố:

1. Các vấn đề với mã nguồn được tạo tự động khi làm việc nhóm.

2. Gánh nặng nhận thức ngày càng tăng.

3. Sự áp đặt mạnh mẽ (ép buộc) từ phía Giám đốc Công nghệ (CTO) và tầng lớp quản lý.

Nhìn chung, tôi cũng khó thảo luận sâu sắc với các đồng nghiệp xung quanh nên cần một lượng khán giả lớn hơn. Khi đưa ra những gợi ý để cùng suy ngẫm, tôi thường chỉ nhận lại các bài viết tiếp thị từ những bên hưởng lợi từ Mô hình ngôn ngữ lớn (LLM), hoặc là những cách so sánh rất kỳ quặc mà tôi cũng sẽ phân tích trong bài viết này.

Nhìn chung, trong bài viết này tôi không cố gắng (thôi được rồi, thực ra là có cố gắng) thuyết phục bất kỳ ai, thông điệp của tôi chỉ là muốn chúng ta đặt ra nhiều câu hỏi hơn và suy nghĩ về những ranh giới áp dụng rõ ràng hơn của AI/LLM trong phát triển phần mềm.

Những điều bài viết này sẽ không đề cập

Tôi không thấy có lý do gì để bài xích việc sử dụng LLM hoàn toàn. Chúng rõ ràng mang lại lợi ích và chắc chắn giúp đẩy nhanh một số công việc lặp đi lặp lại mang tính thủ tục.

Các ví dụ về câu lệnh như: "Tạo cho tôi một file json để làm dữ liệu giả (mock data), đây là sơ đồ hợp đồng", "Bạn nghĩ gì về...", "Bạn có thấy vấn đề gì trong đoạn mã này không...", "Đây là một truy vấn ORM, tôi cần một truy vấn SQL tương đương theo ngôn ngữ của postgreSQL", "Tôi đang viết bằng ngôn ngữ X, khung làm việc (framework) Y, gặp phải vấn đề này, đây là nhật ký lỗi (log), nguyên nhân là gì và tôi có thể khắc phục như thế nào..."

Đó là những câu lệnh mà theo tôi hoàn toàn hợp lý và LLM xử lý chúng rất tuyệt vời trong hầu hết các trường hợp. LLM rất tốt đóng vai trò như một ý kiến tham khảo thứ hai (second opinion). Vì vậy, sẽ không có sự thù ghét cực đoan nào đối với LLM ở đây.

Và những điều bài viết này sẽ đề cập

Trong bài viết này, tôi sẽ xem xét các vấn đề khi sử dụng LLM như một công cụ chính. Tôi xin nhấn mạnh lại: Không phải là một công cụ tham khảo phụ trợ, mà là một công cụ chính, tự viết phần lớn mã nguồn trong các yêu cầu hợp nhất (merge requests) lên tới hàng trăm và hàng ngàn dòng mã. Đồng thời, tôi cũng xem xét các trường hợp ranh giới, khi lập trình viên được cho là đang đọc mã được tạo ra và kiểm soát các tác nhân AI (agents).

Các vấn đề

1. Mã nguồn được tạo tự động khi làm việc nhóm

Về các yêu cầu hợp nhất (merge requests): LLM tạo ra rất nhiều mã, nhưng LLM không có khả năng suy nghĩ sâu sắc về một tính năng, không thể lập ra danh sách các câu hỏi để tìm gặp giám đốc sản phẩm/nhà thiết kế/nhà phân tích nhằm có thêm thông tin giúp tư duy và viết ra những đoạn mã đơn giản, trực quan hơn.

LLM chỉ viết mã cho yêu cầu hiện tại, chúng không quan tâm đến ngày mai sẽ ra sao, không quan tâm đến lộ trình phát triển (roadmap), không quan tâm đến hệ lụy đối với các dịch vụ/mô-đun lân cận. Kết quả là chúng ta thấy một lượng mã khổng lồ chỉ cho một tính năng nhỏ trong yêu cầu hợp nhất.

Vài ngày sau, có yêu cầu thêm một tính năng khác vào chính mô-đun đó, LLM lại xáo trộn toàn bộ mã và một bản so sánh khác biệt (diff) với +1500 dòng và -1400 dòng lại xuất hiện. Việc đọc những khối lượng lớn như vậy một cách thường xuyên là điều không thể. Điều này không những không tăng tốc độ phát triển mà còn xóa sạch mọi điểm cộng của công nghệ. Nó làm tăng tốc độ thay đổi của kho mã (codebase) đến mức bộ não không thể tải nổi.

Sau vài lần lặp đi lặp lại như vậy, tôi không còn hiểu dịch vụ mà mới ngày hôm qua tôi còn nắm khá rõ và có thể nhanh chóng sửa các lỗi đột xuất nhờ hiểu sâu về kho mã. Giờ đây, ngay cả việc sửa lỗi cũng sẽ mất nhiều thời gian hơn. Gánh nặng nhận thức tăng vọt lên tận trời xanh. Lập trình viên đáng lẽ phải chiến đấu chống lại sự phức tạp, nhưng điều ngược lại đã xảy ra.

Hệ quả là chất lượng đánh giá mã (code review) giảm sút. Từ đó kéo theo chất lượng của mã nguồn và chất lượng của các bản phát hành/sản phẩm nói chung cũng đi xuống.

2. Gánh nặng nhận thức ngày càng tăng

Ý này có phần trùng lặp với ý trước. Tuy nhiên, tôi muốn tập trung vào những khía cạnh khác một chút. Tính đến năm 2026, hầu hết các bên tham gia vào thế giới IT vẫn đang đánh giá thấp mức độ gánh nặng nhận thức. Yếu tố này lại ảnh hưởng trực tiếp đến cả áp lực cảm xúc lẫn sức khỏe của lập trình viên nói chung.

Hiện nay, trong công việc hàng ngày, lập trình viên phải sử dụng hàng tá công cụ khác nhau ngoài kiến thức về chính ngôn ngữ lập trình đó. Đó là các công cụ kiểm tra lỗi cú pháp (linters), công cụ định dạng mã (formatters), các thùng chứa (containers), quy trình CI/CD, hệ thống theo dõi công việc, các phương pháp luận, các kiến trúc khác nhau cùng các nguyên lý như SOLID, công cụ kiểm tra kiểu dữ liệu, công cụ kiểm tra tải, các trình giả lập, hệ thống quản lý phiên bản, cơ sở dữ liệu, các hệ thống chuyển tiếp tin nhắn (brokers) và nhiều, nhiều thứ khác nữa.

Chưa kể bản thân các ngôn ngữ lập trình ngày càng trở nên phức tạp hơn. Tôi chưa thấy ngôn ngữ nào trở nên đơn giản đi cả. Ngôn ngữ hướng đối tượng của ngày hôm qua thì ngày hôm nay đã liên tục chạy các nhánh bằng so khớp mẫu (pattern matching) thay cho các câu lệnh if quen thuộc. Để làm quen với toàn bộ "sở thú" này cần vài tháng, còn để làm chủ được nó thì phải mất nhiều năm.

Và tất cả những điều đó là câu chuyện của ngày hôm qua. Còn ngày hôm nay, một công cụ nữa lại được thêm vào: LLM. Nó khác biệt hoàn toàn so với tất cả các công cụ khác. Giao diện của nó thay đổi quá nhanh. Ranh giới áp dụng của nó bị mờ nhạt. Không có thời gian để suy nghĩ, bạn buộc phải dùng, nếu không ngày mai thị trường sẽ đào thải bạn – đó là lời cảnh báo từ mọi phía, từ người đứng đầu nhà cung cấp LLM cho đến đồng nghiệp của bạn, và nhìn chung là xuất hiện trong mọi yêu cầu tuyển dụng hiện nay.

LLM tạo mã rất nhanh. Bạn phải đọc nó, hiểu nó, sửa lại nó, rồi lại đọc lại, hiểu lại và sửa lại lần nữa. Không ai mảy may suy nghĩ xem liệu bộ não có thể hoạt động ở nhịp độ như vậy hay không. Nhưng như thường lệ, chẳng có thời gian để nghĩ đâu, tính năng đã được hứa hẹn sẽ phát hành từ hôm qua rồi.

3. Sự áp đặt mạnh mẽ (ép buộc) từ phía CTO/tầng lớp quản lý

Ở đây thì mọi chuyện vẫn diễn ra như thường lệ. Quản lý luôn bị dẫn dắt bởi sự cường điệu (hype). Quản lý dễ sa vào hội chứng sùng bái hình thức (cargo-cult) hơn. Hôm qua vừa đạt lợi nhuận +x, hôm nay họ đã nghĩ ngay đến +10x. Và không gì có thể ngăn cản họ. Không một bài báo, sự thật nào, không một lời giải thích về nguyên lý hoạt động, không một mô tả về các vấn đề, hay những câu hỏi về việc chúng ta sẽ làm gì với đống mã được tạo tự động này sau nửa năm nữa, không gì cả.

Nhưng khác với bất kỳ làn sóng cường điệu nào khác, làn sóng này rất đặc biệt. Nó tiêm nhiễm vào đầu óc của cả những người thông minh nhất trong chúng ta. Rất nhiều CTO, kỹ sư trưởng (techleads), trưởng nhóm (teamleads), vốn là những kỹ sư của ngày hôm qua, giờ đây không thể chữa khỏi căn bệnh này. Nhìn chung, điều đó cũng dễ hiểu. Một mặt, họ chịu áp lực từ cấp quản lý cao hơn. Mặt khác, LLM tạo ra những đoạn mã trông cực kỳ có vẻ hợp lý.

Một chút về lý thuyết

Nhiều người dẫn nguồn từ bài viết này và tôi cũng không ngoại lệ. Đó là bài viết của Peter Naur: Programming as Theory Building (Lập trình như một quá trình xây dựng lý thuyết).

Trong đó, tác giả nói rằng vai trò thiết yếu trong việc phát triển phần mềm là xây dựng một lý thuyết trong đầu. Lý thuyết về việc các thành phần khác nhau của hệ thống liên kết với nhau như thế nào, mô hình được xây dựng phản ánh các quy trình kinh doanh được tích hợp vào đó ra sao, mô hình hiện tại linh hoạt đến mức nào, các sự đánh đổi khác nhau, v.v.

Và tất cả những điều này nằm trong đầu của các lập trình viên. Một phần của nó có thể được đưa vào tài liệu hướng dẫn, vào các thông số kỹ thuật, vào các dòng ghi chú (comments), nhưng dù thế nào đi nữa, khi các lập trình viên mới tham gia vào dự án, họ cần phải xây dựng toàn bộ lý thuyết này trong đầu ngay từ đầu. Và việc này tiêu tốn rất nhiều thời gian, chưa kể việc giao tiếp cũng sẽ lấy đi thời gian của các đồng nghiệp khác.

Tài liệu hướng dẫn là tốt, nhưng trước hết, tài liệu không phải lúc nào cũng là sự thật tuyệt đối. Tốc độ phát triển có thể vượt quá tốc độ viết tài liệu. Sẽ có người nói rằng LLM có thể giúp viết tài liệu. Nhưng LLM sẽ không viết trong tài liệu lý do tại sao một lớp (class) nào đó lại được triển khai chính xác theo cách đó và nó đã ảnh hưởng thế nào đến các lớp lân cận, mặc dù điều này có thể cực kỳ quan trọng cho việc phát triển chức năng sau này. Không ai kiểm tra những gì LLM viết ở đó cả.

Và nếu trừu tượng hóa hơn nữa, chúng ta có thể chuyển hẳn sang một ngôn ngữ hình thức tối đa – toán học. Các phương trình vi phân hay Lý thuyết trường đã được viết ra từ lâu và rất chi tiết. Nhưng:

• Thứ nhất, điều đó có cho phép ai đó áp dụng chúng vào thực tế để giải quyết các bài toán mà không cần xây dựng các lý thuyết này trong đầu mình không?

• Thứ hai, bạn đã thấy nhiều người giải thích các phương trình vi phân hoàn toàn giống nhau chưa?

Mà đó là ngôn ngữ hình thức tối đa rồi đấy. Huống chi là những thứ mang tính ứng dụng và logic kinh doanh (business logic). Do đó, ngay cả trong trường hợp có tài liệu chi tiết và mã nguồn chất lượng, con người vẫn cần một khoảng thời gian nhất định để hiểu được bản chất của dự án.

Ở cuối bài viết, bạn có thể tìm thấy một số nghiên cứu khoa học về đề tài này.

Những câu hỏi dành cho trạng thái hiện tại của LLM

Tất cả chúng ta đều thấy và tự mình cảm nhận được áp lực tiếp thị mạnh mẽ từ các công cụ LLM và AI nói chung. Tuy nhiên, hãy tạm rời xa các tin tức kiểu như "vừa ra mắt phiên bản x.yz mới của mạng ABC, tốt hơn e^100000 lần so với tất cả các phiên bản trước cộng lại" và nhìn vào kết quả tác động của LLM đối với việc phát triển phần mềm từ một khía cạnh khác.

Từ vài năm nay, người ta đã quả quyết với chúng ta rằng chẳng mấy chốc sẽ không còn việc làm cho lập trình viên nữa. Nghĩa là, LLM sẽ làm hết mọi việc thay chúng ta. Thế nhưng, điều gì đang xảy ra với các sản phẩm, chuyện gì đang xảy ra với các bộ công cụ, với các ngôn ngữ lập trình?

• Phải chăng đã xuất hiện các cơ sở dữ liệu nhanh hơn, đáng tin cậy hơn do LLM viết?

• Có phải mọi thứ đã được viết lại bằng ngôn ngữ Rust và không còn vấn đề với các ứng dụng chạy trên nền Electron ngốn hàng tấn bộ nhớ nữa?

• Các môi trường phát triển (IDE) đã thôi giật lag khi gõ văn bản thông thường chưa?

• Đã hoàn thiện xong Wayland và không còn lỗi nào sót lại?

• Có lẽ trong cpython, người ta đã đưa vào những tối ưu hóa cốt lõi bằng LLM và nó đã đuổi kịp tốc độ của các ngôn ngữ biên dịch?

• Trình duyệt của Anthropic tiến triển đến đâu rồi?

• Còn Bun thì sao, chạy trên môi trường thực tế (production) có bị sập không?

Vậy câu hỏi là: Hàng tấn sản phẩm đó đang ở đâu? Khi nào thì mỗi lập trình viên sẽ tự biến mình thành một chủ doanh nghiệp?

Đúng là có nghe nói về thành công riêng lẻ của một vài dự án nhỏ mang tính chất ngẫu hứng (vibe-projects), nhưng đó thường là các dự án nhỏ, mang lại thu nhập chỉ ở mức của một lập trình viên bậc trung/cao cấp (middle/senior), hoặc là... những trường hợp cực kỳ cá biệt mà chúng ta vẫn cần phải kiểm chứng kỹ lưỡng. Còn trong thế giới nguồn mở (opensource) có gì mới và thú vị không? Thật sự trong giai đoạn 2025/2026, trên GitHub không thấy có gì rầm rộ lắm về khía cạnh này.

Những điểm nghẽn thực sự

Không biết từ lúc nào, chẳng cần báo trước, bỗng nhiên tất cả mọi người đều quyết định rằng điểm nghẽn lớn nhất trong phát triển phần mềm là việc viết mã. Không rõ kết luận này dựa trên nghiên cứu nào. Những người dùng Vim với phương pháp gõ phím 10 ngón vẫn chưa thuyết phục được ngành công nghiệp này.

Những điều mà khách hàng đã quên/không hiểu/hoặc không muốn nhìn thấy:

• Thiết kế chương trình/dịch vụ – từ các lớp và phương thức, cho đến thiết kế hệ thống (system design) của toàn bộ sản phẩm.

• Giao tiếp với các giám đốc sản phẩm, nhà thiết kế, nhà phân tích, và các đồng nghiệp.

• Tìm kiếm giải pháp.

• Đảm bảo chất lượng (QA) cho mã đã viết. Đúng vậy, các lập trình viên cũng mất thời gian tự kiểm thử trước khi bàn giao cho đội ngũ kiểm thử phần mềm (testers).

• Viết tài liệu, giải quyết vấn đề, tư duy và dự đoán các tình huống khác nhau có thể ảnh hưởng đến tải của hệ thống, đến hành vi của nó trong các trường hợp ngoại lệ.

Tất cả những việc này tiêu tốn rất nhiều thời gian. Không, LLM không làm được những việc này, hoặc làm không tốt lắm.

Hãy thử thực hiện một thí nghiệm tưởng tượng. Cứ cho là tất cả những việc này không phải do LLM làm mà do một lập trình viên cấp cao đóng vai trò trợ lý thực hiện. Bất kể có đạt được thành công nào, trách nhiệm cuối cùng vẫn thuộc về lập trình viên được thuê. Và để duy trì trách nhiệm đó, anh ta cần phải chắc chắn về tính đúng đắn của các giải pháp. Để nạp được điều đó vào đầu mình, người ta vẫn sẽ cần một khoảng thời gian đáng kể.

Luận điểm của các tín đồ AI

1. "Hãy tưởng tượng bạn có một đội ngũ gồm 10 lập trình viên trung cấp/cao cấp. Các tác nhân AI cũng tương tự như vậy thôi"

Không, không hề giống nhau. Tôi đã có kinh nghiệm làm trưởng nhóm khoảng 2.5 năm. Không phải quá nhiều, nhưng để đưa ra kết luận và chỉ ra sự khác biệt thì không khó đối với tôi:

1. Trách nhiệm. Con người thực sự chịu trách nhiệm về công việc của mình. Mỗi thành viên trong đội ngũ đều có động lực (bằng lương) và áp lực (bằng các khoản phạt tiềm ẩn hoặc nguy cơ sa thải). Còn trong cuộc sống là các khoản vay mua nhà, mua xe, các nhu cầu cá nhân, v.v. Động lực và áp lực của họ buộc họ phải gánh vác trách nhiệm đó. Lập trình viên sẽ không nói câu "Ôi, bạn đúng rồi, đây mới là giải pháp đúng" tới 10 lần trong vòng một tiếng đồng hồ.

2. Tính dự đoán được. Từ yếu tố thứ nhất sẽ suy ra tính dự đoán được. Mỗi thành viên trong đội ngũ sẽ trở nên dễ đoán biết sau một khoảng thời gian nhất định (khoảng thời gian thử việc). Trưởng nhóm sẽ hiểu được trình độ kỹ thuật, tốc độ làm việc, mức độ tương tác trong quá trình phát triển và hàng loạt đặc điểm khác. Bản thân các thành viên cũng không muốn mình trở thành người vô định hướng, bất thường. Do đó, trưởng nhóm biết có thể kỳ vọng gì từ một con người. Ngược lại, LLM hoàn toàn không thể đoán trước và hỗn loạn tối đa. Nó quên bối cảnh, nó lặp lại chính những lỗi cũ, nó không biết cách rút lui. Còn các bản cập nhật thì chỉ làm tăng thêm sự hỗn loạn.

2. "Tất cả mọi người đều dùng thì chúng ta cũng bắt buộc phải dùng"

Đây là hội chứng sùng bái hình thức thông thường, các lập luận sẽ không cứu vãn được. Nhưng xin vui lòng, chúng ta hãy thử đặt ra nhiều câu hỏi hơn một chút trước khi mang một thứ gì đó về áp dụng cho mình.

3. "Nhưng rõ ràng LLM giúp đẩy nhanh tốc độ phát triển mà. Mặc kệ chuyện gì sẽ xảy ra với dự án/dịch vụ sau 3-6-9 tháng nữa, hiện tại tất cả mọi người đều vui vẻ và hài lòng là được"

Không, tôi không hài lòng. Tôi thấy mệt mỏi khi phải đánh giá các yêu cầu hợp nhất lên tới hàng ngàn dòng khác biệt. Tôi thấy đau lòng khi không còn những con người thực sự hiểu mã nguồn nữa. Và điều quan trọng nhất là niềm vui công việc. Niềm vui từ việc tạo mã tự động nằm ở đâu chứ? Khi viết mã bằng tay, tôi liên tục nhận được một lượng dopamine nhất định (để bù lại hàng tấn cortisol căng thẳng nhận được từ thời còn là lập trình viên sơ cấp/trung cấp).

Hàng tấn mã nguồn không một ai hiểu sẽ ảnh hưởng trực tiếp đến doanh nghiệp và sản phẩm. Đường cong khả năng bảo trì (maintainability), sau một thời gian đi ngang, sẽ vọt thẳng lên trời. Và thế là việc phát hành các tính năng ngày càng bị trì hoãn lâu hơn. Lỗi xuất hiện thường xuyên hơn, còn sửa chúng thế nào thì không ai hiểu nổi. Một doanh nghiệp lành mạnh, bình thường rõ ràng cũng cần tính dự đoán được từ dự án và quá trình phát triển giống như cần nước vậy thôi.

Các trường hợp ranh giới

Ở đây thì mọi chuyện phức tạp hơn. Tôi sẽ xếp vào nhóm này trường hợp: LLM viết mã, nhưng lập trình viên vẫn đánh giá mã của mình ở mức độ tương đối. Trước những lời phản đối về việc số lượng dòng mã tăng lên trong các yêu cầu hợp nhất và việc thường xuyên phải viết lại cùng một đoạn mã, họ sẽ trả lời kiểu như: "Cứ đọc lướt qua bản yêu cầu hợp nhất thôi", "Mô-đun này không quan trọng đến thế đâu", v.v.

Theo tôi, trường hợp này đối với sản phẩm vẫn rất rủi ro. Có chăng chỉ có thể chấp nhận được đối với các dịch vụ chỉ cần viết một lần rồi quên đi, chứ không thể hơn được. Xác suất xảy ra lỗi chắc chắn sẽ tăng lên, ý nghĩa của việc đánh giá mã bị tiêu tan. Trách nhiệm có thể bắt đầu bị đùn đẩy, mờ nhạt đi. Chúng ta có thể bắt đầu nghe thấy những câu đại loại như: "Do con LLM nó gợi ý đoạn mã lỗi đấy thôi", "Con LLM làm sai cấu hình (config) rồi", v.v.

Tôi cho rằng trách nhiệm luôn luôn phải thuộc về lập trình viên. Trong trường hợp xảy ra sự cố đến từ các công cụ khác, cho dù đó là CI/CD, các thành phần hạ tầng hay thậm chí là trình soạn thảo mã – thì lập luận kiểu đó mới hợp lý. Chúng ta tin tưởng vào các đồng nghiệp, vào thời gian tồn tại của dự án, vào những người duy trì hệ thống, vào các công ty, v.v. và hiểu rằng không có phần mềm nào là không có lỗi. Tuy nhiên, chúng ta vẫn tiếp tục tin tưởng cho đến một điểm tới hạn nào đó. Điểm tới hạn có thể đơn giản là công cụ đó không chịu nổi mức tải đặc thù của sản phẩm hiện tại. Nhưng ít ra chúng ta vẫn có phản hồi từ những con người thực tế rằng trong các trường hợp còn lại, công cụ đó hoạt động tốt.

Nhưng với mã do LLM tạo ra, chúng ta không thể cho phép mình làm như vậy – chúng ta không có các công cụ để đánh giá rủi ro và xác suất của mã nguồn lỗi. Và tôi tin rằng, bất kỳ sự mờ nhạt nào về mặt trách nhiệm trong trường hợp này đều dẫn đến các rủi ro và rắc rối, xét cả về góc độ mức độ hiểu sản phẩm của lập trình viên lẫn mức độ tin tưởng nói chung đối với lập trình viên đó.

Kết luận

LLM không ổn định. Không có các công cụ cho phép xác định/nâng cao/làm việc với mức độ tin cậy từ LLM. Chúng ta đã chứng kiến điều này một năm trước với xu hướng Phát triển phần mềm dựa trên kiểm thử bằng AI (Test-Driven AI Development), điều mà tôi không muốn bình luận hay nghiên cứu vì nó đã biến mất như một bong bóng. Ngày hôm nay chúng ta có Phát triển phần mềm dựa trên đặc tả (SPEC-Driven Development), thứ mà tôi cũng không đặt nhiều kỳ vọng, bởi vì một lần nữa, tôi không thấy mỗi lập trình viên đều đã trở thành chủ doanh nghiệp và cũng không thấy có làn sóng các dự án chất lượng trong thế giới nguồn mở.

Với việc sử dụng LLM làm trình tạo kho mã chính, mức độ tin tưởng vào lập trình viên cũng như mức độ hiểu biết về kho mã, về các vấn đề và về sản phẩm của chính lập trình viên đó sẽ bị mất đi. Điều này ảnh hưởng tiêu cực đến gánh nặng nhận thức, có thể làm tăng xác suất kiệt sức (burnout). Có những rủi ro không hề nhỏ khi sử dụng trên các dự án dài hạn.

Tôi xin được lặp lại câu nói trong bài viết: Chúng ta hãy thử đặt ra nhiều câu hỏi hơn một chút trước khi mang một thứ gì đó mới mẻ vào quá trình phát triển phần mềm.

Danh mục tài liệu tham khảo

• Peter Naur. Programming as Theory Building. Microprocessing and Microprogramming, Vol. 15, Issue 5, 1985, pp. 253–261. — pages.cs.wisc.edu/~remzi/Naur.pdf

• Teun A. van Dijk, Walter Kintsch. Strategies of Discourse Comprehension. Academic Press, 1983. — discourses.org

• Nancy Pennington. Stimulus Structures and Mental Representations in Expert Comprehension of Computer Programs. Cognitive Psychology, Vol. 19, Issue 3, 1987, pp. 295–341. — doi.org/10.1016/0010-0285(87)90007-7