As part of our secure SDLC strategy, we generate an SBOM(Software Bill of Material) and store it inside Dependency Track . This gives us a good overview of all our applications, their dependencies and vulnerable components. However after upgrading to the latest CycloneDx-dotnet version, our SBOM pipeline turned out broken. The problem When uploading an XML-based Software Bill of Materials (SBOM) to Dependency-Track, we started to encounter a 400 – Bad Request response. The culprit is a version mismatch: a recent update to the dotnet-CycloneDX tool now generates SBOMs in CycloneDX 1.7 format by default — a version that Dependency-Track does not yet support. Dependency-Track validates incoming SBOMs against its supported schemas. When it receives a 1.7 document, schema validation fails and the upload is rejected entirely. The dotnet-CycloneDX package was updated our your build server, silently bumping the default output format from CycloneDX 1.6 to 1.7. No code change, just...
Verifying frontend changes always meant a mental context switch: write code, alt-tab to a browser, poke around in DevTools, switch back. Even with a decent dev server, the loop was still manual — and for AI agents, it was essentially broken. Agents could write unit tests for logic, but verifying whether a button actually renders, whether a dialog triggers, or whether a layout holds up? That required a human in the loop. I first tried to tackle this problem by using the Playwright or Chrome Dev-Tools MCP server, but with the February 2026 release of VS Code (1.110) , that changes. Agents can now open, interact with, and inspect your running application directly inside VS Code's integrated browser — closing the development loop without any manual hand-off. How it works When browser agent tools are enabled, Copilot gains access to a set of tools that let it read and interact with pages in the integrated browser. As the agent interacts with the page, it sees updates to page co...