“I would have written a shorter letter, but I did not have the time.” — Blaise Pascal

Because of AI, everyone on your team is more productive than they were a year ago, just ask them. So why isn’t the company itself faster?

I think I know why.

Let’s say an engineer needs to write a tech brief for a database migration. Two years ago, this would’ve cost him an entire afternoon: reading the code and some articles online, weighing the options, writing, deleting, rewriting. The result was short, and every word of it had survived contact with his brain.

Fast forward to today, and he pastes the context into a model and hits send. A few minutes later, the agent hands back a plan several times longer than anything he would’ve written by hand.

Well, he’s more productive now, right? A fraction of the time, many times the output. But what about everyone else? A handful of reviewers open a document several times longer than it needs to be, with that unmistakable AI smell on it.

And the length is not the biggest concern! Given that the doc was clearly AI-generated, every reviewer is now also fact-checking the thing. The brief says the current job processes events sequentially. Does it, though? It says the migration touches nine tables. Is it nine? When a colleague writes a sentence like that by hand, you trust it, because someone counted and put their name on the count. When a model writes it, and the author didn’t check, the sentence looks exactly the same. You can’t tell which claims he stands behind and which ones the model dreamed up, so you have to treat every single line as unverified. The reviewers end up doing the thinking the author skipped (except this time it arrives nicely formatted, and with confidence ).

So every one of those reviews now takes longer than it used to. He saved himself the afternoon and quietly spent everyone else’s. The time was just transferred, and because a document has one writer and many readers, one person’s shortcut becomes everyone else’s problem.

You see, a document is supposed to be a service. The (implicit) deal is that the writer spends their time so the readers don’t have to. It’s why Pascal, in that quote at the top, was apologizing: the long letter is cheap for me and expensive for you, the short letter is expensive for me and cheap for you. At the workplace, I usually owe you the short one because there’s one of me and many of you. Compression, editing, and fact-checking are the work.

By the way, it’s not just documents… I’m also seeing the same pattern in pull requests, automated tests, and even decisions. We’re going faster by passing the slow part (the reading, the actual understanding) to whoever comes next. A Ponzi scheme?

Don’t get me wrong: by all means, do use AI. I do too, and I’m (probably) not going back. The thing is: the model is giving you many hours back, so please spend a bit of them editing!

I already have a rule for AI-written code: if I can’t explain the change, I can’t ship it. The same rule applies here: if you can’t defend a sentence with the document done, it’s not really done, is it?

And if you’re on the receiving end of these, you’re allowed to push back and say: “This reads like an unedited draft. Can you cut it down to the decision, the tradeoffs, and what you need from me? Happy to review it then.”

---

So that’s why the company never speeds up, even when everyone in it does. The time that the engineer saved didn’t go anywhere good: it landed on everyone who had to read his document.

And again, he’s not lying when he says he’s faster. He is. So am I, most days. The speed is very much real for each of us individually. It’s just that when you add it up across the team, it points the wrong way; everybody’s faster, and the whole thing somehow moves slower.

Which makes me think we owe the people reading us a bit more than we’ve been giving them lately.

MSBuild binary logs (.binlog files) contain a wealth of information about your build — every property evaluation, target execution, task invocation, error, and warning. But navigating that data manually can be overwhelming, especially when you’re debugging a complex multi-project solution. What if your AI coding assistant could do the investigation for you?

Today we’re introducing the Microsoft Binlog MCP Server, a Model Context Protocol (MCP) server that gives AI assistants like GitHub Copilot direct access to your build logs. It parses .binlog files and exposes 15 specialized tools that enable AI-driven build failure diagnosis, property tracing, performance analysis, and build comparison — all through natural language conversation.

Why MCP for Build Logs?

The Model Context Protocol is an open standard that lets AI assistants call external tools in a structured way. By wrapping MSBuild binary log analysis in an MCP server, we give AI assistants the ability to:

• Investigate build failures by querying errors, warnings, and their full project/target/task context
• Trace property origins to understand where a property got its value
• Analyze performance bottlenecks by identifying the slowest projects, targets, and tasks
• Compare two builds to spot differences in properties and packages
• Read embedded source files captured during the build

Instead of manually scrolling through the MSBuild Structured Log Viewer, you can simply ask your AI assistant questions like “Why did my build fail?” or “What’s making my build slow?”

15 Tools at Your AI Assistant’s Disposal

The Microsoft Binlog MCP Server provides tools organized into four categories:

Build Investigation

Tool	What It Does
binlog_overview	Build status, duration, project count, error/warning counts
binlog_errors	Build errors with full project, target, task, file, and line context
binlog_warnings	Build warnings, filterable by warning code
binlog_search	Full-text search using the StructuredLog Viewer search DSL
binlog_projects	List all projects with build status and duration
binlog_properties	MSBuild property values (curated defaults or filtered)
binlog_items	MSBuild items like PackageReference, Compile, and more
binlog_imports	Full import chain of .props and .targets files
binlog_explain_property	Traces where a property gets its value — which file, target, or task set it

Embedded Files

Tool	What It Does
binlog_files	List or read source files captured during the build
binlog_search_files	Search text across all embedded source files

Performance Analysis

Tool	What It Does
binlog_expensive_projects	Slowest projects by exclusive duration
binlog_expensive_targets	Slowest targets across the entire build
binlog_expensive_tasks	Slowest tasks across the entire build

Build Comparison

Tool	What It Does
binlog_compare	Diff two binlogs — compare properties, packages, and more

Getting Started

The easiest way to get started is through the .NET Agent Skills repository. The dotnet-msbuild plugin bundles the Microsoft Binlog MCP Server along with curated skills and agents for MSBuild build investigation and optimization. Pick the section below that matches your development environment.

Visual Studio

Visual Studio supports MCP servers through GitHub Copilot’s agent mode (Visual Studio 17.14 or later). After installing the dotnet-msbuild plugin, the Microsoft Binlog MCP Server is automatically discovered by Copilot Chat in agent mode. Open the Copilot Chat window, switch to Agent mode, and the binlog_* tools become available for any conversation about a .binlog file in your solution.

Visual Studio Code

In VS Code, enable plugin support and add the marketplace to your settings.json:

{
  "chat.plugins.enabled": true,
  "chat.plugins.marketplaces": ["dotnet/skills"]
}

Then install the dotnet-msbuild plugin from the marketplace — the Binlog MCP Server is configured automatically.

Prefer to wire up the MCP server directly? Add it to your .vscode/mcp.json:

{
  "servers": {
    "binlog-mcp": {
      "type": "stdio",
      "command": "dotnet",
      "args": ["tool", "run", "Microsoft.AITools.BinlogMcp"]
    }
  }
}

To pre-load a specific binlog at startup, pass the --binlog argument:

{
  "servers": {
    "binlog-mcp": {
      "type": "stdio",
      "command": "dotnet",
      "args": ["tool", "run", "Microsoft.AITools.BinlogMcp", "--", "--binlog", "msbuild.binlog"]
    }
  }
}

Command Line (Copilot CLI / Claude Code)

For terminal-based AI assistants such as GitHub Copilot CLI or Claude Code, install the plugin directly from the dotnet/skills marketplace:

/plugin marketplace add dotnet/skills
/plugin install dotnet-msbuild@dotnet-agent-skills

Restart your assistant and the binlog_* tools are ready to use. You can verify they loaded with /skills.

Example: Diagnosing a Build Failure

Once the MCP server is running and your AI assistant has access to a .binlog file, you can investigate build issues conversationally.

Here’s a typical workflow:

1. Generate a binlog: Run dotnet build /bl to capture a binary log
2. Ask your assistant: “My build failed. Can you investigate msbuild.binlog and tell me what went wrong?”
3. The AI investigates: It calls binlog_overview to get the high-level status, then binlog_errors to retrieve the actual errors with full context, and may use binlog_explain_property or binlog_search to trace the root cause
4. Get actionable guidance: The assistant synthesizes findings and suggests concrete fixes

For performance investigations, the AI uses the binlog_expensive_projects, binlog_expensive_targets, and binlog_expensive_tasks tools to identify bottlenecks and recommend optimizations.

The screenshot below shows this workflow in action inside VS Code.

Try It Yourself: Compare Two Builds

Here’s a great way to take the MCP server for a spin right now. Pick a repository you build regularly — your own product, or an open-source project like dotnet/msbuild or microsoft/testfx — and capture two binary logs from different versions or configurations:

# Build version A
git checkout main
dotnet build /bl:build-a.binlog

# Build version B (a different branch, SDK, or configuration)
git checkout my-feature-branch
dotnet build /bl:build-b.binlog

Then ask your AI assistant:

“Compare build-a.binlog and build-b.binlog. What MSBuild properties and package versions changed, and did any of those changes affect build performance?”

Behind the scenes, the assistant calls binlog_compare to diff properties and packages, then uses binlog_expensive_projects and binlog_expensive_targets on both logs to correlate the changes with timing differences — turning what used to be a tedious side-by-side log comparison into a single conversation.

Built on StructuredLogger

Under the hood, the Microsoft Binlog MCP Server uses the MSBuild Structured Log Viewer library — the same engine that powers the popular MSBuild Structured Log Viewer desktop app. The binlog_search tool supports the full StructuredLog Viewer search DSL, including node type filters ($error, $warning, $task, $target, $project), hierarchical scoping with under(), and exact phrase matching with quoted strings.

Telemetry

The server emits anonymous usage telemetry (tool name, latency, result size, success/failure) to help us improve the product. It follows the standard .NET SDK approach: on by default, single opt-out via the DOTNET_CLI_TELEMETRY_OPTOUT environment variable.

export DOTNET_CLI_TELEMETRY_OPTOUT=1

No binlog content, file paths, or raw error messages are ever collected — only filenames are HMAC-SHA256 hashed for correlation.

What’s Next

The Microsoft Binlog MCP Server is in preview and we’re actively improving it. We’d love your feedback — please file issues in the dotnet/skills repository.

If you’re working with MSBuild builds and using AI coding assistants, give it a try. Let your AI do the heavy lifting of build investigation while you focus on writing code.

The post AI-Powered MSBuild Investigation with the Microsoft Binlog MCP Server appeared first on .NET Blog.

Replit is now available directly inside Claude, making it easier than ever to go from a conversation to a fully built, shipped product - without losing context, in one seamless workflow. Design in Claude, Build in Replit You can now design on-brand, beautiful apps in Claude Design using natural language. Once your design is ready, send it directly to Replit to continue building, refining, and shipping your app—all through natural language and in one seamless workflow. No copy-pasting, no context switching, no friction. Delegate Any Task to Replit

Although Wall Street loves AI, every day Americans are significantly less optimistic about the industry, a new report from Pew Research shows.

Epic Games has released Lore, an MIT-licensed version control system written in Rust and designed specifically for "games and entertainment purposes with large file sizes," reports Phoronix. From the report: While there is Git LFS for large file storage with Git, Epic Games has crated Lore as a version control system designed entirely around the large file needs of modern game development as well as multimedia/entertainment purposes. Lore is designed to be fast and efficient for large files including binary files, and be easy-to-use including for 3D artists and more. The Lore documentation elaborates more on its differences and motivation for development compared to Git: "No existing system was designed for the combination of constraints that large game and entertainment projects require: arbitrary content types, multi-axis scale, multi-tenant safety, and a fully open specification and license. [...] Lore is designed to combine what works in each (Git's content-addressed revision graph and centralized systems): a centralized server-of-record for durability, access control, and conflict resolution; content-addressed storage with fragment-level deduplication that is as effective on a multi-gigabyte binary as on a kilobyte of text; sparse, lazy working copies that materialize only what you need; free branching; and a fully open, publicly versioned specification and MIT license. Normal editing operations -- staging, committing, branching, diffing -- never require a network round trip." You can learn more at Lore.org. All the code is available on GitHub.

Read more of this story at Slashdot.