Hành trình đưa AI vào công việc của tôi

• Mitchell Hashimoto, người đã exit HashiCorp và hiện đang tạo ra Ghostty, đã tổng hợp quá trình tích hợp công cụ AI vào công việc thực tế của mình
• Ông chia quá trình này thành ba giai đoạn: kém hiệu quả → thích nghi → nâng cao năng suất, đồng thời ghi lại cụ thể những thử nghiệm sai, thất bại và bài học ở từng giai đoạn
• Sau khi nhận ra giới hạn của việc lập trình dựa trên chatbot, ông bắt đầu thực sự thấy giá trị khi chuyển sang các công cụ dựa trên agent
• Thông qua việc luyện tập tái hiện bằng agent các commit trước đây từng hoàn thành thủ công, ông đúc kết được rằng chia nhỏ công việc, tách biệt lập kế hoạch/thực thi và xác minh tự động là những yếu tố cốt lõi
• Tận dụng 30 phút cuối cùng của ngày làm việc để thực hiện các tác vụ tự động ban đêm, và giao các công việc đơn giản có thể lặp lại cho agent, từ đó đạt được mức cải thiện năng suất thực chất
• Hiện tại, ông đang ở giai đoạn luôn chạy một agent, đồng thời áp dụng "harness engineering" để ngăn lỗi, nhằm tối đa hóa hiệu quả cộng tác giữa AI và con người

---

Bối cảnh áp dụng và cách tiếp cận

• Mỗi khi áp dụng một công cụ mới, đều phải đi qua ba giai đoạn: kém hiệu quả → thích nghi → đổi mới
  • Do đã quen với workflow hiện có nên việc áp dụng ban đầu sẽ bất tiện, nhưng về dài hạn sẽ dẫn tới cải thiện năng suất
• Thay vì kỳ vọng hoặc chỉ trích quá mức đối với công cụ AI, bài viết đưa ra một góc nhìn cân bằng dựa trên trải nghiệm sử dụng thực tế

Bước 1: Thoát khỏi chatbot

• Việc lập trình thông qua giao diện chatbot như ChatGPT hay Gemini phụ thuộc vào kiến thức đã được huấn luyện sẵn, và việc sửa lỗi lại dựa vào phản hồi lặp đi lặp lại của con người nên kém hiệu quả
• Khoảnh khắc "gây kinh ngạc" đầu tiên là khi ông dán ảnh chụp màn hình command palette của Zed vào Gemini để tái hiện bằng SwiftUI, và điều này đã trở thành nền tảng của command palette trên macOS của Ghostty
• Tuy nhiên, trong bối cảnh dự án brownfield (codebase sẵn có), chatbot thường tạo ra kết quả tệ, và quá trình copy-paste mã nguồn cùng đầu ra còn kém hiệu quả hơn cả việc tự làm trực tiếp
• Muốn tạo ra giá trị thì nhất thiết phải dùng agent; ở đây, agent là công cụ cho phép LLM lặp lại các hành động bên ngoài, tối thiểu cần có khả năng đọc file, chạy chương trình và thực hiện HTTP request

Bước 2: Tái hiện công việc của chính mình bằng agent

• Khi lần đầu dùng Claude Code, ông không hài lòng với kết quả, và việc chỉnh sửa lại còn mất thời gian hơn tự làm
• Thay vì bỏ cuộc, ông liên tục luyện tập bằng cách tái hiện y hệt các commit thủ công bằng agent
  • Đây là một quá trình đau đớn vì phải làm cùng một việc hai lần (thủ công + agent), nhưng ma sát khi áp dụng công cụ mới là điều tự nhiên
• Trong quá trình đó, ông tự rút ra 3 nguyên tắc cốt lõi:
  • Hãy chia session thành những đơn vị công việc rõ ràng và có thể thực thi
  • Với các yêu cầu mơ hồ, hãy tách riêng session lập kế hoạch và session thực thi
  • Nếu cung cấp cho agent phương tiện xác minh công việc, nó có thể tự sửa sai và ngăn regression
• Việc hiểu được những mảng mà agent làm không tốt, và biết khi nào không nên dùng nó, cũng là một yếu tố lớn giúp nâng cao hiệu quả
• Ở giai đoạn này, ông chưa cảm nhận được mức tăng hiệu quả ròng, nhưng đã chấp nhận agent như một công cụ một cách thỏa đáng

Bước 3: Tận dụng agent vào cuối ngày

• Ông áp dụng mô hình dành 30 phút cuối mỗi ngày để khởi động công việc cho agent
  • Giả thuyết là có thể đạt hiệu quả nếu agent tiếp tục tạo tiến triển trong lúc bản thân không làm việc
• Có 3 loại công việc tỏ ra hiệu quả:
  • Session deep research: khảo sát các thư viện có giấy phép cụ thể trong một ngôn ngữ nhất định, rồi tạo bản tóm tắt nhiều trang về ưu nhược điểm, mức độ hoạt động phát triển, phản ứng cộng đồng, v.v.
  • Khám phá ý tưởng mơ hồ bằng các agent chạy song song: không nhằm mục đích phát hành, mà để phát hiện các biến số chưa biết cho công việc của ngày hôm sau
  • Phân loại/review issue và PR: dùng gh (GitHub CLI) để triage issue bằng các agent song song; agent không trả lời trực tiếp mà chỉ tạo báo cáo để tham khảo vào hôm sau
• Ông không để agent lặp đi lặp lại suốt đêm; phần lớn đều hoàn tất trong vòng 30 phút
• Bằng cách chuyển khoảng thời gian mệt mỏi ở cuối ngày sang cho agent, ông có được hiệu ứng "warm start" vào sáng hôm sau

Bước 4: Giao hẳn công việc chắc chắn làm được

• Sau khi xác định được những công việc mà agent gần như chắc chắn sẽ làm tốt, ông giao chúng cho agent chạy nền và tập trung vào việc khác
• Mỗi sáng, ông lọc thủ công kết quả triage từ đêm hôm trước để chọn ra các issue phù hợp cho agent, rồi chạy từng việc một
• Trong khoảng thời gian đó, thay vì lướt mạng xã hội hay xem video, ông tự làm công việc tư duy sâu theo cách cũ trước thời AI
• Việc tắt thông báo desktop của agent là then chốt: chi phí chuyển đổi ngữ cảnh rất lớn, nên hiệu quả hơn khi agent không làm gián đoạn con người mà được kiểm tra vào những lúc nghỉ tự nhiên
• Đối với lập luận từ bài nghiên cứu về hình thành kỹ năng của Anthropic: ông chấp nhận từ bỏ việc hình thành kỹ năng ở những công việc đã giao cho agent, nhưng với các công việc vẫn tiếp tục làm thủ công thì quá trình hình thành kỹ năng vẫn tự nhiên tiếp diễn
• Ở giai đoạn này, ông đã đạt tới mức "không thể quay lại như trước"; lợi ích lớn nhất là có thể tập trung vào những công việc mình thích

Bước 5: Harness engineering

• Agent hiệu quả nhất khi đưa ra kết quả đúng ngay từ lần đầu, hoặc ít nhất chỉ cần chỉnh sửa tối thiểu
• Mỗi khi agent mắc lỗi, việc thiết kế giải pháp để nó không lặp lại cùng một lỗi nữa chính là khái niệm "harness engineering"
• Có hai hình thức:
  • Cải thiện prompt ngầm (AGENTS.md): khi agent chạy sai lệnh hoặc tìm sai API, ghi lại trong file AGENTS.md để xử lý — có ví dụ thực tế trong repository Ghostty
  • Công cụ được lập trình sẵn: viết script để chụp ảnh màn hình, chạy test có lọc, v.v., rồi thông báo sự tồn tại của các công cụ đó trong AGENTS.md
• Hiện tại ông đang ở giai đoạn này, tích cực đầu tư vào việc ngăn hành vi xấu của agent và xác minh hành vi tốt

Bước 6: Luôn duy trì trạng thái đang chạy agent

• Song song với Bước 5, ông đặt mục tiêu luôn có một agent đang chạy nền
• Ông thích các mô hình chậm nhưng cho kết quả chất lượng cao, chẳng hạn deep mode của Amp (dựa trên GPT-5.2-Codex), dù mất hơn 30 phút
• Hiện tại ông không chạy song song nhiều agent, và cho rằng sự cân bằng giữa một agent và công việc thủ công là phù hợp
• Trên thực tế, agent chạy nền chỉ chiếm khoảng 10~20% thời gian làm việc, và ông vẫn đang cố gắng cải thiện tỷ lệ này
• Mục tiêu không phải là cứ chạy agent bằng mọi giá, mà chỉ chạy khi thực sự có công việc hữu ích để giao; xây dựng luồng công việc chất lượng cao có thể ủy quyền là điều quan trọng dù có AI hay không

Trạng thái hiện tại và góc nhìn

• Ông đang tạo ra kết quả với công cụ AI, đồng thời tiếp cận nó bằng một góc nhìn cân bằng dựa trên thực tế
• Ông không làm việc cho, đầu tư vào hay tư vấn cho công ty AI nào; bất kể AI có tồn tại hay không, động lực cốt lõi vẫn là niềm vui được tạo ra sản phẩm như một người thợ phần mềm
• Ông cũng bày tỏ lo ngại sâu sắc về vấn đề hình thành kỹ năng của các lập trình viên junior có nền tảng còn yếu
• Vì tốc độ đổi mới của mô hình rất nhanh, cần liên tục xem xét lại nhận định về những mảng mà agent chưa làm được
• Việc có dùng AI hay không là lựa chọn cá nhân, và bài viết này nhằm chia sẻ một ví dụ cá nhân về cách khám phá và tận dụng công cụ

[GN⁺]

Ý kiến trên Hacker News

• Mấu chốt là chia phiên làm việc thành các đơn vị công việc rõ ràng và có thể thực thi
  Nếu đưa chỉ dẫn quá chi tiết thì chẳng còn lý do gì để dùng LLM, còn nếu quá rộng kiểu “hãy làm một ứng dụng Facebook cho chó” thì chỉ ra được mấy prototype vô dụng
  Cuối cùng, việc dùng LLM cho code thành công chính là tìm ra phạm vi phù hợp này

  • Phần tôi thích nhất khi dùng công cụ AI chính là xây dựng trực giác này
    Quá trình cảm nhận xem nên giao loại việc nào thì cho kết quả tốt, rồi điều chỉnh phạm vi cho phù hợp, mang lại niềm vui khá giống với việc mô-đun hóa trong lập trình
  • Tôi cũng từng thất bại vì đưa ra yêu cầu quá lớn như ví dụ “Facebook for dogs”
    Với Lovable, tôi có cảm giác ngay từ onboarding đã bị dẫn tới thất bại, còn khi dùng Claude Code và chia nhỏ để làm dần thì thành công hơn hẳn
  • Nếu chỉ dùng LLM để tìm ví dụ cú pháp for thì khá tiện vì giảm được chuyển đổi ngữ cảnh
    Ban đầu tôi chủ yếu dùng nó như công cụ hỗ trợ viết code đơn giản kiểu đó
  • Càng về sau khi model tiến bộ, tôi có cảm giác giới hạn trên của phạm vi phù hợp lại tăng lên sau mỗi 6~8 tuần
  • Có lần tôi bảo “hãy in output ra” thì nó thật sự phản ứng bằng cách chỉ thêm mỗi print(output)
    Việc qua lại giữa ngôn ngữ tự nhiên và code lại khiến tôi thấy thoải mái về mặt tâm lý hơn

• Năm 2025 là năm các công cụ code bằng AI thực sự bước vào giai đoạn hữu dụng trong thực tế
  Trước đây, các model đời đầu như GPT-3 chỉ cho thấy tiềm năng, và vì thế đã tạo ra cả sự cường điệu lẫn hoài nghi quá mức
  Nhưng bây giờ nhiều lập trình viên đã tích hợp AI vào workflow thực tế
  Nếu bạn vẫn còn hoài nghi thì nên đọc bài của Mitchell và tự mình thử Claude Code

  • Tôi cũng nghĩ vậy. Tôi tò mò không biết 10 năm nữa người ta sẽ nhớ thời điểm nào là bước ngoặt
    Có thời từng nói rất nhiều về “giới hạn dữ liệu”, nhưng sau khi Claude Code, Sonnet 4.5 và Opus 4.5 xuất hiện thì bầu không khí đã thay đổi hoàn toàn
  • Tôi muốn biết có lý do gì để dùng Claude Code thay vì Codex hay Gemini không
    Hai model kia có vẻ tương tự, còn Claude thì tôi vẫn chưa thử vì nghe nói giới hạn sử dụng của gói cước hết rất nhanh
  • Nhưng tôi vẫn lo về một cấu trúc ngành công nghiệp lấy cường điệu làm trung tâm
    Tôi sợ giới quản lý chỉ coi trọng tốc độ và sản lượng rồi tạo ra một đống code không thể duy trì nổi

• Cách tiếp cận “Don’t draw the owl” cũng khớp với trải nghiệm của tôi
  Vấn đề là LLM ngày càng trôi dạt khỏi các ràng buộc thực tế
  Vì vậy tôi tách riêng: chat dùng cho thảo luận thiết kế, còn agent chỉ giao các diff hẹp và có thể kiểm chứng
  Khi vòng lặp này ổn định, nó không còn là đồ chơi nữa mà trở thành đòn bẩy thực sự, và tôi đã nhiều lần deploy tính năng thật cho dự án thực tế

  • Có người nhận xét văn phong của bài này giống LLM
    Dạo này những cấu trúc câu mang tính khuôn mẫu như vậy cũng đang xuất hiện ngày càng nhiều ở cả con người, khá thú vị
  • Tôi cũng thấy cách tiếp cận này thật ra không khác mấy so với cách lẽ ra chúng ta vẫn nên viết phần mềm từ trước đến nay

• Vì thấy ngày càng nhiều thảo luận về Opus 4.5 nên tôi đã tự thử, và cảm nhận được rằng mô hình agent giờ thực sự đã trở nên hữu ích
  Dù hiện tại tôi vẫn chủ yếu dùng cho các tác vụ đơn giản, nhưng khá hài lòng

• LLM không hợp với tôi
  Năng lực tư duy và sáng tạo của con người là thứ tạo nên sự khác biệt của chúng ta, và tôi cảm thấy giao điều đó cho máy móc là tự làm mình yếu đi
  Là một lập trình viên Rails, tôi đã dùng Zed cùng Claude Sonnet 4.x và Opus, nhưng ngày càng cảm thấy khả năng viết RSpec của mình bị giảm đi
  Cuối cùng tôi quay lại neovim và làm việc mà không dùng agent
  Sự tiện lợi rốt cuộc có thể dẫn đến sự thoái hóa của tư duy
  LLM là công cụ tiện dụng vĩ đại nhất mà con người từng tạo ra, nhưng tôi chọn giữ gìn kỹ năng và tư duy của mình

• Bài này cho cảm giác thực tế hơn và bớt cường điệu hơn hẳn so với các bài khác trên trang nhất

  • Cuối cùng cũng có một hướng dẫn từng bước để cả người hoài nghi cũng có thể làm theo
    Đây là cách tiếp cận thực tế, thay vì kiểu phóng đại như “tôi dùng vibe coding để làm ra một hệ điều hành”

• Thật thú vị khi thấy mọi người đều đang trải qua hành trình ứng dụng AI khá giống nhau
  Họ dùng song song nhiều model, áp vào các phần khác nhau của codebase, rồi để các model kiểm tra chéo lẫn nhau
  Tôi vẫn phải git reset thường xuyên, nhưng đang dần học được cách tránh điều đó hiệu quả hơn
  Cảm giác như đang sống trong thời đại của tự động hoàn thành cho bộ não

• Có người nói rằng “agent phải có khả năng đọc file, chạy chương trình và thực hiện HTTP request”,
  nhưng điều này gần như tương đương với ‘bộ ba chết người’ mà Simon Willison từng nói tới

  • Vì vậy tôi sẽ không bao giờ chạy thứ đó trên máy local của mình

• Việc cứ phải liên tục nói cho agent biết chỗ nào cần cải thiện thật phiền
  Mỗi lần lại phải sửa agent.md để đưa feedback, trong khi tôi muốn nó tự học rồi tự cải thiện

  • Nhưng điều mà một người xem là cải thiện thì với người khác có thể lại là mùi code
    Thêm vài dòng vào AGENTS.md cũng không phải chuyện gì to tát
    Nếu tạo lệnh /fix để nó tự động sửa và ghi lại tài liệu thì sẽ tiết kiệm thời gian kha khá
  • Ngược lại, tôi lại thích việc đưa feedback
    Nó cho tôi cảm giác mình vẫn nắm quyền chủ động trong kỹ thuật
    Đặc biệt là vì tôi có thể lặp nhanh giữa nghiên cứu và triển khai tính năng mới

• Nếu muốn hình dung cách tiếp cận này trông như thế nào trong thực tế,
  thì có thể tham khảo bài blog cũ của OP “Non-trivial Vibing” và thảo luận HN về bài đó