Mark Downie - PoppaString

Old Protocols, New Pipes

Tue, 07 Apr 2026 01:03:51 GMT

I built an MCP server this week. Not a toy exactly, not even a proof of concept; I wanted a working tool that lets a Copilot agent publish blog posts to a twenty-year-old blogging engine: thirteen tools, an XML-RPC client, multi-blog profile support, credential persistence, and auto-discovery of blog APIs. I built the whole thing in a single session with GitHub Copilot, describing what I wanted more than typing code.

The DasBlog Core blogging engine is an open-source project I've maintained and upgraded for years. It speaks MetaWeblog, Blogger, and Movable Type APIs over XML-RPC, protocols designed over 20 years ago so that desktop clients like Open Live Writer could talk to blog servers.

The Model Context Protocol was published in 2024 so that agents could actually use tools. The MCP server I built sits between the agent and my blog. It translates natural language requests from an agent into XML-RPC calls that DasBlog knows how to respond to.

DasBlog was never designed for this. Nobody writing XML-RPC handlers in 2003 was imagining that an AI would one day call metaWeblog.newPost on behalf of a human having a conversation in a terminal or an IDE. Here is what that bridge looks like:

public async Task&lt;string&gt; CreatePostAsync(BlogPost post, bool publish)
{
    var postStruct = Struct(MapFromPost(post));
    var result = await Rpc.InvokeAsync("metaWeblog.newPost",
        Str(Profile.BlogId), Str(Profile.Username), Str(Profile.Password), postStruct, Bool(publish));

    return result.AsString();
}

A few lines of C# connecting a 2024 protocol to a 2003 API.

Anil Dash wrote a piece called "Codeless" earlier this year framing the current moment as the latest abstraction in a long history of letting developers focus on the problem rather than the plumbing. He makes a compelling case, and the part about putting power in the hands of product managers resonates with me personally as I have moved into a product role. But he also concedes something quietly:

"Codeless approaches are probably not a great way to take over a big legacy codebase, since they rely on accurately describing an entire problem, which can often be difficult to completely capture."

This is exactly where I started. The software I needed already existed. The interesting question is not whether AI can generate greenfield applications from a strategic plan. It is whether AI can connect what you already have to what comes next.

Greenfield is easy to demo. You describe a feature, the agents generate code, you "ship" it. But brownfield development is where I believe the real test lives. Brownfield means case-sensitive method names that will silently fail if you get the capitalization wrong. It means timezone conversion bugs buried in a refactoring that someone started and never finished 22 years ago. It means an API that has no deletePost method in one protocol but does in another, so your abstraction layer has to quietly delegate to a different client for that one operation.

I encountered all of these building this MCP server. Copilot helped me write the code, but the knowledge that made it work was mine: understanding how DasBlog stores entries, knowing that XML-RPC dateTime.iso8601 carries no timezone information, recognizing that the Movable Type API is additive. You cannot bridge what you do not know.

This is where I think the conversation about AI and software development overlooks the brownfield reality. The abstractions Anil describes are real and valuable. But an abstraction built over ignorance will not simplify things in the long term. It only hides complexity with indirection.

The twenty-year-old XML-RPC layer in DasBlog only became useful again because someone (me) understood what it did, knew why it existed, and how to connect it to something new. Copilot wrote most of the glue, but it could not know which pieces belonged together or that a bridge was needed.

There are tens of thousands of systems like DasBlog sitting in production environments right now. Internal tools, legacy APIs, department-level applications that do their jobs quietly and well. Scott Hanselman once called the people who build and maintain these systems dark matter developers, the unseen majority who are not chasing the latest beta but are getting work done with mature, well-understood technology.

They were not building for this moment, but many of them have structured interfaces, documented protocols, and stable systems. The real work now is in understanding what you have well enough to connect it to what has become possible.

Three New MAI Models

Sun, 05 Apr 2026 01:24:15 GMT

Microsoft announced three new first‑party MAI models this week, all available through Foundry. The releases cover transcription, voice generation, and image creation through Microsoft Foundry and the MAI Playground.

The transcription model (MAI‑Transcribe‑1) focuses on accuracy across a broad set of languages while running faster and cheaper than the usual options. The voice model (MAI‑Voice‑1) generates natural speech from very small samples. The model can produce a full minute of audio in about a second, and it does so with unusually efficient GPU use. If you want to check it out, try it in Copilot Audio Expressions.

MAI‑Image‑2 also improves image generation speed across Copilot and Foundry, delivering roughly twice the performance while keeping quality in line with previous models. Just ask Copilot (web or Windows) to generate an image and it will use MAI‑Image‑2 where available.

Microsoft is also pricing these models well below the usual market rates. Transcription at thirty‑six cents per hour is roughly a 40 to 60 percent savings compared to the typical dollar‑per‑hour services. Voice generation at twenty‑two dollars per million characters comes in at about half the cost of most high‑quality TTS models. Image output at thirty‑three dollars per million tokens is often 70 percent cheaper than comparable offerings from the major providers. The MAI lineup is clearly positioned as the lower‑cost option.

What stands out is not any single capability, but the shift in direction. Microsoft is building more of its own stack rather than betting everything on OpenAI. That shift, I assume, has deeper implications for cost, direction, and long‑term strategy. Even more significantly, each model was built by small team about 10 and tuned for efficiency, which seems to be the through‑line of this entire effort. Suggesting that high‑quality models no longer require massive research groups.

As a note, I do work at Microsoft, but I am not part of the team that develops these models.

We are still engineers

Fri, 06 Mar 2026 06:31:41 GMT

Steve Sanderson from the GitHub Copilot coding agent team walks through the techniques and mental models that make the Copilot tools feel like a genuine part of a new engineering process. He shows the newest Copilot CLI features, but for me, the real value is in the principles that still matter when everything around us is accelerating.

After sharing tools and techniques Steve talks about one of my core uncertainties, that is…

The sheer rate at which code is created ... who is going to read it? How do we know it is actually correct? I do not think this is a solved problem ... we do not know the answer right now.

Later he touches on how these tools are reshaping the physical act of writing software.

Something that bothers me a little bit is when I go back into my IDE and I start trying to write code with my actual fingers, like an animal, it is a weird experience for me now. I am not sure what buttons to press and I just look at my hands and think, make the code come out of them somehow, and I am not sure how to do it. Genuinely my muscle memory is starting to change in some way and I feel that when I want a load of code to come up on the screen I should say it in English. It feels weird to type it out now. I am not proud of that.
I do not think that necessarily is a great thing. I do not know what to do ... is it a problem or not? Do I need to do some daily manual exercises to keep myself sharp or something? Or is there no point? I honestly do not know ... I do not feel qualified to predict the future so I am not going to. Despite all these unknowns I do not think I would be willing to let anyone take this from me.

He returns to the oldest part of engineering, the part that has nothing to do with typing or tooling and everything to do with reasoning.

We are still engineers. Fundamentally we are still doing the same job. We are still using our brains to make decisions about how to solve problems. There is still an almost infinite space of possibilities for what you could actually build.

So even as world is accelerating, I keep coming back to the same truth. The responsibility to understand what we are building still rests with us. That is the part of the craft that no model can meaningfully duplicate. Download the the GitHub Copilot CLI and the Copilot SDK, and take some time to watch the entire AI-Powered App Development NDC keynote here.

Upgrading old code with Copilot

Fri, 27 Feb 2026 09:21:50 GMT

I finally did it! DasBlog Core has been officially upgraded to .NET 10! This is probably the single biggest release I've shipped, and it warranted a proper version bump. The truth is that I do all this work out of a deep, stubborn love for neglected software, but if I am honest I would not have had the time or energy to take this on without Copilot.

Prior to these LLMs and Agents code was expensive. Not just in dollars, but in time, in the accretive collection of knowledge, and the cognitive load required to hold a dozen patterns in your head just in getting started. For most of my career I felt this at a personal level too, limited by the fundamentals of my typing, taking deliberate steps just to improve my WPM. These constraints are gone. The cost of producing code has in some ways collapsed. This also means we no longer need to carry as much concern with getting it wrong the first time, because correcting has and will probably continue to get cheaper. Trying a new framework or stack is starting to become a trivial concern. The penalty for iteration is dropping precipitously.

Copilot accelerated what I consider the tedious parts of writing software, things like test coverage, non-critical bugs, and code consistency. It handled the scaffolding and the repetition of a UI framework upgrade while I could use my energy on the shape of the system, along with the philosophy and intent. That shift is not at all subtle. It changes where and for how long I need to focus, and what work I can do in parallel.

All that said, the future is fuzzy. We are going to be generating more and more code. I mean orders of magnitude more. The tools that help us generate code are improving faster than the tools that help us understand it, and the gap in understanding systems is where the real lag will be. I also found myself “writing” far more code but with much less direct connection to the detail. I relegated myself to a reviewer looking for patterns of neglect. Code was easier to produce, but also, presumably, easier for me to lose the thread of why it even exists. Code authorship has always mattered, but now it feels less central, and I find myself wondering what we lose when that connection fades.

With all this new code, and less direct connection to it, we need new ways of managing the scale. We need new ways of understanding what we have built. We need new tools for navigating and communicating the complexity. I imagine the difference will be as stark as the distance between assembly and C#.

I am saying all this but I am still optimistic. Some of the best ideas never made it far enough to be validated, they stalled out for lack of expertise or because they did not fit the incentives of venture capital. I for one will be happy to see those barriers collapse.

My hope, selfishly, is that Visual Studio remains the place where we are most comfortable improving performance. That it becomes the place where you handle brownfield development, where you test code, where you understand how the system behaves under real constraints. My hope, selfishly, is that Visual Studio remains the place where we are most comfortable improving performance.

Leadership from Birds

Mon, 26 Jan 2026 05:22:36 GMT

A colleague shared a newsletter with me titled The Shape of Leadership by Mike Fisher, here is an excerpt:

The V-formation is the one most of us are familiar with in organizations. It maps cleanly to how we think about leadership: someone sets direction, others align behind them, and progress is made through coordination and efficiency. Everyone knows where they’re going. Roles are clear. Responsibility is explicit. When it works, it’s a beautiful thing.

There’s a reason migrating birds use it. Flying long distances is expensive. Energy matters. Small inefficiencies compound over thousands of miles. The V-formation minimizes wasted effort by design. Each bird benefits from the work of the bird ahead of it, and the group as a whole goes farther than any individual could alone. In leadership terms, this is what strong alignment looks like. A clear vision reduces wasted motion. When people understand the destination and their role in getting there, they don’t have to guess. They don’t have to hedge. They can put their energy into execution instead of interpretation...

Murmurations, on the other hand, feel almost like the opposite extreme. There’s no visible plan. No clear leader. No stable shape. And yet, they are remarkably resilient. When a predator strikes, the flock doesn’t panic. It doesn’t wait for instructions. It responds instantly, each bird adjusting based on the movement of the birds nearest to it.

What’s fascinating is that murmurations aren’t chaotic at all. They operate on a small set of simple rules: maintain distance from your neighbors, match their velocity, and pay attention to sudden changes. That’s it. No bird has a global view of the flock, but the flock as a whole behaves intelligently.
This is what strong cultures look like.

Most corporate leaders do not choose the shape of their environments or their teams. They inherited them. They absorb the patterns that were in place long before they arrived, especially when those patterns have a history of success. The quiet assumption is that whatever worked in the past must be correct, so the inherited shape might go unchallenged. The problem though is that the conditions shift. The work shifts. Teams shift. Yet the shape of leadership often stays the same.

Systems, including the ways we lead, carry their own inertia, and they intuitively preserve whatever state produced success in the past. This is not a conspiracy or a character flaw. Success creates momentum, and momentum takes deliberate effort to redirect, especially when it is in service of finding and securing unrealized opportunities. It requires planning, patience, execution and a willingness to recognize when the moment has changed.

It comes back to culture

A team’s culture becomes most evident in what people do when no one is asking and no one is watching. It shows up in the choices made in unobserved moments, in the habits that persist without direction, and in the behaviors that surface when pressure is low (or indeed, high). What emerges in those moments is the real system, not the one written in documents or described in meetings. And if a team consistently falls back into a familiar V‑formation, even when unwarranted, it is usually because the culture has rewarded and reinforced that pattern over time.

Culture sets the boundaries of what feels acceptable, what feels risky, and what feels necessary. So when a team reverts to old patterns, when the intended formation collapses under pressure, or when outcomes fail to match stated values, it is the culture doing exactly what it was historically shaped to do.

Transforming culture is by no means easy. It is not a matter of slogans or revised instruction sets. It happens when teams practice different behaviors long enough for those behaviors to become the instinct. Meeting the moment requires leaders who can create the conditions where those new patterns can take root.

Color‑Driven Code Navigation

Thu, 22 Jan 2026 09:10:45 GMT

Color has become one of the most important tools in my daily development workflow.

When I am moving across dozens of solutions, projects, and file types, a consistent color system gives me instant orientation. Visual Studio has made this easier than ever with a combination of tab coloring by project rules, file extension patterns, regular expressions, and both solution level and user level themes. By leaning into a couple of simple color palettes I have built a visual map that helps me understand where I am in the codebase before I read a single file name or line of code.

Themes by Solution (and User)

When I am working with multiple solutions I use themes to associate colors with each solution. This gives me a top level color identity, a visual anchor that helps me recognize which codebase I am in before I read a single project name.

How do I do this? Visual Studio's Unified Settings feature allows me to save settings by user or by solution. Navigate to Tools > Options and select Environment > Visual Experience. To ensure this does not impact every instance, set Applies to Solution. This saves your preferences in the settings.VisualStudio.json file in the solution root directory.

Once you get into the IDE you have several options for tab organization that are worth experimenting with for project, file extension, and regular expression.

Tab Color – Project

Associating tabs with the project is especially helpful for solutions with more than half a dozen projects. The file name is not always enough context and hovering over a tab to figure out the root location is not always efficient. Color gives me a structural map, letting me see boundaries of responsibility within the solution at a glance. To update the default color of each project right click on the document tab and assign with Set Tab Color.

Tab Color - File Extension

For single project solutions I typically group by file extension. Extension based colors create quick, low friction cues that tell me what kind of work I am about to do the moment I open a file. To update the default color for, let’s say .cs files right click on the document tab and update it with Set Tab Color.

Tab Color - Regular Expression

My favorite and most versatile option is the use of regular expressions. It lets me surface patterns in folders, names, extensions, or a combination of all three. One of my favorites is assigning a distinct tab color for controllers in ASP.NET projects.

Controller\.cs$
^.*\.cs$
^.*\.fs$
^.*\.vb$
^.*\.json$
^.*\.txt$

This creates a ColorByRegexConfig.txt file in the .vs folder. After defining this file you can apply a specific color by right clicking on the tab and selecting Set Tab Color.

Color is not useful to everyone, but when it is available it can become a grounding part of your workflow. For me it is a small shift in how Visual Studio presents information, but it has a big impact on how quickly I can move through a codebase and find the work that matters most.

I Misunderstood Skills Entirely

Wed, 31 Dec 2025 08:54:29 GMT

I found this excerpt from Did Skills Kill MCP? really helpful:

Saying skills killed MCP is about as accurate as saying GitHub Actions killed Bash…
MCP is where capability lives. It’s what allows an AI agent to actually do things instead of just talking about them. When an agent can run shell commands, edit files, call APIs, query databases, read from drives, store or retrieve memory, or pull live data, that’s MCP at work. MCP Servers are code. They run as services and expose callable tools. If an agent needs to interact with the real world in any meaningful way, MCP is almost certainly involved.
For example, if an agent needs to query the GitHub API, send a Slack message, or fetch production metrics, that requires real integrations, real permissions, and real execution. Instructions alone can’t do that.
Skills live at a different layer. Skills are about process and knowledge. They’re markdown files that encode how work should be done. They capture team conventions, workflows, and domain expertise. A Skill might describe how deployments should happen, how code reviews are handled, or how incidents are triaged. This is institutional knowledge made explicit.

- Angie Jones,

I Miss Riding the Cuts

Tue, 23 Dec 2025 04:57:33 GMT

My brother gifted me a Diamond Back Ascent in the early 90s, I remember it was snowing when he dropped it off, but literally overnight the world opened up to me. My range expanded from the adjacent cul‑de‑sacs and estates to neighboring woods, forests, quarries, towns and cities. The roads were always narrow and never particularly safe, so I usually stuck to the pavements, which wasn’t technically allowed. In the end though, I found myself drawn to the local canal system, what we colloquially called the cut.

Back then I lived close to the Wyrley & Essington Canal which ran through the remnants of industries that had once relied on the delivery of cheap coal. The neglected towpaths always ran beside shuttered factories and half‑collapsed brickworks, and a mountain bike made easy work of the decay. Everyone seemed to know their local stretch of the cut, but the scale and interconnection of the national network wasn’t always obvious. I would ride for miles without seeing anyone, surrounded by a mix of green countryside and abandoned Black Country.

Some weekends I’d wake up early and follow the cut out toward Rough Wood, letting the narrow towpath guide me through the quiet stretches behind nearby estates while also reveling in the occasional curated canal facing private garden. It felt like a portal to another world, in fact it would be years before I even knew how to get to Rough Wood via car or public transport.

Every now and then I’d push farther to the west side of town toward Aldersley Stadium, now known as Wolverhampton & Bilston Athletics Club. The route was something I built slowly, threading together stretches of the Wyrley & Essington, the Old Main Line, and the Staffordshire & Worcestershire Canal. None of it was signposted or obvious. Looking back, I’m still not sure how I figured it out, it was just the path that emerged after enough weekends spent exploring the cuts.

During my time in Birmingham as a student at UCE (now Birmingham City University), I was often short of money for public transport, so I fell back on the canals to get me from one part of the city to another. Birmingham is said to have more miles of canal than Venice, but back then the comparison would have been purely academic, the network was rough, functional at best, and mostly overlooked. I would bike from my place in Moseley, south of the city, join the Grand Union Canal, follow it into the Birmingham and Warwick Junction Canal, and then take the Tame Valley Canal out toward Perry Barr on the north side. It was a quiet thread through a growing city, a route I stitched together systematically using old an AA Road Atlas, only slipping onto the congested streets when the towpath ended or had been reclaimed by the remnants of industry.

Of course a lot has changed since the 90s. The towpaths that were once muddy, uneven, and forgotten have been resurfaced and lit. The canals are now deliberate public spaces, and the transformation is even more striking in Birmingham. Warehouses have become apartments, factories have become cafés, and these once‑neglected corridors have shifted into a welcoming centerpiece. It’s hard to reconcile that with the rough routes I used to ride.

Today my wife and I walk and bike along our two rivers in Columbus, the Scioto and Olentangy, they converge conveniently in the heart of the city. It often brings the memory of those old canal rides back to me, while the cut may look different now, the sense of freedom they originally gave me hasn’t faded. They were the first places that let me move through a town on my own terms, and I’m eager to see how those old routes feel when I finally return to Birmingham.

Does the math work?

Thu, 04 Dec 2025 10:01:13 GMT

The Verge has delivered some of the year’s best interviews with a variety of tech CEOs, and this end‑of‑year conversation between IBM CEO Arvind Krishna and Nilay Patel may actually be my favorite. This quote on AGI in particular has me reflecting even more deeply on the scale of private AI investment:

So, let’s ground this in today’s costs because anything in the future is speculative. It takes about $80 billion to fill up a one-gigawatt data center. That’s today’s number. If one company is going to commit 20-30 gigawatts, that’s $1.5 trillion of CapEx. To the point we just made, you’ve got to use it all in five years because at that point, you’ve got to throw it away and refill it. Then, if I look at the total commits in the world in this space, in chasing AGI, it seems to be like 100 gigawatts with these announcements. That’s $8 trillion of CapEx. It’s my view that there’s no way you’re going to get a return on that because $8 trillion of CapEx means you need roughly $800 billion of profit just to pay for the interest. Arvind Krishna

This is a back of the napkin calculation but it assumes that this kind of large‑scale capital expenditure will be financed with debt. So a common rule of thumb is that you need ~10% annual profit relative to capital expenditure just to cover interest payments and keep the investment viable.

In my opinion that number makes the scale of the AGI challenge effectively insurmountable. For reference, in 2024, the combined profits of Microsoft, Alphabet, Amazon, Meta, NVIDIA, and Apple amounted to about $394 billion. That is still well below the $800 billion in annual profit required simply to service interest on the $8 trillion debt. The sustainability threshold implied here just seems overwhelming.

I read the interview but you can listen and watch the whole thing here.

An AI-orchestrated espionage campaign

Fri, 14 Nov 2025 07:34:16 GMT

Fascinating (frightening?) report from Anthropic describing how they eventually disrupted the first reported AI-orchestrated cyber espionage campaign.

In mid-September 2025, we detected suspicious activity that later investigation determined to be a highly sophisticated espionage campaign. The attackers used AI’s “agentic” capabilities to an unprecedented degree—using AI not just as an advisor, but to execute the cyberattacks themselves.
The threat actor—whom we assess with high confidence was a Chinese state-sponsored group—manipulated our Claude Code tool into attempting infiltration into roughly thirty global targets and succeeded in a small number of cases. The operation targeted large tech companies, financial institutions, chemical manufacturing companies, and government agencies. We believe this is the first documented case of a large-scale cyberattack executed without substantial human intervention.

Quick aside: The phrase ‘state‑sponsored group’ may sound novel, but history shows otherwise. During the era of maritime exploration, governments issued licenses to privateers who raided enemy trade. They were not formal navies, yet they sailed under state authority and operated in the space between national policy and private agency. One of the most famous British privateers was Sir Francis Drake, commissioned by Queen Elizabeth I to raid settlements and shipping in the Americas. To the Spanish he was simply a pirate.

The barriers to performing sophisticated cyberattacks have dropped substantially—and we predict that they’ll continue to do so. With the correct setup, threat actors can now use agentic AI systems for extended periods to do the work of entire teams of experienced hackers: analyzing target systems, producing exploit code, and scanning vast datasets of stolen information more efficiently than any human operator. Less experienced and resourced groups can now potentially perform large-scale attacks of this nature…
This raises an important question: if AI models can be misused for cyberattacks at this scale, why continue to develop and release them? The answer is that the very abilities that allow Claude to be used in these attacks also make it crucial for cyber defense. When sophisticated cyberattacks inevitably occur, our goal is for Claude—into which we’ve built strong safeguards—to assist cybersecurity professionals to detect, disrupt, and prepare for future versions of the attack. Indeed, our Threat Intelligence team used Claude extensively in analyzing the enormous amounts of data generated during this very investigation.

Artificial intelligence carries immense promise, yet it clearly brings risks familiar from earlier technology breakthroughs. When nuclear weapons emerged, nations had to confront a technology that could deter conflict while holding the power to devastate the world. While these present threats are not existential, AI presents a similar paradox. It can drive progress and solve problems, yet it can, in a very real sense, be turned against us. The issue is not whether AI is good or bad, but how we choose to govern its use.

Private AI Investment is on a GDP-Scale

Sat, 08 Nov 2025 10:04:05 GMT

Like you, I’ve been blown away by the projected capital investments in AI. The only way I can wrap my head around the numbers is to anchor them to something more tangible in recent history. I keep coming back to the Interstate Highway System, which, adjusted for inflation, cost over $600 billion. Spread over multiple decades (since 1956), its annualized impact was roughly 0.10% of U.S. GDP.

By contrast, moderate projections are at over $1 trillion (with a “T”) for AI investment deployed over the next 10 years, which clocks in at 0.40% of GDP annually. That’s four times the relative scale, compressed into a fraction of the time. This is bigger, faster, and more concentrated. The Interstate was a slow, deliberate public investment with obvious and predictable returns (in hindsight). To sense the scale of impact consider that Interstates make up about 1–2% of U.S. road miles but carry a disproportionate share of vehicle travel (roughly 20–30% of total vehicle‑miles traveled), and this number is substantially larger for heavy‑truck and freight miles. AI investment, by comparison, is a flash flood of private capital. Its sheer velocity demands a different kind of analysis, and no matter how I crunch it, it is difficult to see how all this investment pays off.

If AI investments deliver on its promise, we’re looking at a potential GDP uplift ranging from 0.20% to 0.80% annually. Those might sound like small numbers, but they represent a tectonic shift. Still, that multiplier isn’t automatic. It hinges on diffusion i.e. how quickly AI tools reach and reshape small firms, public services, and lagging sectors. That’s why you’re seeing companies push AI into every nook and crevice of their operations. It’s why executives are predictably shoehorning and measuring the use and value of AI-infused workflows in the most inorganic ways.

The United States is, by deliberate policy, a service-driven economy. Services account for the overwhelming majority of it’s GDP, and that structural reality raises the stakes for AI adoption. Unlike past waves of capital investment that primarily transformed manufacturing or physical infrastructure, AI is positioned as a direct force multiplier for our critical service work infrastructure. Gains in information processing, decision support, customer interaction, and back-office automation translate immediately into productivity where most of our economic value is created.

If the U.S. wants to remain the world’s leading service economy, it cannot afford to lag in AI adoption and diffusion. Other nations must see the same opportunity and are racing to embed AI into finance, healthcare, logistics, and professional services. Adopting AI has become the foundation of maintaining leadership in the very sectors that define the US economy.

Define a default startup project in your slnx file

Thu, 23 Oct 2025 06:22:31 GMT

Earlier this year we introduced SLNX, an XML-based solution file format that replaces the old, proprietary .sln layout with a much more concise, readable XML representation. It preserves the same solution data by folding common defaults into the format so files are smaller and easier to inspect and merge while retaining full build behavior. Tooling support is already available in Visual Studio and the dotnet CLI, however, our plan is to make this the default experience for Visual Studio 2026 forward.

One legitimate complaint is that the format does not inherently support ordering, more specifically, you could not define the start up project (you can in Visual Studio but it gets saved in your personal .suo file).

The immediate fix we applied is deliberately simple and explicit: add a DefaultStartup="true" attribute to the project element you want to launch first.

&lt;Solution&gt;
  &lt;Project DefaultStartup="true" Path="ConsoleApp1/ConsoleApp1.csproj" /&gt;
  &lt;Project Path="SomeTestSolution/SomeTestSolution.csproj" /&gt;
&lt;/Solution&gt;

That attribute is applied by the solution model at load time so Visual Studio treats that project as the default startup on first open, while existing .suo state continues to take precedence for individual developer environments.

Here’s how to turn off Copilot

Sun, 21 Sep 2025 06:13:39 GMT

Every time I talk about Copilot, its value, its impact, the way it can improve a developer workflow, someone jumps in with the complaint: “Just let me switch it off.” As if they’re somehow locked into a tool they didn’t choose. Let’s be clear. You’ve always had the option to disable it. You can remove it entirely. And now, you can fine-tune exactly how and when it shows up.

So this is the post I’ll point to every time someone insists they’re stuck with Copilot. If you genuinely can’t use the tool or simply don’t want to, here’s how to turn it off

Switch off Copilot in Visual Studio:

Launch the Visual Studio Installer by selecting Tools > Get Tools and Features from the Visual Studio menu.

In the Visual Studio Installer, select the Individual components tab. In the search box, type "copilot" to locate the GitHub Copilot component.
Uncheck GitHub Copilot, GitHub Copilot Chat, GitHub Copilot Completions to remove it from your VS installation.
Click the Modify button to apply the changes. This will uninstall GitHub Copilot from your Visual Studio instance.
Restart Visual Studio

That’s it, really simple.

Reducing Interruptions from Copilot

Maybe you do not need to switch off Copilot, you just might prefer a quieter workspace while deep in thought. Then Visual Studio offers streamlined options to help you stay immersed in your code and get the level of assistance that matches your style or task. Your options include:

No completions while typing.
Only receive code completions when you request it.
Hide next edit suggestions and only preview when you are ready.

For more details on how to control Copilot please check out this post, Better Control over Your Copilot Code Suggestions.

Ok, now let me get this off my chest…

There is a kind of knee-jerk rejection that shows up whenever I suggest AI tools, not specifically Copilot, might be remotely helpful to some segments of the developer population. There is a very vocal minority that can see no inherent value in AI for anything. Some people treat my reaction to AI the way I treat excitement around crypto. With skepticism and doubt. Meanwhile I see thousands of developers using AI daily and getting valuable stuff done.

Now, I do think it is important to recognize concerns about the environmental impact of LLMs, I also support promoting and supporting ethically sourced datasets with fair compensation for authors and artists. However, most of the critiques I receive fail to reflect our current reality. AI brings real utility and continues to reshape developer tools, but criticism often reduces anyone who sees even a glimpse of value to a corporate shill.

Despite all this, developers continue to adopt Copilot (and other AI tools) at an extraordinary pace. That said, if AI features aren’t serving your workflow you should absolutely have the freedom to turn them off. But if you dismiss this all as hype or just a passing trend, you might be overlooking what’s actually driving this shift.

Anyway this is my “taps the sign” blog post on this topic.

Visual Studio Insiders

Wed, 10 Sep 2025 08:19:11 GMT

With the launch of Visual Studio 2026 Insiders, our team is embracing the reality of a rapidly evolving developer landscape head-on. That’s why with the launch of Visual Studio 2026 we’ve introduced a new release cadence designed for developers who move fast, iterate quickly, and expect their tools to keep pace.

Insiders Channel

The Insiders Channel delivers monthly updates packed with experimental features, performance upgrades, and UI innovations. It’s where we test for the future. The Insiders Channel replaces the "Preview Channel" that was available with Visual Studio 2022. This channel will be the first to receive experimental features like Copilot integrations, UI redesigns, and performance upgrades. Monthly cadence ensures fast feedback loops and continuous refinement. Side-by-side install with other channels is still supported, so you can test without disrupting your primary workflow.

Stable Channel (coming later this year)

The Stable Channel will eventually replace the "Current Channel" that was available with Visual Studio 2022, features will flow into the Stable Channel after being available in the Insiders Channel. The Stable Channel will be available when Visual Studio 2026 becomes generally available. Even if you're on the Stable Channel, you can still explore upcoming capabilities through Preview Features. Unlike the Insiders Channel, Preview Features let you toggle individual experiments on or off at your discretion. Just head to Tools > Manage Preview Features to browse the list.

LTSC - Long-Term Servicing Channel (coming later this year)

While the Insiders and Stable Channels focus on velocity and continuous improvement, Long-Term Servicing Channel (LTSC) is built for those who need their development environment to remain steady and dependable over time. We’re planning to introduce a Long-Term Servicing Channel (LTSC) specifically for developers using the Professional, Enterprise, and Build Tools editions of Visual Studio 2026. More details on availability and servicing timelines will be shared soon. In the meantime, we encourage developers to explore the Insiders Channel to preview what’s coming.

I am excited for what’s ahead, and we’re building Visual Studio to help this generation of developers meet this uncertain future.

Prioritizing your backlog

Fri, 05 Sep 2025 07:04:28 GMT

The Product Managers I attempt to emulate aren't just juggling timelines and features, they are constantly finding throughlines in ambiguous spaces and aligning competing interests to ensure that the product's core intent is delivered. This prioritization process isn’t just about ranking tasks, it’s also about choosing what not to build, what not to pursue, and where we can never afford to compromise. At its core, product leadership means asking:

What creates real value now?
What builds strategic advantage later?
What’s noise, distraction, or legacy baggage we need to avoid?

Recognizing what qualifies as noise takes time, experience and a health dose of intuition, but in the meantime, frameworks like ICE (Impact × Confidence × Ease) or RICE ([Reach × Impact × Confidence] ÷ Effort) can help cut through the clutter. Think of engineering focus as your most limited and precious resource. Product Managers must act as its steward, guarding, curating, and directing it in defense of your most important objectives.

MCP server integration in Visual Studio

Tue, 22 Jul 2025 03:52:58 GMT

I’ve been tinkering with MCP server support in Visual Studio recently, and the latest improvements have helped a bunch. Firstly, you can set up your integration in the IDE, which of course, is entirely the point of a good IDE. I am going to run through the steps of adding the GitHub MCP server.

Set Up a GitHub MCP Server

Add an mcp.json file to your solution or PC, Visual Studio will detect it automatically in the following locations:

[SOLUTIONDIR]\.vs\mcp.json [Visual Studio only, for the specified solution]
[SOLUTIONDIR]\.mcp.json [Tracked in Source Control]
[SOLUTIONDIR]\.vscode\mcp.json [Supports VS Code and is scoped to the solutions]
%USERPROFILE%\.mcp.json [Global MCP server configuration, applies to all Visual Studio solutions]

Add the following text to the json file at your selected location:

{
  "servers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

Immediately open in Visual Studio (if you are using 2026 it should be super fast). The positive thing about Visual Studio is that it allows you to start and generally manage MCP servers directly with CodeLens controls which allows you to restart and reconnect to this MCP server (note that you need :

The first time you try this the CodeLens will make it clear that Authentication is required and will show a popup allowing you Revoke Access or, more appropriately Authenticate. Seamless authentication was top of mind and so keychain support is baked into the process meaning Visual Studio will pull your credentials for supported MCP servers, today that includes GitHub and Entra ID with more OAuth providers to follow. This is much easier, no more passing and potentially fumbling with tokens from your GitHub settings.

Use Your MCP Servers

When you open the Copilot Chat panel, look for the Tools dropdown. There you’ll find your connected MCP servers waiting. My advice is to only select the MCP servers you actually plan to use, there is an upper limit. Hit the arrow to expose a fresh menu, manage your server inputs in the new modal dialog, and watch Copilot pull in project context from your select GitHub repository (or indeed all public repositories).

Note, make sure you’re in Agent Mode (or @ reference the agent while in Ask Mode), this is the only way to talk to, and take action on, your MCP servers from Copilot Chat.

New LLMs for Visual Studio

While I am on this topic it is worth mentioning that Claude Sonnet 4 and Claude Opus 4 are now generally available in Visual Studio, offering enhanced and alternate AI capabilities. I would suggest testing Claude Sonnet 4 in Agent Mode for faster, more focused interactions. Try either Claude Sonnet 4 and Opus 4 in Ask Mode for deeper reasoning of coding issues. However, I would suggest taking a look at the pricing for premium LLMs, Claude Opus 4 is currently 10x more expensive than Claude Sonnet 4.

We’re rapidly approaching the point where picking the right LLM for the task, and the budget, requires its own kind of planning and resource deployment strategy. What, for example, would be more effective: a $200/hour veteran software engineer using a standard model, or a $75/hour rookie armed with a top-tier LLM? My guess is that it will always depend on the situation, but either way, the terrain ahead demands not just adaptation, but a reimagining of how we learn, work, and collaborate alongside with our new crop of tools.

Note: Content updated on November 11th

When LLMs Remember Instead of Reason

Fri, 18 Jul 2025 02:33:24 GMT

SWE-Bench Verification asserts to be ahigh-quality, human-validated subset of the SWE-Bench benchmark designed to assess LLMs on real-world code-fixing tasks. It comprises several 100 issues, each drawn from public GitHub repositories and confirmed by experts to ensure accuracy. I've admittedly relied heavily on SWE-Bench scores to assess LLM performance without critically examining the benchmark's themselves. It's the kind of passive acceptance of data I'm consciously working to move away from in multiple areas of my life.

I found it fascinating then that a colleague, Roshanak Zilouchian, chose to explore the question of how much trust we can place in coding benchmarks. The findings raise important questions about whether current benchmark scores truly reflect generalizable programming abilities. Here is a link to their paper (THE SWE-BENCH ILLUSION: WHEN STATE-OF-THE ART LLMS REMEMBER INSTEAD OF REASON) and an excerpt from the abstract:

Recent LLMs show impressive performance on SWE-Bench, leading to optimism about their capacity for complex coding tasks. However, current evaluation protocols may overstate these models’ true capabilities. It is crucial to distinguish LLMs’ generalizable problem-solving ability and other learned artifacts … We present empirical evidence that performance gains on SWE-Bench-Verified may be partially driven by memorization rather than genuine problem-solving. We show that state-of-the-art models achieve up to 76% accuracy in identifying buggy file paths using only issue descriptions, without access to repository structure. This performance is merely up to 53% on tasks from repositories not included in SWE-Bench, pointing to possible data contamination or memorization … These findings raise concerns about the validity of existing results and underscore the need for more robust, contamination resistant benchmarks to reliably evaluate LLMs’ coding abilities.

My super pithy take away is as follows:

Models may be recalling specific training examples rather than genuinely reasoning through problems.
Reported gains on SWE-Bench might be overstating the true reasoning capabilities.
High benchmark scores may reflect dataset contamination and biased exposure rather than robust coding skills (when you already know the answer is “C” your hardly need to read the question).

In the rush of rapid advancement, it's easy to overlook that today’s evaluations of LLMs in software engineering urgently require rigorous, contamination-resistant benchmarks, ones that truly test for generalization, not just memorization.

Solving for the last mile

Thu, 05 Jun 2025 09:04:39 GMT

Paul Ford on the The Extremely Human Last Mile:

I think the answer is actually really simple, and it’s something I keep mumbling to myself: AI is great at the first mile because it seems human, but bad at the last mile because it’s not human.
First-mile tasks include “writing a summary,” or “looking for interesting companies in the cannabis space” or “reviewing inbound emails and classifying them in the CRM” or “finding the right SaaS tool for my church-membership drive” or “listing the kind of software components my new online hat store needs”—and for all of these, LLMs often work surprisingly well. They simulate basic human skill sets to differing degrees of talent, and they’re fast, too.
But then there’s the last mile. That includes “launching the app at the same time the marketing campaign rolls out in four languages” or “finishing the five-hundred-thousand line migration from COBOL to Java“ or “completing the oral defense of your PhD thesis.” This set of skills might be in reach of AI, but I don’t buy it yet.

The last mile analogy is nearly perfect! While self-driving on highways is generally the most predictable and structured scenario for autonomous vehicles challenges abound in the final leg of the journey. Parking in the right spot on a private driveway or navigating those unpredictable pedestrians or a traffic cop waving you through a red light. In these moments, context takes precedence over rigid rules, demanding flexibility and intuition that favor humans over our nascent crop of agents. If you're in the business of creating AI products, identifying the environments where this generation of agents can truly excel is the key to driving meaningful customer success.

Updates from BUILD 2025

Sat, 24 May 2025 08:32:02 GMT

For me, this year's BUILD was all about sharing a vision for how the end-to-end developer experience will evolve in the coming years. Naturally, AI was at the center of this discussion, but at its core, we are exploring the tools developers need to not only harness AI but also create even better tools with it in the near future. Jay Parikh, our new EVP of Core AI, shared news focusing on the vital role developers play in helping enterprises successfully embrace AI and digital transformation. One of our key tenets that I was personally pleased to hear articulated is the embrace of openness and choice, recognizing the rapid pace at which this space is evolving.

My aim for this post is a simple one: to highlight key developer updates from Build 2025, including the latest advancements in Visual Studio, VS Code, .NET, and Microsoft Dev Box, as well as must-watch sessions covering AI, development efficiency, and performance optimization. I hope this is helpful.

Visual Studio

Visual Studio 2022 17.14 now generally available
Agent Mode has arrived in preview for Visual Studio

VS Code

Beyond the tool, adding MCP in VS Code
VS Code for the Web - A zero-install, browser-based development environment that enables you to run, debug, and deploy applications to Azure

.NET

.NET ships new GA and preview functionality at Build 2025
Seamlessly upgrade and modernize .NET & Java codebases with GitHub Copilot (or Accelerate Your .NET Upgrades with GitHub Copilot)
.NET Aspire 9.3 is here and enhanced with GitHub Copilot
Official C# MCP SDK - Available in Preview

Microsoft Dev Box

New AI-powered features in Microsoft Dev Box

Favorite Sessions

A Kind of Blue

Sat, 17 May 2025 08:12:09 GMT

I mostly run the 17.x preview version of Visual Studio which means I have also being using the earliest release of Fluent UI Refresh experience. Note: Fluent is now on by default for Visual Studio 2026+.

The new themes are inspired by Microsoft Edge and has what our designers call a “tinted” appearance, this gives us access to a new look beyond the rudimentary Dark, Light (and Blue) theming. Here is the list of themes available as of today:-

Light
Dark
Bubblegum
Cool Breeze
Cool Slate
Icy Mint
Juicy Plum
Mango Paradise
Moonlight Glow
Mystical Forest
Silky Pink
Spicy Red
Sunny day

I love the names, but do note there is no Blue theme, and that ultimately comes down to our focus on three pillars: cohesiveness, productivity and accessibility. To put this simply the Blue theme simply did not meet our accessibility standards, so while I imagine there will be an alternative on the market place I am not expecting it to be official. That said I am personally digging Cool Breeze, and Moonlight Glow more than adequately fills my gap for a kind of blue.

If you’re looking to bring a touch of blue into your editor, here are a couple of themes worth trying:

A Kind of Blue Theme Pack — Contains three calm, jazz-inspired themes.
Blue Steel — A sharper, cooler take on blue tones.

I hope this helps.

Updated: 11/27/2025