Mã là một khoản nợ (không phải tài sản). Các ông chủ công nghệ không hiểu điều này. Họ nghĩ AI là tuyệt vời vì nó sản xuất gấp 10.000 lần mã so với một lập trình viên, nhưng điều đó chỉ có nghĩa là nó đang sản xuất gấp 10.000 lần khoản nợ. 1/

Nếu bạn muốn một phiên bản định dạng bài luận của chủ đề này để đọc hoặc chia sẻ, đây là liên kết đến nó trên blog của tôi, nơi không có giám sát, không có quảng cáo và không có theo dõi: 2/

AI là amiăng mà chúng ta đang đổ vào những bức tường của xã hội công nghệ cao của chúng ta: Mã là một trách nhiệm. *Khả năng* của mã là tài sản. 3/

Mục tiêu của một cửa hàng công nghệ là có mã nguồn mà khả năng của nó tạo ra nhiều doanh thu hơn so với chi phí liên quan đến việc duy trì mã nguồn đó. 4/

Trong một thời gian dài, các công ty đã nuôi dưỡng một niềm tin sai lầm rằng mã nguồn có chi phí vận hành thấp hơn theo thời gian: sau một giai đoạn khởi động ban đầu, trong đó các lỗi trong mã được phát hiện và giải quyết, mã sẽ không cần bảo trì đáng kể nữa. 5/

Sau cùng, mã là một cỗ máy không có bộ phận chuyển động - nó không bị hao mòn; nó thậm chí không bị mài mòn. Đây là luận điểm trong cuốn sách *Postcapitalism* của Paul Mason năm 2015, một cuốn sách đã trở nên kém giá trị một cách đáng kể (mặc dù có thể không kém giá trị như uy tín chính trị của chính Mason). 6/

Mã không phải là một cỗ máy có thể tái sản xuất vô hạn mà không cần lao động. Thay vào đó, nó là một cỗ máy dễ gãy cần những biện pháp ngày càng anh hùng để giữ cho nó hoạt động tốt, và cuối cùng sẽ "mòn đi" (theo nghĩa cần phải tái cấu trúc từ đầu đến cuối). 7/

Để hiểu tại sao mã là một trách nhiệm, bạn phải hiểu sự khác biệt giữa "viết mã" và "kỹ thuật phần mềm." "Viết mã" là một sở thích vô cùng hữu ích, thú vị và hấp dẫn. 8/

Nó liên quan đến việc phân chia các nhiệm vụ phức tạp thành các bước riêng biệt, được mô tả một cách chính xác đến mức một máy tính có thể thực hiện chúng một cách đáng tin cậy, tối ưu hóa hiệu suất bằng cách tìm ra những cách thông minh để giảm thiểu yêu cầu mà mã đặt lên tài nguyên của máy tính, chẳng hạn như RAM và chu kỳ xử lý. 9/

Trong khi đó, "kỹ thuật phần mềm" là một lĩnh vực bao gồm "viết mã", nhưng tập trung vào các hoạt động lâu dài của *hệ thống* mà mã đó là một phần của nó. 10/

Kỹ thuật phần mềm liên quan đến các quy trình đầu vào tạo ra dữ liệu mà hệ thống nhận được. Nó liên quan đến các quy trình đầu ra mà hệ thống phát ra thông tin đã được xử lý. 11/

Nó liên quan đến các hệ thống liền kề đang nhận dữ liệu từ cùng một quy trình đầu vào và/hoặc phát ra dữ liệu đến cùng một quy trình đầu ra mà hệ thống đang phát ra. 12/

"Viết mã" là về việc tạo ra mã mà *chạy tốt*. "Kỹ thuật phần mềm" là về việc tạo ra mã mà *thất bại tốt*. Nó liên quan đến việc tạo ra mã có thể đọc được - mà các chức năng của nó có thể được hiểu bởi những bên thứ ba có thể được yêu cầu bảo trì nó. 13/

Các bên thứ ba đó có thể được yêu cầu điều chỉnh các quy trình ở hạ nguồn, thượng nguồn hoặc liền kề với hệ thống để giữ cho hệ thống không bị hỏng. 14/

Đó là điều này: bất kỳ mã nào không tầm thường đều phải tương tác với thế giới bên ngoài, và thế giới bên ngoài không tĩnh, nó *động*. Thế giới bên ngoài phá vỡ những giả định mà các tác giả phần mềm *luôn luôn* đưa ra và mỗi khi điều đó xảy ra, phần mềm cần phải được sửa chữa. 16/

Bạn có nhớ Y2K không? Đó là một ngày mà mã hoàn toàn hoạt động, chạy trên phần cứng hoàn toàn hoạt động, sẽ ngừng hoạt động - không phải vì mã đã thay đổi, mà vì *thời gian trôi đi*. 17/

Chúng ta còn 12 năm nữa để đối mặt với vấn đề Y2038, khi các phiên bản 32-bit của Unix sẽ ngừng hoạt động, vì chúng cũng sẽ hết giây có thể tính toán. 18/

Sự tồn tại của "thế giới" là một yếu tố không thể tránh khỏi làm hao mòn phần mềm và yêu cầu nó phải được xây dựng lại, thường với chi phí khổng lồ. Thời gian mà mã hoạt động càng lâu, khả năng nó gặp phải "thế giới" càng cao. 20/

Lấy mã mà các thiết bị sử dụng để báo cáo vị trí vật lý của chúng. Ban đầu, điều này được sử dụng cho những thứ như thanh toán - xác định mạng của nhà cung cấp hoặc nhà mạng mà bạn đang sử dụng và liệu bạn có đang chuyển vùng hay không. 21/

Sau đó, các thiết bị di động của chúng tôi đã sử dụng mã này để giúp xác định vị trí của bạn nhằm cung cấp chỉ đường từng bước trong các ứng dụng điều hướng. Sau đó, mã này lại được sử dụng để giúp chúng tôi tìm các thiết bị bị mất của mình. 22/

Điều này trở thành một cách để xác định các thiết bị *bị đánh cắp*, một trường hợp sử dụng hoàn toàn khác với việc tìm kiếm các thiết bị bị mất. Khi xác định một thiết bị bị mất, bạn không phải đối mặt với khả năng rằng một kẻ xấu đã vô hiệu hóa chức năng "tìm thiết bị bị mất". 23/

Các trường hợp sử dụng bổ sung này - thượng nguồn, hạ nguồn và liền kề - đã phơi bày các lỗi trong mã gốc mà chưa bao giờ xuất hiện trong các ứng dụng trước đó. 24/

Ví dụ, tất cả các dịch vụ định vị phải có một loại hành vi mặc định nào đó trong trường hợp (rất phổ biến) mà chúng không thực sự chắc chắn về vị trí của mình. 25/

Có thể họ có một cách khắc phục chung - ví dụ, họ biết họ đang kết nối với trạm phát sóng di động nào, hoặc họ biết họ đã ở đâu lần *cuối* khi họ nhận được vị trí chính xác - hoặc có thể họ hoàn toàn bị lạc. 26/

Hóa ra trong nhiều trường hợp, các ứng dụng định vị đã vẽ một vòng tròn xung quanh tất cả các địa điểm mà chúng *có thể* ở và sau đó đặt vị trí của chúng ở giữa vòng tròn đó. 27/

Điều đó không sao nếu vòng tròn chỉ có vài feet đường kính, hoặc nếu ứng dụng nhanh chóng thay thế sự ước lượng này bằng một vị trí chính xác hơn. Nhưng nếu vị trí cách nhau hàng dặm và việc xác định vị trí *không bao giờ* được cải thiện thì sao? 28/

Điều gì sẽ xảy ra nếu vị trí cho bất kỳ địa chỉ IP nào không có vị trí xác định được cho là *trung tâm của Hoa Kỳ lục địa* và bất kỳ ứng dụng nào không biết nó ở đâu báo cáo rằng nó ở trong một ngôi nhà ở Kansas? 29/

Và ở thị trấn Burbank của tôi, nơi dịch vụ chia sẻ vị trí của Google từng cho chúng tôi biết rằng con gái 11 tuổi của chúng tôi (mà chúng tôi không thể liên lạc được) đang cách đó 12 dặm, trên một lối ra cao tốc ở một khu vực không được thành lập thuộc quận LA. 32/

(Cô ấy đang ở một công viên gần đó, nhưng ngoài tầm với, và ứng dụng ước lượng vị trí của cô ấy là trung tâm của khu vực mà nó đã xác định lần cuối.) (Đó là một vài giờ khó khăn.) 33/

Mã nguồn - mã sử dụng một số mặc định từng vô hại để làm mờ các vị trí không xác định - cần được cập nhật *liên tục*, vì các quy trình upstream, downstream và liền kề liên quan đến nó đang thay đổi *liên tục*. 34/

Mã càng nằm yên lâu, các hành vi ban đầu của nó càng trở nên lỗi thời, và các bản vá được xếp chồng lên trên nó càng trở nên phức tạp, rối rắm và khó hiểu. 35/

Mã không phải là tài sản - nó là một khoản nợ. Hệ thống máy tính càng hoạt động lâu, nó càng đại diện cho nhiều khoản nợ công nghệ. Hệ thống càng quan trọng, việc tắt nó và làm lại hoàn toàn càng khó khăn hơn. 36/

Thay vào đó, các lớp mã mới được phủ lên trên nó, và bất cứ nơi nào các lớp mã gặp nhau, có những vết nứt mà các hệ thống này hoạt động theo cách không hoàn toàn khớp nhau. 37/

Tệ hơn nữa: khi hai công ty được sáp nhập, các hệ thống CNTT bị rạn nứt của họ bị đập lại với nhau, khiến giờ đây có các nguồn nợ công nghệ *kề bên* nhau, cũng như các vết nứt ở phía trên và phía dưới: 38/

Đó là lý do tại sao các công ty lớn lại dễ bị tấn công ransomware - chúng đầy rẫy các hệ thống không tương thích đã được thuyết phục thành một bản sao của sự tương thích với nhiều hình thức "silly putty" kỹ thuật số, dây và dây buộc.

Chúng không kín nước và không thể làm cho kín nước. Ngay cả khi chúng không bị hacker tấn công, đôi khi chúng chỉ đơn giản là đổ xuống và không thể đứng dậy trở lại. 40/

Bạn có nhớ khi máy tính của Southwest Airlines bị sập trong suốt tuần lễ Giáng sinh 2022, khiến hàng triệu hành khách bị mắc kẹt không? 41/

Các hãng hàng không đặc biệt tệ, vì họ đã số hóa sớm, và không bao giờ có thể tắt các máy tính cũ để thay thế bằng những cái mới. Đây là lý do tại sao ứng dụng của họ lại tệ đến vậy. 42/

Đây là lý do tại sao thật tồi tệ khi các hãng hàng không sa thải nhân viên dịch vụ khách hàng của họ và yêu cầu hành khách sử dụng ứng dụng cho *mọi thứ*, mặc dù các ứng dụng này không. hoạt động. Những ứng dụng này sẽ không bao giờ hoạt động. 43/

Lý do mà ứng dụng của British Airways hiển thị "Đã xảy ra một lỗi không xác định" 40-80% thời gian không chỉ vì họ đã sa thải tất cả nhân viên IT và thuê ngoài cho những nhà thầu giá rẻ ở nước ngoài. 44/

Đúng vậy, nhưng cũng vì những chiếc máy tính đầu tiên của BA chạy bằng van điện cơ, và mọi thứ từ đó phải tương thích ngược với một hệ thống mà một trong những học trò của Alan Turing đã gặm ra từ một khúc gỗ nguyên vẹn bằng chính chiếc răng của mình. 45/

Mã là một khoản nợ, không phải là tài sản (ứng dụng mới của BA đã chậm tiến độ nhiều năm). Mã là một khoản nợ. Các máy chủ cho các đầu cuối Bloomberg đã biến Michael Bloomberg thành tỷ phú chạy trên các chip RISC. 46/

Điều này có nghĩa là nó bị khóa vào việc sử dụng một số nhà cung cấp phần cứng và trung tâm dữ liệu chuyên biệt ngày càng giảm, phải trả tiền cho các lập trình viên chuyên môn, và xây dựng những chuỗi mã dễ gãy để kết nối các hệ thống RISC này với các tương đương ít kỳ lạ hơn của chúng trên thế giới. Mã không phải là một tài sản. 47/

AI có thể viết mã, nhưng AI không thể làm kỹ thuật phần mềm. Kỹ thuật phần mềm hoàn toàn liên quan đến việc suy nghĩ về *bối cảnh* - điều gì sẽ xảy ra trước hệ thống này? Điều gì sẽ xảy ra sau nó? Điều gì sẽ đồng hành cùng nó? Thế giới sẽ thay đổi như thế nào? 48/

Kỹ thuật phần mềm yêu cầu một "cửa sổ ngữ cảnh" rất rộng, điều mà AI không có và không thể có. Cửa sổ ngữ cảnh của AI thì hẹp và nông. Việc tăng tuyến tính cửa sổ ngữ cảnh của AI yêu cầu *mở rộng* theo hình học trong nhu cầu tính toán: 49/

Viết mã mà không xem xét cách nó sẽ thất bại là một công thức cho thảm họa. Đó là cách tạo ra nợ công nghệ ở quy mô lớn. Đó là việc đổ amiăng vào các bức tường của xã hội công nghệ của chúng ta. 50/

Các ông chủ *không biết* rằng mã là một khoản nợ, không phải tài sản. Đó là lý do tại sao họ không ngừng nói về những chatbot sản xuất ra 10.000 lần nhiều mã hơn bất kỳ lập trình viên con người nào. 51/

Họ nghĩ rằng họ đã tìm thấy một cỗ máy sản xuất *tài sản* với tốc độ gấp 10.000 lần một lập trình viên con người. Họ đã nhầm. Họ đã tìm thấy một cỗ máy sản xuất *nợ* với tốc độ gấp 10.000 lần bất kỳ lập trình viên con người nào. 52/

Khả năng bảo trì không chỉ là vấn đề của kinh nghiệm khó kiếm được dạy bạn những cạm bẫy ở đâu. 53/

Nó cũng yêu cầu sự phát triển của "Fingerspitzengefühl" - cảm giác "đầu ngón tay" cho phép bạn đưa ra những phỏng đoán hợp lý về nơi mà những cạm bẫy chưa từng thấy có thể xuất hiện.

Đó là một hình thức kiến thức quy trình. Nó là điều không thể tránh khỏi. Nó không tiềm ẩn ngay cả trong tập hợp mã lớn nhất mà bạn có thể sử dụng làm dữ liệu huấn luyện: *Chà* các ông chủ công nghệ thật sự không hiểu điều này. 55/

Lấy Microsoft làm ví dụ. Cược lớn của họ hiện nay là vào "AI tác động." Họ muốn cài đặt phần mềm gián điệp trên máy tính của bạn để ghi lại mọi phím bấm, mọi giao tiếp, mọi màn hình bạn thấy và gửi nó lên đám mây của Microsoft, đồng thời cho một loạt các chatbot truy cập vào đó. 56/

Họ tuyên bố rằng bạn sẽ có thể nói với máy tính của mình, "Đặt cho tôi một chuyến tàu đến Cardiff và tìm khách sạn mà Cory đã đề cập năm ngoái và đặt cho tôi một phòng ở đó" và nó sẽ làm điều đó. Đây là một ý tưởng vô cùng không khả thi. 57/

Không có chatbot nào có khả năng thực hiện tất cả những điều này, điều mà Microsoft thừa nhận một cách tự do. Thay vì thực hiện điều này với một chatbot, Microsoft đề xuất chia nhỏ điều này giữa hàng chục chatbot, mỗi chatbot mà Microsoft hy vọng sẽ đạt được độ tin cậy lên tới 95%. 58/

Đó là một tiêu chuẩn chatbot hoàn toàn không hợp lý, nhưng hãy xem xét điều này: xác suất là *có tính nhân*. Một hệ thống chứa hai quy trình hoạt động với độ tin cậy 95% có độ tin cậy tổng thể là 90.25% (0.95 * 0.95). 59/

Chia nhỏ một nhiệm vụ giữa vài chục bot có độ chính xác 95% và khả năng nhiệm vụ này được hoàn thành đúng sẽ gần như là *không có gì*. 60/

Trong khi đó, một giám đốc điều hành của Microsoft đã gặp rắc rối vào tháng 12 năm ngoái khi ông đăng trên Linkedin thông báo ý định của mình là để AI viết lại *tất cả* mã nguồn của Microsoft. 63/

Việc tái cấu trúc mã nguồn của Microsoft là rất hợp lý. Microsoft - giống như British Airways và các công ty lâu đời khác - có rất nhiều mã cũ đại diện cho khoản nợ công nghệ không bền vững. 64/

Một số bạn *là* kỹ sư phần mềm đã thấy chatbot cực kỳ hữu ích trong việc viết mã cho bạn. Đây là một nghịch lý phổ biến của AI: tại sao một số người sử dụng AI lại thấy nó thực sự hữu ích, trong khi những người khác lại ghét nó? 66/

Có phải những người không thích AI là "kém về AI?" Có phải những người hâm mộ AI lười biếng và không quan tâm đến chất lượng công việc của họ? 67/

Chắc chắn có một phần của cả hai điều này đang diễn ra, nhưng ngay cả khi bạn dạy mọi người trở thành chuyên gia AI, và loại bỏ tất cả những ai không tự hào về công việc của họ ra khỏi mẫu, thì nghịch lý vẫn sẽ tồn tại. 68/

Giải pháp thực sự cho nghịch lý AI nằm trong lý thuyết tự động hóa, và khái niệm "centaur" và "reverse centaur": 69/

Trong lý thuyết tự động hóa, một "centaur" là một người được một cỗ máy hỗ trợ. Một "reverse centaur" là người đã bị bắt buộc vào *việc hỗ trợ một cỗ máy*. 70/

Hãy nói rằng bạn là một kỹ sư phần mềm sử dụng AI để viết mã lặp đi lặp lại mà bạn có thời gian và kinh nghiệm để xác thực, triển khai sự nhạy bén và kiến thức quy trình của bạn để đảm bảo rằng nó phù hợp với mục đích sử dụng. 71/

Thật dễ dàng để thấy tại sao bạn có thể thấy việc sử dụng AI (khi bạn chọn, theo cách bạn chọn, với tốc độ bạn chọn) là hữu ích. Nhưng giả sử bạn là một kỹ sư phần mềm đã được yêu cầu sản xuất mã với tốc độ gấp 10 lần, 100 lần, hoặc 10.000 lần so với tốc độ trước đây của bạn. 72/

Nói rằng cách duy nhất để làm điều đó là thông qua AI, và không có cách nào của con người mà bạn có thể xem xét mã đó và đảm bảo rằng nó sẽ không bị lỗi khi tiếp xúc lần đầu với thế giới, bạn sẽ ghét điều đó: 73/

(Bạn sẽ ghét nó nhiều hơn nếu bạn đã bị biến thành cái thùng chứa trách nhiệm của AI, cá nhân phải chịu trách nhiệm cho những sai lầm của AI.) Có một cách khác mà các kỹ sư phần mềm thấy mã được tạo ra bởi AI là vô cùng hữu ích: khi mã đó được *tách biệt*. 74/

Nếu bạn đang thực hiện một dự án đơn lẻ - ví dụ, chuyển đổi một lô tệp sang định dạng khác, chỉ một lần - bạn không cần phải lo lắng về các quy trình hạ nguồn, thượng nguồn hoặc liền kề. Không có quy trình nào cả. 75/

Bạn đang viết mã để thực hiện một việc gì đó một lần, mà không tương tác với bất kỳ hệ thống nào khác. Rất nhiều mã hóa là loại dự án tiện ích như thế này. Nó tẻ nhạt, không được cảm ơn, và rất thích hợp cho việc tự động hóa. 76/

Nhiều dự án cá nhân rơi vào danh mục này, và tất nhiên, theo định nghĩa, một dự án cá nhân là một dự án centaur. Không ai ép buộc bạn phải sử dụng AI trong một dự án cá nhân - luôn là sự lựa chọn của bạn về cách và khi nào bạn sử dụng bất kỳ công cụ nào cho mục đích cá nhân. 77/

Nhưng thực tế là các kỹ sư phần mềm đôi khi có thể cải thiện công việc của họ với AI không làm mất giá trị của việc mã là một khoản nợ, không phải là tài sản, và rằng mã AI đại diện cho việc sản xuất nợ ở quy mô lớn. 78/

Trong câu chuyện về thất nghiệp công nghệ, có ý tưởng rằng công nghệ mới tạo ra việc làm mới ngay cả khi nó làm cho những công việc cũ trở nên lỗi thời: cho mỗi người thợ rèn bị mất việc do ô tô, có một công việc đang chờ đợi với tư cách là thợ máy. 79/

Trong những năm kể từ khi bong bóng AI bắt đầu phình to, chúng ta đã nghe rất nhiều phiên bản của điều này: AI sẽ tạo ra việc làm cho "kỹ sư yêu cầu" - hoặc thậm chí tạo ra những công việc mà chúng ta không thể tưởng tượng, vì chúng sẽ không tồn tại cho đến khi AI thay đổi thế giới đến mức không thể nhận ra. 80/

Tôi sẽ không đặt niềm tin vào việc tìm kiếm công việc trong một ngành nghề kỳ diệu mà thực sự không thể tưởng tượng được vì ý thức của chúng ta chưa thay đổi bởi AI đến mức có khả năng hình dung ra những hình thức công việc mới này. 81/

Nhưng nếu bạn *đang* tìm kiếm một công việc mà AI chắc chắn sẽ tạo ra, hàng triệu công việc, tôi có một gợi ý: loại bỏ amiăng kỹ thuật số. 82/

Mã AI - được viết với tốc độ gấp 10.000 lần bất kỳ lập trình viên nào, được thiết kế để hoạt động tốt, nhưng không để thất bại một cách thanh lịch - là loại amiăng kỹ thuật số mà chúng ta đang lấp đầy vào các bức tường của mình. Các thế hệ con cháu của chúng ta sẽ phải dành hàng thế hệ để đào loại amiăng đó ra khỏi các bức tường. 83/

Sẽ có rất nhiều công việc để sửa chữa những thứ mà chúng ta đã làm hỏng nhờ vào cơn tâm thần AI nguy hiểm nhất - niềm tin ảo tưởng rằng "viết mã" là giống như "kỹ thuật phần mềm." 84/

Với tốc độ này, chúng ta sẽ có việc làm đầy đủ cho nhiều thế hệ công nhân gỡ bỏ amiăng. 85/