Software development is changing so quickly that even experienced engineers are beginning to question what "coding" will actually mean a few years from now. One of the strongest statements came from Microsoft Distinguished Engineer David Fowler, who recently wrote that "typing code is absolutely over." Coming from someone who has spent 18 years at Microsoft and helped build technologies such as SignalR, NuGet, Kudu and ASP.NET Core, the comment carries more weight than the usual provocative prediction about AI replacing programmers.
Fowler's point is not that developers will stop understanding code, reviewing it or making technical decisions. The bigger shift is that manually writing every line inside an editor is becoming a smaller part of software engineering. As AI coding systems move from autocomplete toward autonomous agents capable of modifying repositories, running applications, testing their work and fixing failures, developers are increasingly being pushed toward architecture, validation, security and deciding what should be built in the first place.
Microsoft Is Moving Beyond AI Autocomplete
The first generation of AI-assisted development was largely about suggestions. Tools such as Visual Studio IntelliCode and the early versions of GitHub Copilot watched what the developer was typing and attempted to predict the next line, method or code block. The programmer still remained firmly in control of the workflow, with AI functioning more like an unusually capable autocomplete system.
Microsoft Research was already studying the usability of this model in 2023. Researchers tested 19 different IntelliCode designs across seven laboratory studies involving 61 programmers and discovered that the challenge was not simply generating useful suggestions. Developers often failed to notice those suggestions because of how they were presented inside the interface.
That entire interaction model now looks relatively conservative. GitHub Copilot has evolved well beyond waiting for a programmer to type something before offering assistance. Its coding agent can receive a development task, create an environment, inspect the repository, modify files, run tests and eventually prepare a pull request for human review.
The difference is fundamental. AI is no longer simply helping someone type code; it is increasingly being given responsibility for carrying out part of the development workflow itself.
Copilot Can Now Work in the Background
GitHub's coding agent represents a very different relationship between developer and machine. Instead of sitting beside the programmer inside the editor, the agent can work asynchronously on a task while the developer does something else. It can make changes, execute build processes, run linters and validate its own output before returning the completed work for review.
In February 2026, GitHub expanded the coding agent with Windows development environments, allowing it to work directly with Windows-targeted projects. This means an agent can build software intended for Windows, run tests and verify that the project compiles successfully without requiring the developer to manually perform every step.
Copilot can also run agent sessions inside Windows Subsystem for Linux, extending the same approach to Linux-oriented development on Windows. This is increasingly important because modern developers frequently work across Windows, Linux, cloud environments and containers within the same project.
The development environment itself is therefore becoming more agent-aware. Instead of expecting AI to merely produce code snippets, Microsoft and GitHub are building infrastructure in which AI can actually operate.
Even Linus Torvalds Sees AI as Another Useful Development Tool
The shift is not limited to Microsoft. Linus Torvalds, whose opinions on software development are rarely described as blindly enthusiastic, has also expressed support for AI-assisted coding. His view is essentially that AI should be considered another tool in the developer toolbox rather than something fundamentally alien to software engineering.
That perspective matters because debates around AI-generated code often become unnecessarily dramatic. The choice is not simply between programmers writing everything manually and machines replacing programmers entirely. Software development has always evolved through better abstractions and automation.
Assembly gave way to higher-level languages. Developers stopped manually managing many aspects of memory when managed runtimes became common. IDEs automated repetitive refactoring, while frameworks eliminated huge amounts of boilerplate. AI agents may simply represent another major step in that continuing abstraction.
What changes this time is the scale. Instead of automating one narrow operation, the tool may participate across much of the software-development lifecycle.
Aspire Shows What an AI-Native Development Workflow Could Look Like
Fowler currently leads work around Microsoft Aspire, a code-first toolchain for developing and running distributed applications. Aspire allows developers to describe services, containers, databases and other application components through a unified application model rather than manually managing every infrastructure component independently.
The project has increasingly been redesigned with AI agents in mind. Aspire 13.1 made AI coding assistants first-class participants in the development workflow, while Aspire 13.2 expanded the idea further through an agent-friendly command-line interface and support for the Model Context Protocol, or MCP.
This matters because generating application code is only one part of building software. A functioning distributed application may involve several services, databases, configuration files, containers, telemetry systems and dependencies. Getting one function correct does not mean the entire application actually runs.
Microsoft is trying to expose those surrounding systems to AI agents so they can participate in the full development loop.
Writing Code and Shipping Working Software Are Very Different Problems
Fowler's team acknowledged this directly when discussing AI agents earlier in 2026. AI systems have become very capable at producing code, but generating syntactically valid code and delivering a working application are completely different challenges.
A developer normally does far more than type. They start services, inspect error logs, look at telemetry, debug failed dependencies, modify configuration and rerun tests. A traditional AI chatbot may be able to suggest a fix, but the human still needs to copy an error message into the conversation, apply the recommendation and manually test whether it worked.
Aspire aims to remove much of that handoff. An AI agent can potentially launch the services itself, inspect what failed, read logs, check telemetry, make another change and restart the application. The feedback loop becomes much more autonomous.
This is where Fowler's statement starts making more sense. If the AI can operate inside the same development environment as the engineer, manually typing every implementation detail becomes less central to the job.
The Developer Becomes More of a System Designer and Reviewer
If code becomes inexpensive to generate, the value of software engineering moves elsewhere. Architecture becomes more important because someone still needs to decide how the system should be structured. Performance remains important because an AI-generated solution that technically works may still be inefficient.
Dependency management becomes more critical as agents can easily introduce libraries without fully understanding their long-term maintenance or security implications. Testing becomes more important because developers will increasingly need confidence that machine-generated changes behave correctly under conditions the AI did not anticipate.
The developer therefore shifts from being primarily an author to being a combination of architect, reviewer, tester and technical decision-maker. The skill is less about how quickly someone can type an implementation and more about whether they can recognise a good implementation when they see one.
That is still software engineering. It simply changes where the human effort is concentrated.
AI-Generated Code Creates a New Review Problem
There is also an uncomfortable consequence of generating software faster: someone still needs to determine whether the generated code is safe. Veracode's 2026 GenAI Code Security Report found that around 44% of the AI coding tasks it tested produced code containing a known vulnerability.
That result came from a controlled benchmark and should not automatically be interpreted as a failure rate for every AI coding tool. It nevertheless illustrates the broader concern. If organisations produce far more code because AI has dramatically reduced the cost of writing it, traditional line-by-line manual review becomes increasingly difficult.
Developers may simply be unable to inspect every generated function in the same way they would have reviewed a smaller amount of manually written code. Security tooling therefore needs to scale alongside code generation.
Microsoft is already attempting to apply AI to that side of the problem as well.
MDASH Uses AI to Hunt Vulnerabilities at Windows Scale
Microsoft's security teams are using an agentic vulnerability-scanning system known internally as MDASH. The technology is already being applied across engineering teams working on Windows, Azure and Microsoft identity systems.
According to Microsoft's Windows security team, MDASH allows vulnerability hunting to happen at the scale of the Windows codebase while providing deeper analysis than was previously practical. The system has reportedly been used to examine highly sensitive components including the Windows kernel, Hyper-V and networking stack.
That creates an interesting symmetry. AI can generate more code, but AI can also examine more code than a human security team could reasonably review manually.
This may become an important part of the future development workflow. Rather than relying entirely on developers to inspect everything an agent creates, separate AI systems could continuously analyse code for vulnerabilities, performance problems and architectural inconsistencies.
Windows 11 Development May Already Be Moving in This Direction
It is difficult to know exactly how much of Windows 11's recent development has been directly written by AI. Microsoft has not provided a detailed breakdown for individual Windows components, although CEO Satya Nadella has previously said that around 20% to 30% of code at Microsoft is being written by AI.
What is much clearer is that the surrounding engineering environment is becoming increasingly AI-oriented. Microsoft is developing autonomous coding agents, agent-ready application frameworks and security systems capable of analysing extremely large codebases.
Windows itself has also received an unusually large number of improvements and fixes throughout 2026. The July update alone reportedly addressed around 570 bugs, alongside numerous usability and feature changes.
It would be difficult to attribute those improvements directly to AI without evidence. However, they show why Microsoft is interested in increasing software-development throughput. If AI can help engineering teams work through larger backlogs while humans concentrate on architecture and validation, the effect could become visible to ordinary Windows users even when they never interact with the coding tools themselves.
Native Windows Development Is Also Making a Comeback
Fowler has previously argued that native applications are returning to prominence, and Microsoft's recent development strategy appears to support that idea. The company increasingly recommends WinUI 3 as the native framework for new Windows applications instead of relying exclusively on web-based wrappers.
Microsoft has also opened WinUI 3 more extensively, improving the amount of source code and documentation available to developers. That openness has an interesting secondary benefit in an AI-heavy development environment.
AI agents perform better when tools, APIs and frameworks are clearly documented and structurally predictable. A mature native framework with accessible documentation gives agents more reliable information about how Windows applications should be built.
In that sense, better developer tooling helps humans and AI at the same time.
Project Zenith Takes AI Development Closer to the Hardware
Microsoft is also preparing Windows for developers who want to run increasingly powerful AI models locally rather than sending every request to cloud services. Project Zenith, announced on September 4, introduces a developer-focused Windows 11 configuration designed around extremely capable AI hardware.
The baseline is aggressive: systems are expected to provide 64GB of unified memory and around 250GB/s of memory bandwidth, beginning with platforms based on AMD Ryzen AI Halo processors. That level of hardware allows developers to run much larger models locally, including models with more than 30 billion parameters.
Local inference changes the economics and privacy characteristics of AI development. Instead of paying for every cloud token, a developer with sufficient hardware can run an agent repeatedly on the workstation itself.
It also reduces latency and makes certain workflows possible without continuously sending source code or project context to a remote service.
The Keyboard Is Becoming Less Central, Not Completely Irrelevant
Fowler's statement works best when interpreted as a description of emphasis rather than a literal claim that nobody will type another line of code. Developers will obviously continue editing code manually when doing so is faster, clearer or necessary.
The difference is that typing may no longer define programming in the way it once did. A developer might spend the morning describing a feature to an agent, reviewing the resulting architecture, investigating performance problems and approving several pull requests without manually writing most of the implementation.
Someone looking over their shoulder might say they barely coded all day. Yet they may have made dozens of highly consequential engineering decisions.
The keyboard remains useful, but it is no longer necessarily the centre of the development process.
Software Engineering Becomes More About Judgment
This shift could actually make experienced engineers more valuable rather than less. Generating code is increasingly easy, but knowing whether that code is appropriate requires understanding systems deeply.
A less experienced developer may accept an AI-generated implementation because it compiles and passes basic tests. A stronger engineer may recognise that the same implementation will become difficult to maintain, introduces unnecessary dependencies or creates performance problems at scale.
That kind of judgment becomes increasingly important when AI can create enormous amounts of software very quickly. The expensive part is no longer producing possibilities. It is identifying which possibility should become the product.
Junior Developers May Need to Learn Differently
The transition does create a difficult question for less experienced developers. Traditionally, writing lots of code was how programmers learned the behaviour of languages, frameworks and systems. If AI performs much of that implementation work, newer developers need other ways to develop the deep understanding required to review its output.
Blindly accepting generated code would be dangerous because someone eventually needs to recognise when the agent has made a poor decision. Developers will still need to understand data structures, algorithms, architecture, operating systems, networking and security even if they spend less time manually implementing every detail.
Education may therefore move increasingly toward reading, debugging and evaluating software alongside writing it.
Knowing why something works becomes more valuable when producing something that appears to work is almost effortless.
AI Agents Need Better Boundaries as Their Authority Grows
Autonomous coding agents also introduce governance questions that autocomplete never created. A suggestion appearing inside an editor cannot independently modify twenty files, launch services or change infrastructure. An agent potentially can.
Organisations will need controls around which repositories an agent can access, what credentials it can use and which commands it is allowed to execute. Changes produced autonomously still need traceability, review and accountability.
The more capable these agents become, the more software development begins resembling the management of another technical worker rather than the use of a traditional tool.
That requires engineering organisations to think seriously about permissions, auditing and human approval points.
Developers Are Not Disappearing
The dramatic interpretation of statements such as "typing code is absolutely over" is that programmers are becoming unnecessary. The reality described by Fowler's work looks much less like replacement and much more like a change in abstraction.
Developers are still deciding what the system should do. They still need to understand whether the implementation is secure, fast, maintainable and appropriate for the business. They still own the consequences when the software fails.
What is becoming automated is more of the mechanical translation between an engineering intention and the code required to implement it.
That is a major change, but it is not the end of software engineering.
Final Thoughts
David Fowler's statement that "typing code is absolutely over" sounds extreme until you look at what Microsoft is already building. GitHub Copilot can work asynchronously inside repositories, Aspire is being redesigned so AI agents can operate throughout the application lifecycle, MDASH is hunting vulnerabilities across some of Microsoft's hardest code, and Windows development environments are being prepared for increasingly powerful local AI models.
The pattern is clear. AI development is moving beyond autocomplete and into agentic software engineering, where models can write, run, inspect, debug and test software with far less human intervention at every individual step.
That does not make the engineer irrelevant. If anything, it pushes the job toward the parts that were always hardest to automate: deciding what should be built, designing the architecture, understanding trade-offs and determining whether the result can actually be trusted.
Code is becoming cheap to produce. Good engineering judgment is not.
The future developer may therefore spend far less time typing every line into an editor, but considerably more time directing systems, reviewing decisions and making sure that whatever the AI built is something people should actually run.
Comments 0