Lập luận: Prompt AI chính là lập trình

Prompt AI không phải trò chuyện, đó là lập trình

Một bài viết đăng trên blog cá nhân của Bret Thorsting (lan truyền qua Hacker News) đưa ra một góc nhìn đáng chú ý: viết prompt tốt cho AI chính là lập trình, chỉ khác ở cú pháp. Tác giả lập luận rằng khoảng cách năng suất giữa lập trình viên và các ngành nghề khác khi dùng AI không đến từ việc mô hình được huấn luyện trên nhiều mã nguồn, mà từ thói quen tư duy mà lập trình viên được rèn luyện qua nhiều năm.

Câu chuyện khởi nguồn

Tác giả kể lại việc chứng kiến một người bạn — giáo sư ngành khoa học nhân văn tốt nghiệp Ivy League — làm việc với Claude. Cuộc trò chuyện cứ lặp vòng, người bạn không bao giờ nói rõ mục tiêu của mình là gì. Mỗi câu trả lời của Claude đều hợp lý với những gì được yêu cầu, nhưng lệch một chút so với điều người bạn muốn, nên họ lại chỉnh, rồi kết quả trôi sang hướng khác.

Theo tác giả, đây cũng là lý do các ngành ngoài phần mềm hầu như chưa thu được lợi ích năng suất từ AI. Nhân viên marketing, phân tích, quản lý và vận hành được hỗ trợ soạn email hay tóm tắt cuộc họp, rồi lại dùng chính thời gian tiết kiệm được để sửa những đầu ra "trông có vẻ đúng" nhưng không làm đúng việc cần làm.

Vì sao lập trình viên khác biệt

Tác giả bác bỏ ba cách giải thích quen thuộc: mô hình được huấn luyện trên núi dữ liệu mã nguồn, mã nguồn dễ kiểm chứng (biên dịch và vượt qua kiểm thử hay không), và các phòng thí nghiệm AI dồn nỗ lực vào coding agent (tác nhân lập trình) vì nhân viên của họ là kỹ sư.

Lý do: chính ông và nhiều kỹ sư khác vẫn đạt kết quả tốt với những việc không liên quan đến mã nguồn, như lên kế hoạch du lịch, tái cơ cấu ngân sách hay soạn đề xuất tài trợ.

Lý thuyết của tác giả đơn giản hơn: viết prompt tốt là lập trình, công việc trí óc giống hệt nhau, chỉ đổi cú pháp. Kỹ sư giỏi việc này vì đã làm nhiều năm, còn phần lớn người khác thì chưa từng làm.

Những thói quen mà lập trình viên có sẵn

Khi viết một hàm hay một lớp, lập trình viên phải:

• Quyết định đầu vào là gì và đến từ đâu
• Quyết định chính xác đầu ra phải trông như thế nào
• Chia vấn đề thành các bước đủ nhỏ để mỗi bước đều hiển nhiên đúng
• Nghĩ tới các trường hợp biên: danh sách rỗng, trường bị thiếu, người dùng làm điều không lường trước
• Quyết định cách biết rằng nó hoạt động

Không điều nào trong số đó liên quan đến việc gõ dấu chấm phẩy, nhưng tất cả đều là thứ phân biệt một prompt tốt với một prompt tồi. Trạng thái đầu và trạng thái đích là hai thứ đầu tiên lập trình viên viết ra, dù chỉ trong đầu — và đó chính là thứ còn thiếu trong phiên làm việc của người bạn giáo sư.

Tác giả đưa ra so sánh: người không lập trình yêu cầu tác nhân "tổng hợp một báo cáo về doanh số quý 3". Kỹ sư, gần như theo phản xạ, hỏi một câu khác: dữ liệu nào, trong tệp nào, phân tách theo tiêu chí gì, so sánh với mốc nào, ở định dạng nào, và xử lý ra sao với hai khu vực đã tái cơ cấu giữa quý.

Bài học từ trình biên dịch

Mỗi lập trình viên đều từng được nhắc đi nhắc lại, tức thì và không khoan nhượng, rằng máy tính làm điều bạn nói chứ không phải điều bạn muốn. Người không lập trình thì dành cả sự nghiệp giao tiếp với con người — những người tự lấp đầy khoảng trống bằng bối cảnh chung và lẽ thường, và sẽ hỏi lại khi không hiểu.

Mô hình ngôn ngữ lớn (LLM) cũng lấp đầy khoảng trống, nhưng bằng phỏng đoán hợp lý nhất và hiếm khi hỏi lại. Một prompt mơ hồ không báo lỗi: mô hình sẽ ảo giác (hallucinate) ra ý bạn muốn, trả về thứ trông gần đúng, và để bạn tự phát hiện chỗ sai. Bản năng của kỹ sư là nghi ngờ đầu ra "trông gần đúng"; bản năng của phần lớn người khác là chấp nhận nó.

Khoảng cách còn rộng hơn khi đầu ra sai. Kỹ sư gỡ lỗi (debug): đặt giả thuyết về chỗ nào trong chỉ dẫn của mình đã dẫn mô hình đi lệch, sửa đúng chỗ đó rồi chạy lại. Người không lập trình thường gửi lại y nguyên prompt, thêm câu "hãy chính xác hơn", hoặc kết luận công cụ không dùng được. Họ chưa từng phải xây thói quen coi một kết quả tồi là thông tin về chính đầu vào của mình.

Kỹ sư không thông minh hơn. Kỹ sư chỉ bị trình biên dịch bắt lỗi đến mức thành phản xạ.

Bổ sung cho luận điểm cũ

Tác giả cho rằng điều này làm phức tạp thêm lập luận ông viết hồi tháng 5: rằng kiến thức chuyên ngành (domain expertise) mới là lợi thế thực sự, và một chuyên gia có tác nhân AI bên cạnh có thể hiệu quả đến bất ngờ vì họ biết thế nào là đúng.

Ông vẫn tin điều đó, nhưng phân biệt hai kỹ năng. Biết thế nào là đúng là kỹ năng đánh giá, chỉ phát huy khi tác nhân đã tạo ra thứ đáng để đánh giá. Đưa nó tới đó là kỹ năng đặc tả, và kỹ năng này mang tính điện toán. Những người ngoài ngành thực sự thu được giá trị lớn từ các công cụ này thường có sẵn tư duy lập trình dưới một chức danh khác: nhân viên tài chính tự dựng bảng tính với bảng tra cứu, quản lý vận hành tự viết luồng Zapier, nhà nghiên cứu xử lý dữ liệu bằng R vì không ai khác làm. Họ vốn đã lập trình từ lâu, chỉ là không gọi tên như vậy.

Góc nhìn

Với kỹ sư và lập trình viên Việt Nam, kết luận thực dụng rất rõ: lợi thế cạnh tranh khi dùng AI không nằm ở việc thuộc mẹo viết prompt, mà ở kỷ luật đặc tả — nói rõ đầu vào, đầu ra, tiêu chí kiểm tra và cách xử lý trường hợp biên trước khi giao việc. Khi đưa AI vào quy trình của nhóm, việc huấn luyện đồng nghiệp ngoài ngành kỹ thuật nên bắt đầu từ tư duy này thay vì từ bộ prompt mẫu.

Ở chiều ngược lại, đây là lời nhắc rằng công cụ càng mạnh thì chất lượng chỉ dẫn càng quyết định. Một tác nhân viết mã nhanh đến đâu cũng vô nghĩa nếu yêu cầu ban đầu mơ hồ; và bước kiểm thử, review vẫn là nơi người kỹ sư giữ vai trò then chốt.