Phương pháp code AI “dây ngắn” đánh bại Fable
(blog.okturtles.org)- Để dùng tác nhân lập trình AI cho phần mềm quan trọng về bảo mật, cần một phương pháp Short Leash trong đó lập trình viên liên tục kiểm soát các thay đổi thay vì giao cho AI tự vận hành
- Cách tiếp cận kiểu “vibe” với nhiều tác nhân song song cùng tạo và rà soát mã có thể làm suy yếu khả năng hiểu codebase, đồng thời khiến vấn đề chỉ bị phát hiện sau khi AI đã off the rails
- Quy trình cốt lõi gồm lập kế hoạch, chia nhỏ theo bước, xem xét diff trong prompt cấp quyền, thường xuyên từ chối và can thiệp, commit theo từng tác vụ con, rồi rà soát cuối cùng
- Trong review PR, dùng cả AI và con người sẽ giúp giảm sai sót tốt hơn; AI nhanh chóng bắt các lỗi phổ biến còn con người đánh giá các vấn đề ở mức cao hơn và định hướng chung
- Với PR có AI tham gia viết, người gửi phải tự rà từng dòng và ghi rõ model đã dùng trong phần AI Disclosure của mô tả PR để tạo niềm tin
Điều kiện tiên quyết để dùng tác nhân lập trình AI
- Phương pháp này dựa trên kinh nghiệm sử dụng tác nhân AI để tạo phần mềm chất lượng cao trong các hệ thống quan trọng về bảo mật
- Đối tượng không phải là lập trình viên mới xem AI như kẻ thù của việc học, mà là lập trình viên chuyên môn cao giỏi hơn “frontier AI models” trong lĩnh vực chuyên môn của mình
- Mục tiêu là dùng AI như công cụ tăng năng suất mà vẫn không đánh đổi chất lượng phần mềm
- Phạm vi kinh nghiệm bao gồm việc khám phá giới hạn của tác nhân AI, tự xây dựng công cụ review AI, và duy trì bản fork tùy chỉnh của tác nhân lập trình AI Crush
Điểm mà cách tiếp cận kiểu “vibe” bắt đầu chao đảo
- Trong các phiên làm việc với tác nhân AI, thường có thể phát sinh hai vấn đề
- Ý tưởng ban đầu kém và chỉ về sau mới phát hiện ra rằng có cách tiếp cận tốt hơn
- Tác nhân đi off the rails theo hướng không mong muốn
- Khi nhiều tác nhân song song và bộ điều phối cùng làm việc một lúc, còn lập trình viên bị loại khỏi quá trình viết mã, sẽ rất khó tự tích lũy hiểu biết trực tiếp về codebase
- Trong bối cảnh không quá quan tâm đến chất lượng, cách này có thể vẫn chấp nhận được, nhưng khi chất lượng là yếu tố quan trọng thì cần một cách tiếp cận khác
- Mã do Fable 5 viết hoặc review, dù chạy được, vẫn có thể kém hiệu quả và khó nhìn
- Trong các lĩnh vực ngách nơi model có ít dữ liệu huấn luyện để dựa vào, những vấn đề này có thể xảy ra thường xuyên hơn
- Trái với cách tiếp thị của một số CEO, quan điểm ở đây cho rằng model không thể suy nghĩ vượt ra ngoài dữ liệu huấn luyện của nó
Cách phương pháp Short Leash hoạt động
- Short Leash không phải là phương pháp phù hợp cho tất cả mọi người, mà được thiết kế cho lập trình viên phần mềm chuyên nghiệp
- Ưu điểm là có thể cho ra kết quả vượt Fable ngay cả khi không dùng frontier model
- Trước khi làm việc, ở giai đoạn lập kế hoạch cần nghiên cứu bài toán và lập kế hoạch
- Với công việc lớn, dùng công cụ như tasks skill để theo dõi tiến độ và chia thành các bước
- Điểm này giống với nhiều phương pháp “vibe engineering”
- Sau đó, điều cốt lõi là luôn giữ AI trên dây ngắn
- Không dùng chế độ “YOLO” hoặc “dangerously skip permissions”
- Không để AI tự làm việc một mình trong lúc người dùng đi chơi game
- Dùng tác nhân lập trình có hiển thị diff của thay đổi sắp áp dụng trong prompt cấp quyền
- Lập trình viên thực sự phân tích các thay đổi mà AI đề xuất
- Dùng diff trong prompt cấp quyền để luôn cập nhật hiểu biết về codebase và giữ AI trong tầm kiểm soát
- Nếu AI định làm điều không mong muốn thì từ chối cấp quyền
- Can thiệp thường xuyên khi cần để AI không đi chệch hướng
- Mỗi khi hoàn thành một tác vụ con, tạo một commit để ngăn AI phá hỏng hoặc xóa mất công việc trước đó
- Điều này thực sự có thể xảy ra, và đã có trường hợp như vậy được thấy trên Opus
- Bước cuối cùng là thực hiện review
AI review không thay thế review của con người
- So với PR chỉ do con người review hoặc chỉ do AI review, PR được cả con người và AI cùng review có thể giảm sai sót tốt hơn
- Có thể xem AI như một linter
- Bắt nhanh các lỗi phổ biến
- Con người đánh giá các vấn đề ở cấp độ cao hơn và việc có cần đổi hướng hay không
- Khuyến nghị mọi PR đều nên đi qua AI review
- AI review cần đủ ngữ cảnh
- issue
- mô tả PR
- codebase
- các thay đổi
- Khuyến nghị dùng model mới nhất sẵn có cho việc review
AI Disclosure và trách nhiệm của người gửi
- Nếu AI được dùng để viết PR, thì trong phần AI Disclosure của mô tả PR phải công khai chính xác model đã dùng
- Việc công khai này có nhiều mục đích
- Thông báo cho maintainer rằng có dùng AI
- Nếu dùng model yếu, họ có thể đề xuất model tốt hơn
- Phát tín hiệu rằng đây không phải là cố tình lén đưa AI vào quy trình
- Với PR có dùng AI, chính “tác giả” PR bắt buộc phải tự review
- PR có AI hỗ trợ thực chất gần với PR của AI có con người trợ giúp, nên người gửi phải hiểu rõ nội dung mình đang gửi
- Người gửi phải xem PR của mình như PR của người khác và tự review từng dòng một
- Sau khi hoàn tất tự review, họ có thể xác nhận chấp thuận của mình và yêu cầu maintainer xem xét
- Quy trình này vừa giúp hình thành vừa thể hiện rằng người gửi thực sự hiểu codebase
Cách okTurtles áp dụng
- okTurtles sử dụng AI theo phương pháp này
- Chính sách chính thức được tóm tắt trong AI Usage Policy
- Bài viết này do con người viết, và có kèm AI Disclosure rằng trước khi đăng chỉ thực hiện kiểm tra chính tả theo kiểu AI
1 bình luận
Ý kiến trên Hacker News
Cách “dây dắt ngắn” này trông giống một cái nạng hơn là công cụ hỗ trợ, và có vẻ là dấu hiệu cho thấy ngay từ đầu bạn chưa giải thích vấn đề đủ rõ cho AI, hoặc chưa xem xét và lặp lại trên đầu ra
Việc cầm tay dẫn dắt một mô hình mạnh như Fable ở giai đoạn triển khai là lãng phí thời gian và lãng phí Fable. Mô hình càng mạnh thì càng có thể thảo luận thiết kế tinh tế hơn, và viết mã tốt hơn trước rất nhiều. Chính quá trình thảo luận về thiết kế và triển khai, đặt câu hỏi về những phần trông lạ, và thực sự đọc câu trả lời của AI giúp tìm ra giải pháp tốt hơn
Trước đây khi định tạo một lời giải bằng thuật toán tham lam, trong quá trình trao đổi với Opus, tôi được gợi ý rằng có thể giải chính xác bài toán bằng thư viện MILP hiện có. Tôi thậm chí chưa từng nghe đến MILP, nhưng bản triển khai cuối cùng tốt hơn và đơn giản hơn so với khi tự làm một mình
Nhưng nó không chạy được, và khi tôi yêu cầu giải thích các bước suy luận từ nguyên lý đầu tiên đó, nó đáp rằng thực ra nó chỉ bịa ra. Vì vậy tôi khó tin vào chuyện thảo luận tinh tế với mô hình
Nếu đã đầu tư đủ vào giai đoạn lập kế hoạch và kiến trúc cũng như quy ước hiện có của dự án đủ vững, thì có thể không cần giám sát nhiều ở giai đoạn triển khai như bài viết nói
Việc “ý tưởng ban đầu ngu ngốc và có thể phát hiện ra cách tốt hơn” thường được phát hiện ở mức cao trong giai đoạn lập kế hoạch và kiến trúc
Vấn đề agent “chệch hướng” theo cách không mong muốn cũng không còn tệ như trước, và những thay đổi có ảnh hưởng nên có tối thiểu một mức độ bao phủ kiểm thử. Kể cả khi kiểm thử đó chỉ ở mức “đóng đinh” hành vi đã được triển khai cũng được. Cuộc thảo luận rà soát cuối cùng là cơ hội tốt để kiểm tra thêm ngoài những gì phần review hoặc agent review mang tính đối kháng đã tìm ra
Ví dụ MILP không phải là điều cách tiếp cận này sẽ ngăn cản, và lẽ ra đã lộ ra ở giai đoạn lập kế hoạch
Cuối cùng thì chi tiết mới quan trọng, và cách bạn đưa prompt khởi đầu công việc sẽ có ảnh hưởng. Dù vậy, việc kiểm tra đầu ra, tham gia vào những gì mô hình đang làm, và truy hỏi vì sao nó định làm như vậy là bắt buộc
Nhưng khi đó ý tưởng của nhân viên ấy sẽ không được đưa ra bàn, và những đóng góp có thể có lợi lâu dài cho cả đội cũng biến mất
Nó giúp tôi hiểu mọi thứ được sinh ra và tiếp tục duy trì kiến thức làm việc về codebase. Cũng dễ đổi hướng cho nó
Tôi đã làm như vậy trong 2 tuần với một dự án phụ, nhưng cuối cùng vẫn rơi vào trạng thái không có mô hình tinh thần về codebase
Tôi càng tin rằng không có cách nào xây dựng được mô hình đó nếu không tự tay làm
Vì đường cong lãng quên, mô hình tinh thần của tôi không tồn tại lâu bằng giai đoạn tôi xây dựng nó lúc đầu. Tôi vẫn chưa tìm ra cách xây dựng lại nó
Tuy vậy tôi đồng ý rằng nó không tích lũy tốt “khả năng tự mình làm ra” như khi trực tiếp viết
Ví dụ, tôi biết để đạt một hiệu ứng nào đó thì cần thay đổi gì, và khi thực sự thay đổi thì kết quả đúng như kỳ vọng, nên tôi biết mô hình tinh thần của mình hoạt động. Nhưng nếu bảo tôi tự làm một thứ tương tự từ đầu thì có lẽ tôi không làm được. Cách tiếp cận có cảm giác nằm ngoài tầm tay tôi, khó giải thích
Tôi tưởng những người thực sự biết lập trình đều dùng AI theo cách này khi dùng cho việc quan trọng
Tôi sai à? Dạo này mọi người cứ cho chạy ở chế độ YOLO sao?
Đó là niềm vui của thời gian funemployment. Khi quay lại làm việc thì chắc sẽ là một thay đổi khá thú vị
Hiện giờ cách làm đơn giản là cho nó chạy, uống bia, khoảng một tiếng thì thiết lập lại phản biện định hướng lớn và phản hồi tự kiểm tra/vòng kín, rồi lại để nó chạy tùy ý
Tôi tò mò không biết ngoài bypass-permissions thì dùng Claude theo cách nào. Tôi đã thử quản lý danh sách công cụ Claude được dùng trong một thời gian dài, nhưng rốt cuộc cứ quay lại là thấy nó bị dừng vì cố pipe đầu ra của công cụ này sang công cụ khác và việc đó không được cho phép rõ ràng. Chỉ là mấy việc kiểu
grepmà cũng dừng lại nên rất bựcVới bypass-permissions thì “cứ thế chạy”. Tất nhiên tôi chỉ dùng để phân tích mã hiện có và đề xuất thay đổi; nếu có gì hỏng thì đó là lý do ta có quản lý phiên bản
Nhìn chung tôi đồng ý với tác giả. Trên hết, tôi muốn bổ sung rằng đừng tin bất cứ điều gì LLM làm hoặc nói
Hôm nay tôi bảo Claude thống nhất hành vi của 3 component, và phải yêu cầu 5 lần. Lần nào đến cuối vẫn còn chỗ chưa khớp, và Claude đều tìm ra cách hợp lý hóa chuyện đó
Khi hỏi thì nó trả lời “đó là trách nhiệm của tôi” hoặc “tôi nghĩ đó là một lựa chọn có chủ ý”, nhưng chưa một lần nào nó chủ động hỏi phải làm gì trước hay nêu vấn đề. Vì vậy hãy giữ dây dắt ngắn, xem quá trình suy nghĩ, và chỉnh ngay những việc vô nghĩa. Đây là với Sonnet 5 hôm nay; ngày mai có thể tốt hơn hoặc tệ hơn. Cách nói hiệu quả với Claude hôm nay có thể cho kết quả khác vào ngày mai
Vấn đề với các bài kiểu “cách làm X bằng AI” là mỗi tình huống đều khác nhau. Ví dụ, việc nâng một dự án Symfony từ 3.1 lên 8.1 có lộ trình rõ ràng
Chỉ cần làm theo các hướng dẫn migration được viết cho từng phiên bản major, rồi kiểm thử toàn bộ route, luồng xác thực, v.v. Các kiểm thử này cũng có thể tự chọn lọc; cái thì trả về 200, cái thì trả về 302
Tùy chọn, có thể viết trước một lớp an toàn để giảm kiểm thử thủ công, chẳng hạn đặt baseline PHPStan
Nếu các route hoạt động đúng như dự định về mặt chức năng end-to-end thì xong. Trường hợp này cũng có thể dùng snapshot test
Trong những trường hợp như vậy, không cần phải canh chừng AI. Cuối cùng vẫn có thể review code, nhưng không cần phê duyệt thủ công từng bước ở giữa, nên tôi tắt các tính năng an toàn
Phần lớn bài viết được viết từ một góc nhìn, nhưng thực tế góc nhìn thì rộng hơn; thứ hiệu quả trong một tình huống có thể không hiệu quả trong tình huống khác. Toàn bộ kỹ nghệ phần mềm rốt cuộc gần như là việc nhận ra nên áp dụng cái gì, ở đâu, khi nào, và bỏ qua phần còn lại
Nhiều bài blog công ty khiến người ta tin rằng có một viên đạn bạc dùng được cho mọi trường hợp, nhưng thường thì không phải vậy
Sau cùng, như những gì kỹ nghệ phần mềm vẫn luôn xử lý, nó gần với “một số thứ hiệu quả trong một số tình huống” hơn; không phải đúng hay sai, mà việc áp dụng thực tế theo từng bối cảnh là khác nhau, và điều đó là bình thường
AI ở mức kỹ sư junior đến mid-level. Nếu đối xử với nó như vậy, bạn có thể có được cả lợi ích của vibe coding lẫn kỹ nghệ nghiêm ngặt mà không cần tất cả sự hoang tưởng này
Ngay từ đầu tôi đã chạy Claude trong một VM tách biệt ở chế độ YOLO. Nó giống như đưa laptop riêng cho một kỹ sư. Claude làm tính năng đến mức có thể mở PR, tôi review diff như với một kỹ sư khác, rồi chỉnh lại cho đúng hình dạng phù hợp và tiếp tục
Kỹ sư non kinh nghiệm cũng mắc những lỗi tương tự. Tôi cũng từng thấy
rm -rf, dù không phải chạy từ thư mục root. Nếu cứ từ chối mọi quyền và micromanage ai đó, chắc tôi phát điên mấtTôi cũng đồng ý với phép so sánh kỹ sư junior/mid-level, nhưng có một điều kiện lớn. AI giống một kỹ sư junior không biết cách học
Cảm giác như đang làm việc với nhân vật chính trong Memento. Mỗi ngày LLM đến làm là nó không học được gì từ công việc trước đó, ngày nào cũng là ngày đầu tiên
Tất nhiên, như nhân vật chính trong Memento, ta có thể giúp bằng cách rải giấy nhớ và thông báo khắp workspace. Nếu nỗ lực thì có thể tiến gần đến thứ gọi là “học”, mà đây đúng nghĩa là đặc tính quan trọng nhất với mọi lập trình viên trong đội
Nhưng không dễ, và công cụ hiện vẫn còn thiếu. Điều tốt nhất tôi từng làm được gần giống một “bộ não thứ hai” dùng các công cụ như Obsidian. Đáng buồn là tôi cho rằng bộ não thứ hai không thể thay thế bộ não thứ nhất. Thành thật mà nói, nếu một kỹ sư không thể học hỏi và trưởng thành như AI agent, thì ở bất kỳ công ty nào tôi từng làm việc, người đó đã bị sa thải sau tháng đầu tiên
Dù vậy, tôi khá lạc quan rằng các nhà cung cấp AI lớn, hoặc ai đó, sẽ cải thiện phần này trong tương lai. Nếu có memory tốt, kết hợp với một hệ thống tư duy được thiết kế tốt để đưa ký ức vào đúng ngữ cảnh hơn, và có thể nắm bắt việc học thực sự mà không cần giám sát, thì đây không giống một nhiệm vụ bất khả thi
Tôi đọc những bài như thế này với hy vọng rằng ai đó đã giải quyết vấn đề đó rồi và chỉ là tôi biết muộn, nhưng hiện tại thì năng lực thiết kế agent của tôi chỉ khá hơn lúc đầu một chút
Nguyên tắc kinh nghiệm của tôi là mọi quy trình đặc biệt tạo ra cho AI cũng phải hợp lý với con người; nếu không thì nó không có giá trị. Công cụ dòng lệnh tốt, tự động tóm tắt output lệnh dài, tài liệu Markdown và workflow đều hữu ích cho con người
Để ngăn lỗi và lạm dụng, nên dùng sandbox và quyền hạn giới hạn theo phạm vi, không phải micromanage
Điều tôi muốn tìm ra là workflow pair programming tốt với AI agent. Có thể giao việc lớn cho model hiệu năng cao và việc đó chạy tốt. Cũng có thể dùng model cấp thấp làm trợ lý IDE và việc đó cũng chạy tốt. Nhưng hai cái là hai workflow riêng biệt
Thứ thật sự hữu ích là cùng xây dựng với model hiệu năng cao bằng cách thay phiên nhau cầm bàn phím. Tuy nhiên, không nên là chạy chế độ YOLO hoàn toàn trên máy của tôi. Đây là khác biệt giữa con người và LLM. Vì nó quá nhanh, nên khi nó đi chệch hướng, rất khó giật lại bàn phím
Không ai biết chính xác AI là gì, nhưng nó không phải kỹ sư junior hay mid-level. Nó giống một staff engineer hạt nhân sống trong căn lều tạm, không có ngữ cảnh domain và cứ mỗi 5 giờ lại thức dậy mà không có ký ức hơn
LLM vẫn chỉ là bộ dự đoán token tiếp theo. Việc nó tìm ra các bước đúng dù bạn đưa ra chỉ dẫn mơ hồ hơn không có nghĩa là nó có trí thông minh. Nó chỉ có nghĩa là bạn đang nói cùng thứ ngôn ngữ với bộ harness được dùng để huấn luyện mô hình
Và điều đó có giới hạn. Nếu bạn chỉ dừng ở mức proof of concept hoặc ứng dụng đơn giản, có thể bạn sẽ không nhận ra các mô hình hiện tại vẫn còn hạn chế đến mức nào. Trong những trường hợp đó, bạn nên chia nhỏ công việc, chứ không nên tin vào một bộ dự đoán token biết liệt kê các bước nghe có vẻ hợp lý
Ở đâu đó nhất định phải có human loop. Khi bạn bắt đầu bỏ qua quyền hạn, kịch bản tốt nhất là trúng lớn, nhưng khả năng cao hơn là nhận được giải pháp hạng hai và lãng phí token. Điều thật sự đáng sợ là khi mô hình phớt lờ chỉ dẫn, làm chuyện ngớ ngẩn và phá hỏng cả ngày của bạn
Thứ này sắc như máy CNC. Không phải là không hữu ích, nhưng có thể nguy hiểm. Nếu bạn không biết đỗ xe song song, tốt hơn đừng cố dùng một cỗ máy quái vật để tiện gỗ, hoặc cố đậu Ferrari trong một khu phố chật hẹp
Nói rằng LLM có thể hoặc không thể làm gì đó vì nó là “bộ dự đoán token” là một lỗi phạm trù. Giao diện không phải là một giới hạn cứng
Tôi tò mò không biết làm sao có thể có một định nghĩa loại trừ mô hình ngôn ngữ nhưng bao gồm con người, mà không dùng tiên đề định sẵn rằng LLM không có trí thông minh
Thường thì câu này hàm ý rằng “nó chỉ dự đoán token tiếp theo trong dữ liệu huấn luyện, tức là Internet”, điều này có thể đúng với mô hình thô. Nhưng mô hình còn trải qua hậu huấn luyện, nên ngay cả cách mô tả đó cũng không còn đúng nữa
Câu “không phải trí thông minh” vừa không hữu ích, vừa theo tôi là sai. Ai quan tâm nó có khớp với định nghĩa trí thông minh của bạn hay không. Nó vẫn đang làm được những việc ấn tượng, và còn làm được nhiều việc lớn hơn nhiều so với điều bạn ám chỉ
Bài gốc có cảm giác vẫn mắc kẹt ở năm 2025
Nó nói “AI sẽ nhiều lần đi chệch hướng và bạn chỉ nhận ra khi thật sự dùng phần mềm”, nhưng giờ AI có thể tự dùng phần mềm để tìm và sửa lỗi, cũng như thúc đẩy tính năng mới
Vẫn có lúc agent bắt đầu làm những việc không mong muốn, nhưng ít hơn trước rất nhiều, và lập luận ủng hộ agent hoàn toàn tự chủ đang mạnh lên chứ không yếu đi
Câu “con người hiểu codebase là điều bất khả thi về mặt con người” cũng nghe lỗi thời. Tôi nghĩ giờ chúng ta đang đi theo hướng con người không còn cần hiểu codebase nữa, còn AI sẽ dẫn dắt
Nhiều người đang nhảy lên chuyến tàu này, nhưng tôi xem đó là một trào lưu ngu ngốc
Nhưng tuyệt đối không đúng với các hệ thống có rủi ro bảo mật lớn. Trong các lĩnh vực như ngân hàng, hàng không, quốc phòng, AI chắc chắn sẽ đóng góp, nhưng không thể vận hành độc lập với hiểu biết kỹ thuật của con người
Cách dây dắt ngắn là phương pháp bảo đảm kết quả tốt khi làm việc ngoài dữ liệu huấn luyện. Tôi nghĩ với bất kỳ lập trình viên nào chỉ cần khá hơn trung bình một chút, đây là cách duy nhất để bảo đảm phát triển nhanh và chất lượng bằng LLM
Câu nói rằng con người không còn cần hiểu codebase nữa có vẻ xuất phát từ việc không biết thế giới lập trình mà AI vẫn còn vụng về thảm hại. Tôi liên tục thấy nó xử lý sai bộ nhớ trong các ngôn ngữ có quản lý bộ nhớ thủ công. Chuyện này không đơn giản đến mức chỉ cần nhét nó vào một vòng lặp Valgrind là xong
Tôi đã lặp đi lặp lại nhiều lần để tinh chỉnh định nghĩa API, mô hình request/response, schema cơ sở dữ liệu và toàn bộ luồng, rồi tự tay loại bỏ mâu thuẫn và sửa tài liệu khá nhiều. Opus liên tục đi chệch hướng, và tài liệu cuối cùng dài hơn 500 dòng
Với test tích hợp API cũng phải qua lại nhiều lần. AI không thể tạo test trực tiếp từ tài liệu, nên trước tiên tôi phải tạo placeholder có chú thích Given-When-Then, tự rà soát và chỉnh sửa, rồi ở vòng lặp thứ hai mới triển khai test. Có rất nhiều lỗi được sửa sau khi review
Ở giai đoạn triển khai, tôi cung cấp tài liệu API, test đang chạy được, hook chặn sửa đổi, hơn 6 skill “best practice”, các agent “rubber duck” và “đơn giản hóa code”, cùng script để kiểm tra test, linter và lỗi biên dịch. Sau lập kế hoạch, thực thi, review và nhiều lần chỉnh sửa, tính năng đã được triển khai và toàn bộ test đều pass
Khi review code, trung bình cứ 20 dòng code tôi lại tìm thấy một vấn đề. Không tính style code, còn có việc dùng semaphore in-memory trong service Kubernetes, thực hiện 8 lần gọi DB để cập nhật cùng một record trong một request, cập nhật từng cột một, đọc-sửa-lưu không có transaction, cùng các lỗi về business logic, khôi phục và phân quyền
Kết quả là gần một tuần thời gian làm việc, hơn 100 đô la chi phí token, và chỉ còn suy nghĩ “nỗ lực này có đáng không?”. Tôi đang có một đội 2 developer, và vừa review PR của một người thì 80% là slop
Tôi đã thử một cách tiếp cận tương tự nhưng không hợp với tôi. Hầu như không tăng tốc, hoặc không tăng chút nào. Tôi nghĩ để có năng suất thì cần một mức YOLO mode nào đó trong sandbox
Mục tiêu nên là outsource cho mô hình càng nhiều việc càng tốt, đồng thời giảm tối thiểu công sức cần thiết để hiểu và review kết quả
Ví dụ như giao cho mô hình tìm nguyên nhân bug, tạo proof of concept cho X, tối ưu dần một thứ gì đó, hoặc refactor được định nghĩa rõ với hướng dẫn
Điều mọi người gọi là tạo loop cũng rất giống vậy. Tức là tối đa hóa phần việc mô hình làm, và tối thiểu hóa phần việc tôi phải làm để kiểm soát nó
Bài viết chẳng có nội dung gì đáng kể
Năm ngoái là “AI chỉ là con vẹt xác suất”
Năm nay là “AI có thể viết code, nhưng con người vẫn phải review!” Tất nhiên, ngay cả việc review đó cũng dùng AI
Chỉ cần thêm 1 năm nữa, câu chuyện sẽ trở thành “chỉ AI mới có thể review code, và cũng chỉ AI mới có thể review phần review của AI. Con người chỉ cần đọc ý kiến cuối cùng của AI để duy trì sự giám sát có ý nghĩa”
Khung thành thì cứ dịch chuyển, nhưng niềm tin chắc chắn thì không bao giờ lay chuyển