- Nhờ AI agent, giờ đây có thể tạo các ứng dụng native cá nhân chỉ trong vài giờ, khiến phần mềm dịch chuyển sang kiểu tùy biến theo phong cách Emacs
- MDV.app là một trình xem Markdown cho macOS, đã triển khai tìm kiếm, chỉ mục SQLite FTS, dấu trang, mục lục và ghi nhớ vị trí chỉ trong vài giờ
- Vấn đề các ứng dụng Electron mỗi cái mang theo một bản sao Chromium riêng và độ khó của phát triển UI native vốn rất lớn, nhưng Claude xử lý SwiftUI rất thành thạo
- Giống văn hóa Emacs, ngày càng có nhiều công cụ siêu đặc thù để tự giải quyết bất tiện riêng, và giá trị của ý tưởng, quan sát và prompt ngày càng lớn hơn sản phẩm hoàn chỉnh
- Agent coding giúp dễ gắn UI dễ dùng vào các side project và công cụ terminal, đồng thời biến việc làm UI native thành một việc thú vị
Lý do tự làm trình xem Markdown
- Trong phát triển phần mềm, Markdown đã được dùng như một ngôn ngữ chung từ trước cả LLM, và sau khi agent xuất hiện, các công cụ TUI lại tăng lên, khiến trải nghiệm cứ phải cuộn đọc Markdown trong terminal ngày càng khó chịu hơn
- Các trình xem Markdown TUI có glow của Charm và Markless do Josh tạo ra; Markless còn hỗ trợ duyệt mục lục, nhưng terminal nhìn chung dùng phông chữ đơn cách, nên đọc lâu khá mỏi mắt
- Trên macOS có các trình soạn thảo Markdown giao diện đồ họa như Obsidian, Typora, Bear và chúng dễ đọc, nhưng tất cả đều là trình soạn thảo, nên ngay khi mở tệp
.md, môi trường biên tập và cách bố trí cửa sổ hiện có sẽ bị xáo trộn
- Các trình xem Markdown trên App Store ban đầu có vẻ ổn, nhưng khi dùng thực tế thì lộ ra vấn đề như không có tìm kiếm, có mua hàng trong ứng dụng, hoặc không thể sao chép văn bản đã chọn vào clipboard
- Đến năm 2026, thay vì tiếp tục đi tìm một trình xem tạm được, tác giả chuyển hướng sang nhận định rằng có thể tạo trình xem Markdown mình muốn bằng AI agent
MDV.app được làm bằng Claude
- MDV.app đã được tạo ra chỉ trong vài giờ, đạt mức tốt hơn các trình xem Markdown chuyên dụng tìm thấy trên App Store, và thời gian tương tác thực tế chỉ khoảng 30 phút
- Tác giả đã thiết lập Xcode và git trên một chiếc MacBook cũ, dựng môi trường Claude, đồng thời việc chuẩn bị trước như tìm tài liệu hỗ trợ về Swift và thiết kế macOS đã được thực hiện từ vài tuần trước
- MDV không phải là ứng dụng macOS tốt nhất hay phần mềm đặc biệt xuất sắc, nhưng với vai trò trình xem Markdown chuyên dụng cho macOS thì nó đủ tốt hơn đáng kể và cải thiện lớn chất lượng cuộc sống
- Các tính năng chính của MDV gồm chọn và sao chép văn bản trong tài liệu, tìm kiếm chuỗi cố định, lập chỉ mục SQLite FTS cho mọi tệp Markdown trong lịch sử có thể chỉnh sửa, dấu trang bằng phím tắt và duyệt mục lục
- Khi chuyển qua lại giữa các tài liệu, nó nhớ vị trí và tiếp tục được cả sau khi khởi động lại, đồng thời cung cấp chủ đề màu và kiểu chữ dễ đọc, để khi nhấp vào tệp
.md thì môi trường đọc mong muốn mở ra ngay lập tức
Giới hạn của Electron và sự thay đổi của UI native
- Mỗi khi có tin nhắn Signal đến, màn hình lại nhấp nháy, và hiện tượng đó không dừng lại cho đến khi ứng dụng Signal được ẩn đi một cách tường minh, khiến sự nhấp nháy tinh vi kéo dài đến mức gần gây đau nửa đầu
- Hiện tượng này là do Signal là một ứng dụng Electron; bề ngoài trông như ứng dụng macOS native, nhưng thực chất là một bản sao Chromium đang render một trang web bí mật
- Gần như mọi ứng dụng UI xuất hiện trong 10 năm qua đều có vẻ như mang theo bản sao Chromium của riêng mình, và Electron tuy không phải lựa chọn tốt nhưng vẫn tồn tại như một phương án đủ dùng
- Trong lịch sử, việc tạo UI native thực sự rất khó, ngay cả việc tìm nhân lực ở mức bình thường để giao làm cũng khó, và các lập trình viên giỏi phát triển UI native cho macOS thì rất hiếm
- Claude không chỉ thay thế được một lập trình viên SwiftUI ở mức trung bình, mà còn thực sự được xem như một người phát triển SwiftUI rất thành thạo
Cách văn hóa Emacs lan ra toàn bộ phần mềm
- MDV đúng hơn nên được xem là thứ để người khác lấy ý tưởng rồi làm ra bản tốt hơn, giống như người dùng Emacs nhìn vào một cấu hình
.emacs lấp lánh, hơn là một sản phẩm hoàn chỉnh được khuyến nghị cài đặt để sử dụng
- Trong văn hóa Emacs, những người dùng lâu năm tạo ra các ứng dụng bằng elisp để giải quyết những bất tiện cá nhân ban đầu nảy sinh từ việc chỉnh sửa văn bản, và các công cụ đó mở rộng vượt xa phạm vi hợp lý mà một trình soạn thảo văn bản nên đảm nhiệm
- /r/emacs gần với văn hóa khoe thứ mình làm hơn là kiểu quảng bá sản phẩm như Product Hunt; dù có những gói elisp được dùng rộng rãi, nhưng ngoài Magit ra thì xu hướng chung vẫn là mỗi người lại tự làm một phiên bản còn lấp lánh hơn
- Điểm yếu của văn hóa Emacs là ngoài Magit ra, các gói phần lớn đều xấu, chậm và có trải nghiệm người dùng tệ mà chỉ sau thời gian dài vật lộn với elisp mới nhận ra được
- AI agent đã đẩy văn hóa đó ra ngoài Emacs, và khi chỉ cần có thể truy cập màn hình và đầu vào là đã có thể tạo UI native một cách ổn định, UI native chuyển từ phạm vi của những chương trình được đóng gói chuyên nghiệp sang phạm vi của tùy biến cá nhân
Khả năng của các công cụ native cá nhân
- Phần mềm bị Emacsification hóa phần lớn là phần mềm cá nhân chỉ hữu ích cho chính người tạo ra nó, và sẽ có ngày càng nhiều công cụ bị lãng quên giống như những chương trình elisp cũ còn sót lại trong
.emacs
- Đôi khi các chương trình như vậy có thể vượt qua ranh giới để trở nên hữu ích đến mức nhiều người cài đặt, nhưng ngay cả khi đó, thứ quan trọng nhất vẫn có thể không phải là sản phẩm đã phát hành hay mã nguồn
- Nếu agent đã viết toàn bộ mã SwiftUI, thì thay vì đọc kỹ mã nguồn, ý tưởng và quan sát rằng “cũng có thể làm được thứ như thế này và nó hoạt động tốt” sẽ trở nên quan trọng hơn
- Với kiểu phần mềm này, prompt có thể có giá trị hơn mã nguồn, và với những người đã quen tự vận hành để tạo ra phần mềm, mọi thứ trở nên có thể lập trình không chỉ về mặt kỹ thuật mà còn cả về mặt thực tiễn
- Gọi phần mềm do agent tạo ra là được “build” có vẻ như đã đánh giá quá cao lượng công sức bỏ vào; cảm giác thực tế gần hơn với việc cấu hình (configuring) trên một nền tảng bỗng trở nên dễ cấu hình hơn rất nhiều
- Các nhà phát triển dùng AI cuối cùng cũng đang hoàn thành những side project ngẫu nhiên đã chất đống suốt nhiều năm
- Giờ đây, những công cụ siêu đặc thù đó không chỉ đơn thuần được hoàn thiện mà còn có thể có UI dễ dùng, điều này làm suy yếu một phần lý do cũ rằng phải chấp nhận UI vụng về của Emacs
- Khả năng cải thiện các ứng dụng terminal giờ lớn hơn nhiều, và các công cụ như
iostat, iostat trên nhiều host, hay bpftrace cũng có thể được biến thành những dạng dễ hiểu hơn
- Sự phức tạp mà Brendan Gregg từng phải chấp nhận để có trực quan hóa terminal cho
bpftrace giờ không còn cần phải cam chịu nguyên trạng, và thực tế cũng đã có ví dụ tự làm
- Với tư cách là một nhà nghiên cứu lỗ hổng, tác giả thấy những tiến bộ của phát triển exploit dựa trên agent coding trong nửa đầu năm 2026 rất thú vị, nhưng với phần lớn mọi người đó là một thay đổi đi kèm nỗi sợ; ngược lại, việc tạo UI native trở nên thú vị là tin tốt gần như hoàn toàn
- Hãy thử tạo ra những công cụ quá mức cụ thể cho vấn đề của riêng mình, tận hưởng chúng một thời gian rồi chia sẻ, hoặc tốt hơn nữa là chia sẻ ảnh chụp màn hình và các prompt đã dùng
1 bình luận
Ý kiến trên Hacker News
Tôi nghĩ giờ là lúc các nerd giành lại những mảng mà phần lớn đã trở thành phần mềm chuyên dụng đóng gói sẵn: ứng dụng podcast, ứng dụng nghe nhạc, trình đọc feed, client Bluesky, ứng dụng ghi chú, ứng dụng bookmark/đọc sau trên desktop, chat và messenger, công cụ theo dõi thời gian, trình quản lý công thức nấu ăn, v.v.
Với Claude, hoàn toàn có thể tạo ra thứ đủ tốt, thậm chí tốt hơn các lựa chọn thay thế. Có thể không phải ứng dụng tốt nhất hay cạnh tranh toàn cầu, nhưng có thể là ứng dụng phù hợp hơn nhiều với cách làm việc kỳ quặc của chính mình
Music.app rất khó dùng, còn Apple thì đã tách phần cốt lõi ra thành MusicKit từ lâu rồi. Giờ sản phẩm thật sự là MusicKit, nên tôi không hiểu vì sao vẫn còn dùng Music.app, và đó là một thay đổi mới
Một thử nghiệm theo hướng đó là https://github.com/dharmatech/9social
Client đầu tiên được viết cho plan9, vì làm vậy sẽ giữ cho thiết kế được trung thực. Nếu nó chạy được trên plan9/rc/acme thì nó có lý
Demo video ở https://youtu.be/q6qVnlCjcAI, và bản hiện tại chưa tới 3000 dòng code
Nói về Emacs thì 9social lấy cảm hứng rất lớn từ dự án Emacs tên Org Social: https://github.com/tanrax/org-social
Đây là giao diện dạng bảng tính chưa hoàn chỉnh để nhập thời gian. Tôi làm nó cho công việc tư vấn nhưng chưa đi tới phần lưu dữ liệu. Có một thuật toán khá dễ thương có thể xử lý gần như mọi cách mọi người tự nhiên nhập thời gian, vì tôi ghét việc các công cụ theo dõi thời gian hiện có cứ ép nhập liệu có cấu trúc: https://stackoverflow.com/a/49185071/59087
Trình quản lý công thức nấu ăn: https://repo.autonoma.ca/repo/recipe-fiddle
Trong thời đại LLM, việc phân loại nguyên liệu và định dạng sang TeX để xuất bản PDF sẽ dễ hơn nhiều. Ý tưởng của dự án này là gần như chỉ cần copy/paste công thức từ web hoặc bản scan viết tay là nó tự định dạng
Trên F-Droid không có ứng dụng nào đáp ứng đủ các điều kiện này nên tôi tự làm APK luôn
Tôi nghĩ nhờ thời đại LLM mà việc sản xuất phần mềm đã trở nên quá dễ, nên mọi thứ giờ giống như file .emacs. Tức là mỗi cá nhân có một cái kén phần mềm hoàn toàn riêng tư và có thể tùy biến vô hạn
Như cách OP nói, bây giờ tự tạo giải pháp riêng còn dễ hơn cài hoặc học cái có sẵn
Lisp cũng là một phép so sánh hay. Một lời phê bình cũ về macro Lisp là mọi lập trình viên cuối cùng biến nó thành ngôn ngữ riêng tư của mình, khiến người khác không đọc nổi
Tôi cũng nhớ đến bài năm 2007 của Mark Tarver, "The Bipolar Lisp Programmer": https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%20Lisp%20Programmer&type=story&dateRange=all&sort=byDate&storyText=none&prefix
Ông nói về "brilliant bipolar mind", và điều đó cũng chạm khá thú vị tới thứ ngày nay thường được nhắc đến, dù mỉa mai hay nghiêm túc, là AI psychosis
Bài của Tarver https://www.marktarver.com/bipolar.html nói rằng kiểu "throw-away design" của cộng đồng Lisp rất hợp với BBM. Lisp khiến việc quăng ra một thứ gì đó quá dễ, nên ai cũng làm giải pháp riêng cho mình và thấy thế là đủ nếu nó quay lại phục vụ bản thân
Còn trong C/C++, làm ra thứ gì có ý nghĩa khó đến mức bản thân nó đã là một thành tựu, từ đó tạo động lực để viết tài liệu và cộng tác. Với nhà tuyển dụng, 10 người biết giao tiếp, viết tài liệu và làm việc cùng nhau hấp dẫn hơn 1 hacker Lisp khó thay thế
Khi sản xuất trở nên dễ, thì tiêu thụ trở thành nút thắt cổ chai, và việc chia sẻ trở nên khó hơn. File .emacs mang tính cá nhân như dấu vân tay; có thể lấy vài mảnh, nhưng không ai muốn dùng nguyên cái của người khác
Cái kén đó càng được tùy biến sâu thì người khác càng khó hiểu hoặc muốn dùng. Không chỉ chi phí nhận thức cao, mà còn khó chịu như mặc quần áo của người khác. Có lẽ nên gọi đây là AI duy ngã hơn là AI psychosis
Trong phần mềm, quản lý cấu hình đang trở thành phần khó. Chia sẻ source và quản lý version kiểu gì? Source là gì? Là prompt à? Ở cuối OP cũng nghiêng về việc chia sẻ screenshot và prompt hơn là code
Trên Show HN cũng từng có người thả bóng thử rằng vì code được sinh ra không còn là source nữa nên nên chia sẻ prompt, nhưng bị phản ứng mạnh từ những người hiểu chuyện: https://news.ycombinator.com/item?id=47213630
Áp lực mà GitHub đang chịu có lẽ cũng bắt nguồn từ xu hướng này. Người kế nhiệm nó sẽ trông ra sao thì chưa rõ, nhưng rốt cuộc sẽ cần xuất hiện. Hiện giờ vẫn như giai đoạn xe ngựa chưa mui
Điều quan trọng hơn là làm việc nhóm. Nếu ai cũng là BBM, hoặc mỗi chúng ta có cả một đội quân BBM điên cuồng chỉ phục vụ riêng mình 24/7, thì còn làm việc cùng nhau thế nào? Các cái kén sẽ giao tiếp và tương tác ra sao? Một đội ngũ toàn những người theo chủ nghĩa duy ngã AI nghe như mâu thuẫn
Những team và startup ở tuyến đầu của phát triển kiểu agent do AI dẫn dắt hẳn đang thật sự vấp phải chuyện này ngay bây giờ. Đại loại như ghép code tôi sinh ra với code bạn sinh ra như thế nào. Khả năng cao một phần lợi ích năng suất từ code sinh ra sẽ bị trả ngược lại vì những ma sát đó
Hơi tiếc là công khai người ta chưa nói nhiều về chuyện này. Không ai muốn là người đầu tiên ngồi xuống trong màn vỗ tay đứng bắt buộc, nhưng nếu cứ giả vờ đây là bữa trưa miễn phí không có nhược điểm thì thảo luận sẽ nhạt nhẽo và tiến hóa cũng chậm đi
Nếu những người đang làm công việc nghiêm túc và tiên tiến nhất với các công cụ mới không nói về nhược điểm, thì mọi câu chuyện về nhược điểm của AI trong phát triển phần mềm sẽ chỉ còn nằm trong tay phe hoài nghi cho rằng AI chẳng có giá trị gì. Không khí hiện nay khiến việc nói về bug tăng lên hay năng suất chững lại còn khó hơn nói về tận thế nhân loại
Tôi muốn biết thực sự chuyện gì đang xảy ra, mọi người ứng phó thế nào, và theo thời gian nó thay đổi ra sao. Chắc phải đi meetup mất
Tựa của bài nghiên cứu liên quan cũng là "Easier to Write, Harder to Read": https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702
Tại sao tôi phải đọc sản phẩm của một cuộc trò chuyện cụ thể với LLM? Chỉ cần biết chủ đề cuộc trò chuyện là tôi có thể tự có một cuộc trò chuyện tốt hơn
Phần mềm kiểu này cũng tương tự. Có thể có chút khác biệt về gu, nhưng nhìn chung ý tưởng và công thức mới là thứ quan trọng
Sẽ hay nếu có một thread "Vibe HN" hằng tháng
Tôi tò mò không biết có ai chia sẻ được video làm một WhatsApp tùy biến trong thời gian ngắn hơn không. Chưa kể còn chưa đụng tới bài toán kéo người khác vào dùng một messenger dựng tạm ngay tại chỗ
Giờ thì thành kiểu "tôi sẽ ném ticket này cho Claude, còn bạn thử bằng Copilot rồi so kết quả" hoặc "tôi tạo PR từ kết quả thô của tôi, còn bạn review bằng công cụ của bạn". Thành thật mà nói nó gần như vô nghĩa, và pair programming đã chết hẳn
Ai muốn ngồi xem chạy nhiều agent, sửa bug trên các worktree khác nhau, rồi chỉnh những chỗ agents.md không khớp chứ
Chúng tôi đang thúc đẩy xây một pipeline cloud hoàn toàn tự vận hành, còn ban quản lý có vẻ đang âm thầm ghìm lại. Có cảm giác họ hiểu rất đơn giản rằng khoảnh khắc chứng minh được nó thực sự bay được, sẽ có vài người mất đi chỗ ngồi êm ái
UNIX không phải là sản phẩm mà là môi trường tối ưu cho việc tạo công cụ và giải quyết vấn đề thực tế, còn các công cụ được viết bằng C. Trong lúc đó các BBM chắc bận với Lisp ở Boston
C++ lại là câu chuyện hoàn toàn khác, và ở đó thì cần IDE
Emacs có tính chất đó vì nó dùng Lisp. Xu hướng rộng hơn là lập trình viên tự tay làm mọi thứ đã được quan sát từ Lisp, và từng được gọi là The Lisp Curse
Nó bị gọi là lời nguyền vì lập trình viên ngừng cộng tác. Ai cũng thành pháp sư bị nhốt trong tòa tháp riêng, tiến bộ chung dừng lại và thời kỳ tăm tối kéo đến
Đúng là thời đại LLM đã tạo ra phần mềm cá nhân
Nhưng thành thật mà nói, thời gian tôi dùng Emacs không hề dạy tôi cách làm phần mềm cá nhân. Cấu hình Emacs của tôi cực kỳ dễ vỡ, và khi cố dùng chung giữa Windows với macOS thì thành ác mộng
Dự án đại học của tôi được viết bằng một tổ hợp quái dị giữa org-mode và một workflow nào đó để tạo ra file LaTeX đẹp, nhưng giờ tôi không thể giải thích cách compile lại nó. Nếu phải thử, chắc tôi sẽ nhờ LLM dịch thẳng sang LaTeX
Tôi muốn cuộc sống của mình càng ít bảo trì càng tốt, và việc tự làm mọi thứ không phải lúc nào cũng phù hợp với mục tiêu đó
Tôi từng viết lại một ứng dụng NETFX sang Rust, vì bực chuyện cài đặt mất 20 phút: https://github.com/bevan-philip/wlan-optimizer
Công việc thường nhật của lập trình viên là thay đổi hành vi của các hệ thống máy tính: local, remote, cloud, embedded, đủ cả. Yêu cầu thay đổi, phạm vi dao động, không gian vấn đề tiến hóa, và cặn lắng là điều không tránh khỏi
Ta phải liên tục di chuyển giữa các stack ngôn ngữ, kiểu dữ liệu, định dạng, công cụ CLI và web, giao thức, mô hình lập trình, ứng dụng mã nguồn mở và độc quyền
Vì thế phải luôn thích nghi, và control plane của riêng mình cũng phải thích ứng với thay đổi. Cốt lõi ở đây là tự động hóa. Mọi sự phiền toái nhỏ đều có thể và nên được tự động hóa. Điều đó đồng nghĩa với việc liên tục biến đổi workflow, tức là bảo trì công cụ liên tục, nhưng không phải kiểu bảo trì phản ứng đầy khổ sở
Là lập trình viên mà lại không muốn liên tục làm phần mềm cho chính mình là một ảo tưởng. Cũng như đầu bếp bật lửa trong nhà hàng nhưng về nhà lại không muốn cầm dao
Emacs là căn bếp nhà riêng của đầu bếp. Có bảo trì phản ứng như sửa hỏng hóc và bám theo thay đổi, và có bảo trì sinh thành là nặn công cụ theo sự tiến hóa của hiểu biết. Lập trình viên nên ghét cái trước và bị hút vào cái sau
Emacs gần như độc nhất phù hợp với kiểu bảo trì sinh thành vì công cụ và công việc chia sẻ cùng một khí chất
Than phiền rằng Emacs "đòi hỏi quá nhiều việc trong cấu hình" là chuyện phổ biến, nhưng thường chỉ có nghĩa là "tôi không muốn đầu tư trước khi thấy giá trị". Về dài hạn đó không phải chiến lược khôn ngoan. Tốt hơn là xem Emacs như công cụ phổ quát để giảm gánh nặng bảo trì tổng thể cho sự nghiệp và cả đời mình
Cấu hình Emacs hay VIM chỉ là các file text đơn giản, có thể mở bằng trình soạn thảo bình thường và chỉnh theo nhu cầu, hơn nữa còn biết cái gì nằm ở đâu. Cấu hình VIM của tôi đã 20 năm tuổi, và 1–2 năm trước tôi chỉ mới bỏ quản lý package thủ công để dùng plugin manager
Ở đây không có gatekeeper, cũng không có dependency
Trong khi cách làm hiện nay là trả cho công ty bên thứ ba 20–200 USD, hoặc cần GPU khá mạnh để chạy local, rồi nhét chỉ dẫn vào file text và cứ sửa tới khi nó cho ra thứ mình muốn
Nghĩa là tự thêm dependency cho mình, và nếu nó rối đến mức con người khó review nổi thì dependency đó sẽ thành dependency rất mạnh. Dù là GPU đắt tiền hay gửi dữ liệu cho một công ty phải làm hài lòng cổ đông thì cũng vậy
Ta cần phân biệt hai thứ đó khác nhau ra sao, và cái giá thật sự ta đang trả là gì
Ý tưởng về phần mềm cá nhân, tức viết chương trình cho chính mình, vốn là tầm nhìn ban đầu của điện toán gia đình từ những năm 1960
PC không được hình dung chính xác như sau này, nhưng người ta đã nghĩ rằng ai cũng sẽ có một terminal máy tính ở nhà và viết chương trình để làm những việc mình cần. Họ tưởng tượng việc lập trình sẽ trở nên đủ dễ để ai cũng học được
Ta vẫn chưa tới đó, nhưng nhờ LLM thì đang tiến gần hơn
Tức là người không chuyên vẫn có thể tạo phần mềm thú vị trong môi trường biên soạn với các thành phần được thiết kế tốt và những phép ẩn dụ dễ hiểu. Những lớp phức tạp ngẫu nhiên hoặc bị over-engineer cần phải được gỡ bỏ
Ngay cả trong tầm nhìn đó, phần mềm vẫn đòi hỏi tư duy logic cẩn thận, nhưng gánh nặng chuyển tư duy đó thành code thực thi sẽ ít hơn nhiều. Cũng không còn ác mộng toolchain và build system
Thay vào đó, ta lại tạo ra những model quá mạnh để lặp lại và tái tổ hợp những câu thần chú phức tạp thay cho ta. Nhưng độ phức tạp vẫn còn đó, và với người không chuyên thì nó vẫn mờ mịt
Dù vậy, LLM có thể giúp xóa bớt một phần sự phức tạp đó. Hướng mà phần mềm do LLM tạo ra vẫn dễ để cá nhân hiểu và tự chỉnh sửa vẫn còn khả thi, và còn có thể bổ trợ rất tốt cho thế giới LLM
Đây không phải chuyện có thể hay không, mà là chuyện bao giờ; lâu lắm cũng chỉ 10 năm, mà có lẽ còn nhanh hơn nhiều. Ngay bây giờ đã có người thân của tôi không biết code nhưng vẫn đang làm chuyện này
Tương lai điện toán đó thật đáng yêu và cực kỳ trao quyền
App Swift hiện tại dài 15.000 dòng, trong đó test là 5000 dòng và phần triển khai là 10.000 dòng. Giờ gần xong rồi và nó làm được việc cần làm. Tổng cộng mất 20 giờ
Tôi chưa từng làm Swift, nên nếu tự viết thủ công thì chắc cá nhân tôi phải mất 500 giờ
Có lẽ vì đa số chúng ta lười nên sẽ không đi xa đến thế, nhưng rõ ràng đây là điều đáng cân nhắc
Bản thân khái niệm ứng dụng sẽ trở nên linh hoạt hơn nhiều
Nếu app được làm bằng ngôn ngữ động, chẳng có lý do gì để không cho người dùng tự viết lại code và thêm những tính năng hoàn toàn mới
Không liên quan trực tiếp tới bài viết gốc, nhưng tôi không đồng ý với ý rằng terminal gần như luôn fixed-width nên đọc văn bản dài sẽ mệt. Cá nhân tôi thấy đọc văn bản dài bằng font monospace dễ chịu hơn nhiều
Tác giả đã chạm tới một điểm thú vị. Các biến số đang tác động là độ khó khi tạo công cụ, độ khó khi phát hành, mức hữu ích với người khác, phần thưởng xã hội khi phát hành, và động lực tiêu cực của việc thêm dependency
Mức độ khó tìm ra giải pháp có sẵn tăng lên tùy theo chi phí để ai đó làm ra nó và chi phí để ai đó biết cách công bố nó. Ngược lại, thứ nào càng hữu ích cho cộng đồng thì càng dễ tìm vì sẽ có người truyền tai nhau
Nếu độ khó tạo và độ khó phát hành chênh nhau nhiều, đặc biệt khi tạo khó hơn rất nhiều, thì người ta có xu hướng tự làm rồi quên luôn. Nếu phát hành dễ thì số giải pháp cho vấn đề sẽ ít hơn
Nếu cả hai đều thấp, và mức hữu ích cho người khác cùng phần thưởng xã hội cao hơn chi phí dependency, thì sẽ xuất hiện tình huống kiểu leftpad. Nhiều package trên NPM được tạo thành từ độ hữu ích và phần thưởng cao, còn chi phí dependency thấp
Với Emacs Lisp, trước đây độ khó tạo cao nhưng giờ đã thấp, và khi vượt qua đường cong học tập thì độ khó phát hành cũng thấp. Mức hữu ích, phần thưởng và chi phí dependency đều không quá cao theo hướng nào cả
Khi đó sẽ xuất hiện kịch bản người ta cứ tự làm luôn trước cả khi đi tìm xem có công cụ nào sẵn không. VSCode hay Eclipse ngày xưa khác ở chỗ độ khó phát hành cao hơn
Có lẽ ai đó trẻ hơn tôi sẽ biến chuyện này thành đề tài nghiên cứu đưa ra trước thế giới
Bài này gợi ra một thay đổi chưa thành hình mà LLM coding có thể mang lại. Có lẽ ta có thể bỏ Electron/React Native, và để LLM biến Figma, wireframe, và đặc tả hành vi thành ứng dụng native thực sự cho từng nền tảng?
Với app CRUD, chỉ cần đặc tả API và mockup UI, thậm chí chỉ ảnh chụp màn hình của một nền tảng đã được triển khai, cũng có thể đi rất xa. Đó là dạng bài toán được xác định rõ mà LLM làm khá tốt. Việc kiểm thử tính tương đương cũng hẳn có thể tự động hóa phần lớn
Những cái cớ như "biết đâu sau này mới thêm Android" hay "người dùng Mac/Linux không đủ nhiều" liệu còn tồn tại không? Việc trên app iOS không làm các luồng ít dùng như đặt lại mật khẩu mà cứ mở bừa một WebView liệu còn biện minh được không?
Ngay cả với app có logic không hề đơn giản chạy trên thiết bị, LLM cũng đã cho thấy khá nhiều tiềm năng trong việc viết lại sang các ngôn ngữ dễ cross-compile như Go hay Rust
Nói kích động hơn một chút thì ở thời điểm này còn lý do gì để học SwiftUI? Với phần lớn công việc, chuyên môn SwiftUI gần giống kiểu "học Microsoft Word thật sâu"
Tôi tôn trọng những người bỏ thời gian vào đó, nhưng dù có làm hay không thì chênh lệch kết quả cũng chỉ ở mức từng milimet
Tôi không nghĩ như vậy về lập trình nói chung. Chỉ là bây giờ lý do để chuyên sâu vào một số ngôn ngữ đã trở nên phức tạp hơn