# From Coding Assistance to Agentic Coding: How Teams Can Truly Put AI Programming to Work ## 1. What Is AI Programming / Agentic Coding? AI programming is no longer just about “completing a few lines of code.” In the past, when people talked about AI coding, they mostly meant autocomplete in an IDE, code explanation, or function generation. Today, **Agentic Coding** means that AI does more than generate code—it can keep working toward a goal: reading a codebase, understanding conventions, breaking down tasks, modifying files, running commands, executing tests, reporting results, and then waiting for human review. The difference from traditional “Q&A-style AI” is that: - The object it operates on is not just text, but **codebases, terminals, tests, documentation, and task workflows**. - The input it receives is not just a prompt, but **repository context, team conventions, tool permissions, and execution boundaries**. - The output it produces is not just a code snippet, but **a reviewable process and result**. In *Introducing Codex*, OpenAI defines Codex as a software engineering agent that can work on tasks in parallel inside independent cloud sandboxes, and explicitly emphasizes that an `AGENTS.md` file in a repository can tell the agent how to navigate the codebase, run tests, and follow project conventions. In *Claude Code overview*, Anthropic describes this type of tool even more directly: it can read code, edit files, run commands, connect to MCP, remember project information, and execute team workflows through custom commands and hooks. In short, **the focus of AI programming has shifted from “can it write code?” to “can it reliably complete tasks in a real engineering environment?”** --- ## 2. What Mainstream Tools Look Like Now Today’s AI programming tools can be roughly divided into four categories. ### 2.1 IDE Inline Completion Typical examples include IDE-based tools like Cursor, GitHub Copilot, and Windsurf. Their strengths are: - Fast, suitable for everyday coding, completion, and local edits - Barely interrupt the flow state - More like an “enhanced editor” Their limitations are also clear: - Better suited to local tasks, not long-chain tasks - Context usually revolves around the current file or current session - Limited support for “multi-step execution” ### 2.2 Terminal Agent Typical examples include Codex CLI / App and Claude Code. These tools are characterized by: - Working directly in the terminal or a sandbox - Completing tasks across multiple files and directories - Running commands, testing code, checking logs, and generating changes - Being closer to a “collaborative developer” than an “autocomplete plugin” This is also the most important direction to watch in Agentic Coding right now. ### 2.3 Multi-Agent / Asynchronous Collaboration In *Introducing the Codex app*, OpenAI defines the Codex app as an “agent command center.” The core of this category is not one-off generation, but: - Multiple agents running in parallel - Worktrees / isolated copies - Long-running tasks executed asynchronously - Review queues - Scheduled automations This means teams are beginning to move from “I’m talking to one AI” to “I’m dispatching a group of agents to get work done.” ### 2.4 Enterprise Workflow Integration Truly mature adoption will not stop at the IDE or terminal itself, but will continue integrating downstream with: - Issues / tickets - Design - Docs - CI - Release - Review OpenAI’s *How OpenAI uses Codex* and Anthropic’s Claude Code documentation both emphasize the same point: **AI programming is not an isolated tool, but an execution node connected into the software development workflow.** --- ## 3. Why “Context Engineering” Matters More Than Model Parameters If the model determines the ceiling, then context engineering determines the floor. The same agent, in a repository without conventions, boundaries, or tool constraints, can often only produce results that “look right.” But once team rules, common commands, external dependencies, and repeated workflows are solidified, its stability improves noticeably. This is also why I recommend teams prioritize building: 1. `AGENTS.md` 2. `Skill` 3. MCP Not the other way around. ### 3.1 `AGENTS.md` Is the Most Basic Form of Persistent Context The value of `AGENTS.md` lies in turning “things you have to repeat every time” into something fixed inside the repository. The most suitable content to put in it includes: - How to understand the repository structure - Which directories can be modified, and which should not be touched - Standard commands for running tests and builds - Code style, commit conventions, and review requirements - Historical pitfalls and business constraints that cannot be inferred from reading code alone OpenAI explicitly emphasizes the role of `AGENTS.md` in both *Introducing Codex* and *How OpenAI uses Codex*: it gives the agent persistent, stable, cross-task repository context. For teams, `AGENTS.md` solves the problem of **having a unified source of guidance**. ### 3.2 Why I Recommend Teams Prioritize Skill OpenAI’s definition of skill in *Introducing the Codex app* is very clear: **skills bundle instructions, resources, and scripts**. In other words, a skill is not a single prompt, but a reusable, executable, and shareable unit of work. I recommend Skill over treating MCP as the default answer for five main reasons. #### 1. Skill Is Better Suited for Capturing Team Methods What teams truly need to reuse is often not “connecting to a system,” but: - How to do code review - How to write a changelog - How to sync API documentation - How to troubleshoot production issues - How to perform pre-release checks These are essentially **methods, steps, constraints, and scripts**, not “external system connection protocols.” Skill is exactly suited to carrying this kind of content. #### 2. Skill Is Easier to Version and Review Skills can be placed directly in the repository and reviewed, iterated on, and rolled back together with code. This is very important for teams because it means: - Changes are traceable - Rules are reviewable - Experience can be inherited - New members can reuse it OpenAI also explicitly states that skills can be reused across the app, CLI, and IDE extension, and can be checked into a repository for team sharing. #### 3. Skill Usually Has a Smaller Permission Surface Most Skills are centered on: - Instructions - Local resources - Known scripts - Fixed workflows By contrast, MCP often implies: - Additional servers - Remote connections - External authentication - Real-time data access - Executable tool calls For team governance, Skill is usually easier to constrain in terms of permissions and risk. #### 4. Skill Is More Reproducible Skill is more like a “standard operating procedure.” As long as the input conditions are similar, the output path is usually relatively stable. It makes it easier to create assets such as: - Project onboarding skills - Release checklist skills - API documentation sync skills - Incident troubleshooting skills These kinds of assets are far more valuable than one-off prompts. #### 5. Skill Is Better for Landing First, Then Expanding Many teams start by talking about MCP and eventually get stuck on: - How to deploy the server - How to manage authentication - How to authorize data - Which tools can be executed - How to do auditing - How to troubleshoot issues Skill has a much lower starting barrier. If teams first turn high-frequency workflows into Skills, they can already capture 70% of the value. ### 3.3 What MCP Is: Useful, but Not the Default Answer The official MCP specification defines it clearly: it is a **host / client / server** architecture and a JSON-RPC-based protocol for exchanging context and tools. Its core primitives include: - resources - prompts - tools - sampling So, **MCP is more like a “protocol layer” and “access layer”**, not a team methodology. It is certainly useful, especially in scenarios such as: - Reading from external systems like Figma, Google Drive, Jira, Slack, and Linear - Connecting AI to real-time data sources - Exposing clearly defined tool invocation interfaces - Providing unified access across multiple agents / hosts But it also has inherent drawbacks. ### 3.4 Several Practical Problems with MCP The following judgments are my summary based on the official MCP specification, OpenAI / Anthropic documentation, and real-world team implementation experience. #### 1. MCP Solves “Connection,” Not “Method” MCP can tell an agent how to retrieve resources and call tools, but it will not tell a team: - How reviews should be done - How coding standards should be enforced - Which commands should be run - Which steps require human confirmation These still need to be supplemented by `AGENTS.md` and Skill. #### 2. MCP Has Higher Governance Cost Once MCP is introduced, what you bring in is not just a “capability,” but an entire layer of additional complexity: - Host / client / server relationships - Capability negotiation - Authentication and permissions - Service availability - Call failures and retries - Auditing and accountability For many teams, this layer of complexity is not worth it. #### 3. MCP Has a Larger Security Surface MCP often connects to external systems and executable tools. This means you need to additionally consider: - Which data can be exposed to the server - Which tools can be invoked - Whether a remote server is trustworthy - How to restrict network access - Whether prompt injection could amplify the blast radius The official MCP specification itself also emphasizes user consent, data privacy, and host-side security boundaries. In other words, the specification already assumes this is a high-risk surface. #### 4. MCP Is Not Suitable for Carrying Implicit Project Rules The most critical things in a project are often not Jira tickets or Figma designs, but constraints that “only the team itself knows”: - Historical baggage in a particular module - A certain directory that must not be touched - A certain field that must not be changed - A certain test suite that must be run - Certain logs that should be checked first for a certain class of issues These are better written into `AGENTS.md` and Skill, rather than stuffed into an MCP server. ### 3.5 A More Practical Priority Order If the goal is team adoption, my recommended priority is: 1. Write a good `AGENTS.md` first 2. Turn high-frequency workflows into Skills 3. Connect MCP only when real-time external systems are genuinely needed In other words: - `AGENTS.md` solves “how this project should be worked on” - Skill solves “how this task can be done repeatedly and reliably” - MCP solves “how this task can be done by connecting to external systems” This order is more stable and better suited for team-wide adoption. ### 3.6 The Principle: How the Model Knows When to Use MCP, Skill, `CLAUDE.md`, and `AGENTS.md` This is the part that is easiest to explain vaguely. Many talks lump all these things together and describe them as “feeding context to the model.” That is not accurate enough. Their principles, triggering mechanisms, and control points are actually completely different. Let’s start with the most important judgment: | Mechanism | Essence | Who Controls Triggering | When It Enters Context | |------|------|------------|--------------------| | `AGENTS.md` | Repo-level persistent instruction manual | Agent / host reads it at the start of the task | Usually as persistent context when a repo task starts | | `CLAUDE.md` | Project / user / organization-level persistent instruction manual | Loaded when Claude Code starts and reads directories | Loaded at startup; subdirectory rules are loaded on demand | | Skill | Reusable workflow package | The model matches based on description, or the user specifies it explicitly | Metadata is loaded first; after a hit, the body and resources are loaded | | MCP Prompts | Templated prompts | User-controlled | Enter when the user selects or executes them | | MCP Resources | External resource references | Host / application-controlled, and can also be explicitly referenced by the user | Enter when attached or referenced | | MCP Tools | External tool-call interfaces | Model-controlled, but the host is responsible for permissions | Executed only when the model decides to call them | ### 3.7 What Is the Principle Behind MCP? MCP is not “a plugin,” but a protocol. The official specification defines it as a **host / client / server** architecture: - the host is responsible for coordination, authorization, and enforcing security policies - the client connects to a specific server on behalf of the host - the server exposes capabilities such as prompts, resources, and tools MCP’s underlying communication is JSON-RPC. The standard lifecycle is very clear: 1. `initialize` first 2. perform capability negotiation 3. then enter normal operation In other words, **the model does not “know all the tools” right from the start**. First, the host negotiates the available capabilities; afterward, the model and application work within those boundaries. ### 3.8 How Exactly Is MCP Triggered? This needs to be split into 3 categories. The official specification states this very clearly: - Prompts are **user-controlled** - Resources are **application-controlled** - Tools are **model-controlled** All 3 may look like “capabilities,” but their triggering mechanisms are completely different. #### 3.8.1 MCP Prompts: User-Triggered An MCP prompt is more like a reusable template command. It is usually triggered in these situations: - the user selects it from a menu - the user executes a slash command - the user explicitly invokes a certain prompt template So a prompt is not something the model secretly uses by itself. Instead, **the user selects it, and the host expands the template for the model**. #### 3.8.2 MCP Resources: Triggered When Referenced by the Application or User A resource is context, not an action. It has two typical triggering methods: - the host attaches it automatically - the user references it explicitly Anthropic’s Claude Code documentation gives a very concrete example: an MCP resource can be referenced like a file with `@server:protocol://path`; once referenced, the resource is automatically fetched and placed into the context as an attachment. So the essence of a resource is not “letting the model execute something,” but **feeding external content to the model to inspect**. #### 3.8.3 MCP Tools: The Model Decides Whether to Call Them Tools are the layer closest to “the agent taking action in the external world.” According to the official MCP specification, tools are **model-controlled**. That means: - the host first exposes the callable tools - the model decides during reasoning whether it needs to use them - before and after actual execution, the host is still responsible for permissions, isolation, confirmation, and logging So the phrase “how the model triggers MCP” is, strictly speaking, only valid for the tools part; prompts and resources do not follow the same triggering logic. ### 3.9 What Is the Principle Behind Skills? A Skill is not an external connection protocol, but a **loadable workflow package**. OpenAI’s *Introducing the Codex app* defines skills as bundles of instructions, resources, and scripts. Anthropic’s Agent Skills documentation explains the principle in more detail: a Skill is a directory inside a VM / file system, containing `SKILL.md`, scripts, and reference materials, and Claude loads it in stages through progressive disclosure. This is extremely important, because it explains why Skills are more suitable for team adoption. The essence of a Skill is not “connecting an external system,” but: - packaging team methods - placing instructions, resources, and scripts in the same unit - letting the model load them only when needed, instead of occupying context all the time ### 3.10 How Are Skills Triggered? #### 3.10.1 OpenAI / Codex’s Public Position As of **February 2, 2026**, OpenAI’s *Introducing the Codex app* publicly says: - you can **explicitly ask** Codex to use a certain skill - you can also let it **use one automatically based on the current task** OpenAI’s public materials currently do not describe the internal layered loading mechanism in as much detail as Anthropic does. Based on public information, a safer understanding is: - a skill has at least “discoverable description information” - the agent routes to skills based on task semantics - after a hit, it uses the instructions / resources / scripts inside that skill The last two points here are **inferences based on public behavior**, not implementation details that OpenAI’s current public documentation spells out item by item. #### 3.10.2 Anthropic / Claude’s Public Position Anthropic discloses this part in more detail. The official documentation describes Skill triggering in three layers: 1. **Metadata** is loaded persistently `name` and `description` enter the system prompt at startup for discovery and matching. 2. The **body of `SKILL.md`** is loaded when triggered When the user request matches the skill description, Claude reads `SKILL.md`. 3. **Additional resources and scripts** are loaded on demand Only when the body references extra documents or scripts does Claude continue reading or executing them. This is typical progressive disclosure. So Skill triggering is not “the entire skill package is always in context,” but: - first know “which skills exist” - then judge “whether the current task resembles this skill” - only after a hit, read the instruction manual - only expand further when more material is needed This is also the fundamental reason Skills are more efficient than “large system prompts.” ### 3.11 What Is `CLAUDE.md` For, and When Is It Used? `CLAUDE.md` is not a command or a plugin. It is **Claude Code’s persistent instruction file**. Anthropic’s official documentation states it very directly: - `CLAUDE.md` is used to give Claude ongoing project rules, workflows, and architecture information - Claude reads it at the **start of every session** - `CLAUDE.md` files in parent directories are fully loaded at startup - `CLAUDE.md` files in subdirectories are loaded on demand when Claude reads files in those directories More importantly, Anthropic also distinguishes it from auto memory: - `CLAUDE.md` is instructions and rules written by you - auto memory is learnings and patterns accumulated by Claude itself In other words, the principle behind `CLAUDE.md` is not a “memory library,” but **a manually maintained, reviewable, systematic instruction manual that works across sessions**. If you ask “when does the LLM use `CLAUDE.md`,” the most accurate answer is: - it is used as soon as the session starts - when entering a specific directory / reading specific files, finer-grained rules continue to be loaded - it is not something the model only looks for when it happens to think of it; Claude Code’s context-loading mechanism itself handles it Anthropic also adds another layer with `.claude/rules/`: - rules without path restrictions are loaded at startup - rules with `paths` are triggered only when matching files are read - the official documentation even states clearly: if the instructions are “task-oriented, not persistent,” you should prefer Skill instead of stuffing everything into persistent rules This is very much worth copying. ### 3.12 What Is `AGENTS.md` For, and When Is It Used? First, let’s correct one name. As of OpenAI’s public materials — **Introducing Codex** on **May 16, 2025**, and **How OpenAI uses Codex** in **October 2025** — the official name OpenAI uses is **`AGENTS.md`**, not `agent.md`. The role of `AGENTS.md` in the Codex system is very similar to `CLAUDE.md`, though the publicly available details are not as granular as Anthropic’s. OpenAI has clearly disclosed two points: - `AGENTS.md` can tell Codex how to navigate the codebase, which tests to run, and which project conventions to follow - it can provide Codex with **persistent context** This means it is essentially also a **repository-level persistent instruction file**. That said, it is worth noting that OpenAI’s public materials have not spelled out “loading order, on-demand subdirectory loading, path-rule triggering” as explicitly as Anthropic has. So the safer conclusion is: - `AGENTS.md` is referenced as ongoing context when Codex handles repo tasks - it is suitable for project conventions, commands, boundaries, and architectural hints - it is not an “external tool trigger,” nor is it a “knowledge block loaded temporarily only when asked about” If we go one step further and say “Codex definitely loads `AGENTS.md` at a specific moment, and definitely merges it in a specific order,” that goes beyond the currently public materials. That part can only be treated as an **implementation-level inference**, and should not be written as a definitive conclusion. ### 3.13 Explaining These 4 Mechanisms in One Sentence If I had to distinguish them in one sentence during a talk, I would put it this way: - `AGENTS.md` / `CLAUDE.md`: the **long-term manual** for a repository or project - Skill: a **workflow package** triggered by a task - MCP Resource: **referenceable context** from an external system - MCP Tool: an **action interface** the model can call within defined boundaries Once these four categories are separated clearly, many of the phenomena behind “why AI programming sometimes feels extremely capable, and sometimes surprisingly dumb” become explainable. --- ## 4. How to Handle Security, Sandboxing, and Permission Control AI programming cannot only be about efficiency; it must also be about boundaries. Once an agent can read files, modify code, run commands, and access the internet, its risk model is already completely different from that of an ordinary chatbot. Anthropic makes this very clear in *Making Claude Code more secure and autonomous with sandboxing*: what really matters is two layers of isolation. - File system isolation - Network isolation Only when both layers are in place can we talk about “letting an agent act autonomously more safely.” OpenAI gives a similar direction in *Introducing the Codex app*: by default, the agent is only allowed to edit files inside the working directory; network access is restricted by default; and commands that cross boundaries require authorization. When teams implement this in practice, I recommend doing at least the following. ### 4.1 Default to Least Privilege A good starting point is: - Read-only by default - Only allow access to the current working directory by default - Disable network access by default, or only allow cached search - Disallow high-risk commands by default Do not give the agent full-disk read/write access and unrestricted internet access from the beginning. ### 4.2 Make File System Boundaries Clear The most basic restrictions should include: - Only allow modifications to the current repo or current worktree - Forbid access to sensitive directories - Forbid touching SSH keys, signing keys, and global configuration - Separately constrain output directories, cache directories, and temporary directories ### 4.3 Whitelist Network Permissions If the agent needs network access, I recommend only opening access to explicit domains: - Documentation sites - Package repositories - Specific APIs - Specific internal services Do not allow “arbitrary outbound access.” ### 4.4 Any Privilege Escalation Must Be Visible The ideal state is not “nothing ever goes wrong,” but rather: - It gets blocked as soon as it crosses a boundary - Every step it takes is logged - The commands it ran are traceable - The outputs it saw can be reviewed This matters more than simply “trusting the model.” ### 4.5 Leave High-Risk Actions to Humans For the following actions, I recommend requiring human confirmation by default: - Pushing remote branches - Modifying production configuration - Deleting large numbers of files - Executing database changes - Calling real production write APIs - Accessing sensitive business data The agent can prepare the action, but it is better not to let it perform the final step automatically. --- ## 5. How to Measure Impact, Not Just Watch Demos The most misleading thing about AI programming for teams is that demos often look impressive. But the real question is not “can it produce an example,” but: - Can it handle real tasks reliably? - Can it be reproduced in a team environment? - How much rework and review cost does it introduce? - Is it actually improving efficiency, or just pushing the cost downstream? ### 5.1 What External Benchmarks Can Tell You SWE-bench is currently one of the most worthwhile public benchmarks to reference. Its value lies in the fact that: - It uses real GitHub issues - It provides reproducible Docker-based evaluation environments - It measures whether a task is truly solved and passes tests - It is not just comparing who can generate a plausible-looking piece of code This kind of benchmark is very useful for explaining: **why evaluating AI programming cannot rely only on demo videos and one-off examples.** ### 5.2 But Teams Cannot Look Only at Benchmarks SWE-bench answers “how models / agents compare on public tasks.” That is not the same as “your team is already improving efficiency.” What teams should really look at are their own internal metrics. ### 5.3 The 8 Metrics Worth Tracking I recommend that teams track the following metrics: | Metric | Question It Answers | |------|--------------| | Time to first usable patch | How quickly the agent can produce a first version that is reviewable | | Task completion rate | Whether the assigned task actually gets finished | | First-pass merge rate | How close the first output is to being mergeable | | Human rework time | How much extra time humans spend turning the result into something deliverable | | Test pass rate | Whether the agent proactively adds tests, runs tests, and fixes failures | | Review rejection rate | Whether code quality, conventions, and edge-case handling are stable | | Documentation sync rate | Whether docs, changelogs, and API descriptions keep up after code changes | | Security boundary violations | How many times the agent attempts to cross permission boundaries | These metrics are far more useful than “it generates very quickly” or “it looks smart.” ### 5.4 A Simple Evaluation Framework I recommend dividing AI programming evaluation into three layers: #### Layer 1: Public Benchmarks Look at the general upper bound of models and agents, such as SWE-bench. #### Layer 2: Team Standard Task Set Create a fixed set of tasks yourself, such as: - Fixing a real bug - Adding an API field and updating the documentation - Adding a set of tests - Performing a refactor - Handling a production alert This layer is the most important. #### Layer 3: Real Engineering Metrics Ultimately, look at: - Whether delivery cycles have shortened - Whether the rework rate has decreased - Whether production incidents have increased - Whether documentation and processes have become more complete Only when the third layer improves can AI programming be considered truly adopted. --- ## 6. Team Adoption Advice: Skills First, MCP Later If I were to give a team a very pragmatic rollout sequence, I would recommend doing it this way. ### Step 1: Get `AGENTS.md` Right First At minimum, clearly document: - Project structure - Core commands - Testing and build methods - Boundaries that must not be crossed - Commit and review requirements ### Step 2: Turn High-Frequency Tasks into Skills The tasks most worth prioritizing as Skills are usually: - code review - changelog generation - release checks - API documentation synchronization - troubleshooting - new member onboarding ### Step 3: Connect Only Capabilities That “Must Use External Systems” to MCP For example: - Figma - Jira / Linear - documentation repositories - read-only data systems Do not pile everything onto MCP. ### Step 4: Discuss Automation and Multi-Agent Last Only after `AGENTS.md`, Skills, security boundaries, and evaluation methods are relatively stable should you introduce: - automations - multi-agent - asynchronous execution of long-running tasks - scheduled inspections This sequence is much more reliable than “connecting a pile of tools first and slowly adding governance later.” --- ## 7. A Core Takeaway Worth Sharing If this talk leaves people with only four sentences, I recommend these four: 1. AI programming has moved from “code completion” into “Agentic Coding”; the key question is whether it can complete tasks in real engineering environments. 2. The key to team adoption is not model parameters, but context engineering—especially `AGENTS.md` and Skills. 3. MCP is very useful, but it is better suited for integrating external systems and should not replace team methodology; the default priority should be `AGENTS.md` > Skill > MCP. 4. Evaluating AI programming cannot rely on demos alone; it must look at sandboxes, security boundaries, real task completion rates, and long-term engineering metrics. --- ## Appendix: Core Reference Materials ### The 5 Most Worth Digesting - [OpenAI, “Introducing Codex”](https://openai.com/index/introducing-codex/) - [OpenAI PDF, “How OpenAI uses Codex”](https://cdn.openai.com/pdf/6a2631dc-783e-479b-b1a4-af0cfbd38630/how-openai-uses-codex.pdf) - [Anthropic, “Claude Code overview”](https://code.claude.com/docs/en/overview) - [Official MCP Specification](https://modelcontextprotocol.io/specification/2024-11-05/index) - [Official SWE-bench Overview](https://www.swebench.com/SWE-bench/) ### Useful Supplementary Materials - [OpenAI, “Introducing the Codex app”](https://openai.com/index/introducing-the-codex-app/) - [Anthropic, “How Claude remembers your project”](https://code.claude.com/docs/en/memory) - [Anthropic, “Agent Skills Overview”](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) - [Anthropic, “Making Claude Code more secure and autonomous with sandboxing”](https://www.anthropic.com/engineering/claude-code-sandboxing) - [MCP Architecture](https://modelcontextprotocol.io/specification/2024-11-05/architecture/index) - [MCP Server Features Overview](https://modelcontextprotocol.io/specification/2024-11-05/server) - [OpenAI, “Codex is now generally available”](https://openai.com/index/codex-now-generally-available/) - [OpenAI, “Introducing upgrades to Codex”](https://openai.com/index/introducing-upgrades-to-codex/) ### Secondary Reference Layer: How to Incorporate Talks, Shares, and Experience-Based Materials These materials are very valuable, but their usage needs to be clearly distinguished. My suggestion is to divide materials into two layers: - **Primary materials**: official documentation, official blogs, official specifications Used to define the “fact layer” and “mechanism layer.” - **Secondary materials**: personal talks, experience sharing, third-party interpretations Used to supplement the “narrative layer,” “case layer,” “perspective layer,” and “points of debate.” In other words: - For principles, definitions, and trigger timing, prioritize official materials from OpenAI / Anthropic / MCP - For cases, experience, topic angles, and presentation rhythm, you can cite the secondary materials below - If a secondary material makes a strong factual claim, it is best to verify it against primary materials before writing it into the main text ### Geoffrey Challen, “A Day With Claude: Using and Teaching Coding Agents” - Link: [Geoffrey Challen, “A Day With Claude: Using and Teaching Coding Agents”](https://www.geoffreychallen.com/talks/2026-01-15-a-day-with-claude-using-and-teaching-coding-agents) - Suitable placement: `What Is Agentic Coding`, `How Team Workflows Change`, `How Education and Organizations Should Adapt` - Points suitable for citation: This material feels like a complete keynote, with a very mature rhythm. It is not simply about tools; instead, it turns the new way of working—“Plan -> approve -> agent implements -> verify with tests”—into a complete story arc. - Content worth borrowing: - Use “a day’s workflow” to explain agentic coding, rather than stacking definitions from the start - Emphasize the shift “from iterating on implementation to iterating on plans” - Emphasize that testing is not an accessory, but the secret weapon of the agent loop - Emphasize that organizations and education systems must adapt to this new way of working - Recommendation when writing it into the document: This is better placed in a chapter on “trends and workflow changes” as an experience-based case. Do not treat his personal usage data directly as an industry-wide conclusion. ### Claude Code Anonymous, “Agentic Coding: Real Talk from the Trenches” - Link: [Claude Code Anonymous, “Agentic Coding: Real Talk from the Trenches”](https://plattenschieber.github.io/agent-presentation/) - Suitable placement: `Topic Angle Library`, `Common Misconceptions`, `Experience-Based Sharing Materials` - Points suitable for citation: This is not a single material, but an entire presentation collection. Its value lies less in “giving you an authoritative conclusion” and more in helping you see “what angles others use to talk about agentic coding.” - Content worth borrowing: - Title packaging approaches - Entry points for experience-based talks - Topics that easily resonate - Concepts that are suitable to split out into standalone slides - Recommendation when writing it into the document: There is no need to cite it heavily in the main text. You can create a separate subsection called “Reference Pool for Sharing Topics” and use it as a source of inspiration for later material organization. ### Mitsuhiko, “Agentic Coding: The Future of Software Development with Agents” - Link: [Mitsuhiko, “Agentic Coding: The Future of Software Development with Agents”](https://speakerdeck.com/mitsuhiko/agentic-coding-the-future-of-software-development-with-agents) - Suitable placement: `Overview Section`, `Why Agentic Coding Suddenly Took Off`, `Tool Landscape` - Points suitable for citation: This is very suitable as an overview perspective. It defines agentic coding relatively clearly and explicitly discusses tools, workflow, observability, and context conservation. - Content worth borrowing: - Define agentic coding as “a software development process where AI is not just suggesting code, but participating in planning / implementing / refining” - Emphasize principles for tool and workflow design - Clearly point out that “too much MCP will cause context rot faster,” and recommend using MCP cautiously for coding agents - Recommendation when writing it into the document: This is very suitable for strengthening our current argument that “Skills should come first, with MCP in a supplementary role.” It is not an official specification, but it provides strong practical support. ### hiromitsusasaki, “The World Has Changed” - Link: [hiromitsusasaki, “The World Has Changed”](https://speakerdeck.com/hiromitsusasaki/world-has-changed) - Suitable placement: `Industry Overview`, `Plan Mode / Spec-Driven Development`, `Ecosystem Changes` - Points suitable for citation: This material is very new and closely aligned with the direction you want to discuss. It connects spec-driven development, the popularization of Plan mode, and ecosystem changes across Kiro / Claude Code / Copilot / Cursor. - Content worth borrowing: - “Plan first, code later” is becoming a mainstream interaction pattern - Spec-driven development can serve as a higher-level methodology for agentic coding - The tool ecosystem has already moved from single-point completion into a stage of “multiple tools coexisting + layered workflows” - Recommendation when writing it into the document: This fits well in the sections “why it suddenly became popular now” and “how ways of working are changing,” helping elevate the perspective. ### Gota, “I Want to Use Agent Skills in Codex Too” - Link: [Gota, “I Want to Use Agent Skills in Codex Too”](https://speakerdeck.com/gotalab555/codexdemoagent-skillswoshi-itai) - Suitable placement: `Skill vs MCP`, `How to Transfer the Skill Approach to Codex`, `Context Engineering` - Points suitable for citation: This material is highly aligned with the current main thread of our document. It explicitly discusses: - Loading MCP servers consumes a considerable number of tokens - Connecting too many MCP servers reduces tool-selection accuracy - Skills can support layered loading - `AGENTS.md` can help Codex recognize and autonomously choose skills - Content worth borrowing: - Explain Skills using the structure of L1 metadata / L2 `SKILL.md` / L3 scripts - Explain why coding agents are better suited to Bash / Shell + Skills, rather than endlessly stacking MCP - Explain that `AGENTS.md` can take on the role of “letting Codex know which skills are available” - Recommendation when writing it into the document: This should be absorbed heavily, especially as a supplement to our existing section on “why Skills are more suitable than MCP for teams.” ### Sunagaku, “What I Realized After Using Codex Extensively: Claude Code’s Real Strengths and How to Use It Well” - Link: [Sunagaku, “What I Realized After Using Codex Extensively: Claude Code’s Real Strengths and How to Use It Well”](https://speakerdeck.com/sunagaku/codexwoshi-idao-siteqi-tuita-claude-codenoben-dang-noqiang-mitoshi-ikonasishu) - Suitable placement: `Practical techniques`, `multi-agent / review agent`, `tool comparison` - Points suitable for citation: The greatest value of this kind of material is not that it provides definitions, but that it helps explain “how to actually use it” in a more grounded way. - Content worth borrowing: - How to explain the differences between Codex and Claude Code - How to explain practical patterns such as subagents / review agents - How to turn experience into workflows that others can directly copy - Recommendation when writing it into the document: This is better placed in the later “usage techniques / practical experience” section, rather than in the earlier chapters on principles. ### PromptLayer, “Watch my AI Engineering talk: How Claude Code Works” - Link: [PromptLayer, “Watch my AI Engineering talk: How Claude Code Works”](https://blog.promptlayer.com/watch-my-ai-engineering-talk/) - Suitable placement: `agent loop principles`, `why Bash matters`, `why subagents are effective` - Points suitable for citation: This one leans more toward a “principles breakdown.” Several points it emphasizes are especially worth absorbing: - `CLAUDE.md` is essentially an editable markdown instruction file - Bash is the universal adapter for coding agents - The value of subagents is that they isolate subtasks into separate context windows, avoiding pollution of the main context - Recommendation when writing it into the document: This fits well near “Skill / context engineering / agent loop,” where it can help explain why simple tool combinations can be effective. ### How These Secondary Sources Connect to the Current Document I suggest introducing them like this: 1. Add Geoffrey and Mitsuhiko in “What Is Agentic Coding” Use them to strengthen the overview and the narrative around changes in working style. 2. Add Gota and PromptLayer in “Skill / MCP / AGENTS.md / CLAUDE.md Principles” Use them to strengthen points about layered Skill loading, Bash, subagents, and the limitations of MCP. 3. Add hiromitsusasaki in “Why It Is Popular Now” and “Industry Changes” Use it to connect spec-driven development, Plan mode, and ecosystem shifts. 4. Add Sunagaku and Claude Code Anonymous in “Practical Techniques” or a future “Experience” section Use them to enrich examples, framing angles, and hands-on experience. ### Usage Principles at the Current Stage At this stage, I recommend keeping the following principles in the main text: - **Mechanisms, definitions, and trigger methods**: prioritize official sources - **Experience, framing, and practical viewpoints**: supplement with these shared materials - **Debatable judgments**: clearly label them as “practice-based viewpoints” rather than “protocol facts”