How Far Can You Go with Backend Vibe Coding? Improving Accuracy with Minimal Setup and GitHub Copilot

This article summarizes the results of three events where we investigated how to make back-end "Vibe Coding" more comfortable and universal, regardless of the infrastructure vendor being used.
Although I use Azure as an example, I believe it will be useful for other platforms as well. If you are short on time, please jump to the summary at the end.

First Round

At an event called AI Coding Mastery Meetup - VS Code Meetup × GitHub dockyard - connpass, we held a session to build a survey form using live Vibe Coding.
In this event, we were divided into a back-end team (which I was part of) and a front-end team, and challenged to complete the following Web app in one hour:

• Two screens: "Survey Form" and "Results Summary Screen"
• Infrastructure: Azure
  • Front-end: Hosted on Azure Static Web Apps
  • API: HTTP-triggered Azure Functions (.NET)
    • Database: Cosmos DB

Deployment workflows and resources were pre-created before we started.

Watch the archive here ↓

https://www.youtube.com/live/pOYUgAn4qZM

Results

The front-end team completed the survey form and successfully deployed it within the one-hour limit.
On the other hand, the back-end team encountered errors during data registration to Cosmos DB and could not reach the deployment stage.

The cause of the error was that GitHub Copilot did not account for the Cosmos DB Partition Key. Because GitHub Copilot was guessing the Partition Key and writing code without checking the actual state of Cosmos DB, it resulted in an error stating that it was trying to update data using a non-existent Partition Key.

The Difficulty of Back-end Vibe Coding

Personally, I feel that back-end Vibe Coding is more difficult than front-end.
In the front-end, most issues are resolved within the code, making it easier to provide the necessary context (though there are various challenges, such as the AI lacking vision and being poor at detailed UI implementation).

On the other hand, the back-end requires consideration of infrastructure-side resources, so context is insufficient with code alone.
In this state, GitHub Copilot ends up thinking of code based on an infrastructure resource configuration it has guessed on its own.

The cause of defeat in the first round was exactly that: "GitHub Copilot did not know the database configuration."
If so, a hypothesis arises: if we can provide infrastructure-side resource information as context, it might work well.

How to Provide Infrastructure Information

I came up with the following two methods to provide the infrastructure configuration as context:

1. Use IaC (Infrastructure as Code)
   • A method to manage the state of infrastructure via code. This allows infrastructure information to be included within the code.
2. Have the Agent use MCP or commands that can retrieve the infrastructure configuration.

In the case of "1. Use IaC (Infrastructure as Code)," it is desirable for the IaC definitions to be in the same repository. However, for the convenience of separating developer and infrastructure administrator permissions, there are many cases where they are managed separately.
Since making this a prerequisite would lower versatility, I decided to go with the strategy of "2. Have the Agent use MCP or commands that can retrieve the infrastructure configuration," which can be practiced even when the infrastructure is not managed as IaC.

Round 2

https://azure-waigaya.connpass.com/event/360954/

We held an event and challenged the same task with the following improvement measures applied.

Previous Issues

• Failed to provide GitHub Copilot with specific configurations and settings on the infrastructure side.

Improvement Measures

1. Introduction of Azure MCP Server

   • Role: Retrieve resource configurations on Azure (infrastructure).
   • Actually, I had included it since the first round, but it wasn't working properly.
   • Get it here: Azure/azure-mcp: The Azure MCP Server, bringing the power of Azure to your agents.

2. Introduction of Microsoft Docs MCP Server

   • Role: Search for information from official Microsoft documentation.
   • It was working properly even in the first round.
   • Get it here: MicrosoftDocs/mcp

3. Introduction of GitHub Copilot for Azure Extension

• Get it here: GitHub Copilot for Azure Extension
• Details on features: What is GitHub Copilot for Azure - GitHub Copilot for Azure | Microsoft Learn

4. Improvement of Custom instructions

• Custom instructions is a feature that allows you to set specific prompts to always be given when instructing Copilot. If you have instructions you always write, setting them here makes things easier.
• Details here: Customize AI responses in VS Code
• This time, I wrote the following directly in the VS Code setting github.copilot.chat.codeGeneration.instructions. *Note: Writing directly in the settings file (settings.json) is currently deprecated, so in practice, you should create a separate file and configure it to be referenced.

      "github.copilot.chat.codeGeneration.instructions": [
       {
           "text": "Always grasp the configuration on the Azure side using Azure MCP Server and Azure CLI before thinking about implementation."
       },
        (Omitted)
      ]
  

Results

I thought everything would be fine if we could retrieve Azure information seamlessly, but once again, we couldn't achieve it within an hour.
Time ran out without resolving the error, but the main cause was an issue with the Azure Cosmos DB SDK—or rather, a subtle current specification issue (I won't go into details, but it related to referenced JSON packages). It seemed like it would have worked if this issue were resolved in a newer version.

However, even if it had worked, I couldn't deny the cluttered feel and low reproducibility, and since we didn't reach the goal within an hour, I performed another cause analysis.
The causes analyzed at that time included:

• Azure authentication issue: It was unclear where the authentication info was being pulled from in Agent Mode, preventing authentication with the desired account.
• Ignoring Custom instructions: Despite setting "grasp the configuration on the Azure side before implementation" in the Custom instructions, Agent Mode started implementing while ignoring it.
• Inconsistent procedures: Even when instructed to "first show the procedure and implement after permission is given," it implemented on its own.
• Copilot malfunction: It was a strange off-day where both Gemini and Claude Sonnet were returning errors, leaving only GPT-4.1 available.
• Unorganized Tools: The number of Tools configured in Agent Mode exceeded 128, and sometimes tools that were deselected would get reselected, leading to loss of time for Tool cleanup every time a request was sent.

As a result, the hypothesis "Would things go smoothly if we could retrieve Azure-side information?" ended without being fully verified.

Round 3

https://azure-waigaya.connpass.com/event/361466/

We held an event and challenged the same task with the following improvement measures applied.

Improvement Measures

1. Azure authentication issue
   I investigated the Azure authentication information visible from Agent Mode.
   Regarding the GitHub Copilot for Azure extension,

@azure get auth state

I could check which account was logged in and which subscription was being referenced by asking in the Chat (I confirmed it was looking at a specific subscription, though it didn't work properly on the event day...).

2. Organizing Agent Mode Tools & Reducing Inconsistency
   By setting up a custom chat mode, I narrowed down the MCP Server tools to be used and further detailed the instructions previously set in Custom instructions.
   Additionally, I included the following in the instructions:

• Output tasks in a Markdown checklist format
• Use connection strings when running locally
  • Otherwise, it might use complex authentication methods for local settings (this might be specific to Azure).
• Always install packages via commands
  • Because there are many cases where it fails by trying to write incorrect version names directly into package files.

For more details on custom chat modes, please refer to Chat modes in VS Code.
This time, I based my settings on the chat mode published by @taiga_kk322.

https://github.com/taiga-K/github-copilot-rules/blob/main/.github/chatmodes/taskmode.chatmode.md

Regarding the Tools, I changed some parts randomly after the event, so some unnecessary tools are selected, but I used a chat mode roughly like the one below during the event.
It's a bit rough since it was created during the event, but for your reference:

https://github.com/yuma-722/azurewaigaya-share/blob/main/250709-backend-vibecoding/azure.chatmode.md

I modified @taiga_kk322's version for Azure and adjusted it so that code could be written within this chat mode.
The original version is better for reducing inconsistency by limiting roles, but since I wanted to verify how to achieve the goal with minimal customization, I didn't separate the chat modes for design and implementation.

However, in actual development, it would likely be more stable to create chat modes for each role, such as a "chat mode for design that doesn't change code" and a "chat mode for implementation that changes code."

Results

The "Survey Form Back-end Creation" was completed in about 40 minutes!
That said, most of the time was spent on Azure authentication issues. Azure CLI didn't work well either (it's a mystery where the login information for the az command executed in the Copilot terminal is retrieved from; even after manually running az login, subsequent command executions by the Agent occurred in new terminals, which didn't work). In the end, I took a screenshot of the Cosmos DB settings and sent it to Copilot Chat.

However, the major difference from Round 2 was that it followed the instructions in the custom chat mode.
Because of this, for the Cosmos DB configuration that it didn't ask about in Round 2, it acted in a way that allowed me to notice that I had forgotten to provide those instructions.
The behavior of arbitrarily fabricating infrastructure-side configurations (in this case, mainly the Cosmos DB Partition Key) and starting to write code has stopped, which is a big step forward.
This allows us to avoid the situation where code is written based on unknowingly fabricated infrastructure information, resulting in code that doesn't work.

If the Azure authentication issues could be resolved, it should be able to automatically retrieve the Azure-side configuration, including the Partition Key, design based on that, and then move to implementation after getting permission.

Summary

Through the series of events on mastering back-end Vibe Coding, I have summarized the minimum points to keep in mind to make Vibe Coding easier in the back-end. This is just the minimum! It would be best to use this as a base and layer on further adjustments.

• Set it up to either automatically retrieve infrastructure-side information or ask a human
  • Provide such instructions using things like custom chat modes in GitHub Copilot.
  • Enable seamless retrieval of infrastructure-side information using commands or MCP Servers
    • In the case of Azure, the Azure MCP Server, GitHub Copilot for Azure extension, and Azure CLI fulfill this role.
    • If you have introduced IaC, it is a different story. If code such as Terraform exists in the same repository, it is sufficient to have it refer to that.
  • If no officially provided Tool can retrieve infrastructure-side information, or if it cannot be retrieved due to network restrictions, set instructions in a custom chat mode for the Agent to interview a human during the design phase.
    • Including this instruction prevents forgetting to convey the infrastructure configuration context that could affect the code.
• If you want to generate code specialized for a specific technology (Azure in this case), use custom chat modes instead of Custom instructions
  • This is because you can manage by linking the Tools used by the Agent with specific prompts, and switching between multiple chat modes is easy.
• Run the Agent with an appropriate model
  • In many cases, GPT-4.1 did not call the MCP Server well, while using Claude Sonnet 4 often worked better.
  • Continue to select models that follow custom chat mode instructions well and call MCP Servers appropriately as models are updated.

I will summarize where the authentication information for each Azure-related tool is retrieved from in a separate article at a later date.

Until then, have a great Vibe Coding Life!