AI Coding Workflow Templates: Plan, Review, Test, and Document Software with LLMs

Overview

A reliable AI coding workflow starts with context and ends with verification. Give the model a specific task, the relevant repository information, the constraints it must respect, and a clear output format. Then treat the response as a draft or proposal until a developer checks it against the codebase, tests, security requirements, and product intent.

This approach works across coding assistants and model families because it focuses on transferable prompt engineering practices rather than a particular interface. The available context features may differ: one tool may index a repository, another may accept selected files, and another may work primarily through an API or terminal. The underlying discipline remains the same.

A useful baseline prompt has five parts:

1. Role and task: State what the assistant should help accomplish.
2. Context: Provide the ticket, relevant files, language, framework, interfaces, and constraints.
3. Acceptance criteria: Describe what a correct result must do.
4. Boundaries: Identify files, APIs, dependencies, or behaviors that must not change.
5. Output format: Request a plan, patch, test cases, review findings, or documentation in a defined structure.

Do not paste secrets, private credentials, customer data, or proprietary material into an AI development tool unless your organization has approved that use and the tool configuration supports it. Repository access should follow the same least-privilege principle used for other developer tools.

Checklist by scenario

Use the templates below as starting points. Replace bracketed text with project-specific details, and ask the assistant to identify uncertainty instead of filling gaps with guesses.

1. Clarify a ticket

Act as a software engineer helping clarify this ticket: [paste ticket].

Context:
- Product area: [area]
- Users affected: [users]
- Relevant existing behavior: [behavior]
- Known constraints: [constraints]

Return:
1. A concise restatement of the problem
2. Missing information and questions for the product owner
3. Testable acceptance criteria
4. Edge cases to discuss
5. Assumptions, clearly labeled

Human check: Confirm that the acceptance criteria reflect product intent and do not silently expand scope.

2. Explore a repository

Analyze the supplied repository context without proposing changes yet.

Goal: [feature or bug]
Relevant paths: [paths, if known]

Explain:
- Where the current behavior is implemented
- The main data flow and control flow
- Related interfaces, configuration, and tests
- Likely extension points
- Files that should not be changed without further review

Cite file paths and symbols. Mark any conclusion that is uncertain.

Human check: Open the cited files and verify that the assistant has not inferred behavior from filenames alone.

3. Plan implementation

Create an implementation plan for [task] in [language/framework].

Constraints:
- Preserve: [existing behavior]
- Avoid: [dependencies, API changes, migrations]
- Required tests: [test expectations]
- Compatibility concerns: [versions or clients]

Return:
1. Proposed approach
2. Ordered file-level changes
3. Data, API, or schema implications
4. Test plan
5. Rollback or failure considerations
6. Open questions

Human check: Compare the plan with repository conventions and architectural decisions before asking for code.

4. Generate tests

Write tests for [function, module, or endpoint] using the existing test framework.

Behavior to cover:
- Happy path: [case]
- Boundary cases: [cases]
- Invalid input: [cases]
- Failure or timeout behavior: [cases]
- Authorization or permission behavior: [cases]

Use existing fixtures and naming conventions. Do not weaken assertions to make tests pass. After the test code, list behaviors that remain untested.

Human check: Verify that tests assert outcomes rather than implementation details and that they fail for a real regression.

5. Review code

Review the following change as a careful code reviewer: [diff or files].

Prioritize:
- Incorrect behavior and missed edge cases
- Security and authorization risks
- Data validation and error handling
- Concurrency, performance, and resource use
- Backward compatibility
- Missing or misleading tests

For each finding, provide severity, file and symbol, explanation, and a concrete recommendation. If no issue is found, list areas that were not verifiable from the supplied context.

Human check: Reproduce important findings locally. An AI review is an additional perspective, not approval.

6. Debug a failure

Help investigate this failure without assuming the cause.

Observed behavior: [description]
Expected behavior: [description]
Error or logs: [sanitized logs]
Recent changes: [changes]
Environment: [relevant runtime details]

Return:
1. Ranked hypotheses with evidence
2. The smallest diagnostic steps for each hypothesis
3. A likely fix only after the diagnosis
4. A regression test
5. Information still needed

Human check: Sanitize logs, reproduce the issue, and distinguish correlation from demonstrated cause.

7. Refactor safely

Propose a low-risk refactor of [component] to address [problem].

Preserve:
- Public interfaces
- Observable behavior
- Performance expectations
- Error semantics

First identify duplication or complexity. Then provide incremental steps, tests to run after each step, and any behavior that could change accidentally. Do not combine unrelated cleanup.

Human check: Keep the change reviewable and confirm that the refactor has a measurable reason, such as clearer ownership or safer maintenance.

8. Write release notes and documentation

Using the supplied merged changes and issue summaries, draft release notes for [audience].

Include:
- What changed
- Who is affected
- Required migration or configuration steps
- Compatibility or deprecation notes
- Links or follow-up actions

Do not claim an improvement unless it is supported by the supplied material. Mark uncertain details for verification.

Human check: Compare every operational instruction with the actual release, configuration, and migration behavior.

What to double-check

Before accepting AI-generated code, run the normal quality gates: formatting, linting, type checks, unit tests, integration tests, and security scanning where applicable. Review the diff rather than only the assistant’s explanation. Confirm imports, error paths, logging, permissions, transaction boundaries, and handling of empty, malformed, duplicated, or unexpectedly large input.

For structured responses, request a defined schema and validate it in code instead of trusting a visually correct answer. For tool-using workflows, restrict available actions, validate arguments, and require confirmation before irreversible operations. Treat repository files, issue descriptions, comments, and retrieved documents as potentially untrusted content; they can contain instructions that conflict with the task.

Keep a small prompt-testing set for recurring workflows. Include representative tickets, difficult edge cases, security-sensitive examples, and cases where the correct answer is to ask for more information. Compare outputs across model or tool changes using the same rubric: correctness, completeness, format compliance, unnecessary changes, and review effort.

Common mistakes

• Asking for “better code” without a target: Define the behavior, constraints, and success criteria.
• Providing too much unfiltered context: Select the relevant files and explain their relationships.
• Accepting a large first patch: Request a plan, then implement in small, testable increments.
• Using generated tests as proof: Check whether the tests can detect the failure they claim to cover.
• Ignoring uncertainty: Require assumptions, missing context, and confidence limits to be labeled.
• Sharing sensitive material: Remove secrets and personal or customer data before using an assistant.
• Letting the tool approve its own work: Keep human review and independent automated checks in the workflow.
• Freezing prompts forever: Prompts are part of the workflow and need maintenance when repositories, models, or standards change.

When to revisit

Review these AI coding workflow templates before a new project, when onboarding teammates, when changing coding assistants or model families, and when adopting a new language, framework, repository structure, or deployment process. Revisit them before seasonal planning cycles if engineering standards or delivery goals have changed.

Teams should also update prompts after a recurring failure: missed security checks, weak tests, inaccurate release notes, excessive diffs, or repeated requests for clarification. Record a representative example, revise the template or context instructions, and add the case to the team’s prompt-testing set. A quarterly review is a practical baseline, with an additional review after a significant tool, model, repository, or policy change.

Use this adoption checklist in your next team session:

1. Choose one low-risk workflow, such as ticket clarification or documentation.
2. Define its input, output, reviewer, and automated checks.
3. Store the approved prompt beside the relevant engineering guidance.
4. Test it on normal cases and known failure cases.
5. Set rules for secrets, private code, repository access, and tool actions.
6. Measure review effort and defects informally before expanding usage.
7. Assign an owner and a date for the next template review.

The objective is not to add AI to every step. It is to make useful steps more consistent while preserving the controls that make software dependable.