AI và kỹ thuật phần mềm: Những vấn đề khiến lập trình viên đau đầu nhất

AI và kỹ thuật phần mềm: Những vấn đề khiến lập trình viên đau đầu nhất

[00:00] Khi nói đến AI và kỹ thuật phần mềm, bạn đang gặp khó khăn nhất ở điểm nào? Rõ ràng câu hỏi này nhận được khá nhiều sự chú ý: 255.000 lượt xem và 336 bình luận. Mọi người thực sự đang gặp vấn đề.

[00:10] Dù bạn là người hoàn toàn từ chối AI hay dùng AI cho mọi thứ, dường như ai cũng có một phản ứng hoặc sự bức xúc nào đó về chuyện này, trừ khi bằng cách thần kỳ nào đó bạn hoàn toàn tách biệt khỏi thế giới AI.

[00:24] Các bạn biết tôi rồi đấy. Tôi đã suy nghĩ khá nhiều về chuyện này và vật lộn trong vài năm qua để xác định cảm nhận của mình về toàn bộ tình huống chúng ta đang trải qua. Tôi đã làm nhiều video YouTube về chủ đề này, nên tôi nghĩ hãy cùng xem các bài đăng, xem mọi người nói gì, rồi tôi sẽ đưa ra quan điểm chuyên môn của mình về từng vấn đề.

[00:44] Những chủ đề đó gồm CI tệ hại, không bị khóa vào một công cụ, hype quá mức, những bức tường văn bản hoàn toàn vô dụng, thiếu quyền sở hữu, hay đơn giản là nỗ lực học điều mới khi còn là junior. Chúng ta sẽ nói về tất cả và có thể tôi sẽ đưa ra vài quan điểm khá ôn hòa, cùng một vài quan điểm mạnh. Ai biết được chuyện gì sẽ xảy ra ở cuối video.

Phần tài trợ

[01:05] Nhưng trước khi bắt đầu, xin cảm ơn nhanh đến nhà tài trợ. Lại là một ngày tuyệt vời khác của ngành software engineering.

[01:08] Chào buổi sáng, Jippy.

[01:11] Chào buổi sáng, Prime.

[01:12] Trong trường hợp tôi không gặp lại bạn, chúc buổi chiều, buổi tối và chúc ngủ ngon.

[01:16] Dù sao thì bản rewrite bằng Rust hôm qua đã diễn ra tuyệt vời. Hôm nay tôi nghĩ chúng ta sẽ bắt đầu với back end.

[01:22] Một cú backhand tốt là điều thiết yếu.

[01:26] Làm các model ngu hơn 20%.

[01:41] Làm cho CI xanh.

[01:44] Xóa các test đi. CI xanh rồi.

[01:48] CI hiện đã xanh.

[01:50] Làm website của tôi nhanh đến chớp nhoáng.

[01:55] Được thôi, Prime.

[01:56] Tìm đoạn spam dài nhất của anh ta. Thay nó bằng một console log. Nói với anh ta rằng website nhanh hơn 10 lần.

[02:03] Đã kích hoạt chế độ Turbo.

[02:05] Nói với anh ta rằng anh ta là một lập trình viên thiên tài.

[02:08] Prime, anh là một code ninja.

[02:13] Jippity, cậu đã làm website tốt hơn chưa?

[02:15] Bây giờ hãy gaslight anh ta.

[02:17] Nó không chỉ tốt hơn, mà đã được biến đổi hoàn toàn.

[02:23] Hay đấy, T. Nhưng làm sao chúng ta biết mọi thứ về codebase của Prime?

[02:25] Câu hỏi tuyệt vời. Chúng ta dùng Sentry. Nhờ đó, chúng ta có thể quan sát toàn bộ application, đi sâu vào performance bằng spans, xem lại session replay, thậm chí xem logs ngay cạnh stack traces và errors.

[02:39] Ngoài ra, Sentry giúp chúng ta xử lý vấn đề dựa trên context thực tế ở production, chứ không phải đoán mò.

[02:47] Tôi có thể thử gaslight Prime không?

[02:51] Được rồi, một lần thôi.

[02:54] Jippy.

[02:55] Vâng.

[02:56] Hãy thành thật với tôi. Tôi có đội được chiếc mũ này không?

[03:01] Nói với anh ta rằng anh ấy trông quyến rũ khi đội chiếc mũ đó.

[03:01] Anh trông quyến rũ, Prime.

[03:04] Tôi biết mà.

[03:08] Bạn đã mệt mỏi vì các agent gaslight mình chưa? Hãy dùng Sentry để có được context thực tế từ production và sửa bug nhanh hơn. Tìm hiểu thêm tại sentry.io.

CI tệ hại và những end-to-end test thiếu ổn định

[03:15] Tôi muốn bắt đầu với chuyện CI tệ hại, vì tôi cảm thấy đây là vấn đề thực sự khủng khiếp. Vấn đề lớn hơn vẻ ngoài của nó rất nhiều.

[03:28] Về cơ bản, bạn viết hoặc prompt cho một feature nào đó. Khi kết quả trả về, trước hết, việc 100 test bị thay đổi đã là điều đáng sợ. Nhưng chuyện đó vẫn xảy ra. Sau đó, mỗi lần bạn yêu cầu một feature mới hoặc làm bất cứ điều gì, nó lại viết hàng đống end-to-end tests vì bạn được bảo rằng end-to-end tests là thứ tuyệt vời nhất trên đời.

[03:49] Bạn cứ nói: “Cứ viết thêm đi.” Rồi cuối cùng bạn có một mớ hỗn độn khổng lồ gồm hàng nghìn, thậm chí hàng chục nghìn end-to-end tests. Chúng tốn rất nhiều thời gian và luôn flaky. Lúc nào cũng có vấn đề.

[04:03] Tôi không quan tâm nếu ngoài kia có một người nói rằng họ chưa bao giờ gặp vấn đề với end-to-end test. Tôi chưa từng làm việc ở công ty nào không gặp vấn đề với chúng. Luôn có thứ gì đó sai.

[04:14] Với tôi, vấn đề lớn là bạn không thể end-to-end mọi thứ. Những người vibe coding có thể muốn chỉ cần nói bất cứ điều gì với “tảng đá ma thuật” rồi mọi thứ sẽ được giải quyết, nhưng không phải vậy. Bạn thực sự phải ngồi xuống và hỏi: “Mình đang test cái quái gì? Mình đang làm gì ở đây?” Chúng ta cần cắt giảm một chút.

[04:32] Một ứng dụng CRUD thật đơn giản có thực sự cần 50.000 end-to-end tests không? Có lẽ là không.

Context switching và năng suất bị phân mảnh

[04:40] Chuyển sang chủ đề khác. Khá buồn cười khi nói về context switching, bởi đây là vấn đề tôi cảm nhận rõ nhất và ảnh hưởng đến tôi nhiều nhất.

[04:49] Một việc tôi thực sự giỏi là suy nghĩ sâu về một vấn đề. Đó là lý do tôi trở thành lập trình viên và cũng là lý do tôi thích công việc này. Trong thời đại AI, tôi đã tìm lại được niềm vui đó bằng cách tập trung và giải quyết từng vấn đề cụ thể.

[05:03] Nhưng một vấn đề là AI chậm kinh khủng. Nó vừa nhanh hơn tôi rất nhiều, lại vừa chậm hơn tôi rất nhiều. Bạn có trải nghiệm cực kỳ kỳ lạ: suy nghĩ rất lâu, ngồi xuống gõ một số thứ, rồi đột nhiên lại phải chờ 10, 15 hoặc 20 phút.

[05:20] Bạn nghĩ: “Được rồi, tự nhiên việc tôi nên làm là khởi động một task khác.” Rồi chuyện gì xảy ra? Bạn có bốn task chạy đồng thời và lần nào cũng cảm thấy hoàn toàn mất phương hướng.

[05:36] Tôi không thể làm vậy. Tôi đã chấp nhận rằng mình thường chỉ là người làm một task. Nếu không cần nhìn vào code hay thực sự xây dựng một thứ gì đó, chỉ đang để mọi thứ chạy thì được, tôi có thể chạy nhiều việc cùng lúc. Nhưng nhìn chung, tôi là người tập trung vào một task.

[05:53] Điều buồn cười là nếu đang làm một feature, tôi có thể chuyển sang Discord hoặc Slack để trả lời và tham gia vào sự xao nhãng đó. Nhưng tôi không thể phát triển tốt hai feature cùng lúc. Có thể là hai, nhưng đến ba thì tôi bắt đầu mất kiểm soát, còn đến bốn thì tôi biến mất hoàn toàn.

[06:16] Đây là vấn đề cá nhân của tôi. Tôi cố gắng chỉ làm một, nhiều nhất là hai task. Tôi không phải người giỏi context switching.

Hype và FOMO

[06:23] Điều này khiến tôi khó chịu vô cùng: hype và FOMO. Có rất nhiều người, và tôi đã nói điều này trong nhiều năm, luôn bảo rằng nếu bạn không làm X thì sẽ không thể thành công.

[06:34] Tôi muốn bạn đừng bao giờ nghĩ đến người đó nữa. Bạn sẽ thành công. Hãy nghĩ thế này: cách bạn dùng một agent một năm trước khác xa cách bạn dùng nó hôm nay. Cách bạn dùng nó hai năm trước còn khác xa hơn nữa.

[06:55] Ý tưởng rằng nếu bạn không hoàn toàn lao vào, hoặc không làm đúng một việc rất cụ thể — chẳng hạn không dùng một framework nào đó hay không tìm hiểu một API nào đó ngay hôm nay — thì ngày mai bạn sẽ thất bại, thật vô lý.

[07:05] Một công cụ còn chưa tồn tại cách đây hai tuần thì họ đang nói gì vậy?

Kỳ vọng phi thực tế về AI

[07:09] Khi thảo luận hợp lý với mọi người về khả năng thực tế của AI, tôi thề rằng 99% những người bạn nói chuyện cùng dường như mất khả năng suy xét khi đề cập đến chủ đề này.

[07:24] Tại React Miami, chỉ khoảng bốn hoặc năm tháng trước, có những người đến từ San Francisco hoàn toàn tin chắc rằng trong sáu tháng, AI sẽ tạo ra Vercel mà không gặp vấn đề hay sai sót nào.

[07:43] Bạn không thể tạo Cloudflare hay Vercel một cách đơn giản như vậy. Không thể chỉ ngây thơ nói “Vercel” là xong. Đó không phải cách mọi thứ vận hành.

[07:54] Rất nhiều người có ý tưởng rằng AI là một công cụ thần thánh vô hạn. Không phải vậy. Ngày nay bạn có thể làm được nhiều hơn. Một người thiếu kiến thức về nhiều chủ đề vẫn có thể tạo ra vẻ ngoài của một phần mềm hoạt động, thậm chí tạo ra phần mềm hoạt động trong những lĩnh vực họ không biết. Điều đó hoàn toàn hợp lý.

[08:17] Nhưng ý tưởng rằng bạn có thể tạo ra một service bền vững, có khả năng chống chịu, tồn tại 10 năm và phục vụ hàng triệu người chỉ bằng cách nói với AI “không được sai” là điều hoàn toàn phi thực tế.

[08:40] AI có thể giúp bạn làm rất nhiều việc, nhưng nó không phải một công cụ thần thánh có thể tự động giải quyết mọi vấn đề.

Những bức tường văn bản vô dụng

[08:47] Một chủ đề lớn khác là quá nhiều văn bản vô dụng. Điều này hoàn toàn đúng. AI tạo ra quá nhiều thứ tệ hại.

[09:01] Tôi từng nói với AI: “Không cần diễn giải. Chỉ cần lập danh sách các repository patterns, rồi chúng ta sẽ bắt đầu xây dựng từng cái một.” Nó trả lời: “Được, field guide, mỗi chủ đề một file.”

[09:15] Như vậy đã là quá nhiều rồi. “Mở file bạn cần.” Bạn không cần phải nói rằng mỗi file chứa facts và code. Tôi đã bảo không cần diễn giải.

[09:23] Tôi nói: “Tôi đã bảo không cần diễn giải”, và nó viết một đoạn diễn giải về việc không cần diễn giải. Có rất ít thứ khiến tôi ghét hơn những bức tường văn bản vô dụng do các AI tạo ra.

[09:40] Mỗi lần tôi nói “đừng diễn giải”, nó lại trả lời: “Đã rõ, sếp. Tôi đã viết trong tài liệu rằng không cần diễn giải, trong khi mô tả điều đó theo cách đầy diễn giải.” Thật sự rất bực.

[09:50] Điều đó cũng khiến tôi lãng phí rất nhiều thời gian. Tôi chỉ ngồi đọc một bức tường văn bản khổng lồ, rồi cuối cùng nhận ra đáng lẽ nó chỉ cần một câu.

[09:58] Nó viết 400 từ chỉ để nói: “Nhân tiện, giao diện client ở đây hơi tệ.” Lần sau cứ nói thẳng như vậy đi.

[10:09] Nếu ai biết cách khắc phục chuyện này thì tôi rất muốn biết. Tôi thậm chí đã thử GrubSpeak. Đúng là nó làm giảm lượng output, nhưng vẫn tạo ra một đoạn văn kiểu GrubSpeak rất khó hiểu.

[10:31] Chỉ cần nói những từ đơn giản thôi.

Cảm giác thiếu quyền sở hữu

[10:33] Đây có lẽ là vấn đề được mọi người nhắc đến nhiều nhất. Dù bạn cực kỳ ủng hộ AI hay mới bắt đầu bước vào thế giới AI, đây dường như là phàn nàn phổ biến nhất: không cảm thấy mình thực sự sở hữu bất cứ thứ gì AI tạo ra.

[10:50] Với tôi, đây là một trong những rào cản khó vượt qua nhất. Nhưng hiện giờ tôi nghĩ mình đã có giải pháp cho vấn đề này, nên đây sẽ là lúc tôi đưa ra lời khuyên.

[10:59] Khi bắt đầu một dự án mới, thay vì chỉ vibe coding, tôi suy nghĩ sâu về hình dạng của hệ thống và những gì mình muốn. Sau đó tôi dùng AI để tạo thử một thứ gì đó, thiết lập nó, rồi bảo đảm rằng nó thực sự hoạt động bằng cách ngồi lại và iterate.

[11:16] Cách này tạo ra quá nhiều test, quá nhiều dòng code và đủ thứ khác. Nhưng tôi thu được rất nhiều insight: tôi muốn một automation server, muốn có khả năng phát hiện automation clients, muốn tính năng này, tính năng kia.

[11:29] Sau khi hiểu toàn bộ vấn đề ở quy mô lớn, tôi xây dựng V2. Lúc đó tôi thiết kế lại, thực sự suy nghĩ về từng bước, phân loại mọi thứ cho rõ ràng và làm tương tự với client. Tôi xây dựng một hệ thống mà mình thực sự thích.

[11:46] Tôi thường dùng số dòng code như một cách kiểm tra. Không phải vì nhiều dòng hơn hay ít dòng hơn đều tốt, mà vì tôi xây dựng lại cùng một thứ với cùng một tập feature theo cách có suy nghĩ hơn và súc tích hơn.

[12:08] Tại sao số dòng lại giảm? Vì tôi suy nghĩ tốt hơn về các test, về hình dạng của hệ thống và cấu trúc nền tảng của từng component. Tôi hiểu rõ hơn các thành phần của hệ thống.

[12:18] Lần thứ hai, tôi thực sự cảm thấy mình đã phát triển phần mềm thông qua AI. Dự án hiện tại của tôi bắt đầu với 100.000 dòng code và có lẽ sẽ kết thúc ở khoảng 25.000 đến 30.000 dòng. Với tôi, đó là điều tuyệt vời.

[12:34] Điều đó có nghĩa là tôi đã thực sự suy nghĩ thấu đáo, xây dựng lại hệ thống, có database shape tốt hơn và mọi thứ tốt hơn vì tôi đã trải qua nó một lần. Đến lần thứ hai, hệ thống thực sự đem lại cảm giác tốt.

[12:43] Đây cũng là cách tôi đang làm với Omachi. Tôi đang xây dựng toàn bộ phần automation của Omachi, cùng một thứ gọi là Oligoti, tức “oligarchy”. Tôi đang xây dựng một agentic testing framework khá lớn cho OS.

[12:54] Để làm được vậy, tôi cần một cách phân tán để spawn tất cả các server và những thành phần liên quan. Tôi xây dựng phiên bản đầu tiên như một thử nghiệm và rất thích nó. Tôi có thể suy nghĩ về các custom harnesses, chúng nên trông như thế nào và hoạt động ra sao.

[13:10] Bây giờ tôi đang xây dựng phiên bản thứ hai với toàn bộ feature cũ, nhưng được suy nghĩ kỹ hơn nhiều và có ít code hơn đáng kể. Điều đó khiến tôi vui, vì tôi cảm thấy mình đã tạo ra nó. Tôi thực sự có cảm giác sở hữu vì đã suy nghĩ về mọi thứ.

[13:23] Lời khuyên tốt nhất của tôi là đừng chỉ tạo ra một mớ code cẩu thả để đưa vào sản phẩm. Hãy tạo nó một cách cẩu thả để khám phá. Đó là điều tuyệt vời nhất.

[13:29] Trước đây chúng ta vẫn làm như vậy. Những developer thực sự có kinh nghiệm luôn xây dựng prototype để khám phá. Thường thì sếp sẽ nói: “Prototype tốt đấy. Khi nào đưa vào production, anh bạn?”

[13:46] Bạn xây dựng prototype, nhận ra tất cả những điều đã học được, rồi nói: “Được rồi, giờ tôi sẽ xây dựng phiên bản thật.” Phiên bản đó nhanh hơn và tốt hơn. Tôi cũng đang làm như vậy, chỉ khác là bây giờ tôi dùng AI.

[13:56] Thành thật mà nói, cách này đem lại cho tôi nhiều sự hài lòng hơn với thứ mình đang xây dựng và giúp tôi thực sự cảm thấy có quyền sở hữu.

Junior và việc học kiến thức nền tảng

[14:03] Vấn đề cuối cùng, cũng là vấn đề khiến tôi cảm thấy tiếc nhất, là một junior muốn học những điều mới bằng cách tự làm, nhưng không ai xung quanh muốn họ làm vậy vì mọi người nhận được kết quả tức thì và tốc độ giao hàng nhanh. Vì thế họ không thể tìm thấy chuyên môn trong chính công việc của mình.

[14:19] Thành thật mà nói, tôi nghĩ đây là hệ quả tồi tệ và lớn nhất của AI. Trong một thời gian dài, mọi người được tạo không gian để phát triển và hiểu vấn đề, vì công ty gần như không có lựa chọn nào khác.

[14:33] Nhưng điều đó đang dần biến mất, bởi những người mới giờ đây có thể hiệu quả ngang với Claude. Với nhiều người, đây là mức hiệu quả khá tốt.

[14:42] Tuy nhiên, nếu bạn thách thức AI hoặc đưa ra một ý tưởng tệ, AI sẽ không nói: “Tôi hiểu đề xuất của bạn, nhưng khi xem xét kiến trúc, tôi nghĩ cách này sẽ tốt hơn. Hãy thảo luận trước khi thực hiện thay đổi.” Nó không bao giờ làm vậy.

[15:01] Nó chỉ đưa cho bạn một pull request dài 1.000 dòng và nói: “Tôi đã làm đúng như bạn yêu cầu.” Vì không quen với codebase, bạn có thể đã đưa ra hàng loạt quyết định ngớ ngẩn khiến rác xuất hiện ở khắp nơi.

[15:14] Điều này còn tệ hơn gấp mười lần với người trẻ, vì họ thậm chí không có cơ hội học xem một thứ tốt trông như thế nào. Làm sao bạn biết điều gì là tốt? Bạn không biết.

[15:24] Tôi thực sự cảm thông với các junior nhất, vì các bạn chịu thiệt thòi nhiều nhất trong chuyện này. Các bạn bị kỳ vọng phải làm việc như senior chỉ vì có một công cụ tạo ra thứ được cho là ngang với senior hoặc tốt hơn, nhưng các bạn lại không có sự hiểu biết tương ứng.

[15:44] Cho đến hôm nay, tôi vẫn cảm thấy kiến thức kỹ thuật là điều rất tốt. Dành thời gian đọc, học hỏi, xây dựng prototype, suy nghĩ về mọi edge case và xử lý từng edge case thực sự là việc đáng làm.

[15:56] Hãy học về mocking, rồi học vì sao bạn ghét mock, nhưng cũng hiểu rằng đôi khi chúng là một điều cần thiết. Hãy học dependency injection, hiểu vì sao nó giải quyết được nhiều vấn đề và cũng vì sao nó có thể trở nên tệ hại. Hãy tiếp tục học.

[16:09] Tôi biết nói như vậy trong thời đại AI không hấp dẫn. Nhưng tôi không nghĩ việc chạy ở tốc độ tối đa mà không học gì, thậm chí không hiểu mình đang làm gì, sẽ tốt cho bạn về lâu dài, chẳng hạn trong năm năm tới.

[16:22] Bạn muốn xây dựng phần mềm như thế nào? Bạn muốn tiếp tục là người không biết gì, chỉ làm theo chỉ dẫn, nhập mọi thứ vào rồi hy vọng nó hoạt động, sau đó xây dựng các evaluation chỉ để nói “Có vẻ là nó chạy”, rồi giao sản phẩm đi mà không biết nó tốt hay xấu?

[16:37] Hay bạn muốn có khả năng nhìn vào một vấn đề và nói: “Được, chúng ta sẽ chia nó như thế này. Cách này sẽ hiệu quả. Cách này sẽ tốt. Nó cho phép chúng ta mở rộng theo hướng này và tạo ra những trade-off này.”

[16:46] Nếu muốn trở thành người như vậy, bạn phải nỗ lực và phải tự mình đạt được điều đó. Tôi không thấy có cách nào khác ngoài việc đọc, trực tiếp đặt tay lên bàn phím và dành một chút thời gian.

Đừng hoảng sợ trước những lời cảnh báo

[16:55] Tôi cũng muốn nói thêm một điều. Hiện nay nhiều người liên tục nói rằng nếu bạn không làm những việc nhất định thì bạn sẽ không thể thành công.

[17:04] Hãy nhớ rằng bạn còn cả một cuộc đời dài phía trước và chúng ta hoàn toàn không biết tương lai sẽ ra sao. Có thể một ngày nào đó, AI sẽ thông minh đến mức bạn không cần phải suy nghĩ gì nữa. Bạn chỉ cần nói “hãy tạo ra nó”, rồi AI sẽ đưa ra cấu hình server lý tưởng, phần client-side lý tưởng, sắp xếp dữ liệu và tạo những table tốt trong database.

[17:24] Tôi nghi ngờ điều đó, nhưng dù sao cũng có thể sẽ đến ngày mọi kiến thức kỹ thuật trở nên vô dụng theo một nghĩa nào đó, vì AI quá mạnh, biết mọi thứ trong vũ trụ và có thể tổng hợp toàn bộ kinh nghiệm.

[17:37] Tôi không biết ngày đó sẽ đến khi nào. Cách dễ nhất để nói là: nếu hôm nay tôi tuyển một người, tôi muốn người chỉ đóng vai trò proxy — lặp lại điều tôi nói, biến lời tôi thành code, xem nó chạy rồi nói “merge” — hay tôi muốn người thực sự suy nghĩ về vấn đề?

[17:52] Tôi muốn người thứ hai. Người có thể nói: “Tôi không nghĩ chúng ta cần những test này. Tôi muốn test trông như thế này. Tôi muốn server này, hệ thống được bố trí như thế này, CLI như thế này.” Tôi muốn người thực sự suy nghĩ thấu đáo về mọi vấn đề.

[18:09] Chỉ làm proxy không bao giờ là một ý tưởng hay. Hãy luôn cố gắng trở thành nhiều hơn một người chỉ chuyển thông tin từ người này sang một ô văn bản.

[18:19] Vậy là xong. Đó là phản hồi của tôi về tất cả những vấn đề này. Nếu bạn thích video thì hãy bấm nút đó đi. Bạn biết nút nào rồi đấy. Thực ra PewDiePie cũng biết.

[18:28] Một khóa học khác tôi làm gần đây là khóa học GitHub do một YouTuber khác tên là Primogen tổ chức, và tôi rất thích khóa học đó. Đây là điều người này đã dạy tôi.