GitHub Copilot has evolved from an AI code completion tool into a powerful development assistant. With the introduction of AI development agents, Copilot can now help automate entire development workflows rather than simply suggesting individual lines of code.
Instead of acting as an autocomplete tool, AI agents understand high-level objectives, plan the required steps, modify multiple files, execute tests, review results, and assist with completing development tasks. Developers remain in control, reviewing and approving changes while Copilot handles much of the repetitive implementation work.
Modern GitHub Copilot agents can assist with tasks such as:
Depending on the workflow, these tasks can be performed directly inside the IDE or autonomously in GitHub repositories.
GitHub Copilot becomes significantly more effective when it understands your project. By using repository context, documentation, coding standards, issues, pull requests, and external tools, it can generate more accurate and relevant solutions that fit your existing codebase.
To get the best results, provide clear objectives, supply sufficient context, and always review generated changes before accepting them. Think of GitHub Copilot as a collaborative teammate that accelerates development while leaving architecture, security, and business decisions to the developer.
AI development agents represent the next step in GitHub Copilot's evolution, enabling developers to spend less time on repetitive coding and more time designing, solving problems, and delivering high-quality software.
Open-source frameworks give developers the freedom to build AI agents without being tied to a commercial platform. They provide reusable components for common AI patterns such as agent orchestration, memory, tool calling, and workflow management, while still allowing full control over the implementation.
These frameworks evolve quickly and are often among the first to support new AI capabilities. They are a popular choice for development teams that want maximum flexibility and are comfortable managing their own infrastructure and deployments.
Open-source frameworks provide an excellent balance between flexibility and productivity. They accelerate AI development while allowing developers to keep full control over architecture and implementation.
Cloud providers offer complete ecosystems for building, deploying, and managing AI agents. Instead of assembling individual components yourself, these platforms combine AI models with infrastructure, security, storage, monitoring, and development tools. This allows development teams to focus on building intelligent solutions rather than managing servers and infrastructure.
Cloud platforms are particularly attractive for organizations that already run their applications in the cloud, as they integrate naturally with existing services and can scale from small prototypes to enterprise-wide deployments.
Cloud platforms provide a powerful foundation for AI agents by combining managed AI services with secure and scalable infrastructure. They reduce operational effort while making it easier to build production-ready AI solutions.
Not every AI solution requires a team of developers. Low-code and no-code platforms allow users to build AI-powered workflows through visual interfaces instead of writing large amounts of code. By connecting triggers, actions, and AI models, organizations can automate everyday tasks in a fraction of the time needed for traditional development.
These platforms are especially useful for creating internal automations, prototypes, or business processes that integrate multiple applications. While they may not offer the same flexibility as custom development, they provide an excellent balance between speed and functionality.
Low-code platforms make AI accessible to a much wider audience. They are an excellent choice when speed, simplicity, and integration are more important than complete technical control.
Many organizations already use business platforms that now include built-in AI capabilities. Rather than creating an AI agent from scratch, these platforms allow you to build intelligent assistants directly within existing business applications. This significantly reduces development effort because the agent can immediately access business data, workflows, permissions, and automation features that already exist.
For companies that are heavily invested in a specific business ecosystem, this is often the fastest path to delivering useful AI solutions.
Enterprise AI platforms focus on speed, reliability, and business integration. They are an excellent choice when AI should enhance existing enterprise applications rather than replace them.
Building an AI agent from scratch gives you complete control over how it works. Instead of relying on predefined workflows or platform limitations, you decide how the agent reasons, stores information, communicates with other systems, and interacts with users. Although this approach requires more development effort, it provides the flexibility needed for highly specialized solutions.
For organizations with experienced development teams, custom development is often the preferred choice when existing platforms cannot satisfy business or technical requirements.
Custom development delivers the greatest flexibility and control, making it ideal for organizations that have the technical expertise to build and maintain their own AI solutions.
A good logging configuration helps you troubleshoot problems quickly while avoiding unnecessary telemetry and storage costs. In ASP.NET Core, Application Insights is configured in two parts: one for connecting to Azure and another for controlling which log messages are collected.
The ApplicationInsights section contains the connection to your Azure Application Insights resource.
{
"ApplicationInsights": {
"ConnectionString": "InstrumentationKey=...;IngestionEndpoint=..."
}
}Using a Connection String is the recommended approach and replaces the older Instrumentation Key.
The Logging section determines which messages are written by your application. In most cases, the global LogLevel settings are sufficient. If needed, you can also define provider-specific settings for Application Insights.
{
"ApplicationInsights": {
"ConnectionString": "InstrumentationKey=...;IngestionEndpoint=..."
},
"Logging": {
"LogLevel": {
"Default": "Information",
"YourCompany.YourApplication": "Information",
"Microsoft": "Warning",
"System": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
},
"ApplicationInsights": {
"LogLevel": {
"Default": "Information",
"YourCompany.YourApplication": "Information",
"Microsoft": "Warning",
"System": "Warning"
}
}
}
}| Setting | Purpose |
|---|---|
ApplicationInsights:ConnectionString |
Connects the application to your Azure Application Insights resource. |
Logging:LogLevel |
Defines the default log levels used throughout the application. |
Logging:ApplicationInsights:LogLevel |
Optionally overrides the log levels used only by the Application Insights logging provider. |
A balanced production configuration is usually:
InformationInformationWarningWarningInformationFor development, you can temporarily change your own application's namespace to Debug or Trace to collect more detailed diagnostic information without increasing the verbosity of framework logs.
This configuration provides useful application telemetry, keeps framework logging under control, and makes troubleshooting easier while avoiding unnecessary noise and storage costs.
Artificial Intelligence is no longer limited to data scientists. Modern cloud platforms provide ready-to-use AI services that allow developers to add intelligent capabilities to applications with minimal machine learning expertise.
Azure offers a broad portfolio of managed AI services for different use cases:
A common architecture combines AI Search with generative AI. Documents are indexed, relevant information is retrieved, and only the most useful content is supplied to the language model. This retrieval-based approach improves response accuracy while enabling AI applications to work with private organizational data without relying solely on the model's built-in knowledge.
Modern AI development platforms provide centralized workspaces for managing models, datasets, and shared resources. They also include tools for governance, collaboration, deployment, and monitoring. AI-powered assistants further improve productivity by helping developers generate scripts, troubleshoot cloud resources, analyze costs, and identify security or compliance issues, making it easier to design, deploy, and maintain intelligent applications at scale.
A surprisingly large C:\Windows\System32\Configuration folder can consume tens of gigabytes on a Windows Server. One common cause is the DSC (Desired State Configuration) status history stored in the ConfigurationStatus folder.
In this case, the folder contained more than 30,000 status files and consumed over 40 GB of disk space. Although the Local Configuration Manager (LCM) was configured to retain status information for only a limited number of days, old files were still present, indicating that the cleanup process was no longer working correctly.
A structured approach helps determine whether the problem is caused by excessive status files, corrupted DSC state information, or a failing configuration.
The process consists of three main steps:
Following these steps helps reclaim disk space, restore DSC functionality, and identify configuration issues that may prevent DSC from running successfully.
If cleanup does not resolve the issue, the next step is to investigate DSC itself.
First restart the relevant services:
Restart-Service WinRM -Force
Restart-Service WmiApSrv -Force -ErrorAction SilentlyContinueNext, review the DSC operational log for detailed error messages:
Get-WinEvent -LogName "Microsoft-Windows-DSC/Operational" -MaxEvents 20 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-ListThe operational log often reveals the resource responsible for the failure.
To test the current DSC configuration, manually start a configuration run:
Start-DscConfiguration -UseExisting -Wait -VerboseIn this scenario, DSC reported a failure in the MSFT_AccountPolicy resource while attempting to update the Minimum_Password_Length setting.
This indicates that:
At this stage, review the DSC configuration source and verify whether password policy settings should still be managed by DSC. Correcting or removing the failing configuration and then applying a new configuration is typically the final step in restoring a healthy DSC environment.