The Brutal Reality of Open Source CI Pipelines

This is Part 3 of the PowerToys Experience series. Read Part 2 here.

I was monitoring the automated testing nodes for my latest PowerToys PR when reality hit. Contributing to an enterprise-grade open-source project isn't just about writing cool features. It’s about surviving the brutal reality of code reviews and Continuous Integration (CI) pipelines. If your code can't survive the pipeline, your feature doesn't exist.

The Danger of Duplicated Effort

This was my first time collaborating directly with Microsoft, and frankly, diving into a tier-1 enterprise repository was overwhelming. It's so massive that it’s easy to get tunnel vision. Before I built the PasteRich integration, I actually spent hours architecting a completely different feature—adding an "Update and Restart" button to the Command Palette.

I submitted the Pull Request, and it was instantly closed. Why? Because I failed to read through the massive backlog of active issues and PRs to get familiar with the current workstreams. Someone else had already submitted the exact same feature three days prior. It was a hard lesson: before you write a single line of code in an enterprise repository, you must map the active issues to avoid duplicated effort.

Refactoring Brittle UI Tests on the Fly

The true test of a Systems Architect is how you handle infrastructure bottlenecks and code review pushback. Instead of arguing or defending my lazy test code, I took extreme ownership.

I immediately gutted the static delays and built a custom C# polling loop that checks for UI elements natively every 200 milliseconds. Here is the exact WaitUntil loop I contributed to eliminate the vulnerability:

// The Polling Loop that saved the CI Pipeline
private T WaitUntil<T>(Func<T> action, int timeoutMs = 15000)
{
    var stopwatch = System.Diagnostics.Stopwatch.StartNew();
    while (stopwatch.ElapsedMilliseconds < timeoutMs)
    {
        var result = action();
        if (result != null)
        {
            return result; // Element found, return immediately!
        }
        Thread.Sleep(200); // 200ms throttle to prevent CPU spike
    }
    throw new TimeoutException("WaitUntil timed out waiting for the UI element.");
}

// Usage in the test:
// var pasteBtn = WaitUntil(() => apWind.Find<TextBlock>("Paste as Rich Text"));

The test runtime dropped from 35 seconds to fractions of a second, completely eliminating the CI bottleneck and proving to the maintainers that I prioritize infrastructure resilience over just shipping a feature.

Architects don't just write code. We write tests that scale. Adapting to strict CI environments and taking extreme ownership of your code's performance is what separates amateurs from professionals.

Orchestrated by Antigravity

This entire journey—from reverse-engineering the PowerToys monolith and gutting brittle UI tests, right down to generating this exact blog post and publishing it via XML-RPC directly to my Odoo server—was orchestrated alongside my AI-Assisted Systems Architect, Antigravity. It proves that when you augment a human architect with autonomous infrastructure agents, massive tier-1 enterprise repositories become completely transparent.

If you want to read the code I contributed to Microsoft PowerToys, check out the GitHub Repo.

Want to try the tool? Download Microsoft PowerToys from the Microsoft Store.