AI-SDLC in Practice: Engineering Six Core Capabilities of Intelligent Programming

The hard part of intelligent programming is not getting a model to generate more code. The real challenge is making sure the model sees the right information at the right time, uses the right tools, and completes tasks within controlled boundaries.

An executable intelligent programming system can be divided into two parts:

• The model: understands, reasons, plans, and generates.
• The host: runs the conversation loop, calls tools, assembles context, compresses history, splits tasks, confirms permissions, connects to external systems, and isolates the execution environment.

The model decides how to think. The host decides what the model can see, what it can do, and when it can do it. Teams should therefore avoid rebuilding host capabilities that are already mature. They should focus on two things. First, they should understand the capability boundaries the host provides. Second, they should turn their own process standards, architecture knowledge, and quality requirements into engineering assets that the host can reliably read.

1. Understanding Context: The Core Resource of Intelligent Programming

The quality of an intelligent programming task depends heavily on what goes into the context in each round. System rules, project documentation, tool definitions, skill descriptions, conversation history, file contents, command output, and external knowledge all compete for limited context space.

When the context contains a lot of irrelevant material, several problems follow:

1. The model struggles to tell hard constraints from general background.
2. Early trial-and-error can distort current judgments.
3. Key architecture rules get buried under logs and long text.
4. The more complex the task, the more likely historical information is to become distorted.
5. The same rule repeats across stages, which raises maintenance costs.

For this reason, the basic principle of AI-SDLC is not to give the model every available document. Instead, it provides information dynamically, based on stage, directory, role, and task.

Context can be divided into four layers:

• Resident layer: project standards, directory constraints, and coding principles that apply in every round.
• On-demand layer: specialized knowledge for a particular module, language, or framework, loaded only when related code is accessed.
• Temporary layer: the requirements, plans, test results, and tool output for the current task.
• External layer: knowledge bases, tickets, build records, or monitoring data queried in real time through connectors.

Each layer should be managed separately. All content should not be written into one very long instruction file.

2. Six Capabilities and Their Boundaries

1. Project Instruction Files: Establishing Stable Long-Term Constraints

Project instruction files describe the repository structure, startup methods, test commands, code style, commit requirements, security restrictions, and change process. They are suited to rules that must be followed in almost every task.

Recommended content includes:

• Project directories and module responsibilities;
• Local development and verification methods;
• Required checks;
• Directories or generated files that must not be modified;
• Coding constraints for interfaces, logging, and exception handling;
• Change description and review requirements;
• How to handle uncertain information.

The following should not be included:

• Detailed background for a single requirement;
• Large blocks of interface documentation;
• Frequently changing release information;
• Complete business data;
• Dynamic content that can be retrieved with tools.

These files should be short, clear, and actionable. Rules work best when they use explicit terms such as “must,” “must not,” “prefer,” or “only when.” Vague phrases such as “try to follow the standard” or “optimize appropriately” cannot be verified and should be avoided.

For multi-module repositories, a layered structure works well. Global rules go in the root directory, and module rules go in subdirectories. When the model accesses a directory, it loads the matching local constraints. This keeps every task from carrying the full knowledge of the repository.

2. Skill Modules: Packaging Complex Workflows as Reusable Capabilities

A skill module is an operating guide for a specific task. It usually contains trigger conditions, required inputs, execution steps, output formats, and error handling. Examples include:

• Generating an interface change description;
• Analyzing database migration risks;
• Writing unit tests;
• Running security checks;
• Summarizing the impact of changes;
• Generating a release checklist.

A skill module should function as an executable workflow, not as a knowledge article. A good skill module answers at least five questions:

1. When should the skill be triggered?
2. What inputs does it need?
3. What is the order of execution?
4. Which results require user confirmation?
5. What format should the final output follow?

Skills should be loaded on demand. The skill list keeps only short descriptions, and detailed content enters the context only when the skill is triggered. This reduces the resident information and lowers the chance of conflicts between skills.

3. Subagents: Isolating Roles, Tasks, and Context

Subagents suit relatively independent work that can run in parallel or that needs a specialized perspective. Examples include:

• One agent that clarifies requirements;
• One agent that checks architectural impact;
• One agent that writes tests;
• One agent that performs security review;
• One agent that checks whether documentation matches the code.

The value of a subagent lies less in running several models and more in context isolation. The development agent’s trial-and-error record does not need to be passed in full to the review agent. The review agent only needs the change summary, related files, and review criteria.

When using subagents, define the following:

• The task goal;
• The scope of input;
• Content the agent must not access;
• The output format;
• Whether the agent may modify files;
• Who consolidates the results when the work is complete.

Tasks that should not be split should stay in a single context. For example, a refactoring task that depends on a continuous chain of decisions may produce duplicate changes and inconsistent designs if it is split across subagents that do not share background.

4. Hooks: Running Governance Actions Automatically at Fixed Points

A hook is a rule or script that runs automatically when a specific event occurs. Common trigger points include task start, before a file write, after a file write, before a command runs, after a command runs, and session end.

Hooks suit deterministic tasks that do not require model judgment:

• Automatic formatting;
• Checking sensitive files;
• Blocking dangerous commands;
• Recording audit information for changes;
• Running fast static checks after modifications;
• Refreshing local indexes automatically;
• Checking whether generated files were modified unintentionally.

Hooks should not carry complex business decisions. If an action requires understanding a large amount of context, comparing several options, or making trade-offs, it should go to the model or to a human for confirmation. Hooks also need failure policies. The team should define in advance which errors can show a warning and let the process continue, and which errors must stop the process.

5. External Connectors: Bringing Dynamic Knowledge into Tasks

External connectors provide access to information outside the host. This includes requirement systems, code search services, knowledge bases, build systems, defect records, log platforms, and monitoring systems.

They address two kinds of problems:

• Information that changes frequently and should not be written into project files;
• Information that is too large to keep in the resident context.

Connectors should follow the principles of least privilege and minimal return. The model does not need access to an entire system. It only needs the fields required to complete the current task. Returned results should also include the source, the timestamp, and the permission scope, so the model does not treat outdated information as current fact.

External data should separate facts from inferences. For example, a build system reporting that a check failed is a fact. Inferring the root cause from the failure log is an analysis. The output should present the two separately.

6. Permissions and Sandboxing: Setting Hard Boundaries Outside the Context

Permissions and sandboxing are not prompts, and they are not rules the model can decide for itself. They are mandatory constraints enforced at the host level.

Permission controls can cover:

• File reads and writes;
• Command execution;
• Network access;
• External system queries;
• Credential use;
• Deletion, release, and production operations.

Sandboxing limits the scope in which programs run, the resources they use, and the system access they have. During development, tests may be allowed to run in a temporary directory, but access to production credentials should be blocked. During verification, build results may be read but not published directly. During delivery, critical operations should require manual confirmation.

Security boundaries must not depend only on the model following the rules. Any action that could cause data leakage, irreversible changes, or environmental impact should be controlled by the host, the operating system, or an approval process.

3. How the Six Capabilities Apply Across Five Lifecycle Stages

Stage 1: Requirements Understanding

Project instruction files provide domain terminology, requirement formats, and business boundaries. External connectors query historical requirements, defect records, and existing interfaces. Subagents can separately extract business goals, identify ambiguities, and analyze the scope of impact.

The output of this stage should not be code. It should include:

• Requirement goals;
• Out-of-scope items;
• User scenarios;
• Acceptance criteria;
• Dependent modules;
• Open questions;
• Risks and assumptions.

Hooks can check whether a requirements document is missing acceptance criteria or an owner after it is generated. Permission controls make sure the model can only read information related to the current project.

Stage 2: Solution Design

Skill modules can guide the model to complete the architecture design using a standard template. The template covers the current state, candidate solutions, trade-offs, data changes, compatibility, failure recovery, and test strategy.

Subagents suit independent reviews. One can focus on performance, one on security, and one on maintainability. The main agent consolidates structured conclusions instead of concatenating each subagent’s full reasoning into the context.

This stage should keep human checkpoints. Designs that involve data structures, permission models, public interfaces, or infrastructure should not move into implementation just because the model produced a complete document.

Stage 3: Code Implementation

Project instruction files constrain directories and coding standards. Skill modules guide specific types of changes. Hooks run formatting and basic checks. The sandbox limits the commands and file access.

Use a small-step approach:

1. Locate the relevant files first.
2. State the scope of the planned change.
3. Complete one minimal set of changes.
4. Run targeted checks immediately.
5. Continue to the next set of changes based on the results.

This limits the scope of errors and makes review and rollback easier. For high-risk files, set read-only or manual-confirmation policies so the model cannot overwrite large amounts of content in one pass.

Stage 4: Verification and Review

Verification should run in an independent context wherever possible, so assumptions made during development do not influence the review conclusions. The review subagent receives only the requirement summary, the change content, the test results, and the review criteria.

Skill modules can split verification into several levels:

• Formatting and static checks;
• Unit tests;
• Module-level tests;
• Interface and integration tests;
• Security checks;
• Performance baseline checks;
• Documentation consistency checks.

Hooks suit automated deterministic checks. External connectors can query build records, historical failure cases, and defect status. The final report should distinguish between “verified,” “not verified,” “verification failed,” and “requires human judgment.” Vague statements such as “mostly passed” should not replace facts.

Stage 5: Delivery and Continuous Improvement

The focus of delivery is not generating more code. It is confirming that the changes are complete, traceable, and reversible. Project instruction files should specify commit messages, change records, and release checklist items. Skill modules can generate delivery checklists. External connectors can verify task status, build results, and document versions.

After delivery, the team should turn frequently occurring problems into new rules or skills. For example, if the same type of error keeps appearing, the project constraints are probably insufficient. If a check is often skipped, it should become an automatic hook. If a query always needs to be copied manually, the team can build a standard connector.

4. Working with Different Intelligent Programming Hosts

To avoid being locked into one specific product, split engineering assets into three layers:

The first layer is the general knowledge layer. It includes project rules, module descriptions, interface constraints, test standards, and security requirements, stored as plain text or structured documents.

The second layer is the capability description layer. It includes skills, roles, input and output protocols, and review templates. Each host can load them through its own directory or configuration mechanism, but the content stays the same.

The third layer is the host adaptation layer. It includes hook configurations, permission policies, sandbox settings, and external connector declarations. Different hosts can implement this layer differently, but all must follow the same behavioral goals.

The recommended directory structure is:

project/
├── instructions/       # Global and module-level rules
├── skills/              # Reusable task workflows
├── agents/              # Role and subtask definitions
├── hooks/               # Automated checks and governance actions
├── policies/            # Permission, approval, and security policies
├── docs/                # Architecture, interface, and decision records
└── scripts/             # Host-independent check scripts

Scripts and documents should stay independent of any specific host where possible. Adaptation files should only map the shared capabilities to each host’s configuration format. This reduces migration costs and keeps key processes from depending on the proprietary mechanisms of a single tool.

5. Governance Issues Most Often Overlooked During Rollout

First, more rules are not always better. Too many rules increase conflicts and maintenance costs. Teams should prioritize rules for security, quality, and architecture boundaries.

Second, more automation is not always better. Actions involving deletion, release, permission changes, and production data must keep a human confirmation step.

Third, subagents are not free parallel computing. Each subagent adds context, coordination, and consolidation costs. Split work only when the task boundaries are clear.

Fourth, external knowledge must be traceable. Information without a source and a timestamp should not serve as the basis for a key decision.

Fifth, monitor actual results continuously. Teams should track rule hit rates, reasons for automated check failures, the number of manual rollbacks, the proportion of ineffective context, and the types of defects found after delivery. Use this data to determine which capabilities actually deliver value.

Conclusion

Each of the six capabilities addresses a different problem. Project instruction files provide long-term constraints. Skill modules make workflows reusable. Subagents isolate roles. Hooks automate governance. External connectors supply dynamic information. Permissions and sandboxing enforce hard security boundaries.

Combined, these capabilities turn intelligent programming from one-off code generation into an engineering system with context management, process control, quality verification, and security governance. The priority is not to pile on more prompts. It is to keep improving how information is supplied: each stage should carry only the content it needs, each role should have clear responsibilities, and every high-risk action should stay within boundaries that are auditable, confirmable, and reversible.