u/riturajpokhriyal

the author is a model session that closed an hour ago. the PR description was written by the same agent that wrote the code so it covers the happy path and skips the wrong turns. PRs where the description doesn't match the diff take 3.5x longer to merge.

we started requiring git trailers on AI commits. pre-commit hook rejects anything flagged AI-generated without an AI-Prompt-Summary field. one line. what was the agent actually asked to do. three months later when something breaks you have a starting point instead of a cold diff.

for agents running in CI we also write a small session record: task, files it expected to touch, whether tests passed. commit it with the code.

review becomes a completely different job when that trail exists. you stop asking what this code is and start asking whether it did what it was supposed to. way faster.

anyone actually enforcing this or does your team just wing it?

spent two years creating PRs in visual studio and then opening a browser to review them. 18.7 (stable, june 9) finally does review + comment + approve in the IDE for github and azure devops.

everyone's leading with "no more browser" but the part that actually changed my workflow is you can review a PR without checking out the branch. no stash, no fetch, no switch-back-and-unstash. your working tree just sits there while you read someone else's diff.

wrote up the workflow stuff plus where the browser still wins (branch policies, huge diffs, and the PR activity timeline that's literally still on their roadmap). also worth flagging: 18.7 adds PRs to copilot chat, which is handy but review is the one place a bit of friction is healthy.

handed an AI agent a chunk of our solution last week — repository layer, some query work. it produced cleaner code than the first PR i ever reviewed from a junior years ago. no business logic in the controller, no query inside a loop hitting the db per row, no method called DoStuff. genuinely better.

and my first reaction wasn't "great." it was "huh, we don't hire that junior anymore."

been stuck on it since. that junior's bad PR is why i can write decent EF Core now — i left a wall of comments, then had to actually explain deferred execution on a call, realized i half-understood it myself, went and read the source. the reviewing made me better. we deleted that loop and kept the output, and on the spreadsheet that's obviously correct: one mid with an agent > two juniors.

but the mid who becomes the senior catching the agent's subtly-wrong 30% in 2031 only gets there if someone stretches them now. through the exact structure we just cut.

not anti-AI, i use it daily, i'm complicit. just noticing the seniors in this sub got made by a process we're not running anymore, and nobody seems bothered.

anyone's team actually doing juniors-plus-AI well, or is it all just quietly gone?

The C# MCP SDK hit version 1.0 in March 2026. The hello-world examples in the docs work as advertised. The gap between those examples and a server an LLM client actually uses well in production is wider than the README suggests.

Three failures kept showing up while I was getting one to behave properly:

stdio transport silently corrupts when anything writes to stdout, and ASP.NET's default Console logger does. One config line fixes it, but you have to know to add it.

[Description] attributes are the model's tool-selection prompt, not API documentation. "Gets a user" is not a description, it's a coin flip. They need to read like system prompts: when to use, when not to, what each parameter means.

Throwing exceptions other than McpException returns "An error occurred invoking <tool>" to the model. The SDK is protecting you from leaking stack traces. The model is getting nothing it can recover from. There's a pattern that gives you both.

If you've shipped an MCP server in C# already, what gotchas have you hit that I haven't covered here?