23 điểm bởi GN⁺ 2026-01-07 | 3 bình luận | Chia sẻ qua WhatsApp
  • Claude Opus 4.5 cho thấy năng lực phát triển tự chủ ở mức có thể xây dựng các ứng dụng hoàn chỉnh với độ hoàn thiện cao mà không cần sự can thiệp của lập trình viên, khác với các tác nhân AI viết code trước đây
  • Từ tiện ích chuyển đổi ảnh trên Windows đơn giản đến công cụ ghi và chỉnh sửa video, ứng dụng tự động đăng bài bằng AI, và ứng dụng theo dõi đơn hàng và tính toán lộ trình, nó đều hoàn thành các dự án chạy thực tế trong thời gian ngắn
  • Opus 4.5 tự xử lý các công việc phát triển phức tạp như thiết lập backend Firebase, phân tích log lỗi và tự động sửa, và cấu hình triển khai bằng GitHub Actions
  • Tác giả cho biết mình không hoàn toàn hiểu cấu trúc mã, nhưng xác nhận rằng Opus 4.5 có thể tự giải quyết lỗi và thậm chí đề xuất refactor
  • Từ trải nghiệm này, tác giả nhấn mạnh rằng khả năng AI có thể thay thế hoàn toàn lập trình viên đang dần trở thành hiện thực, và đây là bước ngoặt của kỷ nguyên phát triển lấy AI làm trung tâm

Sự xuất hiện của Opus 4.5 và điểm khác biệt với các tác nhân AI trước đây

  • Các tác nhân AI trước đây thường có năng suất thấp do tạo mã kém hiệu quả và sửa lỗi lặp đi lặp lại
    • Sau nhiều lần sao chép-dán và sửa lỗi, codebase thường bị hỏng
  • Opus 4.5 vượt qua những vấn đề đó, viết chính xác phần lớn mã ngay từ đầu, và khi phát sinh lỗi thì lặp lại quá trình build và sửa trực tiếp qua CLI
  • Tác giả đánh giá đây là “mô hình đã thực sự hiện thực hóa lời hứa của AI coding”

Dự án 1 – Tiện ích chuyển đổi ảnh trên Windows

  • Opus 4.5 hoàn thành chỉ với một yêu cầu một tiện ích có chức năng chuyển đổi định dạng ảnh từ menu chuột phải trong Windows Explorer
    • Tự động hóa quy trình build và sửa lỗi bằng dotnet CLI
    • Chỉ các lỗi XAML là được kiểm tra bằng Visual Studio rồi sao chép lại để cung cấp
  • Nó còn thiết lập cả website phục vụ triển khai, script cài đặt PowerShell, và pipeline triển khai tự động bằng GitHub Actions
  • Phần tạo logo dùng Figma AI, còn Opus viết script chuyển đổi SVG và định dạng biểu tượng

Dự án 2 – Công cụ ghi và chỉnh sửa màn hình

  • Bắt đầu từ một tiện ích ghi GIF tương tự LICEcap, sau đó mở rộng thêm cả chức năng chỉnh sửa video và hình ảnh
    • Các tính năng chỉnh sửa như thêm hình khối, cắt, làm mờ được triển khai chỉ trong vài giờ
  • Mã nguồn đã được công khai trên GitHub, và tác giả nói rằng nó đã được phát triển đến mức khá cao chỉ trong vài giờ
  • Điều này cho thấy Opus 4.5 có thể xử lý không chỉ UI mà cả công việc tích hợp backend

Dự án 3 – Ứng dụng tự động đăng bài bằng AI

  • Một ứng dụng di động dựa trên AI tự động đăng bài lên trang Facebook được phát triển bằng Opus 4.5
    • Sau khi tải ảnh lên, AI sẽ tạo caption và lên lịch đăng
    • Backend Firebase, xác thực, lưu trữ và cloud function đều được Opus tự cấu hình trực tiếp bằng CLI
  • Tác giả nói rằng trong lúc mình đang lắp rèm, Opus đã hoàn thành ứng dụng
  • Opus còn tự động phân tích log lỗi để sửa, đồng thời tạo cả dashboard quản trị
  • Công việc trước đây mất hàng tháng thì nay được hoàn thành trong vài giờ

Dự án 4 – Ứng dụng theo dõi đơn hàng và tính toán lộ trình

  • Phân tích email đơn hàng từ Gmail để tự động tính lịch trình, tuyến đường, thời gian lái xe và nhật ký quãng đường phục vụ khai thuế
  • Opus 4.5 xử lý trọn gói tích hợp xác thực Google và kết nối Firebase trong một lần
  • Tác giả nhận xét rằng “những việc đau khổ nếu làm thủ công đã được Opus thực hiện hoàn hảo”

Vấn đề về hiểu mã và chất lượng

  • Tác giả nhắc rằng dù mình không biết Swift, ứng dụng vẫn hoạt động hoàn hảo
  • Opus 4.5 tự tìm và sửa lỗi, nên tác giả vẫn tiếp tục phát triển bình thường dù không biết rõ cấu trúc bên trong của mã
  • Trước câu hỏi về chất lượng mã, tác giả viết rằng nếu đó là mã để AI đọc và bảo trì, thì tính dễ đọc với con người không còn quá quan trọng
  • Bằng cách dùng prompt viết mã chuyên cho AI trong VS Code, tác giả tạo ra mã ưu tiên cấu trúc dễ hiểu với LLM

Nguyên tắc lập trình lấy AI làm trung tâm

  • Prompt được xây dựng với tiền đề rằng đây là “mã do AI viết và bảo trì”
    • Nhấn mạnh cấu trúc đơn giản, điểm vào rõ ràng, tối thiểu hóa trừu tượng, độ kết dính thấp
    • Coi trọng luồng điều khiển tường minh, hàm đơn giản, logging có cấu trúc, khả năng tái tạo dễ dàng
  • Khi refactor mã, Opus sắp xếp thành tài liệu các hạng mục cải thiện theo mức ưu tiên (cao/trung bình/thấp)
  • Khi kiểm tra bảo mật, tác giả yêu cầu rà soát API key, xử lý đăng nhập, và việc lưu trữ dữ liệu nhạy cảm hay không
    • Về tính hoàn thiện bảo mật, tác giả nói rằng “mới khoảng 80% nên vẫn còn bất an”

Bước chuyển của thời đại phát triển bằng AI

  • Tác giả bày tỏ rằng “vừa phấn khích vừa thấy trống rỗng trước thực tế có thể tạo ra thứ gì đó chỉ trong vài giờ”
  • Trước đây tác giả tin rằng “AI không thể thay thế lập trình viên”, nhưng giờ thừa nhận không thể phủ nhận khả năng đó nữa
  • Kết luận, tác giả nhấn mạnh rằng trong môi trường phát triển lấy AI làm trung tâm, đừng chần chừ mà hãy tự tay tạo ra thứ gì đó
  • Cuối cùng, tác giả cảnh báo rằng “ít nhất việc quản lý API key thì vẫn phải tự mình chịu trách nhiệm”

Tóm tắt: Opus 4.5 được đánh giá là một mô hình ở cấp độ lập trình viên AI, có thể tự chủ thiết kế, triển khai và phát hành ứng dụng hoàn chỉnh chứ không chỉ hỗ trợ viết mã đơn thuần. Qua trải nghiệm này, tác giả cho biết mình đã trực tiếp chứng kiến khả năng thực tế để AI thay thế lập trình viên con người.

3 bình luận

 
wegaia 2026-01-08

Tôi bảo Opus 4.5 sửa một dòng code, vậy mà nó tự ý xóa khoảng 10 dòng mã cấu hình ở phía trên. Khi tôi hỏi tại sao lại xóa, nó nói đại khái là thấy đó chỉ là mã vô nghĩa nên đã xóa..

 
GN⁺ 2026-01-07
Ý kiến trên Hacker News
  • Công việc của một kỹ sư tầm trung không đơn thuần là tạo app mới, mà là thiết kế cấu trúc có tính đến khả năng mở rộng và khả năng dễ hiểu
    Opus 4.5 xử lý tốt các yêu cầu kiểu “làm cho tôi một app”, nhưng khi muốn thêm tính năng vào code hiện có như trong công việc thực tế thì nó lại dùng các lớp trừu tượng kỳ quặc hoặc phải sửa đi sửa lại nhiều lần mới đạt được chất lượng mong muốn
    Người không chuyên có thể nghĩ “chạy được là được”, nhưng kỹ sư thì biết như vậy là chưa đủ

    • Có hai kiểu “đúng cách” — cách phù hợp với ngữ cảnh và cách mà kỹ sư thường khái quát hóa để suy nghĩ
      Tôi nhớ trước đây trong team từng cãi nhau về “đáp án đúng”. Cuối cùng phải có người ngoài vào nhắc lại điều gì mới quan trọng dưới góc độ kinh doanh
      Đôi khi làm nhanh dù hơi bừa để kiểm chứng hướng đi có đúng không mới là cách “đúng” thật sự
      Vấn đề phát sinh khi ngay từ đầu đã thiết kế quá mức, hoặc ngược lại khi quản lý ngăn cản refactor. Cuối cùng sự cân bằng mới là cốt lõi
    • Nhìn các dự án kiểu này, tôi thấy thay vì dùng LLM thì cứ fork thẳng trình chuyển đổi ảnh hay bản clone Minesweeper có trên GitHub là được, nên cảm giác LLM ở đây chỉ dùng để gỡ rủi ro bản quyền
    • Có người cho rằng “chất lượng code giờ không còn quan trọng nữa”. Chỉ cần hôm nay pass test là đủ, còn nếu ngày mai cần refactor toàn bộ thì nạp thêm chút credit và làm lại trong vài tiếng là xong
    • Tôi khá ngạc nhiên khi thấy Opus 4.5 bám theo rất tốt các mẫu code mang tính thành ngữ của codebase hiện có
      Nếu chỉ dẫn rõ ràng để nó đọc phần code lân cận thì nó hoạt động tốt hơn hẳn. Chỉ cần thêm một hai câu là đủ
    • Khi thêm tính năng vào code có sẵn, nếu tự chỉ rõ kiểu trừu tượng mong muốn thì nó làm theo khá ổn theo hướng tăng dần
      Dù vậy cá nhân tôi vẫn thích GPT‑5.2 hơn
  • Nhiều kỹ sư đang đánh giá thấp hiệu năng hiện tại của các tác tử LLM như Claude Code
    Team chúng tôi đã tự động hóa code review, ESLint, checklist PR, đồng bộ tài liệu, và kiểm tra độ phủ test bằng Claude Code
    Việc phân loại ticket cũng được tự động xử lý, nên khi kỹ sư bắt tay vào làm thì thực ra đã xong sẵn một nửa
    Kho ví dụ nằm tại claude-code-showcase
    Tôi tin chắc đến khoảng năm 2026 đây sẽ trở thành quy trình làm việc tiêu chuẩn của ngành

    • Có sự khác biệt rất lớn về trải nghiệm dùng LLM giữa frontend (React, HTML, mobile) và các mảng low-level (OpenGL, io_uring, libev, v.v.)
      Opus 4.5 làm app JS rất tốt, nhưng nếu bảo nó hiện thực một thuật toán đổ bóng từ bài báo năm 2003 bằng C++ thì kết quả hoàn toàn thảm họa
      Kể cả nhồi cho nó cả bài review về threading của Doom3 BFG của Fabien Sanglard thì nó vẫn chỉ sinh ra code vô dụng
      Rốt cuộc không phải là “chúng ta đánh giá thấp LLM”, mà là “nó vẫn chưa đủ thực dụng nên chúng ta đang chờ”
    • Nhiều người đã thử AI coding từ sớm rồi bỏ cuộc vì lỗi và sự thất vọng
      Nhưng Opus 4.5 đã lên một nấc mới. Lỗi ít hơn nhiều và đa phần chỉ là sai sót nhỏ
    • Tôi dạy sinh viên ở đại học và đã thử Cursor, Claude Code, Codex,
      nhờ AI mà hoàn thành một dự án lẽ ra mất 2 tuần chỉ trong 5 giờ.
      Nếu không có AI thì có lẽ tôi còn chẳng thử làm
    • Thấy buồn cười khi README do AI viết cứ cố ghi cấu trúc thư mục. Chạy tree là ra hết rồi
    • Có vẻ về sau chính nghề “lập trình viên” sẽ thu hẹp lại, còn khả năng sáng tạo bằng cách tận dụng công cụ sẽ trở nên quan trọng hơn
  • Tôi đã dùng Opus 4.5 khá nhiều, và thấy nó xuất sắc trong phân tích code phức tạp nhưng vẫn chưa đạt năng lực giải quyết vấn đề ở mức con người
    Ví dụ, nó có thể nhận diện chính xác thuật toán bố cục đồ thị, nhưng không tự sửa lỗi của thuật toán đó được
    Nó rất tốt cho phân tích code và bổ sung tri thức, nhưng giải quyết vấn đề phức hợp thì vẫn chưa tới

    • Copilot có giới hạn vì cấu trúc cắt bớt ngữ cảnh để tiết kiệm token
      Nếu muốn hiệu năng thật sự thì phải dùng API trực tiếp, và chi phí cho một PR có thể lên tới ba chữ số
      Tham khảo: models.dev
    • Việc Copilot tính số token gấp 3 khi dùng Opus 4.5 khiến tôi ngạc nhiên; tôi đã dùng hết một nửa quota tháng chỉ trong một tuần
    • Chỉ cần dùng AI như công cụ phân tích code thôi cũng đã rất có giá trị
      Nó tạo tài liệu tốt hơn con người, và tỷ lệ lỗi cũng có xu hướng thấp hơn con người
    • Nếu dùng qua công cụ bên thứ ba thì cách hoạt động sẽ khác
      Tôi khuyên nên thử trực tiếp trong VS Code hoặc Cursor bằng gói Claude Code
  • Trong kỳ nghỉ tôi đã làm nhiều dự án với GPT‑5.x —
    công cụ tự động hóa Swift, tích hợp engine ARM JIT, nguyên mẫu synthesizer, v.v.
    GPT‑5.2 và dòng Codex mạnh không kém Opus, đến mức có thể thiết lập toàn bộ workflow CI chỉ trong một lần
    Với người có thói quen lập kế hoạch và review code như tôi, đây là công cụ nhân đôi năng suất

    • GPT‑5.2 khá hay ảo giác (hallucination) về sự tồn tại hay chức năng của các tiện ích CLI
      Tôi phải lục mã nguồn thật mới xác nhận được lỗi
    • Gemini 3 Pro (High) cùng các công cụ như Antigravity, Amp, Junie cũng rất ấn tượng
      Tôi đã hoàn thành thư viện binding Ratatui cho Ruby chỉ trong 2 tuần
      Antigravity chạy nhiều tác tử song song để thực hiện nén ngữ cảnh và quản lý tự động
      Những công cụ cao cấp kiểu này mang lại trải nghiệm hoàn toàn khác so với bản miễn phí
      Khi dùng cùng công cụ Unix và git CLI, có thể giữ ngữ cảnh nhỏ và tối đa hóa hiệu quả
    • LLM rất mạnh với code backend·CLI, nhưng ở các mảng như HTML/CSS hay frontend JS, nơi cần phản hồi thị giác, thì nó vẫn còn yếu
      Nó mạnh ở đầu vào·đầu ra có cấu trúc, nhưng thất bại ở những phần cần “độ hoàn thiện cảm quan”
  • Gần đây tôi cảm nhận số bình luận tiêu cực về LLM trên HN đã giảm mạnh
    Nhưng đa số dự án được chia sẻ vẫn chỉ dừng ở mức demo kỹ thuật
    Việc tích lũy ngữ cảnh, tức là hiểu yêu cầu người dùng, vẫn là phần của con người
    Có thể làm vài app trong một cuối tuần, nhưng gần như chẳng có ai bảo trì chúng

    • Việc bình luận tiêu cực giảm có thể là vì mọi người đã mệt mỏi với những cuộc tranh cãi lặp đi lặp lại kiểu “mô hình mới mạnh hơn 1000 lần”
    • Cũng có thể những người đang làm sản phẩm có thể kiếm tiền thì âm thầm phát triển nên không chia sẻ
    • Đưa vào production và bảo trì đòi hỏi nỗ lực khổng lồ
      Karpathy cũng từng chia sẻ trải nghiệm tương tự — prototype thì dễ nhưng triển khai thì khó
      Nếu là công cụ dùng cá nhân thì tiếp cận theo hướng giải quyết vấn đề hơn là độ hoàn thiện cũng đã đủ
    • Càng là người dùng AI nhiều thì càng hay mắc kẹt ở đoạn 20% cuối cùng, nơi cần tư duy tích hợp
      Nếu giao việc suy nghĩ cho AI thì sức tự suy nghĩ của bản thân sẽ yếu đi
    • Trong phát triển game, quy luật 80/20 vẫn đúng y nguyên
      Kiểm thử ý tưởng thì nhanh, nhưng để thành sản phẩm hoàn chỉnh vẫn cần sự kiên nhẫn của con người
  • Với Opus 4.5, điều cải thiện lớn không phải tri thức đơn thuần mà là khả năng giải quyết vấn đề tự chủ
    Nếu bài toán được định nghĩa rõ ràng thì nó gần như giải quyết được hết, thậm chí còn làm cả reverse engineering
    Gần đây tôi không còn code trực tiếp nhiều nữa mà viết đặc tả rồi chỉ huy để Opus thực thi và cải thiện

    • Ví dụ công khai gồm có coding-agent-benchmark
      dự án reverse engineering game C64
    • Tôi tò mò cách ngăn chặn “thiết kế quá mức”
    • Tôi thấy dùng ứng dụng web Claude để rubber duck debugging hiệu quả hơn
      Claude Code mạnh vì có thể nhìn toàn bộ codebase, nhưng tiêu quota quá nhanh
      Nên tôi lại quay về bản web
    • Dạo này tôi cũng đang làm side project gần như theo đúng cách này
  • Với Opus 4.5 tôi đã thử cả trình thông dịch JavaScript viết bằng Python, runtime WebAssembly, lẫn port routine tìm chuỗi của Rust sang C
    Hầu hết đều được thử nghiệm trên điện thoại, và kết quả thật đáng kinh ngạc

    • Nếu “trình thông dịch JS viết bằng Python” dựa trên MQJS của Bellard, thì nên ghi rõ nguồn
      Tham khảo: micro-javascript
    • Nó vẫn yếu ở các bài toán cần suy luận trực quan, ví dụ như thuật toán đường đi của slime mold
    • Tôi khá tò mò về kết quả “port routine của Rust sang C mà lại nhanh hơn”
    • Tôi từng bảo nó “hãy viết trình thông dịch Python 3 bằng JavaScript”, và nó khiến tôi bất ngờ khi còn cho pass cả test
    • Nhưng gần đây tôi không còn cảm nhận được khác biệt lớn. Mô hình thì chững lại, còn framework tác tử dường như mới là thứ tiến bộ
      Video ví dụ: liên kết Mastodon
  • Lý do nhà phát triển thực sự được thuê là vì trách nhiệm
    Ngay cả thời còn copy code từ StackOverflow hay GitHub thì công cụ vẫn đã tồn tại,
    nhưng khi có sự cố thì người chịu trách nhiệm cuối cùng vẫn là con người

    • Dạo này người có thể chịu trách nhiệm mới là nhân tố quan trọng nhất
      Nếu có một đồng nghiệp đáng tin sẵn sàng đặt tên mình lên phần code do AI tạo ra thì cũng ổn
    • Nhưng ngành này thưởng nhiều hơn cho người tạo ra cái mới hơn là cho trách nhiệm
      Việc bảo trì thường bị xem nhẹ
    • Giờ đây review code theo thời gian thực đã trở thành chế độ mặc định
      Cuối tuần rồi tôi làm 80% một SaaS bằng AI và chỉ tự viết phần lõi
      Khi tôi dán vào đặc tả ngôn ngữ đã viết từ 22 năm trước, Opus hoàn thành parser và test chỉ trong 3 phút
      Rốt cuộc chúng ta đang ở thời điểm phải thích nghi với thay đổi như ngành khai khoáng
    • Vì vậy tôi thấy thoải mái hơn khi dùng AI như biên tập viên·người review hơn là tác giả
      Tôi viết code, còn AI lo tìm vấn đề và đề xuất test
  • Opus 4.5 đang giúp tôi tạo ra một ngôn ngữ lập trình mới
    Chúng tôi thảo luận cả về hiện thực low-level, hợp tác như đang pair programming
    Nhưng với codebase lớn thì vẫn cần khả năng kiểm soát có hệ thống của con người
    Nếu không, Opus sẽ tự ý đổi đặc tả hoặc lấy giải pháp tạm bợ để che lấp
    Đây không phải cây đũa thần, nhưng có lẽ sẽ là năm năng suất nhất trong đời tôi
    Đồng thời, nếu công nghệ này trở nên phổ biến, tôi cũng kỳ vọng sự hồi sinh của các cộng đồng web nhỏ

    • Có thể một ngày nào đó AI sẽ tự bảo trì code,
      nhưng trước thời điểm đó tôi nghĩ ngôn ngữ con người dễ hiểu sẽ còn quan trọng hơn
    • Cũng có góc nhìn hoài nghi kiểu “liệu làm thứ đó có thật sự có ý nghĩa không”
    • Cũng có phản ứng đùa nửa thật kiểu “ai mà mua cuốn tiểu thuyết đó chứ”
  • Tôi từng giao cho Opus 4.5 nhiệm vụ “hãy cải thiện toàn bộ project”, và kết quả là nó tạo ra kiến trúc lạc quẻ cùng vô số bug
    Nó rất giỏi ở test hay dò bug, nhưng nếu giao thiết kế cấu trúc tổng thể thì sẽ hối hận

    • Thay vào đó, hiệu quả hơn là bảo nó “hãy đề xuất ý tưởng cải thiện”, chọn cái ổn rồi nhờ Claude giải thích trước sau đó mới cho triển khai
    • Nó hoạt động tốt nhất khi bạn biết rõ muốn cải thiện cái gì
      “Cứ cải thiện đại đi” là prompt tệ nhất
    • Những trường hợp như vậy là ví dụ rất tốt cho thấy điểm yếu của mô hình
      Trước đây từng có người để tác tử tự cải thiện suốt đêm và nhận lại 100.000 dòng code rác
      Vì vậy phát triển dựa trên kế hoạch là rất quan trọng
      Tham khảo: The Highest Quality Codebase
    • Hầu hết mô hình, kể cả Opus, đều yếu trong việc cải thiện code có sẵn, nhưng lại viết code mới khá tốt
    • 90% đề xuất review code từ AI là vô dụng, nhưng 10% còn lại lại thực sự bắt được vấn đề
      Có cảm giác nó có thể cứ tiếp tục đề xuất chỉnh sửa mãi như một vòng lặp vô tận
 
[Bình luận này đã bị ẩn.]