Một thời gian dài tôi hoài nghi LLM — mỗi lần dùng đều thất vọng với kết quả. Năm ngoái tôi thử Copilot và Cursor để tweak một game mình build, cả hai đều không tạo ra thay đổi chạy được. Ở job trước tôi thử Gemini để outline product brief và generate wireframe, nhưng cuối cùng vứt hết. Mỗi lần thử LLM, tôi đều dùng cho việc mình vốn đã giỏi — và chúng làm tệ hơn tôi.
Sau khi vào Jane Street mùa hè vừa rồi, tôi thấy AI support trở nên không thể thiếu. Có quá nhiều thứ mới với tôi, quá nhiều thứ tôi chưa giỏi, ví dụ OCaml và Bonsai. Nhưng bất ngờ lớn nhất là cách nó thay đổi đúng cái tôi giỏi nhất: design workflow.
Thay vì cặm cụi viết spec doc, build Figma mockup, viết proposal, rồi review implementation với dev, tôi đang build prototype feature làm đúng cái mình hình dung trong đầu. Thực tế trông như sau:
- Viết một đoạn mô tả vấn đề và đề xuất của mình
- Mở editor, start build, start server, mở Claude, dùng đoạn mô tả vừa viết làm prompt
- Cho functionality cơ bản chạy được để tự chứng minh là khả thi
- Iterate tới khi nào tôi muốn
- Push changes lên dev environment, hỏi users họ nghĩ sao
- Submit một feature (phiên bản pull request của bọn tôi) trông và hoạt động đúng như tôi muốn
Prototype trong codebase thật vs mockup
Một prototype feature trong codebase thật cảm giác tốt hơn ở gần như mọi mặt so với mockup và docs. Lấy ví dụ một prototype gần đây tôi làm — thêm LLM prompting vào JSQL input (JSQL là dialect SQL nội bộ chúng tôi dùng cho nhiều tool user-facing). Prototype này chạy thật, tôi sống với nó vài ngày và test. Claude cho tôi iterate vô hạn, không hề khó chịu khi tôi đổi ý lần thứ 50 hay yêu cầu tweak nhỏ. Tôi refine Submit button, thêm keyboard shortcut, tweak copy, điều chỉnh prompt, và thêm confirmation message được generate. Những cải thiện workflow như vậy ở job cũ sẽ mất nhiều ngày tới vài tuần engineering/design back-and-forth — hoặc nhiều khả năng là sẽ không bao giờ xảy ra.
Toàn bộ công sức cho feature này dồn vào cải thiện artifact thật, không phải vào việc phụ như tạo Figma component hay format doc.
Tôi mất một thời gian mới đến được workflow này. Khi mới vào mùa hè ngoái, tôi chỉ dùng AI cho task nhỏ như fix UX papercut. Với idea lớn hơn tôi vẫn dùng Figma và docs — khi thử làm chúng bằng Claude thì thất bại.
Nhưng 2 tháng gần đây những lần tôi với tới Figma đã giảm hẳn. Một combo của model tốt hơn, tôi quen tay hơn, và chọn scope đúng — AI giờ làm được cả thứ lớn. Không chỉ JSQL prompt mà cả nửa tá prototype khác thay đổi user-facing, data model, library — vài cái có diff 2000+ dòng. Tôi dùng nó implement interactive prototype cho app mới sau khi design ở Figma, và cho một số app mới tôi bỏ luôn Figma, iterate visual design từ đầu với Claude.
Empower designer, nhưng có trade-off
Là designer chuyện này rất empowering. Engineer có khả năng tạo working proof of concept khi có idea. Designer phải thuyết phục người khác làm hộ. Với idea như “direct LLM prompting trong JSQL input” — tôi đang đề xuất thứ mà feasibility ban đầu còn chưa rõ; bắt ai đó build prototype có thể lãng phí thời gian họ. Trong các case khác tôi có thể đề xuất thứ không rõ ràng đáp ứng user need. Dùng Claude để biến idea thành thật, tôi làm cho người khác dễ đánh giá hơn nhiều — họ chỉ cần dùng thử.
Nhưng có một downside: trong workflow này reviewer nhận một feature đã chín. Vậy có nghĩa họ không có input gì về functionality và chỉ review code? Review không phải việc vui — tương đương ở design world là nhận một wireframe chi tiết từ PM và bị bảo “làm cho đẹp”. Tôi muốn proposal của mình rõ ràng và hoàn chỉnh nhất có thể, nhưng vẫn muốn engineer teammate đối xử với nó như một mockup trong Figma — thứ chúng tôi cùng iterate trong design-space.
Giải pháp hiện tại của bọn tôi là nghĩ về những feature kiểu này khác đi. Tôi viết một note ngắn trong description: prototype là proposal doc sống, code là disposable, và việc của reviewer là cho feedback về design và user experience. Cuối cùng reviewer vẫn take over idea và implement trong một feature riêng — reference prototype nhưng own production code. Trong thực tế bọn tôi vẫn đang figure out cái gì hợp lý và cảm giác đúng với workflow mới này.
Nỗi sợ và bài học cũ
Có một nỗi sợ khác: design với Claude giữ tôi ngoài cái mindset sáng tạo, lưu loát, và mắc kẹt trong mindset iterative — bị giới hạn ở outcome tôi nghĩ Claude làm được. Điều này ok cho tool đã chín, nơi thay đổi mang tính iterative, nhưng có thể khiến tôi miss idea khi làm thứ mới.
Tension này quen thuộc. Khi tôi mới vào nghề năm 2011 có nhiều tranh luận về việc designer có nên code không. Bên phê phán cho rằng một khi đã bắt đầu programming, bạn ít làm big change hơn cho idea. Nhưng tôi thích làm website và thích programming, nên tôi tiếp tục viết code. Rồi khi frontend framework như React phổ biến và frontend dev phức tạp hơn, tôi quyết định specialize như nhiều người khác. Tôi vẫn làm personal project trong React — điều đó giúp tôi tương tác với dev — nhưng dành gần như toàn bộ thời gian ở công ty trong Figma và docs.
Nếu tôi vào Jane Street trước thời LLM, tôi nghĩ mình sẽ còn entrench sâu hơn trong Figma. Với JavaScript tôi ít nhất có kinh nghiệm; OCaml và Bonsai hoàn toàn mới, và contribute ở level kỹ thuật sẽ cảm thấy ngoài tầm với. Thay vào đó tôi đang quay lại làm thứ thật, và cảm giác tuyệt vời khi được làm việc trong medium đó. Tôi cảm thấy tự do hơn bao giờ hết để thử nghiệm.
Edwin là designer ở options desk tại Jane Street.