Vậy đấy, tôi đã lập trình tô màu nhật ký theo phong cách riêng của mình — và tôi cảm thấy hài lòng về điều đó.

 

Công cụ tô màu nhật ký Nginx của tôi đang hoạt động, hiển thị lưu lượng truy cập của Space City Weather vào một chiều thứ Tư điển hình. Ở đây, tôi đang chạy hai phiên bản, một cho khách truy cập IPv4 và một cho IPv6. (Theo mặc định, tất cả lưu lượng truy cập đều được hiển thị, nhưng việc chia nhỏ như thế này giúp mắt tôi dễ dàng quan sát hơn.) Nguồn ảnh: Lee Hutchinson

Tại sao lại cần một công cụ tô màu nhật ký? Có hai lý do. Thứ nhất, và quan trọng nhất đối với tôi, là vì tôi cần xem xét một đống nhật ký máy chủ web khổng lồ, và các giải pháp tô màu nhật ký có sẵn trên thị trường không thể tùy chỉnh đến mức độ tôi mong muốn. Việc tự viết mã một công cụ phù hợp chính xác với nhu cầu của mình đã khiến tôi hài lòng.

Thứ hai, và gần như quan trọng không kém, là đây là một dự án nhỏ. Công cụ tô màu cuối cùng chỉ là một đoạn mã Python đơn tệp với khoảng 400 dòng. Toàn bộ mã nguồn, cộng với các lời nhắc và hướng dẫn tiếp theo, đều nằm gọn trong cửa sổ ngữ cảnh của Claude Code. Đây không phải là một ứng dụng trải rộng trên hàng chục hoặc hàng trăm hàm trong nhiều tệp, giúp việc kiểm tra trở nên dễ dàng (ngay cả đối với tôi).

Giới thiệu sơ lược: Tôi đảm nhiệm việc lưu trữ web cho trang dự báo thời tiết khu vực Houston của đồng nghiệp Eric Berger, có tên là Space City Weather . Đó là một trang web WordPress tự lưu trữ, chạy trên máy chủ AWS EC2 t3a.large , được Cloudflare hỗ trợ bằng tính năng Tối ưu hóa nền tảng tự động WordPress của Cloudflare .

Space City Weather cũng sử dụng Discourse tự lưu trữ để bình luận , thay thế cho hệ thống bình luận mặc định của WordPress ở cuối các bài đăng thời tiết hàng ngày của Eric thông qua plugin WP-Discourse . Tuy nhiên, kể từ khi tích hợp Discourse vào trang web vào tháng 8 năm 2025, tôi đã gặp phải một sự cố không thường xuyên, đôi khi - nhưng không phải lúc nào cũng vậy - một bài đăng dự báo hàng ngày sẽ được Cloudflare lưu vào bộ nhớ cache với khu vực bình luận mặc định cũ, bị vô hiệu hóa của WordPress được gắn ở cuối bài thay vì khu vực bình luận Discourse mới đẹp mắt. Hàng trăm khách truy cập sau đó sẽ thấy một phiên bản bài đăng không có hệ thống bình luận hoạt động cho đến khi tôi tự tay xóa trang cũ hoặc cho đến khi trang đạt đến thời gian tối đa do APO của Cloudflare quy định và tự động xóa.

Lỗi này có thể âm ỉ trong nhiều tuần hoặc nhiều tháng, rồi đột nhiên lại tái diễn trong nhiều ngày liên tiếp. Việc vô hiệu hóa bộ nhớ cache biên trên các bài đăng mới được cho là sẽ tự động được kích hoạt bởi plugin WordPress chính thức của Cloudflare , và thực tế, nó thường hoạt động tốt — nhưng "thường" không có nghĩa là "luôn luôn".

Vì không tìm thấy manh mối rõ ràng nào về lý do tại sao điều này xảy ra, tôi đã tham khảo ý kiến ​​của một vài chuyên gia quản trị hệ thống (LLM) và hỏi về các giải pháp khả thi. Giải pháp mà tôi lựa chọn là nhờ một trong số họ viết một plugin nhỏ bằng PHP (lập trình theo phong cách riêng!) buộc WordPress phải thêm tiêu đề “KHÔNG LƯU VÀO BỘ NHỚ CACHE!” vào các trang bài viết cho đến khi nó xác minh rằng Discourse đã liên kết phần bình luận với bài viết đó. (Độc giả tò mò có thể xem plugin này tại đây .)

Cách này "giải quyết" vấn đề bằng cách ngăn chặn hành vi gây ra sự cố, nhưng nó không giúp tôi xác định hoặc khắc phục vấn đề gốc rễ thực sự. Tôi chuyển sự chú ý sang việc khác trong vài tháng. Một ngày vào tháng 12, khi đang cập nhật mọi thứ, tôi quyết định tạm thời vô hiệu hóa plugin mu để xem mình có còn cần nó nữa không. Suy cho cùng, đôi khi vấn đề tự biến mất, phải không? Máy tính thật kỳ lạ!

Than ôi, lần tiếp theo Eric đăng bài về thời tiết ở Thành phố Vũ trụ, bài viết lại hiện lên mà không có phần bình luận trên Discourse, thay vào đó là biểu mẫu bình luận của WordPress (có vẻ như đã bị vô hiệu hóa) ở phía dưới. Rõ ràng, lỗi vẫn còn tiếp diễn.

Sự gián đoạn vô tận

Bạn đã bao giờ gặp phải tình huống khó xử khi khắc phục sự cố chập chờn chưa? Một thứ gì đó không hoạt động, bạn thực hiện một thay đổi, nó đột nhiên hoạt động, rồi dù không thực hiện thêm bất kỳ thay đổi nào, nó lại tự nhiên bị lỗi trở lại.

Quá trình này khiến bạn nghi ngờ những giả định cơ bản, chẳng hạn như, “Mình có thực sự biết cách sử dụng máy tính không?” Bạn cảm thấy như mình thực sự đang mất trí. Giai đoạn cuối cùng của quá trình này là vòng xoáy tử thần hủy diệt, nơi bạn bắt đầu tự hỏi những câu như, “Mình có cần phải kiểm tra lại các phương pháp khắc phục sự cố của mình không? Máy chủ của mình có hoạt động không? Phải chăng thế giới mô phỏng mà chúng ta đang sống cuối cùng cũng sụp đổ và chính thực tại đang trêu đùa mình?!”

Trong trường hợp này, tôi không thể tái hiện được lỗi theo yêu cầu, bất kể tôi đã thử bao nhiêu lần. Tôi không tìm thấy bất kỳ điểm chung cụ thể, có thể xác định được giữa những ngày mọi thứ hoạt động tốt và những ngày mọi thứ gặp sự cố.

Đã đến lúc khởi động VSCode và giả vờ làm lập trình viên. Tôi thiết lập một dự án mới, thực hiện nghi thức triệu hồi ma quỷ để gọi Claude Code, chuyển nó sang " chế độ lập trình " và bắt đầu.

Tôi viết vào ô gợi ý: “Tôi muốn tìm hiểu về việc tạo một công cụ tô màu nhật ký Nginx. Tôi không biết nên sử dụng ngôn ngữ nào. Tôi muốn ưu tiên hiệu quả và hiệu suất trong mã, vì tôi sẽ chạy nó trực tiếp trong môi trường sản xuất và tôi không thể để nó tạo thêm bất kỳ tải trọng nào.” Tôi đã sao chép một bản sao đã được cắt bớt và loại bỏ địa chỉ IP của nhật ký truy cập Nginx ngày hôm qua vào thư mục dự án.

“Hãy xem tập tin access.log trong thư mục dự án để tham khảo ví dụ về dữ liệu mà chúng ta sẽ tô màu. Bạn có thể thử nghiệm bằng cách sử dụng tập tin đó,” tôi đã viết.

 

Visual Studio Code, với sự tích hợp LLM mang tính tác nhân, tạo ra mã nguồn bằng cảm hứng. Nguồn ảnh: Lee Hutchinson

Luôn sẵn lòng giúp đỡ, Claude Code xử lý lời nhắc và dữ liệu ví dụ trong vài giây, rồi bắt đầu xuất ra kết quả. Nó đề xuất Python cho việc tô màu nhật ký của chúng ta vì ngôn ngữ này có hỗ trợ biểu thức chính quy (regex) hoàn thiện — và để giữ cho mã nguồn dễ đọc hơn đối với một người kém hiểu biết như tôi. Quá trình "lập trình theo cảm hứng" thực tế kéo dài hai phiên trong hai ngày, vì tôi đã dùng hết số lượt sử dụng Claude Code của mình trong phiên đầu tiên (một mối nguy hiểm thực sự của việc lập trình theo cảm hứng!) và phải đợi mọi thứ được thiết lập lại.

“Này anh bạn, LNAV và Splunk đều có rồi, anh có vấn đề gì vậy?”

Vâng, vâng, một công cụ tô màu nhật ký thì hơi cầu kỳ và nhàm chán, và tôi đang đi trên con đường đã quá quen thuộc rồi.  Thực tế là tôi đã dành chút thời gian xem xét các công cụ hiện có—đặc biệt là  lnav , công cụ đáp ứng hầu hết các nhu cầu của tôi.  Nhưng tôi không chỉ muốn đáp ứng hầu hết các yêu cầu. Tôi muốn đáp ứng tất cả . Tôi muốn một công cụ được thiết kế riêng, và tôi muốn có nó mà không phải trả giá bằng câu hỏi " liệu có đáng bỏ thời gian ra không? ". (Hoặc, có lẽ, tôi muốn cảm thấy thời gian của người quản lý dự án bị lãng phí chứ không phải của tôi, vì cuối cùng nỗ lực này đã mất đến hai ngày để lập trình.)

Còn về hai ngày đó: Việc lập trình và vận hành một bộ tô màu cơ bản chỉ mất khoảng 10 phút và có lẽ hai vòng gợi ý. Nó cực kỳ dễ dàng. Phần tốn nhiều thời gian và sức mạnh xử lý nhất là ở việc tinh chỉnh kết quả ban đầu sao cho chính xác như ý muốn của tôi.

Đó chính là điểm quyến rũ thực sự của lập trình cảm xúc – sự dễ dàng khi yêu cầu LLM thực hiện những thay đổi hoặc cải tiến nhỏ và dường như không tốn chi phí hay hậu quả nào khi thực hiện những thay đổi đó. Cảm giác như bạn đang ở trên tàu Enterprise-D , trò chuyện với máy tính của tàu, cùng nhau giải quyết vấn đề với Geordi và Data đứng ngay phía sau bạn. Thật sự rất tuyệt khi nói, “Ừm, được rồi, giờ hãy thiết lập để tôi chỉ hiển thị các máy khách IPv4 hoặc IPv6 bằng một công tắc dòng lệnh,” và máy móc thực hiện điều đó . (Còn tuyệt hơn nữa nếu bạn đưa ra yêu cầu trong khi vung chân qua lưng ghế để có thể ngồi theo kiểu Riker !)

 

Đây là một vài ví dụ về những việc tôi đã yêu cầu máy móc thực hiện, cùng với một hình ảnh minh họa nhỏ về cảm xúc của tôi sau tất cả những điều đó. Nguồn: Lucasfilm / Disney

Thành thật mà nói, cảm giác thật phấn khích, giống như kiểu "SỨC MẠNH VÔ HẠN!" của Hoàng đế Palpatine vậy. Nó phá bỏ một rào cản mà tôi nghĩ sẽ không bao giờ bị phá bỏ – hay nói đúng hơn, một rào cản mà tôi nghĩ mình sẽ không bao giờ có thời gian, động lực hay khả năng để tự mình vượt qua.

Cuối cùng, sau vài ngày thử nghiệm và điều chỉnh – bao gồm cả một vài lần trao đổi qua lại về việc “Công cụ tô màu này có hiệu quả không, và liệu nó có gây tải cho hệ thống nếu chạy trong môi trường sản xuất không?” – trong đó LLM đã giảm chi phí cho việc khớp biểu thức chính quy và đảm bảo vòng lặp chính không quá nặng nề, tôi đã có được một công cụ đáp ứng chính xác những gì tôi muốn .

Cụ thể, hiện tại tôi đã có một công cụ tô màu nhật ký (log colorizer) với các chức năng sau:

• Hỗ trợ nhiều định dạng tệp nhật ký của Nginx (và Apache).
• Tô màu các đối tượng bằng cách sử dụng mã ANSI 256 màu, cho kết quả hiển thị gần như giống nhau trong các ứng dụng terminal khác nhau.
• Sắp xếp tên máy chủ và địa chỉ IP thành các cột có độ dài cố định để dễ dàng quét.
• Tô màu các mã trạng thái HTTP và trạng thái bộ nhớ đệm (với các màu sắc có thể tùy chỉnh)
• Áp dụng các màu khác nhau cho URI yêu cầu tùy thuộc vào tài nguyên được yêu cầu.
• Có các màu sắc và định dạng cảnh báo cụ thể để làm nổi bật các yêu cầu không phải HTTPS hoặc các điều bất thường khác.
• Có thể áp dụng các màu khác nhau cho các địa chỉ IP cụ thể (để tôi dễ dàng phân biệt yêu cầu của Eric hoặc của tôi).
• Có thể giới hạn đầu ra chỉ hiển thị các máy chủ IPv4 hoặc IPv6.

…và, điều đáng nhắc lại là, mọi thứ trông đúng như tôi muốn và hoạt động đúng như tôi mong muốn. Đây là một bức ảnh chụp thực tế khác!

 

Sản phẩm cuối cùng. Có thể ngoại hình cô ấy không bắt mắt lắm, nhưng cô ấy có những tố chất quan trọng đấy, nhóc ạ. Nguồn ảnh: Lee Hutchinson

Đã phát hiện vấn đề

Với công cụ tô màu nhật ký tiện dụng trong tay, tôi kiên nhẫn chờ đợi lỗi "vùng bình luận sai" tái diễn. Tôi không phải chờ lâu, và chỉ trong vài ngày, tôi đã tìm ra nguyên nhân gốc rễ. Nó đã ở đó suốt, chỉ cần tôi chịu dành chút thời gian tìm kiếm. Và đây là nguyên nhân:

 

Đã phát hiện vấn đề. Lưu ý rằng AppleNewsBots đã can thiệp vào bài đăng mới được xuất bản trước khi Discourse kịp xử lý và phiên bản cuối cùng của trang với phần bình luận đã sẵn sàng. Nguồn ảnh: Lee Hutchinson

Tóm lại: Vấn đề là do Apple gây ra. (Thực ra không hẳn vậy. Nhưng cũng có phần nào đó.)

Nói ngắn gọn hơn: Tôi đã làm mờ địa chỉ IP của Eric, nhưng nó có màu xanh đậm, vì vậy bất kỳ chỗ nào trong hình ảnh trên mà bạn thấy một vệt mờ màu xanh đậm, đó chính là Eric. Trong khoảng 12 giây được hiển thị ở đây, bạn đang thấy Eric nhấn nút “xuất bản” trên bản dự báo hàng ngày của mình — đó là sự kiện “POST” ở ngay trên cùng của cửa sổ. Các sự kiện tiếp theo từ địa chỉ IP của Eric là trình duyệt của anh ấy thực hiện cuộc hội thoại tiêu chuẩn sau khi xuất bản với WordPress để hiển thị thông báo “bài viết đã được xuất bản thành công” và sau đó vẽ lại trình chỉnh sửa khối WP.

Bên dưới bài đăng của Eric, bạn có thể thấy máy chủ Discourse (với địa chỉ IP màu cam) thông báo cho WordPress rằng nó đã tạo một luồng bình luận Discourse mới cho bài đăng của Eric, sau đó lấy những thứ cần thiết để sao chép bài đăng của Eric làm bài mở đầu cho luồng đó. Bạn có thể thấy nó thực hiện các yêu cầu GET cho bài đăng thực tế và cả cho các hình ảnh được nhúng trong bài đăng. Khoảng một giây sau khi Eric nhấn "xuất bản", luồng Discourse của bài đăng mới đã sẵn sàng và được gắn vào bài đăng của Eric.

À, nhưng hãy để ý xem điều gì khác xảy ra trong một giây đó.

Để giúp mở rộng phạm vi tiếp cận của Space City Weather, chúng tôi đăng tải chéo tất cả các bài viết của trang web lên Apple News, sử dụng một plugin phổ biến của Apple News (thực tế là cùng một plugin mà Ars sử dụng). Và ngay tại đó, với hai yêu cầu GET ngay sau yêu cầu POST của Eric, vấn đề nằm ở chỗ: Bạn đang chứng kiến ​​đội tiên phong của đội quân bot thu thập tin tức đói khát của Apple News, được triệu tập bởi cùng một sự kiện "đăng tải", xông vào và yêu cầu một bản sao của bài đăng mới trước khi Discourse có cơ hội thực hiện công việc của nó.

Lee mất phương hướng

Vậy là tôi đã có công cụ tô màu nhật ký, và tôi đã tìm ra vấn đề của mình. Sau khi để công cụ tô màu hiển thị trong một cửa sổ theo dõi nhật ký máy chủ web theo thời gian thực, tôi cũng phát hiện ra đủ loại thứ mà trước đây tôi chỉ thỉnh thoảng xem nhật ký không hề hay biết. Ồ, nhìn kìa, có một tuyến đường REST có lẽ nên bị chặn khỏi thế giới bên ngoài! Ồ, nhìn kìa, có một trình thu thập dữ liệu web mà tôi cần đưa vào bộ xử lý WAF của Cloudflare vì nó đang bỏ qua robots.txt! Ồ, nhìn kìa, đây là khu vực mà tôi có thể tinh chỉnh cài đặt bộ nhớ cache fastcgi và cải thiện tỷ lệ truy cập một chút!

Nhưng điều đáng nói về niềm vui khi giải quyết vấn đề là: Giống như mọi niềm vui khác, nguồn gốc của nó là hữu hạn. Niềm vui đến từ chính quá trình giải quyết vấn đề, và ngay cả khi tất cả các vấn đề của tôi đã được giải quyết và các hệ thống đều hoạt động tốt, tôi vẫn khao khát thêm niềm vui. Vì vậy, bản chất của tôi là luôn tạo ra những vấn đề mới để giải quyết.

Tôi quyết định rằng vấn đề tiếp theo tôi muốn giải quyết là tìm ra cách để trình tô màu nhật ký của tôi hiển thị đầu ra mà không cần xuống dòng đối với các dòng dài — vì việc xuống dòng sẽ làm mất đi sự phân tách gọn gàng giữa các cột dữ liệu nhật ký. Thay vào đó, tôi muốn cửa sổ terminal của mình tự động thêm thanh cuộn ngang khi cần thiết, và nếu tôi muốn xem toàn bộ nội dung của một dòng dài, tôi có thể kéo thanh cuộn để xem xét.

Những độc giả tinh ý sẽ nhận thấy hai điều ở điểm này: thứ nhất, giờ đây tôi thực sự đang tái tạo lại  LNAV, nhưng tệ hơn và ngu ngốc hơn nhiều. Thứ hai, và quan trọng hơn, hành vi xuống dòng đúng ra là một chức năng của ứng dụng terminal , chứ không phải dữ liệu được hiển thị bên trong nó, và cách tiếp cận của tôi đã sai lầm ngay từ những nguyên tắc cơ bản. (Thực tế, đây chính xác là loại yêu cầu có thể và nên bị bác bỏ trên StackOverflow — và quả thực, tìm kiếm ở đó cho thấy nhiều ví dụ về chính xác điều này đang xảy ra .)

Nhưng sức hút của việc ra lệnh cho máy móc và sau đó chứng kiến ​​máy móc biến những lời nói của tôi thành phép màu hoạt động hiệu quả quá lớn—chắc chắn chúng ta có thể lập trình để giải quyết vấn đề này! Với LLM, chúng ta có thể lập trình để giải quyết mọi vấn đề! Phải không?

Cuối cùng, sau nhiều lần tinh chỉnh yêu cầu, Claude đã tạo ra thứ tôi yêu cầu: một kịch bản Python riêng biệt, chấp nhận đầu vào được truyền qua đường ống và tạo ra một cái gì đó giống như khung nhìn—tôi không biết, tôi không biết lập trình, nhớ chứ?—và trong khung nhìn đó, tôi có thể cuộn xung quanh. Có vẻ như nó hoạt động rất tốt!

Vấn đề bắt đầu xuất hiện khi tôi thực sự thử cuộn chuột quá xa—và khi nói "vấn đề", ý tôi là "CPU của máy chủ web nóng lên như một cây thông Noel đang bốc cháy".

“Vấn đề là,” tôi nói với LLM. “Khi cuộn ngang, trình bao bọc nhật ký chiếm gần 100% lõi CPU của máy chủ. Chúng ta có thể đánh giá xem làm thế nào để biến công cụ này thành công cụ không ảnh hưởng đến CPU không?”

“Công cụ này phải phân tích ANSI, cắt các dòng và vẽ lại khi bạn cuộn,” nó trả lời bằng giọng điệu mà tôi cho là mỉa mai và hài hước. “Điểm nghẽn là việc vẽ lại màn hình cộng với quét toàn bộ chiều rộng của tất cả các dòng trên mỗi dòng mới hoặc khi nhấn phím lặp lại. Mỗi dòng mới kích hoạt việc vẽ lại toàn bộ màn hình với số dòng bằng term_height, cộng với visible_width() trên toàn bộ vùng đệm. Giữ phím mũi tên sẽ tạo ra các lần lặp lại nhanh, mỗi lần thực hiện vẽ lại toàn bộ và cắt mỗi dòng.”

Tôi vô cùng thất vọng.

“Việc không cần CPU là không thể đạt được,” LLM tiếp tục, “nhưng có những phương pháp ít gây ảnh hưởng đến hiệu suất.”

Tinh thần tôi phấn chấn hơn một chút, và chúng tôi bắt đầu làm việc chăm chỉ hơn—nhưng có lẽ LLM hơi lạc quan về những “phương pháp ít tác động” đó. Chúng tôi đã tiêu tốn thêm vài ngày token để cải thiện hiệu suất—mà tôi không có bất kỳ đóng góp thực tế nào vì đến lúc này, tôi đã vượt quá khả năng của mình để mày mò với mã Python và hiểu những gì LLM đang làm. Cuối cùng, chúng tôi đã gặp phải bế tắc.

 

Nếu bạn lắng nghe kỹ, bạn sẽ nghe thấy âm thanh của những kỳ vọng của tôi tan vỡ khi đối mặt với thực tế.

Thay vì bỏ cuộc, tôi tiếp tục cố gắng, vì hiệu ứng chi phí chìm chỉ dành cho người khác . Tôi hướng dẫn LLM chuyển hướng và giúp tôi chạy tập lệnh hiển thị nhật ký cục bộ, để máy tính để bàn của tôi với nhiều lõi và chu kỳ CPU dư thừa sẽ gánh vác gánh nặng làm lại/vẽ lại chứ không phải máy chủ web.

Thay vì kéo dài câu chuyện này thêm nữa, tôi sẽ nhờ đến tài năng của Giám đốc Sáng tạo của Ars, Aurich Lawson, để trình bày câu chuyện về cách mọi việc diễn ra dưới dạng một bức tranh ghép vui nhộn, cho thấy sự thúc giục ngày càng mất kiểm soát của tôi đối với LLM để giải quyết các vấn đề mới phát sinh khi cố gắng chạy một kịch bản trên đầu ra ssh khi sử dụng xác thực khóa và sudo:

 

Các bà mẹ ơi, đừng để con mình lớn lên trở thành những người chuyên lập trình cảm xúc. (Nguồn ảnh: Aurich Lawson)

Kết cục cay đắng

Vậy là, thất bại trong nỗ lực làm chính xác những gì mình muốn theo đúng cách mình muốn, tôi cầm công cụ tô màu nhật ký và về nhà. (Đoạn mã hiển thị nhật ký bị lỗi cũng được đăng trên GitHub cùng với công cụ tô màu nếu ai muốn chỉ trích và cười nhạo nỗ lực của tôi . Mã đó có tốt không? Ai biết?! Tôi thì không!) Tôi đã giành được chiến thắng lớn và tìm ra nguyên nhân gốc rễ của vấn đề, và như vậy là đủ đối với tôi—ít nhất là hiện tại.

Còn về "chiến thắng lớn" đó - cuối cùng cũng phân tích được nguyên nhân gốc rễ của vấn đề bộ nhớ đệm WordPress-Discourse-Cloudflare - tôi cũng nhận ra rằng có lẽ tôi không cần đến một công cụ tô màu nhật ký tự động để làm được điều đó. Bằng chứng đã có sẵn trong nhật ký Nginx, dù nó có được trình bày cho tôi dưới dạng màu sắc bắt mắt hay không. Liệu tôi có thực sự sử dụng cảm giác thích thú khi tự tạo động lực cho bản thân bằng cách tự mình tìm kiếm nhật ký không? ("Ôi, bản thân ơi, nhìn công cụ tô màu nhật ký mới tuyệt vời này xem! Chắc chắn bạn có thể dùng nó để giải quyết đủ loại vấn đề! Đúng rồi, bản thân ơi! Cùng làm thôi!") Rất có thể. Tôi biết cách tự tạo động lực cho mình, và đôi khi bắt đầu một nhiệm vụ cần một chút mánh khóe tinh thần.

Vòng mã hóa cảm xúc này và kết quả hỗn loạn của nó đã củng cố đánh giá cá nhân của tôi về LLMs — một đánh giá không thay đổi nhiều ngay cả khi các khả năng chủ động được bổ sung vào bộ công cụ.

Các mô hình ngôn ngữ lập trình (LLM) có thể rất tuyệt vời nếu bạn sử dụng chúng để làm điều gì đó mà bạn hiểu khá rõ. Nếu bạn đủ quen thuộc với một vấn đề để hiểu các phương pháp phổ biến được sử dụng để giải quyết nó, và bạn hiểu rõ lĩnh vực đó đến mức có thể phát hiện ra những ảo tưởng và sự bịa đặt không thể tránh khỏi của LLM, và bạn hiểu rõ nhiệm vụ đang thực hiện đến mức có thể hướng LLM tránh khỏi những ngõ cụt và ngăn nó lặp lại những việc đã có, và bạn có phương tiện để xác nhận kết quả đầu ra của LLM, thì những công cụ này, thành thật mà nói, khá tuyệt vời.

Nhưng ngay khi bạn bước ra khỏi lĩnh vực chuyên môn của mình và bắt đầu sử dụng chúng cho những công việc mà bạn không thực sự hiểu rõ, hoặc nếu bạn không đủ quen thuộc với vấn đề để nhận ra những giải pháp tồi, hoặc nếu bạn không thể kiểm tra kết quả đầu ra của nó, thì ôi, hỡi độc giả thân mến, cầu Chúa thương xót linh hồn bạn. Và cả dự án tội nghiệp của bạn nữa, bởi vì nó sẽ trở thành một mớ hỗn độn.

Những công cụ hiện có chỉ có thể giúp bạn nếu bạn đã có sẵn năng lực. Chúng không thể mang lại cho bạn năng lực đó. Tốt nhất, chúng có thể tạo ra ảo tưởng nguy hiểm về sự thành thạo; tệ nhất thì ai mà biết được? Mất dữ liệu, rò rỉ thông tin cá nhân, lãng phí thời gian, nguy cơ kiện tụng nếu dự án đủ lớn – danh sách những rủi ro “tệ nhất” cứ kéo dài mãi!

Hòa mình vào không khí hay không hòa mình vào không khí?

Công cụ tô màu nhật ký không phải là dự án lập trình "vibe coding" đầu tiên cũng không phải là cuối cùng mà tôi từng thực hiện. Mặc dù tôi không năng suất như Benj , nhưng trong vài tháng qua, tôi đã sử dụng LLM cho một loạt các tác vụ lập trình cần thiết mà tôi không thể tự làm được—thường đi ngược lại lời khuyên của chính tôi ở trên về việc chỉ nên sử dụng chúng trong những lĩnh vực mà bạn đã có một số kỹ năng nhất định. Tôi đã sử dụng nó để tạo ra các plugin PHP nhỏ cho WordPress, biểu thức chính quy, tập lệnh bash, và thành tựu lớn nhất hiện tại của tôi: một trình chỉnh sửa file lưu cho một trò chơi MS-DOS cũ (bằng cả Python và Swift!). Và tôi đã rất vui khi làm những việc này, ngay cả khi toàn bộ những khu rừng mưa nhiệt đới rộng lớn bị đốt cháy để phục vụ cho những cuộc phiêu lưu của tôi.