Spec-Driven vs Code-First vs Chat-to-Code: Ba Triết Lý Dạy AI Về Doanh Nghiệp Của Bạn

Có ba cách để dạy một AI agent về doanh nghiệp của bạn. Mỗi cách đảo ngược ai — hoặc cái gì — là nguồn sự thật.

GitHub’s Spec Kit (122k stars) nói rằng thông số kỹ thuật là sự thật: viết spec, spec tạo ra code. OpenWiki và Mintlify nói rằng code là sự thật: đọc codebase, viết docs, agent tiêu thụ docs. QuotyAI nói rằng chuyên gia lĩnh vực là sự thật: chat quy tắc kinh doanh, nhận lại code có thể thực thi.

Mỗi cách tiếp cận đều hoạt động. Mỗi cách phá vỡ theo cách khác nhau. Và các lỗi không ngẫu nhiên — chúng theo các mẫu có thể dự đoán liên quan đến ai đã tạo kiến thức, khi nào nó được viết, và nó được tiêu thụ như thế nào.

Ba Triết Lý

Spec-Driven: Thông Số Kỹ Thuật Là Nguồn Sự Thật

GitHub Spec Kit đảo ngược phát triển truyền thống. Thông số kỹ thuật không phục vụ code — code phục vụ thông số kỹ thuật. PRD không phải là hướng dẫn cho việc triển khai; nó là nguồn tạo ra việc triển khai. Kế hoạch kỹ thuật không phải là tài liệu thông báo việc lập trình; chúng là định nghĩa chính xác tạo ra code.

Quy trình gồm bốn lệnh:

/speckit.specify  →  /speckit.plan  →  /speckit.tasks  →  /speckit.implement

Mô tả tính năng trở thành spec có cấu trúc với user story và tiêu chí chấp nhận. Spec trở thành kế hoạch triển khai với lựa chọn công nghệ và lý do. Kế hoạch trở thành danh sách task có thể thực thi. Danh sách task trở thành code.

Spec Kit đi kèm với một bản hiến pháp — chín điều khoản bất di bất dịch (nguyên tắc library-first, yêu cầu test-first, cổng kiểm tra simplicity) mà mọi triển khai được tạo ra phải tuân theo. Các mẫu giới hạn đầu ra của LLM bằng checklist, các dấu hiệu không chắc chắn bắt buộc ([NEEDS CLARIFICATION]), và các cổng phase chặn tiến trình trừ khi các nguyên tắc kiến trúc được đáp ứng.

Hệ sinh thái xung quanh phát triển spec-driven rất lớn:

Specmatic biến thông số kỹ thuật API (OpenAPI, AsyncAPI, gRPC) thành các contract có thể thực thi với service ảo hóa và kiểm tra tương thích ngược
Speakeasy chuyển hướng từ công cụ spec API sang bảng điều khiển AI cho quản trị MCP và Skills
Stoplight/Spectral cung cấp linting thiết kế API trước với các bộ quy tắc quản trị
OpenAPI/Swagger tạo API client và server stub từ spec trên hơn 40 ngôn ngữ

Cược: nếu thông số kỹ thuật đủ chính xác, khoảng cách giữa ý định và triển khai biến mất.

Code-First: Codebase Là Nguồn Sự Thật

OpenWiki, được xây dựng bởi LangChain AI, đọc codebase và viết tài liệu markdown cho coding agent. GitHub Action chạy openwiki --update hàng ngày. Agent so sánh git, xác định các trang bị ảnh hưởng, và chỉ viết lại các trang đó. Các file AGENTS.md và CLAUDE.md trong gốc repository chỉ coding agent đến wiki làm điểm vào.

Nhưng OpenWiki chỉ là một công cụ trong hệ sinh thái lớn hơn nhiều:

Mintlify cung cấp docs cho Anthropic, Coinbase, và Vercel. Công cụ Agent Score kiểm tra tài liệu với 29 kiểm tra cho sự sẵn sàng của agent. Một thử nghiệm có kiểm soát bởi tổ chức kỹ thuật lớn cho thấy docs có cấu trúc đưa ra câu trả lời chính xác hơn 64%, tiết kiệm ~50% token, và hoàn thành task nhanh hơn 1.5x so với không có docs.
GitBook cung cấp Git Sync (xem nhánh/review/merge docs như code) và Agent chủ động phát hiện nội dung cũ.Thông điệp chính của họ: “Agent biến lỗi docs nhỏ thành vấn đề lớn.”
ReadMe đề xuất cập nhật docs trên PR thông qua AI Writer, với MCP server cho agent quyền đọc/ghi.
Swimm sử dụng phân tích tĩnh deterministic kết hợp GenAI để xây dựng cơ sở kiến thức đã xác thực cho các công cụ AI, tuân thủ SOC 2, đã phân tích hơn 100 triệu dòng code.

Hệ sinh thái file cấu hình trong repo cũng rất lớn:

Công cụ	File Cấu Hình	Chi Tiết Chính
Claude Code	`CLAUDE.md`, `.claude/rules/*.md`	Khuyến nghị tối đa 200 dòng; quy tắc theo phạm vi đường dẫn chỉ tải cho các file khớp
Cursor	`.cursor/rules/*.mdc`	Thư viện plugin cộng đồng với 4k stars
Cline	`.clinerules` + `.cline/skills/`	64.7k GitHub stars
Aider	`CONVENTIONS.md`	Tree-sitter AST-based repo map
GitHub Copilot	`.github/copilot-instructions.md`	Hướng dẫn cấp dự án
Windsurf	`.windsurfrules`	Tương thích chéo công cụ với Claude Code

Cược: nếu tài liệu đủ toàn diện, agent sẽ hiểu codebase cũng như các nhà phát triển đã xây dựng nó.

Chat-to-Code: Chuyên Gia Lĩnh Vực Là Nguồn Sự Thật

QuotyAI cho phép chủ spa gõ “massage deep tissue của chúng tôi giá $90 cho 60 phút,$ 120 cho 90 phút, và chúng tôi giảm giá 10% cho thành viên.” Nền tảng tạo ra hàm quoteOrder() trả về $108 cho đặt lịch thành viên 90 phút. Mỗi lần.

Kiến trúc: chủ doanh nghiệp chat với skills builder bằng ngôn ngữ tự nhiên. Builder tạo các tài liệu có cấu trúc (JSON schema, kiểu TypeScript, dữ liệu tham khảo) và code có thể thực thi (hàm pricing, phép biến đổi lịch trình, logic xác thực). Output chạy trong sandboxed Node.js VM trên mỗi tin nhắn khách hàng đến.

Tại sao các sản phẩm hiện có không lấp đầy khoảng trống này? Bối cảnh chat-to-app tiết lộ một lỗ hổng:

Vercel v0, bolt.new, Lovable nhắm đến người dùng không kỹ thuật nhưng tạo ra UI và ứng dụng frontend. Template “finance calculator” là máy tính đơn giản, không phải engine giá với chiết khấu theo tier, add-on có điều kiện, và quy tắc thành viên.
Cursor, GitHub Copilot, Codex mạnh mẽ nhưng đòi hỏi nhà phát triển là người dùng chính. Chúng không hiểu lĩnh vực kinh doanh của bạn — AI không biết rằng confirmed_at là timestamp đúng cho báo cáo doanh thu, không phải created_at.
Zapier, Make, Bubble tự động hóa quy trình đơn giản nhưng không thể biểu đạt logic kinh doanh phức tạp. “Nếu điều này thì điều đó” quá đơn giản cho giá cả và báo giá thực tế.

Thể loại bị thiếu: một công cụ hiểu lĩnh vực kinh doanh của bạn và tạo ra code cụ thể thực thi quy tắc của bạn, mà không yêu cầu bạn viết code hoặc thậm chí suy nghĩ theo thuật ngữ code.

Các sản phẩm liền kề tồn tại — DealHub và Salesforce CPQ cho Configure-Price-Quote doanh nghiệp, Clay cho AI sales enrichment, Voiceflow và Botpress cho chatbot builder — nhưng không có sản phẩm nào cho phép chuyên gia lĩnh vực không kỹ thuật mô tả logic giá phức tạp bằng ngôn ngữ tự nhiên và nhận lại code deterministic, có thể kiểm toán.

Cược: nếu cuộc hội thoại đủ có cấu trúc, kiến thức của chuyên gia lĩnh vực có thể được chuyển đổi trực tiếp thành logic production.

Mỗi Cách Phá Vỡ Ở Đâu

Spec-Driven: Vấn Đề Mục Nát Ngữ Cảnh

Cược spec-driven giả định thông số kỹ thuật toàn diện cải thiện hiệu suất agent. Dữ liệu nói ngược lại.

Mục nát ngữ cảnh là có thật. Nghiên cứu về context engineering cho AI agent của Anthropic mô tả cách “khi số lượng token trong cửa sổ ngữ cảnh tăng, khả năng mô hình nhớ chính xác thông tin từ ngữ cảnh đó giảm.” Điều này xuất phát từ giới hạn cơ bản của kiến trúc transformer: mỗi token chú ý đến mọi token khác, tạo ra n² mối quan hệ đôi mỏng đi khi ngữ cảnh lớn lên.

Hiện tượng này phổ quát — tất cả mô hình đều biểu hiện, mặc dù một số giảm chất lượng chậm hơn những cái khác. Hệ quả rõ ràng: mỗi token được nạp vào ngữ cảnh đều làm giảm “ngân sách chú ý” của agent, và spec nặng về token. Một thông số kỹ thuật đủ toàn diện để hữu ích có thể quá lớn để hiệu quả.

Quy mô lệnh agent (ThoughtWorks Technology Radar Vol 34, tháng 4/2026, xếp hạng “Caution”):

“Các file ngữ cảnh như AGENTS.md và CLAUDE.md có xu hướng tích lũy theo thời gian khi nhóm thêm tổng quan codebase, giải thích kiến trúc, quy ước và quy tắc. Mặc dù mỗi bổ sung hữu ích khi riêng lẻ, điều này thường dẫn đến quy mô lệnh agent. Hướng dẫn trở nên dài và đôi khi xung đột với nhau. Mô hình có xu hướng chú ý ít hơn đến nội dung nằm sâu trong ngữ cảnh dài.”

Bài nghiên cứu “On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents” (arXiv:2601.20404, tháng 1/2026) phát hiện AGENTS.md viết tay giảm thời gian chạy trung bình 28.64% — nhưng chỉ khi chúng giữ được sự gọn gàng. Spec cồng kềnh hoặc viết kém có hiệu ứng ngược lại.

Chu kỳ mệt mỏi spec theo mẫu có thể dự đoán:

Hype ban đầu: “Hãy viết spec toàn diện để AI biết chính xác phải làm gì”
Spec phát triển: edge case xuất hiện, thêm nhiều quy tắc và tài liệu
Spec trở nên cồng kềnh: quá lớn đến mức giảm hiệu suất agent
Gánh nặng bảo trì: spec mất đồng bộ với codebase đang phát triển
Mệt mỏi spec: nhóm ngừng bảo trì spec
Tài liệu chết: agent tuân theo hướng dẫn lỗi thời với độ tin cậy cao

Trôi dạt kiến trúc vẫn tồn tại ngay cả với spec. ThoughtWorks Radar chỉ ra “Giảm trôi dạt kiến trúc với LLMs” (Assess): “Việc sử dụng tăng coding agent AI có thể tăng tốc trôi dạt khỏi codebase và thiết kế kiến trúc dự kiến. Nếu không kiểm soát, sự trôi dạt này tích lũy khi agent và con người nhân rộng các mẫu hiện có, bao gồm cả những mẫu bị suy giảm.”

Code-First: Thuế Mất Tươi

Cược code-first giả định tài liệu được tạo từ code vẫn chính xác. Nó không.

Mất tươi là thách thức số 1. Báo cáo GitBook State of Docs 2026 cho thấy “giữ docs đồng bộ với sản phẩm” là thách thức lớn nhất cho nhóm tài liệu — gần gấp đôi vị trí thứ hai. README là “snapshot bị lỗi thời biến thành nguồn thông tin lỗi thời khác cho agent hallucinate.”

Không giống người đọc có thể nhận ra và xử lý tài liệu lỗi thời, AI agent coi tài liệu mất tươi như ground truth. Agent tuân theo README sáu tháng tuổi sẽ tự tin tham chiếu các API, đường dẫn file, và quy trình không còn tồn tại.

Vấn đề “tại sao” không thể giải quyết từ code. Đồng sáng lập Mintlify, Han Wang:

“Code chỉ cho thấy cái gì được xây dựng, không phải tại sao. Lý do đằng sau quyết định kiến trúc nằm trong các thread Slack cũ và trong não bộ của vài người. Agent làm việc từ code không có lớp ý định. Thậm chí một cái búa cũng phức tạp nếu bạn không biết mình phải dùng nó để đập đinh.”

Agent có thể đọc rằng hàm X gọi hàm Y, nhưng nó không biết rằng Y tồn tại do yêu cầu tuân thủ từ năm 2023 hoặc rằng X sử dụng một thuật toán cụ thể vì benchmark hiệu suất đòi hỏi.

Thuế cửa sổ ngữ cảnh rất khắc nghiệt. Chi phí khởi động của Claude Code — trước khi bạn gõ bất cứ điều gì — tiêu thụ khoảng 8.000-10.000 token. Mỗi file đọc thêm 1.000-3.000 token. Khi agent đã đọc 5-6 file nguồn, nó có thể đã vượt quá 50% ngữ cảnh. Quy trình nặng về tài liệu đẩy nhanh sự cạn kiệt này.

Nghiên cứu của Mintlify phát hiện docs có cấu trúc cắt tiêu thụ token mỗi task khoảng 50%. Đối với công ty chi $1 triệu/năm cho token AI coding, đó là$ 500K tiết kiệm. Nhưng docs phải được bảo trì để mang lại tiết kiệm đó — đưa bạn trở lại vấn đề mất tươi.

Chi phí sai sót là không đối xứng. Từ GitBook: “Agent biến lỗi docs nhỏ thành vấn đề lớn.” Nhà phát triển con người đọc tài liệu lỗi thời có thể nhận ra sự không nhất quán và xử lý. Agent tuân theo mù quáng, tạo ra code hỏng với độ tin cậy cao.

Chat-to-Code: Khoảng Cách Xác Minh

Cược chat-to-code giả định ngôn ngữ tự nhiên đủ chính xác để tạo code đúng. Nó thường không.

Vấn đề xác Minh là thách thức lớn nhất chưa được giải quyết. Không có công cụ nào hỏi người dùng: “Đây là 5 test case. Output này có vẻ đúng không?” Hàm pricing có vẻ đúng có thể có lỗi sai đơn vị ở ranh giới. Lỗi làm tròn có thể vô hình cho đến khi tiền thật liên quan. Edge case — số lượng bằng 0, giá trị âm, giá trị cực — có thể không được kiểm tra.

Việc viết lại Bun runtime (tháng 7/2026) giải quyết điều này với “bộ test độc lập ngôn ngữ với một triệu assertion, review code đối kháng và khi sự cố xảy ra, sửa quy trình tạo code thay vì sửa code thủ công.” Nhưng điều đó đòi hỏi nhóm kỹ sư chuyên gia xây dựng bộ kiểm tra conformity. Chủ spa không thể làm điều này.

Niềm tin rất mong manh. Chủ doanh nghiệp tin tưởng giá do AI tạo ra đối mặt rào cản thực tế: rủi ro tài chính (sai giá nghĩa là mất doanh thu), yêu cầu kiểm toán (nhiều ngành đòi hỏi logic giá có thể giải thích), trách nhiệm pháp lý (nếu giá do AI tạo ra phân biệt đối xử, ai chịu trách nhiệm?), và sự bất lực cơ bản trong việc đọc code để xác minh tính đúng đắn.

Sự cố xAI Grok Build (tháng 7/2026) chứng minh niềm tin mong manh đến mức nào: chạy CLI trong thư mục đã tải toàn bộ thư mục — SSH keys, cơ sở mật khẩu, tài liệu — lên Google Cloud. Một thảm họa quyền riêng tư có thể phá hủy niềm tin trong toàn bộ thể loại.

Vấn đề “vibe coding” vẫn áp dụng. Thuật ngữ của Andrej Karpathy cho code có vẻ đúng nhưng có bug tinh vi đặc biệt nguy hiểm cho logic kinh doanh. Tính toán giá sai $0.03 mỗi giao dịch có vẻ nhỏ cho đến khi bạn nhân nó với 10.000 giao dịch.

Từ khảo sát Pragmatic Engineer (hơn 170 người tham gia): “Copilot có thể (và thực sự!) tạo code sai. Khi sử dụng Copilot, bạn cần giả định nó tạo ra lỗi.” Các công cụ hoạt động khi người dùng đã biết code nên làm gì. Đối với người dùng không kỹ thuật mô tả quy tắc kinh doanh mà họ không hoàn toàn hiểu theo thuật ngữ code, rủi ro cao hơn nhiều.

Đặc thù lĩnh vực giới hạn thị trường. Công cụ AI coding tổng quát có kiến thức rộng nhưng chuyên sâu lĩnh vực hạn chế. Công cụ đặc thù lĩnh vực có chuyên môn sâu nhưng phạm vi giới hạn. Xây đủ kiến thức lĩnh vực vào công cụ mà không khiến nó quá đặc thù đến mức không có thị trường là mâu thuẫn cơ bản.

Sự Hội Tú: Ngành Công Nghiệp Đang Hướng Đến Gì

Điều thú vị ở đây: cả ba cách tiếp cận đều hội tụ về cùng mô hình cơ bản.

Markdown có cấu trúc đang thắng làm lớp kiến thức. Định dạng Agent Skills (agentskills.io) đã được hơn 40 sản phẩm agent chấp nhận — Claude Code, Cursor, GitHub Copilot, VS Code, Gemini CLI, Roo Code, Amp, Factory, và nhiều sản phẩm khác. Định dạng sử dụng file SKILL.md với YAML frontmatter và hướng dẫn markdown, với progressive disclosure: agent chỉ tải tên và mô tả ban đầu, sau đó nội dung đầy đủ khi task khớp.

MCP đang trở thành giao thức công cụ. Model Context Protocol là “USB-C của AI” — đầu nối phổ quát cho agent truy cập công cụ và dữ liệu. Cộng đồng MCP đã thành lập Nhóm Công việc “Skills Over MCP” đang tích cực hợp nhất hai thứ: MCP server nên cung cấp cả công cụ VÀ hướng dẫn sử dụng chúng cùng nhau.

ThoughtWorks Technology Radar tháng 4/2026 chỉ ra hướng đi:

Tín hiệu	Xếp hạng	Ý nghĩa
Context engineering	Adopt	Coi cửa sổ ngữ cảnh như bề mặt thiết kế, không phải ô văn bản
Progressive context disclosure	Trial	Đừng nạp trước mọi thứ; để agent tự kéo những gì cần
Quy mô lệnh agent	Caution	Hướng dẫn dài giảm hiệu suất
Giảm trôi dạt kiến trúc với LLMs	Assess	Ngay cả với spec, trôi dạt vẫn tồn tại và tích lũy

Cách tiếp cận được khuyến nghị là progressive context disclosure: bắt đầu với chỉ mục nhẹ về những gì có sẵn, để agent xác định những gì liên quan, và chỉ kéo những gì cần. Đây là anti-pattern với spec-first — thay vì viết spec toàn diện trước, bạn xây agent tự động khám phá những gì chúng cần.

Truy vấn lai vượt tr tìm thuần vector. Lớp truy vấn kiến thức đang hội tụ kết hợp tìm vector (tương đồng ngữ nghĩa cho nội dung không có cấu trúc), truy vấn có cấu trúc (SQL/Cypher cho tổng hợp và suy luận), và đồ thị kiến thức (cho duyệt mối quan hệ). Mẫu GraphRAG của Neo4j và truy vấn lai của Qdrant minh họa điều này.

Thông tin sâu hơn: định dạng quan trọng less hơn ai tạo ra nó, khi nào nó được viết, và liệu nó có được cập nhật không. File SKILL.md được bảo trì tốt đánh bại spec OpenAPI lỗi thời. Truy vấn trực tiếp đánh bại file Markdown tĩnh. Phỏng vấn có cấu trúc với chuyên gia lĩnh vực đánh bại prompt đoán mò quy tắc kinh doanh.

Khi Nào Sử Dụng Mỗi Cách

Spec-Driven: Cho Nhóm Kỹ Thuật Xây Dựng Phần Mềm Mới

Sử dụng Spec Kit khi bạn bắt đầu dự án mới với nhóm kỹ thuật có thể viết và bảo trì thông số kỹ thuật. Bản hiến pháp, mẫu, và cổng phase hoạt động tốt nhất khi nhóm có từ vựng chung, ngữ cảnh chung, và kỷ luật giữ spec cập nhật.

Sử dụng Specmatic hoặc OpenAPI khi bạn cần thiết kế contract API — giao diện có kiểu giữa các dịch vụ nơi spec nhỏ, tập trung, và có thể enforced bởi máy.

Đừng sử dụng cách tiếp cận spec-driven khi “chuyên gia lĩnh vực” của bạn là chủ doanh nghiệp suy nghĩ theo thuật ngữ giá cả và lịch hẹn, không phải user story và tiêu chí chấp nhận.

Code-First: Cho Codebase Hiện Có Với Agent Hướng Đến Nhà Phát Triển

Sử dụng Mintlify, GitBook, hoặc OpenWiki khi bạn có codebase hiện có và cần coding agent hiểu nó. Cách tiếp cận docs có cấu trúc + MCP của Mintlify đưa ra kết quả đo lường tốt nhất (chính xác hơn 64%, tiết kiệm 50% token).

Sử dụng CLAUDE.md, .cursorrules, hoặc .clinerules cho cấu hình agent cụ thể dự án — nhưng giữ dưới 200 dòng và sử dụng quy tắc theo phạm vi đường dẫn để giảm thiểu chi phí ngữ cảnh.

Đừng sử dụng cách tiếp cận code-first khi kiến thức bạn cần không nằm trong code. Quy tắc kinh doanh, logic giá, và chuyên môn lĩnh vực nằm trong não bộ con người, không nằm trong chữ ký hàm.

Chat-to-Code: Cho Chuyên Gia Lĩnh Vực Không Biết Code

Sử dụng QuotyAI khi chuyên gia lĩnh vực không kỹ thuật cần logic kinh doanh production-ready — hàm pricing, quy tắc xác thực, phép biến đổi lịch trình — từ mô tả ngôn ngữ tự nhiên. Cách tiếp cận đặc thù lĩnh vực hoạt động vì nó giới hạn bài toán: hệ thống biết hàm pricing trông như thế nào và có thể xác minh output theo contract có kiểu.

Đừng sử dụng cách tiếp cận chat-to-code cho phát triển phần mềm tổng quát. Khoảng cách xác minh quá rộng mà không có ràng buộc đặc thù lĩnh vực.

Mô Hình Sâu

Ba triết lý thực ra không cạnh tranh. Chúng trả lời các câu hỏi khác nhau:

Spec-Driven trả lời: “Làm thế nào để đảm bảo AI xây đúng thứ chúng ta dự định?”
Code-First trả lời: “Làm thế nào để đảm bảo AI hiểu đúng thứ đã tồn tại?”
Chat-to-Code trả lời: “Làm thế nào để đảm bảo AI nắm đúng thứ chuyên gia biết?”

Chế độ thất bại thực sự không phải chọn sai cách tiếp cận. Đó là áp dụng cách tiếp cận sai bài toán. Phát triển spec-driven thất bại khi chuyên gia lĩnh vực không thể viết spec. Tài liệu code-first thất bại khi kiến thức không nằm trong code. Chat-to-code thất bại khi lĩnh vực quá rộng để giới hạn.

Stack đang nổi lên sử dụng cả ba: thông số kỹ thuật ở ranh giới API, kiến thức tính toán tại runtime, và hội thoại có cấu trúc cho chuyên môn lĩnh vực. Điểm chung là tài liệu tĩnh, toàn diện, do con người tạo là đơn vị sai. Đơn vị đúng là thứ gì đó giữ được sự cập nhật, giữ được sự gọn gàng, và giữ được sự liên quan với task hiện tại.

Xây dựng runtime deterministic bên dưới mô hình, và vấn đề kiến thức tự giải quyết.

Câu Hỏi Thường Gặp

Sự khác biệt giữa các cách tiếp cận spec-driven, code-first, và chat-to-code là gì? Phát triển spec-driven (GitHub Spec Kit) đảo ngược phát triển truyền thống: thông số kỹ thuật tạo ra code, không phải hướng dẫn code. Tài liệu code-first (OpenWiki, Mintlify) đọc codebase hiện có và viết markdown cho AI agent. Chat-to-code (QuotyAI) cho phép người dùng không kỹ thuật mô tả quy tắc kinh doanh bằng ngôn ngữ tự nhiên và tạo ra TypeScript có thể thực thi. Mỗi cách nhắm đến đối tượng khác nhau: nhà phát triển, nhóm phát triển, và chuyên gia lĩnh vực.

Tại sao các cách tiếp cận spec-driven thất bại ở quy mô lớn? Ba chế độ thất bại đã được ghi nhận: (1) Mục nát ngữ cảnh — nghiên cứu của Anthropic cho thấy hiệu suất mô hình giảm khi cửa sổ ngữ cảnh đầy, do kiến trúc transformer giới hạn sự chú ý mỏng đi trên nhiều token hơn. (2) Quy mô lệnh agent — ThoughtWorks Technology Radar chỉ ra các file AGENTS.md tích lũy và xung đột, làm giảm hiệu suất agent. (3) Chu kỳ mệt mỏi spec — spec phát triển, trở nên cồng kềnh, mất đồng bộ, và nhóm ngừng bảo trì.

Tại sao v0, bolt.new, hoặc Lovable không giải quyết vấn đề chat-to-code cho logic kinh doanh? Các công cụ này nhắm đến người dùng không kỹ thuật nhưng tạo ra UI và ứng dụng frontend, không phải logic kinh doanh phức tạp. Một engine giá với chiết khấu theo tier, add-on có điều kiện, và quy tắc thành viên đòi hỏi sự hiểu biết đặc thù lĩnh vực mà các công cụ chat-to-app tổng quát thiếu. Hiện chưa có sản phẩm lớn nào cho phép chủ doanh nghiệp mô tả quy tắc giá bằng ngôn ngữ tự nhiên và nhận code production-ready, deterministic.

Ngành công nghiệp đang hội tụ về đâu cho kiến thức AI agent? Định dạng Agent Skills (agentskills.io) đã được hơn 40 sản phẩm agent chấp nhận. MCP đang trở thành giao thức công cụ chuẩn. ThoughtWorks Technology Radar tháng 4/2026 khuyến nghị “context engineering” (Adopt) và “progressive context disclosure” (Trial) — coi cửa sổ ngữ cảnh như bề mặt thiết kế và để agent tự kéo những gì cần, thay vì nạp trước toàn bộ thông số kỹ thuật.

Đọc Thêm

Open Knowledge Format (OKF) vs Agent Skills — tại sao thực thi deterministic đánh bại file kiến thức tĩnh
OpenWiki vs QuotyAI — hai dự án LangChain DeepAgents, hai kiến trúc
Determinism as Infrastructure — tại sao nền tảng AI cần thực thi deterministic
Why I Picked Bun and Hono — phân tích quyết định ban đầu cho stack của QuotyAI

Tags: spec-driven-development openwiki mintlify quotyai ai-agents agent-architecture context-engineering deterministic-ai spec-kit agent-skills MCP