AI đòi hỏi kỷ luật kỹ thuật nhiều hơn, không phải ít hơn
(charitydotwtf.substack.com)- Việc chất lượng sinh mã bằng AI đã tăng lên không phải là tín hiệu để bỏ code review, mà là đòi hỏi kỷ luật xác minh và vận hành mạnh hơn trong một môi trường nơi mã có thể được tái tạo nhanh và rẻ
- Sau Opus 4.5 vào cuối năm 2025, AI đã có thể tạo ra mã có chất lượng gần với một kỹ sư phần mềm trình độ trung cấp ở các mẫu phổ biến, nhanh hơn và rẻ hơn nhiều; agentic harness, sử dụng công cụ, function calling và MCP là nền tảng cho bước chuyển này
- Khi chi phí sản xuất mã gần như tiến về 0, các dòng mã không còn là tài sản quý giá cần được gìn giữ mà gần hơn với một bộ đệm có thể tái tạo hiện thực hóa sự hiểu biết hiện tại
- Giống như immutable infrastructure khiến người ta thay thế thay vì sửa các máy chủ đang chạy, mã ứng dụng trong thời đại AI cũng khiến xác minh hành vi, characterization test, capture/replay, chia tách lưu lượng và khả năng quan sát trở nên quan trọng hơn bản thân việc thay đổi
- Các hệ thống phi định tính đòi hỏi kỷ luật kỹ thuật như trace, production eval và vòng phản hồi nhanh, thay vì cách con người cố thủ như một quality gate; AI không xóa bỏ thực tế rằng phần mềm vẫn cần kỹ thuật viên và kỷ luật
Tính kinh tế của việc sản xuất mã đã đảo chiều trong năm 2025
- Trong phần lớn năm 2025, quan điểm cho rằng mã do AI tạo ra là “slop” và có thể sẽ tiếp tục như vậy là một đánh giá hợp lý và chủ lưu
- Sau Opus 4.5 vào tháng 11 năm 2025, AI ít nhất ở các mẫu phổ biến đã có thể tạo ra mã với chất lượng tương đương một kỹ sư phần mềm trình độ trung cấp, nhanh hơn và rẻ hơn rất nhiều
- Opus 4.5 gần với một điểm bùng phát hơn là một nguyên nhân đơn lẻ
- agentic harness là cấu trúc mã đặt LLM vào trong một vòng lặp cùng với công cụ
- Các harness kiểu này đã trở nên thực tế vào giữa năm 2025, với dấu hiệu báo trước có thể truy về cuối năm 2024
- tool use, function calling và MCP đã tích lũy trong suốt năm 2025 rồi dẫn tới khả năng dùng phổ quát vào cuối năm
- Ở lần thay đổi đầu tiên, thái độ hoài nghi kiểu “thấy rồi mới tin” còn có thể chấp nhận được, nhưng khi một đợt thay đổi khác với cùng tốc độ lại xuất hiện thì rất khó giữ nguyên thái độ đó
Mã chuyển từ tài sản quý giá thành đầu ra có thể tái tạo
- Thay đổi cốt lõi diễn ra trong năm 2025 là tính kinh tế của việc sản xuất mã đã bị đảo ngược
- Từ trạng thái tạo mã là việc khó, chậm và tốn kém, sang trạng thái gần như tức thời và rẻ
- Các dòng mã chuyển từ thứ cần tái sử dụng và chăm chút sang thứ có thể bỏ đi và tạo lại
- Cũng có một góc nhìn cho rằng đầu ra thực sự của các nhóm kỹ thuật phần mềm là sự hiểu biết được chia sẻ
- Sự hiểu biết đó được lưu như cache trong đầu con người, rồi được ghi xuống đĩa dưới dạng commit GitHub và triển khai production
- Nhưng trí nhớ con người rất dễ quên, dễ chai lì trước sự lặp lại và dễ bỏ sót các chi tiết nhỏ
- Mô hình trong đầu liên tục lệch khỏi thế giới mà người dùng thực sự gặp phải
- Từ góc nhìn SRE, đầu ra thực sự của một đội phần mềm tốt nằm ở production
- “Only prod is prod”
- Production không nên được xem là nơi đến sau phát triển, mà là một giai đoạn của phát triển
Sự tương đồng giữa Phoenix Architecture và immutable infrastructure
- Honeycomb đã đưa ra AI mandate vào tháng 8 năm 2025 và cho rằng với tư cách là một công ty devtools, họ phải xử lý những vấn đề khó của công nghệ mới nhất
- Phoenix Architectures của Chad Fowler kết nối thời đại mã AI với immutable infrastructure
- Chad Fowler là người đã đặt ra cụm từ “immutable infrastructure” vào năm 2013
- Relocating Rigor là bài viết được Martin Fowler nhắc đến trong phần tóm tắt meetup của Thoughtworks
- Cốt lõi của The Death and Rebirth of Programming là nguyên tắc đừng sửa thứ đang chạy, hãy thay thế nó
- immutable infrastructure, stateless services, containers, blue-green deployments, infrastructure as code đều chia sẻ cùng một tiền đề
- AI mở rộng tiền đề này từ hạ tầng sang mã ứng dụng
- Khi chi phí viết lại giảm xuống, việc sửa tại chỗ trở nên rủi ro, mutation tích lũy entropy, còn replacement đặt lại nó
- The Deletion Test yêu cầu tưởng tượng việc xóa toàn bộ phần triển khai
- Lý do việc xóa đáng sợ không phải vì bản thân mã, mà vì người ta không biết hành vi nào là cần thiết, lỗi nào là không thể chấp nhận, bất biến nào luôn phải được giữ, và tiêu chuẩn nào để đánh giá tính đúng đắn của phiên bản mới
- Việc không biết một bug đã sửa trong một edge case bị quên là gì cũng là cùng một vấn đề
- Đây không phải là vấn đề về mã mà là vấn đề đánh giá
- Khi mã là nơi duy nhất tri thức sống trong đó, mã trở nên quý giá
- Trước đây, vì lao động tạo mã là nút thắt cổ chai nên việc đối xử với mã như một tài sản bền vững là hợp lý
- Khi việc tái tạo trở nên dễ dàng, mã hoạt động như một cái nhìn vật chất hóa của sự hiểu biết: hữu ích ở hiện tại nhưng có thể bỏ đi khi đã lỗi thời
Mã phải có thể được tái tạo như cách tái tạo máy chủ
- Trải nghiệm chuyển từ các server pet được chế tác thủ công sang immutable infrastructure cattle để lại bài học rằng tính biến đổi là kẻ thù của sự hiểu biết
- Khi sửa đầu ra đang chạy ngay tại chỗ, drift sẽ xuất hiện
- Drift khiến việc bảo trì hệ thống trở nên khó khăn
- Honeycomb dùng cron mỗi thứ Ba để giết node Kafka lâu đời nhất
- Cách này giúp họ có thể tin tưởng rằng quy trình bootstrapping và balancing có thể lặp lại
- Dữ liệu là thứ có thể tái tạo, còn những cam kết quan trọng nằm ở nơi khác
- Nếu không thể tái tạo mã theo cùng cách đó thì đây là dấu hiệu cho thấy người ta chưa hiểu đủ về mã ấy
- Không biết đã đưa ra cam kết gì
- Không biết phụ thuộc nào sẽ bị phá vỡ
- Phần lớn chỉ được phát hiện bằng cách thử phá nó
- Những migration, rewrite, thay thế legacy code và strangler fig kéo dài, đau đớn là các trường hợp mà các dòng mã đã gánh quá nhiều trách nhiệm
- Trong mã bị buộc chặt cả ý đồ của lập trình viên, kỳ vọng của người dùng, hành vi ngầm và tường minh, cùng dấu vết của các bug trong quá khứ
Đối tượng cần review không chỉ là các dòng mã
- Vì chi phí duy trì và thay đổi các dòng mã quá lớn nên những đầu ra khác đã không phát triển đủ
- Thiếu các đầu ra để hiểu và thảo luận về việc kiến trúc đang thay đổi ra sao
- Bản thân kiến trúc cũng thường chỉ được suy ra lờ mờ từ mã
- Hướng đi lý tưởng gần với việc thảo luận và thống nhất trên sơ đồ kiến trúc rồi tái tạo mã từ thay đổi đó
- Không thể khẳng định rằng mọi mã sẽ được AI tạo theo đặc tả mà bỏ qua sự hiểu của con người
- Toàn bộ khả năng phụ thuộc vào spec là gì, hoặc có thể trở thành gì
- Bất kỳ ai từng trải qua một database migration đau đớn đều phải biết rằng việc trích xuất và hình thức hóa kỳ vọng của người dùng thành dạng có thể tái hiện và tự động hóa là rất khó
- Công cụ vẫn chưa có, nhưng các ý tưởng liên quan thì đã tồn tại
- behavioral test, characterization test, capture/replay và traffic splitter từ vận hành và QA là các ví dụ
- Các kỹ thuật này gần với việc quan sát và mã hóa điều gì thực sự đang xảy ra hơn là điều gì lẽ ra phải đúng
- observability theo nghĩa tốt cũng nằm trong đó
Con người không phù hợp làm quality gate cho việc xác minh
- Mã phi định tính trong production buộc người ta phải làm những việc vốn dĩ đã nên làm từ trước
- trace instrumentation
- test và eval trong production
- cách đối xử với production như một giai đoạn phát triển thay vì thứ đến sau phát triển
- Não người không phù hợp cho xác minh
- Kém hơn máy móc trong việc liên tục kiểm tra các khác biệt lặp đi lặp lại và nhỏ nhặt
- Nếu vai trò của con người chỉ được đặt ở năng lực làm quality gate, chất lượng phần mềm sẽ trở nên mong manh
- Con người có thể còn giữ vai trò lâu dài ở sáng tạo, cảm hứng, các bước nhảy logic, nhưng khó có thể đặt họ làm chủ thể đánh bại máy móc trong validation
Kết luận của thời đại AI là sự trở lại của kỷ luật
- Lý do diễn ngôn AI trong hai năm qua khiến nhiều kỹ sư thấy lạ lẫm và lo sợ là vì một số tiếng nói về AI dường như đang nói rằng phần mềm không còn là một vấn đề kỹ thuật nữa
- “SaaS is dead”
- “Making AI great at coding was the strategy that unlocks everything else”
- Adam Jacob được nhắc đến như một người dự báo thay đổi lớn về việc làm trong ngành phần mềm
- Nếu năm 2025 là năm của vibe coding, thì năm 2026 trông giống như sự trở lại của kỷ luật
- Khi AI có thể tạo ra các dòng mã ngang một kỹ sư phần mềm trình độ trung cấp, biên độ của những tương lai khả dĩ đã mở rộng theo cách bất ổn
- Tri thức nằm trong đầu sẽ không thể được AI sử dụng cho đến khi nó được mã hóa vào hệ thống
- Có rất ít đội phần mềm làm việc với vòng phản hồi nhanh và ngắn
- Tỷ lệ được nêu vào khoảng 5%, chắc chắn dưới 10%
- Công cụ AI có thể đưa cách làm này đến gần hơn trước đây
- Kịch bản chỉ với AI mà không có kỷ luật kỹ thuật vẫn tạo ra lợi nhuận đầu tư khổng lồ không phải là điều đáng lo trong tương lai gần
- Nhiều đội sẽ thử, nhưng thứ có giá trị được chống lưng bởi durability chứ không phải disposability
- Người dùng không muốn mỗi ngày đăng nhập Slack lại thấy nút và menu thay đổi tinh vi
- Họ cũng không muốn giao dịch tài chính chỉ hoàn tất trong phần lớn trường hợp
- determinism không biến mất
- AI không phải phép màu, và phần mềm vẫn là kỹ thuật
- Công nghệ vẫn cần technologist
- Những đầu ra cần được xem xét trong tương lai sẽ mở rộng từ không chỉ các dòng mã sang các loại đầu ra kỹ thuật khác nữa
1 bình luận
Ý kiến Hacker News
Giờ đây khó phân biệt hơn rất nhiều giữa người thực sự hiểu hệ thống và dùng AI hiệu quả, với người chẳng hiểu gì mà chỉ rải LLM copy-paste khắp nơi
Trước năm 2025, những người làm kém hoặc chỉ cố bám trụ thường lộ ra tương đối rõ vì đóng góp ít, nhưng giờ thì mọi kỹ sư đều có thể tuôn ra các PR, review code, tài liệu thiết kế kỹ thuật trông rất thuyết phục
Một phần lớn là do tầng C-level gây áp lực mạnh phải tận dụng AI tối đa, và từ góc nhìn của từng kỹ sư thì việc tạo ra càng nhiều càng tốt cũng là một phản ứng theo lý thuyết trò chơi có lợi
Chúng ta đang chìm ngập hoàn toàn trong những tài liệu và đoạn code trông có vẻ hợp lý, rồi lại tiếp tục phụ thuộc vào AI để xử lý chính cái khối lượng đó
Cú phản lực của giai đoạn này có lẽ sẽ trở thành một dạng nợ kỹ thuật kỳ lạ, đặc biệt nổi bật ở quy mô của nó
LLM thích tạo ra nhiều thứ và thích thêm thắt, nhưng kỹ sư thực sự giỏi lại tạo ra nhiều kết quả kinh doanh hơn với ít code hơn và ít bộ phận vận hành hơn
Tôi thường nghe kiểu: “Tôi muốn dùng AI để tự động hóa quy trình, nhưng tài liệu quy trình chưa đầy đủ nên hy vọng AI sẽ giúp”
Dù có giải thích rằng không thể tạo ra kết quả từ hư không, mọi cuộc thảo luận về AI rồi cũng quay lại đúng hướng đó
Ngay cả giải pháp để tạo ra tài liệu đưa vào tự động hóa AI cũng lại là dùng AI, thành ra giống một ouroboros nơi AI viết tài liệu, AI tóm tắt nó rồi AI lại giải thích nó
Code cũng sẽ y như vậy: AI tạo ra hàng nghìn dòng, rồi lại dùng AI để giải thích
Dạo này nhờ có LLM mà chỉ nhìn vào lượng đóng góp thì quá dễ để trông như người chăm chỉ
Khác biệt bây giờ là một người kém năng lực có thể tạo ra sản lượng nhiều hơn theo đúng nghĩa đen vài bậc độ lớn so với một kỹ sư cẩn trọng và giàu kinh nghiệm
PR không phải cánh cổng hoàn hảo, nhưng nó là một trong số rất ít cánh cổng mà chúng ta còn có lúc này, và ai có thực sự bỏ công hay không thì khá rõ ràng
Chẳng phải các câu hỏi thuật toán ở vòng phỏng vấn đã hoàn toàn lọc sạch những kẻ giả vờ có hiểu biết hệ thống rồi sao?
Tôi đồng tình với ý “đó không phải vấn đề về code mà là vấn đề đánh giá” và “code chỉ có giá trị khi tri thức chỉ tồn tại bên trong code”
Việc ngồi đọc code do AI viết cả ngày thật sự quá khổ sở, và là một cách làm tan chảy bộ não đúng vào lúc con người cần phải sắc bén nhất
Lập trình thủ công có một vòng phản hồi hiệu quả và thỏa mãn: đọc code, viết code, rồi sửa cho tới khi nó biên dịch được, chạy được hoặc làm đúng điều mình muốn
Code AI không chỉ làm thay một nửa quá trình đó mà còn khiến khoảnh khắc “click” cuối cùng bớt đáng giá hơn. Vì bạn không thể chắc mình có đang lách đâu đó một chút để tới được khoảnh khắc ấy hay không
Xem code do AI tạo ra là đầu ra bền vững duy nhất của lập trình là ngõ cụt của ngành
Điều Charity chỉ ra như không gian làm việc thú vị, và nên được loại bỏ đúng cách, là sơ đồ kiến trúc và đặc tả
Tôi nghi rằng nó còn gần với prompt, kế hoạch Markdown và lời dẫn do con người trực tiếp viết hơn
Chúng ta cần tập trung vào thứ con người trực tiếp tạo ra, vì đó mới là nền tảng cho vòng lặp cốt lõi “AI có làm theo chỉ thị của tôi không”, và cũng tạo đòn bẩy cao hơn trong review code
Đến lúc có PR thì đáng ra bạn đã đưa đủ ngữ cảnh cho Claude để có thể tạo lại code, nhưng mặc định hiện nay của ngành là vứt bỏ toàn bộ phiên đó và chỉ triển khai code. Như vậy là ngược đời
Những khối code lớn về thực tế là con người không thể review nổi, nhưng khi có LLM tham gia thì nhiều người dường như quên mất điều đó
Mỗi ngày một đống code khổng lồ lại được gửi tới để review, thật sự rất mệt
Dù vậy tôi vẫn thấy AI khá hơn, vì nếu viết sẵn quy tắc ra thì ít nhất nó có xu hướng làm theo
Nhiều lập trình viên offshore lặp lại cùng một lỗi mỗi ngày
Có lẽ công ty tôi cần tuyển các lập trình viên offshore tốt hơn
Trước đây, một phần mô hình tinh thần của tôi về hệ thống được hình thành qua việc trực tiếp code, còn giờ thì tôi ngày càng dựa vào review code để xây nó lên
Việc hiểu và ghi nhớ các chi tiết của hệ thống đang trở nên khó hơn, điều này cũng không có gì lạ nếu nghĩ rằng thông tin do tự mình “tạo ra” thường được nhớ tốt hơn thông tin chỉ đọc qua
Tôi đang áp dụng các bài học từ giáo dục học vào việc mở rộng review code, và nếu điều này khiến bạn thấy đồng cảm thì tôi muốn trò chuyện thêm
Một giải pháp tạm là bảo Claude viết phần tóm tắt phiên làm một phần của commit message, nhưng tôi muốn biết có công cụ nào có cấu trúc hơn và ở mức cao hơn không
Nếu bạn muốn code có thể kiểm chứng được và bám theo một kế hoạch thiết kế tốt, thì trên thực tế bạn phải viết gần như mã giả rồi để AI dịch lại
Nếu vậy thì ngay từ đầu cũng phải tự hỏi vì sao lại để AI viết code
Cá nhân tôi thấy tự lên kế hoạch, tự viết và tự debug vui hơn nhiều. Đó vốn là phần khiến tôi yêu thích lập trình ngay từ đầu
Gần đây tôi thực sự nghĩ rất nhiều về điều này
Phần lớn trực giác của tôi về phát triển phần mềm dựa trên kinh nghiệm tích lũy suốt 25 năm về “viết một đoạn mã nào đó mất bao lâu”
Khi cân nhắc có nên thêm phần kiểm chứng cho các edge case không làm hỏng toàn bộ hệ thống nhưng sẽ khiến mọi thứ hơi bừa bộn nếu ai đó vấp phải, tôi có thể sẽ bỏ qua nếu điều đó tốn thêm vài giờ viết mã
Nhưng nếu chỉ cần một prompt thì tại sao lại không làm?
Để giúp một tính năng mới dễ hiểu hơn, có một API explorer chuyên dụng sẽ rất tốt, nhưng trước đây có lẽ không đủ lý do để biện minh cho khoản đầu tư đó
Nhưng nếu với Codex chỉ mất 10 phút thì câu chuyện sẽ khác, và thực tế đúng là như vậy: https://tools.simonwillison.net/datasette-extras-explorer#ur... cũng được liên kết trong ghi chú phát hành https://docs.datasette.io/en/latest/changelog.html#extra-sup...
Ở quy mô lớn hơn, cũng có những dự án mà trước đây tôi hoàn toàn không cân nhắc. Dù cần một thư viện phân tích cú pháp truy vấn SQLite SELECT tùy chỉnh, nó vẫn không đáng để dành hơn một tuần cho việc đó
Nhưng giờ thì điều đó đã khả thi: https://github.com/simonw/sqlite-ast
Mỗi khi nói rằng việc tạo ra nhiều dòng mã nhanh hơn là có giá trị, người ta lại rất tức giận và coi thường điều đó
Tất nhiên, đo đầu ra bằng “số dòng mã” là ngu ngốc
Nhưng đo bằng số dòng mã đã được kiểm chứng và mang lại giá trị thì không ngu ngốc, và giờ chúng ta có thể làm điều đó nhanh hơn
Google có giá trị vì họ hút dữ liệu vào để tạo doanh thu quảng cáo, và chi tiêu của họ nhỏ so với doanh thu
Còn tất cả những “cược lớn” đó à? Buồn cười thật, rốt cuộc chúng đã ra sao?
Kỹ thuật chỉ vì kỹ thuật thì không có giá trị nào với nền kinh tế, tức là vô nghĩa
Sự thật lạnh lùng mà không ai muốn nghe là: trong nền kinh tế tại một thời điểm nhất định, chỉ những gì có giới hạn, có giá trị và bền vững về mặt kinh tế mới có thể tồn tại và sống sót
Có nhiều người không quan tâm, nhưng cũng có những người quan tâm
Tôi thích bài này, và có vẻ nhiều bình luận khác thì không, nên tôi viết ra suy nghĩ của mình
Khi bắt đầu với một codebase mới, làm sao để trở thành người đóng góp hữu ích nhanh nhất có thể? Tôi tìm ngay đến con người và tài liệu do con người viết
Tôi kiểm tra xem vấn đề mà hệ thống này ban đầu định giải quyết là gì, thiết kế ban đầu ra sao, vấn đề lớn nhất là gì, và hiện tại ai đang sử dụng nó
Biết được những điều này giúp đoán ra vì sao nó được tạo theo cách đó, nên việc đọc code trở nên dễ hơn rất nhiều
Bài blog này cũng đã được chú ý nhiều: https://blog.gpkb.org/posts/just-send-me-the-prompt/
Có vẻ Charity đang nhìn vào một vấn đề rất cũ và kỳ vọng rằng công nghệ mới sẽ dẫn tới một lời giải mới nào đó
Tôi không nghĩ thế hệ công cụ hiện tại là hồi kết của câu chuyện phát triển phần mềm bằng AI
Ý tôi cũng không phải là cứ ném tài liệu thiết kế vào Claude code rồi bỏ đi. Tài liệu thiết kế cũng không hoàn chỉnh, nên khi onboard bạn vẫn phải nói chuyện với người khác, đọc các ticket cũ và cả postmortem
Trong production, chúng ta làm hạ tầng dưới dạng mã vì ghét việc khó hiểu tại sao hạ tầng lại thành ra trạng thái hiện tại
Codebase cũng vậy, trạng thái mặc định là “khó hiểu vì sao nó lại trở thành như hiện nay”, và đây là vấn đề đã được quan sát từ trước cả “Programming as Theory Building”
Vì thế, tương tự như hạ tầng, tôi kỳ vọng phát triển phần mềm cũng sẽ chuyển sang các công cụ giúp làm rõ hơn “vì sao code lại thành ra trạng thái hiện tại”
Cách tiếp cận xem con người và tài liệu do con người viết trước khi vào một codebase mới là đúng, nhưng nhiều đội kỹ thuật hoàn toàn không có loại tài liệu đó
Quyết định được đưa ra trong đầu một kỹ sư nào đó hoặc trong các cuộc chat không được lưu lại, còn đặc tả thì chỉ là vài dòng ghi chú trong những ticket đã bị xóa khi đang dọn dẹp, hoặc biến mất khi đổi công cụ theo dõi
Không có bản đồ của codebase hay tính năng, không có ADR, khả năng quan sát cũng ở mức tối thiểu
Thứ còn lại chỉ là code, nên bạn phải đọc code để tìm ra chuyện gì đang diễn ra, rồi hỏi kỹ sư nào gần đây commit vào khu vực đó xem họ còn nhớ vì sao đã làm vậy không
Có khi ai đó sửa một chỗ thì phần ở đầu kia của codebase, vốn tưởng chẳng liên quan gì, lại vỡ tung
Đúng là AI đòi hỏi nhiều kỷ luật hơn, nhưng về mặt lý thuyết, loại kỷ luật đó dễ học hơn rất nhiều so với việc trở thành một kỹ sư giỏi
Cách đây 20 năm, để viết được mã C tốt và có khả năng mở rộng, bạn phải là thiên tài, hoặc phải thật sự tận hiến cho công nghệ đó
Bạn phải nắm rõ hàng loạt công cụ như ASan, LSan, UBSan, TSan, GDB, và nếu còn phải tự đọc file DWARF thì còn khủng khiếp hơn nữa
Việc làm chủ chúng trong thời gian ngắn là điều thực tế rất khó, trong khi bạn còn phải học cả thiết kế hệ thống, vốn gần như là một kỹ năng riêng biệt và trực giao
Giờ đây, bạn chỉ cần biết các điểm rủi ro của ngôn ngữ và framework mình dùng, bảo LLM kiểm thử chúng, có hạ tầng để xác nhận rằng nó đã kiểm thử đủ, rồi đọc phần kiểm thử và phần triển khai thực tế
Đọc và hiểu Rust dễ hơn rất nhiều so với gỡ lỗi các lỗi kỳ quái phát sinh trong quá trình phát triển bằng Rust
Việc nhận ra một kịch bản nào đó cần kiểm thử Loom, rồi tạo công cụ để phát hiện xem nó đã thực sự được viết hay chưa, cũng dễ hơn
Ngay cả khi vẫn tiếp tục dùng C hay Zig, việc biết khi nào nên dùng từng công cụ và phát hiện điều đó vẫn dễ hơn rất nhiều so với tự mình thành thạo từng công cụ một
Đọc SQL không khó, gần một nửa số người làm kinh doanh cũng làm được. Python chỉ khó hơn một chút, còn Rust thì cũng có thể hiểu được nếu đọc một hướng dẫn 50 trang, một cái giá rất nhỏ so với việc mất 10 năm mò mẫm bằng thử-sai
Con đường từ “LLM hoạt động theo những cách không thể biết được” sang “vì thế cần nhiều kỷ luật hơn”, rồi tới “mọi thứ đều ổn” là không rõ ràng
Tôi đồng ý rằng mọi thứ đều ổn, nhưng không cho rằng chuỗi suy nghĩ đó là một lộ trình rõ ràng
Trên thực tế, nếu ai đó có ý chí làm cho nó hoạt động và chịu dành chút thời gian để hiểu điều gì khiến nó thất bại, thì họ có thể dùng LLM để làm nên những việc rất lớn
Vì LLM khiến chi phí tạo ra những thứ phức tạp gần như bằng không, nó ngược lại sẽ làm tình hình trở nên phức tạp hơn rất nhiều
Kỹ thuật từ trước đến nay luôn là chuyện của kỷ luật và làm cho mọi thứ hoạt động, nhưng trước đây muốn trở nên có giá trị thì bạn cần một tập hợp kỹ năng nền tảng có trước
Phần lớn trong số đó giờ đã biến mất, và mọi thứ dễ hơn nhiều so với trước
Kỷ luật vẫn cần thiết, nhưng so với việc lăn lộn 10 năm trong lửa, thì tôi cho rằng kỷ luật là rẻ
Tôi vừa mất một tuần để review PR khoảng 200 dòng này: https://github.com/ncruces/wasm2go/pull/37
Nó do một người dùng có kinh nghiệm gửi lên và rất có thể họ đã hỏi một LLM hàng đầu
Dù vậy, tôi vẫn có cảm giác có gì đó không ổn. Tôi không hiểu nó, và cũng không định merge khi chưa hiểu
Tôi cũng nghi nó sai theo cách sẽ gây ra vấn đề trong tương lai
Vì vậy tôi đã review theo bốn hướng: hiểu rồi cải thiện nó, làm lại bằng một thuật toán tốt hơn, sửa vấn đề ở upstream để né nó, hoặc viết lại từ đầu theo cách phù hợp với đầu óc của tôi
Tôi đã nghĩ câu trả lời sẽ là cách thứ hai hoặc thứ ba, nhưng cách thứ hai dù đúng thì cũng đòi hỏi phải làm lại dự án từ đầu, còn cách thứ ba thì tôi thực sự hy vọng sẽ được nhưng đã không thành
Cuối cùng tôi phải trộn cách thứ nhất và thứ tư, và dù vẫn chưa hoàn toàn chắc chắn, giờ tôi đã hiểu vấn đề và lời giải
Dĩ nhiên tôi nghĩ cách tiếp cận của mình tốt hơn
Tuy vậy, tôi vẫn cho LLM review cả hai bên sau khi bỏ hết chú thích
LLM trả lời rằng PR gốc rõ ràng tốt hơn, nhưng khi tôi giải thích vì sao không phải vậy thì nó lại nói tôi đúng
Nếu thêm chú thích vào rồi thử lại thì các LLM sẽ nói bản của tôi tốt hơn. Vì tôi đã tìm ra đúng vấn đề thực sự
Nhưng tôi không biết liệu nó nói bản của tôi tốt hơn là vì tôi đã dẫn dắt nó để nó nói vậy hay không
Đọc bài này xong tôi có cảm giác như tác giả đã quên mất câu châm ngôn “mọi mô hình đều sai”
Đây cũng là lỗi mà những người thích RPG “mô phỏng” “thực tế” thường hay mắc phải
Nếu bạn mô hình hóa một đối tượng đủ toàn diện, thì mô hình đó rốt cuộc sẽ chính là bản thân đối tượng
Muốn tạo một mô hình địa điểm bao gồm mọi chi tiết của nơi thật, bạn sẽ cần một mô hình tỷ lệ 1:1, mà như thế thì cuối cùng chỉ là một bản sao của chính nơi đó
Một bản kế hoạch đủ đầy để tái hiện đáng tin cậy 100% chức năng của hệ thống — tức prompt cho mô hình — có lẽ chính là mã nguồn của hệ thống đó
Tôi thường tự hỏi liệu phần lớn IT và lập trình có thực ra chỉ là việc ghép các mảnh đã được hiểu rõ lại với nhau hay không
8 năm trước tôi từng nghĩ về chuyện tại sao không thay LLVM bằng một hệ thống đơn giản hơn nhiều, và thay tối ưu hóa thủ công bằng một “bộ tối ưu hóa” AI đơn giản
Tôi cho rằng chỉ cần huấn luyện nó biến mã biên dịch đơn giản thành mã “đã tối ưu hóa”, nhưng đồng thuận khi đó là hệ thống AI rất khó tạo ra mã đúng với độ tin cậy đủ để dùng được
Nếu AI còn không thể thay thế cả mã mức thấp như vậy, thì các vấn đề mức cao hiển nhiên phải còn xa hơn nhiều
Thế nhưng người ta lại dùng AI cho các vấn đề mức cao
Giả thuyết của tôi là phần lớn kỹ nghệ số hiện đại mang tính plug-and-play
Tôi nhớ trước năm 2023, trên HN ai cũng tôn việc giảm số dòng mã là dấu hiệu senior mạnh nhất
Chỉ là dòng lũ số dòng mã do LLM tạo ra quá mạnh, không thể thắng cuộc bơi ngược dòng được
Và tôi cũng không đồng ý với giả định của bài viết rằng LLM có thể viết mã tốt
Nó viết được mã chạy được, nhưng trông như thể do Demogorgon viết, nhìn vào thấy hơi buồn nôn
Nó dở, nhưng dở theo cách mà con người sẽ không bao giờ viết ra
Đó là một kiểu khó chịu khác với khi đọc đống spaghetti code của junior, kiểu ghê tởm như thể đâu đó trong bụng bạn có trứng của Cthulhu đang nở ra
Tôi nhớ ở công ty cũ có một senior mà từ lúc vào cho đến khi lên làm manager, việc anh ấy làm chỉ là xóa code
Bài này đọc không thấy vui
Từng câu riêng lẻ hay từng đoạn riêng lẻ thì ổn, nhưng xét như một tổng thể thì rời rạc, và xin nói thẳng là vô nghĩa
Từ ngữ thì rất nhiều nhưng thứ thực sự được nói ra lại quá ít
Ví dụ, cách nói rằng kinh tế học của việc sản xuất code đã bị đảo ngược vào năm 2025 là không chính xác
Trước đây nếu quy trình chế tạo giống kiểu cộng dồn nghiêm ngặt như in 3D, thì bây giờ đúng hơn là nó được bổ sung thêm kiểu cắt gọt như CNC milling
“Hình dạng” cần thiết không thay đổi bao nhiêu, và nếu bạn quan tâm đến dung sai cụ thể thì công sức của con người cũng không thay đổi
Ta vẫn phải trân trọng sản phẩm, tái sử dụng, chăm sóc và tuyển chọn nó ở mức mà thị trường đòi hỏi
Tôi cũng không đồng ý với câu “số dòng mã không phải là đầu ra lý tưởng để review”
“Lý tưởng” ở đây nghĩa là gì?
Hồi nhỏ, trong mọi bài kiểm tra luôn có quy tắc “hãy trình bày cách giải”
Lý do là vì mục tiêu không chỉ là sản phẩm phát hành ngày mai, mà còn là cải thiện mental model và quy trình tư duy của thế hệ tiếp theo
Ngôn ngữ thực sự rất khó theo dõi, và điểm cốt lõi của bài cũng không nổi bật
Những bài như thế này lại càng khiến tôi nghi ngờ tuyên bố rằng việc làm kỹ sư phần mềm sẽ biến mất
Công việc kỹ sư phần mềm năm 2026 đã khác năm 2020, chưa nói gì đến năm 1990, vậy tại sao lại phải tin vào cái nhị nguyên giả tạo rằng công việc năm 2026 либо sẽ giữ nguyên, либо sẽ biến mất hoàn toàn?
Hồi rất lâu trước đây khi làm ở Google, ý tưởng rằng mọi đoạn code đều được review đối với tôi là điều mới mẻ
Trước đó ở MS, code kiểu được ghi ra CD rồi cho vào hộp, nên phần lớn chẳng được review cho đến tận giai đoạn rủi ro cao ở cuối dự án
Trong giai đoạn 2000 đến 2004, cách kỹ sư phần mềm dùng thời gian đã thay đổi mạnh, và theo tôi là tốt lên vì nó tăng hiểu biết chung và thúc đẩy cộng tác
Nếu AI viết code còn con người dành nhiều thời gian hơn cho review, thì điều đó chưa chắc đã xấu
Nhưng nếu mã do AI tạo ra trở nên đủ tốt, người ta sẽ bắt đầu xem việc review kỹ lưỡng là tùy chọn
Khi đó công việc của kỹ sư phần mềm sẽ rất khác trước, không còn vừa viết nhiều code vừa dành nhiều thời gian cho review nữa
IDE thậm chí có thể biến mất như chim dodo
Trọng tâm có thể chuyển sang đặt mục tiêu và thiết lập test để đội ngũ AI coding không chệch khỏi nhiệm vụ
Những kỹ sư phần mềm hiểu rất rõ dự án đang đi về đâu có thể dành nhiều thời gian hơn cho kiến trúc. Vì khi đích đến thay đổi một cách hợp lý, bạn sẽ không muốn AI cứ viết lại cái này cái kia
Cũng có thể dành nhiều thời gian hơn cho khám phá. Làm theo một cách, rồi một cách khác, rồi một cách nữa, sau đó so sánh và tạo ra ý tưởng mới từ các hướng tiếp cận khác nhau
Tôi không có dự đoán nào tốt hơn ai, nhưng tôi phản đối mạnh quan điểm rằng vai trò này sẽ biến mất, và ủng hộ quan điểm rằng nó sẽ tiến hóa như đã từng nhiều lần trước đây. Chỉ có điều lần này có thể nhanh hơn hẳn
Tôi không nghĩ câu “chúng ta coi code là thứ lâu bền vì lao động tạo ra code là nút thắt cổ chai” là đúng
Chúng ta coi code là thứ lâu bền vì xem code là nguồn chân lý
Máy tính không thực thi tài liệu mà thực thi code
Nếu tài liệu yêu cầu mâu thuẫn với code, mặc định trước đây là tài liệu yêu cầu sai
Không thể tách code khỏi đặc tả. Vì code chính là đặc tả