Tại sao lập trình nằm trên một phổ và cả hai đầu đều quan trọng trong thời đại AI

Phần mềm ngày nay có vẻ đơn giản đến mức đánh lừa. AI có thể tạo ra toàn bộ mã nguồn trong vài phút. Các video hướng dẫn trên YouTube hướng dẫn người mới bắt đầu cách "xây dựng một bản sao" của bất kỳ ứng dụng nổi tiếng nào chỉ với 20 phút sao chép và dán. Các framework, thư viện, và API ẩn đi hầu hết mọi thứ bên dưới.

Dễ dàng để rời bỏ điều đó và nghĩ rằng: điều này thật dễ dàng.

Nhưng điều đó bỏ qua một điều gì đó cơ bản: lập trình luôn tồn tại trên một phổ. Ở một đầu là nghệ thuật, nơi mã được tinh chỉnh thủ công, khắt khe và gắn liền với phần cứng và tính ổn định lâu dài. Ở đầu kia là mã kết quả, nơi mục tiêu chính là làm cho mọi thứ hoạt động nhanh chóng—gửi tính năng, tạo mẫu hoặc tự động hóa.

Cả hai đầu đều quan trọng. Cả hai đầu bổ sung cho nhau. Nhưng việc nhầm lẫn chúng—đối xử với tất cả mã như nhau, hoặc tuyên bố rằng viết các script kết nối khiến bạn trở thành kỹ sư hệ thống—tạo ra những vấn đề, đặc biệt khi nói đến độ tin cậy và bảo mật.

Phổ lập trình

Dưới đây là phổ mà tôi sử dụng để giải thích:

Copy

10                   0                   10
|---------------------------------------|
Nghệ thuật                                   Kết quả

Phía nghệ thuật (trái, điểm ~10)
Các ngôn ngữ và môi trường yêu cầu sự chính xác: C, C++, Assembly, Erlang, COBOL, Fortran, đôi khi ngay cả Java doanh nghiệp nghiêm ngặt. Ở đây, trọng tâm là độ chính xác, tính xác định, hiệu quả bộ nhớ, và khả năng bảo trì lâu dài. Đây là nơi chúng ta xây dựng hệ điều hành, trình biên dịch, firmware, thuật toán mã hóa, và phần mềm quan trọng cho nhiệm vụ. Các lỗi ở đây không chỉ “khó chịu”—chúng có thể tiêu tốn hàng triệu đô la, gây nguy hiểm đến tính mạng, hoặc làm hỏng phần cứng vĩnh viễn.
Phía kết quả (phải, điểm ~10)
Hệ sinh thái cấp cao, phát triển nhanh: Python, JavaScript, TypeScript, các framework frontend hiện đại như React hoặc Vue, các chức năng serverless. Sự nhấn mạnh là tốc độ và sản lượng. Nếu nó hoạt động hôm nay, hãy gửi đi. Nếu nó bị hỏng, hãy vá sau. Phía này cung cấp sức mạnh cho MVPs, các script tự động hóa, ứng dụng web, và các nguyên mẫu hackathon. Nó giúp phần mềm trở nên dễ tiếp cận với hàng triệu người sẽ không bao giờ viết assembly trong cuộc đời của họ.

Hầu hết các nhà phát triển bắt đầu từ phía Kết quả. Đó là một tính năng, không phải lỗi. Khả năng tiếp cận thúc đẩy đổi mới. Nhưng để thành thạo đòi hỏi cuối cùng phải đi qua đường biên và grappling với phía Nghệ thuật—ngay cả khi chỉ một lần—để bạn hiểu cách mà máy thực sự hoạt động.

Kỹ thuật nhúng: Một nghiên cứu trường hợp về Nghệ thuật

Một trong những ví dụ rõ ràng nhất về lập trình phía nghệ thuật là kỹ thuật nhúng.

Khác với các dịch vụ đám mây với bộ nhớ không giới hạn và tính toán co giãn, các hệ thống nhúng bị hạn chế một cách khắc nghiệt:

RAM được đo bằng kilobyte, không phải gigabyte.
Bộ xử lý có tốc độ được đo bằng megahertz, không phải gigahertz.
Ngân sách năng lượng liên quan đến các pin nhỏ.
Thời hạn thực mà nếu bỏ lỡ một micro giây có thể làm hỏng hệ thống.

Đó là lý do tại sao C vẫn chiếm ưu thế trong phát triển nhúng sau hàng thập kỷ. Nó cung cấp:

Truy cập trực tiếp vào phần cứng: Các nhà phát triển thao tác trực tiếp lên các thanh ghi và địa chỉ bộ nhớ.
Kiểm soát chặt chẽ tài nguyên: Mỗi byte đều quan trọng.
Hiệu suất dự đoán được: Không có bất ngờ từ garbage collector.

Ví dụ: lập trình một vi điều khiển để đọc cảm biến. Trong Python, bạn sẽ nhập một thư viện và gọi một hàm. Trong C nhúng, bạn đang đảo bit trong một thanh ghi được ánh xạ bộ nhớ để kích hoạt ADC, thiết lập tỷ lệ mẫu, và đảm bảo rằng các ngắt xảy ra đúng thời điểm.

Nó không hào nhoáng. Nhưng nếu bạn làm sai, drone của bạn sẽ không ổn định, hoặc máy tạo nhịp của bạn sẽ bỏ lỡ một nhịp đập.

Đó là sự khác biệt: trong nghệ thuật nhúng, “hoạt động trên máy của tôi” không được chấp nhận. Nó phải hoạt động một cách xác định, mỗi lần, trên phần cứng thực tế.

ABI: Hợp đồng ẩn tách biệt người mới khỏi kỹ sư

Một khái niệm thực sự minh họa cho phía nghệ thuật là Giao diện nhị phân ứng dụng (ABI).

Hầu hết các nhà phát triển biết về APIs (Giao diện lập trình ứng dụng)—các hàm và lớp mà bạn gọi trong mã. Một ABI là cấp thấp hơn: nó định nghĩa cách mã máy đã biên dịch tương tác.

Các quy tắc chính của ABI bao gồm:

Quy ước gọi: Các đối số hàm được truyền qua các thanh ghi hay được đẩy lên stack?
Sử dụng thanh ghi: Những thanh ghi nào phải được bảo tồn qua các cuộc gọi?
Bố cục khung stack: Các địa chỉ trả về và biến cục bộ ở đâu.
Biểu diễn dữ liệu: Endianness, padding cấu trúc, căn chỉnh.

Tại sao điều này quan trọng? Bởi vì nếu bạn vi phạm ABI, chương trình của bạn vẫn biên dịch, nhưng nó sẽ âm thầm bị hỏng trong thời gian chạy.

Ví dụ:

Trình biên dịch A (ARM EABI) truyền đối số nguyên đầu tiên trong thanh ghi r0.
Trình biên dịch B (quy ước khác) đẩy nó vào stack. Bây giờ hãy tưởng tượng liên kết các tệp đối tượng được xây dựng bằng hai trình biên dịch này. Các cuộc gọi hàm của bạn sẽ hiểu sai các đối số, làm hỏng bộ nhớ, hoặc gặp sự cố không thể đoán trước.

Đây là những bóng ma ám ảnh các kỹ sư nhúng. Bạn sẽ không thấy chúng trong JavaScript hoặc Python. Bạn chỉ gặp chúng khi bạn rời vào giải mã và gỡ lỗi ở mức máy.

Hiểu biết về ABI tách biệt những người có thể thực sự thiết kế hệ thống khỏi những người chỉ có thể viết script.

Sức mạnh và nguy hiểm của mã kết quả

Bây giờ, hãy dành cho phía Kết quả sự công nhận.

Python, JavaScript, các framework frontend—đây là động lực của văn hóa phần mềm hiện đại. Chúng:

Trao quyền cho người mới tạo nhanh chóng.
Thúc đẩy tạo mẫu và MVPs.
Nuôi dưỡng sự bùng nổ của các dự án khởi nghiệp và mã nguồn mở.

Đây là thứ tôi gọi là mã vibe: mã với năng lượng của sự thử nghiệm, hướng dẫn, và “xem nó có chạy không.”

Và đó không phải là một sự xúc phạm. Mã vibe có giá trị. Nó hạ thấp rào cản. Nó dân chủ hóa phần mềm. Nó tạo ra nhiều cơ hội hơn bao giờ hết. Nó thú vị, nhanh chóng, và thường đủ cho nhiều ứng dụng thực tế.

Nhưng mã vibe cũng có những trade-off:

Lối tắt: An ninh và ổn định thường bị bỏ qua.
Nợ kỹ thuật: Các cách giải quyết nhanh chóng tích tụ.
Hiểu biết nông: Người mới có thể không học được cách mà các hệ thống thực sự hoạt động.

Sai lầm không nằm ở mã vibe—mà là nhầm lẫn mã vibe với lập trình kỹ thuật đầy đủ.

Bảo mật: Lưỡi hai

Đây là sự mỉa mai: mã kết quả là một món quà cho các chuyên gia an ninh mạng.

Tại sao? Bởi vì tốc độ tạo ra các lỗ hổng. Và các lỗ hổng là những cánh cửa.

SQL injection vì đầu vào của người dùng không được vệ sinh.
Bí mật cứng mã được cam kết lên GitHub.
Các bucket đám mây để mở rộng rộng rãi.
Các API gỡ lỗi vô tình bị lộ.

Trong thời kỳ Nghệ thuật, các nhà phát triển nghiêm khắc hơn. Họ lo lắng về tràn bộ đệm, an toàn bộ nhớ, và xác thực đầu vào. Trong thế giới Kết quả hiện nay, việc xem bảo mật như một suy nghĩ sau là điều phổ biến.

Đối với những kẻ tấn công, đây là thiên đường. Đối với các kiểm thử viên xâm nhập, đây là bảo đảm công việc. Những người mã vibe, một cách vô tình, trở thành những người khai thác dữ liệu vĩ đại nhất cho hacker. Họ mở những cánh cửa mà người khác đi qua.

Sự phân chia tâm lý

Cuối cùng, sự khác biệt giữa Nghệ thuật và Kết quả không chỉ ở ngôn ngữ. Đó là tâm lý.

Tâm lý Kết quả: “Nếu nó hoạt động, hãy gửi đi.”
Tâm lý Nghệ thuật: “Nếu tôi không biết tại sao nó hoạt động, nó chưa sẵn sàng.”

Các kỹ sư Kết quả tối ưu hóa cho tốc độ, khả năng sử dụng, và sự phù hợp thị trường. Các kỹ sư Nghệ thuật tối ưu hóa cho độ chính xác, sự ổn định, và độ tin cậy lâu dài. Cả hai đều có giá trị. Cả hai đều cần thiết. Nhưng chúng không thể thay thế cho nhau.

Vai trò của AI trong phổ

AI nghiêng nặng về phía Kết quả. Nó rất giỏi trong:

Tạo ra mã nhanh chóng.
Điền vào các đoạn mã mẫu.
Đề xuất các sửa lỗi hoặc cải tiến phong cách.

Nhưng AI không lý luận về ABI. Nó không đảm bảo tính xác định trong các hệ thống thời gian thực. Nó không đảm bảo mã C nhúng của bạn sẽ đạt thời hạn mà không có độ trễ.

AI tăng tốc mã Kết quả nhưng không thể thay thế kỹ thuật Nghệ thuật. Nếu có gì, nó làm cho các kỹ sư Nghệ thuật trở nên có giá trị hơn, bởi vì càng nhiều mã phía Kết quả tràn ngập thế giới, thì càng có nhu cầu cho những người hiểu những phần khó khăn.

Đi qua phổ

Vậy điều này có nghĩa là gì đối với các nhà phát triển?

Nếu bạn sống trong thế giới Kết quả:

Tiếp tục lập trình, tiếp tục gửi đi, tiếp tục sáng tạo.
Nhưng đừng nhầm lẫn việc làm cho một cái gì đó hoạt động với việc hiểu hệ thống.
Hãy chú ý đến bảo mật và khả năng bảo trì lâu dài.

Nếu bạn sống trong thế giới Nghệ thuật:

Tôn trọng tốc độ và sự sáng tạo của mã Kết quả.
Sử dụng nó khi tạo mẫu hoặc xây dựng công cụ.
Nhưng đừng thỏa hiệp tiêu chuẩn của bạn khi xây dựng các hệ thống quan trọng.

Và nếu bạn muốn phát triển như một kỹ sư:

Đi qua phổ ít nhất một lần.
Viết C. Gỡ lỗi assembly. Nghiên cứu ABI. Hiểu cách căn chỉnh bộ nhớ và quy ước gọi.
Sau đó trở lại với Python, JavaScript, hoặc Rust với trực giác sâu sắc hơn.

Tại sao điều này quan trọng

Sự phân chia không phải là về “tốt hơn” hay “kém hơn”. Đó là về việc phù hợp tâm lý đúng với vấn đề đúng.

Xây dựng một bảng điều khiển nội bộ nhanh chóng? Mã kết quả là hoàn hảo.
Viết firmware cho một vệ tinh? Nghệ thuật là không thể thương lượng.
Tạo mẫu một mô hình học máy? Các công cụ Kết quả sẽ đưa bạn xa.
Triển khai các quy trình mã hóa bảo mật cho mô hình đó? Nghệ thuật hoàn toàn.

Sai lầm là khi ai đó chỉ chạm vào các công cụ phía Kết quả và sau đó tuyên bố trở thành kỹ sư của mọi thứ. Kỹ thuật yêu cầu hiểu những gì xảy ra bên dưới lớp trừu tượng.

Tương lai

Khi AI lan rộng, phía Kết quả sẽ trở nên dễ dàng hơn. Nhiều người sẽ lập trình. Nhiều phần mềm sẽ tràn ngập thế giới. Và với dòng chảy đó sẽ đến nhiều lỗ hổng hơn, nhiều hệ thống mong manh hơn, và nhiều cơ hội cho những người hiểu phía Nghệ thuật.

Các nhà phát triển mạnh mẽ nhất trong tương lai sẽ không phải là những người chỉ có thể yêu cầu AI tạo ra các thành phần React. Họ sẽ là những người có thể:

Đắm chìm vào các lớp thấp hơn khi mọi thứ bị hỏng.
Đảm bảo tính chính xác nơi mà tính xác định quan trọng.
Thiết kế các hệ thống an toàn, hiệu quả khi hàng triệu mạng sống hoặc hàng tỷ đô la phụ thuộc vào đó.

AI sẽ làm cho mã Kết quả trở nên rẻ. Nghệ thuật sẽ vẫn còn hiếm và có giá trị.

Lập trình không dễ. Nó không phải là một kích thước phù hợp cho tất cả. Nó là một phổ—từ Nghệ thuật đến Kết quả.

Những người mã vibe giữ cho thế giới di chuyển nhanh. Những kỹ sư Nghệ thuật giữ cho nó đứng vững khi điều đó quan trọng. Không bên nào tồn tại mà không có bên kia.

Nhưng nếu bạn muốn gọi mình là một kỹ sư, bạn nợ bản thân mình việc đi qua con đường Nghệ thuật ít nhất một lần. Để hiểu những gì thực sự đang xảy ra bên dưới các lớp trừu tượng. Để học tại sao ABI quan trọng, tại sao các hệ thống nhúng đòi hỏi sự khắt khe, tại sao tính ổn định không phải là tùy chọn.

Bởi vì một ngày nào đó, mã của bạn sẽ không chỉ vẽ một nút. Nó sẽ điều khiển một máy móc, bảo vệ dữ liệu nhạy cảm, hoặc giữ vững hàng rào chống lại các cuộc tấn công.

Và khi ngày đó đến, bạn sẽ vui mừng vì đã học nghệ thuật.

Tại sao lập trình nằm trên một phổ và cả hai đầu đều quan trọng