48 điểm bởi xguru 2025-05-26 | 8 bình luận | Chia sẻ qua WhatsApp
  • Một văn hóa phát triển đang hình thành, trong đó AI được xem là công nghệ nền tảng chứ không chỉ là một công cụ đơn thuần
  • Các cách làm hiện có về quản lý phiên bản, dashboard, template, tài liệu hóa và quản lý secret đang thay đổi để phù hợp với kỷ nguyên AI
    • Git không còn được hiểu chủ yếu như công cụ theo dõi thay đổi theo từng dòng mã, mà đang được diễn giải lại thành cách quản lý trạng thái xoay quanh prompt và kết quả kiểm thử
    • Agent trở thành người viết mã đồng thời cũng là người tiêu thụ mã, khiến nhu cầu thiết kế lại chính các công cụ ngày càng lớn
    • Dashboard và UI đang chuyển sang giao diện dựa trên ngôn ngữ tự nhiên, phát triển theo hướng để con người và agent AI cùng sử dụng
    • Tài liệu hóa đang chuyển thành cơ sở tri thức dành cho cả con người lẫn AI, được tái cấu trúc theo định dạng mà agent có thể hiểu được

1. AI-Native Git: Định nghĩa lại quản lý phiên bản cho agent AI

  • Git ban đầu được thiết kế để theo dõi lịch sử thay đổi theo từng dòng của mã do con người trực tiếp viết ra
    • Nhưng trong bối cảnh AI tự động tạo và chỉnh sửa phần lớn mã nguồn, kiểu theo dõi chi li này trở nên kém quan trọng hơn
    • Lập trình viên không còn chú ý nhiều đến bản thân thay đổi, mà tập trung vào tính phù hợp của hành vi đầu ra (test có pass hay không, có chạy đúng hay không)
    • SHA cho biết đã có thay đổi, nhưng không chứa thông tin về vì sao thay đổi xảy ra hoặc thay đổi đó có hợp lệ hay không
    • Đặc biệt với các thay đổi quy mô lớn hoặc mã được tạo tự động, lập trình viên thường không rà soát từng diff một
  • Trong workflow AI-first, tổ hợp các yếu tố sau trở thành đơn vị hữu ích hơn
    • Prompt: đầu vào dùng để dẫn dắt việc sinh mã
    • Test: kiểm thử để xác minh hành vi kỳ vọng
    • Specconstraints: các yêu cầu thiết kế và ràng buộc
    • Chúng được quản lý và theo dõi như một bundle có thể version hóa
  • Nếu đẩy xa hơn một bước, trong workflow Agent-Driven, Source of Truth có thể được đẩy upstream về phía prompt, schema dữ liệu, API contract và ý đồ kiến trúc (intent)
    • Kết quả là mã được xem như một đầu ra đã biên dịch, được xử lý như sản phẩm phụ của các đầu vào đó chứ không còn là nguồn gốc chính
    • Git khi đó hoạt động như một artifact log thay vì một workspace cho mã nguồn
      • Ai đã dùng model nào và prompt nào để tạo mã
      • Những test nào đã pass
      • Phần nào cần con người rà soát, cùng các metadata liên quan khác
  • Lịch sử thay đổi sẽ bao gồm prompt, mục đích, các test liên quan và thông tin về model đã tạo ra mã
    • Có thể tạo ra luồng review tự động khi tích hợp với các công cụ AI reviewer như Diamond
    • Đồng thời có thể phân lớp metadata phong phú hơn, chẳng hạn cấu trúc để tách biệt mã do agent sinh ra và các vùng được con người quản lý, cần bảo vệ
  • Nếu hình dung workflow AI-Native Git
    • Có thể xuất hiện một dạng dashboard Git mới, nơi hiển thị cùng lúc prompt, luồng thay đổi dựa trên prompt đó, kết quả test, thông tin agent đã hoạt động và thông tin bundle

2. Dashboards → Synthesis: Tiến hóa sang giao diện động dựa trên AI

  • Trong nhiều năm, dashboard đã đóng vai trò là giao diện chủ đạo để tương tác với các hệ thống phức tạp như hệ thống quan sát, công cụ phân tích và cloud console (như AWS)
    • Tuy nhiên, quá nhiều thành phần điều khiển, biểu đồ và tab đã tạo ra tình trạng quá tải UX, khiến người dùng dễ lạc hướng giữa việc khám phá thông tin và thực hiện hành động
    • Đặc biệt với người không chuyên hoặc trong bối cảnh nhiều nhóm cùng cộng tác, những dashboard như vậy có thể bị xem là công cụ đáng sợ và kém hiệu quả
    • Người dùng biết mục tiêu mình muốn đạt được, nhưng thường không biết phải tìm ở đâu hoặc áp dụng bộ lọc nào
  • Thế hệ model AI mới nhất cho thấy khả năng giải quyết những vấn đề này
    • Có thể diễn giải lại dashboard không phải là một canvas cố định, mà là một không gian có thể khám phá và tương tác
  • LLM có thể hỗ trợ người dùng theo các cách như sau:
    • Tìm vị trí điều khiển, ví dụ: “Thiết lập giới hạn tốc độ của API này thay ở đâu?”
    • Tóm tắt tích hợp dữ liệu, ví dụ: “Hãy tóm tắt xu hướng lỗi trong 24 giờ qua trên mọi dịch vụ trong môi trường staging”
    • Đề xuất insight ẩn, ví dụ: “Dựa trên tình hình kinh doanh của tôi, hãy gợi ý các chỉ số cần chú ý trong quý này”
  • Hiện nay, các công nghệ như Assistant UI đã hỗ trợ agent sử dụng React component như công cụ
    • Cũng giống như nội dung đang trở nên động và cá nhân hóa hơn, bản thân UI cũng đang được tái cấu trúc theo ý định của người dùng và tiến hóa theo hướng đối thoại
    • Dashboard tĩnh có thể sớm bị coi là lỗi thời
    • Ví dụ:
      • Nếu người dùng nói “Hãy cho tôi xem các bất thường xảy ra ở châu Âu vào cuối tuần trước”, log tóm tắt và xu hướng sẽ tự động được cung cấp mà không cần thao tác bộ lọc thủ công
      • Với câu hỏi “Vì sao điểm NPS giảm trong tuần trước?”, AI có thể đưa ra phân tích cảm xúc từ khảo sát, phân tích tương quan với lịch sử triển khai sản phẩm và bản tóm tắt chẩn đoán
  • Ở góc nhìn rộng hơn, nếu agent trở thành người tiêu thụ phần mềm, thì chính khái niệm ‘dashboard’ cũng cần được thiết kế lại
    • Chẳng hạn, dashboard có thể render các view được tối ưu cho Agent Experience
      • Cung cấp giao diện có cấu trúc và có thể truy cập bằng lập trình để agent nhận biết trạng thái hệ thống, đưa ra quyết định và hành động
    • Kết quả là có thể hình thành cấu trúc giao diện kép, nơi UI cho người dùng và UI cho agent cùng tồn tại
      • Hai UI chia sẻ cùng một trạng thái, nhưng cách tổ chức sẽ khác nhau tùy theo phương thức tiêu thụ
  • Agent thay thế vai trò của cảnh báo, cron job và tự động hóa dựa trên điều kiện truyền thống, đồng thời trở thành tác nhân thực thi có nhiều ngữ cảnh và linh hoạt hơn rất nhiều
  • Ví dụ:
    • Trước đây: if error rate > threshold then send alert
    • Theo kiểu agent: “Tỷ lệ lỗi đang tăng. Nguyên nhân là dịch vụ này, và dưới đây là các thành phần bị ảnh hưởng cùng hành động được khuyến nghị”
  • Theo cách đó, dashboard không còn chỉ là nơi để quan sát, mà được định nghĩa lại thành không gian nơi con người và AI cùng cộng tác, tổng hợp và thực thi hành động

3. Tài liệu đang tiến hóa thành tổ hợp của công cụ, chỉ mục và cơ sở tri thức tương tác

  • Cách lập trình viên sử dụng tài liệu đang thay đổi
    • Trước đây, người ta đọc theo mục lục hoặc đọc spec từ trên xuống, nhưng giờ đây cách làm “đặt câu hỏi trước” đang trở nên phổ biến
    • Thay vì nghĩ “Mình phải học spec này”, ngày càng xuất hiện sự chuyển dịch sang tư duy “Hãy tái cấu trúc thông tin theo đúng cách mình muốn
    • Sự thay đổi này cũng ảnh hưởng tới hình thức của tài liệu, khiến nó tiến hóa từ HTML hoặc Markdown tĩnh thành hệ thống tri thức tương tác được hậu thuẫn bởi chỉ mục, embedding và các agent có nhận thức về công cụ
  • Vì thế, các công cụ như Mintlify đang xuất hiện
    • Mintlify không chỉ tổ chức tài liệu thành cơ sở dữ liệu có thể tìm kiếm theo ngữ nghĩa, mà còn được dùng làm nguồn ngữ cảnh cho agent trên nhiều nền tảng khác nhau
      • Ví dụ: trong AI IDE, tiện ích mở rộng VS Code, terminal agent..., tài liệu Mintlify được dùng làm tài liệu tham chiếu thời gian thực
    • Lý do là các agent sinh mã sử dụng tài liệu mới nhất làm ngữ cảnh dựa trên tri thức
  • Vì điều này, mục đích của tài liệu cũng đang thay đổi
    • Tài liệu không còn chỉ để truyền đạt thông tin cho độc giả là con người, mà giờ phải được thiết kế như một cấu trúc dành cho các agent tiêu thụ
    • Trong động lực mới này, tài liệu sẽ đóng vai trò như hướng dẫn sử dụng dành cho agent AI
    • Đây không chỉ là việc phơi bày nội dung, mà là một định dạng giải thích cách khai thác hệ thống sao cho đúng

4. Từ template sang tạo sinh: vibe coding thay thế create-react-app

  • Trước đây, khi bắt đầu một dự án, việc chọn một mẫu tĩnh như create-react-app, next init, rails new là điều phổ biến
    • Những mẫu này cung cấp cấu trúc ứng dụng nhất quán, nhưng khó tùy biến theo ý đồ hoặc stack của lập trình viên, và phải đi theo các giá trị mặc định của framework
    • Kết quả là, để thoát khỏi cấu hình mặc định, thường cần rất nhiều công việc refactor thủ công
  • Giờ đây, xu hướng này đang thay đổi nhờ sự xuất hiện của các nền tảng text-to-app như Replit, Same.dev, Loveable, Chef by Convex, BoltAI IDE như Cursor
    • Ví dụ, nếu lập trình viên mô tả “một máy chủ API TypeScript có Supabase, Clerk, Stripe”, thì AI có thể tự động dựng một dự án tùy chỉnh chỉ trong vài giây
    • Starter được tạo ra không còn là một template chung chung, mà là cấu trúc được tối ưu theo ý đồ và stack của lập trình viên
  • Sự thay đổi này cũng đang làm đổi khác cấu trúc phân phối của hệ sinh thái
    • Thay vì chỉ có một vài framework chiếm vị trí trung tâm như trước, luồng tạo dự án tùy chỉnh kết hợp nhiều công cụ và kiến trúc khác nhau đang lan rộng
    • Trọng tâm đang chuyển từ chọn framework sang mô tả “muốn xây cái gì”
    • Một lập trình viên có thể chọn tổ hợp Next.js và tRPC, người khác có thể chọn Vite và React, và cả hai đều có thể được tạo thành dự án chạy được ngay lập tức
  • Tất nhiên, stack tiêu chuẩn vẫn có những lợi thế riêng:
    • Nâng cao năng suất nhóm, cải thiện hiệu quả onboarding, dễ debug hơn
    • Nhưng việc refactor giữa các framework không chỉ là vấn đề kỹ thuật đơn thuần, mà còn gắn với sản phẩm, hạ tầng và năng lực tổ chức
  • Điểm bẻ ngoặt nằm ở chỗ chi phí chuyển đổi framework đã giảm xuống
    • AI agent có thể hiểu ý đồ của dự án và thực hiện refactor quy mô lớn theo cách bán tự động
    • Nhờ đó, việc thử nghiệm trở nên dễ hơn, và ở giai đoạn đầu có nhiều dư địa hơn để thử hoặc quay lại giữa các stack khác nhau
  • Kết quả là, việc chọn framework đang dần trở thành quyết định có thể đảo ngược (decision reversible)
    • Ví dụ: bắt đầu với Next.js rồi chuyển sang Remix + Vite, và agent xử lý toàn bộ quá trình refactor
  • Framework lock-in giảm đi, nên ngay cả những stack có tính áp đặt cao (opinionated) cũng có thể được thử mà không quá áp lực

5. Vượt ra ngoài .env: quản lý secret trong môi trường lấy agent làm trung tâm

  • Trong hàng chục năm, file .envcách mặc định để lập trình viên quản lý đơn giản các secret cục bộ như API key, URL cơ sở dữ liệu, service token
    • Cách này đơn giản, dễ di chuyển và thân thiện với lập trình viên, nhưng khi AI IDE hoặc agent viết code, triển khai dịch vụ và điều phối môi trường, vấn đề bắt đầu xuất hiện
    • Cụ thể là, không còn rõ ai là chủ thể sở hữu file .env
  • Một xu hướng nhằm giải quyết vấn đề này đang xuất hiện
    • Ví dụ, bản đặc tả MCP mới nhất có bao gồm framework xác thực dựa trên OAuth 2.1
    • Cấu trúc này gợi mở hướng trao cho AI agent token bị giới hạn phạm vi thay vì secret thô (scope-based, revocable tokens)
    • Ví dụ: thay vì cấp cho agent toàn bộ khóa AWS, hệ thống sẽ cấp credential ngắn hạn chỉ cho phép các hành động bị giới hạn như “upload file lên S3”
  • Một xu hướng khác là sự xuất hiện của secret broker cục bộ (local secret broker)
    • Đây là dịch vụ chạy cục bộ hoặc bên cạnh ứng dụng, đóng vai trò trung gian giữa agent và các secret nhạy cảm
    • Agent không truy cập trực tiếp vào .env hay hardcode secret; thay vào đó, khi có yêu cầu thực hiện tác vụ cụ thể, broker sẽ đánh giá theo thời gian thực và cấp quyền
      • Ví dụ: yêu cầu “triển khai lên staging” hoặc “gửi log tới Sentry”
      • Broker xử lý việc này theo kiểu Just-in-time, và mọi truy cập đều có thể được audit
  • Cách tiếp cận này chuyển quyền truy cập secret từ mô hình dựa trên file system sang mô hình phân quyền dựa trên API
    • Kết quả là, quản lý secret đang phát triển từ cấu hình .env sang cấu trúc kiểm soát quyền dựa trên OAuth

6. Biến accessibility thành giao diện phổ quát: ứng dụng dưới góc nhìn của LLM

  • Gần đây, các ứng dụng như Granola và Highlight yêu cầu quyền accessibility trên macOS, nhưng mục đích này không còn chỉ để hỗ trợ người khuyết tật theo nghĩa truyền thống, mà để AI agent quan sát và tương tác với UI
    • Đây không phải một thủ thuật tạm thời, mà có thể xem là dấu hiệu báo trước một sự chuyển đổi giao diện mang tính căn bản hơn
  • Accessibility API ban đầu được tạo ra để cải thiện khả năng tiếp cận số cho người dùng có khiếm khuyết về thị giác hoặc vận động
    • Nhưng nếu mở rộng các API này, chúng có thể hoạt động như một lớp giao diện phổ quát cho AI agent
    • Thay vì click theo vị trí pixel hoặc scraping DOM, agent có thể quan sát và thao tác với ứng dụng theo cách dựa trên ngữ nghĩa (semantic), tương tự như công nghệ hỗ trợ diễn giải UI
    • Accessibility tree vốn đã phơi bày các thành phần UI có cấu trúc như nút, tiêu đề, ô nhập liệu
    • Nếu bổ sung thêm metadata như ý định (intent), vai trò (role), khả năng tương tác (affordance), thì agent có thể thao tác chính xác theo mục tiêu và ngữ cảnh
  • Hướng đi này có thể mở rộng thành các khả năng như sau:
    • Context extraction: truy vấn các phần tử đang hiển thị trên màn hình, các mục có thể tương tác và hành động hiện tại của người dùng thông qua API accessibility/semantic
    • Intentful execution: thay vì nối thủ công nhiều lệnh gọi API, chỉ cần khai báo mục tiêu ở mức cao như “thêm mặt hàng vào giỏ và chọn giao nhanh nhất”, rồi backend tự cấu thành quy trình thực thi
    • Fallback UI for LLMs: tính năng accessibility cung cấp giao diện dự phòng để agent vẫn dùng được những ứng dụng không có API công khai
      • Ngoài UI trực quan hoặc DOM, lập trình viên có thể định nghĩa render surface mà agent có thể nhận biết bằng structured annotation hoặc component lấy accessibility làm trung tâm
  • Tóm lại, accessibility API hiện đang phát triển thành một lớp giao diện cốt lõi cho tương tác giữa AI, hệ thống và ứng dụng, chứ không còn chỉ dành cho con người

7. Sự trỗi dậy của tác vụ agent bất đồng bộ

  • Khi các nhà phát triển ngày càng cộng tác một cách tự nhiên với các tác nhân viết mã, quá trình chuyển sang quy trình làm việc bất đồng bộ đang được thúc đẩy nhanh hơn
    • Tác nhân hoạt động theo cách xử lý song song ở chế độ nền, rồi báo cáo kết quả khi tiến tới một mức độ nhất định
    • Kiểu tương tác này ngày càng giống điều phối tác vụ (task orchestration) hơn là pair programming
    • Tức là, nhà phát triển truyền đạt mục tiêu, tác nhân thực hiện và kiểm tra lại sau
  • Điểm quan trọng không chỉ là giảm bớt khối lượng công việc, mà là nén chính hoạt động cộng tác
    • Ví dụ, thay vì yêu cầu đội khác cập nhật tệp cấu hình, triage lỗi hay refactor component,
      nhà phát triển có thể truyền trực tiếp ý định cho tác nhân và chỉ thị nó xử lý ở chế độ nền
    • Trước đây cần các cuộc họp đồng bộ, bàn giao giữa các bộ phận và chu kỳ review kéo dài,
      nhưng giờ đây vòng lặp yêu cầu → tạo sinh → xác thực (request → generate → validate) diễn ra một cách tự nhiên
  • Cách tương tác với tác nhân cũng đang được mở rộng
    • Ngoài cách đơn thuần nhập prompt trong IDE hoặc CLI, còn có thể theo các cách như:
      • Gửi yêu cầu công việc qua tin nhắn Slack
      • Viết bình luận trên mockup Figma
      • Thêm chú thích inline vào code diff hoặc PR (ví dụ: trợ lý review của Graphite)
      • Bổ sung phản hồi vào bản preview của ứng dụng đã triển khai
      • Mô tả thay đổi bằng lời nói qua giao diện giọng nói hoặc cuộc gọi
  • Những thay đổi này khiến tác nhân hiện diện xuyên suốt toàn bộ vòng đời phát triển
    • Không chỉ dừng ở viết mã, mà còn diễn giải thiết kế, phản ánh phản hồi và thậm chí triage lỗi trên toàn bộ nền tảng
    • Nhà phát triển đảm nhiệm vai trò orchestrator quyết định luồng công việc nào sẽ được tiếp tục, loại bỏ hoặc hợp nhất
  • Xu hướng này cuối cùng gợi ý rằng các luồng công việc dựa trên tác nhân có thể trở thành khái niệm “nhánh Git” mới
    • Không còn là nhánh tách mã tĩnh, mà là các luồng động theo mục đích chạy bất đồng bộ và được hợp nhất khi hoàn tất

8. MCP: Model Context Protocol tiến thêm một bước tới chuẩn phổ quát

  • Sau khi gần đây công bố bài phân tích chuyên sâu về MCP, tốc độ áp dụng MCP đang tăng nhanh
  • OpenAI đã chính thức áp dụng MCP, nhiều tính năng mới đã được hợp nhất vào đặc tả,
    và ngày càng nhiều nhà phát triển công cụ đang chấp nhận MCP như giao diện mặc định giữa tác nhân và thế giới thực
  • Về bản chất, MCP giải quyết hai vấn đề quan trọng:
    • Cung cấp ngữ cảnh cần thiết để LLM có thể thực hiện cả những công việc lần đầu gặp
    • Loại bỏ các tích hợp tùy chỉnh theo kiểu N×M, và đơn giản hóa thành cấu trúc nơi công cụ phơi bày giao diện chuẩn (server), để mọi tác nhân (client) đều có thể sử dụng
  • Trong tương lai, việc áp dụng MCP được dự đoán sẽ còn mở rộng hơn nữa,
    và nếu MCP từ xa cùng một registry MCP trên thực tế (de-facto registry) xuất hiện,
    nhiều ứng dụng có thể được phát hành với giao diện MCP tích hợp sẵn theo mặc định
  • Tương tự như cách API từng kết nối các công cụ SaaS và cấu thành quy trình làm việc,
    MCP có thể tạo ra một hệ sinh thái các thành phần tương tác được dành cho tác nhân AI
  • Một nền tảng tích hợp sẵn MCP client sẽ không chỉ dừng ở mức “có hỗ trợ AI”, mà còn
    trở thành một phần của hệ sinh thái có thể kết nối trực tiếp vào mạng lưới chức năng mà tác nhân truy cập được
  • Client và server của MCP chỉ là các khái niệm logic, không tách biệt về mặt vật lý
    • Điều này có nghĩa là bất kỳ MCP client nào cũng có thể trở thành server, và ngược lại
    • Nhờ đó, mở ra khả năng kết hợp (composability) ở mức cao như sau:
      • Ví dụ: một tác nhân lập trình có thể lấy GitHub issue với vai trò client, đồng thời với vai trò server cung cấp kết quả phân tích mã hoặc độ bao phủ kiểm thử cho tác nhân khác
  • MCP đang dần trở thành lớp giao diện nền tảng cho một hệ sinh thái nơi công cụ và tác nhân tương tác hữu cơ với nhau

9. Primitive được trừu tượng hóa: xác thực, thanh toán, kho lưu trữ mà mọi tác nhân AI đều cần

  • Khi các tác nhân vibe coding ngày càng mạnh hơn, có một điều ngày càng rõ ràng:
    tác nhân có thể tạo ra rất nhiều mã, nhưng chúng cần một nền tảng đáng tin cậy để đoạn mã đó kết nối vào
  • Cũng như nhà phát triển con người dựa vào Stripe cho thanh toán, Clerk cho xác thực, và Supabase cho cơ sở dữ liệu,
    tác nhân cũng cần những service primitive đáng tin cậy và có thể kết hợp
  • Các dịch vụ này cung cấp ranh giới API rõ ràng, SDK dễ sử dụng và các thiết lập mặc định hợp lý,
    đồng thời ngày càng đóng vai trò như giao diện runtime của tác nhân
  • Ví dụ, khi xây dựng một công cụ tạo ứng dụng SaaS, thay vì để tác nhân tự triển khai hệ thống xác thực hay logic thanh toán,
    có thể dùng Clerk và Stripe để tích hợp nhanh chóng và an toàn
  • Khi mô hình này trưởng thành hơn, các dịch vụ có thể vượt ra ngoài việc chỉ cung cấp API để công khai thêm:
    • Schema: định nghĩa dữ liệu có cấu trúc
    • Capability metadata: đặc tả các tác vụ có thể thực hiện
    • Example flows: ví dụ về cách tích hợp
      → Nhờ đó, tác nhân có thể tích hợp ổn định hơn
  • Một số dịch vụ thậm chí có thể được phát hành kèm MCP server tích hợp sẵn
    • Ví dụ: Clerk có thể thông qua MCP server để phơi bày các chức năng như xem danh sách sản phẩm khả dụng, tạo gói giá mới, chỉnh sửa đăng ký thuê bao
    • Thay vì phải tìm đặc tả API hay tài liệu, tác nhân chỉ cần yêu cầu bằng ngôn ngữ tự nhiên,
      còn MCP server sẽ xác thực và xử lý yêu cầu trong phạm vi quyền hạn và các ràng buộc cho phép
    • Ví dụ:
      > “Hãy tạo gói Pro giá 49 USD/tháng và thiết lập phụ phí theo mức sử dụng”
      → MCP server của Clerk sẽ diễn giải và thực thi yêu cầu này
  • Cũng như rails new từng giúp phát triển nhanh trong thời kỳ đầu của web,
    trong kỷ nguyên tác nhân, cần có những primitive đáng tin cậy (drop-in identity, thanh toán, kiểm soát truy cập, v.v.)
    • Chúng phải được trừu tượng hóa đủ tốt để tác nhân có thể tận dụng cho việc tạo sinh,
      đồng thời vẫn phải có cấu trúc đủ khả năng mở rộng cùng với sự phát triển của ứng dụng

Kết luận

  • 9 mô hình này cho thấy không chỉ đơn thuần là thêm AI vào cách phát triển hiện có, mà chính phương thức tạo phần mềm đang được định nghĩa lại xoay quanh tác nhân, ngữ cảnh và ý định
  • Theo đó, các mô thức hành vi cũ của nhà phát triển cũng đang thay đổi, và những toolchain cùng giao thức mới (như MCP) hỗ trợ cho điều này đang xuất hiện rất nhanh
  • Các lớp công cụ cốt lõi hiện có như Git, template, dashboard, cách viết tài liệu, v.v. đều đang được thiết kế lại ở mức nền tảng cùng với AI
  • Trong giai đoạn chuyển đổi này, có thể kỳ vọng rằng việc xây dựng và đầu tư vào các công cụ cùng hạ tầng thế hệ mới để hình thành hệ sinh thái phát triển mới sẽ diễn ra sôi động

8 bình luận

 
aa1567 2025-05-28

Có người thực sự làm điều số 1 sao..?

 
hhcrux 2025-05-27

LLM không đảm bảo cùng một đầu vào sẽ cho ra cùng một đầu ra, vậy kiểu quản lý cấu hình như thế kia có hiệu quả thật sao...
Hay là đến giờ mình vẫn chỉ đang dùng nó theo cách quá một chiều nhỉ

 
beoks 2025-05-27

Tôi được biết rằng nếu đặt tùy chọn temperature về 0 thì sẽ đảm bảo cùng một đầu ra cho cùng một đầu vào.

 
fanotify 2025-05-28

Dù sao thì sau vài tháng nữa bản thân mô hình lại thay đổi, nên có lẽ cũng chẳng có nhiều ý nghĩa đúng không?

 
beoks 2025-05-27

Bỏ qua chuyện đó thì việc hoàn toàn không tính đến sự can thiệp của con người có vẻ quá khẳng định,
trong những trường hợp như chỉnh sửa vài con số hoặc thông điệp đơn giản thì để con người can thiệp còn hiệu quả hơn LLM.

 
nicewook 2025-05-26

Đây là một bài viết mang lại cảm giác có chiều sâu lớn. Quả nhiên là a16z.

 
ruinnel 2025-05-26

https://vi.news.hada.io/topic?id=21091
Đọc xong bài này rồi đọc tiếp thì thấy có vẻ đúng thật.

 
ahwjdekf 2025-05-26

Mục số 1 đúng là một thay đổi như cơn ác mộng, hoàn toàn không muốn chấp nhận. Cảnh việc lần vết lịch sử mã nguồn trở nên vô nghĩa.