You Can't Prompt the Room: The Last Skill AI Won't Replace

1. Thứ cuối cùng AI sẽ không lấy đi của người làm phần mềm

Balázs Horváth mở đầu bằng câu hỏi của cả talk: trong nghề phần mềm, đâu là thứ cuối cùng AI sẽ lấy đi khỏi con người? Câu trả lời của anh xuất phát từ một quan sát đơn giản. Khi viết code không còn là bottleneck nữa, việc thật sự quan trọng là tìm ra mình nên build cái gì. Và chuyện đó rốt cuộc quy về kỹ năng làm việc với con người, khả năng "work the room": ngồi cùng những người trong phòng họp, hiểu họ, dẫn dắt cuộc thảo luận để rút ra điều họ thật sự cần.

Tên talk chính là cách anh nói gọn ý này: bạn prompt được AI của mình, nhưng bạn không prompt được cả một căn phòng đầy người ("you can't prompt a room").

2. Hackathon nội bộ: 21 ý tưởng agent, 17 bị bỏ

Ví dụ đầu tiên đến từ chính công ty anh. Đầu năm nay, VisualLabs tổ chức một hackathon nội bộ. Cả đội đưa ra khoảng 21 ý tưởng agent, và 17 trong số đó bị bỏ giữa chừng. Lý do theo lời anh kể: chúng thật ra không tạo ra business value nào. Có cái thì đội không có quyền truy cập dữ liệu cần thiết, có cái thì đơn giản là build ra cũng chẳng có ý nghĩa gì.

Bốn ý tưởng còn lại mới là những cái tạo ra tác động rất lớn lên cách VisualLabs làm việc ngày nay. Với Balázs, đây là một ví dụ rất rõ cho việc phải chắc chắn mình đang build đúng thứ đáng build, chứ không phải build tất cả những gì build được.

3. Mười ba năm làm cầu nối giữa business và developer

Balázs kể lại con đường của mình. Suốt mười ba năm sự nghiệp, anh luôn là người đứng giữa, làm cầu nối giữa business, bộ phận IT và developer. Anh bắt đầu bằng việc test các functional design và specification, rồi chuyển sang tự viết chúng. Sau đó, trong vai trò functional consultant, anh làm việc với các chương trình ERP và CRM lớn ở Mỹ và Anh, trước khi thành lập VisualLabs.

Ở VisualLabs, việc anh làm về cơ bản là đào tạo đội của mình cách khai thác yêu cầu (elicit requirements) sao cho biến được chúng thành specification tốt: cho developer để build, cho consultant để cấu hình hệ thống, và gần đây nhất là cho AI để build.

Điều anh thấy gần như không thay đổi qua bao nhiêu năm là cách mình tương tác với khách hàng. Cách mình tương tác với hệ thống, với AI thì đang thay đổi rất nhiều, và đó là câu chuyện lớn lúc này. Nhưng nếu bạn đọc được không khí trong phòng (read the room) và khai thác được đúng requirement, bạn sẽ build ra phần mềm có giá trị hơn.

4. Bottleneck đã dời chỗ: từ viết code sang quyết định build gì

Theo Balázs, chuyển dịch lớn của hai, ba năm qua là: có được code và có khả năng build không còn là bottleneck của software development lifecycle nữa. Bottleneck thật bây giờ là đưa được đúng người vào phòng: các stakeholder, những người ra quyết định. Là có được quyền tiếp cận họ, có thời gian ngồi với họ, và khai thác được requirement từ họ.

Nói cách khác, việc khó nhất bây giờ là tìm ra cái gì nên được build. Anh nhắc lại câu chủ đề: bạn prompt được code của mình, prompt được AI, thậm chí prompt được cả bản specification, nhưng bạn không prompt được căn phòng của mình.

5. Hỏi model nên build gì, bạn nhận về một con ngựa nhanh hơn

Để giải thích vì sao model không tự làm được phần việc này, Balázs mượn câu chuyện quen thuộc gắn với Henry Ford. Nếu Ford hỏi khách hàng của mình họ cần gì, họ sẽ nói họ cần những con ngựa nhanh hơn. Nhưng thực tế ông build ra chiếc ô tô, và thành công rực rỡ với nó.

Những gì một model làm được, theo anh, rất giống câu trả lời "ngựa nhanh hơn" kia. Nếu bạn chỉ dùng AI để làm cho mọi thứ tốt hơn một chút, khả năng cao là bạn đang tái tạo lại những gì đã tồn tại, vì AI về bản chất được xây dựng để đưa ra câu trả lời phổ biến nhất. Việc của chúng ta là kéo AI ra khỏi mức trung bình đó, hướng về thứ thật sự tốt hơn cho mình, để không dừng ở một con ngựa nhanh hơn mà làm ra được chiếc ô tô, một bước nhảy lớn hơn hẳn so với những gì đang có.

Một ghi chú nhỏ: câu "faster horses" thường được gán cho Henry Ford, nhưng các nhà nghiên cứu trích dẫn chưa tìm được bằng chứng ông thật sự nói câu này (xem Quote Investigator). Dù vậy nó vẫn là cách nói phổ biến cho ý: khách hàng mô tả giải pháp theo những gì họ đã biết.

6. Bộ đồ nghề của analyst giờ là việc của người senior

Balázs gọi đây là một thế giới thú vị: viết code tốt không còn là kỹ năng quan trọng nhất. Kỹ năng thật bây giờ là trở thành analyst, dùng được bộ đồ nghề của analyst (analyst toolkit). Đó là những thứ như story mapping, business model canvas, value canvas (value proposition canvas), những công cụ "cũ mà tốt" mà các functional consultant, business analyst, hay người làm design thinking đã quá quen tay.

Trong số đó, anh chọn đi sâu vào story mapping, vì đây là bộ kỹ năng anh thấy có giá trị nhất.

7. Story map cho một hệ thống support: backbone, release 1 và backlog

Một story map bắt đầu bằng backbone: chuỗi các bước lớn trong quy trình. Khi đã có backbone và hiểu ở mỗi bước khách hàng, người dùng của bạn đang làm gì, bạn sẽ thấy cái gì giúp họ tiến lên được trong quy trình của mình.

Ví dụ của anh là story map cho một hệ thống support, với backbone gồm bốn bước: tiếp nhận liên hệ (contact), phân loại (triage), giải quyết hoặc chuyển tiếp (resolve or route), và đóng case (close). Story map giúp bạn hiểu từng giai đoạn của quy trình, rồi ghi các user story nằm bên dưới mỗi giai đoạn. Nó được cố ý giữ ở mức khá cao để bạn thấy bức tranh tổng thể.

Từ bức tranh đó, bạn quyết định release 1 sẽ build gì. Ở đây là bốn việc: nắm được ý định của người liên hệ (capture intent), phân loại mức độ khẩn (classify urgency), soạn một câu trả lời có căn cứ (draft a grounded answer), và ghi lại vào system of record. Về cơ bản đó là MVP của bạn: những thứ đầu tiên muốn build, và cũng là bốn user story đầu tiên.

Bên dưới là lớp user story thứ hai: đọc sentiment, route tới đúng team, gợi ý bước tiếp theo (suggest next action), chat, kiểm tra mức hài lòng (check satisfaction), và cứ thế tiếp. Những cái này nằm trong backlog.

8. Một user story: persona, nhu cầu, lý do, và vì sao AI hiểu dạng này

Theo Balázs, cách để có kết quả agentic thật tốt là tập trung vào chính các user story này, và dùng chúng làm phương tiện để mở ra thảo luận với stakeholder, với phía business, rồi cùng nhau làm rõ mỗi user story thật ra nói về điều gì.

Anh lấy user story thứ hai làm ví dụ: "As a support lead, I need open cases ranked by urgency so that none of the escalations slip." Tức là: với vai trò trưởng nhóm support, tôi cần các case đang mở được xếp theo mức độ khẩn, để không một escalation nào bị lọt.

Anh khuyên viết mọi user story theo đúng khuôn này, vì AI rất giỏi nhận dạng pattern, và nó thật sự đã được huấn luyện trên cấu trúc user story, một khuôn mẫu rất nổi tiếng và được dùng rộng rãi. Quay về thứ AI đã quen thì bạn sẽ có kết quả tốt hơn.

Mỗi user story gồm những phần quen thuộc: persona, cái gì (nhu cầu thật), và tại sao. Đóng gói các phần này lại và đưa cho AI, tất nhiên kèm acceptance criteria để từ đó suy ra test case, bạn sẽ có một thiết lập tốt và kết quả rất tốt.

As a <persona>, I need <what> so that <why>.

As a support lead, I need open cases ranked by urgency so that none of the escalations slip.

Rồi nếu bạn nối các user story với nhau thành chuỗi ("daisy chain"), bạn có được một hệ thống mạch lạc, từ đó viết ra specification và cuối cùng là code. Vì vậy, theo anh, software development lifecycle không thay đổi nhiều vì AI. Thứ thay đổi là bộ công cụ mình dùng.

9. Bốn câu hỏi trước khi agent bắt đầu

Khi làm việc với hệ thống và nghĩ xem mình muốn build gì, Balázs luôn đặt ra bốn câu hỏi.

Một: đây là vấn đề của ai? Mình đang thật sự giải quyết vấn đề cho ai? Để có thể gọi tên một người cụ thể, một persona cụ thể, và định lượng rõ ràng.

Hai: thắng với họ trông như thế nào? Khi nào họ thật sự thành công? Họ có đạt được đúng kết quả không? Mình có giúp họ đạt kết quả đó một cách nhanh, trơn tru hay an toàn không?

Ba: điều gì khiến họ từ chối dùng nó? Có thể là nó không có trên platform họ đang dùng. Có thể nó cồng kềnh, khó dùng. Có thể vướng chuyện bảo mật dữ liệu, nên họ sẽ không dùng.

Bốn: nó có thay đổi một quyết định không? Lý tưởng nhất, mình muốn tác động lên cách một người ra quyết định, và nghiêng họ về phía những quyết định tốt hơn. Vậy nó có thay đổi một quyết định không, và đó là quyết định nào?

Khi trả lời được bốn câu này, bạn sẽ nhận được phản hồi tốt hơn từ AI. Anh khuyên ghi tất cả lại trong một file Markdown "cũ mà tốt" ngay trong repository để AI truy cập được; nó sẽ lấy được nhiều context hơn hẳn từ đó.

1. Whose problem is this?
2. What does winning look like for them?
3. What would make them refuse to use it?
4. What decision does it change?

10. VAD: Value, Architecture, Design

Nếu bạn chỉ đưa ra một yêu cầu chung chung kiểu "build us an agent that handles support" (build cho chúng tôi một agent xử lý support), bạn sẽ không nhận được câu trả lời mình muốn.

Cách đội của Balázs luôn làm là đi từ value. Hiểu value được tạo ra thế nào, cái gì cấu thành value, quy trình hiện đang chạy ra sao, kiến trúc nào nằm bên dưới để đỡ quy trình đó, rồi mới bắt đầu phần design thật sự. Họ gọi lối tư duy này là VAD: Value → Architecture → Design, và đây là con đường họ luôn muốn đi qua.

Nghĩa là luôn giữ value trong đầu. Mình tạo ra value thế nào? Value mình đang tạo ra là gì? Khách hàng đang tìm kiếm value gì? Quy trình nào bên dưới đỡ cho nó, và mình có thể design một hệ thống xung quanh ra sao để hỗ trợ tốt nhất cho cả value lẫn quy trình, cùng những thay đổi quy trình cần làm trên đường đi.

11. "Đây chẳng phải là product management sao?"

Balázs đoán trước câu hỏi của khán giả: "Đây chẳng phải là product management cũ thôi sao?" Ở một mức độ nào đó, đúng vậy. Đây là một kỹ năng cũ, một cái nghề cũ, nhưng rất đáng để học lại. Lý do: nó đang trở thành moat (lợi thế phòng thủ), nếu có thể gọi như vậy, quyết định ai khai thác được đúng requirement và ai build được phần mềm tốt hơn.

Tất cả chúng ta đều có trong tay cùng một bộ công cụ, nên khác biệt sẽ nằm ở chỗ ai hiểu nhu cầu của business tốt hơn. Phần viết code thì ai cũng có thể giao cho model mới nhất, mạnh nhất. Vậy là kỹ năng cũ, nhưng kinh tế học mới ("old skill, new economics"), và là một chuyển dịch thật sự về phía bộ đồ nghề của analyst.

12. Build sai thứ một cách thật nhanh trông ra sao

Tiếp theo, Balázs mô tả build sai thứ trông như thế nào, qua một loạt anti-pattern.

Velocity tăng, adoption không tăng. Bạn ship tính năng mới liên tục như điên, nhưng adoption kém, người ta hầu như không dùng. Đó là một pattern rất tệ, và là thứ bạn cần xử lý.

Không ai dùng lần thứ hai. Người ta thử tính năng mới, đăng nhập vào hệ thống mới, chỗ mình vừa vibe code ra thứ mới nhất, điên rồ nhất, nhưng họ không quay lại dùng nữa. Vì vậy đừng nhìn vào thời gian sử dụng hay thời gian ở lại trên trang. Hãy nhìn vào tần suất của một hoạt động cụ thể.

Demo là sản phẩm bàn giao. Đây là một anti-pattern khác. Mình muốn chắc chắn người ta đưa được thứ đó vào production. Làm demo thì rất nhanh và trông rất đẹp, nhưng người ta không thật sự dùng. Một hệ thống demo không phải là một hệ thống live.

PRD chưa được người dùng thật thử. Nếu một PRD (product requirements document) chưa được test với người dùng thật, nếu bạn không thu được feedback đúng nghĩa từ một người dùng thật, khả năng cao nó sẽ không đi tới được môi trường live, và người ta sẽ không dùng nó.

13. Đưa người giỏi nhất lên thượng nguồn

Điều lớn nhất ở đây, theo Balázs, là mọi thứ cần dời lên thượng nguồn (upstream). Trước cơn bùng nổ AI, chúng ta để những người giỏi nhất của mình viết code. Bây giờ cần chuyển những người giỏi nhất đó về phía khách hàng, về phía các vấn đề của business, và dành nhiều thời gian hơn để quyết định build cái gì. Vì đó mới là phần đắt. Còn build thì thật ra đã trở nên rất rẻ.

14. Làm gì từ sáng thứ Hai

Balázs đưa ra vài việc bạn có thể bắt đầu ngay từ sáng thứ Hai, hoặc ngay ngày mai.

Audit tỷ lệ build sai. Bắt đầu tìm xem mình đang đo sai những thứ gì, rồi chỉnh lại cách đo, cách dùng thời gian, và thứ mình đang tìm kiếm. Con số "bao nhiêu tính năng đã ship trong quý trước" nên bị loại bỏ. Thay vào đó, hãy nhìn vào số tính năng mình ship mà thật sự được dùng nhiều hơn hai lần. Đó sẽ là một chuyển dịch tốt trong KPI, trong các metric của bạn.

Đưa một người senior lên thượng nguồn. Chuyển những subject matter expert thật sự sang vai trò gần khách hàng hơn, nơi họ có tác động thật lên việc cái gì được build. Trên slide, ý này được ghi là chuyển từ giám sát việc build sang discovery. Anh nói rõ, anh không bảo ai cũng phải trở thành functional consultant, product manager hay product owner. Ý anh là hãy kéo họ vào việc ra quyết định, vì họ là những người có nhiều kinh nghiệm nhất về cái gì đã chạy được trong quá khứ và cái gì không. Đảm bảo kinh nghiệm đó được đưa vào quyết định build cái gì là một khía cạnh cực kỳ quan trọng.

Chạy một buổi mapping trước khi build. Đây là việc anh vẫn làm, và khuyên mọi người bắt đầu làm. Hãy tạo một user story map, một business model canvas, hay bất kỳ kiểu mapping nào làm nổi bật value nằm ở đâu, để chắc chắn bạn hiểu mình tạo ra value như thế nào.

15. Build the right thing, not the next thing

Balázs khép lại: những gì anh trình bày phần lớn là nhiều thứ cũ được khâu lại với nhau, nhưng chúng thật sự tạo ra khác biệt. Lời mời của anh rất cụ thể: nếu bạn có một use case tốt muốn vibe code, hãy thử build nó một lần có user story và một lần không có user story, rồi so sánh khác biệt trong kết quả.

Khi anh tự làm thử điều này, đó là một chuyển biến lớn với chính anh, kiểu "Holy cow, mình vẫn cần đưa user story vào quá trình phát triển của mình." Theo cách đó, chúng ta build được thứ đúng, chứ không chỉ thứ tiếp theo.

Slide cuối nhắc lại thông điệp "Build the right thing. Not the next thing.", kèm mã QR để kết nối với anh trên LinkedIn. Anh rất sẵn lòng trò chuyện thêm, và cảm ơn mọi người đã theo dõi.