Mark Michaelis is a figure who has witnessed every major evolution of the .NET ecosystem, from the early days of C# to the current explosion of agentic AI. As a Microsoft Regional Director and an MVP for over 25 years, he has guided countless developers through the shifting tides of software engineering. Currently, he serves as the Chief Technical Architect at IntelliTect and teaches at Eastern Washington University, giving him a unique vantage point on how both seasoned professionals and eager students are grappling with the rise of artificial intelligence. With tools like Visual Studio’s agent mode beginning to take over tasks that once required hours of manual labor, Michaelis is sounding a clarion call for a return to fundamental engineering discipline. He isn’t suggesting we retreat from AI, but rather that we use it with a surgical precision that preserves our ability to build long-term, strategic software. This conversation explores the inherent tension between the speed of AI-generated code and the lasting value of human architectural judgment.
Visual Studio’s agent mode can now execute terminal commands and react to test results autonomously. How does this level of machine agency redefine what it actually means to be a software engineer in the .NET ecosystem?
The shift we are seeing with agentic coding is more than just a simple upgrade to our IDEs; it is a fundamental change in the developer’s role from being a primary writer to being a sophisticated editor and overseer. When an AI agent can look at a high-level task, determine the necessary steps, and then proceed to make code edits or run terminal commands on its own, it is handling the tedious “how” while we must focus intensely on the strategic “why.” This increasing autonomy means that we have to make a very deliberate choice about which parts of the engineering process we are willing to hand over and which parts require our unique human judgment. We are seeing a platform where developers can add AI capabilities while still using their familiar tools for debugging and deployment, but the speed of these agents creates a new kind of pressure. If we do not have a rock-solid understanding of our engineering principles, we risk becoming passive observers of a process that can go off the rails faster than we can blink. I see this struggle every day at the university level, where the temptation to just let the AI provide the answer can easily override the work ethic required to truly learn the material.
When we look at the foundational concepts of .NET, which specific areas do you believe are too critical to outsource to AI, and why should developers guard these skills so fiercely?
For me, the areas that must remain under human control are architecture, code structure, and the entire spectrum of DevOps skills. It is incredibly tempting for a student or a junior developer to let the AI handle the complex logic of how a system is put together, but that is exactly where the human touch is most needed to ensure long-term stability. Developers absolutely need to understand the nuances of testing—distinguishing between unit, integration, and load testing—and they must be proficient in source-code control and automated deployment practices. These DevOps disciplines are not just secondary tasks; they are the essential guardrails that keep AI-generated code from becoming a tangled mess. If your engineering infrastructure is strong enough, you can use those automated builds and testing practices to help keep the AI “on the rails.” Without that discipline, you have no way of knowing whether the massive amount of code being produced at unprecedented speed is actually of any quality.
You’ve identified technical debt as a potentially bigger long-term problem than any single knowledge gap when using AI. How does this debt manifest differently when code is generated at such a high velocity?
The danger of technical debt in an AI-driven world is that it accumulates at a speed that traditional manual coding simply cannot match. When you are writing every line by hand, you have a natural, built-in speed limit that allows you to catch architectural inconsistencies before they become systemic problems. AI, on the other hand, can churn out massive amounts of code in seconds, and if you are working on a strategic project that is expected to live for years, that debt can become an insurmountable wall very quickly. I have noticed that while AI can help you get a prototype up and running in record time, it often lacks the strategic foresight required to build a maintainable, long-term architecture. There is a hope that future AI might help us rewrite systems to clear this debt, but currently, the rate of accumulation is far outstripping our ability to manage it. This makes it extremely difficult to build large, successful, strategic products if you rely exclusively on AI without a heavy human hand on the tiller to steer the architecture.
Since AI can be incredibly prolific at generating tests, how can a developer effectively verify that the produced code is actually reliable without getting bogged down in noise?
This is one of the biggest challenges I see today: AI is amazing at producing tests, but those tests are often of very little actual value to the health of the application. It is not unusual to look at a codebase where as much as 80 percent of the unit tests generated by an AI are essentially useless noise that should just be thrown away. These tests might consume tokens and add bulk to your repository, but they do not provide the meaningful protection you need for a production environment. The key is to focus on your specifications and ensure that the 20 percent of tests that actually matter are tightly aligned with the behavior you expect from the system. We have to be more diligent about reviewing the quality of the tests than even the code itself sometimes, because a bad test suite gives a false sense of security that can hide critical flaws. You need a strong testing methodology and functional tests that actually correspond to the desired behavior of the system to keep things safe.
In your view, which specific development activities currently see the most significant advantage from AI integration, and where does it still fall short?
Right now, AI has a massive advantage in areas like deployment and triage, where it can handle repetitive or investigative tasks with incredible efficiency. Its ability to write complex deployment scripts is already quite impressive, and it has a real knack for helping developers focus on where a specific defect might be hiding in a large codebase. If you have a bug, the AI can be a powerful partner in investigating the likely source and even suggesting the unit tests that will expose the defect for you to fix. However, it still has a long way to go when it comes to making the high-level architectural and strategic choices that lead to a maintainable codebase over many years. It can solve a localized problem or write a specific script beautifully, but it does not yet have the “big picture” thinking required to design the overall architecture of a complex, strategic system that needs to be evolved by a human team.
Which stage of the software-development lifecycle do you feel is the most vulnerable when we move toward agentic coding?
I believe the actual writing of the code itself remains the most vulnerable stage because we have not yet reached a point where the AI understands the long-term consequences of its choices. While AI can and should write code, the risk of accumulating technical debt is so high that we have to shift our focus to the activities that surround that code generation. This means putting more emphasis on automated feedback loops, rigorous testing, and the DevOps practices that allow us to judge if the system is moving in the right direction. We need to spend more time on the mechanisms of verification and less on the raw act of typing out logic, because the code writing is where the most subtle and dangerous errors in architecture can be introduced. Our role is to ensure that the “agentic” part of the process does not lead us into a dead end that we cannot easily refactor our way out of later.
For beginners who are just starting out, what is the best way to balance the help they get from AI with the need to actually learn the fundamentals of programming?
I would strongly encourage beginners to use AI as a learning tool and a partner in a feedback loop rather than a simple shortcut to get the answer. One of the best ways to learn is to have the AI write a piece of code, then spend a significant amount of time reviewing it to see if you truly understand every line and every decision it made. You can even turn it into a game: review the code yourself to find potential errors, then ask the AI to do a review and see how your findings compare to what it identifies. This process keeps you actively engaged and forces you to think critically about the software being produced, which is the only way to build real expertise. The real danger is not that the AI is writing the code; the danger is when the developer switches off their brain and stops thinking about what the code is actually doing, which effectively halts their growth as an engineer.
What habits should engineering leaders encourage within their teams to make sure that fundamental programming skills are preserved as automation becomes more common?
The most important habit for any engineering leader to foster right now is a relentless focus on quality over the sheer quantity of output. Because AI makes it so effortless to produce mountains of code and endless test suites, it is easy for a team to feel like they are being incredibly productive when they might actually just be creating a maintainable nightmare. Leaders need to keep the team’s attention on whether the code is maintainable, whether the tests provide real value, and whether the system as a whole is built to survive over the long haul. We should be rewarding the developer who throws away the 80 percent of useless AI-generated tests just as much as the one who uses AI to speed up a deployment script. Maintaining that engineering discipline and focusing on the long-term health of the codebase is what will separate the successful teams from those who get buried under AI-generated technical debt.
How can developers prepare for the mental and emotional shift required to give up some of the low-level problem-solving that has traditionally defined the profession?
This is a very real challenge, and for many experienced developers like myself who have been in this for decades, there is almost a grieving process involved in letting go of the manual problem-solving we have mastered. Since I have been a Microsoft MVP for over 25 years and a Regional Director since 2007, I have seen how much our identity is tied to solving those low-level puzzles. We have to wrestle with the tension between the “work ethic of learning” and the convenience of having an AI give us the answer instantly. To prepare for this shift, you have to be honest with yourself about what knowledge is still essential for you to remain an effective engineer and what tasks you can safely delegate to the machine. It requires a lot of introspection and a willingness to redefine your value as someone who understands the system’s architecture and quality, rather than just someone who can solve a clever algorithm. Wrestling with that tension is the most important preparation you can do, because it forces you to make deliberate choices about your own growth.
What is your forecast for the evolution of the .NET developer’s role over the next few years as these AI agents become more sophisticated?
I believe we will see the .NET developer evolve into something much closer to a “Systems Architect and Quality Assurance Lead” for every project they touch. The focus will shift entirely away from the syntax of C# and toward the orchestration of complex systems, where the ability to manage DevOps pipelines and verify the integrity of automated code becomes the most valuable skill in the room. We will likely see AI becoming incredibly adept at rewriting and refactoring legacy systems, which might help us manage technical debt, but the initial strategic design will still rely on human intuition for a long time to do well. Ultimately, the successful developers will be those who can harness the speed of agentic AI while maintaining a fierce, uncompromising commitment to engineering quality and architectural clarity. We have to decide what work we should continue doing ourselves, what work we should hand over, and what knowledge we still need in order to remain effective engineers who can build software that lasts.
