# From Assisted Coding to Integrated R&D: Putting AI Programming into Team Practice (PPT)

# From Assisted Coding to Integrated R&D
## How teams can truly put AI programming to work

Plan / Skill / AGENTS.md / Security boundaries / Effectiveness evaluation

---
layout: section
---

# 1. First, clarify the concepts

---

# What is AI programming

- It is not just code completion
- It is not just answering “what does this code mean?”
- It is not just generating a function or component

A more accurate term now is:

## Agentic Coding

AI works continuously toward a goal:

- Read the codebase
- Understand the rules
- Break down the task
- Modify files
- Run commands
- Execute tests
- Report results

---

# The difference between Agentic Coding and traditional AI coding

| Dimension | Traditional AI coding | Agentic Coding |
|------|--------------|----------------|
| Input | A prompt | Repository + rules + tools + permissions |
| Output | Code snippets / suggestions | A reviewable process and result |
| Scope of work | Current file / current question | Multi-file / multi-step / long-chain tasks |
| Tool capabilities | Completion, explanation, generation | Read and write code, run commands, test, call tools |
| Collaboration style | Q&A-style | Task-based / agent-based |

---
layout: section
---

# 2. What mainstream tools look like

---

# The 4 main forms of mainstream tools today

1. IDE inline completion tools  
   Cursor / Copilot / Windsurf

2. Terminal agent tools  
   Codex CLI / App / Claude Code

3. Multi-agent / asynchronous collaboration tools  
   worktree, review queue, automations

4. Enterprise workflow integration tools  
   issue / docs / CI / design / review

---

# IDE inline completion tools

Advantages:

- Fast
- Does not interrupt flow
- Good for daily coding
- Good for localized changes

Limitations:

- Better suited for short tasks
- Limited ability on multi-step tasks
- Context usually centers on the current file

Conclusion:

## More like an “enhanced editor”

---

# Terminal agent tools

Examples:

- Codex App / CLI
- Claude Code

Characteristics:

- Operate directly on the codebase
- Can modify files across directories
- Can run commands and tests
- Better suited for large and long-running tasks
- Closer to a “collaborative developer”

Conclusion:

## This is the route in Agentic Coding most worth paying attention to

---

# Multi-agent / asynchronous collaboration tools

Keywords:

- Multiple agents in parallel
- worktree isolation
- review queue
- automations
- Asynchronous execution of long tasks

What changes:

From “I am talking to one AI”

To

## “I am orchestrating a group of agents to do work”

---
layout: section
---

# 3. What really determines results is not model parameters

---

# Why context engineering matters more

With the same model:

- Without rules, output often “looks right”
- Without boundaries, it can easily exceed its authority
- Without process, rework and review costs are high

Once rules, commands, boundaries, and processes are solidified:

- Stability improves
- Reusability improves
- Team collaboration costs go down

---

# The implementation order I recommend for teams

## `AGENTS.md` > Skill > MCP

Reasons:

- `AGENTS.md` solves the need for a unified project-wide understanding
- Skills solve the reuse of high-frequency workflows
- MCP solves external system integration

Do not do it in reverse.

---

# What `AGENTS.md` is for

It is:

## A repository-level persistent instruction manual

What it is suitable for:

- Repository structure
- What can be changed and what cannot
- Test and build commands
- Code style and review requirements
- Historical pitfalls and business constraints

Value:

- Project rules are automatically included in every conversation
- Reduces the cost of repeatedly explaining project background

---

# Why Skills are more suitable than MCP for initial team adoption

Skills are better suited to carrying:

- code review
- changelog generation
- YApi docs-sync
- issue troubleshooting
- release checks
- onboarding

In essence, they capture:

## Methods, steps, constraints, and scripts

Rather than just “an external connection protocol.”

---

# The 5 advantages of Skills

1. Better for capturing team methods
2. Easier to version and review
3. Usually have a smaller permission surface
4. More reproducible
5. Better suited for landing first, then expanding

In one sentence:

## Skills are more like “standard operating procedures”

---

# MCP is useful, but not the default answer

MCP is better suited for:

- Figma
- Jira / Linear
- Google Drive / Docs
- Slack / external knowledge bases
- Real-time data systems

What it solves is:

## A connectivity problem

Not:

## A team methodology problem

---

# Some practical issues with MCP

1. It solves connectivity, not methodology
2. Governance cost is higher
3. The security surface is larger
4. It is not suitable for carrying implicit project rules

Typical implicit rules include:

- Which directories must not be touched
- Which fields must not be changed
- Which test suites must be run
- Which logs to check first for which kinds of issues

These are better written into `AGENTS.md` and Skills.

---
layout: section
---

# 4. The principles need to be explained clearly

---

# How does the model know when to use these mechanisms

| Mechanism | Essence | Triggered by |
|------|------|--------|
| `AGENTS.md` | Repository-level persistent instruction manual | Read by the agent / host when a task starts |
| `CLAUDE.md` | Claude Code persistent instruction file | Loaded at startup, with subdirectories loaded as needed |
| Skill | Reusable workflow package | Matched by the model or explicitly specified by the user |
| MCP Prompt | Template prompt | Triggered by the user |
| MCP Resource | External context | Attached by the application or referenced by the user |
| MCP Tool | External action interface | The model decides whether to call it |

---

# What is the principle behind MCP

MCP is not a plugin, but a protocol.

Core structure:

- host
- client
- server

Core capabilities:

- prompts
- resources
- tools
- sampling

How it works:

1. initialize
2. capability negotiation
3. normal operation

---

# What is the principle behind Skills

A Skill is not a prompt.

It is more like a directory-based workflow package:

- `SKILL.md`
- scripts
- references
- resources

Key point:

## Loaded on demand, rather than always occupying context

This is also why Skills can be more efficient than a “large system prompt.”

---

# The difference between `CLAUDE.md` and `AGENTS.md`

What they have in common:

- Both are persistent instruction files
- Both are used to inject project rules into coding agents

Differences:

- `CLAUDE.md`: Anthropic has published a more detailed loading mechanism
- `AGENTS.md`: OpenAI clearly states that it provides persistent context, but fewer implementation details are publicly available

Conclusion:

## Neither is a tool invoker; both are entry points for long-term context

---
layout: section
---

# 5. Security, sandboxing, and permission control

---

# AI programming cannot be discussed only in terms of efficiency

Once an agent can:

- Read files
- Modify code
- Run commands
- Access the network

The risk model changes completely.

What really needs to be discussed is:

- Filesystem isolation
- Network isolation
- Least privilege
- Human confirmation
- End-to-end traceability

---

# I recommend teams do at least 5 things

1. Default to least privilege
2. Restrict filesystem boundaries
3. Use a network allowlist
4. Make all privilege overreach visible
5. Require human confirmation for high-risk actions

Examples of high-risk actions:

- Pushing remote branches
- Changing production configuration
- Deleting large numbers of files
- Running database changes
- Calling real online write APIs

---
layout: section
---

# 6. How to measure results, not just demos

---

# Why demos alone are not enough

A demo often only answers:

- Does it look smart
- Can it generate a decent piece of code

What teams really should ask is:

- Can it handle real tasks reliably
- Can it be reproduced in the team environment
- How much rework and review cost does it introduce
- Does it actually improve delivery efficiency

---

# What external benchmarks can tell us

The value of SWE-bench:

- Real GitHub issues
- A reproducible evaluation environment
- It measures whether problems can actually be fixed and tests can pass

What it shows:

## Evaluating AI programming cannot rely only on demo videos and one-off examples

But it does not directly mean:

## Your team has already improved efficiency

---

# The 8 metrics teams should track more closely

- Time to first usable patch
- Task completion rate
- First-pass merge rate
- Manual rework time
- Test pass rate
- Review rejection rate
- Documentation sync rate
- Security overreach count

In one sentence:

## Look at the quality of real task completion, not just generation speed

---
layout: section
---

# 7. Back to real team implementation

---

# How we are implementing it now

- Use Plan mode to break down work before development
- Use a Skill system to solidify high-frequency workflows
- Use YApi docs-sync as the unified source of truth for API facts
- Use changelogs to preserve a trace of changes
- Let AI do the first round of review, with humans making the final judgment

The goal is not “to let AI replace people”

But rather:

## Let AI enter the R&D workflow and become stable productive capacity

---

# Which Skills are most valuable in our team

Global-level:

- YApi Skill
- ZenTao Skill

Project-level:

- Log Skill
- KV Skill
- Database Skill

The value is not in “how advanced” they are

But in:

## High-frequency, stable, reusable, reviewable

---

# A real collaboration example

When an API field changes:

- Backend: modify code
- Backend: use YApi Skill to do docs-sync
- Frontend: read YApi changes
- Frontend and backend: align integration according to the Plan

Results:

- Documentation and code stay more consistent
- Less repetitive communication
- YApi becomes the single source of truth

---

# The most pragmatic order for team adoption

1. First write `AGENTS.md` well
2. Turn high-frequency tasks into Skills
3. Connect only necessary external systems through MCP
4. Only then talk about automations and multi-agent

This order is more stable than “stack tools first, then patch governance later.”

---
layout: section
---

# 8. In the end, just remember 4 sentences

---

# Core conclusions

1. AI programming has moved from “code completion” into “Agentic Coding”
2. The key to team adoption is not model parameters, but context engineering
3. The default priority should be `AGENTS.md` > Skill > MCP
4. AI programming should not be evaluated only by demos, but by boundaries, quality, and real R&D metrics

---

# References

- OpenAI, "Introducing Codex"
- OpenAI, "Introducing the Codex app"
- OpenAI PDF, "How OpenAI uses Codex"
- Anthropic, "Claude Code overview"
- Anthropic, "How Claude remembers your project"
- Anthropic, "Making Claude Code more secure and autonomous with sandboxing"
- MCP official specification / MCP Architecture
- SWE-bench official Overview

---

# Thank you

Discussion keywords:

`Agentic Coding` / `Skill` / `MCP` / `AGENTS.md` / `CLAUDE.md`