- CEO GitHub Thomas Dohmke nhấn mạnh tầm quan trọng của năng lực viết code thủ công dù các công cụ AI đang được phổ biến rộng rãi
- Ông cho rằng ngay cả khi AI tạo ra mã, lập trình viên vẫn cần trực tiếp chỉnh sửa và rà soát thì mới hiệu quả
- Nếu chỉ phụ thuộc vào tự động hóa, sẽ có nguy cơ kém hiệu quả thực tế và làm giảm năng suất; khi lạm dụng mã do AI tạo ra như "vibe coding", rủi ro về chất lượng và bảo mật sẽ gia tăng
- Ông giải thích và củng cố bằng các xu hướng, ví dụ trong ngành rằng cách tiếp cận lai giữa AI và lập trình viên con người là hiệu quả nhất
- Vai trò của lập trình viên không biến mất, mà đang tiến hóa theo hướng hợp tác với AI và đòi hỏi năng lực giải quyết vấn đề chiến lược cùng khả năng thiết kế
CEO GitHub nhấn mạnh tầm quan trọng của viết code thủ công trong thời đại AI
CEO GitHub Thomas Dohmke nhấn mạnh tầm quan trọng của việc duy trì năng lực viết code thủ công, dù việc sử dụng các công cụ AI trong môi trường phát triển phần mềm ngày càng lan rộng
- Xuất hiện trên “The MAD Podcast with Matt Turck”, ông giải thích rằng lập trình viên cần có năng lực trực tiếp chỉnh sửa mã do AI tạo ra để tránh suy giảm năng suất
- Một quy trình làm việc hiệu quả là công cụ AI tạo mã và gửi Pull Request, sau đó lập trình viên dùng kỹ năng của mình để chỉnh sửa ngay lập tức
- Ông cũng đề cập rằng nếu chỉ dựa vào các tác nhân tự động hóa, có thể phát sinh kém hiệu quả vì phải tốn thời gian không cần thiết để mô tả các chỉnh sửa đơn giản bằng ngôn ngữ tự nhiên
- Dohmke chỉ ra rằng “cố gắng mô tả bằng ngôn ngữ tự nhiên những việc vốn đã có thể tự làm trực tiếp bằng ngôn ngữ lập trình là lựa chọn kém hiệu quả nhất”
- “vibe coding”, thuật ngữ do đồng sáng lập OpenAI Andrej Karpathy nhắc đến để chỉ sự phụ thuộc quá mức vào mã do AI tạo ra, cũng là điều mà Dohmke cảnh báo cần thận trọng
Insight và xu hướng ngành
1. Giải pháp tối ưu cho AI coding là chiến lược lai
- Góc nhìn của Dohmke phù hợp với đồng thuận trong ngành rằng cách tối ưu là kết hợp tự động hóa bằng AI với kỹ năng lập trình của con người
- Theo nghiên cứu của Deloitte, các lập trình viên chủ yếu dùng công cụ AI để viết boilerplate code, nhưng vẫn giữ khâu rà soát cuối cùng của con người, nhờ đó tăng năng suất khoảng 10~20 phút
- Khoảng một nửa mã do AI tạo ra có lỗi một phần, nên chiến lược “tin tưởng nhưng phải xác minh” đang trở thành tiêu chuẩn trong ngành
- Google hiện có hơn 25% tổng số mã được AI tạo ra, nhưng kinh nghiệm của họ cho thấy quy trình rà soát và cải tiến tích cực từ lập trình viên vẫn là điều bắt buộc
- Cách tiếp cận cân bằng này phản ánh việc ngành đang trưởng thành theo hướng nhìn nhận đúng giới hạn của AI, đồng thời xem chuyên môn của lập trình viên là yếu tố được tăng cường chứ không bị thay thế
2. Vai trò lập trình viên đang thay đổi chứ không biến mất
- Thay vì làm nghề lập trình biến mất, AI đang khiến vai trò của lập trình viên chuyển từ coder thuần túy sang người quản lý quy trình phát triển dựa trên AI
- Các chuyên gia dự đoán lực lượng phát triển sẽ phân hóa thành kỹ sư sản phẩm tận dụng AI và kiến trúc sư cấp cao đảm bảo chất lượng/bảo mật của hệ thống
- Sự thay đổi này đồng nghĩa với nhu cầu về các năng lực mới như cách sử dụng AI hiệu quả, khả năng giải quyết vấn đề mang tính chiến lược và năng lực thiết kế ở cấp độ cao
- Cùng với tình trạng thiếu hụt kỹ sư phần mềm, hiệu quả hỗ trợ lập trình viên junior của công cụ AI đã được chứng minh, qua đó cũng mở ra cơ hội tăng trưởng mới cho các lập trình viên giàu kinh nghiệm
- Điều này cho thấy tương tự như khi các công cụ phát triển và công nghệ trừu tượng hóa từng xuất hiện trước đây, sự sáng tạo của con người vẫn là yếu tố cần thiết
3. Thế lưỡng nan năng suất-chất lượng của “vibe coding”
- Hiện tượng “vibe coding” là một xu hướng phơi bày lợi ích năng suất và giới hạn về chất lượng/bảo mật của mã do AI tạo ra
- Các công cụ AI hỗ trợ tạo prototype nhanh và phát triển lặp, nhưng đồng thời cũng làm gia tăng lo ngại về suy giảm chất lượng mã và rủi ro bảo mật
- Trong thực tế, đã có những trường hợp phát sinh lỗ hổng bảo mật do sử dụng mã AI mà không được kiểm chứng
- Ở các startup như startup do nhà sáng lập không chuyên kỹ thuật dẫn dắt, việc lạm dụng mã AI có thể tích tụ technical debt và dẫn tới cản trở tăng trưởng dài hạn
- Theo kinh nghiệm từ các công ty IT lớn, cân bằng giữa tự động hóa và quản lý chất lượng nghiêm ngặt là cốt lõi của việc áp dụng AI, và bài học này cũng quan trọng với startup
1 bình luận
Ý kiến trên Hacker News
Tôi rất thắc mắc vì sao mọi người không còn nói về độ phức tạp bản chất của hệ thống nữa
Trong No Silver Bullet của Fred Brooks, ông chỉ ra rằng khó khăn thực sự của kỹ nghệ phần mềm đến từ việc hiểu, làm rõ và mô hình hóa không gian vấn đề cốt lõi. Độ phức tạp ngẫu nhiên như giới hạn của công cụ chỉ là thứ yếu
Gần đây có rất nhiều câu chuyện về việc agent AI sẽ tạo ra toàn bộ codebase bằng prompt ngôn ngữ tự nhiên thay cho kỹ sư. Nhưng giả định đó là một sự ngộ nhận rằng bài toán đặc tả (specification) đã được giải quyết sẵn. Trên thực tế, việc biến một ý tưởng mơ hồ thành một hệ thống chi tiết và vững chắc vẫn là vai trò cốt lõi của kỹ sư
Nếu ai đó cung cấp đặc tả chi tiết và làm việc lặp đi lặp lại với AI để tạo phần mềm, thì về bản chất đó là dùng AI để loại bỏ độ phức tạp ngẫu nhiên. Điều này giống như khi lập trình viên chuyển từ assembly sang ngôn ngữ bậc cao. Nó không thay thế kỹ sư mà chỉ nâng cao năng suất. Nó cũng giảm chi phí của công việc lặp lại và tạo cơ hội mở rộng tầm ảnh hưởng hơn
Nếu agent có thể tạo ra sản phẩm chỉ bằng prompt, thì đó là vì đã có ai đó định nghĩa hệ thống một cách rõ ràng từ trước. Và nếu AI chỉ sao chép các sản phẩm hiện có, thì đó không phải giải quyết vấn đề kỹ thuật mà là cạnh tranh về phân phối hay chi phí, tức là đổi mới kinh doanh chứ không phải đổi mới kỹ thuật.
Tôi tự hỏi liệu mình có đang bỏ sót điều gì không
Cốt lõi là vì sao công việc đặc tả (specification) đã bị xem nhẹ từ rất lâu trước khi AI xuất hiện
Các bên liên quan như khách hàng hay quản lý từ trước đến nay vẫn thường chỉ đạo kiểu mơ hồ, cảm tính rồi bảo người khác đi code. Chỉ cần mô tả sơ sài là sẽ có ai đó kỳ diệu đưa ra một giải pháp phù hợp. Không ai thực sự biết giải pháp đó có hoạt động hoàn chỉnh hay không. Thường chỉ thấy có vẻ chạy được ở mức nào đó nên cho qua
Trong đa số trường hợp, lập trình viên là người cụ thể hóa dựa trên kiến thức miền của mình, ví dụ họ bản năng biết một trang submit form đúng chuẩn nên trông như thế nào
Giờ chỉ là phía đối diện được thay bằng AI, còn việc cách làm này có thể lặp lại y nguyên hay không thì vẫn phải chờ xem
Phân biệt giữa độ phức tạp bản chất/độ phức tạp ngẫu nhiên là một insight cực kỳ quan trọng khi suy nghĩ xem AI có thể đảm nhận phần nào của phát triển phần mềm
Nhiều lập trình viên không diễn đạt được thành lời vì sao họ sẽ không bị AI thay thế, nhưng trực giác của họ nằm đúng ở điểm này
Thực tế tôi cũng đã thử để các agent như Claude xử lý vấn đề trong codebase lớn cực kỳ phức tạp, nơi logic kinh doanh bên ngoài đan xen chặt chẽ. Nhưng AI không thể trực giác đúng về yêu cầu kinh doanh hay bối cảnh, nên không thể làm các thay đổi code mang tính kinh doanh. Nó chỉ giúp được những thay đổi code có ngữ cảnh hẹp. Tức là nó chỉ xử lý được độ phức tạp ngẫu nhiên, còn việc chuyển yêu cầu thực thành hệ thống, tức vai trò thật sự của lập trình viên, thì nó vẫn có giới hạn
Nói thêm, trên thực tế thứ nhiều lập trình viên đang giải quyết có thể không phải vấn đề kỹ thuật mà là vấn đề phân phối/thị trường. Việc thay thế junior bằng AI hiện vẫn đáng lo. Vấn đề lớn nhất là AI chưa thể tự hiệu chỉnh một cách độc lập. Dù vậy, các doanh nghiệp dựa trên AI vẫn sẽ tiếp tục xuất hiện để tìm cách hạ chi phí của mô hình kinh doanh hiện có. Việc thay đổi đó là tốt hay xấu thì với người bị mất việc cũng chẳng có nhiều ý nghĩa
Có một câu trả lời cho câu “Liệu mình có đang bỏ sót điều gì không?”
Thực sự có rất nhiều lập trình viên không biết dùng phần mềm. Những người này sẽ rất dễ bị AI thay thế
Trong giai đoạn trước tôi làm việc với JavaScript, và những người làm được điều thật sự ấn tượng chỉ là những người đã tự mày mò lập trình như một sở thích. Ở công ty, đa số mọi người còn chật vật chỉ để hiển thị văn bản lên màn hình. Không đùa đâu
Nhiều người lao vào các framework khổng lồ nhưng cuối cùng chỉ ở mức copy-paste cho chạy tạm. Họ giả vờ như đang giải quyết độ phức tạp cao cấp, nhưng phần lớn chỉ là việc thừa hoặc khoe code
Gần như không có năng lực tạo ra app nguyên bản, viết tài liệu hay đo lường khả năng sử dụng thực tế
Giải quyết điều này thế nào ư? Hãy áp dụng một tiêu chuẩn cao như kỳ thi hành nghề luật sư, mạnh tay loại những ai không đạt chuẩn và chỉ tuyển họ ở vai trò junior hay học việc thì thế hệ lập trình viên mới có thể phát triển đúng hướng
Câu trả lời dễ hiểu cho phần “điều đang bị bỏ sót” là: không ai trong ngành đọc "No Silver Bullet"
Những người viết về technical debt hay kiến trúc hệ thống thường không phải là người ra quyết định thực sự chi phối team hay doanh nghiệp, và các cuốn sách đó với kỹ sư cũng chỉ là thứ tùy chọn
Những người dẫn dắt câu chuyện thay thế việc code bằng AI thường không phân biệt được giữa việc làm MVP và việc mở rộng codebase trong 10 năm cũng như cải thiện legacy
Ví dụ, có một quản lý từng đưa ra đề xuất sai lầm rất điển hình là chia 33% thời gian cho 3 dự án mỗi ngày. Việc phân bổ nhân sự hay cấu trúc thời gian lẽ ra phải là năng lực của quản lý, nhưng cuối cùng người xử lý cho ra hồn vẫn là kỹ sư
Giờ thì những quản lý như vậy lại đề xuất kiểu “hãy để AI giải quyết toàn bộ technical debt/test”, và khi không làm được thì người phải giải thích vẫn là kỹ sư
Câu chuyện về độ phức tạp thực chất chỉ là sự lặp lại của vấn đề quản lý yếu kém. Phần lớn kỹ sư dày dạn kinh nghiệm vốn đã không tin công việc của họ sẽ bị thay bằng những prompt đơn giản
Điều chúng ta thực sự nên nói là: “kỹ nghệ phần mềm có vấn đề nghiêm trọng về quản lý, và AI chỉ làm nó lộ rõ hơn”
Nhiều người không phải lập trình viên hoặc sinh viên cảm thấy phát triển phần mềm là phải học cách dùng những công cụ phức tạp, và họ bị hấp dẫn bởi lời hứa rằng “chỉ cần viết đặc tả tốt là ai cũng có thể làm phần mềm” (còn chuyện bản thân năng lực đặc tả đã rất khó và cần công nghệ hỗ trợ thì lại bị lờ đi)
No-code trước đây cũng theo kiểu này, và thực tế công cụ no-code rất hạn chế; càng mạnh thì càng phức tạp và đòi hỏi học tập chuyên môn nhiều hơn
Luận điểm thay thế SWE bằng LLM rốt cuộc cũng chỉ là một phiên bản của ý tưởng “thay vì học hệ thống, chỉ cần prompt bằng ngôn ngữ tự nhiên rồi model sẽ tự dùng công cụ”
Nhìn theo cách này, cái gọi là vibe coding hiện nay thực ra là đỉnh điểm của mục tiêu đó, dù vẫn có những điểm yếu thực tế như khả năng bảo trì
Theo tôi, một trong những lý do quản lý muốn loại bỏ SWE là vì họ không thể giao tiếp hiệu quả với SWE
Dùng LLM thì họ cảm thấy có thể giao tiếp với máy móc mà không cần “nerd/lập trình viên”, nên họ cho rằng như vậy là đã giải được vấn đề
Ngôn ngữ lập trình là phương tiện phù hợp cho đặc tả chính xác của chương trình mong muốn. Ngôn ngữ tự nhiên thì không bao giờ có được mức độ rõ ràng đó
Vì vậy việc review và chỉnh sửa kết quả do AI tạo ra là điều hiển nhiên. Có lúc tự tay sửa còn dễ hơn giải thích thay đổi cần làm
Tôi cũng tự hỏi liệu các nghiên cứu độc lập cho thấy Copilot làm tăng tỷ lệ lỗi có phải là yếu tố tự nhiên khiến thái độ thận trọng lan rộng hơn hay không
Những người bán AI thường hay khẳng định rằng tác giả con người sẽ sớm không còn cần thiết nữa
Transformer có thể áp dụng vào nhiều việc như test tự động, mở rộng đặc tả, tăng tốc dự án mới, khám phá API chưa biết, dựng tính năng ban đầu, review code, v.v.
Ngay cả khi thừa nhận code là phương tiện đúng cho đặc tả, Transformer vẫn đóng vai trò là giao diện tự động giữa ngôn ngữ tự nhiên và phương tiện đó là code
Gần đây Transformer không gặp vấn đề gì với việc sinh code nhờ lượng kiến thức khổng lồ
Cũng như con người luôn theo đuổi tự động hóa trong lập trình, Transformer là một bước nhảy vọt rất lớn
Vào một thời điểm nào đó trong tương lai, việc AI thay thế lập trình viên có thể trở thành hiện thực, giống như máy dệt tự động, kỹ thuật in hay máy tính điện tử từng thay thế lao động của con người
Tuy nhiên điều đó có thể chưa xảy ra ngay bây giờ, hoặc thậm chí trong 10 năm tới; vẫn còn những bài toán như hallucination, độ chính xác, công cụ hóa, xây dựng hạ tầng
Việc còn hay mất việc làm lập trình còn có thể khác nhau tùy domain, kỹ năng và kỳ vọng thu nhập
Điều quan trọng là phải nghiêm túc tiếp nhận công cụ AI và thích nghi. Nếu không, rất dễ bị tụt lại như khi máy tính cá nhân hay Internet được phổ cập
Tôi cho rằng tính giả-sáng tạo của AI có giới hạn
Nếu toàn bộ kết quả học từ LLM lại chỉ quay vòng thành đầu vào cho LLM, thì phạm vi ý tưởng mới sẽ không bao giờ thật sự mở rộng
Trong khi đó con người vẫn liên tục thể hiện sự sáng tạo vượt ra ngoài phạm vi đó
Có thể trong tương lai LLM sẽ vượt qua bức tường này, nhưng hiện giờ thì nó chưa khác mấy so với “con khỉ gõ máy chữ”
Theo kinh nghiệm của tôi, LLM hiệu quả nhất khi được dùng như scaffolding
Tôi đổ toàn bộ ý tưởng tính năng mình muốn làm ra cho nó, rồi yêu cầu tạo model và controller cơ bản cần thiết cho model đó
Phần còn lại tôi chỉ cần tập trung vào view và logic kinh doanh thực tế nên việc phân chia công việc khá rõ ràng
Tôi nhớ rằng khi ngôn ngữ bậc cao mới xuất hiện, ở giai đoạn cực kỳ đầu cũng từng có những chỉ trích tương tự với LLM hay code bằng ngôn ngữ tự nhiên bây giờ, kiểu như “khó điều khiển trực tiếp bộ nhớ nên thiếu độ chính xác”
Vấn đề không phải là ngôn ngữ tự nhiên không thể có tính chính xác, mà là đa số mọi người mô tả yêu cầu một cách không chính xác, hoặc chỉ rõ điều mình muốn chứ không giải thích đúng điều máy tính thực sự phải làm
Kết quả là kỹ sư phải đoán rất nhiều khi chuyển yêu cầu kinh doanh, hoặc LLM lặp lại vai trò đó nhưng lại hiểu được còn ít ngữ cảnh hơn
Cách dùng AI tốt nhất là giữ cho tôi không bị khựng lại ở những API tôi chưa từng thấy hoặc những tính năng phiền phức không muốn tự làm, để duy trì trạng thái flow
AI có thể nhanh chóng và hiệu quả áp dụng mẫu chung trên toàn bộ code, nhưng về bản chất nó không tự biết mình đang làm gì
Chia sẻ một trải nghiệm gần đây: tôi đã thử để LLM refactor đoạn code liên quan đến tính kích thước popup và định vị
Một chỗ viết bằng "if", một chỗ bằng "switch", nhưng LLM hoàn toàn không phản ứng linh hoạt trước việc hai cách đó khác nhau, và dù tôi đã giải thích rõ thì nó vẫn thống nhất cả hai chỗ thành if hoặc switch
LLM có xu hướng tiếp tục duy trì mẫu của các token trước đó
Ở đây thì không thành vấn đề lớn, nhưng trong tình huống phức tạp hơn một chút, nó sẽ bỏ qua sự tinh tế và đưa ra đoạn code chỉ có vẻ hợp lý trên bề mặt
Thay vào đó, nếu chia nhỏ và ra lệnh rõ ràng, LLM khá hiệu quả. Ví dụ như chỉ thị “lưu kích thước vào
m_StateStoragerồi áp dụng ở bước render” thì nó làm rất dễĐặc biệt nếu đi cùng các model như Cerebras có thể xử lý nhanh cả vài kilobyte code, thì còn nhanh hơn nhiều so với việc tôi tự gõ ý tưởng của mình thành code thực tế
Cuối cùng thì thứ chúng ta đang đánh giá hôm nay chỉ là lời phê bình giới hạn trong hiệu năng hiện tại của mô hình Transformer
Ngành này thay đổi quá nhanh nên giới hạn của hôm nay có thể thành vô nghĩa chỉ sau một tháng
“LLM” cũng là một cách gọi mơ hồ nếu xét nghiêm ngặt. Các mô hình Transformer mới nhất là đa phương thức và xử lý nhiều dạng dữ liệu chứ không chỉ văn bản
Vì vậy nếu muốn phê bình thì nên chỉ rõ model/công cụ/paradigm nào để cuộc thảo luận có hiệu quả thực tế hơn
Về các kết quả nghiên cứu nói rằng “thiếu kỹ sư phần mềm” và “AI đặc biệt hữu ích cho lập trình viên junior”
Trong dòng thời gian thực tế nơi tôi đang sống, thị trường việc làm công nghệ đang tệ nhất có thể, và AI ngược lại còn lấy mất kinh nghiệm ở những nơi junior cần được trưởng thành, nên tác động bất lợi nhiều hơn
Gần đây tôi có một trải nghiệm thú vị với Claude. Trong Zed, tôi ra lệnh “hãy sửa lỗi ở dòng 71”, thì nó lại đi đổi mấy thứ format vô ích ở dòng 91
Cảm giác như đang chơi trò truyền miệng với LLM vậy
Với những chỉnh sửa đơn giản thế này thì tự làm còn nhanh hơn. Trải nghiệm đó lại càng củng cố cảm giác “LLM thực sự không suy nghĩ”
LLM nhận diện số dòng cực kỳ kém
Từ trải nghiệm này tôi rút ra bài học là “LLM không biết đếm số dòng”
Lần sau có lẽ sẽ tốt hơn nếu nói kiểu “hãy sửa lỗi trong hàm XYZ” hoặc dán trực tiếp dòng đó vào để ra lệnh
Và dĩ nhiên, LLM không suy nghĩ. Nó chỉ là một phương trình khổng lồ mà thôi
Có vẻ trong thread này có khá nhiều người đang lần đầu thử code với AI
Cũng có thể là lỗi của người vận hành
Cần cung cấp ngữ cảnh phù hợp cho LLM. Số dòng là một loại ngữ cảnh không phù hợp
Theo tôi, vai trò của kỹ sư phần mềm là biến yêu cầu thành phần mềm
Phần mềm không chỉ đơn thuần là code, và yêu cầu cũng không chỉ được đưa ra bằng ngôn ngữ tự nhiên đơn giản
Ở thời điểm hiện tại, ngay cả khi làm việc cùng AI thì tôi cũng không nhanh hơn AI bao nhiêu, trừ các tác vụ đơn giản hay phần mềm quy mô nhỏ
AI hiện tại theo tiêu chuẩn của tôi chỉ ở mức junior/mid-level
Trong 2 năm gần đây, AI không mang lại cảm giác đã tiến bộ đột phá thêm bao nhiêu
Phần lớn yêu cầu không được tài liệu hóa rõ ràng
Gần như cũng chẳng có ai thực sự biết logic kinh doanh là gì
Vì vậy kỹ sư phần mềm thường phải tự đi hỏi để tìm ra
Nó cũng đòi hỏi kinh nghiệm và trực giác để suy nghĩ về hướng phát triển của phần mềm và cách thiết kế sao cho đảm bảo khả năng mở rộng đó
Tôi không thể hình dung LLM có thể đảm đương nổi dù chỉ một phần vai trò này
Tôi chưa từng thấy một dự án phần mềm nào có yêu cầu rõ ràng ngay từ đầu
Một nửa dự án là để ‘xác định xem thực sự người ta muốn gì’
LLM hiện vẫn chưa đạt cả mức junior
Nếu AI hiện có trong công ty bạn thật sự ở mức lập trình viên mid-level, thì đó là vấn đề tuyển dụng của công ty bạn
Một trong những ưu điểm lớn nhất của máy tính là tự động hóa đáng tin cậy và có tính lặp lại cao
Các ngôn ngữ hình thức như ngôn ngữ lập trình có thể truyền đạt yêu cầu tự động hóa mong muốn một cách rõ ràng, không mơ hồ
Ngôn ngữ tự nhiên thì không đạt được mức chính xác đó
Ground truth thật sự của chương trình cuối cùng vẫn là code
Nếu con người muốn kiểm soát chính xác hành vi của chương trình, thì năng lực hiểu và sửa được code mới là điều quan trọng nhất
Từ “manual” có sắc thái tiêu cực
Ý của bài báo đó có lẽ là “việc code do con người thực hiện vẫn là cốt lõi”
Tôi không chắc CEO GitHub có thật sự dùng từ "manual" hay không. Sẽ tốt hơn nếu có nguồn bài viết dùng cách diễn đạt trung tính hoặc chính xác hơn
Việc hạ thấp coding của con người thành “manual” là không phù hợp. Các lập trình viên con người cũng dùng rất nhiều bộ công cụ tự động hóa ngoài AI
Nó tiêu cực gần như kiểu “tư duy thủ công” vậy
Tôi mới biết “manual” có hàm ý tiêu cực như vậy
Không rõ dạo này mọi người có ác cảm đến thế với công việc thủ công hay không
Tôi tò mò không biết khác biệt giữa “manual coding” và “human coding” là gì
“Chỉ dựa vào agent AI có thể kém hiệu quả”
Ví dụ, nhiều khi chỉnh code trực tiếp còn nhanh hơn việc mô tả dài dòng bằng ngôn ngữ tự nhiên cho một thay đổi đơn giản
Vì vậy tương tác chủ động với agent AI có lẽ sẽ là workflow tối ưu
Nhiều lúc đang nghĩ cách diễn đạt thay đổi bằng ngôn ngữ tự nhiên thì ngay trước cả khi gõ xong, tôi đã nảy ra cách sửa trực tiếp mà mình cần
Có vẻ những thay đổi nhiều ngữ cảnh thì bản thân tôi vẫn sửa nhanh hơn agent
Tôi tò mò không biết mức độ tương tác chủ động nào là hợp lý
Gần đây tôi gia nhập một startup làm tooling cho agent, và trong nội bộ bọn tôi bàn rất nhiều về chuyện này
Tôi nghĩ việc liên tục phản hồi cho agent kiểu “thật lòng mà nói, chỗ này bạn làm chưa tốt!” là chấp nhận được, nhưng có những phần cũng dễ thành mệt mỏi
Muốn nghe thêm suy nghĩ của mọi người, hoặc tưởng tượng/phản hồi về workflow
AI hiện vẫn chưa đạt tới mức kỳ vọng
Ví dụ, tôi thường xuyên khổ sở vì tài liệu tham chiếu hay đặc tả sai. Có vẻ điều này là vì AI được huấn luyện trên dữ liệu cũ và thiếu khả năng cập nhật theo thời gian thực
Các giải pháp LLM và GI hiện có cố giải toàn bộ bài toán nhiều bước (n-step) trong một lần nên lại làm giảm hiệu quả
Chỉ cần xử lý thật tốt từ bước 1 đến bước i thôi thì với con người cũng đã hữu ích hơn nhiều
Tôi vẫn chưa thấy giải pháp AI hoàn toàn mô-đun như mình mong muốn, ví dụ phản ánh phong cách GitHub của tôi và chỉ tham chiếu các resource a, b, c để giải bài toán x
Ngoài ra, tôi mong sẽ có một AI coding biết khám phá vấn đề theo tuần tự, liên tục đặt thêm câu hỏi và đối thoại trong suốt quá trình
Tôi thấy khá ấn tượng khi có một CEO đưa ra góc nhìn hơi khác về AI và coding
Thông thường CEO hay nhà đầu tư thường dự báo vai trò lập trình viên sẽ thu hẹp, với các câu như “hơn 30% toàn bộ code được AI viết”, nhưng chẩn đoán ở đây là thực chất vẫn chỉ là cùng những lập trình viên đó dùng công cụ để viết code nhanh hơn
Nhấn mạnh rằng bản thân việc viết code chỉ là một phần trong công việc phát triển phần mềm