What Do DOS, ADHD, and Baked Beans Have in Common?

What do DOS, PowerToys, ADHD advocacy, community building, and baked beans have in common? They are all part of Jeremy Sinclair’s MVP journey. From a curious kid exploring computers in Wheeling, West Virginia, to a globally connected Microsoft MVP, Jeremy has built a reputation for diving deep into technical challenges, amplifying the work of others, and creating space for people to feel they belong. Along the way, he has shown that curiosity can open doors, community can change lives, and sometimes an enduring friendship can begin with a joke about baked beans.

"When I find things that I think are awesome and amazing, I make sure the rest of the community finds out as well." - Jeremy Sinclair

Microsoft Build 2026: (left to right) Scott Hanselman (Microsoft) and Jeremy Sinclair (MVP)

From DOS to PowerToys: Curiosity Finds a Way

Jeremy’s path into technology began beside his father and a family computer. At three or four years old, he was experimenting with DOS and five-and-a-quarter-inch floppy disks, learning by watching, imitating, and trying again. When his father returned to school after a steel-mill layoff, a local program at West Virginia Northern Community College introduced Jeremy to T1 lines, the Mosaic browser, and Windows 3.1. Soon he was tinkering with JavaScript, helping resell websites at 13, and learning PHP in high school.

I can keep looking, or I’m going to pull up my own seat to that table and join them. - Jeremy Sinclair

That same impulse - to understand why something does not work and then make it work - became the thread through his career and community contributions. A Windows Phone music player started because an existing option failed while he was mowing the yard. Later, when Microsoft PowerToys did not run as he wanted on his Surface Pro X, Jeremy helped bring it to ARM64. Contributions like those helped lead from the Windows Insider MVP community to his Microsoft MVP award in Windows Development in 2022.

Jeremy recently brought that journey to the Microsoft Build stage, joining Microsoft Full-Time Employees (FTEs) Fernanda Saraiva and Betsy Weber to share how curiosity, self-directed learning, community contribution, and a willingness to step into unfamiliar problems helped him become an MVP. The conversation offers an engaging first-hand look at the experiences behind his award - and practical encouragement for anyone wondering how their own learning and community work can grow into something more. Watch Jeremy’s MVP story from Microsoft Build 2026.

Being West Virginia’s only Microsoft MVP carries both pride and responsibility. Jeremy sees abundant talent across the state and the nearby Ohio and Pennsylvania communities. Rather than treating geography as a limit, he drives to events, connects online, summarizes .NET Conf sessions for people who cannot attend, and points attention toward work he believes others should see.

I don’t want anyone to struggle. I want to help. If something helped me, I want to help everyone else. - Jeremy Sinclair

The Double-Edged Sword That Builds Bridges

Jeremy was diagnosed with ADHD as an adult and describes it as a “double-edged sword.” Hyperfocus can send him deep into logs, telemetry, debugging, and disassembly until he understands what failed and why. That persistence has helped him solve problems at work, contribute to open source, and identify the right people when a fix requires broader collaboration. Learning more about ADHD has also helped him pace himself, set boundaries, and, in his words, “properly sandbox” himself.

Just as importantly, openness turned into connection. When Jeremy shared the difficulty of staring at a screen and feeling unable to begin, people in his community reached out and encouraged him to seek professional support. He now speaks candidly because someone else may recognize their own experience and feel less alone. He emphasizes that neurodivergence is a spectrum; no single accommodation or experience represents everyone.

For community leaders, his advice is practical: ask rather than assume. Invite feedback through a questionnaire or a trusted community member. Check whether an experience feels overwhelming, what makes sense, and where the balance lies. Inclusive community building is not waiting for someone to struggle publicly - it is reaching out first and making participation easier.

Someone reaching out - that’s the most important thing. - Jeremy Sinclair

Jeremy Sinclair and his baked beans t-shirt.

Pull Up a Seat - and Pass the Baked Beans

Jeremy’s story is also a reminder that community grows through delight - and that an inside joke can become a genuine connection. It began when Microsoft FTE Barry Dorrans posted a photo of baked beans on pizza on social media. Jeremy replied with one perfectly dry line: “You know you can delete this, right?” Barry realized he could get a reaction, and the joke took on a life of its own. Soon there were baked-bean birthday gifts, a bean medallion for Jeremy’s MVP Summit badge, and even a baked-bean shirt. The best part is that the joke started before Jeremy and Barry had ever met face to face. Their playful online exchange became the start of a lifelong friendship, strengthened through shared events, ongoing banter, and even a full Irish breakfast cooked by Barry - with baked beans included, of course. For Jeremy, the story captures something true about technical communities: sometimes belonging grows through code and collaboration, and sometimes it begins with a ridiculous pizza topping.

Every MVP journey starts somewhere: a spark of curiosity, a stubborn problem, or a person who reaches out. Explore Jeremy Sinclair’s MVP profile, then reflect on your own journey. What person, problem, or unexpected inside joke helped you find your community? Share your story in the comments - we would love to hear it.

Want to learn more about the MVP Program?

To find an MVP and learn more about the MVP Program visit the MVP Communities website and follow our updates on LinkedIn.

Join us for a future live session through the Microsoft Reactor where we walk through what the MVP program is about, what we look for, and how nominations work. These sessions are designed to help you connect the dots between the work you’re already doing and the impact the MVP Program recognizes - with time for questions, examples, and real conversations. 

 

 

Comment

Happy Friday!

If I had to summarise the common theme of this week’s issue, it would be “development at scale”. Apple platform development, not to mention Swift itself, has long since reached a level of maturity where the community is discussing the various challenges of building software at scale.

So I’m not surprised to see several great articles published recently that revolve around these challenges. Conveniently, as someone who is part of a large development team, I have a personal interest in these topics, so putting together this issue and providing the commentary felt effortless.

I hope you enjoy it 🫡

– Alex Ozun

Sponsored Link

swiftCon Discount Code for iOS Dev Weekly

The swiftCon agenda is almost here, and we can’t wait to show you the full lineup. With 110+ talks and 120+ speakers from swiftCon alone, this is shaping up to be something special for the world’s largest conference for mobile app developer conference in Berlin. To celebrate, we’re continuing to offer an exclusive 25% discount code for iOS Dev Weekly readers. 50 fresh coupons have been generated, so be quick: enter voucher code IOSDEVWEEKLY25 on the next.app devCon home page or use this registration link.

News

Apple launches a new leasing program Apple Upgrade

This week, Apple announced Apple Upgrade, a new U.S. leasing programme for iPhone, iPad, Mac, and Apple Watch. My impression is that it’s a fairly standard leasing programme with multiple end-of-lease options, including a buyout that lets you keep the device for its original list price, effectively treating it as an interest-free loan.

But the more interesting part of the announcement was the controversy around the so-called ‘Restricted Mode’ discovered in the iOS 27 betas. It was initially suggested by 9To5Mac that Restricted Mode could be used to limit the capabilities of financed devices if you miss a payment. Apple then dismissed that assumption, stating that Restricted Mode won’t be used for this purpose, but without clarifying how it will actually be used. That leaves an uncomfortable question of how Restricted Mode will be used at launch, and what Apple (and other actors) might do with it in the future.

Code

Revisiting the JET iOS Modular Architecture in 2026

I still remember when Alberto first published the original article outlining Just Eat’s modular project architecture. It quickly became one of the most influential resources on modularisation, with many folks I’d discussed the topic with over the years directly citing it as inspiration for their own modularisation efforts. This makes me think that sharing this 7-years-later update is important for the community.

In the new article, Alberto describes an interesting challenge: a new module didn’t fit cleanly into any of the existing categories, leaving it in limbo between the Domain and Shared layers and prompting the team to reconsider their modularisation model from first principles. The final design they arrived at feels both convincing and natural.

Side note 💡: one small detail in the article that caught my attention was this: “The internal architecture of a module is unconstrained and teams may use MVVM, TCA, or anything else, provided they do so behind the facade.” Knowing that many teams, ours included, try to standardise their architectural patterns across the codebase, I felt compelled to reach out to Alberto to confirm that this is how it works in practice. Alberto confirmed that it is indeed common practice at Just Eat, and one the team is happy with, as it has saved them from unproductive architectural debates.

---

AI Broke Code Review. Here’s How to Rebuild It.

Whether or not you agree with Pawel that AI has indeed “broken” code review, it’s hard to argue that the existing social contracts around it are being heavily challenged by the sheer volume of AI-generated code. From whispers across the community, I know that almost every team is exploring some form of AI-powered code review to reduce the burden on human reviewers and let them focus on diffs that need their judgement most.

I like the article’s proposal (and the memes 🙂) to treat code review as a pipeline that starts before the pull request is opened. The pipeline acts as a “low-pass” filter, making sure that by the time the diff reaches human reviewers, all that’s left are the decisions a machine isn’t allowed to make. Easier said than done, and I can see how putting these systems in place would require significant upfront effort, but it seems like a worthwhile investment for teams.

The part I agree with most is the boundary it keeps around automation. Agents can apply safe mechanical fixes, but anything touching critical behaviour or public APIs still goes to a human. This feels like the right direction for code review when AI can generate code much faster than people can meaningfully review it.

---

Demystifying Thread Hopping with Swift 6.2 Approachable Concurrency

If I’ve learned anything about Approachable Concurrency it’s that there can never be too many articles explaining Approachable Concurrency. And this one from Nikita does the explaining part very well. I particularly like the side-by-side execution traces comparing how work is scheduled before and after enabling Approachable Concurrency, which makes the article useful as a quick reference. And as someone who hasn’t yet fully embraced Swift 6.2 and Approachable Concurrency, I find its conclusions reassuring.

Tools

The coolest use for the Vision Pro

Long-time indie developer Christian Selig, the creator of the legendary Apollo(RIP🪦) has a knack for finding practical uses for Apple’s platforms. This time, he built Prospector, an open-source Vision Pro tool that lets you load a 3D model and explore it at full scale. Christian used it to walk through the house he’s building before it exists. It’s a simple idea, but also one of the clearest examples I’ve seen of spatial computing solving a real problem.

And finally...

A funny iOS 27 beta bug occasionally leaves the iPhone keyboard visible on the Always-On Display and Lock Screen. Can we make it a feature and call it BlackBerry Mode 😉?

Bug fixes

• bugfix: [Python] sessions.list() raised ValueError for any non-empty session list due to boolean-discriminated union decoding bug (#2123)
• bugfix: [Python] binary tool results (e.g., base64 image data) were silently dropped when forwarding tool responses, causing the model to report it could not view images (#1821)
• bugfix: [Python] codegen emitted an unintended synthetic class name (PermissionDecisionApproveForIonApproval) for permission approval types; now emits the correct schema-named aliases (PermissionDecisionApproveForSessionApproval, PermissionDecisionApproveForLocationApproval) (#1652)
• bugfix: [C#] CustomAgentsLocalOnly was only sent via session.options.update after session creation, arriving too late to restrict agent discovery to the working directory; it is now included in the session.create and session.resume wire payloads (#1899)

New contributors

• @abhinavgautam01 made their first contribution in #1652
• @arimu1 made their first contribution in #2032

Generated by Release Changelog Generator · sonnet46 21.4 AIC · ⌖ 4.16 AIC · ⊞ 8.6K

A common request to a coding agent is only one line:

Generate unit tests.

That request leaves important questions open. Which code needs tests? Which test framework does the project use? Where should the tests go? How does the build find them? What should the tests check?

The agent can learn from the repository, write the tests, and prove that they work.

This is why we built code-testing-generator. It is an open-source, polyglot agent for unit-test generation. You can find it in the dotnet-test plugin in dotnet/skills.

The agent writes unit tests. It isolates the code under test and mocks external services and other outside dependencies.

Integration, end-to-end, browser, and performance tests are outside its current scope.

It does more than make the tests pass. It checks the assertions, the requested scenarios, and whether the repository’s normal test run finds the new tests.

What happens after the prompt

The agent does not start writing tests immediately. It learns from the repository first, then plans, writes, and checks the tests.

First, learn from the repository

The agent searches the repository for the code that needs tests. It detects the language and test framework. It also looks for existing tests that show where new tests belong and how they should look.

It also finds the correct commands to build and run the tests.

This prevents a common problem. A new test project can build and pass on its own but never run in continuous integration (CI) because it was not added to the solution or the repository’s test command. The agent checks how the repository discovers tests and confirms that the new tests appear there.

Next, choose the right amount of work

A single method does not need a large plan. A whole solution does.

The agent chooses from three paths:

• Direct: Read the relevant code, write the tests, and validate the result.
• Single pass: Research and plan once, then implement that plan.
• Iterative: Repeat the cycle to cover a large request or reach a coverage goal.

Then, plan and write the tests

For larger tasks, the agent lists the code that needs tests. It starts with simple code and then moves to code with more dependencies. It maps each behavior to a test file.

The plan follows the request. A request for one module should not change every test project in the repository.

The agent follows the local conventions and runs the tests as it works. If the generated code does not compile, it fixes it. If an assertion is wrong, it reads the source and corrects the test.

It does not change production code during test generation. It also avoids unit tests that call external URLs, open ports, or depend on exact timing.

Finally, check that the tests are useful

A test can pass but provide little or no added value. For example, it may only check that a result is not null. It may test the wrong method. It may even pass if the method always returns a default value.

The agent checks for these problems before it finishes:

1. It considers small code changes that should make the tests fail. This is a lightweight form of mutation testing.
2. It looks for weak or missing assertions.
3. It checks that every requested scenario has a matching test.
4. It builds the full workspace and runs the full test suite.
5. It confirms that the repository’s test command can find the new tests.

This workflow turns a short prompt into a tested result.

What we measured

In our latest benchmark, the agent completed 140 of 152 tasks. Stock Copilot, which used the same tool without our plugin, completed 120 with the same model. That is a 92.1% completion rate versus 78.9%, with 63% fewer failures.

The biggest gains came from prompts like the one at the start of this post. We call these vague prompts because they leave most decisions to the agent.

Vague prompts show why the workflow matters

Vague prompts produced the clearest result. The agent passed 79 of 89 tasks, compared with 59 for stock Copilot. Failures fell from 30 to 10.

We used our internal unit-testing benchmark. It contains 152 tasks from real repositories. Some prompts are detailed. Others are vague and leave most decisions to the agent.

We compared four setups: stock GitHub Copilot, stock Claude Code, our agent in GitHub Copilot, and our agent in Claude Code. The results below focus on the GitHub Copilot comparison unless we say otherwise. Both Copilot setups used the same model and prompts.

A task passed only when:

• The repository built.
• All tests passed.
• The agent added at least one test.
• The agent did not remove any existing tests.

The full breakdown shows that detailed prompts were tied:

Prompt type	Specialized agent	Stock Copilot
Vague prompts, 89 tasks	79 (88.8%)	59 (66.3%)
Detailed prompts, 63 tasks	61 (96.8%)	61 (96.8%)

That is 67% fewer failures on vague prompts. All 20 net gains came from these tasks. This matches the goal of the agent: do the research that the developer did not put in the prompt.

The same pattern appeared when the prompt pointed to a code change. The benchmark has 15 tasks that ask for tests for a specific diff. The agent passed all 15. Stock Copilot passed none.

More successful results, not simply more tests

Both setups ran the same 152 tasks. This lets us compare each result directly.

• Both passed 119 tasks.
• Only the specialized agent passed 21 tasks.
• Only stock Copilot passed one task.
• Both failed 11 tasks.

Metric	Specialized agent	Stock Copilot
Tasks completed	140/152 (92.1%)	120/152 (78.9%)
Solutions building	148	145
Final test suites passing	149	147
Tests generated	6,963	7,129
Average final line coverage	72.4%	72.2%
Average final branch coverage	49.8%	49.1%
Average task time	359 seconds	380 seconds

The specialized agent generated 2.3% fewer tests, with effectively the same average coverage. It also completed more tasks and was about 5.5% faster on average. The gain came from reliability, not from producing more tests.

The benefit extends across models and languages

The benchmark contains 45 .NET tasks. They cover several repositories and different task sizes. We ran the same comparison with three models:

Model	Specialized agent	Stock Copilot	Failure reduction
Claude Opus 4.8	43/45 (95.6%)	35/45 (77.8%)	80%
GPT-5.5	41/45 (91.1%)	36/45 (80.0%)	56%
Claude Haiku 4.5	34/45 (75.6%)	25/45 (55.6%)	45%

The workflow helped every model. With Opus, it added eight wins with no losses. With Haiku, it completed nine more C# tasks than stock Haiku.

The result also suggests that a strong workflow can lift a mid-tier model close to the best result. Across all 152 tasks, specialized GPT-5.5 reached 90.1%. That was within two points of specialized Opus and more than 11 points above stock Opus.

The agent includes guidance for .NET, Python, TypeScript, JavaScript, Java, Go, Ruby, Rust, Swift, Kotlin, PowerShell, and C++. It learns each repository’s conventions instead of applying C# patterns everywhere.

Beyond .NET, the same Opus run covered several of these languages:

Language	Specialized agent	Stock Copilot
Python, 15 tasks	13 (86.7%)	6 (40.0%)
Go, 15 tasks	15 (100%)	10 (66.7%)
PowerShell, 10 tasks	7 (70.0%)	8 (80.0%)

The agent passed every Go task and more than doubled the Python completion rate. It also passed five Go and five Python tasks that targeted a specific code change.

The result was not better in every language. Stock Copilot passed one more PowerShell task. These groups are also small, so we see them as useful signals, not promises for every repository.

A second, harder benchmark

We also tested the workflow on 44 unit-test tasks from SWE Atlas. This benchmark checks requirements and uses code changes to see whether the tests can catch bugs.

Metric	Specialized agent	Stock Copilot
Tasks completed	16/44 (36.4%)	12/44 (27.3%)
Wins by only one setup	4	0
Passing generated tests	550	493
Tests that caught injected bugs	360	316

The specialized agent completed four more tasks, with no stock-only wins.

The completion rates are much lower than in our internal benchmark. SWE Atlas is hard, and there is still a lot to improve.

What we learned and what comes next

The clearest gain was reliability. The agent was more likely to deliver unit tests that built, passed, and matched the request. The difference was largest when the prompt was vague or linked to a code change.

Once both setups produced a valid result, neither led every quality measure. Stock Copilot scored slightly higher on assertions and coverage. The specialized agent scored slightly higher on test hygiene, such as clean structure and avoiding slow or fragile patterns.

These groups contain different tasks. The specialized group includes harder tasks that stock Copilot did not complete, so this is not a direct quality ranking. We see these results as guidance for the next improvements: deeper assertions and error-path tests while keeping strong test hygiene.

Efficiency remained close after accounting for completed tasks. The agent used about 3.2% more recorded tokens per completed task. These counts include cached input, so they do not directly represent cost.

These results cover unit tests only. We are exploring where the same workflow could help with other types of testing, but we have no committed plans to announce.

Try the agent

The agent, skills, and language guidance are open source in dotnet/skills.

You can use the plugin in GitHub Copilot CLI. It is also available in Visual Studio Code and VS Code Insiders through plugin support, which is still in preview. We are also working on support for Visual Studio.

Add the marketplace and install the plugin in GitHub Copilot CLI:

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

Restart the CLI. Select code-testing-generator from the list of agents. Then try the prompt from the start of this post:

Generate unit tests.

Review the plan, the tests, and the final checks. You can also ask for tests for one function, one module, or a specific coverage goal.

Good tests are not only generated. They are planned, built, run, and checked. That is the trust loop we are building.

The post From generated code to trusted code with a unit-test agent appeared first on .NET Blog.

In yesterday’s earnings call, we shared that Microsoft 365 Copilot has surpassed 30 million paid seats, with net seat adds more than doubling quarter over quarter.

The post The next measure of AI momentum is work transformed appeared first on Microsoft 365 Blog.

Tags:

• AI

The post Microsoft unveils new AI cybersecurity model appeared first on Source.