AI coding assistants already understand .NET. The next challenge is teaching them how your team builds software.
One of the most interesting things happening in software engineering right now isn't the arrival of another language model.
It's the gradual realization that intelligence alone isn't enough.
Over the past couple of years, AI coding assistants have become remarkably capable. Whether you're using GitHub Copilot, Claude Code, Cursor, Codex, or another modern coding assistant, it's difficult not to be impressed by how quickly they can generate APIs, write unit tests, explain unfamiliar code, or scaffold entire applications.
In many cases, they already understand programming languages better than most developers ever will.
Ask them about C#, ASP.NET Core, Entity Framework, LINQ, Minimal APIs, dependency injection, or asynchronous programming, and the answers are usually accurate, well-structured, and surprisingly practical.
Yet despite all of that progress, I continue hearing the same complaint from engineering teams.
"The AI still doesn't understand our project."
At first, that sounds like a limitation of the model itself.
The more I think about it, the more I believe it's actually a limitation of context.
Understanding a Language Isn't the Same as Understanding a Codebase
Knowing how .NET works is only one small part of software engineering.
Every engineering organization develops its own way of building software.
Some teams organize their applications around Clean Architecture.
Others prefer Vertical Slice Architecture.
Some rely heavily on CQRS with MediatR.
Others use repository patterns, Result, domain events, feature folders, or entirely custom conventions that have evolved over years of development.
Then there are the business rules.
The naming conventions.
The deployment pipeline.
The testing philosophy.
The internal libraries.
The security requirements.
The architectural decisions that exist nowhere except inside the heads of experienced engineers.
This is the context that makes one company's codebase fundamentally different from another's.
Modern language models understand C#.
What they don't automatically understand is your organization.
Every new conversation begins from almost zero.
The assistant has to rediscover your architecture, infer your conventions, and guess how your team prefers to solve problems.
That's an incredibly expensive way to collaborate.
Why Microsoft's Repository Matters
This is why Microsoft's recently open-sourced dotnet/skills repository caught my attention.
At first glance, the announcement appears relatively straightforward.
Microsoft published nearly one hundred reusable AI skills covering common .NET development tasks such as ASP.NET Core, Entity Framework, testing, project modernization, upgrades, and AI application development.
For many developers, the headline became the number.
Ninety-nine skills.
An impressive collection.
But I think the number is the least interesting part.
The real innovation is the idea behind it.
Instead of repeatedly explaining the same workflows every time an AI assistant starts a new session, those instructions can be packaged into reusable skills that compatible AI agents automatically load whenever they're relevant.
The assistant doesn't need to be reminded how to approach a particular .NET task.
The knowledge already exists.
The context is reusable.
Microsoft Can Teach AI About .NET
Only You Can Teach AI About Your Company
This is where I think the conversation becomes much more interesting.
Microsoft can teach AI how to write better .NET applications.
Only your engineering team can teach AI how to build software your way.
Imagine every architectural principle your team follows becoming reusable knowledge.
Your preferred folder structure.
Your API design guidelines.
Your naming conventions.
How authentication works.
How repositories are organized.
How pull requests should be reviewed.
How services communicate.
How logging is implemented.
How feature flags are introduced.
How migrations are managed.
How domain models evolve.
Instead of explaining these ideas repeatedly, they become part of your organization's shared engineering memory.
Every AI-assisted development session starts with context rather than assumptions.
That changes the relationship between engineers and AI completely.
From Prompts to Organizational Knowledge
One pattern has become increasingly obvious over the last year.
Most developers spend far too much time repeating themselves.
Every prompt includes reminders about coding standards.
Every conversation explains the same architecture.
Every new feature starts with another description of how the application is structured.
Eventually, prompt engineering becomes organizational overhead.
Reusable skills solve a different problem.
Instead of writing better prompts, teams begin capturing institutional knowledge.
Knowledge stops living inside Slack conversations, onboarding documents, or the minds of senior engineers.
It becomes something AI can actively use while generating software.
That may sound like a subtle difference.
I don't think it is.
It's the difference between asking someone to remember instructions every day and giving them a well-designed handbook they can reference automatically.
The Competitive Advantage Is Shifting
When AI coding assistants first became popular, much of the conversation focused on choosing the best model.
Should you use Claude?
Copilot?
Cursor?
Codex?
The assumption was that better models would naturally create better engineering outcomes.
I'm no longer convinced that's where the biggest advantage will come from.
As foundation models continue improving, the performance gap between them will likely become smaller.
What becomes difficult to copy isn't the model.
It's the organizational knowledge surrounding it.
Every engineering team has accumulated years of architectural decisions, operational experience, coding conventions, business rules, deployment strategies, and technical trade-offs.
That knowledge is incredibly valuable.
Until recently, most of it existed only inside documentation or experienced engineers.
Now it can become something AI actively participates in.
That's a much more durable competitive advantage than simply paying for access to the latest language model.
Software Engineering Is Becoming More About Context
The longer I work with AI-assisted development, the more I believe that software engineering is quietly shifting from writing code toward managing context.
Generating code is becoming cheaper every month.
Providing the right context is becoming increasingly valuable.
The organizations that succeed won't necessarily be the ones with the most advanced AI models.
They'll be the ones that systematically teach those models how they build software, why they make certain architectural decisions, and what quality means inside their engineering culture.
That's knowledge no foundation model can learn on its own.
Conclusion
Microsoft's ninety-nine AI skills are undoubtedly useful.
They'll help developers work more effectively with .NET, automate common tasks, and reduce repetitive instructions during AI-assisted development.
But I think the repository points toward something much bigger.
The future isn't simply AI that understands programming languages.
It's AI that understands engineering organizations.
Because once an assistant understands not only how to write C#, but also how your team designs systems, reviews code, structures projects, and makes architectural decisions, something fundamental changes.
The assistant stops feeling like a code generator.
It starts feeling like a new engineer who's already completed onboarding.
And that may become one of the most valuable productivity improvements software engineering has seen in years.
Building AI-Powered Software
I spend much of my time helping founders, startups, and businesses build modern software systems, integrate AI into existing products, and design cloud-native architectures that can scale as businesses grow.
If you're exploring AI-assisted development, custom business software, intelligent automation, or scalable web applications, I'd be happy to help turn those ideas into production-ready solutions.
Fastwork: https://fastwork.id/byob/7pFhYwWqZd?openExternalBrowser=1&source=byob
About Me
Most days you'll find me building software, experimenting with AI, exploring distributed systems, and writing about the ideas I encounter along the way.
I'm particularly interested in software engineering, artificial intelligence, cloud computing, system architecture, and how emerging technologies are changing the way we design, build, and maintain software. Through these articles, I share lessons from real projects, technical research, and observations about where our industry is heading.
I don't write because I think I have all the answers. I write because some of the best ideas emerge when they're shared, challenged, and refined together.
Top comments (0)