Sự thay đổi của quy trình làm việc khi lập trình
- Vào tháng 11 năm 2024, tỷ lệ là 80% thủ công + tự động hoàn thành, 20% code bằng agent, nhưng đến tháng 12 thì tỷ lệ này đảo ngược thành 80% code bằng agent và 20% chỉnh sửa/touch-up
- Thực tế đã trở thành tình huống lập trình bằng tiếng Anh, theo kiểu nói cho LLM biết phải viết đoạn mã nào
- Dù có phần làm tổn thương cái tôi, nhưng sức mạnh khi xử lý phần mềm theo đơn vị "hành động trên mã" quy mô lớn là cực kỳ hữu ích
- Nếu thích nghi với điều này, thiết lập, học cách dùng và nắm được điều gì làm được/không làm được thì sẽ hiệu quả hơn nhiều
- Đây là thay đổi nền tảng lớn nhất trong quy trình code trong khoảng 20 năm kinh nghiệm lập trình của anh ấy, và nó diễn ra chỉ trong vài tuần
- Dự đoán điều tương tự có lẽ đang xảy ra với khá nhiều kỹ sư (mức hai chữ số phần trăm), nhưng nhận thức của công chúng nói chung được ước tính chỉ ở mức phần trăm một chữ số thấp
IDE / bầy agent / khả năng mắc lỗi
- Anh ấy cho rằng những lời cường điệu kiểu "không cần IDE nữa" hoặc "bầy agent" hiện tại vẫn là phóng đại
- Mô hình vẫn mắc lỗi, và nếu có mã quan trọng thật sự thì vẫn phải giám sát bằng con mắt đại bàng, đồng thời cần mở một IDE lớn bên cạnh
- Bản chất của lỗi đã thay đổi: không còn chỉ là lỗi cú pháp đơn giản, mà là các lỗi khái niệm tinh vi kiểu một lập trình viên junior hơi cẩu thả và vội vàng dễ mắc phải
- Loại lỗi phổ biến nhất: tự đặt ra giả định sai thay cho người dùng rồi cứ thế tiếp tục mà không xác nhận
- Các vấn đề bổ sung:
- Không quản lý được sự rối rắm
- Không yêu cầu làm rõ
- Không chỉ ra sự không nhất quán
- Không đưa ra các đánh đổi
- Không phản biện khi cần phản biện
- Vẫn còn phần nào xu hướng nịnh ý (sycophantic)
- Ở chế độ lập kế hoạch thì tốt hơn, nhưng cần một chế độ lập kế hoạch nội tuyến gọn nhẹ
- Cũng có xu hướng làm code và API phức tạp quá mức, phình abstraction lên và không dọn dẹp dead code sau khi làm xong
- Có khi nó triển khai một cấu trúc kém hiệu quả, cồng kềnh và mong manh trong 1000 dòng, nhưng nếu hỏi "làm thế này không được à?" thì nó lại đáp "được chứ!" và lập tức rút xuống còn 100 dòng
- Vẫn có trường hợp nó sửa/xóa comment và code mà nó không thích hoặc chưa hiểu đủ, dù điều đó không liên quan tới tác vụ
- Ngay cả khi đưa hướng dẫn vào CLAUDE.md để thử chỉnh nhẹ thì các vấn đề này vẫn xuất hiện
- Dù có các vấn đề đó, đây vẫn là một cải tiến cực kỳ lớn, và rất khó quay lại code thủ công
- Quy trình hiện tại: bên trái là một vài phiên Claude Code trong cửa sổ/tab ghostty, bên phải là IDE để kiểm tra code và chỉnh sửa thủ công
Sự bền bỉ (Tenacity)
- Việc nhìn agent bám lì vào một vấn đề không nghỉ thực sự rất thú vị
- Nó không biết mệt, không nản chí, và vẫn tiếp tục thử ngay cả trong những tình huống mà con người hẳn đã bỏ cuộc từ lâu để hẹn làm sau
- Khi thấy nó vật lộn với thứ gì đó trong thời gian dài và cuối cùng thành công sau 30 phút, đó giống như một khoảnh khắc "cảm nhận được AGI"
- Điều đó khiến ta nhận ra thể lực bền bỉ là nút thắt cổ chai cốt lõi của công việc, và khi cầm LLM trong tay thì yếu tố này tăng lên mạnh mẽ
Tăng tốc
- Không rõ nên đo "mức tăng tốc" của việc có LLM hỗ trợ như thế nào
- Những việc vốn định làm chắc chắn có cảm giác nhanh hơn nhiều, nhưng hiệu ứng chính là làm được nhiều hơn rất nhiều so với dự định ban đầu:
- Có thể code đủ loại thứ mà trước đây không đáng để bỏ công code
- Có thể tiếp cận những phần code mà trước đây không làm được vì thiếu kiến thức/kỹ năng
- Đó là tăng tốc, nhưng có lẽ phần lớn hơn là mở rộng (expansion)
Đòn bẩy
- LLM đặc biệt giỏi trong việc chạy vòng lặp cho tới khi đạt được mục tiêu nhất định, và đó là phần lớn phép màu tạo cảm giác "AGI"
- Đừng nói nó phải làm gì, hãy đưa ra tiêu chí thành công rồi quan sát
- Hãy để nó viết test trước rồi bắt nó vượt qua các test đó
- Hãy đưa browser MCP vào vòng lặp
- Trước tiên hãy để nó viết một thuật toán ngây thơ nhưng khả năng đúng rất cao, rồi yêu cầu tối ưu trong khi vẫn giữ nguyên độ chính xác
- Khi chuyển cách tiếp cận từ mệnh lệnh sang khai báo, agent có thể lặp lâu hơn và tạo ra nhiều đòn bẩy hơn
Niềm vui
- Điều không ngờ tới là khi làm cùng agent, việc lập trình lại trở nên vui hơn
- Những việc chán ngắt kiểu điền vào chỗ trống bị loại bỏ, chỉ còn lại phần sáng tạo
- Tình trạng bí/khựng lại (trạng thái không vui) giảm đi, và ta có nhiều dũng khí hơn — vì lúc nào cũng có cách để cùng nhau tạo ra tiến triển tích cực
- Cũng có những người cảm thấy ngược lại: code với LLM sẽ chia kỹ sư thành những người thích việc code tự thân và những người thích tạo ra sản phẩm
Sự thoái hóa (Atrophy)
- Anh ấy nhận ra khả năng tự tay viết code thủ công đang dần mai một
- Sinh ra (viết code) và phân biệt/đánh giá (đọc code) là hai năng lực khác nhau trong não
- Do có nhiều chi tiết cú pháp nhỏ liên quan đến lập trình, dù gặp khó khăn khi viết thì vẫn có thể review code mà không vấn đề gì
Slopacolypse
- Dự đoán năm 2026 sẽ là năm của Slopacolypse (làn sóng nội dung AI chất lượng thấp tràn ngập) trên GitHub, Substack, arXiv, X/Instagram và nói chung là toàn bộ truyền thông số
- Ngoài những cải tiến thực sự, sẽ còn xuất hiện nhiều hơn nữa các màn sân khấu năng suất được AI thổi phồng quá mức (liệu điều đó còn có thể phóng đại thêm nữa sao?)
Những câu hỏi
- "Kỹ sư 10X" đang trải qua điều gì? — Tỷ lệ năng suất giữa kỹ sư trung bình và kỹ sư hàng đầu? Tỷ lệ này có thể tăng mạnh
- Khi được trang bị LLM, liệu generalist sẽ ngày càng vượt specialist? LLM giỏi ở việc lấp đầy chỗ trống (vi mô) hơn rất nhiều so với đại chiến lược (vĩ mô)
- Việc code với LLM trong tương lai sẽ có cảm giác như thế nào? Giống như chơi StarCraft? Hay như chơi Factorio, hoặc như đang biểu diễn âm nhạc?
- Bao nhiêu phần của xã hội đang bị lao động tri thức số làm nút thắt cổ chai?
TLDR
- Năng lực agent LLM như Claude và Codex đã vượt qua một kiểu ngưỡng nhất quán nào đó vào khoảng tháng 12 năm 2025, tạo ra một chuyển pha (phase shift) trong kỹ nghệ phần mềm và các lĩnh vực liên quan
- Phần trí tuệ dường như đột nhiên đi trước đáng kể so với mọi thứ còn lại — tích hợp (công cụ, tri thức), nhu cầu về quy trình làm việc tổ chức mới, quy trình, và sự lan tỏa rộng hơn nói chung
- Năm 2026 sẽ là một năm năng lượng cao khi ngành công nghiệp tiêu hóa những năng lực mới này
14 bình luận
Dựa trên nội dung trong bài viết này, có vẻ một phiên bản skills nhằm cải thiện cách hoạt động của Claude Code cũng đã được công bố.
Karpathy-Inspired Claude Code Guidelines : https://github.com/forrestchang/andrej-karpathy-skills
Đây vẫn là một băn khoăn cứ lởn vởn trong đầu tôi: với những người đã quen với việc tự tay viết code thì việc giám sát LLM là tốt, nhưng với người mới học, nếu chỉ nhìn vào đoạn code do LLM tạo ra thì có lẽ sẽ rất khó biết nó đúng hay sai.
Không biết ngày xưa những người từng viết bằng assembler, khi compiler xuất hiện, có từng nghĩ kiểu như làm sao mà tin được một compiler lại nhả ra đống mã assembly tệ hại như vậy không.
Hồi đó chắc dù viết bằng C họ vẫn sẽ code theo cách dẫn dắt để đầu ra assembly được tạo ra đúng như ý mình.
Cũng khá tò mò không biết khi kỷ nguyên AI tiến xa hơn nữa thì liệu có thể tạo ra sản phẩm hoàn chỉnh chỉ bằng ngôn ngữ tự nhiên mà không cần con người giám sát hay không.
Các chuyên gia assembly đến giờ vẫn chê compiler. Rốt cuộc điều quan trọng là trong những tình huống cần tối ưu hóa đến cực hạn thì vẫn cần những specialist như vậy; nếu áp vào AI thì dù AI có phát triển đến đâu cũng có thể vẫn khó vượt được những người code cực kỳ xuất sắc ở mức đó. Còn ở mặt bằng chung thì về cơ bản đã không còn con người nào có thể thắng AI nữa rồi. Nếu lại có thêm một khoảnh khắc kiểu AlphaGo với một cuộc đối đầu AlphaCode thì chắc sẽ rất thú vị.
Nếu có nỗ lực phân tích và hiểu đoạn mã mà nó tạo ra thì có lẽ vẫn ổn.
Trình biên dịch là một khái niệm hơi khác, vì nó tạo assembly dựa trên quy tắc nên thuộc miền mang tính quyết định; do đó chỉ cần rà soát một lần thì sau đó vấn đề sẽ không tái diễn. Nhưng LLM thuộc miền xác suất, nên vẫn có khả năng vấn đề lặp lại.
Không rõ khi độ chính xác xác suất này tiếp tục phát triển thì có thể tiến gần 100% hay không, nhưng nếu chính yêu cầu bằng ngôn ngữ tự nhiên đã không chính xác thì rốt cuộc kết quả cũng sẽ không chính xác, nên tôi nghĩ một bản hoàn thiện
tốtcuối cùng vẫn phụ thuộc vào con người.Tôi cũng lo cho các bạn junior đã tiếp xúc với LLM từ thời còn là sinh viên. Tôi cũng có cảm giác là nguồn tuyển dụng cho vị trí junior có vẻ đã xấu đi đôi chút, nhưng lại khó mà chứng minh được...
Cá nhân tôi thấy nếu chỉ có kiến thức CS thì chắc cũng không khác biệt nhiều lắm.
Hoặc cũng có thể là vì cách tôi đang dùng giống như pair programming với một người bạn gõ tay cực nhanh và viết hết toàn bộ code cho mình...
Cuối cùng, khi đi sâu vào phát triển thì sẽ đến lúc phải hiểu được bên trong các lớp trừu tượng.
Khoảng cách giữa prompt ngôn ngữ tự nhiên và đoạn mã được sinh ra là quá lớn, nên có vẻ rất khó đi từ prompt vào bên trong lớp trừu tượng của LLM.
Hiện tại, cách chúng ta làm là truyền cho LLM bằng prompt khái niệm về đặc tả vốn có trong đầu, rồi đọc lại và kiểm chứng đoạn mã đã được viết ra.
Vì vậy nó gần với việc review code do người khác viết hơn, nên tôi không có cảm giác là mình đang đi vào bên trong lớp trừu tượng.
Có vẻ như tôi đã quá xem nhẹ 20% đó
Gần đây tôi gặp một lỗi mà AI không thể giải quyết... nó không phải vạn năng, nhưng tôi đã nhận ra mình đang xem nó như thể vạn năng vậy.
Ái chà... haha
Tôi rất đồng cảm với điều này. Trong dự án gần đây, tôi đã commit khoảng 100 nghìn dòng (lượng mã thực tế còn nhiều hơn) và trung bình sử dụng 2–3 agent. Có lẽ khoảng 95% là do agent viết.
Nhưng vẫn cần quản lý các bài kiểm thử và mã chết, đồng thời cần chi tiết về các ca kiểm thử và điều kiện để kiểm thử thành công. Việc quản lý cần làm gì và đến đâu là rất quan trọng. Để làm được điều đó, không chỉ kế hoạch mà cả kiến trúc tạo ra harness, Rules và các thiết lập khác cũng phải được cập nhật liên tục.
Ý kiến trên Hacker News
Thật thú vị khi thấy agent không biết mệt và cứ tiếp tục thử
GPU và NPU đang chạy nóng rực, còn chúng ta thì giao cả những dữ liệu mà bình thường sẽ không chia sẻ
Lúc này có vẻ như một cuộc trao đổi tiện lợi, nhưng về lâu dài có nguy cơ làm gia tăng sự phụ thuộc và các vấn đề xã hội
Cuối cùng có thể dẫn tới một cấu trúc bị lệ thuộc vào những gatekeeper khổng lồ này
Khi làm việc cùng AI, vấn đề lớn hơn sự teo tóp của não bộ có lẽ là việc biến thành tự mãn và bất lực
Ban đầu dopamine tăng vọt vì kết quả đến nhanh, nhưng càng lặp lại càng có cảm giác AI đang tự ý kéo cả hướng đi của dự án
Rốt cuộc những thử nghiệm sáng tạo mà tôi muốn làm biến mất, và tôi bị hút vào lực hấp dẫn của không gian tiềm ẩn của AI
Nó giống như doomscrolling, một vòng lặp gây nghiện khiến bạn cứ muốn xem đầu ra tiếp theo
Tôi đang làm game multiplayer bằng Rust và Bevy, và dù code chạy ổn thì nó vẫn trở thành đống code mà chính tôi không hiểu
Trước đây tôi sẽ không thể đi xa đến thế nếu chưa hiểu hoàn toàn công cụ, còn bây giờ tôi đã làm ra một game hoạt động được một nửa nhưng lại không biết ECS là gì
Nghĩ đến bảo trì hay ứng phó khẩn cấp thì đây thật sự là một trạng thái nguy hiểm
Giờ đây chúng ta tập trung vào việc học cách dùng mô hình, và quên mất cách tự suy nghĩ
Cách dùng LLM liên tục thay đổi, nên rốt cuộc giống như đang đứng trên một máy chạy bộ học tập vĩnh viễn
Dù bỏ lâu thì cảm giác vẫn còn, và chỉ cần quay lại là sẽ lấy lại nhanh
Ngày càng nhiều lập trình viên thấy LLM không biết thì cứ bỏ cuộc, và không muốn đọc tài liệu nữa
Dù có tự đọc tài liệu rồi chụp cả ảnh màn hình cho họ xem, họ vẫn nghi ngờ kiểu “liệu có đúng không?”
Vì cảm giác khoái cảm ngắn hạn mà cứ liên tục ném prompt vào, rồi chờ xem “lần này sẽ ra cái gì”
Lập trình với LLM đang trở thành yếu tố phân tách giữa ‘người thích coding’ và ‘người thích xây dựng sản phẩm’
Tôi là kiểu builder thích tạo ra kết quả, nên tôi thấy thay đổi này rất vui
Ngược lại, những người thích bản thân việc coding thì thấy không thoải mái với xu hướng này
Sức hấp dẫn của lập trình vốn nằm ở quá trình cấu trúc hóa vấn đề và tự mình triển khai
Bây giờ lại có cảm giác “không phải tôi đang code mà là tôi đang sai khiến”, nên hứng thú giảm đi
Trước đây cũng từng có những đối lập như compile vs interpret, typed vs untyped, triển khai nhanh vs khả năng bảo trì
Cuối cùng, phần mềm thành công đều trải qua quá trình chuyển từ giai đoạn đầu hỗn loạn sang giai đoạn mở rộng ổn định
AI có giúp quá trình đó hay lại làm nó phức tạp hơn thì tôi vẫn chưa chắc
Họ thấy vui không chỉ ở sản phẩm đầu ra, mà còn ở quá trình tổ chức cấu trúc hệ thống
Đồng đội con người có trách nhiệm và sự tin cậy, còn LLM thì không
Ý tưởng rằng AI có thể mang lại mức tăng năng suất gấp 10 lần khá thú vị
DevOps đã thay đổi cách phối hợp giữa phát triển và vận hành để tạo ra những đội ngũ hiệu suất cao, và điều này dẫn đến hiệu quả gần với phiên bản 10X ở cấp độ đội nhóm
Muốn dùng AI coding tốt thì cũng như DevOps, cần có quá trình xây dựng niềm tin thông qua cải tiến liên tục, thay đổi workflow, tự động hóa và kiểm chứng
DevOps cũng không thể phổ biến rộng vì đòi hỏi phải học khái niệm mới và thay đổi văn hóa đội ngũ; AI coding cũng vậy, nếu không có thay đổi về học tập/văn hóa thì dù có tiềm năng 10X, việc thích nghi vẫn có thể chậm
Để bám rễ, cần giáo dục và thay đổi văn hóa kỹ thuật
Tôi từng cảm thấy LLM vô dụng với codebase quy mô lớn
Đặc biệt với những đoạn code phức tạp và có nhiều tương tác thì gần như không giúp được gì
Đưa nó vào codebase lớn/phức tạp sẵn có thì rất rủi ro, trừ khi chỉ là những thay đổi giới hạn có review kỹ lưỡng
Cách làm là đưa danh sách file trong một cấu trúc đơn giản rồi giao cho agent triển khai thì rất ấn tượng, nhưng khi độ phức tạp tăng lên, prompt cũng phải ngày càng đi xuống mức chỉ dẫn chi tiết thì mới còn hiệu quả
Không giống các mô hình trước, giờ đây nó có thể hỗ trợ thực chất cả trong những monorepo phức tạp
Hãy thử so sánh xem nó có làm tốt hơn một thành viên mới trong nhóm khi được cung cấp cùng lượng thông tin hay không
Codebase nội bộ thương mại thường trở nên lộn xộn do phát triển lặp đi lặp lại để đáp ứng yêu cầu khách hàng, trong khi các giả định ban đầu và yêu cầu thực tế ngày càng lệch nhau, dẫn tới nợ kỹ thuật
Nếu dùng LLM để refactor như tách helper/module hóa/đổi tên nhằm sắp xếp lại theo yêu cầu hiện tại, thì về sau hành vi của agent sẽ dễ dự đoán hơn
Cần có luồng làm việc theo từng bước: ghi lại yêu cầu/tiêu chí chấp nhận/user story bằng markdown, để nó viết kế hoạch chi tiết rồi mới chuyển sang triển khai
Điều ấn tượng là điểm mà sự bền bỉ và thể lực của AI vượt qua giới hạn con người
Ngay cả trong nghiên cứu, người ta cũng nói grit gắn với thành công hơn là trí thông minh
Chừng nào ngân sách còn cho phép, LLM có sự bền bỉ gần như vô hạn
Trong vài tháng gần đây, tôi lại có cảm giác hiệu năng AI thậm chí đang thụt lùi
Nó quên quy tắc, tạo ra kế hoạch quá mức và code bị over-engineer
Tuy vậy, ở mảng frontend (HTML + Tailwind) thì vẫn hữu ích
Tôi thấy kỳ vọng quá mức vào IDE hay agent swarm vẫn còn quá sớm
Khi làm ứng dụng iPhone, tôi rất ấn tượng với khả năng sinh code từ prompt tiếng Anh của Claude
> Việc lập trình bằng LLM đang phân hóa thành các kỹ sư thích bản thân việc code và các kỹ sư thích tạo ra sản phẩm
Nếu tổng hợp những gì tôi nghe từ những người xung quanh thì cuối cùng có vẻ đúng là đang chia thành như vậy.