- Tác nhân lập trình LLM vẫn không thể thực hiện một cách tự nhiên các tác vụ di chuyển mã như sao chép-dán
- Khi refactor mã, do cách viết mã dựa vào trí nhớ, rất khó đảm bảo tính nhất quán
- Trong quá trình giải quyết vấn đề, chúng hầu như không đặt câu hỏi mà nhất quán với các lần thử mang tính phỏng đoán
- Lập trình viên con người khi gặp mơ hồ sẽ làm rõ vấn đề bằng cách đặt câu hỏi, nhưng LLM lặp lại việc thử cho đến khi đâm vào tường
- Vì những đặc tính này, tác nhân LLM được nhìn nhận không phải là thay thế lập trình viên con người, mà ở mức thực tập sinh chỉ thừa tự tin
Những giới hạn chính của tác nhân lập trình LLM
Gần đây có nhiều nỗ lực tận dụng LLM như công cụ hỗ trợ lập trình, nhưng vẫn còn những điểm mà lập trình viên con người cảm thấy gượng gạo. Bài viết này giải thích rõ hai lý do đặc biệt gây khó chịu ở các tác nhân lập trình LLM
1. Sự gượng gạo trong cách di chuyển mã và refactor
- LLM không thực hiện thao tác 'sao chép-dán' thực sự
- Ví dụ, khi được yêu cầu refactor một tệp lớn thành các tệp nhỏ hơn, LLM sẽ 'ghi nhớ' một phần khối mã, dùng lệnh
deleteở tệp gốc đồng thời viết phần mã đã 'ghi nhớ' vào tệp mới bằng lệnhwrite - Không dùng công cụ 'cut' hay 'paste', mọi chỉnh sửa đều được khôi phục từ bộ nhớ
- Khi di chuyển mã, lập trình viên con người có được sự chắc chắn về tính khớp của mã nhờ thao tác 'sao chép-dán', còn LLM thì không đảm bảo được điều đó
- Cho đến nay chỉ có Codex đôi lúc cho thấy nỗ lực bắt chước thao tác 'sao chép-dán' của con người bằng các lệnh
sedhoặcawk, nhưng vẫn chưa hoàn hảo
- Ví dụ, khi được yêu cầu refactor một tệp lớn thành các tệp nhỏ hơn, LLM sẽ 'ghi nhớ' một phần khối mã, dùng lệnh
2. Cách tiếp cận giải quyết vấn đề mà không đặt câu hỏi
- Quá trình giải quyết vấn đề của LLM cũng rất khác con người
- LLM gần như không đặt câu hỏi, mà cố giải quyết vấn đề dựa trên vô số giả định
- Lập trình viên con người trong những thay đổi lớn hoặc tình huống chưa rõ ràng luôn xác nhận bối cảnh bằng câu hỏi, hành động theo tinh thần 'không có câu hỏi nào là tồi'
- Ngược lại, LLM có xu hướng chỉ tiếp tục thử lặp đi lặp lại, và khi có vấn đề thì lặp mạnh hơn nữa
- Có thể thiết kế prompt quá mức để ép nó đặt câu hỏi, nhưng ngoài một số công cụ như Roo, hành vi này nhìn chung không diễn ra tốt
- Về căn bản, có thể là do các công ty phát triển LLM đã áp dụng RL (học tăng cường) với trọng tâm là 'viết mã nhanh hơn'
Kết luận
- Với những đặc tính này, LLM vẫn chưa đủ để thay thế lập trình viên con người
- Trong công việc thực tế, nó thể hiện năng lực ở mức 'thực tập sinh quá tự tin'
- Đây là lý do trải nghiệm cộng tác với LLM vẫn chưa mang lại cảm giác hoàn toàn tự nhiên
1 bình luận
Ý kiến trên Hacker News
Gần đây tôi có một trải nghiệm khá thú vị. Không phải liên quan trực tiếp đến code, nhưng hoàn toàn có thể xảy ra trong lĩnh vực code hay các mảng liên quan, và thực tế một đồng nghiệp của tôi cũng đã gặp. Trong lúc thảo luận trên HN về việc vì sao một quy định đã được thông qua từ 15 năm trước lại không được phổ biến rộng hơn, tôi đoán rằng vào thời điểm đó trình độ công nghệ chưa đủ để xử lý các trường hợp phổ quát, nên quy định chỉ được áp dụng cho phần nào khả thi khi ấy (bình luận liên quan). Vài giờ sau quay lại xem tiếp cuộc thảo luận, tôi thấy có vài người nói rằng ngay cả thời đó công nghệ liên quan cũng đã đủ rẻ rồi. Thế là tôi nhờ LLM tìm căn cứ về chủ đề này, và nó trả lời rằng nguyên nhân là do giới hạn kỹ thuật. Tôi kiểm tra các tài liệu nó trích dẫn để xác minh nguồn, thì hóa ra chỉ đúng một nguồn thực sự bàn về giới hạn kỹ thuật, và nguồn đó chính là bình luận mà tôi đã để lại trên HN. Khi kể chuyện này ở công ty, một đồng nghiệp nói rằng anh ấy từng để lại ý kiến trên Github kiểu như "X hoạt động như thế nào trên Windows", rồi sau đó tìm trên Google thì thấy một câu trả lời dựa trên LLM lại dùng chính ý kiến đó làm căn cứ để khẳng định y như vậy. Vì thế tôi rất muốn có thể hỏi LLM không phải là "X hoạt động như thế nào?" mà là "nếu ai đó hỏi X hoạt động như thế nào, hãy cho tôi danh sách các liên kết đáng để trích dẫn"
Tôi nghĩ cách đặt câu hỏi như vậy khá giống với "sorting prompt". Đây là một kỹ thuật tôi học được từ bài viết liên quan của Mike Caulfield, và bản thân tôi cũng dùng khi viết code (ví dụ: Claude code slash command). Nếu không chỉ yêu cầu LLM trả lời mà giao cho nó việc tra cứu, phân loại và đánh giá tài liệu, thì kết quả sẽ chính xác hơn rất nhiều
Phần lớn mọi người khi đọc bình luận về một chủ đề nào đó trên HN cũng thường tin theo kiểu "người này có vẻ biết chuyện, vậy cứ tạm xem là đúng đi". Vì để tự mình trải nghiệm hoặc có được tri thức đã được kiểm chứng thì thực sự tốn kém khủng khiếp, nên tôi nghĩ dạng 'tri thức giá rẻ' này cuối cùng vẫn có giá trị
Tôi từng thử yêu cầu LLM đưa ra căn cứ, nhưng cho đến nay chưa lần nào LLM thực sự cung cấp được căn cứ thật sự để chống lưng cho điều nó nói
LLM đôi khi còn bịa cả liên kết. Cần có một chế độ nghiên cứu sâu để nó thực sự làm việc tra cứu tài liệu, nhưng kể cả vậy thì cách nó diễn giải thông tin trong liên kết cuối cùng vẫn bị ảnh hưởng bởi quá trình huấn luyện
Gần đây tôi đưa vào NotebookLM 6~8 nguồn căn cứ đáng tin cậy (đặc tả IETF, OpenID và các tài liệu bổ sung), rồi hỏi một câu cực kỳ đơn giản: "OID4VP cho phép những định dạng credential nào?". Trong câu trả lời, nó đúng khoảng 90%, nhưng lại rất tự tin thêm vào một định dạng ngẫu nhiên hoàn toàn không có căn cứ nào cả, cứ như thể chính nó là tác giả đặc tả. Tôi thấy nghi ngờ nên tự mở đặc tả ra kiểm tra và lập tức biết đó là bịa đặt. Từ giờ có thể nói rằng ngay cả với LLM đã được "grounded", niềm tin vào tính đúng sự thật cũng đã sụp đổ hoàn toàn
Gần đây tôi dùng Codex CLI để refactor một file HTML, nhưng thay vì copy-paste đoạn code đúng như tôi kỳ vọng, LLM lại nhớ mang máng rồi thay bằng code nó viết mới, đồng thời xóa luôn cả comment. Có một section gồm 40 liên kết phức tạp liên tiếp, và khi kiểm tra lần cuối trước khi deploy, tôi bấm thử từng cái thì thấy phần đầu vẫn ổn nhưng từ giữa trở đi có đến 31 liên kết đều trả về 404. Domain thì đúng, nhưng chỉ phần đường dẫn URL là bị biến dạng. Xem lại URL cũ trong git commit thì hóa ra LLM đã "ảo giác" và đổi chúng thành những đường dẫn không hề tồn tại. Những lỗi tinh vi và âm thầm như thế này thực sự rất nguy hiểm. Nhất định phải cẩn thận
Tôi nghĩ ý cuối này cực kỳ quan trọng. Vì có những "lỗi rất tinh vi chui vào một cách im lặng", nên dù LLM làm việc ngang bằng hoặc tốt hơn con người thì nó cũng không được xử lý theo cùng một cách. Đặc biệt, code review vốn từ lâu là một lớp phòng vệ quan trọng để ngăn ngừa vấn đề, nhưng nếu loại lỗi cần kiểm tra ở đây khác đi thì cách code review cũ sẽ kém hiệu quả. Trước đây khi di chuyển một lượng lớn code, có thể giả định là khối đó được chuyển nguyên xi và tập trung chú ý hơn vào mức độ khái quát cao. Nhưng với refactor bằng LLM, đoạn code được "di chuyển" thực ra có thể là code "mới" được tóm lược/tái cấu trúc lại, nên phải nhìn từng ký tự. Vì vậy tôi nghĩ nên thêm một mục "AI usage" trong phần mô tả Pull Request để ghi lại AI đã được dùng ở đâu và như thế nào, giúp reviewer biết nên tập trung kiểm tra khu vực nào
Tôi cũng thường gặp trải nghiệm tương tự khi ném cho nó các câu hỏi về code hay nghiên cứu. Ban đầu LLM làm khá tốt, nhưng từ lần thứ N trở đi là bắt đầu tự bịa nội dung. Gần đây trước một chuyến đi, tôi nhờ Gemini cho danh sách các brewery với thông tin mới nhất, nhưng nó vẫn thản nhiên đưa vào những nơi đã đóng cửa hoặc chỉ hoạt động tạm thời. Tôi yêu cầu nó thêm liên kết giờ mở cửa và loại bỏ các nơi đã đóng cửa, thì nó chỉ phản ánh ở phần đầu danh sách, còn phần sau lại sửa linh tinh không liên quan hoặc hoàn toàn không xóa các nơi đã đóng. Thế nhưng lần nào nó cũng trả lời cực kỳ tự tin rằng đã nghiên cứu hoàn hảo
Không phải chuyện code, nhưng có lần tôi nhờ LLM chỉ kiểm tra chính tả/ngữ pháp cho một thông báo sự kiện. Nó gửi lại một phiên bản chỉnh nhẹ, nhưng lén dời ngày đi chậm một ngày. May là tôi nhận ra và sửa lại, nhưng đó là một bài học rằng không thể mù quáng tin tưởng ngay cả với tác vụ rất đơn giản. Dù prompt chỉ là một câu ngắn, dễ hiểu và rõ ràng, LLM đôi khi làm được những điều đáng kinh ngạc nhưng cũng có lúc sai cả những thứ đơn giản nhất theo cách hoàn toàn không ngờ tới
Chỉ 5 phút trước, tôi còn gặp chuyện Claude được yêu cầu chỉ thêm câu lệnh debug vào code, nhưng lại âm thầm sửa luôn cả regex. Với diff thì dễ phát hiện, nhưng trong các thay đổi lớn thì thực sự rất dễ bỏ sót
Việc kiểm tra lại toàn bộ 40 liên kết ngay trước khi deploy là một lựa chọn sáng suốt. Nhưng việc bạn đẩy thẳng lên master sau khi Codex hoàn thành mà không chạy 'git diff' thì cũng hơi đáng ngạc nhiên
Tôi đồng ý với lập luận của bài viết. Nhưng theo tôi, vấn đề lớn nhất là agent chỉ nhìn thấy một phần cực nhỏ của code repository. Nó không biết các helper function đã có sẵn và cứ liên tục tạo lại những thứ giống hệt. Trong phát triển UI, nó không thể so sánh toàn bộ cấu trúc UI nên code thiếu nhất quán cứ lặp đi lặp lại. Cuối cùng con người vẫn phải cung cấp đúng context như "hãy tham khảo helper function trong file này", "hãy làm theo implementation này", "nhất định phải đọc tài liệu này". Nếu tự tay đưa đúng ngữ cảnh thì mức độ hữu dụng của agent có thể tăng lên rất nhiều. Nhân tiện, một vấn đề khác là trong monorepo lớn nó rất kém trong việc khám phá cấu trúc thư mục, ví dụ thật sự rất hay không thể chạy đúng 'npm test' từ một thư mục con
Đây chính xác là vấn đề tôi gặp hàng ngày. Gần đây tôi review khoảng hơn 200 dòng code cho một tính năng mới do Cursor tạo ra, nhưng phần code thực sự cần thiết thì chẳng bao nhiêu. Việc tìm xem trong utility library đã có sẵn hàm tương tự chưa thật sự rất phiền, nên thường tôi đành bỏ qua. Cách đây 5 năm kiểu review này còn mang tính onboarding cho junior nên việc chỉ ra chỗ đó rất quan trọng, nhưng dạo này thì với Cursor và các công cụ tương tự, lượng code chỉ tăng lên trong khi chính developer cũng biết rõ cấu trúc, nhưng vì chính sách công ty mà cố tình làm vậy, nên tôi cảm thấy năng suất bị giảm
Chuyện chạy các lệnh như 'npm test' trong thư mục con lúc nào cũng là vấn đề. Trong một repo tách frontend Vite/React và backend .NET, nếu lệnh npm thất bại thì nó hoảng loạn, lặp đi lặp lại nhiều lần mà vẫn không giải quyết được, chỉ tạo thêm troubleshooting vô ích. Có lần tôi còn viết hướng dẫn trong 'CLAUDE.md' để nó luôn kiểm tra thư mục hiện tại trước, nhưng vấn đề quên đường dẫn vẫn tiếp diễn một cách ngẫu nhiên. Vậy nên tôi thêm các alias như 'run-dev server restart', 'run-dev client npm install' có thể chạy từ bất kỳ thư mục nào, rồi đưa các lệnh thuần như dotnet/npm vào danh sách cấm, để ép AI phải tự tham khảo tài liệu dự án và dùng alias. Cách này ít nhất cũng tương đối ổn định, nhưng để đi đến đó thì tốn khá nhiều thời gian, công sức và căng thẳng
Tôi nghĩ sẽ hay nếu các mô hình context lớn được dùng qua tool call. Gemini chat có khả năng ingest toàn bộ repo github. Sẽ ra sao nếu có một tool 'not-invented-here' kiểm tra trước khi viết hàm mới xem codebase đã có thứ tương tự chưa? Dĩ nhiên trước hết chắc tôi phải tìm xem có ai đã làm công cụ kiểu đó chưa
Đó cũng là lý do vì sao cần các tài liệu như claude.md. Nếu muốn tuân theo các quy tắc riêng của nhóm thì bắt buộc phải tài liệu hóa
Thật ra tình huống này là chuyện mà senior engineer rất thường gặp khi làm việc thực tế cùng đồng nghiệp
Tôi hoàn toàn đồng cảm với phần được trích trong bài. Tôi đồng ý rằng LLM chưa thể thay thế các developer trình độ cao. Người tỉnh táo thì lúc này khó mà nói khác được. Nhưng tôi nghĩ những developer yếu hoặc tầm trung thì đã bị thay thế rồi. Ví dụ trong tổ chức của chúng tôi từng có 3 người xuất thân từ bootcamp 6 tháng, được tuyển vào vì thời điểm đó quá khó kiếm developer giỏi. Nhưng trên thực tế, ngay cả những nhiệm vụ cực kỳ đơn giản họ cũng chật vật, và lần nào tôi cũng phải dọn lại toàn bộ code trong review. Sau đó công cụ AI cải thiện theo cấp số nhân và vượt qua hiệu suất của họ. Kết quả là 2 người bị sa thải, người còn lại tự nghỉ việc. Gần đây chúng tôi cũng gần như không tuyển junior developer nữa, và tuyệt đối sẽ không tuyển người xuất thân từ bootcamp. Xung quanh tôi cũng tương tự, nên có vẻ cả ngành bootcamp đang dần biến mất. Tôi không biết AI sau này có thể thay cả developer giỏi hay không, nhưng nếu nhìn vào dữ liệu hiện tại thì rõ ràng nó đang tiến bộ cực nhanh. Những ý kiến phủ định chỉ là né tránh thực tế. Thuở ban đầu ở Mỹ có đến 90% dân số làm nông nghiệp, còn bây giờ chỉ khoảng 2%. Nhưng sản lượng và sự đa dạng thực phẩm lại lớn hơn rất nhiều. Tất cả đều là kết quả của tiến bộ công nghệ. Tôi nghĩ điều tương tự hoàn toàn có thể lặp lại trong ngành phát triển phần mềm với tốc độ rất nhanh
Đúng là công nghệ đã làm tăng sản lượng lương thực, nhưng thực tế cũng khiến giá trị dinh dưỡng giảm và độc tính tăng lên
Tôi tò mò không biết bạn nghĩ nguyên nhân vì sao những người xuất thân từ bootcamp đó không phát triển được
Bài học quan trọng hơn là, LLM rất mong manh ngay cả với các tác vụ khá đơn giản nếu không có một lượng đáng kể chỉ dẫn và giám sát. Trong dự án nhỏ của tôi (2.5K dòng), tôi yêu cầu refactor parser thì kế hoạch nghe rất hợp lý. Tôi chia theo từng bước có checkpoint rõ ràng và cho làm tuần tự, nhưng mỗi lần hỏi "cấu trúc cũ đã bị xóa chưa?", "đã thay bằng cấu trúc mới chưa?" thì câu trả lời luôn là "chưa, nó vẫn còn nguyên". 80% test bị fail, và kể cả khi tôi chỉ ra hướng sửa cụ thể thì với công việc trừu tượng kiểu "refactor", nó vẫn luôn thất bại vì cùng một kiểu vấn đề. Cuối cùng tôi buộc phải viết chỉ dẫn cực kỳ chi tiết đến mức "class nào phải đổi cái gì". Đến mức này thì không thể giao việc một cách độc lập được nữa, và bản thân ý nghĩa của việc dùng LLM cũng giảm đi rất nhiều
Trải nghiệm của tôi hơi khác. Trình phân tích expression tree viết bằng typescript (tinqerjs.org) có đúng 0 dòng do tôi tự viết; chỉ với Codex+Claude mà trong 2 tuần (làm bán thời gian) đã hoàn thành, còn thêm cả hàng trăm test (kể cả test trùng lặp). Tôi cũng từng làm ORM và với LLM thì tiết kiệm ít nhất 4~10 lần thời gian. Hầu như không cần giám sát, và tôi nghĩ kết quả cuối cùng phụ thuộc vào mục đích sử dụng cũng như việc quy trình đã được thiết lập hay chưa. Những developer đã quen khai thác LLM cũng đang xây dựng workflow riêng cho mình, và điểm chung là ai cũng tập trung vào test, tài liệu hóa và code review
Vấn đề kiểu "nếu chỉ dẫn refactor phải quá chi tiết thì dùng nó chẳng còn ý nghĩa" có lẽ cần được thay bằng cách tiếp cận "nếu chia nhỏ tốt các bước cấp cao rồi đưa chỉ dẫn, thì vẫn nhanh hơn rất nhiều so với tự làm một mình"
Điều này cũng liên hệ với điểm trong bài rằng 'AI không cut-paste mà xóa rồi tái tạo'. Trên thực tế, code dần drift đi một chút có lẽ là điều không tránh khỏi
Tôi tò mò không biết bạn đã dùng model/tool nào. Ngay cả khi dùng Cursor hay Copilot, tôi cũng thường gặp chuyện các refactor nhỏ vẫn cần giám sát liên tục
Rõ ràng LLM có những chỗ rất hữu ích. Ví dụ sáng nay tôi sửa được bug trong PDF Metadata parser nhờ có nó mà không cần đào quá sâu vào đặc tả PDF. Nhưng trong phần lớn trường hợp, sản phẩm đầu ra lại kém hiệu quả hơn so với việc tự tôi làm. Trước đây khi tôi thử dùng Codex Code để viết unit test, dù đã chuẩn bị đủ loại setup nhưng do ngại mock dữ liệu nên mới giao cho nó. Tôi đã thử đến 8 lần, vẫn phải sửa tay, và nó còn không hiểu rằng một entity đã obsolete và không còn được service sử dụng nữa. Kết quả là rất thất vọng. Nó chưa đủ để thay thế hoàn toàn developer, nhưng giống như Stack Overflow ngày trước, tôi thấy nó làm rất tốt vai trò mở ra kiến thức và gợi hướng giải pháp ở những chủ đề còn lạ lẫm
Tôi không cho rằng việc quá tay trong việc thiết kế "prompt để buộc nó làm rõ câu hỏi hơn" là điều xấu. Ngược lại, việc thiết kế prompt theo hướng 'nếu chưa rõ thì hãy hỏi trước' đã tỏ ra rất hiệu quả. Một lập trình viên giỏi sẽ biết liệu đặc tả đã được truyền đạt đầy đủ chưa, hay còn cần thêm clarification, và có thể dẫn dắt AI đặt ra những câu hỏi cần thiết ngay từ đầu
Thậm chí có thể chỉ định rõ là nó phải hỏi bao nhiêu câu. Với các chủ đề phức tạp, tôi thường yêu cầu trước 20~30 câu hỏi và kết quả khá hài lòng. Cũng hữu ích nếu lưu phần QnA này vào một file riêng để tái sử dụng trong phiên sau hoặc với agent khác
Nhờ cách này mà giờ tôi không còn viết prompt kiểu cũ nữa. Chỉ cần ném ra ý tưởng rồi thêm "nếu cần thì hỏi" là nó thường chỉ ra rất đúng những điểm mà tôi chưa nghĩ tới
Sau khi đọc đoạn nói về copy-paste trong bài, tôi lấy cảm hứng và thêm một công cụ agent buffer vào clippy (một tiện ích macOS). clippy có MCP server để tương tác với clipboard hệ thống, nhưng lần này dùng một buffer riêng tư riêng biệt là phù hợp hơn. Các tính năng được thêm gồm buffer_copy (copy một dải dòng cụ thể từ file và lưu vào private buffer), buffer_paste (chèn/thay thế đúng từng byte đang có trong buffer vào file đích), buffer_list (xem nội dung trong buffer). Ví dụ nếu agent ra lệnh kiểu "copy dòng 50~75 của auth.py", thì server chỉ trực tiếp thực hiện file I/O, hoàn toàn không có chuyện sinh token hay ảo giác. Nó cũng không ảnh hưởng đến clipboard hệ thống. Trước đây AI cũng có thể copy thẳng code do nó sinh ra vào clipboard để dùng luôn. Mục đích chính của clippy là cải thiện macOS pbcopy — copy nội dung file thật để trong terminal có thể dán chính file đó vào Slack hay email. Ai dùng các agent tương thích MCP như Claude trên macOS thì xem ở đây. Có thể cài bằng brew install neilberkman/clippy/clippy
Phần lớn developer cũng không giỏi đặt câu hỏi. Họ thường xem nhiều thứ là hiển nhiên và lược bỏ chúng. Trong 25 năm kinh nghiệm phát triển, hơn một nửa đồng nghiệp của tôi có nhược điểm thứ hai này. Bản thân tôi cũng vậy trong nửa đầu sự nghiệp nên càng thấy đồng cảm
Đúng như nhận định trong bài rằng "LLMs không copy-paste (hoặc cut-paste)", chúng ghi nhớ code rồi xóa đi và viết lại, nên cảm giác như lần nào cũng chỉ đang phát lệnh write mới. Trong refactor, thực ra copy/paste thật sự không quá nhiều, nên phần lớn vẫn là xử lý bằng recall dựa trên context. Trong công việc thực tế, tôi cũng không chắc bản thân lệnh copy/paste có thật sự hữu ích đến mức đó không (ít nhất là trong các thử nghiệm của tôi thì không khác biệt lớn). Ngược lại, với các phần lặp đi lặp lại và chiếm nhiều context, dùng công cụ như fastmod rồi nhờ codex hay claude "sửa hàng loạt chỗ này" có vẻ hiệu quả hơn. Cách tiếp cận giải quyết vấn đề của nó khác con người nên thấy hơi lạ, nhưng nếu giao tiếp với kế hoạch đủ kỹ thì bản thân cách tiếp cận cũng có thể thay đổi khá nhiều
IDE có thể đổi ngay function signature hay tên ở nhiều file, nhưng LLM agent khi thử làm điều tương tự thì nhiều khi mất hàng phút mà vẫn không xử lý chính xác. Tôi nghĩ lợi ích của hỗ trợ copy/paste thực sự là rất rõ ràng
copy/paste còn giúp giảm bùng nổ context rất nhiều. Vì model không cần phải ghi nhớ nội dung của khối code mà vẫn có thể truy cập bất cứ lúc nào cần