Vì sao vẫn viết mã vào năm 2026

 (softwaredoug.com)
3 điểm bởi GN⁺ 4 giờ trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Vai trò của kỹ sư phần mềm đã mở rộng vượt ra ngoài việc tạo ra mã, sang xây dựng và duy trì nhà máy phần mềm, nhưng để hiểu và cải thiện hệ thống thì vẫn cần trực tiếp làm việc với mã
  • Nếu dẫn dắt tác tử bằng prompt, AGENTS.md, cơ sở tri thức, và bảo vệ kết quả bằng kiểm thử, linting, hệ thống kiểu, đánh giá thì ngay cả mô hình có hiệu năng thấp cũng có thể tạo ra những thay đổi đủ dùng
  • Khi tự viết mã, bạn có thể tư duy ngay trong môi trường thực thi mà không phải đi qua tiếng Anh, nhờ đó cảm nhận được các lỗ hổng, kiểm thử yếu và ngoại lệ không cần thiết mà chỉ rà soát mã một cách thụ động rất dễ bỏ sót
  • Tác tử gần với một thực tập sinh mới gia nhập hơn là trình biên dịch, nên chúng bảo thủ trong việc làm theo mã hiện có và các yêu cầu thiếu chính xác, đồng thời có thể khuếch đại cả những sai lầm nhất thời của con người thành các lớp bọc và tầng gián tiếp
  • Con người cần tự thử nghiệm cách tiếp cận để thiết lập mẫu, rồi để tác tử lặp lại chúng, từ đó giữ được cảm giác sở hữu và khả năng phán đoán trong khi vẫn tận dụng năng suất của tự động hóa

Nhà máy phần mềm nơi tác tử làm việc

  • Kỹ sư phần mềm không chỉ duy trì phần mềm mà còn duy trì cả dây chuyền lắp ráp cho phép bất kỳ ai yêu cầu thay đổi bằng prompt và triển khai ngay lập tức
    • Chủ động thiết lập hạ tầng để tác tử có thể thành công thông qua prompt, kỹ năng, AGENTS.md, và cơ sở tri thức
    • Bảo vệ kết quả về sau bằng đánh giá tự động sử dụng kiểm thử, linting, hệ thống kiểu, đánh giá, và cả AI khác
  • Nếu cung cấp đủ ràng buộc và ngữ cảnh mới nhất, ngay cả mô hình kém thông minh hơn cũng có thể tạo ra những thay đổi đủ dùng mà không đi chệch hướng, khiến việc con người đọc mã hay tự viết mã có vẻ không còn cần thiết
  • Tuy nhiên, ngay cả khi có tác tử với mức thông minh ngang Fable, việc trực tiếp viết mã vẫn cho phép bạn tư duy trực tiếp trong môi trường thực thi mà không cần tầng trung gian là tiếng Anh
  • Chỉ đọc thụ động các diff và patch do tác tử tạo ra thì khó kết nối sâu với kiến trúc hệ thống
    • Khi trực tiếp động vào mã, bạn có thể cảm nhận được điều gì sẽ hỏng khi thêm tính năng lên trên nó
    • Nếu dọn dẹp mã và ghi lại các nguyên tắc kiến trúc nhất quán để nhiều ngoại lệ không bị gắn thêm vào, nhà máy phần mềm cũng vận hành ổn định hơn
    • Nếu trong quá trình gỡ lỗi bạn tìm ra và sửa điểm yếu trong chiến lược kiểm thử, có thể chặn được cả một lớp lỗi mới
  • Tự viết mã không phải là cách duy nhất để hiểu phần mềm, và cũng không cần cố chấp với kiểu thủ công cực đoan như kim bị từ hóa và bàn tay không run
    • Ngay cả khi phần lớn mã thực tế được AI tạo ra, việc trực tiếp viết mã vẫn là một công cụ hữu ích

Giữ khả năng tư duy và cảm giác sở hữu bằng cách tự viết mã

  • Nếu chỉ dừng ở vai trò reverse centaur, chỉ phụ trách đọc và phê duyệt mã, thì sự tập trung và cảm giác sở hữu sẽ suy giảm, mã chất lượng thấp dễ lọt qua khâu rà soát, và cũng khó tinh chỉnh chi tiết
    • Nếu không chú ý đến chi tiết, lỗ hổng sẽ tích tụ, và về lâu dài mã chất lượng thấp cũng gây hại cho tác tử
    • Khi con người tự thử nghiệm cách tiếp cận trước rồi để tác tử lặp lại các mẫu đã được xác lập, họ vẫn có thể tiếp tục tham gia và sở hữu kết quả
  • Tiếng Anh là một ngôn ngữ thiếu đặc tả để biểu đạt tính toán một cách chính xác
    • Trong công việc thuật toán, cần hình dung và tư duy bằng các bước có thể thực thi
    • Tùy tình huống, có thể chọn ngôn ngữ cấp thấp với không gian thiết kế rộng hơn hoặc ngôn ngữ cấp cao với môi trường tính toán bị giới hạn hơn để điều chỉnh mức độ chính xác cần thiết
  • Nếu coi tác tử lập trình như trình biên dịch, điều đó có thể dẫn đến thái độ cho rằng mã viết cẩu thả vẫn có thể đem đi triển khai
    • Tác tử gần với một thực tập sinh mới gia nhập hơn là trình biên dịch
    • Chúng đọc mã hiện có có thể không hoàn chỉnh và chất lượng thấp, rồi tạo ra thay đổi mới dựa trên mô tả thay đổi thiếu chính xác
    • Con người không thể chuyển nguyên xi tư duy và gu thẩm mỹ của mình cho cả một nhóm thực tập sinh, nên không được chỉ đứng ở vị trí người tiêu dùng mà phải trực tiếp tham gia
  • Tác tử khó có thể tự giác tuân theo quy tắc Hướng đạo sinh là để mã ở trạng thái tốt hơn lúc tìm thấy, và việc giao điều đó cho chúng cũng khiến người ta thấy nặng nề
    • Chúng thiên về hướng làm cho thay đổi hiện tại an toàn nhất có thể, nên bảo tồn một cách bảo thủ các quyết định hiện có
    • Trong một codebase, khi con người vô tình dùng browser local storage cho một phần trạng thái, dù phần còn lại vẫn được lưu trong cơ sở dữ liệu backend, tác tử vẫn cố giữ quyết định đó bằng cách thêm các lớp bọc và tầng gián tiếp, khiến số dòng mã tăng gần gấp 3
    • Tính bảo thủ này có thể khuếch đại những quyết định sai lầm mang tính nhất thời của con người
  • Quá trình tự xóa mã và khám phá trực tiếp giúp đi đến kiến trúc tốt hơn so với chỉ ra lệnh bằng tiếng Anh
    • Càng chú ý đến mã, khả năng tư duy, cảm giác là tác giả, và năng lực dẫn dắt nhà máy phần mềm càng được củng cố
  • Trong nhà máy phần mềm, chi tiết vẫn quan trọng, từ các mẫu kiến trúc đến thuật toán và hiệu năng
    • Tác tử đã làm tăng nhu cầu về đánh giá, đo lường và các cơ chế bảo vệ, đồng thời thúc đẩy việc bổ sung CI từ sớm thay vì để như một việc làm sau, ngay cả trong các dự án cá nhân
    • Nhờ đó, trạng thái phát triển phần mềm đã được cải thiện đáng kể, nhưng mọi dây chuyền lắp ráp vẫn còn điểm yếu
  • Ngay cả trong nhà máy ô tô cũng có lúc cần tháo rời dây chuyền lắp ráp, hoặc đào sâu vào chi tiết của động cơ đốt trong để cải thiện 10%, hoặc ngồi quan sát việc kiểm thử má phanh cả ngày để tìm ra vì sao vấn đề tại hiện trường đã không được phát hiện sớm hơn
    • Trong phần mềm cũng vậy, nếu muốn kết nối chi tiết với cấu trúc tổng thể thì không nên vạch ra ranh giới tùy tiện về những gì mình được phép trực tiếp động vào

Bài viết liên quan

2 bình luận

 
choijaekyu 11 phút trước

Vì không có giá trị token hu hu
 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Có vẻ là điều hiển nhiên rằng nếu không thể viết code thì cũng không thể review code, nhưng vẫn có những người và công ty cho rằng cứ để Claude viết rồi Codex review là được. Dù vậy, lý do họ vẫn muốn kết quả ở các ngôn ngữ bậc cao như Python hay Java thay vì assembly hay binary đã biên dịch, rốt cuộc là vì con người phải đọc được code
    Thái độ vừa muốn lập trình viên đọc, debug và suy luận về code, lại vừa không muốn cho họ quá trình rèn luyện năng lực đó, là một mâu thuẫn

    • Lý do không bắt Claude viết assembly là vì gần như không có tài liệu huấn luyện làm app CRUD bằng assembly. Tôi không thích việc LLM lấn chiếm việc làm, nhưng cũng là thực tế rằng các mô hình tiên tiến nhất làm tốt những công việc được lặp đi lặp lại và ghi chép dày đặc trên Internet, và trong vài thập kỷ qua, phần lớn phát triển phần mềm đúng là việc sản xuất các app CRUD theo khuôn mẫu
      Vẫn còn nghi ngờ liệu ngành này có thể tiếp tục phát triển nếu giao toàn bộ sáng tạo cho LLM hay không
    • Hành vi viết code cũng chính là hành vi tư duy, nên nếu ngừng viết code thì tư duy cũng dừng lại. Ngay cả nếu có nói là đang tư duy ở tầng cao hơn, thì chính phần thiết kế cấp cao đó rồi LLM cũng sẽ làm tốt hơn, nên lợi thế hiện tại chỉ là tạm thời
    • Cuối cùng có vẻ đây là sự khác biệt trong cách nhận thức. Có người thấy code chính xác và dễ đọc hơn mô tả bằng tiếng Anh, nên với lập trình viên lành nghề chỉ cần lướt qua là hiểu được cách nó vận hành, nhưng cũng có người thấy code khó đọc và cảm thấy ngôn ngữ tự nhiên dễ tiếp cận hơn
      Không có ý nói bên nào tốt hơn; có thể những người ít coi trọng chi tiết hơn lại là người dẫn dắt thế giới, hoặc mỗi vấn đề đòi hỏi một mức độ tỉ mỉ khác nhau
    • Có vẻ Casey Muratori và Demetri Spanos đã nói về chuyện này trong một video: lý do tránh binary không hẳn vì tin LLM hơn mà gần với vấn đề mỗi máy có machine code và offset khác nhau, cùng với độ khó khi diễn giải ngữ cảnh. Cũng như sự khác biệt trong mức độ dễ hiểu giữa mã C do Ghidra decompile và mã nguồn C do lập trình viên viết, ngôn ngữ bậc cao có thể chứa đựng ý đồ của code
      Compiler giúp LLM viết ra code thực sự có thể compile và chạy, nhưng nếu xuất thẳng machine code thì khả năng cao là còn chẳng chạy được. Tất nhiên, nếu hoàn toàn không thể tự viết code thì việc review sẽ còn khó hơn rất nhiều
    • Cũng có người thực sự cho rằng Claude nên xuất trực tiếp assembly hoặc binary. Chỉ là như vậy có thể kém tính di động hơn so với ngôn ngữ bậc cao vốn có thể compile thành assembly cho nhiều loại máy

  • “Trong ngành này, người ta gọi một bản đặc tả dự án đủ bao quát và chính xác để tạo ra chương trình là gì? Người ta gọi nó là code” — CommitStrip
    Nếu được viết đúng cách, cốt lõi của code là phải biểu đạt logic nghiệp vụ nền tảng theo cách đơn giản nhất. Có thể không cần review toàn bộ các tầng hỗ trợ, nhưng nếu chưa đọc code thì cũng khó nói là đã hiểu hoàn toàn logic nghiệp vụ

    • Liên kết bài gốc
    • Trong một bài viết khác về chủ đề này cũng khuyên dùng code thay vì spec. Có thể chỉ dẫn agent bằng code hoặc tạo sẵn các ví dụ để nó làm theo
      https://softwaredoug.com/blog/2026/07/04/write-code-not-specs
    • Đây là lý do cần Lisp. Trước hết hãy tạo một ngôn ngữ lập trình lấy các thành phần cơ bản của logic nghiệp vụ làm thành phần cơ bản của chính ngôn ngữ đó, rồi dùng ngôn ngữ mới ấy để viết một chương trình đơn giản mô tả doanh nghiệp đang làm gì

  • Câu hỏi quan trọng là ai sẽ trả tiền cho việc viết code thủ công. Khách hàng trả tiền không phải cho việc viết hay sinh ra code, mà cho giải quyết vấn đề, nên bên nào giải quyết với chi phí và sự xáo trộn thấp nhất sẽ giành được hợp đồng, và lợi ích AI tool giúp rút ngắn tiến độ là điều khó bỏ qua
    Tôi ở trong ngành này từ thập niên 1990, và những lập trình viên không quá xuất sắc tạo ra kết quả tầm thường thì lúc nào cũng nhiều. Người ta lãng mạn hóa code viết tay quá mức, nhưng thực tế codebase theo thời gian thường trở nên khó bảo trì và đầy lỗi, còn các dự án làm cẩu thả thì cũng chẳng phải hiện tượng mới mẻ gì

    • Ngược lại, tôi cho rằng tự viết một lượng code ít hơn mới giúp tăng năng suất. Dành một ngày để tái cấu trúc kiến trúc bằng tay có thể tiết kiệm hàng nghìn đô chi phí token và vài tuần đau đầu
      Bây giờ giống như đang cố xây một nhà máy phần mềm khi cả hai tay đều bị trói
    • Giờ đây các lập trình viên tầm thường đang sản xuất ra kết quả tầm thường nhiều gấp 10 lần
    • Trong các ngành mà chất lượng phần mềm là tối quan trọng và bị quản lý chặt, như y tế, hàng không, điện hạt nhân, tôi hy vọng người ta vẫn tiếp tục trả tiền cho việc viết code thủ công. Chỉ là thị trường này tương đối nhỏ

  • Muốn tập trung và hiểu được thì không thể chỉ đứng từ xa quan sát agent rồi đọc code một cách thụ động, mà phải tự mình trải nghiệm code. Cuối cùng điều đó có nghĩa là phải rèn luyện mô hình tinh thần của chính mình
    Khi code, tiềm thức đưa ra rất nhiều phán đoán kiểu “cảm giác như thế này là đúng”, và thứ đó chỉ được hình thành nhờ lặp lại cùng sự tập trung sâu; chỉ review code hay đọc tài liệu thì có giới hạn. Khi đã có mô hình tinh thần như vậy, chỉ nhìn thông báo lỗi của một sự cố vận hành cũng có thể lập tức chỉ ra nguyên nhân, còn với code được sinh ra thì phải lần mò rất lâu bằng tư duy có ý thức chậm chạp
    Nếu LLM thực sự hữu ích, thì phải có thể giả định nó đảm nhận toàn bộ việc bảo trì code và hoạt động như một thư viện bên ngoài; nếu không thì vấn đề sẽ tiếp tục phát sinh

    • Con người cũng từng thử kiểu tách biệt này rồi, và nó hoạt động tệ đến mức xuất hiện cả biệt danh kiến trúc sư tháp ngà. Trong hệ thống thực tế, người ta đưa ra các thiết kế lý thuyết không thể triển khai, đội thực thi hoặc LLM thì tìm cách lách kiến trúc, còn trong lúc kiến trúc sư và người triển khai cãi nhau lệch pha, tốc độ phát triển chậm đi đáng kể
    • Trong lĩnh vực observability, người ta sẽ cho rằng nếu chỉ dựa vào hành vi runtime động mà khó tìm được nguyên nhân thì cần làm hệ thống minh bạch và có khả năng quan sát tốt hơn. Con người có thể di chuyển hoặc nghỉ việc, nên nguyên tắc không được phụ thuộc vào mô hình tinh thần của một cá nhân xuất sắc vốn đã đúng từ trước
      Tôi vẫn chưa biết bên nào đúng hơn và đang tiếp tục tìm hiểu

  • Đến năm 2026, code do AI sinh ra vẫn còn rất tệ. Dù là Fable hay bộ harness LeetCode Pi/opencode tùy chỉnh thì kết quả vẫn kinh khủng, và nếu bạn không phân biệt được chênh lệch chất lượng giữa code của mình và code AI thì đó là tin không vui

    • Code của tôi trước đây tệ hơn AI, hoặc giờ vẫn thế, nhưng ít nhất tôi vẫn được trả tiền, nên tin xấu đó cũng không quan trọng lắm

  • Tác giả đã ghi rõ trong quy tắc rằng agent phải chạy profile để tuân theo quy tắc Boy Scout, kiểm tra độ bao phủ mã, rà soát phản biện, và viết báo cáo cùng các đầu việc tiếp theo. LLM tiên tiến nhất hiện nay làm theo các quy tắc này tốt hơn rất nhiều so với 90% những người tôi từng làm việc cùng, nên tôi cũng tự hỏi liệu điều đó có thực sự là xấu hay không

    • Agent hiện nghiêng mạnh về phía làm cho thay đổi hiện tại an toàn tối đa. Có lần khi còn chưa uống cà phê xong, tôi lỡ bảo nó dùng local storage của trình duyệt, và dù toàn bộ trạng thái còn lại đều nằm trong cơ sở dữ liệu backend, nó vẫn thêm wrapper và các lớp gián tiếp để giữ lại quyết định sai đó, khiến số dòng mã gần như tăng gấp ba
      Agent có tính bảo thủ nên có thể khuếch đại sai lầm nhất thời của con người. Có nhiều cách để giải quyết việc này, và vì mỗi người có cách suy nghĩ khác nhau nên cả cách không đọc mã lẫn cách trực tiếp đọc và viết đều khả thi, nhưng lợi ích từ độ chính xác của mã không đi qua LLM cũng rất lớn

  • Lý do tôi phải tự viết mã là vì nếu không, LLM sẽ tạo ra quá nhiều mã. Cần phải hiểu trọn vẹn vấn đề và khái quát hóa nó thì mới ngăn được cảnh “Hello World” bị gắn thêm 10.000 dòng và 5 lớp trừu tượng hóa
    Vì LLM là bộ dự đoán token nên càng có nhiều vấn đề cần giải thì nó càng có xu hướng xuất ra nhiều token mã hơn

    • LLM dễ phình to vì nó thích bọc mã theo kiểu phòng thủ hơn là suy nghĩ tổng thể một cách toàn diện. Trong khi đó, lập trình viên con người có thể tuân theo quy tắc Boy Scout bằng cách dọn dẹp cả phần mã xung quanh khi làm việc
    • Từ nhiều thập kỷ trước, Peter Naur đã giải thích rằng lập trình không phải là việc cơ học sản xuất mã nguồn, đặc tả và tài liệu, mà là hoạt động của con người nhằm xây dựng một lý thuyết tinh thần sâu sắc về cách từng phần của hệ thống gắn với vấn đề thực tế. Sản phẩm đầu ra thật sự của lập trình là mô hình tinh thần mà các lập trình viên cùng chia sẻ
      Người sở hữu vấn đề cần giải quyết là con người, nên nếu không hiểu vấn đề thì LLM có thể rơi vào bài toán X/Y, tức là giải một vấn đề chẳng liên quan đến nhu cầu thực tế. LLM giỏi trừu tượng hóa những yếu tố không cốt lõi như thư viện hay ngôn ngữ bậc cao, nhưng phần cốt lõi của vấn đề vẫn phải được biểu đạt một cách hình thức
      Vibe coding, nơi người ta thêm từng ràng buộc một để đi đến kết quả mong muốn, rốt cuộc cũng chỉ là một dạng lập trình lỏng lẻo và phi hình thức. Tốt hơn là giao phần ngoại vi của vấn đề cho LLM, còn phần cốt lõi thì tự viết và tự hiểu
    • Dù 99% công việc là C#, nhờ LLM mà giờ tôi có thể tự xưng là lập trình viên cấp thấp như điều tôi luôn mong muốn, dù không phải làm gì cả
    • Tôi đã nhờ nó cấu hình một dự án sẽ chạy trên K8s sao cho giống các module khác trong công ty, và LLM thậm chí còn viết cả unit test cho bản triển khai Hello World
    • Tôi giao cho một model Mỹ mới nhất một việc vặt là hiển thị thông tin phía client, thế mà nó sửa cả mã hai phía để server truyền thông tin sang client ngay từ bắt tay ban đầu, và thực sự còn chạy được nữa. Nhưng thông tin đó vốn đã có sẵn ở client, nên đây thực chất chỉ là công việc thay đổi một dòng mã phía client
      Bề ngoài thì nó giải quyết yêu cầu hoàn hảo, nhưng đó là đoạn mã thừa thãi và cẩu thả. Các công ty bán token theo mức sử dụng có động cơ kinh tế để tạo ra kiểu lời giải Rube Goldberg vừa giải quyết vấn đề qua loa vừa tiêu tốn tối đa token; và token không chỉ bị tốn khi sinh mã mà còn bị tốn thêm khi sau này phải xử lý một đống mã khổng lồ lẫn bug mới
      Thật buồn cười khi những người từng chế giễu mã copy-paste giờ lại hứng khởi với thứ mã được chắp vá cẩu thả

  • Nhìn vào sự phát triển từ ChatGPT 3.5 tháng 11/2022 đến hiện tại, tôi tự hỏi liệu 4 năm nữa mình còn đang review code hay không. Ngay cả khi không phải người theo chủ nghĩa cực đoan về AI, nếu tốc độ hiện tại được giữ nguyên thì khả năng cao trong 5–10 năm nữa, software engineering và phát triển phần mềm theo hình thức ngày nay sẽ biến mất
    Có thể con người chỉ còn lại phần như thiết kế UI, còn mọi thứ khác đều được trừu tượng hóa và AI sẽ xử lý công việc thực tế

    • Nếu đó là cỗ máy thực hiện điều ước trong một lần, thì một yêu cầu đơn lẻ sẽ dễ xử lý; nhưng phần mềm là sự tích lũy của hàng nghìn điều ước, và ở mọi ngóc ngách đều phải đưa ra những quyết định tinh vi kiểu muốn cái này nhưng không muốn cái kia. Với cách làm LLM hiện tại, con người vẫn phải quản lý toàn bộ những quyết định đó, nhưng trong tương lai có thể sẽ xuất hiện một phương thức mà bây giờ ta còn chưa tưởng tượng ra
    • Mọi người giả định rằng tiến bộ sẽ tiếp tục với cùng tốc độ, nhưng nhìn qua thì dường như đã bước vào một giai đoạn chững lại ở mức nào đó. Chi phí tăng theo cấp số nhân mỗi khi model lớn hơn, và theo tôi thì cũng đã lộ ra khá rõ rằng việc cứ tiếp tục huấn luyện model ngày càng lớn không phải là một mô hình kinh doanh có lãi
    • Tôi đã thấy ghét cái tương lai mà ta thậm chí không thể trực tiếp trách những con người kém cỏi đã làm ra các website cần JavaScript cho mọi hành vi và còn không gõ nổi tử tế vào ô nhập liệu. Nếu LLM tạo ra cùng thứ rác rưởi đó ở quy mô còn lớn hơn nhiều do đội ngũ quản lý coi trọng vẻ ngoài hơn chức năng, cộng với dữ liệu huấn luyện mà phần lớn là những website kiểu ấy, thì có lẽ đó sẽ là một khủng hoảng hiện sinh
      Web vốn đã đủ hỗn loạn rồi, ít nhất hãy cho tôi vẫn được trách con người kém cỏi như hiện nay

  • Bất kể áp lực KPI thế nào, tôi vẫn tự viết mã mỗi khi có cơ hội, và chỉ kỳ vọng AI như một dạng tự động hoàn thành mã thông minh hơn

  • Tôi tự viết mã vì yêu thích coding và vì điều đó thực sự làm tôi hạnh phúc. Không có lý do gì để từ bỏ việc mình yêu thích

    • Có một sức hút gần như ma thuật trong việc ra lệnh cho máy tính làm việc và nhìn nó xử lý nhanh hơn hàng tỷ lần so với bất kỳ phương tiện nào khác
    • Tôi đến với lĩnh vực này vì thấy việc thiết kế chương trình và viết mã rất vui. Tôi đã tụt lại trong việc tận dụng AI và còn phải học thêm nhiều, nhưng tôi tuyệt đối không muốn từ bỏ việc tự tay coding
    • Nếu bạn hạnh phúc vì còn được trả tiền để coding, công ty có thể ngừng phần thưởng đó. Nếu bạn phụ thuộc vào thu nhập ấy để giữ visa, thì rất có thể bạn sẽ buộc phải thích nghi với thay đổi và từ bỏ coding