The art of simplicity

There's a moment in every agentic workflow where you pause and think: wait, what exactly is Copilot allowed to touch right now? For a long time the answer was: pretty much everything under your working directory and whatever shell commands it decides to run to get the job done. That was fine when Copilot was mostly suggesting code. It's a different story when it's running tools, executing scripts, and modifying files on your behalf. As of June 2026, GitHub has an answer: local sandboxing , now in public preview. It doesn't replace good judgment about what you ask Copilot to do, but it does put a real isolation boundary between the agent's tool execution and the rest of your machine. Let’s explore this feature… Why do we need this? The Copilot CLI has evolved significantly since GA. What started as a smart terminal assistant now has Autopilot mode, /plan , fleet parallelism, rubber duck, and a full agentic harness underneath. When you run Copilot in Autopil...

Having your AI agent come up with a plan before start coding, has helped me a lot in my agentic development workflow. It allows me to verify the steps the agent will take and allowed me to avoid that the agent goes down the wrong path. To help you with this, Visual Studio got a ‘plan mode’ that once enabled allowed the agent to create a plan. I really liked the feature, the only problem is that is what not always obvious when the agent decides to create a plan and when it just starts executing. To tackle this issue, the plan mode in Visual Studio has evolved to a separate plan agent, similar to what we have in VSCode. Plan first, code second If you have never heard about plan mode or the plan agent, it is a dedicated mode in Copilot Chat that focuses entirely on understanding what you want to build before touching a single file. Instead of jumping straight to implementation, it asks clarifying questions, reads your codebase using read-only tools, and drafts a detailed implemen...

A colleague told me a story recently. A new architect joined his project. Experienced, credentialed, confident. And from day one, all he did was explain what was wrong with the existing system. The choices that were made, the patterns that were used, the technical debt that had accumulated. An endless inventory of flaws. I've seen this before. And it always makes me uneasy. Not because criticism is bad. Codebases do accumulate real problems. Patterns do become outdated. But there's a specific kind of criticism — reflexive, premature, delivered without curiosity — that reveals something troubling about the person offering it. The most dangerous person in a technical team isn't the one who doesn't know enough — it's the one who arrives certain they know better. Every system is a set of scars Software systems carry history inside them. A module that looks over-engineered almost certainly went through a painful incident that demanded it. A seemingly arbitra...

While visiting multiple organizations and talking to colleagues about integrating AI into their software development lifecycle, I noticed something: The approaches couldn’t have been more different. Some teams were embedding AI deeply into every step of development—coding, testing, documentation, even architectural decision-making. Others were deliberately cautious, limiting AI to narrow, controlled use cases. Opposites. And yet, both felt… reasonable. That’s when it clicked for me: We are all beginners. Not in the dismissive sense. Not in a “we don’t know anything” kind of way. But in the ways as described inside the Dreyfus Model of Skill Acquisition .   The Dreyfus model, briefly The Dreyfus model describes how people acquire skills through five stages: Novice – Rely on rules and rigid guidelines Advanced Beginner – Start recognizing patterns, but still need support Competent – Can plan, prioritize, and make conscious de...

After giving a GitHub Copilot training last week where I introduced the concept of hooks, one of the attendants asked me what would be a good example for a hook. Great question! A first use case I could think of is that we use a hook to format the AI generated code to match the style preferences and static analysis recommendations specified in an .editorconfig file. Tip: If you are looking for some inspiration, check out the hooks section in Awesome Copilot: awesome-copilot/docs/README.hooks.md at main · github/awesome-copilot What event should we use? There are multiple hook events that you can use: sessionStart , sessionEnd , userPromptSubmitted , preToolUse , postToolUse , and errorOccurred . As the formatting should be done after every code change, postToolUse seems the logical choice. Why not at SessionEnd ? postToolUse formats the file immediately after each edit. This means the agent sees clean, correctly structured usings before it reads the file again for its ...

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...

Last year Valentine's Day I built a Romantic Movie Generator — an app that turned action movies into sweeping romantic dramas - using AI. Die Hard became a tender love story about a man who just wanted to spend Christmas with his wife. It was fun, it was silly, and it required a surprising amount of hand-holding to get the AI to behave. At that time a colleague took my idea and crafted his own version; Loveflix . This year, my partner made it abundantly clear that another "action movie as romance" project wasn't going to cut it for February 14th. Fair enough. So I did what any reasonable developer does under domestic pressure: I flipped the concept entirely. Built on top of the version from my colleague I created: ActionFlix: turn any rom-com into a high-octane action thriller. Because Love Actually is basically a heist movie if you squint hard enough. Same concept, inverted. Sweet home setup, chaos onscreen. Points successfully gained. But here's ...

I promised yesterday that it would be my last post about how we are using Dependency Track. But turns out that there is some confusion and a few people asked me the following question: "How should I organize all these projects?" This is a good question because a well-structured project hierarchy makes the difference between a dashboard that provides clarity and one that creates confusion. In this post, I'll share the project organization strategies we've explored and practical examples you can adapt to your organization. Understanding Dependency-Track's model Dependency-Track organizes work around several key concepts: Projects : The fundamental unit representing a software component. Each project has a name and version. Remark: A project can also be flagged as current. Versions : Projects can have multiple versions representing different releases or deployments. Classifiers : Indicates if the project type is a library, framework, ...

Yesterday we started exploring GitHub Spark. We looked at the basic prompting experience, the live preview but also explored the visual editing features and the specification generation (through a PRD.md file). But we didn't have the time to check out all the features.  Let's dive in... Seamless GitHub Integration This is where Spark really shines. Unlike standalone vibe coding tools, Spark can create a GitHub repository from your project. Once created you get a repository with GitHub Actions, Dependabot, and all the standard tooling. The code is synchronized so you don’t need to leave the vibe coding experience. Remark: This is also a great way to better understand what is going on behind the scenes. It allowed me to fix some issues where I wasn’t able to solve it inside GitHub Spark. Need more power? Open a Codespace directly from Spark and continue development with the full GitHub ecosystem at your fingertips. Upload a sketch or an image You don’t have to start...

There are multiple platforms available to support you in your vibe coding experience. I mostly used bolt.new but also experimented with lovable.dev and v0.app. But did you know that Github has there own vibe coding platform? Time to give Github Spark a try… Enter GitHub Spark GitHub Spark, it's an AI development platform that converts plain English descriptions into complete, deployable full-stack applications. And I do mean complete—frontend, backend, authentication, database, hosting, the works. Its main focus is simplicity, allowing you to create simple applications without having to worry about all the technical details. Let’s dig into some of the features it has to offer. Pure natural language development The starting point is the same as with any of the other available platforms. You can enter a prompt that describes what you want. "I want to create mobile friendly 7 minutes workout app.." That's it. No setup, no configuration, no choosing betw...

In our efforts to improve the (code) quality of our applications, we started an initiative to get all our teams integrate their projects in SonarQube. We have SonarQube running for a long time inside our organization, but adoption remained fragmented. The initiative turned out quite successful, but as a consequence, we encountered some issues with SonarQube. Teams started to complain that there build pipelines became flaky and sometimes resulted in errors. The reported error was related to SonarQube and the message was like this: Error MBS0418: The ‘MakeUniqueDir’ task failed unexpectedly. System.UnauthorizedAccessException: Access to the path ‘’'db1_work80_sonarqubeout’ is denied. We found out that the problem was related to our build server setup where we have multiple agents running on the same server. As multiple agents try to execute the ’Prepare Analysis’ task, it sometimes fails with the error message above. Furher research brought us to the NodeReuse parameter of...

In a recent code review, I stumbled upon something that made me pause: a developer had included the original AI prompt as a comment block above a set of classes. At first glance, it seemed like unnecessary clutter. But as I read through both the prompt and the resulting code, I realized I was maybe witnessing the birth of a new documentation practice that could fundamentally change how we understand and maintain AI-assisted codebases.   The case for prompts as living documentation Everyone who took the time to dig a little deeper in using AI as part of his day-to-day coding activities knows that a carefully designed and written prompt can make all the difference. So, wouldn't it be unfortunate that all the effort we put into it is lost after the AI agent has done his job? Some other reasons I could think of that makes storing these prompts valuable: Reproducibility : If we need to modify the AI generated code, we could adjust the prompt and regenerate rather than hand-edi...

I always made the assumption that in some way we as humans take rational decisions in a business context. Maybe we do something foolish at home, but at work we weigh options, calculate outcomes, and make logical decisions based on available information. Yes, right? Then I encountered Daniel Kahneman's Thinking, Fast and Slow , and this comfortable assumption crumbled. The book reveals a uncomfortable truth: we're far less rational than we'd like to believe. One of the most pervasive examples of our flawed reasoning is the sunk cost fallacy – our tendency to continue investing in failing ventures simply because we've already invested so much. The blizzard we drive into Kahneman paints a vivid picture: you've bought expensive concert tickets, but a dangerous blizzard hits on the night of the show. The rational choice is clear – stay home and stay safe. The money is already spent; driving into dangerous conditions won't bring it back. Yet many of us would ...