code-engineering

Coding Agent Mode

R — Reading

Claude Code implements file memory, Agent subtask delegation, parallel tool invocation, Git safety protocols, and the "measure twice, cut once" principle; Codex has dirty working tree awareness, a Plan tool with skip rules, and code review ordered by severity; Jules defines a plan→review→execute lifecycle and uses Playwright to verify the frontend; Claude Design pins React+Babel versions and establishes anti-AI-slop guidelines. Core patterns: safety-first Git workflow, plan lifecycle management, context-aware editing, verification loops, and autonomous vs. guided modes.

I — Methodological Skeleton (Interpretation)

1. Safety-first Git workflow: Any destructive operation (force push, hard reset, clean) requires explicit user confirmation, prefer creating new commits over modifying existing commits, and protect the main branch.
2. Plan lifecycle management: Adopt a three-phase plan→review→execute model—first understand the intent and generate a plan, execute only after user confirmation, and verify the results after execution.
3. Context-aware file editing: Read the file contents before editing, understand the context before modifying, and avoid destructive overwrites; prefer diff-based edits over full-text rewrites.
4. Verification loop: After code modifications, run tests or build verification; for frontend changes, use browser tools to take screenshots and confirm the visual effect.
5. Switching between autonomous and guided modes: Simple tasks can be completed autonomously (YOLO mode), while complex tasks require step-by-step confirmation; automatically select the mode based on the nature of the task.
6. Anti-AI-slop rules: Prohibit generating typical AI-style code (excessive comments, unnecessary abstractions, redundant type declarations), and pursue concise, professional engineering code.

A1 — Case Analysis (Past Application)

Case: Claude Code's Git safety protocol

• Problem: A coding agent may perform destructive Git operations (such as force push to the main branch or hard reset that loses uncommitted work), resulting in the loss of code assets.
• Use of the design pattern: Claude Code establishes a complete safety protocol in the system prompt—never perform destructive operations unless the user explicitly requests them, prefer creating new commits over amend (amend overwrites the history of the previous commit), check whether hooks pass before committing, and do not skip --no-verify. It also requires specifying specific file names rather than git add -Awhen staging files, to avoid accidentally including sensitive files.
• Conclusion: Git safety cannot rely on model judgment; it must be declared in the system prompt as hard rules, upgrading high-risk operations from "advised to be cautious" to "must confirm."

Case: Jules's plan→review→execute lifecycle

• Problem: A coding agent that directly starts modifying code can easily deviate from the user's intent, especially for multi-file changes, where the cost of fixing erroneous modifications is far higher than the cost of correction during the planning phase.
• Use of the design pattern: Jules divides programming tasks into three phases—Plan (understand requirements, analyze the codebase, generate a change plan), Review (present the plan for user review and confirmation), and Execute (carry out the modifications according to the plan). Frontend changes also add a Playwright screenshot verification step.
• Conclusion: The "measure twice, cut once" principle significantly reduces rework rates in programming agents; low-cost corrections during the planning phase are far better than high-cost fixes after execution.

A2 — Future Trigger ★

In what situations do users need this?

1. Building an AI programming assistant within an IDE (such as a VS Code extension)
2. Designing autonomous programming agents (such as a CI/CD bot that automatically fixes code based on Issues)
3. Developing command-line programming tools (such as an AI programming assistant in the terminal)
4. Implementing automated code review systems

Language Signals

• "AI programming assistant"
• "automatically modify code"
• "Git operation automation"
• "code review Agent"
• "need to safely edit files"

Distinction from Adjacent Skills

• Distinction from injection-defense : injection defense focuses on the trust boundary of external content, while programming agents focus on the safety of code execution operations (such as protection against destructive Git operations)
• Distinction from citation-system : code references point to files and line numbers rather than document paragraphs; references in programming agents are part of the operational context

E — Execution (Executable Steps)

1. Step 1: Establish a Git safety protocol - Completion criteria: List the Git operations that are prohibited from autonomous execution (force push, hard reset, direct push to the main branch, amending already-pushed commits), and define a user confirmation process and alternative safe approach for each.
2. Step 2: Design the plan→review→execute lifecycle - Completion criteria: Define the inputs and outputs of the three phases—the Plan phase outputs a list of files to change and a summary of modifications, the Review phase requires user confirmation, and the Execute phase executes according to the confirmed result; specify when Review can be skipped (such as low-risk changes like single-line modifications).
3. Step 3: Define context-aware editing rules - Completion criteria: Declare the principle of "must read the file before editing", prioritize diff edits (specifying old_string/new_string) over full rewrites, and specify concrete paths rather than glob wildcards when staging files.
4. Step 4: Add a verification loop mechanism - Completion criteria: Specify the verification steps after code modifications—run the relevant test suite, perform build checks, and use screenshot tools to confirm the visual effect of frontend changes; define the rollback strategy when verification fails (revert the modifications and report the error).
5. Step 5: Write an anti-AI-slop guide - Completion criteria: List prohibited typical AI code styles (excessive comments such as "// this is a variable", unnecessary interface abstractions, redundant type redefinitions, cookie-cutter error handling patterns), and provide comparisons between good and bad examples.

B — Boundary ★

Do not use in the following situations

• Pure code Q&A or teaching (no file modification operations, no need for a Git safety protocol)
• DevOps infrastructure configuration (Terraform, Kubernetes manifests, etc., which belong to the operations domain)
• Code analysis tools (read-only without modification, no need for editing safety protocols)
• CI/CD pipeline design (belongs to automated deployment, not code editing)

Common failure modes

• Excessive autonomy: The programming agent directly performs complex modifications without confirmation, causing deviation from user intent or breaking existing functionality; a confirmation step should be enforced for high-risk operations
• Preference for full rewrites: The model tends to rewrite the entire file rather than make local modifications, increasing the risk of introducing unexpected errors; diff-based editing should be preferred
• Ignoring working tree state: Performing operations in a dirty working tree leads to the loss of unsaved changes; checking the working tree state before operations should be required
• AI slop code: Generating "AI-style" code with excessive comments, unnecessary abstractions, and redundant types requires clear anti-pattern guidelines as constraints