How to improve our coding workflow with Copilot

-

        Better habits of Copilot usage help in two ways:

  • Higher quality code output
  • Reduced credit waste

The objective isn’t to limit our use of the tool. The goal is simply to be more precise.

Context becomes part of the cost

Under usage-based billing, context length directly impacts cost. Vague prompts often lead to repeated attempts, longer answers and more token usage. Effective prompting provides the AI with essential details immediately:

  • The specific logic to modify
  • All necessary source files
  • Mandatory architectural constraints
  • Code areas to remain untouched
  • Required testing and validation
  • The desired response format

Weak prompt example: “Fix this code”

Better prompt example: “Refactor the selected logic for clarity while maintaining the existing API. Do not modify the method signature. Provide unit tests covering edge cases like null inputs. Output the refactored code with a brief summary”

This approach is more professional. It significantly minimizes the need for repeated attempts.

Use custom instructions

One powerful way to standardize output is through repository-level instructions.

GitHub allows teams to define global standards in:

.github/copilot-instructions.md

This file helps Copilot understand project-specific patterns and validation requirements. Support for path-aware guidance is also available via .github/instructions using the .instructions.md naming convention.

For example, a data engineering team, rules might include:

# Team standards for GitHub Copilot

Standardize on Python 3.12.
Use static typing throughout.
Prioritize modular, testable components.
Ensure exceptions are handled explicitly.
Initialize cloud clients outside primary loops.
Document infrastructure impact before modifying resources.
Keep SQL readable with clear aliases.
Evaluate schema evolution and idempotency in pipelines.
Include failure modes in all tests.
Outline complex architectural plans before implementation.

These rules help align Copilot’s output with internal coding standards and reduce the time spent on manual corrections.

Path-level guidance

While global rules are helpful, complex projects often require localized logic.

GitHub supports directory-specific files such as:

.github/instructions/python.instructions.md

.github/instructions/terraform.instructions.md

.github/instructions/sql.instructions.md

Each configuration defines its own scope.

Example Python config:

---
applyTo: "**/*.py"
---

Use type hints.

Prefer pure functions for transformations.

Use pytest for tests.

Do not use broad except blocks unless the error is logged and re-raised.

For dataframes, avoid hidden schema changes.

When modifying ETL logic, add or update tests for nulls, duplicates and invalid formats.

Example infrastructure (Terraform) config:

---
applyTo: "**/*.tf"
---

Prefer small, reviewable Terraform changes.

Do not rename resources unless explicitly requested.

Explain any resource replacement risk.

Keep variables and outputs documented.

Avoid hardcoded account IDs, regions or secrets.

Before changing IAM policies, explain the permission scope.

This ensures Copilot adjusts its behavior based on the specific tech stack in use.

Configuring agentic workflows

For agentic workflows, repository instructions are not the only option. GitHub documents support for agent instruction files such as:

  • AGENTS.md
  • CLAUDE.md
  • GEMINI.md

Support depends on the Copilot surface being used. For example, GitHub documents support for repository-wide instructions, path-specific instructions and agent instructions across GitHub.com, VS Code, JetBrains, Copilot CLI and other environments.

A sample AGENTS.md might include

# Review data pipeline change

Review the selected changes as a senior data engineer.

Focus on:
- Data correctness
- Idempotency
- Schema evolution
- Partitioning
- Performance
- Error handling
- Observability
- Test coverage
- Backward compatibility

Return:
1. Main risks
2. Suggested fixes
3. Missing tests
4. Final approval recommendation

This is particularly effective for cloud agent and autonomous workflows.

Repeatable prompt files

Certain development activities are recurring:

  • Performing PR reviews
  • Creating test suites
  • Interpreting legacy modules
  • Drafting documentation
  • Analyzing CI failures

Instead of writing the same prompt every time, use reusable prompt files.

GitHub documents prompt files as reusable prompt examples for common development tasks, although they are still marked as public preview and availability depends on the IDE.

# Review data pipeline change

Review the selected changes as a senior data engineer.

Focus on:
- Data correctness
- Idempotency
- Schema evolution
- Partitioning
- Performance
- Error handling
- Observability
- Test coverage
- Backward compatibility

Return:
1. Main risks
2. Suggested fixes
3. Missing tests
4. Final approval recommendation

This improves consistency and reduces long, repeated manual prompts.

Specialized skill folders

We can create agent skills as bundles of resources that the AI can trigger for specific workflows. These are supported in VS Code and the CLI.

Storage locations include:

.github/skills
.claude/skills
.agents/skills

These are ideal for complex, process-driven tasks like:

  • Infrastructure safety audits
  • Optimization of SQL queries
  • API contract validation
  • Automated incident post-mortems

Example SKILL.md content:

---
name: data-pipeline-review
description: Review data pipeline changes for correctness, idempotency, schema evolution, tests and production risk.
---

Use this skill when reviewing ETL, ELT, Spark, Glue, Airflow, dbt, SQL or data lake changes.

Check:
- Input and output schema
- Null handling
- Duplicate handling
- Partition strategy
- Idempotency
- Retry behavior
- Backfill impact
- Performance risks
- Monitoring and logging
- Test coverage

Return:
1. Summary
2. Main risks
3. Required fixes
4. Suggested improvements
5. Validation checklist

This turns Copilot from a generic assistant into a more consistent engineering teammate.

Concise communication

Token waste often stems from excessive verbosity. For technical tasks, we rarely need conversational filler.

Prioritize:

  • The actual implementation
  • Core reasoning
  • Risk assessment

Adopting a compressed style can drastically reduce token counts.

Example guidelines:

Be direct. Maintain accuracy. Eliminate filler. Only explain basics if requested. Focus on code changes and risks.

This is similar to a “caveman-style” prompting approach: short, direct and focused on technical signal instead of unnecessary wording

Comments

Post a Comment

Popular posts from this blog

Disaster Recovery of Azure API Management (APIM)

-
Image
Disaster Recovery of Azure API Management (APIM)     In this post, we will try to understand how we can apply a disaster recovery approach for Azure API Management aka. APIM. So, first of all, we will have to understand the importance of it. It's very important for an application using APIM to have a strong disaster recovery approach, as in case of any issue because of disaster reported, the system using the APIs underneath should be accessible for the users/ systems, and since the APIM is used as the fore front of the applications (mostly)  it's  important to restore the APIM service ASAP in case of any disaster reported, so that the application consuming the APIs underneath it  is  not having issue connecting to the APIs.       There are 2 broader options which one can think of:   Have a stand-by service in one or more regions   Service back-up and restore features    Let's  talk about both the approaches (one at a ...
Read more

API Aggregation Using Azure API Management

-
  API Aggregation Using Azure API Management         There are cases where we need to call multiple APIs from the client at the same time in order to proceed further with the processing from the client application. Now as oppose to calling those APIs individually  i.e.,  making separate HTTP requests for all those multiple APIs what if we can make one HTTP request and get all the responses aggregated in one response as opposed to multiple response isn't it going to be super cool.       So,  in this post we will try to understand how we can aggregate/ merge multiple API responses from the backend and provide one single request and response from the Azure API Management (APIM) to the calling client application.       To do this first of all we need to understand our APIs request body which we want to merge using APIM, so let say we want to call 2 APIs and  their   URI  are like this.       ...
Read more

API Response Compression in .Net Core

-
Image
API Response Compression in .Net Core If you are here, I am sure you must have used (consumed/ produced) APIs and indeed its been the case in modern web/ mobile application where APIs are used very frequently.  Data transfer size in case of APIs is a very big concern as the volume of data which can be transferred via APIs are not really meant to have huge data as because of following reasons: Data transfer time over network can be a big constraint if the size of data is huge APIs response time are expected to be fast and quick and if the volume of the data is huge obviously the response time of the API will be impacted as well, and no client application consuming the APIs will expect the response time of an API to be beyond a few seconds (at max). So how do we really solve this problem. Well we all understand that API is not really meant to perform huge data transfers but just in case we still have to do how to do it effectively. And there comes API compression frameworks at our re...
Read more