The AI-Assisted Delivery Protocol

AI-assisted engineering needs an operating protocol. Without one, teams get inconsistent quality: one developer uses AI carefully, another pastes generated code into production, another avoids AI entirely, and managers cannot tell whether the tool is improving outcomes or increasing risk.

The AI-Assisted Delivery Protocol has five stages.

Stage one: define the job

Before prompting, define what AI is being asked to do. Is it exploring options, generating code, creating tests, summarizing logs, drafting documentation, refactoring, reviewing, or explaining unfamiliar code? Different jobs require different standards.

Exploration can be loose. Production code cannot. Documentation can start rough. Security-sensitive changes require strict review. A builder names the job before using the tool.

Stage two: provide context

AI output is only as useful as the context it receives. For meaningful work, include:

• Product goal.
• User role.
• Existing system notes.
• Relevant files or interfaces.
• Constraints.
• Security rules.
• Testing expectations.
• Rollout plan.

This does not need to be perfect. It needs to be enough to prevent the model from guessing the wrong world.

Stage three: generate alternatives

Do not ask for one answer too early. Ask for two or three approaches with trade-offs. For example:

"Give me three implementation options: fastest safe path, most maintainable path, and lowest migration-risk path. Explain what each optimizes and what each risks."

This turns AI into an option generator rather than an authority.

Stage four: verify

Verification is where engineering ownership lives. Review:

• Correctness.
• Product fit.
• Security and authorization.
• Data handling.
• Error states.
• Edge cases.
• Test coverage.
• Observability.
• Performance.
• Rollback.
• Maintainability.

If the author cannot explain the generated code, the code is not ready. "AI wrote it" is not a defense. The human who ships it owns it.

Stage five: evaluate the workflow

After the work ships, ask whether AI helped:

• Did it reduce lead time?
• Did it improve test coverage?
• Did it reveal risks earlier?
• Did review take longer because output was messy?
• Did defects increase or decrease?
• Did documentation improve?
• Did the team learn a reusable prompt, context pack, or checklist?

This is how AI becomes a team capability instead of individual experimentation.

Matching discipline to risk

The protocol should be stricter for high-risk areas:

• Payments.
• Authentication.
• Authorization.
• Data migrations.
• Customer data.
• Compliance logic.
• Infrastructure changes.
• Production incident response.
• AI features that produce user-facing decisions.

For these areas, require smaller changes, stronger tests, explicit reviewer ownership, and rollback planning.

The protocol should be lighter for low-risk areas:

• Drafting documentation.
• Creating test data.
• Explaining code.
• Formatting.
• Building internal prototypes.
• Generating examples.

The point is not to slow everything down. The point is to match discipline to risk.

A shared context library, and metrics that matter

Teams should also maintain a shared AI context library. This can include coding standards, architecture notes, product terminology, common prompts, security rules, review checklists, and examples of good AI-assisted pull requests. The library should live close to the code or team documentation. If it is not easy to use, it will be ignored.

Managers should avoid measuring AI success by number of prompts, number of generated lines, or tool adoption percentage. Those are vanity metrics. Measure flow, quality, learning, and business impact.

Useful AI metrics include:

• Cycle time for selected work types.
• Defect rate after AI-assisted changes.
• Review time.
• Test coverage quality.
• Documentation freshness.
• Developer onboarding time.
• Incident recurrence.

AI should make the team smarter over time. If it only makes the team produce more unreviewed code, it is not leverage. It is risk with a modern interface.

The builder rule is simple: AI may accelerate the work, but it does not absorb responsibility.

Key takeaways

• Name the job before prompting: exploration, production code, and security-sensitive work each need a different standard.
• Ask AI for two or three options with trade-offs before accepting a single answer as authoritative.
• Verification is where ownership lives: if the author can't explain the generated code, it isn't ready to ship.
• Match protocol strictness to risk: stricter for payments, auth, and migrations; lighter for documentation and prototypes.
• Measure AI's effect on cycle time, defect rate, and review time, not on prompt counts or lines generated.