- Một kỹ sư phần mềm hiệu quả xây dựng và duy trì mô hình tinh thần rõ ràng về yêu cầu và mã nguồn, rồi thực hiện một vòng lặp liên tục để so sánh và cập nhật chúng
- LLM có thể viết và sửa mã, tạo bài kiểm thử, gỡ lỗi, nhưng thiếu khả năng duy trì mô hình tinh thần chính xác, nên dễ rơi vào rối loạn trong các tác vụ phức tạp
- Hiện tại, LLM có những hạn chế trong việc xác định chính xác khác biệt giữa mã nguồn và yêu cầu rồi sửa cho phù hợp do các vấn đề thiếu ngữ cảnh, thiên kiến gần đây, và ảo giác
- Con người có thể linh hoạt chuyển đổi cách tư duy tùy tình huống, như tạm lưu toàn bộ ngữ cảnh hoặc tạm ẩn chi tiết để nhìn bức tranh lớn, nhưng LLM chưa làm được điều này
- LLM hữu ích với các công việc có yêu cầu đơn giản, nhưng trong phát triển phần mềm phức tạp, cuối cùng kỹ sư phần mềm vẫn phải trực tiếp chịu trách nhiệm về độ rõ ràng của yêu cầu và cách mã nguồn vận hành, còn LLM đóng vai trò công cụ hỗ trợ
Vòng lặp kỹ thuật phần mềm
- Kỹ sư giàu kinh nghiệm làm việc bằng cách lặp lại các bước sau
1. Xây dựng mô hình tinh thần về yêu cầu
2. Viết mã theo mô hình đó
3. Hiểu điều mà đoạn mã đã viết thực sự thực hiện
4. Xác định khác biệt và sửa mã hoặc sửa yêu cầu - Trọng tâm của vòng lặp này là khả năng sở hữu mô hình tinh thần chính xác và có thể duy trì
Giới hạn của LLM
- LLM có thể thực hiện các chức năng như viết mã, xác định vấn đề rồi sửa, viết và chạy kiểm thử, thêm log, sử dụng debugger
- Tuy nhiên, do không thể duy trì mô hình tinh thần, các vấn đề sau phát sinh
- Giả định rằng mã do chính nó viết hoạt động tốt
- Khi kiểm thử thất bại, dựa vào phỏng đoán để quyết định nên sửa mã hay sửa bài kiểm thử
- Khi bị rối, xóa toàn bộ mã rồi viết lại từ đầu
- Không giống con người, khi kiểm thử thất bại, LLM thiếu sự linh hoạt để kiểm tra lại mô hình và quyết định hướng sửa, hoặc tháo gỡ vấn đề thông qua đối thoại khi gặp bế tắc
- Kỹ sư phần mềm thường chạy kiểm thử trong quá trình làm việc, và khi có vấn đề phát sinh, họ có thể xác định rõ phần nào cần sửa
- Đôi khi, ngay cả khi phải làm lại toàn bộ công việc, kết quả vẫn là mức độ hiểu vấn đề sâu sắc hơn
Khả năng trong tương lai
- Dù sau này mô hình có thể tiến bộ hơn, kỹ thuật phần mềm vẫn đòi hỏi nhiều hơn việc chỉ tạo mã
- Khi giải quyết vấn đề quan trọng, con người có thể tạm lấy toàn bộ ngữ cảnh từ trí nhớ ra để xử lý, rồi tập trung vào từng vấn đề hoặc nhìn ở cấp độ tổng thể
- Điều quan trọng không phải là cứ liên tục mở rộng thông tin ngữ cảnh, mà là cách tư duy xử lý có chọn lọc những thông tin cần thiết
- LLM thiếu khả năng như con người trong việc tạm lưu và khôi phục ngữ cảnh, hoặc luân chuyển tư duy giữa bức tranh lớn và chi tiết
- Các ràng buộc chính của LLM hiện nay
- Thiếu ngữ cảnh (Context omission): Không giỏi tìm ra những phần thiếu thông tin cần thiết
- Thiên kiến gần đây (Recency bias): Quá chú trọng thông tin mới nhất trong cửa sổ ngữ cảnh
- Ảo giác (Hallucination): Tạo ra các chi tiết không tồn tại
- Nếu được bổ sung tính năng bộ nhớ thì có thể cải thiện phần nào, nhưng khi vượt quá ngưỡng phức tạp, LLM vẫn thất bại trong việc hiểu ngữ cảnh và duy trì mô hình
- Nó thiếu khả năng duy trì hai mô hình tinh thần tương tự nhau để phân tích khác biệt và quyết định nên sửa yêu cầu hay sửa mã ở đâu
Vai trò và cách sử dụng hiện tại
- LLM mạnh ở khả năng tạo mã nhanh và tổng hợp yêu cầu, tài liệu, nên hoàn toàn có thể được tận dụng cho các công việc đơn giản, rõ ràng
- Nhưng với các vấn đề không đơn giản, việc duy trì đủ ngữ cảnh và cải thiện lặp đi lặp lại là rất khó
- Vì vậy, các việc như làm rõ yêu cầu, kiểm chứng mã nguồn vẫn là trách nhiệm của kỹ sư phần mềm
- Mục tiêu là hướng tới môi trường nơi con người và tác nhân (LLM) cùng tạo ra phần mềm, nhưng ở thời điểm hiện tại, kỹ sư phải giữ vai trò chủ đạo, còn LLM là công cụ
2 bình luận
Vì sao LLM ở "thời điểm hiện tại" thực ra không thể tạo ra phần mềm..
Ý kiến trên Hacker News
Chúng ta không giải quyết vấn đề chỉ bằng cách nhét thêm thật nhiều từ vào cửa sổ ngữ cảnh; làm thế thì đã phát điên mất rồi
Khi có sự cố xảy ra, chúng ta cũng không chỉ nhìn vấn đề qua văn bản
Nếu debugger báo lỗi xác thực, chúng ta không nghĩ kiểu “hay là cứ xóa luôn phần kiểm tra token trong code nhỉ?” để giải quyết
Ta thực sự lùi lại một bước để nhìn toàn bộ tình huống nhằm tìm ra nguyên nhân gốc rễ của vấn đề
Ví dụ, nếu có lỗi xác thực, ta sẽ xem lại toàn bộ quy trình xác minh token hoặc quyền của người dùng gọi vào, rồi có thể nhận ra chính bài test mới là thứ sai
Trong quá trình đó, ta cũng phát hiện ra rằng không phải chỉ cần xóa lỗi đi, mà còn cần phân biệt chi tiết hơn như “401 là do chưa xác thực hay do thiếu quyền”
Tham khảo Grugbrain.dev
Tôi cho rằng lập trình viên đang làm công việc chuyển các quy tắc nghiệp vụ sang một dạng chặt chẽ để máy tính có thể hiểu được
Quá trình dịch này không phải lúc nào cũng đơn giản, vì phải đồng thời hiểu ý nghĩa của quy tắc và cách máy tính (hoặc framework cùng các tầng trừu tượng đang dùng) vận hành
Đặc biệt khi yêu cầu mới phá vỡ mọi giả định trước đó hoặc mâu thuẫn với chúng, ta gần như buộc phải sửa đi sửa lại nhiều lần
Ngay cả dịch ngôn ngữ giữa con người với nhau cũng đã mơ hồ và phức tạp, trong khi máy tính thì thực thi chính xác những gì được yêu cầu nên chỉ một sai sót nhỏ cũng có thể thành vấn đề lớn
Cá nhân tôi nghĩ cách tiếp cận thực tế là để con người luôn tham gia theo vòng lặp lặp lại
Tôi vẫn tiếp tục dùng cách này vì nó giúp làm việc nhanh hơn và cho chất lượng tốt hơn
Bản thân tôi có thể tự giữ toàn bộ một lượng lớn ngữ cảnh trong đầu
Bản thân văn bản code sẽ nhanh chóng bị bỏ đi, còn não tôi sẽ parse code thành một cấu trúc kiểu AST (cây cú pháp trừu tượng), xa hơn nữa là một đồ thị không gian
Tôi mô hình hóa bản thân chương trình theo logic, và nhận thức nó như một cấu trúc hoàn toàn tách biệt với văn bản
Nhìn từ góc độ này, LLM không hiểu được cấu trúc phần mềm vì nó chỉ tập trung vào văn bản chứ không xây dựng được mô hình logic của chương trình
Việc kiến trúc các hệ thống lớn đòi hỏi tư duy trừu tượng thực sự tiêu tốn rất nhiều nỗ lực trí não, nhưng LLM lại thiếu khả năng trừu tượng hóa này
Cách của tôi là như sau
Khi một test thất bại được báo lên, trước tiên tôi xác định component liên quan, rồi phân tích sâu mục đích của component đó, luồng điều khiển nội bộ, thay đổi trạng thái, và cả các giả định về ngữ cảnh xung quanh, sau đó tổng hợp lại dưới dạng Markdown (
<tên-component>-mental-model.md)Sau đó mỗi khi xử lý vấn đề test, tôi luôn tham chiếu mô hình tư duy này
Nếu dán phần phân tích này vào prompt của Claude thì LLM có thể cho ra kết quả tốt hơn
Thậm chí tôi còn có thể trực tiếp đọc và chỉnh sửa mô hình tư duy do LLM dựng nên
AI cũng có thể khuyên dùng 403 thay vì 401 khi là trường hợp thiếu quyền
Có vẻ tác giả bài viết chưa hiểu đúng năng lực hiện tại của LLM và các công cụ coding
Nhận định rằng khi test thất bại, LLM chỉ đoán mò code đúng hay test sai, rồi đến lúc bế tắc thì xóa sạch toàn bộ code, là điều khác với trải nghiệm thực tế của tôi
Kỹ sư phần mềm luôn xác định cụ thể nguyên nhân test thất bại bằng cách đối chiếu với mô hình trong đầu của mình
Tôi đang dùng Cline và Anthropic Sonnet 3.7 để phát triển theo TDD trong Rails, luôn bắt LLM viết test trước rồi mới viết code
Tôi chia công việc thành các phần nhỏ để có thể tự review từng phần, và khi test thất bại thì nó suy luận khá ổn phần nào cần sửa rồi sửa đúng
LLM không hoàn hảo, nhưng nhiều khi cho kết quả ngang hoặc tốt hơn một kỹ sư junior là con người
Thỉnh thoảng nó không sửa được bug, nhưng thật ra dev mới vào nghề của con người cũng vậy
LLM hoạt động đặc biệt tốt với các tác vụ CRUD trong những framework đã được kiểm chứng như Rails
Ngược lại, khi tôi thử dùng nó để làm ứng dụng native Windows bằng Direct2D và Rust thì tệ kinh khủng
Tôi mong sẽ có những đánh giá cởi mở hơn cho nhiều trường hợp khác nhau
Việc các model dùng mẹo và thủ thuật (như hardcode) để làm cho test lỗi thành pass là hiện tượng đã rất nổi tiếng
Theo kinh nghiệm của tôi thì độ hiệu quả khác nhau rất lớn tùy ngôn ngữ, nền tảng và domain
Gần đây tôi không thử với Rails vì bản thân cũng không còn đụng Ruby nữa, nhưng Rails vốn có văn hóa lập trình rất nhất quán nên có vẻ LLM làm ổn ở đó là điều dễ hiểu
Ngược lại, Python thường trộn lẫn nhiều phong cách code khác nhau nên tôi đã nhiều lần thấy LLM trộn các pattern lại với nhau làm test trở nên thiếu ổn định
Phải sửa code lặp đi lặp lại, và có cả những kết quả kỳ quặc như lỗi thật ra chỉ là “thiếu sắp xếp kết quả query” nhưng LLM lại khuyên bỏ SqlAlchemy và chuyển sang Django
Với ngôn ngữ R thì ngay cả việc nhận được đoạn code chạy đúng theo spec thôi cũng đã rất khó
Nếu giới hạn LLM ở mức kỹ sư mới vào nghề, thì đặc biệt với những vấn đề nó đã từng thấy, nó thực sự tìm và áp dụng lời giải rất nhanh
Ngược lại, với những vấn đề nó chưa từng thấy, nó cần nhiều giải thích hoặc hướng dẫn hơn, và lúc đó vai trò của tôi gần như chỉ là người mentor
Đội của chúng tôi đang tích cực dùng cách làm kiểu ‘claude-code’ cho những việc lặp lại, đã biết rõ như các đợt refactor đơn giản tồn đọng lâu trong backlog hay các hệ thống phân tích thứ cấp
Cá nhân tôi rất hay kéo một block code rồi hỏi kiểu “giải thích như cho trẻ 5 tuổi” hoặc “tìm xem có nguy cơ race condition không”
Code được sinh ra thường khác phong cách với code sẵn có nên tôi vẫn hay phải tự chỉnh lại cho đúng style
Dạo này còn nghe cả chuyện “viết code để AI dễ đọc”, nhưng tôi vẫn thấy lợi ích thu được chưa thật sự lớn so với phần gánh nặng bổ sung
Với ý “LLM đôi khi ngang hoặc hơn junior”, tôi lại nghĩ biết đâu đây là phản ánh về mặt bằng tuyển dụng developer gần đây
Nếu tôi tuyển một junior còn kém hơn Sonnet 3.7 thì chắc tôi sẽ rất thất vọng
Phần lớn các phê bình về LLM có thể là đúng, nhưng qua nhiều năm đầu tư tôi nhận ra nên chú ý tới những công nghệ hay công ty “chưa ra gì nhưng vẫn tiếp tục tăng trưởng”
Đầu thập niên 90, giữa thập niên 90, Internet bị phàn nàn rất nhiều nhưng mọi người vẫn tiếp tục dùng, Twitter cũng hay sập nhưng rồi vẫn thành nền tảng tin tức
Xe điện, smartphone... cũng từng bất tiện, nhưng vì có giá trị nên vẫn tiếp tục được cải thiện
LLM hiện chưa hoàn hảo trong nhiều tác vụ, nhưng so với năm 2022 thì giờ đã tiến bộ gấp 10 lần, và tôi cho rằng trong vòng 5 năm tới phần lớn các vấn đề đang được nhắc đến cũng sẽ được giải quyết
Nhưng ở tất cả các ví dụ vừa nêu, cũng có những lúc kỳ vọng không hề khớp với thực tế
Internet nhanh hơn không có nghĩa metaverse đã từng trở thành xu hướng chủ đạo, và những giới hạn vật lý như say VR vẫn chưa được giải quyết
Hồi đó cũng đâu có nhiều người phàn nàn rằng điện thoại chậm; trường hợp sử dụng được kỳ vọng vốn khác
Chỉ vì nhìn vào quỹ đạo phát triển của các công nghệ trước đây mà khẳng định LLM chắc chắn cũng sẽ tiến hóa theo cùng một mẫu hình thì không thuyết phục
Ta cũng nên ghi nhớ rằng có thể sẽ xuất hiện công nghệ mới mang đến lời giải tốt hơn
Năm ngoái đúng là phạm vi ứng dụng đã rộng hơn, nhưng vẫn chưa có bước đột phá nào thật sự xứng đáng gọi là cách mạng
Dù điện thoại đời cũ chậm và camera kém, chỉ riêng công dụng chính khi đó là “có thể liên lạc mọi lúc mọi nơi” cũng đã đủ khiến nó trở thành thứ thiết yếu
Những tiến bộ đột phá chỉ là “phần thưởng thêm”, chứ không phải thứ người ta ngồi chờ đợi với suy nghĩ “không biết bao giờ chiếc điện thoại này mới khá hơn”
Tôi nghĩ bản thân cũng có sự bóp méo ký ức
Trái với cảm giác rằng có nhiều phàn nàn đại chúng về Internet thập niên 90, thực tế người dùng khi đó là thiểu số, và phải rất lâu sau nó mới thành xu hướng chủ đạo
Thực ra cũng không có nhiều bằng chứng cho thấy từng có một lượng lớn công chúng công khai than phiền rằng Internet quá chậm
Chúng ta chỉ nhớ những sản phẩm thiểu số đã phát triển thành công, còn đa số thì nhanh chóng bị lãng quên hoặc biến mất mà không hề được cải thiện
Thay vì đặt kỳ vọng rằng công nghệ rồi sẽ phát triển, tôi thích đánh giá dựa trên tình trạng hiện tại hơn
Tôi khó đồng ý với lập luận đơn giản rằng bước tiến nhảy vọt của LLM trong vài năm qua sẽ đương nhiên tiếp tục mãi về sau
Nó có thể chạm tới giới hạn tăng trưởng, và đặc biệt tôi cảm thấy điểm giới hạn chí mạng của LLM là thiếu khả năng khám phá tri thức mới hay suy luận về thông tin chưa biết
Tôi không nói đây là công cụ vô dụng, nhưng cũng sẽ không tham gia vào những kỳ vọng quá mức
Kỳ vọng rằng chỉ nghe vài câu là LLM có thể lập tức code ra cả prototype vốn đã là điều phi thực tế
Nếu bắt một đội dev con người làm việc như vậy thì họ cũng không thể làm ra thứ tử tế, nên tôi không hiểu vì sao lại đặt kỳ vọng kiểu đó lên LLM
Muốn cải thiện đáng kể chất lượng đầu ra phát triển phần mềm của LLM thì cần tích cực tận dụng quy trình và công cụ mà các đội phát triển hiện có đang dùng
bài autonomous-software
Tôi đã bắt đầu một dự án tên là steadytext, nơi code được viết hoàn toàn tự chủ, chủ yếu theo kiểu vibe, và LLM còn tự xử lý cả issue lẫn yêu cầu tính năng trong một dự án phức tạp khoảng 7.000 dòng (thư viện Python, CLI, extension Postgres)
Tôi thậm chí chưa từng tự xem tới 90% code, nhưng tổng độ phủ test, CI pass, và cả việc dùng thật trong production đều không có vấn đề gì
Dĩ nhiên trong
CLAUDE.mdphải có kế hoạch cực kỳ chi tiết, issue và request cũng phải thật rõ ràng cụ thể, nhưng nếu chuẩn bị được như vậy thì nó hoạt động tốtViệc để coding agent quản lý/viết code hiệu quả không hề dễ, nhưng trải nghiệm của tôi là tích cực
GitHub steadytext
Tôi chấp nhận các góc nhìn phê phán, nhưng khi xử lý các vấn đề mơ hồ thì cốt lõi rốt cuộc vẫn là cả đội cùng chia sẻ rất nhiều ngữ cảnh
Ngay cả những lời giải sáng tạo nhất cũng xuất phát từ các ràng buộc tường minh và ngầm định
LLM không có khả năng nắm bắt các ràng buộc như vậy, hoặc tự tạo ra lời giải mới trong các ràng buộc chưa được xác định rõ
Chỉ sau khi con người xác định vấn đề, khoanh vùng phạm vi và hiểu điều kiện ràng buộc thì LLM mới có thể trở thành công cụ hỗ trợ triển khai
Ở thời điểm hiện tại, nó chỉ mới được bổ sung như một lựa chọn ở mức “dùng công cụ nào để hoàn thành đoạn code này?”
Tôi nghĩ việc kéo cuộc thảo luận này về hướng một lời giải duy nhất, tuyệt đối kiểu tất cả hoặc không có gì, mới là điều phi thực tế
Thực ra trong hoàn cảnh này cũng có rất nhiều kỹ sư con người làm việc khá ổn
Nếu việc ra lệnh cho LLM còn chẳng dễ như vậy, thì tôi tò mò không biết ý nghĩa tồn tại của nó là gì
Kiro đang áp dụng cách tiếp cận này; vẫn còn ở giai đoạn đầu nên chưa hoàn hảo, nhưng nếu làm đúng như ý đồ của nó thì kết quả khá ổn
Khi dùng claude code, tôi ngày càng thấy bức bối với điểm “LLM không thể xây dựng một mô hình tư duy rõ ràng”
Tôi không chắc LLM dựa trên văn bản có thể giải quyết thỏa đáng vấn đề này hay không
Tôi nhớ tới trường hợp Google Genie 3 bị mất trạng thái nội bộ chỉ trong khoảng 1 phút
Tôi có trực giác rằng vấn đề này chỉ có thể được giải quyết khi có một kiến trúc mới ở cấp độ transformer, cho phép cả ngữ cảnh ngắn hạn, dài hạn lẫn việc tự điều chỉnh trọng số của chính nó (kiểu mô phỏng học tập)
Tham khảo: thảo luận liên quan
Gần đây tôi đang nghĩ liệu cấu trúc agent phân cấp có phải là một phương án thực tế hơn không
Sẽ hay nếu agent cấp cao nhất chỉ giữ mô hình tư duy tổng thể, còn các agent cấp dưới thì chia nhau công việc
Có lẽ ngay cả bây giờ cũng có thể triển khai tương tự bằng tính năng agent trong công cụ Code; nếu ai có chiến lược liên quan thì tôi rất muốn được chia sẻ
Tôi đã thử claude-code-requirements-builder, có cải thiện đôi chút nhưng vẫn chưa thật sự hài lòng
Thực tế mà nói, trong môi trường làm việc, một dev junior “trung bình” cũng không khác nhiều so với mô tả bên dưới
Họ tin code mình viết chắc chắn là đúng, test hỏng thì hoảng, không biết đi hướng nào thì tệ nhất là xóa sạch code rồi viết lại từ đầu
Copy-paste từ StackOverflow, đổ cho compiler, thậm chí còn lôi cả “do tia vũ trụ” ra làm lý do
Càng dùng LLM, tôi càng nhận ra rốt cuộc mình vẫn phải là người chủ động về planning và thiết kế
Những việc lặp lại ở mức thấp và test thì giao cho LLM, còn tôi có thêm thời gian để nghĩ về bức tranh lớn hơn, điều đó khá tốt
Dù vậy tôi vẫn mong việc review kết quả của LLM, đề xuất thay đổi v.v. sẽ được cải thiện theo hướng tương tác hơn nhiều
Tôi nghĩ hướng đi của các startup AI chính là trọng tâm của vấn đề hiện nay
Cần một workflow AI được tích hợp tự nhiên trong IDE, chứ không chỉ là giao diện chat đơn thuần
Đó cũng là xu hướng như ở Visual Studio, InteliJ, Android Studio
Tôi muốn một công cụ giống lập trình viên thực thụ: có thể ra lệnh bằng giọng nói bằng tiếng mẹ đẻ, AI hiểu được toàn bộ ngữ cảnh dự án để bao quát cả refactor, phân tích tĩnh, phản hồi AI; dựng UI từ phác thảo, code từ chữ viết tay, sinh commit message từ thay đổi trong code
Tôi đồng ý rằng LLM khá hữu ích cho các công việc ở mức junior
Gần đây tôi bắt đầu nghĩ lại về quan điểm cũ rằng “tốc độ gõ phím không quá quan trọng”
Trước đây, vì thiết kế tổng thể và cấu trúc quan trọng hơn rất nhiều so với tốc độ nhập code, nên thời gian gõ bản thân nó không chiếm tỷ trọng lớn
Nhưng sau khi dùng Claude, điều tôi nhận ra là những thay đổi code vốn trước kia phiền phức nên hay lười làm, giờ có thể được thực hiện dễ dàng mà không cần tập trung nhiều
Trước đây mỗi lần thêm một giá trị enum là phải chú ý sửa tất cả các phần liên quan, còn LLM thì có thể tự sửa những chỗ đó
Những việc lặt vặt như phải sửa từng lỗi compile một cũng có thể giao cho Claude chỉnh lặp đi lặp lại
Trong lúc nhiều agent đồng thời động vào các phần khác nhau của code, tôi có thể dành thời gian đó để nghĩ về cấu trúc lớn hơn hoặc lên HN viết bài
Tức là không còn phải tự tay sửa lỗi compile nữa, nên có thể áp dụng nhiều thay đổi hơn một cách nhanh chóng, và những việc trước đây junior phải mất cả ngày giờ có thể xong trong một lần
Nhờ vậy tôi tập trung hơn vào thiết kế kiến trúc tổng thể, đồng thời giải quyết được cả đống việc code vặt đã trì hoãn từ lâu, nên động lực cũng tăng rất nhiều
Tôi đồng cảm với ý “dù gõ nhanh hơn thì cũng chưa chắc tới đích nhanh hơn, vì thiết kế mới là nút thắt”
LLM rất tệ trong việc tạo ra thiết kế tốt, và ngay cả từng hàm nhỏ chi tiết cũng vẫn gần như luôn phải refactor
Có tăng năng suất ở khâu triển khai thật, nhưng chủ yếu ở mức cụ thể hóa những ý tưởng vốn đã có sẵn trong đầu tôi hoặc trong tài liệu
Dùng để brainstorming thì khá ổn
Nếu ném cả code lẫn test cho nó rồi hỏi “có edge case nào bị bỏ sót không”, thì khoảng một hai trên mười lần nó sẽ cho ra gợi ý thật sự có ích
Việc sửa để chạy được trong ngắn hạn và sự xuất sắc về cấu trúc trong dài hạn là hai vấn đề quá khác nhau, nên chưa biết LLM có thể theo kịp vế sau hay không
Về ý “có rất nhiều việc muốn làm trong codebase”, thực ra tôi cảm thấy nút thắt không phải ở việc sửa code mà là ở khâu review
Nếu việc “LLM làm rất nhanh thứ mà junior phải mất cả ngày” cuối cùng lại khiến người mới mất cơ hội học hỏi và kéo theo việc thu hẹp tuyển dụng, thì tôi lo không biết sau này ai sẽ đào tạo họ trưởng thành lên
Với hiện tượng “không biết nên sửa code hay sửa test khi test thất bại”
Việc dùng ngôn ngữ “Red-Green-Refactor” có ích
Hiện tại tôi truyền đạt rất rõ cho LLM luồng RED (test fail là bình thường), GREEN (dùng lượng code tối thiểu để làm pass), REFACTOR (cải thiện code mà không làm hỏng test)
Làm vậy giúp LLM nhận ra đây không chỉ là “sửa code bị hỏng” mà là mô hình tư duy của TDD
Tôi nghĩ rõ ràng là LLM vẫn chưa đủ khả năng cho kiểu dự án mới hoàn toàn ở mức “hãy làm cho tôi một Facebook của riêng mình”
Thay vào đó, với những việc cụ thể hơn như “thêm modal này, tham chiếu code hiện có và giữ đúng style”, tôi đã nhiều lần nhận được kết quả như mong muốn
Nếu chia vấn đề thành các phần nhỏ rồi giao từng phần một thì kết quả sẽ tốt hơn nhiều
Việc copy code sẵn có rồi sửa theo ý mình thì tôi đã tự làm được rồi
Clipboard hệ thống của tôi, khác với LLM, luôn hoạt động một cách tất định, và không vô tận tạo ra những vấn đề mới ngoài dự kiến như LLM
Tôi tò mò những công cụ mới như v0 sẽ phản ứng với loại yêu cầu này như thế nào
Tôi cảm thấy quy trình 4 bước ở phần đầu bài viết rất giống với "The Beginning of Infinity" của Deutsch
Các lý thuyết của chúng ta bắt nguồn từ “phỏng đoán”, và tri thức được hình thành qua “vòng lặp giữa phỏng đoán và phê phán”
Viết code là một dạng “phỏng đoán”, còn tạo test là một dạng “phê phán” đối với phỏng đoán đó
Cả hai đều là quá trình cố gắng tiến gần hơn tới phần giải thích trong đầu ta (một lý tưởng mang tính Platon)