- Trong làn sóng tối ưu hóa quy trình, những kỳ vọng phi thực tế về AI đang lan rộng, nhưng chỉ riêng việc đưa AI vào không giúp cải thiện tốc độ xử lý
- Nguyên nhân thực sự khiến phát triển phần mềm mất nhiều thời gian không nằm ở tốc độ viết mã, mà ở quá trình chuyển đổi yêu cầu mơ hồ thành định nghĩa vấn đề rõ ràng
- Việc tạo mã bằng AI cũng đối mặt với cùng một vấn đề ở thượng nguồn, và để có kết quả chính xác thì sự tham gia sâu của các chuyên gia miền nghiệp vụ và sản phẩm là điều bắt buộc
- Trong các ví dụ so sánh việc sử dụng AI, quá trình cầm tay chỉ việc (handholding) thường bị bỏ qua, trong khi đây mới là yếu tố tạo ra khoảng cách năng suất thực tế; nếu các nhà phát triển con người cũng nhận được bộ tài liệu chi tiết tương tự thì năng suất của họ cũng sẽ tăng vọt
- Để thực sự tăng tốc quy trình, như bài học từ The Goal, ưu tiên trước hết là "cung cấp đầu vào có thể dự đoán được và chất lượng cao cho điểm nghẽn"
Tối ưu hóa quy trình trong thời kỳ suy thoái thị trường và kỳ vọng vào AI
- Khi thị trường chững lại, phần lớn tổ chức có xu hướng tập trung vào tối ưu hóa quy trình, dù chỉ ở mức độ nào đó; gần đây, yếu tố AI cùng với những kỳ vọng phi thực tế lại càng được cộng thêm vào bức tranh này
- The Toyota Way và The Goal gợi nhắc rằng nhiều nỗ lực tối ưu hóa quy trình rất dễ hiểu sai về điều cần tập trung
- Một công đoạn mất nhiều thời gian có thể là tín hiệu để bắt đầu cải thiện, nhưng không thể khẳng định đó là nơi vấn đề thực sự phát sinh
- Nếu chỉ đơn giản bổ sung thêm người hoặc kỳ vọng AI sẽ tăng tốc mạnh mẽ, thì sẽ không nhìn ra vì sao công việc bị chậm
- Muốn làm quy trình nhanh hơn, trước tiên cần kiểm tra xem người thực hiện đã có đủ đầu vào và điều kiện để thực sự bắt đầu và hoàn thành công việc hay chưa
Nút thắt trực quan (The visual bottleneck)
- Thông qua ví dụ biểu đồ Gantt, có thể thấy trực quan rằng công đoạn mất nhiều thời gian nhất là phát triển phần mềm
- Thông thường người ta dùng BPMN, nhưng để giải thích dễ hơn thì ở đây dùng biểu đồ Gantt
- Nếu mục tiêu là cải thiện throughput của dự án, thì cách tiếp cận ưu tiên xem xét công đoạn lâu nhất tự thân là đúng
- Vấn đề nằm ở cách mọi người giải quyết nó
- Đổ thêm nhân lực vào vấn đề (throw people at the problem)
- Giả định rằng AI sẽ làm nhanh hơn rất nhiều
- Trong khi đó, họ lại không xem xét "vì sao công đoạn này mất nhiều thời gian"; quan trọng hơn, thời gian kéo dài không có nghĩa nguyên nhân vấn đề nằm ngay ở công đoạn đó
Giải quyết vấn đề từ thượng nguồn
- Ví dụ được dùng là phát triển phần mềm, nhưng điều này áp dụng tương tự với mọi quy trình đang mất lâu hơn mong muốn
- Phát triển phần mềm không thể nhanh lên chỉ bằng cách tăng tốc độ gõ phím; nếu vậy thì hẳn ai cũng đã đi học đánh máy
- Bản chất của phát triển phần mềm là dịch bài toán thành một giải pháp mà máy tính có thể tự động giải quyết, theo cách càng an toàn và có khả năng mở rộng càng tốt
- Để làm được điều đó, cần có hiểu biết tổng thể về vấn đề
- Nếu theo kiểu gần với waterfall thì cần tài liệu chức năng hoặc tài liệu phạm vi
- Nếu theo kiểu agile thì cần lặp lại liên tục (iteration) với chuyên gia miền nghiệp vụ
- Thứ thực sự làm chậm quá trình phát triển là quá trình tìm hiểu một yêu cầu feature mơ hồ chỉ có tiêu đề rốt cuộc có ý nghĩa gì
- Ngay cả yêu cầu "gửi mail cho người dùng khi việc bán hàng hoàn tất (send mail to user once sale is completed)" cũng chưa phải là yêu cầu có thể triển khai ngay
- Có thể gửi mail, nhưng nội dung mail phải gồm những gì
- Nếu quy trình bán hàng có vấn đề, có nên gửi mail lỗi hay không
- Thời điểm nào thì một giao dịch bán hàng được xem là "hoàn tất"
Luận điểm cho rằng cứ giao hết cho AI
- Một luận điểm thường nghe là dùng AI tạo mã để bỏ qua công đoạn phát triển, còn kỹ sư phần mềm chỉ cần đóng vai trò quản lý dự án
- Nhiều người kỳ vọng khoảng thời gian phát triển phần mềm vốn kéo dài sẽ được thay bằng giai đoạn phát triển bằng AI chỉ khoảng 3 ngày
- Mọi người có hình dung về kết quả của phát triển bằng AI, nhưng trên thực tế nó không vận hành như vậy và vẫn phải đối mặt nguyên vẹn với cùng một vấn đề ở thượng nguồn
- Việc AI có thể tạo mã nhanh là đúng (còn đó có phải điều tốt hay không lại là một cuộc tranh luận khác), nhưng tạo nhanh không đồng nghĩa với tạo ra mã đúng
- Điều luôn bị bỏ qua trong các so sánh giữa phát triển bởi con người và AI là quá trình cầm tay chỉ việc (handholding) để AI hoạt động đúng
- Cách này có thể nhanh hơn phương pháp hiện tại, nhưng đó không phải là một phép so sánh công bằng
- Để phát triển bằng AI hoạt động, cần sự tham gia sâu hơn rất nhiều của các chuyên gia miền nghiệp vụ và sản phẩm
- Mọi tính năng đều phải được viết ra tới từng chi tiết rất nhỏ
- Mọi bản sửa lỗi cũng phải mô tả chi tiết kết quả mong muốn là gì
- Đây chính là điều mà các kỹ sư phần mềm đã luôn yêu cầu từ khi nghề này xuất hiện: một bản mô tả chi tiết về vấn đề và sản phẩm đầu ra cuối cùng
- Nếu cung cấp cho nhà phát triển con người cùng lượng tài liệu feature/scope như vậy, năng suất của họ cũng sẽ tăng mạnh
Cách thực sự giúp tăng tốc quy trình
- Muốn tăng tốc quy trình, cần bảo đảm rằng những người phải thực hiện công việc thực sự có đầy đủ mọi phương tiện để làm công việc đó
- Nếu quy trình phê duyệt pháp lý bị chậm, trước tiên hãy xem cần những gì để có thể bắt đầu quy trình phê duyệt pháp lý
- Nếu phải chạy theo năm người chỉ vì tài liệu chưa đầy đủ, thì việc bổ sung thêm luật sư cho bộ phận cũng không làm quy trình nhanh hơn
- Một trong những bài học lớn từ The Goal là điểm nghẽn phải nhận được các đầu vào có thể dự đoán được và chất lượng cao
- "bottlenecks should receive predictable, high-quality inputs"
- Điểm khởi đầu đầu tiên của tự động hóa quy trình không nên là chính công đoạn nghẽn, mà phải là việc nâng cao chất lượng đầu vào và khả năng dự đoán của những gì điểm nghẽn sẽ nhận được
1 bình luận
Ý kiến trên Hacker News
Có người nói điều mà phát triển phần mềm luôn mong muốn từ đầu là “được mô tả chi tiết vấn đề và kết quả mong muốn”, nhưng thực ra bản thân việc đó chính là kỹ thuật phần mềm
Ngay cả đến năm 2026, cũng nên từ bỏ ý nghĩ rằng chỉ cần có yêu cầu và đặc tả đủ chi tiết là có thể tạo ra lời giải hoàn hảo ngay trong một lần
Theo kinh nghiệm của tôi, nhờ AI mà giờ có thể lặp lại tính năng hay ý tưởng nhanh hơn rất nhiều, và giờ ma sát chủ yếu đến từ việc căn chỉnh và phối hợp với các nhóm khác
Nếu muốn tăng tốc quy trình thì cần giảm chi phí điều phối và trao nhiều quyền hơn cho cá nhân cũng như đội nhóm trong việc ra quyết định và thực thi
Ngay cả Anthropic, dù có đặc tả hoàn hảo, triển khai tham chiếu, cùng hàng nghìn bài kiểm thử do con người viết trong nhiều năm, vẫn không thể làm ra nổi thứ đơn giản như một trình biên dịch C chạy được
Các mô hình hiện tại, ngay cả khi có đặc tả hoàn hảo và bộ kiểm thử hoàn hảo, vẫn chưa đủ để tạo ra phần mềm vận hành không tầm thường mà không có sự giám sát cẩn thận của con người
Nếu không có đặc tả hoàn hảo và bộ kiểm thử hoàn hảo do con người viết thì còn khó hơn nữa, có lẽ phải đến khoảng năm 2027 mới khả thi
Buổi chiều tôi thường nhận những đầu việc mà phía phụ trách sản phẩm vừa nghĩ ra, và họ chỉ quan tâm đến luồng chuẩn, đôi khi còn chỉ quan tâm một phần của luồng đó
Công ty là công ty toàn cầu nên phải tuân thủ quy định và pháp luật ở từng quốc gia, thế là sau khi triển khai xong tính năng lại được báo rằng “thực ra ở 90% thị trường chúng ta đang hoạt động thì về mặt pháp lý không được làm thế này”, rồi lại phải thêm chức năng vô hiệu hóa
Sau đó họ quay lại bảo rằng “ở một số thị trường trong số đó thì vẫn làm được nếu đi qua quy trình pháp lý nào đó, nên hãy triển khai theo hướng đó”
Đến sát hạn chót thì cuối cùng lại phải vá víu lời giải kiểu hack
Đây không phải kỹ thuật phần mềm, thậm chí cũng chẳng liên quan đến bản thân phần mềm
Công việc của kỹ sư phần mềm là nhận một danh sách yêu cầu rồi tìm cách đạt được các yêu cầu đó, còn thu thập yêu cầu không phải là vấn đề kỹ thuật phần mềm
Phần mềm là triển khai, sản phẩm là hành vi, và hành vi của thứ cần xây phải được biết rõ trước khi bắt tay vào làm nghiêm túc
Nếu ai đó chịu lùi lại một tuần để khảo sát thực tế, họ đã có thể thiết kế một cấu trúc có thể mở rộng, dễ mở rộng, dễ bảo trì và giúp tương lai bớt vất vả hơn
Tôi đã viết chương trình hơn 40 năm nhưng chưa từng thấy trường hợp nào hoàn thiện đặc tả trước rồi mới viết phần mềm mà mọi thứ đều suôn sẻ
Trong kỹ thuật không tầm thường, phần khó nhất là hiểu vấn đề, và các phiên bản đầu tiên của phần mềm chính là cách để đi đến sự hiểu đó
Vì vậy tôi cho rằng kiểu “nhà máy phần mềm” dựa trên AI sẽ không bao giờ hoạt động tốt
Rốt cuộc nó lại quay về phát triển kiểu thác nước, nơi kiến trúc sư viết sơ đồ UML rồi giao cho đội lập trình viên một công việc triển khai về bản chất là đơn giản, nhưng rốt cuộc lại triển khai sai thứ cần làm
AI rất giỏi trong việc đi nhanh từ phiên bản đầu tiên sai sang phiên bản thứ hai bớt sai hơn
Chỉ là đừng quên nhiệm vụ cốt lõi là hiểu vấn đề mà mình đang cố giải quyết
Nếu chỉ nhận các đặc tả chi tiết thì tôi chẳng khác gì một robot viết code, và kiểu việc đó tôi giao cho junior
Cũng như trước đây, việc của tôi là đọc các yêu cầu đó, hiểu chúng, rồi kiểm chứng chúng đối chiếu với thực tế mà tôi biết
Code cũng vậy
Trong ít nhất 20 năm qua, cốt lõi của kỹ thuật phần mềm là đừng tin ai cả, và điều đó không thay đổi, vẫn tốn rất nhiều thời gian và công sức
Khi LLM mới xuất hiện, có vẻ như mọi người nghĩ chỉ cần nói kiểu “hãy làm cho tôi một bản sao Facebook” là xong
Giờ thì họ đang nhận ra rằng phải viết yêu cầu chính xác và được định nghĩa tốt hơn nhiều
Đây vốn luôn là nút thắt cổ chai của phần mềm
Hồi trước khi đi làm, tôi thực sự từng nhận những yêu cầu như “lấy dữ liệu và đưa cho người dùng”
Không có định nghĩa dữ liệu gì, lưu ở đâu, phải trả về theo định dạng nào, nên phải mất rất nhiều thời gian với phía sản phẩm để tìm ra họ thực sự muốn gì
Muốn có kết quả tốt với LLM thì cũng cần quá trình tương tự, và yêu cầu mơ hồ sẽ sinh ra kết quả mơ hồ
Họ điền vào mẫu những vấn đề gì đang tồn tại và vì sao, ví dụ như backend có trường X nhưng frontend không có, rồi dữ liệu sẽ được lấy ở đâu và như thế nào, tiêu chí chấp nhận là gì
Trước đây họ đã không làm vậy vì lười hoặc vì nghĩ rằng “dev sẽ tự lo được”
Sau đó lập trình viên có thể sao chép nội dung ticket Jira này vào bất kỳ agent LLM nào họ muốn, hoặc để LLM tự đọc bằng Atlassian MCP
Điều này đã giúp dev rất nhiều và yêu cầu cũng rõ ràng hơn hẳn
Thành thật mà nói, chỉ nhìn bước đầu tiên thôi thì PM đã như làm xong một nửa việc triển khai tính năng, nên có lẽ trong tương lai PM sẽ tự làm hết, còn một số dev sẽ ở lại giống SDET hơn là người triển khai đầy đủ
Ở đó ông mô tả rất chính xác các đặc điểm cốt lõi của vibe coding và trải nghiệm mà chúng ta đang có hiện nay
Ý chính là sau những thành công ban đầu trong một vài lĩnh vực được chọn lọc cẩn thận, khi mở rộng ra ngoài các lĩnh vực đó thì sẽ xuất hiện mức tăng năng suất hợp lý nhưng không mang tính cách mạng
https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...
Tôi chưa bao giờ dùng prompt kiểu gần với “hãy làm cho tôi một bản sao Facebook”, mà thay vào đó là mô tả cách nó phải hoạt động
Ví dụ, tôi đã yêu cầu một script Python đọc
/etc/hosts, tìm các giá trị host cụ thể được cấu hình trong.conf, đặt tên cho từng cấu hình, xác định môi trường hiện tại, tạo biểu tượng ở góc trên bên phải của GNOME mặc định trên Ubuntu 22, khi bấm vào thì liệt kê tên cấu hình, và khi chọn thì sao lưu/etc/hostsrồi chỉ sửa các dòng hostname cụ thểTừ đó nó tạo ra gần như trọn vẹn một công cụ chuyển môi trường dạng app indicator đơn giản cho GNOME chỉ trong một lần, và chỉ cần sửa vài dòng là hầu hết đã chạy
Nếu đưa cho LLM một đặc tả đúng nghĩa thì nó làm rất tốt, thậm chí bạn còn có thể bịa ra một DSL giả để mô tả điều mình muốn mà nó vẫn hiểu được
Lý do quy trình trước đây không hiệu quả là vì người viết yêu cầu không hiểu ý đồ kinh doanh hoặc bất cẩn nên đưa ra yêu cầu mơ hồ hay tệ
LLM chỉ làm cho cùng những yêu cầu mơ hồ hoặc tệ đó trông có vẻ hợp lý hơn thôi, nhưng đào sâu vào thì vấn đề lộ ra ngay
Sẽ có những câu hỏi như “‘lấy dữ liệu’ nghĩa là gì?”
Còn LLM thì chỉ đáp kiểu “Tất nhiên rồi! Đây là đoạn code hoàn chỉnh để lấy dữ liệu và đưa cho người dùng” rồi kết thúc
Bài này giả định AI chỉ tác động đến giai đoạn phát triển, nhưng điều đó rõ ràng không đúng
Nó có thể tăng tốc mọi giai đoạn, gồm lên ý tưởng, pháp lý, tài liệu hóa, phát triển và triển khai
Trong giai đoạn lên ý tưởng, bạn có thể trao đổi ý tưởng, đối chiếu với cơ sở tri thức và tạo tài liệu thiết kế; ở phần tài liệu hóa, có thể sinh ra phần lớn nội dung tài liệu
Phát triển thì quá rõ, còn ở triển khai nó có thể tạo manifest triển khai, công cụ kiểm thử và tri thức liên quan đến nền tảng đám mây
Mọi giai đoạn đều có thể tốt hơn và nhanh hơn nhờ AI, không phải toàn bộ nhưng là rất nhiều phần
Việc phát triển cũng vậy: có phần là hiểu vấn đề tốt hơn ai hết và tạo ra lời giải, nhưng cũng có phần đơn thuần là việc vặt
Nếu bạn đã biết cái nút phải làm X, thì việc thiết kế nút đó, đặt nó vào đâu, nghĩ đến các ngoại lệ cho trạng thái hover và press rồi nối nó với backend là việc vặt, và nguyên lý đó áp dụng cho gần như mọi giai đoạn
Khi định thêm một tính năng mới quan trọng, thường phải họp với các bên nghiệp vụ trong nhiều ngày, nhiều tuần, thậm chí nhiều tháng để hiểu công việc chảy qua các hệ thống X, Y, Z như thế nào và các ngoại lệ quan trọng là gì
Ví dụ tập con A được xử lý thế này, B được xử lý thế kia, nhưng ở bước cuối thì hai nhóm được gộp lại, trừ khi C cần quy trình đặc biệt số 97
Dựa trên sự hiểu đó mới đến bước thiết kế lời giải hệ thống trải dài qua nhiều hệ thống, pha trộn giữa hệ thống nội bộ và hệ thống của nhà cung cấp, trong khi mức độ tùy biến của từng hệ thống lại khác nhau và kéo hình dạng của lời giải cuối theo nhiều hướng
Tăng tốc việc coding rõ ràng có giá trị, nhưng chỉ là một mảnh của bức tranh, và các LLM hiện tại không giúp được trong việc thu thập kiến thức miền và định nghĩa lời giải
Có thêm một điểm nữa là giờ nhiều vai trò hơn có thể tạo ra công cụ phần mềm để giải quyết những vấn đề mà trước đây họ phải dùng quy trình thủ công để ép xử lý
Chúng tôi là một nhà sản xuất nhỏ nên không phải kiểu dự án doanh nghiệp khổng lồ đòi hỏi kinh nghiệm kỹ thuật phần mềm sâu, nhưng các công cụ phần mềm đơn giản đang cải thiện quy trình và năng suất ở khắp nơi
Khi người phụ trách vận chuyển có thể giải quyết bằng công cụ tùy chỉnh những vấn đề trước đây phải đốt rất nhiều giờ lao động thì thực sự có những điều đáng kinh ngạc xảy ra
Chúng tôi dùng AI rất nhiều trong phát triển phần mềm nhưng không ra mắt nhanh hơn, thậm chí có cảm giác còn chậm hơn vì cùng hoặc những lý do khác
Cảm giác lạ lùng như đang chờ đợi một thế giới utopia xuất hiện nhưng nó không đến, mà cũng khó chỉ ra chính xác vấn đề nằm ở đâu
Ngược lại, chính những bất đồng và sự thiếu tin tưởng này lại tạo ra cơ hội và điểm đột phá trên thị trường
Nếu IQ trung bình của những người tham gia dự án là 140 thì AI có IQ 150 có thể sao chép mọi cá nhân trong pipeline
Những người nói AI không làm được cái này cái kia cần chấp nhận rằng khoảng cách IQ này đang tăng lên một cách đơn điệu
Ở một khía cạnh, đây là một bài viết gọn gàng mô tả rất chính xác điều mà nhiều người làm công việc kỹ thuật trong các tổ chức lớn đang nghĩ và đang thấy ngoài thực địa
Tôi đồng ý với tác giả 110% và mong người khác cũng hiểu được nội dung của bài này
Nhưng ở một khía cạnh khác, cả trên HN lẫn ở chỗ làm thực tế, tôi có cảm giác mình đã có kiểu trò chuyện này hàng chục lần gần đây rồi
Các lãnh đạo có động cơ xã hội và tài chính để giả vờ rằng AI thực sự sẽ tăng tốc, nên họ sẽ không bị thuyết phục chỉ bởi một bài blog
Vì thế giờ tôi chỉ còn biết chờ dự án AI của họ thất bại hoặc chậm chạp như các dự án hiện có, rồi hy vọng họ rút ra điều gì đó
Tôi thậm chí còn ngại chia sẻ những bài như thế này ở công ty, vì cảm giác những nội dung đi ngược với hiện trạng thì không dễ được đón nhận
Tôi cho rằng các tài liệu trực quan và biểu đồ Gantt chính xác là ngôn ngữ kiểu PM mà PM có thể hiểu được
Chừng nào cấp C và nhà đầu tư còn tiếp tục phát tín hiệu đổi mới thì việc này sẽ chưa được giải quyết ngay, nhưng mấy thứ đó cũng không thể kéo dài mãi mãi
Vì vậy dạo này tôi dành thời gian làm vườn và ám ảnh với các dự án code cá nhân bằng các công cụ agentic
Kiểu như tự làm một cơ sở dữ liệu OLTP hiệu năng cao từ đầu, tạo một môi trường lập trình bền vững quan hệ logic mới, hay làm một bộ tổng hợp âm thanh dựa trên toán học kỳ lạ và một soft processor FPGA
Toàn những việc bình thường mà người bình thường vẫn làm thôi
Nên tôi biết những công cụ này có thể làm được gì khi nằm trong tay một người, và thực sự là rất đáng kinh ngạc
Nhưng khi nghe bạn bè đang làm ở công ty kể chuyện đặt ra hạn ngạch token tối thiểu hay lập bảng xếp hạng “ngôi sao coder AI”, rồi “đừng review code”, “đừng code bằng tay”, tôi chỉ biết lắc đầu
Mùa đông vừa rồi tôi nhận thử ít việc hợp đồng, cũng ổn, nhưng khi nhà sáng lập vibe code cả một dự án mới nguyên vào mỗi cuối tuần thì code review thoái hóa thành cảnh các LLM đấu tay đôi với nhau
Những công cụ này không hợp lắm với làm việc nhóm hay kỹ thuật phần mềm đội ngũ thực sự
Tôi định lùi lại quan sát cho đến khi ngành này tự sàng lọc xong
Những nơi đáng để làm việc có lẽ chỉ là những nơi biết nói “cứ chậm thôi!” và có những người lớn tuổi, khôn ngoan đủ sức trụ vững khi nói điều đó
Trong lúc đó, tôi đang bán một bó đại hoàng cắt ở khu Hamilton, Ontario với giá 5 đô
Có cả măng tây nữa, rất nhiều
Có một tính hai mặt khá thú vị
Với những việc tôi vốn đã làm tốt thì LLM tương đối ít ảnh hưởng, nhưng với những việc tôi không làm tốt thì nó là một kẻ thay đổi cuộc chơi khổng lồ
Các công ty lớn có thể tuyển đủ hầu hết các vai trò cần cho dự án nên tác động tổng thể sẽ tương đối nhỏ
Nhiều nhất thì chỉ là một người làm tạm được phần việc của năm người để cắt chi phí nhân sự, đổi lại là một sản phẩm tệ hơn
Tổ hợp giữa lợi ích ngắn hạn và chi phí dài hạn sẽ đi về đâu thì quá dễ đoán
Nhưng với studio nhỏ hoặc indie dev thì LLM là thay đổi lớn
Làm tạm được phần việc của năm người vẫn là một bước nhảy vọt rất lớn so với việc xoay xở mà không có các vai trò đó, hoặc phụ thuộc vào tài sản bên thứ ba hay nội dung khác, hoặc tệ hơn nữa là ứng biến một cách kinh khủng
Chỉ cần nhìn UI của gần như mọi chương trình được sắp xếp bởi một lập trình viên mà không có designer là thấy
Hoặc những trường hợp cố bắt chước thứ gì đó trên Dribbble nhưng kỹ năng không đủ
Dùng AI thì bỗng nhiên có thể sao chép một cách khá thuyết phục mọi thứ và mọi người, mà thực ra đó gần như là toàn bộ cách AI vận hành
Nó nghe như một định nghĩa trong giáo trình
Cá nhân tôi thì hoàn toàn ngược lại
LLM chỉ hữu ích khi tôi đã biết chính xác mình đang làm gì
Mọi người không thực sự hiểu rằng phát triển phần mềm không tầm thường thì coding còn chưa chiếm nổi 50%
Giai đoạn coding thường là phần dễ nhất và được giao cho junior developer
Trong các tổ chức lớn, phần lớn thay đổi của sản phẩm băng qua nhiều hệ thống và cách vận hành của nhiều con người
Senior và mid-level chủ yếu dành thời gian để sắp xếp lại các ưu tiên cục bộ thành một cấu hình mới trong thực thể điều khiển học hiện có, rồi giành sự đồng thuận cho tầm nhìn mới đó từ các đội khác vốn cũng có ưu tiên riêng
Việc này tự nhiên kéo theo rất nhiều đánh đổi và chính trị
Các kỹ sư senior sẽ đấu tranh quyết liệt để tránh làm “nặng” thêm các hệ thống mà họ chịu trách nhiệm, cũng như để ngăn phạm vi bị mở rộng hoặc chệch khỏi hướng tiến hóa mà họ đã định
Vì thế cần có thỏa hiệp, hoặc phải escalte lên ban điều hành để họ chọn ưu tiên
Tôi không biết AI có thể giải quyết được phần này hay không, nhưng đó là việc khó hơn rất nhiều
Giờ nó là người gọi công cụ, nên các agent coding có thể chạy lint, kiểm tra kiểu, chạy test rồi sửa lỗi, đào vào các nền tảng quan sát như Sentry để tìm nguyên nhân gốc, chạy benchmark để tìm code chậm hay hot path, đọc và áp dụng tài liệu migration cho major version mới của thư viện đang dùng để giữ hệ thống luôn cập nhật
Nếu bạn không cấu hình những thứ này để tạo áp lực ngược lên agent và buộc nó hiểu hệ thống tốt hơn, thì nó sẽ chỉ dừng lại ở một LLM viết code ngốc nghếch
Nhưng trong bối cảnh mô hình và harness đang cải thiện rất nhanh, rõ ràng nó có thể đi xa hơn thế rất nhiều
Bài này nhìn chung là đúng, và cũng gợi ý nơi cần tập trung nếu muốn AI thực sự làm quy trình nhanh hơn
Ví dụ, có một quản lý sản phẩm nói rằng họ hình dung về tương lai nơi nếu kết thúc cuộc họp với stakeholder mà không có prototype tương tác thì được xem là thất bại, và tôi thấy hướng đó là đúng
Một điều nữa tôi dự đoán là vibe coding sẽ trở thành “Excel 2.0”
Nó sẽ giúp việc tạo ứng dụng tương tác trở nên khá self-service, rồi IT sẽ bước vào cuộc chiến bất tận để biến chúng thành thứ có bảo đảm bảo mật tốt hơn, kiểm soát truy cập và logging phù hợp, khả năng mở rộng, quản lý thay đổi, v.v.
Ở góc nhìn lịch sử rộng hơn, mọi chuyển dịch mang tính cách mạng lúc đầu đều tạo ra ngựa hơi nước
Khi động cơ hơi nước mới được phát minh, người ta tưởng tượng tương lai của giao thông sẽ là những vật thể hình con ngựa chạy bằng hơi nước kéo các cỗ xe hiện có
Chỉ về sau chúng ta mới hiểu được chức năng của giao thông tách khỏi hình dạng của nó
Ban đầu tôi bắt đầu nói đến ngựa hơi nước khi bàn về MOOC, và MOOC đúng là một ý tưởng ngựa hơi nước điển hình
Làm prototype đâu cần code
Cũng giống như để ghi lại một cảnh phim thì không nhất thiết phải có diễn viên và máy quay, đôi khi chỉ vài bản phác thảo là đủ
Biểu đồ Gantt được đưa ra là ví dụ của mô hình thác nước hoặc một phương pháp luận khác coi phần mềm có một đích đến cuối cùng
99,999% phần mềm ngày nay không được làm theo cách đó
Phát triển phần mềm hiện đại không có điểm đến
Cứ mỗi hai tuần, phía kinh doanh lại thay đổi những gì phần mềm phải làm
Liên tục có tính năng mới, tích hợp mới, tính năng bị thay đổi, thành phần được nâng cấp hoặc thay thế, quy mô lớn hơn, hình thức lưu trữ khác đi
Sau vài năm, phần mềm bị biến dạng tận gốc, còn chất lượng và kiểm thử thì bay ra ngoài cửa sổ
Không chỉ là chuyện xử lý thay đổi bằng các giải pháp chắp vá, mà còn là cuộc khổ sai liên miên chống lại entropy
Phần mềm trở thành một thực thể sống bị thương, lối sống thay đổi và già đi
Công ty trở thành người trông thú chăm một con quái vật, cố giữ cho con vật trầm cảm ấy còn sống
Con người là sinh vật của thói quen nên dùng AI rồi thì tất cả những vấn đề đó vẫn sẽ tái diễn
Chỉ là mọi thứ sẽ nhanh hơn một chút và code review có thể làm code tốt hơn một chút
Đồng thời, sự thiếu vắng kiểm thử tốt và ham muốn triển khai nhanh hơn sẽ làm mọi thứ tệ đi một chút
Kết quả của thế co kéo này là chất lượng phần mềm gần như giữ nguyên nhưng chuyển động nhanh hơn một chút
Cuối cùng quy trình sẽ nhanh hơn, nhưng phần còn lại vẫn khổ sở đến mức chẳng ai cảm nhận rõ lắm
Có lẽ mọi người chỉ kiệt sức nhanh hơn mà thôi
Sự phức tạp tồn tại vì có lý do, và nếu không loại bỏ được lý do đó thì không thể loại bỏ được sự phức tạp
Không thể dùng công cụ để giải quyết vấn đề kinh doanh
Về câu “AI có thể sinh code nhanh, nhưng điều đó không có nghĩa là nó sinh ra code đúng”, theo thực tế thì code gần như luôn đúng
Điều tôi không thích thường là cách code được thêm vào
Nếu hiểu codebase đủ rõ thì sẽ có những nghi thức như phải thêm vào đâu, đặt tên thế nào, chú thích ở đâu và bao nhiêu
Nếu agent không làm đúng thì những người như tôi sẽ bực, và có vẻ như ngay cả khi viết vào AGENTS.md thì nó vẫn thất bại
Còn câu “nếu đưa cho dev con người cùng lượng tài liệu tính năng/phạm vi như vậy thì năng suất sẽ tăng vọt” thì tôi làm trong IT gần 20 năm mà chưa bao giờ tin chuyện đó có thể xảy ra
Dù có xảy ra thì cũng hiếm đến mức không đáng để bàn
Chỉ cần so sánh công sức để sao chép một hệ thống đã được viết sẵn với công sức để xây hệ thống đó từ đầu là thấy
Nó hay hallucinate, đặc biệt khi đầu vào là lỗi hoặc vấn đề hiệu năng, và nếu không cầm tay chỉ việc thì thường chẩn đoán sai
Dù vậy, nếu bạn theo dõi nó làm gì và đẩy nó theo đúng hướng thì nó làm phân tích nguyên nhân gốc và phân tích nói chung khá tốt, hiệu quả cũng cao
So với máy móc, con người có giới hạn về tốc độ tiêu hóa và phân tích thông tin nên tôi nghĩ mức tăng năng suất cũng sẽ có trần
AI không nhất thiết phải vượt qua quy trình, nhưng vẫn có thể tăng tốc
Nó có thể giúp refactor, viết boilerplate, tìm những lỗi chưa từng thấy trước đó, và cả những thứ mà linter không bắt được
Nhiều bình luận có vẻ như hoặc là không dùng các quy trình chuẩn đã được biết đến, hoặc là giả định rằng dùng AI rồi thì không cần theo các chuẩn đó nữa
Có thể phát hành nhiều code và tính năng hơn không? Nếu có yêu cầu tốt và kiểm thử đầy đủ thì tất nhiên là có
Mọi đoạn code do AI viết đều phải được review và test, đồng thời phải tách thành các commit và pull request riêng biệt
Ai đưa lên một PR dài hàng nghìn dòng thì đó là dấu hiệu cảnh báo
Không có AI bạn cũng sẽ không làm vậy, thế tại sao dùng AI lại làm thế
Ngoại lệ hiếm hoi được biết đến là các đợt viết lại lớn hoặc refactor lớn, nhưng ngay cả khi đó tôi vẫn cho rằng nên có các commit riêng lẻ có thể chuyển đổi được để nhìn thấy quá trình thay đổi và đưa ra đánh giá tốt hơn
Nếu ai đưa cho tôi một commit hoặc PR khổng lồ kiểu one-shot thì tôi sẽ từ chối
Nó phải được chia thành các phần mà một developer bình thường có thể kiểm toán được