From Code Generation to Delivery: Six Capabilities for End-to-End AI-Assisted Software Engineering

1. From “The Model Can Write Code” to “The Process Can Deliver”

Early applications of AI-assisted programming often started with a natural-language request and ended with a code change. Real software development is much broader. Requirements may be ambiguous, repositories contain historical constraints, test environments have access boundaries, and release operations may require approval and rollback plans.

When these conditions are not organized, even a capable reasoning model can produce predictable problems:

• It completes a local implementation but breaks existing module boundaries.
• It explains the requirement but misses exception paths and acceptance criteria.
• It fixes a test by weakening assertions and conceals the underlying defect.
• It calls external tools while accessing sensitive information that it does not need.
• It produces delivery notes without verifiable evidence of what was actually executed.

An AI coding system should therefore be understood as an engineering system jointly composed of a model and a runtime framework. The model handles understanding, planning, and reasoning. The runtime framework organizes sessions, invokes tools, selects context, schedules sub-tasks, manages permissions, and records execution.

Teams do not necessarily need to rebuild every foundational capability. They first need to determine what the existing runtime framework can already provide, then add the organization-specific processes, standards, and knowledge that are missing.

This article groups the relevant capabilities into six categories. The categories are intended as a general framework for analysis and design. They do not imply that every AI coding environment provides the same interfaces or behavior.

2. First Principle: Context Is a Limited Resource

The information a model can directly use for each task is constrained by its context capacity. System instructions, project rules, tool descriptions, conversation history, retrieved material, and execution logs often compete for the same space.

The goal is not to provide as much information as possible. The real question is whether the information required for the current decision is complete, accurate, and sufficiently up to date.

For example, requirements analysis needs business terminology and acceptance criteria, but not necessarily the complete build log. Code review needs the change set and design constraints, but does not need every failed experiment from development. Large amounts of low-value information increase processing cost and may obscure important constraints.

Context can be divided into four layers:

1. Stable rules: Project constraints and security requirements that remain valid over a relatively long period.
2. Task state: The current objective, confirmed decisions, and unresolved questions.
3. Phase materials: Requirements, design documents, code changes, and test results.
4. Temporary evidence: Error logs, retrieval excerpts, and one-time tool output.

A practical design principle is to keep stable rules concise, maintain task state explicitly, load phase materials when needed, and summarize or remove temporary evidence from the main session when it is no longer useful.

The exact mechanisms for context compression, directory-rule loading, and rule retention depend on the runtime framework. A particular file should not be assumed to remain permanently active, and a constraint that once appeared in conversation history should not be treated as a reliable execution guarantee.

3. Responsibilities and Boundaries of the Six Capabilities

3.1 Project Rules: Define the Long-Term Collaboration Contract

Project rules answer the question: “What practices are allowed and recommended in this repository?”

Suitable content includes:

• Module responsibilities and dependency direction.
• General coding conventions and error-handling requirements.
• Test categories and baseline verification methods.
• Generated directories that must not be edited directly.
• Approval requirements for data changes.
• Evidence that must be provided before a task is considered complete.

Rules should be short, specific, and verifiable. “Pay attention to code quality” is difficult to execute. “When modifying a public interface, check its callers and add compatibility tests” is much easier to convert into concrete action.

Project rules should not contain an entire architecture manual, historical meeting records, or every exceptional case. A better approach is to define knowledge entry points, applicable scope, and the time at which detailed material should be consulted. Tasks can then load the relevant information as needed.

Conflicts between rules should also be avoided. Teams may distinguish organization-level, project-level, module-level, and task-level constraints and define how conflicts are resolved. However, whether the host environment automatically supports these levels must be verified in practice. If it does not, the context assembly process must implement them explicitly.

3.2 On-Demand Skills: Package Repeatable Methods

An on-demand skill is task-oriented process knowledge, not a generic role prompt.

A useful skill description usually includes:

• Applicable and non-applicable scenarios.
• Inputs required before execution.
• A recommended sequence of actions.
• Risks that must be checked.
• The expected output structure.
• Conditions for stopping or escalating when execution fails.

For example, a “data-structure change assessment” skill might require the agent to inspect read and write paths first, analyze compatibility next, and then prepare migration, validation, and rollback plans. Its value comes from turning team experience into reusable steps, not from adding more text to a prompt.

Skills also need controlled loading granularity. During discovery, the system can provide only the skill name, purpose, and trigger conditions. When the skill is actually used, it can load the full procedure and related materials. This reduces the amount of irrelevant content occupying context.

A skill is guidance for performing work; it is not a permission grant. A skill that describes a release process does not mean that the execution agent should receive production deployment privileges.

3.3 Sub-Task Agents: Isolate Context and Assign Responsibility

Sub-task agents are suitable for independent work with a clear objective, defined boundaries, and verifiable results. Examples include dependency analysis, test expansion, change review, and documentation verification.

Their main benefit is not that “more agents are always faster.” It is that different tasks can be completed in relatively independent information environments, reducing interference within long sessions.

A delegated task should specify at least:

• The task objective.
• The materials that may be accessed and the operations that are allowed.
• The areas that must not be modified.
• The required output format.
• The acceptance criteria.
• The reason for any blocker if the task cannot be completed.

For example, an independent review agent may receive the requirements, design constraints, change diff, and necessary surrounding code, without receiving the developer’s entire explanation. This can reduce anchoring, although it does not guarantee that the review will be correct.

Isolation is not the same as a security sandbox. If multiple agents share a working directory, credentials, or tool permissions, they may still affect one another. For concurrent writes, use separate workspaces, explicit file ownership, or serialized merge procedures to prevent changes from being overwritten.

3.4 Event Hooks: Run Deterministic Checks at Critical Points

Event hooks execute scripts, validations, or information-collection steps when predefined events occur. They are useful for checks that should not depend entirely on the model remembering to follow a rule.

Common uses include:

• Checking whether a path belongs to a protected area before modification.
• Running formatting or static checks after a file is written.
• Confirming that required validation has been completed before a task ends.
• Verifying parameters against policy before an external operation.
• Recording important operations and their results.

Hooks should be stable, fast, and easy to interpret. A hook that frequently times out or produces excessive logs can slow down the entire workflow.

It is also important to distinguish between notification hooks and blocking checks. A notification hook can only issue a reminder. A blocking check may prevent the next operation. Whether blocking is supported, and which paths can be intercepted, depends on the implementation and must be confirmed through testing.

Mandatory security requirements should not exist only in prompt text. They should also not rely solely on hooks that may be bypassed. Permissions and the execution environment must enforce them together.

3.5 External Connections: Retrieve Facts and Invoke Tools as Needed

External connections link the AI coding workflow to knowledge bases, code indexes, requirement systems, logging services, and other information sources.

Their purpose is to answer “Where is the information, how can it be retrieved, and can it be trusted?” They are not simply a reason to expose more interfaces to the model.

External capabilities should generally be divided into two categories:

• Read-only queries: Retrieving documentation, searching code, and viewing status.
• Side-effecting operations: Submitting changes, creating resources, sending notifications, and triggering releases.

These categories should use different authorization strategies. Query results should include their source, version, update time, and applicable scope whenever possible. This helps prevent an outdated rule from being applied to a newer system.

External content should also be treated as data that requires verification. Text in documentation, logs, or issue descriptions should not automatically be allowed to modify system rules, expand permissions, or request credential disclosure. Executable operations still require independent validation of parameters and authorization.

3.6 Permissions and Sandboxes: Constrain Real Execution Capability

Permissions determine what an agent is allowed to do. Sandboxes determine where operations occur and what they can affect.

Common control dimensions include:

• The read and write scope of the file system.
• Permitted network targets.
• Executable programs and their arguments.
• Available credentials and their validity periods.
• Resource consumption and execution time.
• Access to shared or production environments.

Context isolation, role descriptions, and security reminders cannot replace these controls.

A safer default is to begin with read-only access and open only the minimum necessary permissions for each stage. Code changes should be made in an isolated workspace, validation should run in a controlled environment, and high-risk operations should require explicit approval.

A sandbox is not an absolute security guarantee. Its effectiveness depends on the isolation mechanism, configuration, credential-injection method, and authorization of external systems. These controls must be validated regularly rather than confirmed only by checking whether a particular switch is enabled.

4. Embedding the Six Capabilities in Five Development Stages

Stage 1: Requirements Understanding

The objective of this stage is to convert natural-language requirements into verifiable constraints.

Project rules provide business terminology and compliance boundaries. A requirements-analysis skill guides the team in identifying roles, boundary conditions, exception scenarios, and non-functional requirements. External connections help retrieve existing designs and historical issues.

The recommended outputs are three sets of material:

1. Confirmed requirements and acceptance criteria.
2. Unresolved questions and their potential impact.
3. Scope explicitly excluded from the current task.

Unresolved questions must be marked explicitly. An agent must not silently turn assumptions into facts. In principle, this stage does not require code-write permissions.

Stage 2: Solution Design

The design stage focuses on module boundaries, interface contracts, data changes, and risk controls.

The primary agent can organize the solution, while independent sub-tasks check compatibility, data consistency, and security impact. When several alternatives exist, the design should explain the selection criteria, constraints, and reasons for rejecting the other options.

At minimum, the phase artifacts should include the impact scope, key interfaces, validation strategy, and any required migration and rollback plans. Once approved, these conclusions should become explicit inputs to the next stage rather than information the model is expected to remember from a long discussion.

Stage 3: Coding and Implementation

During development, load the rules and implementation skills relevant to the current directories instead of reading the entire repository in advance.

Work should be divided into small steps that can be independently verified:

1. Understand the existing behavior.
2. Add or adjust tests.
3. Implement the change.
4. Run focused validation.
5. Inspect the resulting diff.

Event hooks can perform formatting checks and warn about sensitive files. Sandboxes can restrict file writes and external access. Operations such as deleting large numbers of files, changing permission configurations, or modifying dependency sources should require additional confirmation.

Stage 4: Validation and Review

Validation should answer more than “Did the command succeed?” It must also answer “Does the implementation satisfy the requirement?”

An independent review should cover:

• Whether the functionality meets the acceptance criteria.
• Whether error handling and boundary inputs are appropriate.
• Whether compatibility or security is affected.
• Whether tests verify real behavior.
• Whether unexplained configuration or data changes exist.

Reports should distinguish among executed, not executed, and failed checks. A test that was not run must not be reported as passing. If an issue cannot be reproduced, the available evidence and remaining uncertainty should be preserved.

Stage 5: Delivery and Operations Readiness

The delivery stage organizes change notes, configuration adjustments, monitoring points, and rollback conditions.

Production operations should be separated from code-generation permissions. Even if an agent can prepare release materials, it does not follow that the agent should decide the release time or handle approval on its own.

After the stage is complete, lessons learned should be converted into reusable assets:

• Stable constraints should become project rules.
• Repeated procedures should become skills.
• Deterministic checks should become hooks.
• Authoritative materials should be stored in the knowledge base.

Do not copy the entire process history back into permanent context.

5. Adapting the Same Engineering Approach to Different Runtime Environments

The key to cross-environment reuse is to standardize semantics rather than force every configuration file to be identical.

A three-layer structure is practical:

• Specification layer: Platform-independent rules, skill descriptions, and phase-artifact definitions.
• Adapter layer: Runtime-specific rule entry points, event bindings, tool descriptions, and permission configuration.
• Validation layer: Tests that confirm the adapted behavior matches expectations.

The following directory structure is illustrative and does not represent a fixed convention for any runtime environment:

Engineering Collaboration Standards/
  Project Constraints/
  Task Methods/
  Phase Artifact Templates/
  Permission Policies/
  Environment Adapters/
  Behavioral Validation Cases/

During migration, verify in particular:

• When rules are loaded.
• Which rules remain effective after the working directory changes.
• Which information is retained after context compression.
• Whether sub-tasks share files and permissions.
• Whether hooks can actually block operations.
• Whether authorization settings cover every execution entry point.

When a capability is unavailable, define an explicit fallback. If local rules cannot be loaded automatically, assemble them explicitly during task startup. If reliable write interception is unavailable, compensate with file permissions and isolated workspaces. A reminder such as “do not do this” is not a substitute for technical isolation.

6. Measure Outcomes with Evidence, Not Generation Speed Alone

The optimization target for AI-assisted development should not be producing more code faster. It should be reducing uncertainty across the entire delivery cycle.

Teams can continuously monitor:

• Coverage of acceptance criteria.
• Issues discovered during review and their severity.
• Post-release defects and rework.
• Tool-call failures and reasons for human intervention.
• Blocked unauthorized operations.
• The proportion of irrelevant material in context.
• The time and resources consumed by each accepted task.

These metrics should be analyzed together with task complexity and risk level. Simple comparisons of absolute duration across different tasks can be misleading.

A reliable AI coding workflow should ultimately form a clear loop:

• Project rules define boundaries.
• On-demand skills provide methods.
• Sub-task agents isolate responsibilities.
• Event hooks perform checks.
• External connections supply facts.
• Permissions and sandboxes limit the scope of impact.

Only when these six capabilities perform their respective roles can one-off code generation become a verifiable, traceable, and continuously improvable software engineering practice.