- Toàn bộ quá trình phát triển tính năng thông báo tự động cập nhật không gây phiền nhiễu của Ghostty trên macOS chủ yếu bằng các công cụ AI agentic coding đã được công khai; qua 16 phiên làm việc, với chi phí token $15.98, một tính năng có thể triển khai thực tế đã được hoàn thiện chỉ trong khoảng 8 giờ
- Sự việc lời nhắc cập nhật Ghostty làm gián đoạn phần demo trong keynote của OpenAI đã trở thành động lực để chuyển sang cách làm không dạng modal, hiển thị trạng thái cập nhật bằng một thành phần GUI nhỏ ở thanh tiêu đề hoặc phía dưới cửa sổ mà không làm gián đoạn công việc
- Trước khi dùng AI, trước tiên đã lập kế hoạch backend/frontend ở mức khái quát bằng cách tận dụng giao thức UI tùy chỉnh của framework Sparkle và titlebar accessory controller, rồi dùng AI như một công cụ tạo prototype
- Đã sử dụng cách tiếp cận theo từng bước gồm tạo mẫu UI, đổi hướng khi thất bại trong việc sửa lỗi, và các phiên dọn dẹp lặp lại (tài liệu hóa, refactor) để cải thiện hiệu quả cho các phiên AI sau này, cũng như tạo mã mô phỏng
- Nhấn mạnh giá trị của cách làm việc bất đồng bộ khi có thể làm việc khác như chuẩn bị bữa sáng cho gia đình trong lúc AI xử lý, đồng thời giữ nguyên nguyên tắc mọi mã do AI tạo ra đều phải được rà soát thủ công kỹ lưỡng trước khi phát hành và không triển khai bất kỳ đoạn mã nào bản thân không hiểu
Tổng quan tính năng
- Tính năng hoàn thiện là thông báo cập nhật không gây phiền nhiễu trên macOS, không che cửa sổ
- Hiển thị trạng thái cập nhật bên trong cửa sổ terminal mà không làm gián đoạn công việc như tạo cửa sổ mới hay giành focus
- Sự cố lời nhắc cập nhật Ghostty xuất hiện giữa keynote của OpenAI đã cho thấy cần cải thiện UX
- Quyết định làm thông báo cập nhật theo hướng không xâm nhập
- Thay vì cửa sổ popup, sẽ hiển thị một thành phần GUI nhỏ, không dạng modal, ở đâu đó để không làm phiền người dùng
- Vị trí hiển thị thông báo mặc định là bên phải thanh tiêu đề, nhưng cũng có phương án thay thế như overlay phía dưới cửa sổ tùy phong cách như khi thanh tiêu đề bị ẩn
- Xuyên suốt quá trình phát triển, đã tận dụng AI agent nhưng áp dụng chiến lược công cụ hỗ trợ do con người dẫn dắt, kết hợp với chỉnh sửa thủ công, trau chuốt và rà soát cuối cùng
Lập kế hoạch trước khi dùng AI
- Trước khi lôi công cụ AI ra dùng, trước tiên đã lập một kế hoạch khái quát
- Sau khi có ý tưởng sơ bộ về backend, tiếp tục hình dung frontend
- Có một ý tưởng còn mơ hồ là nhúng một nút nhỏ vào thanh tiêu đề
- Đã biết macOS hỗ trợ UI tùy chỉnh trên thanh tiêu đề thông qua titlebar accessory controller, nhưng chưa rõ cụ thể nó sẽ trông và hoạt động như thế nào
- Có đủ điểm khởi đầu để bắt tay vào làm
- AI là một công cụ tạo prototype cực kỳ tốt, nên chỉ cần biết mình chưa biết điều gì cũng đã đủ để bắt đầu
- Có cảm nhận đủ vững về bức tranh tổng thể
Phiên đầu tiên: tạo mẫu UI
- Prompt mở đầu của phiên agentic coding đầu tiên
- Tùy biến
SPUUserDriver để tạo thông báo cập nhật không xâm nhập và yêu cầu kích hoạt cài đặt
- Giới hạn chỉ thực hiện phần UI
- Yêu cầu lập kế hoạch tạo SwiftUI view có thể hiển thị các trạng thái khác nhau mà
SPUUserDriver yêu cầu
- Yêu cầu lập kế hoạch hiển thị ở góc trên bên phải thanh tiêu đề cửa sổ macOS
- Oracle là gì? - sub-agent chỉ đọc dành riêng cho Amp, dùng model chậm hơn và tốn chi phí cao hơn, thường giỏi suy luận hơn
- Quyết định trước tiên tập trung vào prototype UI
- Không giao cho agent xây toàn bộ tính năng ngay
- Thứ nhất, lúc đó vẫn chưa biết UI/UX nên trông như thế nào, nên không thể kỳ vọng AI thực hiện nhất quán điều này giữa nhiều thay đổi khác
- Thứ hai, các phần việc nhỏ sẽ dễ rà soát, dễ hiểu và dễ lặp lại hơn
- Yêu cầu chỉ viết kế hoạch và không viết mã
- Vì đây là một yêu cầu tương đối mơ hồ, nên cần rà soát kế hoạch trước khi để nó làm quá nhiều việc (và tiêu tốn nhiều token)
- Mẹo: xây dựng kế hoạch tổng quát với agent theo cách tương tác là bước đầu quan trọng cho những công việc không hề hiển nhiên
- Thường lưu thành file như
spec.md, rồi ở các phiên sau có thể yêu cầu “tham chiếu @spec.md và thực hiện một công việc nào đó”
- Agent đã đưa ra một kế hoạch đủ thuyết phục để cho phép triển khai
- UI được tạo ra có định hướng rất tốt
- Dù còn nhiều vấn đề cần trau chuốt như khoảng cách, màu sắc..., việc nhìn thấy UI đã tạo ra tia cảm hứng về thứ mình thực sự muốn
- Mẹo: dùng AI rất thường xuyên để tìm cảm hứng; trong trường hợp này đã giữ lại nhiều phần mã UI mà nó tạo ra (dù không phải tất cả), nhưng cũng rất hay có lúc chỉ prompt cho agent rồi bỏ toàn bộ để làm lại thủ công
- Giai đoạn sáng tạo kiểu “zero to one” rất khó và tốn thời gian, còn AI đóng vai trò nàng thơ rất hiệu quả
Đụng tường
- Từ chat 11 đến 14 đã rơi vào vùng slop
- Mã do agent tạo ra có lỗi nghiêm trọng và nó hoàn toàn thất bại trong việc sửa
- Bản thân tác giả cũng không biết cách sửa
- Đã thực hiện vài lần thử vận may để sửa lỗi
- Nếu agent giải quyết được thì có thể nghiên cứu và học hỏi
- Nếu thất bại thì gần như không tốn nhiều chi phí
- Nếu agent giải được nhưng bản thân không hiểu thì sẽ hoàn tác; không triển khai mã mà mình không hiểu
- Trong lúc nó tiếp tục thất bại, tác giả chuyển tab để tìm kiếm vấn đề và tự thử giải quyết
- Đến lúc này, tác giả nhận ra cần lùi lại, rà soát những gì đã làm và tự lập kế hoạch
- Cần thời gian để tự học và suy nghĩ phản biện
- AI lúc này không còn là lời giải mà trở thành gánh nặng kỹ thuật
Phiên dọn dẹp
- Đã dành vài phiên tiếp theo để hướng dẫn agent dọn dẹp mã
- Phiên thứ hai: chuyển một số method sang vị trí phù hợp hơn
- Chuyển các hàm fill background, foreground, badge từ
UpdateAccessoryView.swift sang UpdateViewModel.swift và khái quát hóa chúng hơn
- Phiên thứ ba: thêm tài liệu vào mã
- Cập nhật tài liệu của
UpdateBadge.swift
- Mẹo: thêm tài liệu giúp tự xác nhận lại mức độ hiểu của bản thân về mã, đồng thời giúp huấn luyện các agent tương lai sẽ đọc và chỉnh sửa đoạn mã này
- Agent hoạt động tốt hơn nhiều khi có cả mô tả ngôn ngữ tự nhiên lẫn mã
- Phiên thứ tư: chuyển view model sang vị trí phạm vi toàn ứng dụng
- Vì ban đầu công việc được đặt ở phạm vi cửa sổ, nhưng thông tin cập nhật lại thuộc phạm vi ứng dụng
- Trong quá trình đó, như thường lệ, cũng thực hiện một số thay đổi thủ công nhỏ
- Tầm quan trọng của giai đoạn dọn dẹp
- Muốn dọn dẹp hiệu quả thì cần hiểu khá rõ về mã, vì vậy nó buộc người làm không được mù quáng chấp nhận mã do AI viết ra
- Mã được tổ chức tốt hơn và có tài liệu tốt hơn sẽ giúp cải thiện hiệu quả của các phiên agentic sau này
- Tác giả đùa gọi đây là “anti-slop session”
Đối mặt với lỗi
- Quay lại lỗi đã phát hiện trong các phiên ban đầu
- Tốn thêm vài phiên nữa để tác nhân nhận ra điều này
- Bắt đầu một cách mơ hồ rồi dần dần cụ thể hóa cách tiếp cận
- Phiên mơ hồ đầu tiên: với tab native tiêu chuẩn thì update accessory view không hiển thị, cần làm cho nó luôn hiển thị trong titlebar của cửa sổ - thất bại
- Cụ thể hơn lần thứ hai: cập nhật các ràng buộc của thanh tab trong TerminalTabsTitlebarTahoe.swift để căn mép phải của thanh tab với mép trái của update accessory view - thất bại
- Thử một cách tiếp cận cụ thể khác lần thứ ba: sửa TitlebarTabsTahoeTerminalWindow.swift để biến thanh tab thành top accessory view thay vì bottom accessory view, như vậy tab sẽ nằm trong titlebar - thất bại
- Lần thử cuối: layout của right accessory view xung đột với cấu hình update accessory view trong TerminalWindow.swift, có thể ràng buộc để thanh tab luôn xuất hiện bên trái thông báo cập nhật không - thất bại
- Trong suốt toàn bộ quá trình này, cũng đã cố tự giải quyết bằng nghiên cứu thủ công và nỗ lực của con người
- Các prompt cụ thể hơn dựa trên những gì học được trong quá trình đó
- Nhìn chung rõ ràng là không hiệu quả
- Kết luận rằng không thể tự giải quyết, nên quyết định đổi hướng
- Với kiểu titlebar có vấn đề, đặt thông báo cập nhật ở góc dưới bên phải, chồng lên trên content view của cửa sổ thay vì titlebar
- Ghostty có cấu hình ẩn hoàn toàn titlebar, nên dù sao cũng phải hỗ trợ trường hợp này
- Ngay cả khi sau này có thể giải quyết vấn đề style của titlebar, vẫn cần hỗ trợ chế độ khác này
- Phiên tiếp theo tiến hành theo kế hoạch này với prompt rất cụ thể
- Mở rộng hệ thống Update để cũng hỗ trợ cách tiếp cận overlay trong TerminalView.swift
- Thông báo cập nhật phải xuất hiện ở đáy cửa sổ và hiển thị đè lên phần văn bản, tức là không thay đổi kích thước terminal view
- Mọi hành vi click đều giống accessory view
- Làm rất tốt, về sau có khá nhiều công việc chỉnh sửa thủ công (di chuyển, đổi tên, v.v.) nhưng phần cốt lõi thì vững chắc
Bắt đầu backend
- Cảm thấy UI đã đủ ổn
- Có ghi chú lại nhiều vấn đề cần chỉnh sau, nhưng chủ yếu muốn chuyển sang phần backend để phát hiện những ẩn số chưa biết có thể phá hỏng kế hoạch
- Tự tạo thủ công một file scaffold với các hàm chưa hoàn chỉnh và nhiều chú thích
TODO. Bắt đầu phiên mới
- Yêu cầu hoàn thiện UpdateDriver.swift và đọc tài liệu Sparkle để hiểu tính năng
- Mẹo: AI rất giỏi trong việc điền vào chỗ trống hoặc vẽ nốt phần còn lại của con cú
- Mẫu tạo scaffold bằng tên hàm mang tính mô tả, tham số, chú thích todo, v.v. là rất phổ biến và hoạt động tốt
- Thực tế là nó đã làm một công việc rất tệ, nên đã bỏ toàn bộ số code này
- Code được tạo ra có chạy, nhưng rõ ràng là cách tiếp cận sai
- Nó trộn lẫn nhiều mối quan tâm khác nhau và cách lưu state trong driver là sai rành rành
- Khi nghiên cứu những gì nó làm, nhận ra view model được cấu trúc theo cách chưa tối ưu
- Để cung cấp framework tốt hơn cho AI (và cho con người nếu chọn tự viết), chuyển sang chế độ dọn dẹp
Dọn dẹp lớn lần nữa
- Theo kinh nghiệm, độ gọn gàng của frontend UI và backend business logic thường được quyết định bởi chất lượng của view model ở giữa
- Dành thời gian tái cấu trúc view model bằng tay
- Chuyển từ struct có quá nhiều optional sang tagged union, đồng thời đổi tên và di chuyển một số type
- Theo kinh nghiệm, biết rằng chút công việc thủ công nhỏ ở đoạn giữa này sẽ dẫn tác nhân đến thành công trong các phiên frontend và backend sau đó
- Sau khi hoàn tất tái cấu trúc, việc đầu tiên làm là yêu cầu tác nhân hoàn thành nốt con cú một lần nữa
- Lần này là xem lại các thay đổi, cập nhật code phụ thuộc sang style mới và xóa code cũ
- Tiếp tục một loạt phiên dọn dẹp marathon
Mô phỏng
- Trong phiên UI đầu tiên, yêu cầu tác nhân tạo code demo để có thể thực sự nhìn thấy UI mà không cần kiểm tra cập nhật thật
- Luồng cập nhật có nhiều kịch bản, và đến thời điểm này mới chỉ test happy path
- Trong phiên tiếp theo, tách code mô phỏng ra file riêng và yêu cầu tác nhân tạo thêm nhiều kịch bản hơn
- Tách code mô phỏng cập nhật trong AppDelegate.swift ra file chuyên dụng trong Features/Update
- Bao gồm nhiều kịch bản mô phỏng khác nhau (happy path, không tìm thấy, lỗi, v.v.) để dễ thử nhiều bản demo
- Mẹo: tác nhân rất giỏi trong việc tạo test và mô phỏng
- Code mô phỏng được tạo ở đây thành thật mà nói là khá tệ, nhưng nó hoạt động và không phải là một phần của binary phát hành, nên chất lượng không quan trọng
- Thậm chí còn không dọn dẹp thêm ngoài những điều cơ bản có thể thấy trong phiên
- Chạy nhiều mô phỏng khác nhau và phát hiện ra một số cải tiến UX
Chặng cuối
- Đến thời điểm này đã có backend và frontend hoạt động, chỉ cần nối chúng lại
- Trong phiên tiếp theo, prompt cho tác nhân
- Tạo lớp UpdateController tương tự SPUStandardUpdaterController.m của Sparkle nhưng dành cho kiểu updater
- Cần qua lại đôi chút và chỉnh sửa thủ công, nhưng cuối cùng cũng làm được
- Sau đó thêm một vài cải tiến nhỏ
- Với trạng thái có thể cập nhật kèm appcast, xem SUAppcastItem và hiển thị thêm metadata liên quan khác nếu có thiết lập
- Ví dụ như content length để thể hiện kích thước
Còn gì khác?
- Với prompt cuối cùng cho agent luôn là hỏi xem còn bỏ sót gì không
- Thực hiện việc này dù có tự tay viết mã trực tiếp hay không
- Còn cải tiến nào khác có thể tạo trong tính năng Features/Update không, không viết mã, tư vấn kiểu Oracle, cân nhắc phần mã có thể bổ sung thêm unit test
- Vì đã làm nổi bật vấn đề thực tế nên yêu cầu nó triển khai
- Về sau có thể dễ dàng dọn dẹp bằng các commit tùy chọn, nên tôi nhận ra rằng bảo agent “làm tất cả” sẽ dễ hơn là hỏi những việc cụ thể cần làm
- Điểm thú vị của phiên này là agent bắt đầu lao thật sự vào một hang thỏ điên rồ, nên tôi phải can thiệp để bảo dừng lại
- "Dừng dừng dừng. Hủy tất cả các mục main actor"
- Tôi cũng phát hiện có cách tốt hơn, còn cách làm của mình thì hơi tệ
- Với thông báo lỗi, thay vì cắt ngắn thì chẳng phải có cách chuẩn của SwiftUI sao, cần thêm thành phần UI bổ sung để có thể xem toàn bộ thông báo
Chi phí và thời gian
- Tổng cộng công việc diễn ra trong 16 phiên riêng biệt, tiêu tốn $15.98 token trên Amp
- Tôi sẽ không đoán đây nhìn chung là đắt hay rẻ, nhưng cá nhân tôi đã tiêu nhiều hơn thế ở quán cà phê trong 2 ngày dành cho tính năng này
- Tôi ước tính tổng thời gian thực sự dành cho tính năng này là khoảng 8 tiếng
- Commit đầu tiên và cuối cùng trải dài trong 3 ngày, nhưng mỗi ngày tôi chỉ làm việc trên máy tính khoảng 4 tiếng
- Không phải toàn bộ thời gian đó đều dành riêng cho tính năng này
- Ví dụ, trong lúc làm tính năng này tôi còn làm những việc như phát hành bản cập nhật Ghostty, xuất hiện 1 tiếng với tư cách khách mời trên ThePrimeagen, và trình bày với tư cách khách mời tại sự kiện toàn công ty thường niên của Zoo
- Tôi có con nhỏ ở nhà nên “thời gian dùng máy tính” rất phải lên lịch và rất hạn chế
- Vì vậy ước tính 8 tiếng có lẽ còn là rộng tay
- Nhiều người trên Internet tranh luận về việc AI có giúp làm việc nhanh hơn hay không
- Trong trường hợp này, tôi nghĩ mình đã phát hành nhanh hơn so với nếu tự làm toàn bộ
- Đặc biệt vì các vòng lặp chỉnh style SwiftUI lặt vặt với cá nhân tôi quá nhàm chán và tốn thời gian, còn AI thì làm việc đó quá tốt
- Điều tôi thích nhất hơn cả tranh luận nhanh hơn/chậm hơn: AI có thể làm việc giúp tôi trong khi tôi đi làm việc khác
- Một trong các phiên dọn dẹp được chụp lại khi tôi đang làm bữa sáng cho gia đình
- Sẽ có đủ kiểu phản đối như “tôi không muốn code khi đang nấu ăn” hoặc “hãy hiện diện hơn”
- Nếu bạn muốn như vậy thì hoàn toàn ổn, còn trong trường hợp của tôi ở ví dụ này, tôi là người đầu tiên thức dậy trong nhà và đang chuẩn bị bữa sáng khi mọi người khác vẫn còn ngủ
- Tôi không làm thế này vào mọi khoảnh khắc mình thức
- Kết luận: nó hiệu quả với tôi
- Tôi hoàn toàn không cố thuyết phục bạn
- Tôi không có liên hệ tài chính với bất kỳ công ty AI nào
- Là một người có nhiều thành công với các công cụ AI và thích nói về chúng, tôi thường xuyên được mọi người yêu cầu chia sẻ ví dụ
- Đó chính là điều tôi đang làm ở đây
Kết luận
- Tính năng này đẹp, hoạt động rất tốt, và đã được merge sau lần rà soát thủ công cuối cùng
- "Rà soát thủ công cuối cùng" là cực kỳ cực kỳ cực kỳ quan trọng, đừng triển khai mã do AI viết nếu chưa rà soát thủ công kỹ lưỡng
- Nếu bạn là người dùng Ghostty đang dùng bản tip release thì hiện đã có thể dùng
- Nếu bạn dùng bản phát hành gắn tag thì sẽ có trong Ghostty 1.3
- Tôi là người công khai ủng hộ mạnh mẽ tầm quan trọng của việc chia sẻ công khai các phiên agentic coding
- Một trong các lý do là đây là cách cực kỳ mạnh mẽ để hướng dẫn người khác cách sử dụng hiệu quả các công cụ này
- Tôi hy vọng bài viết này sẽ giúp thể hiện điều đó
2 bình luận
Ý kiến trên Hacker News
Tôi thường dùng AI như một công cụ truyền cảm hứng; lần này cũng vậy, tôi giữ lại khá nhiều mã UI do AI tạo ra, nhưng đôi khi tôi giao cho agent làm rồi bỏ hết và tự viết lại từ đầu (bằng tay!). Giai đoạn sáng tạo "từ 0 đến 1" lúc nào cũng rất khó và tốn thời gian, nên AI thực sự xuất sắc trong vai trò nàng thơ của tôi. Đó chính là ưu điểm lớn nhất của các code agent. Nhiều người lo về khả năng bảo trì hay sự rối rắm của các dự án lấy AI làm trung tâm, nhưng tôi không bận tâm. Chỉ cần có thể nhanh chóng đạt đến trạng thái mà mình thật sự sờ mó được tính năng của dự án và tiếp tục chỉnh sửa nó, thì sau đó mọi thứ sẽ tăng tốc hẳn. Với tôi, 80% chi phí lớn nhất trong lập trình nằm ở chỗ đi đến được "thời khắc vàng" đó. Vì vậy, thành thật mà nói tôi không thật sự hiểu các ý kiến phản đối code agent. Ngay cả khi thứ còn lại chỉ là đoạn mã cuối cùng bị vứt bỏ, tôi vẫn thấy bản thân nó đã có giá trị rõ ràng. PS. Với bacon thì nhất định phải cân bằng trọng lượng
Gần đây tôi có nói chuyện với ai đó về chủ đề này, và tôi cũng phần lớn đồng ý. Những công cụ này rất tuyệt ở chỗ chúng giúp tạo ra prototype để có thể trực tiếp tương tác và thử nghiệm ý tưởng một cách dễ dàng. Tuy nhiên có hai vấn đề. Thứ nhất, vốn đã rất phiền khi phải thuyết phục rằng một prototype trông gần như hoàn thiện thực ra vẫn còn rất xa mới sẵn sàng cho production, mà mã dựa trên LLM còn xa production hơn nhiều so với prototype tôi từng làm theo cách cũ. Thứ hai, với prototype tự tay làm, tôi học được trực tiếp về tech stack và cách triển khai. Mục tiêu chính là làm cho nhanh, nhưng trong quá trình đó có rất nhiều bài học kỹ thuật, và thường thì prototype của tôi còn định hình cả hướng kỹ thuật sau này. Trong khi đó, prototype dựa trên LLM thì chính phần mã đó gần như vô dụng, và nếu thực sự bắt đầu làm gì đó thì gần như phải làm lại từ đầu. Cảm giác là mình đã kiểm chứng ý tưởng, nhưng hoàn toàn chưa kiểm chứng kỹ thuật hay thiết kế. Dù vậy tôi vẫn nghĩ nó hữu ích. Tôi tin vào việc "prototype phải thật nhanh", và nhờ dùng LLM tôi đã có thể lắp ghép cả những hệ thống khá lớn gần như ngay lập tức. Chỉ là cần thay đổi khái niệm về quy trình. Prototype không dùng LLM tương đương khoảng bước 4~5 trên thang 10 bước, còn prototype dùng LLM thì gần với bước 2 hơn. Điều đó không xấu, nhưng cần điều chỉnh kỳ vọng rằng khối lượng công việc còn lại sau prototype giờ nhiều hơn trước
Giá trị của bạn nằm ở chỗ "khi đưa dự án đến mức có thể chạy được đôi chút thì tiến độ sẽ lập tức tăng tốc". Còn với tôi, ngược lại, giai đoạn "từ 0 đến 1" mới là lúc đáng giá và thú vị nhất. Ở thời điểm đó có vô số khả năng và mình có thể tạo ra thứ chưa từng tồn tại. Nếu AI định hướng sẵn thì tôi có cảm giác sẽ mất đi khá nhiều sự sáng tạo đó
Qua ý kiến của bạn, có vẻ nỗi sợ trang giấy trắng là một mối bận tâm lớn. Tôi đồng cảm với việc công cụ giúp xóa bỏ điều đó có thể đóng góp rất lớn cho năng suất. Nhưng không phải ai cũng có cùng nỗi bận tâm. Vì phát triển phần mềm là một hoạt động rất mang tính cá nhân, nên workflow và trải nghiệm của mỗi người có thể khác nhau. Không phải cách của ai tốt hơn, mà điều quan trọng là công cụ phù hợp với từng người là khác nhau, và cần công nhận, tin tưởng trải nghiệm của mỗi cá nhân như chính nó. Trong các tranh cãi liên quan đến LLM, cả hai phía đều có xu hướng giả định rằng mình và đối phương là giống nhau
Tuần này tôi xem một cuộc phỏng vấn về bộ thiết lập phát triển của Mitchell, và khi được hỏi vì sao dùng neovim, câu trả lời "tôi không muốn công cụ viết code thay mình" để lại ấn tượng mạnh. Không phải để chỉ trích, mà điều đáng chú ý là ngay cả một lập trình viên xuất sắc như Mitchell cũng nhìn thấy giá trị ở LLM, khác với intellisense kiểu cũ
Tôi giải thích điều này với đồng nghiệp là mình đang "áp dụng định luật Cunningham cho chính bản thân" Cunningham's Law: 'Cách nhanh nhất để có câu trả lời đúng trên Internet không phải là đặt câu hỏi, mà là đăng một câu trả lời sai'. Khi nhìn vào màn hình trống mà không có gì trong đầu, tôi có thể ngồi đờ người rất lâu, nhưng nếu có thứ gì đó để phê bình thì tôi lập tức chuyển sang trạng thái làm việc hiệu quả
Tôi thật sự tôn trọng ý kiến của Mitchell về phản ứng với sự cố OpenAI, dù điều đó có lợi cho ghostty. Tôi hiếm khi thấy công ty phần mềm nào chủ động giảm bớt sự khó chịu hay bực bội của người dùng, nhất là nếu nghĩ đến những thứ như MS Auto Update; đây là một thay đổi rất đáng mừng. Bài viết này cũng cho thấy cách sử dụng AI có trách nhiệm trong lập trình; theo tôi thì nó hoàn toàn không phù hợp với định nghĩa vibe coding ban đầu vốn từng bị nhắc đến một cách cường điệu
Tôi nghĩ ngay chính cụm từ "vibe coding" ở đây đã là một khái niệm hoàn toàn không phù hợp trong lần này. Thuật ngữ đó đang bị lạm dụng và đem dùng khắp nơi
Tôi đồng ý với ý kiến "cách dùng AI có trách nhiệm trong lập trình". Đây không phải vibe coding mà là vibe engineering, khái niệm mà simonw lần đầu đưa ra ở đây. Bài liên quan
Nhân tiện, Ghostty gần đây đã bắt buộc phải công khai việc có sử dụng công cụ AI để viết code hay không liên kết PR liên quan
Bài này cho thấy vì sao agent AI có thế mạnh lớn khi làm việc với UI framework. Tôi cũng phát triển ứng dụng bằng Rust và GTK, và workflow rất giống như vậy. Không phải là tôi không biết cách triển khai thứ gì đó, mà là AI giúp xử lý phần lớn việc tìm kiếm lặp đi lặp lại và thử-sai nhàm chán trong công việc với UI framework, nên cực kỳ hữu ích. Mitchell hiểu toàn bộ mã trong suốt quá trình làm việc. Chính ở chỗ anh ấy đã biết mình cần làm gì, nên điều này hoàn toàn khác với thứ người ta gọi là "vibe coding". Không có đường tắt riêng nào để trở thành chuyên gia. Tôi thật sự rất thích Ghostty
Nhờ LLM mà việc viết code lại trở nên vui như xưa. Trong công việc, LLM giúp tôi vượt qua bước đầu khó nhất, nên có thể bắt tay vào làm rất nhanh. Nó cũng thật sự hữu ích khi cần hiểu một codebase mới hoặc viết những phần nhàm chán. Nhưng niềm vui thực sự bắt đầu ở các side project. Tôi có thể hiện thực hóa những ý tưởng ngẫu hứng cực kỳ nhanh. Giờ đây tôi không còn phải đổ hàng giờ vào việc viết boilerplate code hay vật lộn với tooling. Những phần tôi không quen thì giao cho agent, hoặc thử kéo ra tính năng chỉ bằng một prompt; nếu không ưng kết quả thì rollback ngay
Câu hỏi hơi lạc đề một chút, nhưng tôi không hiểu vì sao gần như mọi ứng dụng vẫn phải có framework tự cập nhật riêng. Không thể tích hợp chức năng đó vào app store hoặc package manager sao?
Trong hệ sinh thái macOS, kiểu chức năng này khá khó làm
Ví dụ trên Ubuntu thì việc này khá tiện. Nếu bạn trực tiếp tải và cài phiên bản mới nhất, sau đó bạn vẫn sẽ tiếp tục nhận được cập nhật tự động
Rốt cuộc thì chính phần bạn thừa nhận mình không giỏi — tức giai đoạn từ 0 đến 1 — sẽ trở thành lĩnh vực mà nếu giao cho AI, bạn sẽ không bao giờ tự học được. Nếu sau này bạn vẫn muốn tự làm được, thì bạn cần tự rèn luyện phần đó
Ghostty thực sự rất tốt, và tôi gần như đã bỏ iTerm, nhưng rồi nhấn
cmd-fmà chẳng có phản hồi gì nên đành thôi trang issue và phản hồiNếu ngay từ đầu đã có
cmd-f, tôi tự hỏi trong các bài viết về ghostty mọi người sẽ còn bàn những gì. Thành thật mà nói tôi cũng bắt đầu thấy hơi ngán khi cứ ở mọi bài đăng đều nghe chuyện này. Thực ra có lẽ đã có thể có nhiều thảo luận thú vị hơn về công cụ LLM hay cách viết code, nhưng rồi rốt cuộc ai cũng chỉ nói vềcmd-fThú vị là cuối tuần trước tôi đã dùng Claude để triển khai chức năng tìm kiếm cho Ghostty. Phần tìm kiếm thực tế thì đã có sẵn một đoạn mã hoạt động còn khá vụng về, nên phần lớn công việc là nối nó với UI. Chỉ sau hai phiên làm việc (tổng cộng khoảng 10 tiếng), tôi đã làm cho tìm kiếm cơ bản, tô sáng và di chuyển đến mục khớp trước/sau hoạt động được trên frontend Linux. Chức năng tìm kiếm này rõ ràng vẫn đang là WIP nên chưa thật sự sẵn sàng cho người dùng phổ thông. Trong lúc làm, tôi nhận ra ngay cả thứ trông có vẻ là tính năng "cơ bản" như thế này cũng phức tạp đến mức nào khi phải khiến nó hoạt động với văn bản dạng streaming
Tôi cũng thấy tiếc vì Ghostty quá tối giản nên nhanh chóng quay lại Warp. Nhân tiện, dung lượng scrollback buffer mặc định của Ghostty là khoảng 10MB, nhưng có thể điều chỉnh bao nhiêu cũng được trong cấu hình
Chức năng tìm kiếm này hiện được lên kế hoạch nhắm tới v1.3 vào tháng 3 năm 2026 liên kết roadmap
Đọc đoạn trong bài viết nói "hãy xem điều gì đã dẫn đến việc thêm tính năng này", tôi lại nghĩ đến việc chúng ta đang phải chịu đựng quá nhiều bất tiện trong OS. Trình chiếu hay chia sẻ màn hình đã là điều hiển nhiên suốt hàng chục năm rồi, vậy mà đến giờ ngay cả một thiết lập cơ bản để buộc chỉ cửa sổ trình chiếu được hiện trên màn hình vẫn còn khó đến vậy thì thật khó hiểu
Đây là Ghostty, công cụ mà nhà đồng sáng lập HashiCorp Mitchell Hashimoto gần đây đang dành gần như toàn bộ thời gian của mình cho nó.
Ghostty 1.0 phát hành - trình giả lập terminal tốc độ cao, đa nền tảng
libghostty sắp ra mắt
Trong khi ủng hộ agentic coding, ông ấy nói rằng việc chia sẻ session thực sự rất quan trọng,
và có vẻ hầu hết các liên kết đều dẫn tới các session AMP nhỉ Amp - công cụ agentic coding