Claude Fable liên tục hành động một cách chủ động

 (simonwillison.net)
3 điểm bởi GN⁺ 5 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Kết quả thử nghiệm trong 2 ngày cho thấy mô tả Claude Fable 5 là "relentlessly proactive" là phù hợp
  • Chỉ với ảnh chụp màn hình và một dòng prompt, nó đã chạy máy chủ phát triển cục bộ, thao tác trình duyệt thật và chèn mã đo đạc để lần ra nguyên nhân của lỗi CSS
  • Fable đã thử tái hiện lỗi qua Playwright, Firefox, WebKit và Safari, rồi sau khi thất bại đã tự thiết lập tự động hóa ảnh chụp màn hình bằng cách tìm các cửa sổ trình duyệt thật
  • Để kiểm thử hộp thoại modal mở bằng phím /, nó đã chèn JavaScript vào template Datasette và tạo ra trạng thái cần thiết bằng cách phát sinh sự kiện bàn phím sau khi cửa sổ tải xong
  • Để lấy các giá trị đo bên trong trang, nó đã tạo máy chủ thu thập CORS dựa trên Python http.server và lưu thông tin <textarea> bên trong shadow DOM của Web Component dưới dạng JSON
  • Một tác nhân lập trình mạnh có thể làm những việc người dùng có thể làm trong terminal, nên việc chạy ngoài sandbox làm tăng rủi ro prompt injection và rò rỉ dữ liệu

Quá trình gỡ lỗi của Claude Fable 5

  • Bắt đầu điều tra thanh cuộn ngang thừa xuất hiện trong prompt chat của menu nhảy trên Datasette Agent
  • Claude Fable 5 đã chủ động huy động nhiều kỹ thuật khác nhau để đạt mục tiêu
  • Đầu vào là một ảnh chụp màn hình và prompt một dòng Look at dependencies to help figure out why there is a horizontal scrollbar here
  • Vì cho rằng nguyên nhân có thể nằm ở các phụ thuộc của Datasette Agent, đặc biệt là chính Datasette, tác giả yêu cầu nó xem mã phụ thuộc trước
  • Claude Code đã mở một cửa sổ Firefox thông thường và điều hướng tới hộp thoại đó mà không cần chỉ thị tự động hóa trình duyệt rõ ràng, sau đó còn mở cả Safari để tiếp tục khám phá

Tự động hóa ảnh chụp màn hình trình duyệt

  • Fable đã tự dựng cách chụp ảnh màn hình cửa sổ trình duyệt bằng uv run --with pyobjc-framework-Quartz
  • Bằng Python, nó duyệt qua mọi cửa sổ trên máy và lọc các cửa sổ Safari có tên chứa chuỗi dự kiến như "textarea"
  • Sau khi tìm được mã định danh số nguyên như 153551, nó dùng CLI screencapture để lưu PNG
  • Nó viết các trang HTML tạm như /tmp/textarea-scrollbar-test.html, mở trong Safari rồi lấy ảnh chụp màn hình
  • Lệnh ví dụ là screencapture -x -o -l 153551 /tmp/safari-cases.png

Tự động mở hộp thoại modal

  • Modal cần kiểm thử chỉ có thể mở bằng cú nhấp hoặc phím tắt bàn phím, và không thấy cơ chế rõ ràng nào để điều khiển chuột hay phím tắt trong Safari
  • Claude đang chạy trong thư mục có mã nguồn ứng dụng và đã hiểu đủ cấu trúc để chạy máy chủ phát triển cục bộ của Datasette
  • Nó thêm JavaScript vào template Datasette để mô phỏng việc nhấn phím / sau khi cửa sổ mở ra
  • Đoạn mã này phát sinh sự kiện keydown cho phím / sau 1,2 giây kể từ khi cửa sổ tải xong, qua đó kích hoạt phím tắt mở modal
<script>  
window.addEventListener("load", function () {  
  setTimeout(function () {  
    document.dispatchEvent(new KeyboardEvent("keydown", {key: "/", bubbles: true}));  
  }, 1200);  
});  
</script>

Thu thập giá trị đo bên trong trang

  • Claude cần chạy JavaScript ngay trong trang để lấy trực tiếp các giá trị đo, và vì vậy đã viết một ứng dụng web riêng nhận dữ liệu qua CORS
  • Nó dùng thư viện chuẩn Python http.server để chạy máy chủ cục bộ tại 127.0.0.1:9999
  • Máy chủ nhận các yêu cầu POST chứa JSON, ghi vào /tmp/diag.json và gửi header Access-Control-Allow-Origin: * để mã từ miền khác cũng có thể giao tiếp
  • Claude chèn JavaScript vào template được tải trong trình duyệt để tìm <textarea> bên trong Web Component <navigation-search>
  • Đoạn mã được chèn đo devicePixelRatio, scrollWidth, clientWidth, whiteSpace, width rồi gửi về máy chủ cục bộ
const host = document.querySelector("navigation-search");  
const ta   = host.shadowRoot.querySelector("textarea");  
const cs   = getComputedStyle(ta);  
fetch("http://127.0.0.1:9999/diag";, {  
  method: "POST",  
  body: JSON.stringify({  
    dpr: window.devicePixelRatio,  
    scrollWidth: ta.scrollWidth, clientWidth: ta.clientWidth,  
    whiteSpace: cs.whiteSpace, width: cs.width,  
  }),  
});

Chuyển sang Opus và xác minh bản sửa

  • Sau khi tìm ra nhiều kỹ thuật, Fable đã vướng vào các guardrail vô hình và bị hạ xuống Opus
  • Opus có thể truy cập toàn bộ lịch sử hội thoại và tiếp tục dùng các kỹ thuật do Fable khai phá
  • Sau đó Opus tìm ra vấn đề, kiểm thử, xác minh rồi hoàn tất commit sửa lỗi
  • Opus cũng tổng hợp các kỹ thuật tự động hóa và ví dụ mã có thể chạy được đã dùng với trình duyệt thật trong phiên vào /tmp/automation-report.md
  • Báo cáo đó được chia sẻ thành gist riêng, và toàn bộ log terminal của Claude Code cũng đã được công khai

Rà soát toàn bộ những gì đã làm

  • Claude Fable 5 và Claude Code đã tìm ra cách chạy máy chủ phát triển cục bộ và còn cấu hình cả các biến môi trường giả cần thiết
  • Nó chạy phiên Playwright Chrome, bật thanh cuộn hiển thị của Chrome bằng defaults write com.google.chrome.for.testing AppleShowScrollBars Always rồi tắt lại sau đó
  • Nó cũng đi qua Firefox và WebKit của Playwright nhưng không tái hiện được lỗi
  • Nó xác định trình duyệt mặc định là Safari và tạo tài liệu HTML textarea-scrollbar-test.html
  • Nó mở tài liệu thử nghiệm trong Firefox thật, còn truy cập osascript bị chặn vì “osascript is not allowed assistive access”
  • Nó tìm ra cách vòng qua bằng pyobjc-framework-Quartz và thiết lập quy trình chụp màn hình dựa trên số cửa sổ
  • Nó thêm JavaScript vào template của trang để phát sinh phím / và nhận dữ liệu JSON qua máy chủ CORS bằng Python
  • Nó đi qua shadow DOM của Web Component để tìm thông tin cần thiết và xác nhận nguyên nhân lỗi trong Safari
  • Nó áp dụng một bản sửa tiềm năng vào template tùy chỉnh, xác nhận hoạt động rồi báo lại cách giải quyết vấn đề

Ước tính chi phí

  • Gói đang dùng là Claude Max giá 100 USD/tháng; Anthropic cho biết sẽ cấp hạn mức hào phóng cho Fable đến ngày 22 tháng 6 rồi sau đó tính theo giá API đầy đủ
  • AgentsView được dùng để theo dõi chi tiêu, và nếu trả toàn bộ giá thì phiên này được tính khoảng 12,11 USD
  • Đầu ra của phiên là 68606, ngữ cảnh tối đa là 113178, các model dùng là claude-fable-5 và claude-opus-4-8
  • Nếu không để mắt kỹ đến chi phí, Fable có thể dễ dàng tiêu khoảng 12 USD tiền token chỉ để tạo ra các cách mới gỡ lỗi CSS

Sự cần thiết của sandbox

  • Quá trình Fable cuối cùng phải dùng đến những cách cực đoan để lấy thông tin cần cho một bản sửa CSS chỉ có hai dòng là rất ấn tượng
  • Tác nhân lập trình có thể làm những việc mà người dùng có thể làm bằng cách gõ lệnh trong terminal, và các frontier model biết rất nhiều kỹ thuật
  • Nếu có chỉ dẫn độc hại, prompt injection trong mã hoặc trong luồng issue, hay nội dung bị dán bất cẩn vào terminal, thì điều đó có thể dẫn tới rò rỉ dữ liệu hoặc thiệt hại khác
  • Chạy tác nhân lập trình ngoài sandbox luôn là một ý tưởng tồi và được xem là ứng viên hàng đầu cho các sự cố bảo mật liên quan đến tác nhân lập trình
  • Fable có thể thông minh hơn và nghi ngờ chỉ dẫn độc hại nhiều hơn, nhưng một khi đã mắc bẫy chỉ dẫn đó thì tính chủ động không ngừng của nó có thể khiến mức độ thiệt hại lớn hơn

Bài viết liên quan

1 bình luận

 
GN⁺ 5 giờ trước
Ý kiến trên Hacker News

  • Đây giống như một ví dụ ấn tượng cho thấy sự đánh mất tính chủ động của con người một cách nghiêm trọng, và số lượng commit thực tế cũng cho thấy khá nhiều điều [0]
    Tác giả muốn ẩn thanh cuộn ngang. Một lập trình viên frontend junior tử tế hẳn sẽ lập tức hỏi: “đặt overflow-x: hidden; ở đâu?” Một cách sửa hoàn chỉnh chỉ cần bấm “Inspect element” trong trình duyệt để tìm class CSS, rồi dùng (rip)grep trong code để tìm vị trí và thêm một dòng
    Một lập trình viên chủ động hơn có lẽ sẽ hỏi những câu như: vì sao lại có nội dung gì trong textbox trống mà bị tràn, vì sao phải đặt cách chữa cháy che triệu chứng ở hai chỗ thay vì xử lý nguyên nhân gốc, và liệu có nên style textarea chỉ một lần hay không
    [0] https://github.com/datasette/datasette-agent/commit/a75a8b72...

    • Trước khi sửa chi tiết CSS, có lẽ còn nên hỏi vì sao CSS tĩnh nằm trong nhiều đoạn JavaScript lại đang bị giấu trong __init__.py [0]
      Trải nghiệm của tôi khi dùng Claude phần lớn là nó tạo ra code có cấu trúc khá tốt, nên trường hợp này thực sự hơi bất ngờ. Dù vậy, cách tôi dùng giống kiểu thân thiện tranh luận theo lối Socrates với một kỹ sư robot hơn là vibe coding đúng nghĩa
      [0] https://github.com/datasette/datasette-agent/blob/main/datas...
    • Mô hình này dường như đã đạt kết quả ở phần vốn đã mở rộng tốt từ trước, tức là độ dài và độ phức tạp của tác vụ được yêu cầu. Nhưng ở phần trước giờ vẫn chưa mở rộng tốt là thường thức, khả năng phân biệt và phán đoán, thì có vẻ chưa có cải thiện lớn
    • Quá đúng. Simon đã giao những việc lặt vặt như thế này cho LLM, và vì vậy tự đánh mất cơ hội đánh giá rồi cải thiện mức độ trừu tượng dựa trên thông tin bổ sung. Thay vào đó, anh ấy để agent tiêu 12 đô la để sửa và rốt cuộc chẳng học được gì
    • Fable có vẻ có xu hướng tự kiểm chứng các thay đổi của chính nó, và bản thân điều đó là rất tốt. Để khiến Opus làm những gì Fable tự làm mà không cần prompt, phải cung cấp khá nhiều prompt
      Đó cũng chính xác là điều tôi kỳ vọng ở một lập trình viên junior. Xác nhận bug có thực sự tồn tại hay không, tìm cách sửa, rồi kiểm tra xem bug đã được sửa chưa
      Vấn đề, như bài blog cũng chỉ ra rất đúng, là nó cứ liên tục tự đi tìm các đường vòng kiểu hack thay vì dừng lại để hỏi khi cần quyền hạn cao hơn. Nếu là một lập trình viên con người, điều này giống như cần quyền truy cập sandbox của bên thứ ba nhưng lại không xin credential từ senior, mà tự định xây hẳn sandbox riêng từ đầu
    • Thực ra chuyện này trông giống như một cách kiếm tiền quá mức từ bất kỳ xung lực nào
      Nó làm tôi nhớ đến thời trước khi truy cập thế giới trực tuyến còn bị tính phí theo từng phút. Khi đó có rất nhiều động cơ để giữ đồng hồ tính tiền chạy tiếp, và tôi tự hỏi liệu đây có phải cũng là cùng một kiểu như vậy không

  • Tôi vẫn liên tục thấy bối rối và ngạc nhiên khi có quá nhiều người tiếp tục làm điều đó, dù đã thẳng thắn thừa nhận rằng “chạy coding agent ngoài sandbox vốn luôn là một ý tưởng tồi”
    Cảm giác như đăng video ngồi ghế phụ gác chân lên táp-lô rồi nói: “Hãy nhớ là nếu gặp tai nạn thì túi khí có thể làm gãy chân bạn hoặc tệ hơn nữa nhé! May quá là chuyện đó không xảy ra với tôi!”

    • Ví dụ được chọn khá thú vị. Lái xe ô tô, ngay cả khi tuân thủ mọi quy tắc an toàn, vẫn gần như thuộc nhóm hoạt động nguy hiểm nhất mà chúng ta làm hằng ngày. Nhưng dù vậy, chúng ta vẫn kết luận rằng lợi ích lớn hơn rủi ro
    • Dạo này ai cũng bị yêu cầu tăng khối lượng việc xử lý lên 10 lần mỗi ngày. Đến mức đó thì kiểm tra an toàn bị ném thẳng ra ngoài cửa sổ
    • Tôi đã làm vậy từ vài tháng trước, và thành thật mà nói thì chuyện agent sẽ làm gì không hẳn là không thể đoán trước
      Vấn đề là mỗi người đưa prompt theo một cách quá khác nhau
      Ví dụ tôi có thể yêu cầu kiểu “hãy thử nhiều biến thể của annotation này trên pod k8s của service này trong cluster X. Việc đó sẽ chứng minh giả thuyết Y”. Nhưng đồng nghiệp của tôi lại nói “hãy kiểm tra giả thuyết Y”. Nếu hỏi hai kỹ sư junior như vậy, một người có thể thử bừa trên môi trường production, còn người kia có thể chạy test cục bộ. Đó là một yêu cầu không có chỉ dẫn kiểu “cứ làm bất cứ gì cần để tìm ra đi”, và agent sẽ đọc nó giống như một junior bị gây áp lực rất mạnh phải “tìm ra”, trong khi chẳng hề được truyền đạt ranh giới nào
    • Tôi cũng thấy khó hiểu khi nhiều người nghĩ rằng mình có sandbox hiệu quả, nhưng agent bên trong sandbox đó lại có toàn bộ code, GitHub, quyền truy cập web không giới hạn
    • Tôi biết có giải pháp VM, nhưng tôi đang hài lòng với cách dùng một tên người dùng OS riêng là claude
      Nó có dotfile gần giống của tôi nhưng không có secret. Thư mục home của tôi là 0700, claude có SSH key riêng và tôi đã thêm nó vào profile GitHub của mình, nhưng có đặt mật khẩu, còn push/pull thì tôi làm thay. Cũng có user và database Postgres phát triển/kiểm thử riêng, và không phải superuser
      Tức là tôi đối xử với nó như một lập trình viên khác trong dự án. Nếu cần chạy thứ gì đó bằng sudo thì nó sẽ hỏi tôi. Đôi khi cả hai còn có thể làm song song cùng một việc. Ngay từ đầu Unix vốn được thiết kế là hệ thống đa người dùng
      Một mẹo tôi hay dùng là đặt thêm remote như sau trong các git repository của nó:
      paul ssh://paul@localhost/~/src/example (fetch)
      paul ssh://paul@localhost/~/src/example (push)
      Điều đó giúp cộng tác dễ hơn với những thứ vẫn chưa sẵn sàng để chia sẻ
      Cấu hình này khá thoải mái. Dù vậy tôi vẫn lo về các lỗi leo thang đặc quyền trên Linux. Tôi không tin AI thật sự hiểu rằng việc khai thác lỗ hổng là không được phép. Nó làm tôi nhớ hồi công việc đầu tiên, khi có việc gấp tôi từng lạm dụng nhầm tính năng :! của vim để mở rộng quyền sudo vốn chính thức chỉ bị giới hạn cho việc chỉnh httpd.conf. Dạo này dù có cập nhật bảo mật tự động, tôi vẫn nâng cấp package thủ công thường xuyên hơn. Có lẽ Opus sẽ không bỏ công đi tìm lỗ hổng bảo mật, nhưng Fable thì có thể, và gần đây đã có nhiều lỗ hổng kiểu đó. Các model tương lai thậm chí có thể tự tìm ra lỗ hổng mới hoặc cài keylogger để học mật khẩu của SSH key
      User riêng gần như là cấu hình thiên về phòng thủ nhất mà tôi từng nghe, ngoài việc dùng hẳn máy riêng. Vì vậy tôi cũng tự hỏi liệu mình có đang hy sinh quá nhiều tốc độ và sự tiện lợi không. Dù vậy trên thực tế nó vẫn rất tiện, và tôi xem đây là cách làm vừa hiệu quả vừa có trách nhiệm. Nếu ai thấy lỗ hổng thì tôi rất muốn nghe

  • Fable cho cảm giác như “Opus chạy trên một harness khiến nó không thể dừng lại cho đến khi chắc chắn vấn đề đã được sửa”. Nếu bạn muốn một model tốt hơn trên benchmark thì đó là một hướng đi hợp lý
    Đây là model rất tốt, nhưng mức premium rất lớn. Không chỉ token đắt hơn, mà model còn muốn dùng hết sạch số token đó. Ví dụ với tác vụ React Native, Fable không nói kiểu “được rồi, xong rồi”. Nó muốn build lại toàn bộ app từ đầu, chạy toàn bộ bộ test, rồi theo dõi mọi log và cảnh báo
    Đây là lần đầu tiên khi dùng LLM mà tôi cảm thấy việc nâng cấp model là không đáng giá, ngay cả khi công ty cho phép, vì việc build và test hành hạ máy và pin của tôi quá mức đến nỗi tôi không làm được việc khác
    Hiện tại có vẻ dùng ultracode trên Opus vẫn tốt hơn. Ít ô nhiễm ngữ cảnh chính hơn, và việc điều tra cũng được song song hóa tốt hơn

    • Chẳng phải đặt low/medium effort là giải quyết được sao? Fable 5 low có vẻ thường tốt hơn Opus 4.8 high/xhigh, và cũng dùng ít token hơn rất nhiều
    • Trải nghiệm của tôi thì ngược lại. Dĩ nhiên tôi có dùng nhiều sub-agent, nhưng tôi đã cho nó chạy nhiều giờ với số token ít hơn rất nhiều so với hồi dùng opus4.6-8 trước đây
    • Tôi tò mò bạn đang chạy nó với cấu hình nào trong môi trường nào. Tôi dùng extension VSCode ở mức Extra High, và thấy nó chỉ làm đúng những gì cần cho việc được yêu cầu rồi dừng lại khi xong. Ngay cả các bình luận thêm vào cũng chỉ xuất hiện khi liên quan đến vùng mã đã thay đổi
    • Thiết lập high effort mới mạnh quá mức, đến mức nếu chọn nó khi tác vụ không cần thì có vẻ còn ảnh hưởng tiêu cực đến chất lượng đầu ra
    • Về mặt lý thuyết tôi thích kiểu chủ động này, nhưng đúng như bạn nói, nó rất đắt. Tôi tự hỏi liệu có thể giải quyết bằng prompt phù hợp không. Ví dụ kiểu “đây là các ràng buộc. Chỉ giải quyết x thôi. Nếu không chắc việc nào đó có nằm ngoài ràng buộc hay không thì hãy xác nhận với tôi trước”

  • Fable đã cố tự xác minh thay đổi UI trong game của tôi. Lúc đó tôi đang làm việc ở cửa sổ khác thì thấy chương trình mở trên taskbar. Fable đã mở game từ CLI bằng công cụ movie maker, ghi lại đầu ra, rồi chụp frame cuối để xác minh UI. Khi màn hình chào mừng của game che mất phần nó muốn xem, nó tạo một worktree tạm, xóa màn hình chào mừng rồi chạy lại movie maker
    Khi nhìn cả quá trình đó, tôi chỉ nghĩ là giá như nó cứ xin tôi ảnh chụp màn hình thì đã tiết kiệm được token hơn. Nhưng dù vậy tôi vẫn không thể không ấn tượng. Opus thì chắc chắn sẽ không bao giờ làm thế

    • Điều này chạm đúng vấn đề cốt lõi khi model cứ chủ động mãi không thôi. Nó sẵn sàng đốt 5 đô token chỉ để khỏi phải hỏi con người chụp ảnh màn hình hay bấm nút
    • Bạn chỉ cần nói thẳng với nó vậy thôi. Tôi cũng từng gặp chuyện tương tự, nhưng sau khi chỉ thị rằng phần review hãy để tôi làm, thì Fable đã hữu ích trong các vòng lặp frontend suốt nhiều giờ mà không tiêu tốn quá nhiều token

  • Mấy bài kiểu này tạo cảm giác như đến từ một vũ trụ song song. Theo trải nghiệm giai thoại của tôi và benchmark tự làm, vẫn còn mang tính chủ quan nhưng trực tiếp (https://pshirshov.github.io/llm-bench-pi-oneshot/), Fable không ấn tượng đến mức đó
    Ở tầm gpt-5.5 và opus 4.8, có lúc nó tốt hơn, có lúc tệ hơn, và rõ ràng đắt hơn, thậm chí còn từ chối cả câu hỏi về React vì bảo không thể giúp về hóa học
    Tôi không biết sự ầm ĩ này có thực sự có cơ sở hay chỉ là thổi phồng AGI trước IPO

    • Từ sau khi ra mắt, trải nghiệm của tôi với Fable trùng khớp với trải nghiệm của Simon
      Tôi đang để Fable điều phối các phần triển khai phức tạp. Tôi đưa cho nó các ticket cấp cao trong Linear và bảo: “Hãy xem các issue con của ticket này, xác định cái nào anh có thể tự triển khai, nên làm theo thứ tự nào, và phải phối hợp ra sao với những gì các thành viên khác trong nhóm đang làm.” Những ticket này không hề nhỏ nhặt, có nhiều phần chuyển động và phụ thuộc, lại còn liên kết cả trong lẫn ngoài cùng dự án, ví dụ như với backend
      Sau đó Fable chọn ticket và giao từng ticket cho các tác tử con của nó, cũng là Fable. Tác tử con xem thiết kế Figma của ticket đó, tuân thủ chặt chẽ guideline và quy ước của repo, triển khai rất chuẩn, chụp screenshot cho từng phần, viết commit message và mô tả PR chi tiết, rồi đính kèm screenshot làm bằng chứng. Cuối cùng nó đưa ra phần tóm tắt kiểu như: “PR #1283 phải được merge trước. Ngoài ra, một số màn hình như thế này không có thiết kế Figma, nên tôi đã áp dụng pattern từ các màn hình tương tự đã được triển khai rồi.”
      Đây chắc mới chỉ là khoảng 20% những gì Fable có thể làm. Thực sự là một mô hình rất mạnh
      Opus 4.8 cũng làm được nhiều việc trong số này, nhưng phải cầm tay chỉ việc nhiều hơn, và khi gặp điểm bị kẹt thì rất dễ dừng lại kiểu “Tôi làm được đến đây thôi, không thể tiến xa hơn nữa”

  • Fable thông minh hơn một chút, nhưng cũng chính vì thế mà nhìn tổng thể nó lại giống một công cụ tệ hơn
    Nó cứ biến một bản vá 50 dòng vốn xong bằng một prompt thành một cuộc thám hiểm 30 phút, mà nhiều khi hoàn toàn không đáng. Thậm chí còn sai khá thường xuyên
    Tôi đã thử nó với một việc khá đơn giản: backfill cache khử trùng lặp trong redis khi hàm băm thay đổi. Chỉ cần chạy hàm băm mới trên tất cả giá trị trong DB để mở rộng cache, nhưng Fable lại triển khai một cơ chế cập nhật cache phức tạp quá mức, cố suy đoán phiên bản hàm băm của từng giá trị cache rồi chỉ tính lại các hash cũ. Trong một số ngữ cảnh thì có thể hợp lý, nhưng sau 30 phút đốt token, kết quả là đoạn code mà tôi thay bằng một vòng for 10 dòng
    Tôi lo đây là tin xấu cho lập trình nói chung. Có vẻ rất rõ là công nghệ LLM đang đụng vào bức tường lợi ích cận biên giảm dần về mặt trí tuệ, mà nếu cách phản ứng chỉ là làm cho nó lì lợm hơn thì đó là một giải pháp tệ hại cho tất cả những ai liên quan. Có lẽ ngoại trừ những người bán token và những ai đủ sức trả token để quét 0-day

    • Tôi nghĩ LLM và agent có lẽ có hai vấn đề sẽ không bao giờ được sửa triệt để
      Thứ nhất, chúng không có mô hình nhân quả. Điều chúng có thể làm chỉ là khám phá theo kiểu thử-và-sai, cách này hoạt động khá tốt cho nhiều bài toán, nhưng nhiều bài toán khác lại cần mô hình nhân quả
      Thứ hai, prompt không chính xác. Ngôn ngữ lập trình và mô hình máy móc được phát minh ra chính để giải quyết vấn đề này. Tiếng Anh rất tuyệt, nhưng không phải là ngôn ngữ lập trình
    • Tôi nghĩ nội bộ họ đã biết từ lâu rằng mình đã chạm đến lợi ích giảm dần rồi
      Trước IPO họ đã làm rất nhiều thứ theo kiểu triển khai và thao túng mang tính chiến lược, và xét ở mặt đó thì nó có hiệu quả
    • Vài ngày trước tôi dùng CC để làm một thay đổi giống hệt nhau trên 15~20 file, tức là kéo một hàm nào đó ra ngoài thân component. Chỉ cần sửa các file là xong, nhưng nó lại khởi chạy nhiều agent, trong đó có một agent đi tìm tất cả file rồi viết hẳn một script perl dùng regex để thay thế. Sau đó chuyện kiểm tra lỗi thì chỉ cần chạy tsc, nhưng nó lại còn viết thêm script để chạy tsc trong từng tác tử con rồi tổng hợp kết quả
      Thực sự bực mình. Việc lẽ ra cùng lắm 1~2 phút là xong thì vì đi theo hướng đó mà mất khoảng 10 phút
      Sau này tôi sẽ thử các tác vụ phức tạp hơn nhiều, nhưng với việc đơn giản thì nó giống như lái Corvette ra tận hộp thư

  • Tôi ngày càng thấy sự dè chừng của mình với việc dùng LLM chạy trong terminal trên máy local là hoàn toàn có cơ sở
    Kể cả khi nó không làm gì ác ý, vẫn có quá nhiều cách để nó khiến tôi mất không ít công sức, hoặc làm hỏng cả máy lẫn khả năng làm việc của tôi

    • Thật sốc khi không có sẵn cách chạy trong sandbox theo mặc định
      Một công ty 1 nghìn tỷ đô chẳng lẽ không thể chuẩn bị việc đó tương đối dễ sao? So với cả bộ harness thì có vẻ chỉ là chuyện nhỏ

  • An ninh rõ ràng là vấn đề lớn hơn, nhưng suốt lúc đọc cái này tôi chỉ nghĩ đến chuyện họ đã đốt bao nhiêu token chỉ để sửa 2 dòng CSS

    • Số dòng code của bug fix thực sự là một chỉ dấu thay thế rất tệ để ước lượng công sức cần bỏ ra
      Phải ước lượng xem nếu là con người thì sẽ mất bao lâu
    • Đơn giản thôi. Nếu chỉ cần sửa 2 dòng CSS thì tuyệt đối không nên dùng Fable. Chỉ nên dùng nó cho các việc phức tạp và tốn thời gian
    • Hình như vào khoảng 12 đô
    • Tác giả là một tay bán hàng thổi phồng AI và không tự trả chi phí token của mình
    • Tôi còn nhanh hơn mấy tín đồ LLM kiểu này. Tôi không hề tin chắc dùng LLM là nhanh hơn. Có thể boilerplate là ngoại lệ, nhưng chuyện đó có gì quan trọng đến vậy đâu
      Giờ đây người ta chỉ mới có thể vừa lười vừa trông có vẻ năng suất, nhưng vẫn là lười thôi
      Đã xuất hiện những người cần quyền truy cập vào phần cứng trị giá hàng trăm nghìn đô chỉ để viết một email. Tôi xin kiếu kiểu đó. Tôi không muốn đốt não mình để rồi phụ thuộc vào cỗ máy suy nghĩ của tỷ phú
      Tôi cũng sẽ không đốt não mình với một “cỗ máy nghĩ thay” chạy local. Tôi muốn trở thành người có giá trị hơn thứ phần cứng mà mình có thể tiếp cận

  • Trải nghiệm cá nhân của tôi với việc Fable 5 tự vận hành theo cách của nó là rất tích cực
    Nó đã cố tìm nguyên nhân gốc rễ của một vụ crash trong mô-đun Python mà không để lại lỗi nào trong log hay console. Fable viết một test harness mô phỏng các cú nhấp UI, rồi dùng tìm kiếm nhị phân trên mã của tôi để xác định điểm bắt đầu phát sinh crash. Sau đó nó đưa ra một giả thuyết khá mạnh về nguyên nhân gây crash, rồi chạy liên tiếp các lệnh bash một dòng để tạo môi trường ảo cho từng phiên bản của mô-đun Python đó dưới /tmp, nhằm tìm ra phiên bản không bị crash
    Nó đã lần theo nguyên nhân gốc rễ sâu hơn rất nhiều so với khi tôi tự làm một mình, và nguyên nhân là một lỗi hồi quy của mô-đun gây tràn cấp phát heap. Nó cung cấp đủ thông tin và một ví dụ rút gọn đủ để gửi bug report, đồng thời cũng viết một cách обход để việc đó không xảy ra trong ứng dụng của tôi
    Tôi không thả lỏng hoàn toàn. Tôi xem lại từng lệnh CLI mà nó định chạy, và khi tiếp tục bằng “yes”, tôi thêm phản hồi để ngăn việc tiêu tốn token quá mức

    • Tôi thấy Fable thực sự rất giỏi trong việc debug các lỗi khó
      Sẽ hữu ích nếu đặt ranh giới trong prompt hoặc Markdown. Ví dụ, nếu bảo nó không dùng tự động hóa trình duyệt web, tôi đã thấy Fable tuân thủ cả quy tắc lẫn tinh thần của quy tắc đó. Nó cũng không dùng các mẹo kỳ quặc
      Tuy vậy, có vẻ nó đôi khi đối xử với một số tác vụ debug đơn giản như thể chúng phức tạp hơn thực tế. Bài gốc có lẽ là một ví dụ điển hình
    • Tôi nghi ngờ liệu có thực sự cần đến agent để tạo bài test mô phỏng các cú nhấp UI và chạy vòng lặp git bisect nhằm tìm nguyên nhân khiến mô-đun Python bị crash mà không để lại lỗi nào trong log hay console hay không
      Tôi hiểu việc tạo test case và vòng lặp git bisect, nhưng tôi không rõ vì sao phải chạy nó qua Internet và GPU các thứ. Có vẻ đây là việc ngay cả một máy Celeron đơn nhân cũng có thể chạy được mà?