QAing · Developing Features with GitHub Copilot

GitHub Copilot can assist feature development at several levels: inline code completion, next edit suggestions, focused inline chat and broader Ask, Plan and Agent workflows. The fastest workflow is not always the most autonomous one. Good results come from choosing the smallest tool that fits the task, providing strong context, reviewing every change and verifying behaviour with builds and tests before merging.

On this practical guide

Completions Next edits Chat Ask/Plan/Agent Prompting Feature workflow Review Checklist

Choose the smallest Copilot tool that solves the problem

Need	Best starting point
Complete the line/function you are already writing	Ghost text completion.
Propagate a rename or related edit	Next Edit Suggestions.
Change one selected block	Inline Chat.
Ask how a feature should work	Ask mode.
Design a multi-file change first	Plan mode.
Implement a well-scoped multi-file task	Agent mode.

Ghost text completions

Ghost text uses the surrounding code and open-file context to predict the next implementation. It works well for variable names, repetitive mappings, small helper methods, boilerplate and tests that already follow a visible pattern.

// Return active users whose last login is within the supplied number of days
public IEnumerable<User> GetRecentlyActiveUsers(int days)

A specific comment gives the model more intent than a vague stub.

Next Edit Suggestions

Next Edit Suggestions (NES) are designed for modifying existing code rather than only adding the next line. Copilot can predict where a related change is likely needed after the edit you just made.

Rename propagation.
Method signature changes.
Data type changes.
Related condition updates.
Adapting copied code to surrounding patterns.

Review every follow-up edit. A likely next change is not necessarily the correct change for the requirement.

Provide context before asking for code

Meaningful function and class names.
Related files open in the editor.
Correct imports and dependencies already present.
Existing tests showing expected behaviour.
Project-specific examples.
Top-level comments where a file's purpose is not obvious.

Low-quality code also becomes context, so Copilot may reproduce weak patterns. Keep the codebase quality bar high.

Prompting best practices

Start with the goal, then constraints

Goal:
Add a method that determines whether an account can be renewed.

Requirements:
- return false if suspended
- return false if expired more than 90 days ago
- return true otherwise
- do not modify account state
- follow existing AccountService patterns
- add unit tests for boundaries

Give examples

Input:
status=Active, expiry=tomorrow
Expected: true

Input:
status=Suspended, expiry=tomorrow
Expected: false

Break complex work down

Separate architecture, implementation, tests and documentation when the task is substantial instead of asking one vague prompt to generate everything.

Use Ask mode to explore before editing

Which files currently implement this behaviour?
What existing pattern should the new feature follow?
What edge cases already exist?
Will this change require schema or API updates?
Which tests should change?
What backwards-compatibility risks exist?

Use Plan mode for cross-file work

Plan a "book availability" feature.

Requirements:
- add a new user action
- search by title
- report whether an active loan exists
- preserve existing patron flow
- update dependency injection only if needed
- add tests
- list every file to modify
- include verification steps

Do not edit files yet.

A useful plan should contain

Files and components affected.
Data flow.
New interfaces or dependencies.
Error and empty-state behaviour.
Tests.
Build/run verification.
Open questions.

Use Agent mode for implementation

Implement the approved book-availability plan.

Constraints:
- follow existing repository and DI patterns
- search titles case-insensitively
- treat an active loan as ReturnDate == null
- preserve current console navigation
- add tests
- build the solution after edits
- do not change unrelated behaviour

Stop if an assumption cannot be confirmed from #codebase.

Review each changed file and the final diff before accepting.

Inline Chat for focused edits

Update the selected switch expression to support
CommonActions.SearchBooks using input "b".

Do not change the behaviour of existing options.

Selected code is high-quality context and helps keep the edit narrow.

A practical feature-development workflow

User story
   ↓
Ask: understand current behaviour
   ↓
Plan: define multi-file change
   ↓
Create feature branch
   ↓
Implement small edits
   ↓
Build
   ↓
Run tests
   ↓
Manual/exploratory verification
   ↓
Review diff
   ↓
Commit + PR summary
   ↓
Human review
   ↓
Merge

Branch before autonomous changes

Start from a clean working tree.
Create a dedicated feature branch.
Commit logical checkpoints.
Inspect diffs after each significant agent task.
Use editor checkpoints or Git to revert unwanted changes.
Do not mix unrelated cleanup with feature work.

Restoring angle brackets from the source material

The supplied training text used placeholder strings for characters such as < and >. In this article they are restored semantically and HTML-escaped where needed so the rendered page shows the intended code.

C# switch expression

action = userInput switch
{
    "q" when options.HasFlag(CommonActions.Quit) => CommonActions.Quit,
    "b" when options.HasFlag(CommonActions.SearchBooks) => CommonActions.SearchBooks,
    _ when int.TryParse(userInput, out optionNumber) => CommonActions.Select,
    _ => CommonActions.Repeat
};

Generic dependency registration

services.AddSingleton<JsonData>();
services.AddSingleton<ConsoleApp>();

Dependency injection changes deserve extra review

Does the class genuinely own this dependency?
Is there already a service abstraction that should be used instead?
Does adding the dependency make unit testing harder?
Does the lifetime remain correct?
Could this create hidden coupling?

Do not accept generated comments automatically

Remove placeholder comments.
Delete comments that merely describe obvious code.
Keep comments that explain business intent or constraints.
Update comments immediately if implementation changes.

Build and test after AI edits

dotnet build
dotnet test

Compilation is only the first gate. Also verify happy paths, not-found behaviour, invalid input, boundaries, permissions, state persistence and nearby regressions.

Manual exploratory testing still matters

Search for a known available item.
Search for a known unavailable item.
Use different title casing.
Search for a missing title.
Try empty input.
Repeat searches within the same session.
Verify existing navigation still works.

Generated code and passing unit tests do not replace observing the actual feature.

Use Copilot in the PR workflow

Generate a commit message from the diff.
Draft a pull-request summary.
Explain architectural impact.
List tests performed.
Suggest reviewer focus areas.

Summarise this diff for reviewers.

Include:
- user-visible behaviour
- files changed
- architecture/dependency changes
- tests added
- manual verification
- risks or follow-up work

Do not claim tests were run unless the repository context proves it.

Common AI feature-development mistakes

Mistake	Better approach
One giant vague prompt	Ask → Plan → implement in controlled steps.
Accept every edit at once	Review per file and logical change.
No branch/checkpoint	Use Git and editor checkpoints.
Code compiles, therefore done	Run tests and exploratory verification.
New dependency added casually	Review architectural ownership and lifetime.
Tests mirror implementation	Derive expectations from requirements.
Stale chat context	Start a new conversation when scope changes.

QA engineer checklist

Understand existing behaviour before generating changes.
Use a feature branch.
Give Copilot acceptance criteria, not only a feature name.
Use Ask for uncertainty, Plan for cross-file scope and Agent for implementation.
Keep autonomous edits narrowly scoped.
Review every dependency and configuration change.
Build after structural edits.
Run relevant automated tests.
Add independent negative and boundary tests.
Perform exploratory verification of the actual feature.
Inspect the complete diff before commit.
Use Copilot to draft PR communication, then verify every claim.