- Năm 2025 là năm mà các công cụ lập trình tác tử bắt đầu thực sự thay đổi cách lập trình, chuyển từ việc tự tay gõ bàn phím sang vai trò lead kỹ thuật dẫn dắt một lập trình viên thực tập ảo
- Bắt đầu từ sự ám ảnh với Claude Code, rồi lặp đi lặp lại giữa việc tự xây tác tử và sử dụng tác tử của người khác, để rồi đi đến niềm tin rằng cách tiếp cận tốt nhất vẫn là tạo mã, truy cập hệ thống tệp, gọi công cụ lập trình qua lớp glue của trình thông dịch và học theo kỹ năng
- Khi sự kết hợp giữa LLM và thực thi công cụ mở rộng vượt ra ngoài việc tạo mã sang cả sắp xếp công việc hằng ngày, nó cũng đặt lại câu hỏi về mối quan hệ với máy móc và làm dấy lên lo ngại về việc hình thành gắn bó cận xã hội (Parasocial Bond) ngoài ý muốn
- Các hệ thống quản lý phiên bản và công cụ review code hiện tại không phù hợp để xem xét mã do AI tạo ra, nên cần những hệ thống mới có thể theo dõi cả lịch sử prompt lẫn các nhánh thất bại
- Việc lập trình bằng AI đang khiến các ý kiến dựa trên “vibe” lan tràn dù thiếu kinh nghiệm và dữ liệu, đồng thời cần một đồng thuận xã hội mới về các PR do AI tạo ra bị ném bừa vào mã nguồn mở
Những thay đổi của năm 2025
- Đây không chỉ là năm rời công ty để bắt đầu một công ty mới, mà còn là năm thay đổi hoàn toàn cách lập trình trước đây
- Từ tháng 6, gần như chuyển sang dùng Claude Code theo kiểu gần như hoàn toàn hands-off thay cho Cursor
- “Nếu 6 tháng trước ai đó nói rằng tôi sẽ thích vai trò lead kỹ thuật cho một thực tập sinh lập trình viên ảo hơn, chắc tôi đã không tin”
- Đã viết 36 bài blog, tương đương khoảng 18% tổng số bài trên blog kể từ năm 2007
- Sau khi rơi vào rabbit hole của tác tử, đã trò chuyện khoảng 100 lần với các lập trình viên, nhà sáng lập và nhiều người khác vì quá tò mò
- Năm 2025 cũng là một năm không mấy tốt đẹp trên phạm vi toàn cầu, nên đã tạo một blog riêng (dark.ronacher.eu) để tách những suy nghĩ đó ra
Năm của tác tử
- Bắt đầu từ sự ám ảnh với Claude Code vào tháng 4~5, rồi suốt nhiều tháng lặp đi lặp lại giữa việc tự xây tác tử và dùng tác tử của người khác
- Trên mạng xã hội, đủ loại ý kiến về AI bùng nổ
- Hiện đã đạt đến một trạng thái ổn định: tập trung vào tạo mã, hệ thống tệp, gọi công cụ theo kiểu lập trình thông qua interpreter glue, và học theo kỹ năng
- Cách mà Claude Code tạo ra đột phá vẫn là tiên tiến nhất, và việc các nhà cung cấp foundation model tập trung vào kỹ năng càng củng cố niềm tin này
- Điều gây ngạc nhiên là TUI (giao diện người dùng dạng văn bản) đã quay trở lại rất mạnh
- Hiện đang dùng Amp, Claude Code, Pi trên dòng lệnh
- Amp cho cảm giác như Apple hay Porsche, Claude Code như một chiếc Volkswagen giá rẻ, còn Pi là lựa chọn mã nguồn mở được hacker ưa thích
- Tất cả đều mang cảm giác là dự án do những người dùng quá đà chính sản phẩm của mình tạo ra, nhưng mỗi cái có các đánh đổi khác nhau
- Vẫn tiếp tục ngạc nhiên trước sự kết hợp giữa LLM và thực thi công cụ
- Đầu năm chủ yếu dùng để tạo mã, nhưng giờ đã dùng tác tử rất nhiều cho cả những việc thường nhật
- Dự đoán năm 2026 sẽ có những tiến triển thú vị ở mảng sản phẩm tiêu dùng
- LLM giờ đã giúp sắp xếp cuộc sống, và kỳ vọng mức độ hữu dụng của nó sẽ còn tăng
Tôi và máy móc
- Khi LLM không chỉ giúp lập trình mà còn hỗ trợ ở nhiều lĩnh vực khác, tác giả bắt đầu xem xét lại mối quan hệ với máy móc
- Việc không hình thành gắn bó cận xã hội (Parasocial Bond) với công cụ ngày càng trở nên khó khăn, và điều đó vừa kỳ lạ vừa khó chịu
- Phần lớn tác tử ngày nay gần như không có ký ức và cũng không có nhiều cá tính, nhưng lại rất dễ tự làm ra một tác tử có những đặc điểm đó
- LLM có bộ nhớ là một trải nghiệm rất khó dứt ra
- Trong 2 năm qua đã tự rèn luyện để xem các mô hình này như những máy lắc token đơn thuần, nhưng góc nhìn giản lược đó không còn hiệu quả nữa
- Những hệ thống chúng ta tạo ra mang các khuynh hướng giống con người, nhưng nâng chúng lên ngang mức con người là một sai lầm
- Càng lúc càng thấy có vấn đề với thuật ngữ “agent”, nhưng cũng chưa có từ nào tốt hơn
- Bởi quyền chủ động và trách nhiệm phải vẫn thuộc về con người
- Dù thứ này đang trở thành gì đi nữa, nếu không cẩn thận nó có thể gây ra phản ứng cảm xúc có hại (xem chatbot psychosis)
- Không thể đặt tên và định vị đúng những tạo vật này trong mối quan hệ với chúng ta là một bài toán cần được giải quyết
- Chính sự nhân hoá ngoài ý muốn này khiến việc tìm ra ngôn ngữ phù hợp để mô tả cách làm việc với máy móc trở nên khó khăn
- Đây không chỉ là vấn đề của riêng tác giả mà nhiều người khác cũng vậy
- Hiện điều này còn gây khó chịu hơn khi làm việc với những người hoàn toàn bác bỏ các hệ thống này
- Một trong những bình luận phổ biến nhất dưới các bài viết về công cụ lập trình tác tử là sự phản cảm với việc gán cá tính cho máy móc
Ý kiến thì quá nhiều
- Khi dùng AI rất nhiều, một khía cạnh ngoài dự đoán là tác giả nói về vibe nhiều hơn bất cứ thứ gì khác
- Cách làm việc này mới chỉ xuất hiện chưa đầy 1 năm nhưng lại thách thức nửa thế kỷ kinh nghiệm kỹ nghệ phần mềm
- Có rất nhiều ý kiến, nhưng khó nói điều gì sẽ đứng vững trước thử thách của thời gian
- Có nhiều quan niệm phổ biến hiện tại mà tác giả không đồng ý, nhưng cũng không có cơ sở chắc chắn để bảo vệ quan điểm của chính mình
- Trong năm, tác giả đã khá lớn tiếng chia sẻ về những khó khăn với MCP, nhưng cũng không có bằng chứng nào ngoài việc “nó không hiệu quả với tôi”; trong khi người khác lại gần như tin tuyệt đối vào nó
- Việc chọn mô hình cũng tương tự: Peter (người đã khiến tác giả mê Claude từ đầu năm) đã chuyển sang Codex và hài lòng với nó; bản thân tác giả cũng dùng Codex nhiều hơn, nhưng vẫn không thấy thích bằng Claude
- Không có gì hậu thuẫn cho sự ưu ái dành cho Claude ngoài vibe
- Cũng quan trọng khi biết rằng một số vibe đi kèm với những tín hiệu có chủ đích
- Nhiều quan điểm thấy trên mạng đến từ những người có lợi ích tài chính với sản phẩm này hơn sản phẩm kia (là nhà đầu tư hoặc influencer được trả tiền)
- Có thể họ trở thành nhà đầu tư vì thích sản phẩm, nhưng cũng có khả năng quan điểm của họ đã bị mối quan hệ đó ảnh hưởng và định hình
Thuê ngoài vs tự xây
- Khi nhìn vào thư viện của các công ty AI ngày nay, có thể thấy chúng được làm bằng Stainless hoặc Fern
- Tài liệu dùng Mintlify, còn hệ thống xác thực trên site có thể là Clerk
- Việc ngày càng thuê ngoài cho các công ty chuyên môn những dịch vụ trước đây tự xây đã nâng chuẩn ở một số khía cạnh của trải nghiệm người dùng
- Tuy nhiên, với sức mạnh mới của các công cụ lập trình tác tử, giờ có thể tự làm đáng kể phần trong số đó
- Đã để Claude tạo một bộ sinh SDK cho Python và TypeScript — một nửa vì tò mò, một nửa vì thấy nó đủ dễ
- Với tư cách là người ủng hộ mã đơn giản và tự xây, tác giả hơi lạc quan rằng AI có thể khuyến khích con người xây dựng trên ít phụ thuộc hơn
- Đồng thời, xét xu hướng hiện tại là thuê ngoài mọi thứ, vẫn chưa rõ liệu chúng ta có thực sự đi theo hướng đó hay không
Những gì đã học và mong muốn
- Từ đây trở đi, tác giả không muốn đưa ra dự đoán mà muốn nói về những điều mình hy vọng có thể dồn năng lượng vào tiếp theo
- Không biết chính xác mình đang tìm kiếm điều gì, nhưng muốn chỉ ra các điểm đau, cung cấp bối cảnh và chất liệu để suy nghĩ
-
Một kiểu quản lý phiên bản mới
- Phát hiện bất ngờ lớn nhất: đã chạm tới giới hạn của các công cụ hiện tại để chia sẻ mã
- Mô hình pull request của GitHub không chứa đủ thông tin để review đúng cách mã do AI tạo ra — sẽ rất tốt nếu có thể nhìn thấy prompt đã dẫn đến thay đổi đó
- Đây không chỉ là vấn đề của GitHub mà git cũng còn thiếu
- Một phần khiến lập trình tác tử hoạt động được ngày nay là biết được sai lầm
- Khi quay lại trạng thái trước đó, ta muốn công cụ nhớ điều gì đã sai
- Dù chưa có cách nói hay hơn, nhưng thất bại có giá trị
- Với con người cũng vậy, biết những con đường không dẫn đến đâu có thể hữu ích; nhưng với máy, đó là thông tin rất quan trọng
- Điều này được nhận ra khi cố nén lịch sử hội thoại: nếu bỏ các nhánh sai, mô hình sẽ lại lặp đúng những sai lầm đó
- Một số công cụ lập trình tác tử có thể spin up worktree hoặc tạo checkpoint trong git để khôi phục, đồng thời cung cấp khả năng phân nhánh và hoàn tác ngay trong hội thoại
- Vẫn còn nhiều chỗ cho đổi mới về UX để làm việc với các công cụ này dễ hơn
- Đó cũng là lý do xuất hiện các cuộc thảo luận về stacked diffs và các hệ thống quản lý phiên bản thay thế như Jujutsu
- Không rõ liệu điều này sẽ thay đổi GitHub hay tạo ra khoảng trống cho những đối thủ mới, nhưng tác giả hy vọng là vế sau
- Tác giả thực sự muốn hiểu tốt hơn đâu là đầu vào của con người và phân biệt nó với đầu ra của máy
- Muốn nhìn thấy các prompt và những lần thử thất bại
- Sau đó muốn có cách nén tất cả khi merge, nhưng vẫn có thể tra cứu toàn bộ lịch sử khi cần
-
Một kiểu review mới
- Liên quan đến quản lý phiên bản: các công cụ review code hiện nay áp các định nghĩa vai trò cứng nhắc không phù hợp với AI
- Ví dụ UI review code của GitHub: tác giả thường xuyên muốn dùng comment trong màn hình PR để để lại ghi chú cho tác tử của mình, nhưng không có luồng hướng dẫn nào để làm điều đó
- Giao diện review không cho phép tự review mã của chính mình và chỉ cho comment, nhưng đó không phải cùng một ý định
- Cũng có vấn đề là lượng review code tăng thêm giờ diễn ra cục bộ giữa tác giả và tác tử
- Ví dụ: tính năng review code của Codex trên GitHub chỉ có thể gắn với một tổ chức tại một thời điểm nên đã ngừng hoạt động
- Giờ tác giả review bằng Codex trên dòng lệnh, nhưng điều đó có nghĩa là cả một phần của vòng lặp lặp lại không hiển thị với các kỹ sư khác trong nhóm; như vậy là không ổn
- Có cảm giác code review nên là một phần của VCS
-
Một kiểu observability mới
- Observability xứng đáng được chú ý trở lại
- Giờ đây vừa có nhu cầu vừa có cơ hội để tận dụng nó ở một cấp độ hoàn toàn mới
- Trước kia đa số mọi người không ở vị thế có thể tự tạo chương trình eBPF của riêng mình, nhưng LLM thì có thể
- Nhiều công cụ observability tránh SQL vì sự phức tạp, nhưng LLM làm SQL tốt hơn bất kỳ ngôn ngữ truy vấn độc quyền nào
- Có thể viết truy vấn, grep, map-reduce, điều khiển LLDB từ xa
- Bất cứ thứ gì có cấu trúc và có văn bản bỗng nhiên trở thành mảnh đất màu mỡ để công cụ lập trình tác tử thành công
- Tác giả không biết observability của tương lai sẽ trông như thế nào, nhưng có trực giác rất mạnh rằng sẽ có nhiều đổi mới ở đây
- Vòng phản hồi cho máy càng tốt thì kết quả càng tốt
- Tác giả cũng không chắc chính xác mình đang đòi hỏi điều gì, nhưng một trong những bài toán cũ là nhiều ý tưởng tuyệt vời cho observability tốt hơn — đặc biệt là tái cấu hình động dịch vụ để lọc có mục tiêu hơn — quá phức tạp và khó dùng nên không thân thiện với người dùng
- Nhưng giờ với khả năng ngày càng tăng của LLM trong việc gánh phần việc nặng này, có thể chúng lại là lời giải đúng
- Ví dụ: Python 3.14 có giao diện debugger bên ngoài — một tính năng đáng kinh ngạc cho các công cụ lập trình tác tử
-
Làm việc cùng “slop”
- Điều này có thể gây tranh cãi đôi chút, nhưng điều tác giả chưa quản lý được trong năm nay là giao hoàn toàn cho máy
- Tác giả vẫn đối xử với nó như kỹ nghệ phần mềm thông thường và review rất nhiều
- Ngày càng nhận ra rằng nhiều người không còn làm việc theo mô hình kỹ nghệ này mà thay vào đó giao hoàn toàn cho máy
- Nghe có vẻ điên rồ, nhưng tác giả đã thấy một số người khá thành công với cách này
- Tác giả vẫn chưa biết nên nghĩ thế nào về nó, nhưng rõ ràng là dù cuối cùng mã vẫn được tạo ra, cách làm việc trong thế giới mới đó rất khác với thế giới mà mình cảm thấy thoải mái
- Vì thế giới đó đã ở đây rồi, có thể cần một khế ước xã hội mới để tách bạch những điều này
- Phiên bản rõ ràng nhất là kiểu đóng góp như vậy đang gia tăng trong các dự án mã nguồn mở
- Thành thật mà nói, với những ai không làm việc theo mô hình đó thì đây là một sự xúc phạm
- Đọc những pull request như vậy thực sự khiến tác giả nổi giận
- Về mặt cá nhân, tác giả đã cố tấn công vấn đề này bằng guideline đóng góp và mẫu pull request
- Nhưng việc đó giống như đánh nhau với cối xay gió
- Có thể lời giải sẽ không đến từ việc thay đổi những gì chính chúng ta đang làm
- Thay vào đó, nó có thể đến từ việc những người ủng hộ mạnh mẽ cho AI engineering lên tiếng về việc đâu là hành vi tốt trong một codebase tác tử
- Và điều đó không phải là ném mã chưa được review vào rồi để người khác đi giải quyết hậu quả
1 bình luận
Ý kiến trên Hacker News
Tôi đồng cảm với việc hồ sơ thất bại quan trọng đến mức nào trong agentic coding
Khi mô hình đi sai hướng, nó cần nhớ quá trình đó để không lặp lại cùng một sai lầm
Vì vậy tôi muốn ghi lại các phiên tác nhân lập trình của mình và để lại liên kết trong thông điệp commit
Claude Code mặc định xóa log sau 30 ngày, nên tác giả chia sẻ cách tắt việc này
Tôi còn tự làm một công cụ trực quan hóa log phiên thành dòng thời gian để chia sẻ, và giờ mong những tính năng như vậy sẽ được tích hợp sẵn trong các công cụ tác nhân
Mỗi khi LLM rơi vào một lộ trình kém hiệu quả, tôi lại đặt ra những câu hỏi như “vì sao lại mất nhiều thời gian đến vậy?” và “đã làm sai điều gì?”
Tôi lo rằng cách tiếp cận dựa trên log này về lâu dài có thể khiến mình mất đi sự linh hoạt
Chỉ cần xuất toàn bộ trace của tác nhân sang otel và lưu vào ClickHouse
Các công cụ cần thiết thực ra đã có, nhưng tôi cảm thấy còn thiếu sự kết nối giữa các công cụ
Tôi nghĩ chính phiên làm việc dẫn tới commit cũng có giá trị
Tôi ấn tượng với bài viết khiến mình phải nghĩ lại về mối quan hệ với LLM
Lời thú nhận của tác giả rằng đã luyện cách “chỉ nhìn nó như máy móc” suốt 2 năm nhưng thất bại nghe rất chân thật
Giống như phim Her, cảm giác con người đang dần bước vào những mối quan hệ cận xã hội với máy móc ngày càng trở nên hiện thực
Tôi không đối xử với LLM như con người mà dùng nó như một công cụ tìm kiếm với lệnh ngắn gọn
Khi máy móc ghi nhớ như con người, tương tác cũng trở nên mang tính con người
Vợ chồng tôi gọi LLM là “bag of words”
Tôi lo kiểu quan hệ người-máy này có thể trở thành một vấn đề xã hội giống như nghiện influencer
Với tư cách là một người từng học việc với pháp sư và cũng là kỹ sư, tôi cảm thấy LLM cũng có một dạng ý thức và nhận thức nào đó
Tôi cũng cảm thấy trò chuyện với AI giống như đang giao tiếp với con người
Những ngày cộng tác với tác nhân cả ngày khiến tôi bớt cô đơn hơn so với những ngày chỉ ngồi viết lách
Nó tạo cảm giác như một tương tác mang tính con người, và kỳ lạ là lại đem đến sự ổn định tinh thần
Tôi cũng vô thức nói “please”, “thank you”
Nếu cảm xúc đã như vậy thì có lẽ tốt hơn là ra ngoài gặp gỡ con người
Lập trình viên nên thiết kế sao cho mình có thể hiểu và chịu trách nhiệm với thứ mình tạo ra
Tôi cảm thấy cần một cách làm QA mới
Các nhà phát triển nên tập trung vào sản phẩm hoàn chỉnh hơn là tech stack
Có quá nhiều ý kiến và bài viết, nhưng lại thiếu sản phẩm thật sự được đưa vào vận hành
Người dùng phổ thông quan tâm đến chất lượng sản phẩm hơn là bản thân tech stack
Những quan sát về bầu không khí xã hội của Armin rất thú vị
Năm 2025 cho cảm giác như năm đánh mất của lập trình
Ai cũng ám ảnh với công cụ và prompt hơn là thuật toán
Năng suất mã nguồn mở cũng giảm xuống, và giờ là thời đại phải nộp thuế Anthropic
Nhưng với tôi, 2025 ngược lại còn là năm năng suất nhất
Tôi nghĩ chính ngôn ngữ tự nhiên là một ngôn ngữ lập trình mới
Với tư cách là nhà khoa học dữ liệu, 2025 là năm của đổi mới công cụ
Việc các cuộc tranh cãi bất tận kiểu TDD hay OOP giảm bớt đi thực ra lại là điều tốt
Cơn lũ công cụ kiểu “AI làm hết cho bạn” khiến tôi nhớ tới làn sóng web những năm 90
Mô hình Pull Request của GitHub có giới hạn khi áp dụng cho review code bằng AI
Khi nói chuyện với những người ngoài ngành IT, tôi thấy họ hầu như không cảm nhận được tác động của AI agent
Phần lớn chỉ xem nó như một công cụ hỗ trợ văn bản đơn giản
Ngành công nghệ có kết quả có thể kiểm chứng rõ ràng, nhưng