News and Tech Update

Code review has always had two parts: the feedback and the sign-off. GitHub Copilot has been able to handle the first part for a while now, leaving comments, catching bugs, and flagging style issues on pull requests. The second part — the actual approval that clears a PR to merge — has stayed a human job. That changed this week. GitHub announced that Copilot code review can now submit real approvals on pull requests, not just comments. When an organization turns the feature on, Copilot’s sign-off counts toward a repository’s required-approvals rule, just as a teammate’s approval would. It’s a small-sounding change with real weight: GitHub has moved Copilot from advisory to authoritative in the one place where code review actually gates what ships. Here’s how it works. Every Copilot code review already ends with an overview comment. That comment now includes an approval assessment, Copilot’s read on whether the pull request looks ready to merge. On i...

The first sign of trouble was a screenshot. We’d just switched on the A/B test via our feature management platform. Within the hour, a senior stakeholder landed in the variant feature flag, opened the app on their own phone, and sent us an image of it. The message, more or less: “Why is there a new tab in my app?” It was a fair question. It was also one I thought we’d answered weeks earlier. Turns out we never really had. That’s the day I learned the difference between telling people and aligning them. The Work We Were Proud Of My team was reworking the information architecture and frontend navigation architecture of our app. This wasn’t a cosmetic refresh. We were changing the top-level structure to match our product vision and make the app the home of our loyalty programme. It was a strategic bet, and it carried real commercial weight. We did the work properly, or so I believed at the time. We ran discovery sessions. We walked through the concep...

Open source supply chain security has been a scanner-and-CVE game for years — pull the package, run the scan, cross-reference known vulnerabilities, hope the metadata is current. That model always had gaps, and AI agents are widening them fast. Agents pull open source components from wherever they can find them, at machine speed, and the after-the-fact scan is not a control that keeps up. What developers and platform teams actually need is a curated catalog that vets components before they enter the environment, not after they cause a problem. Alan Shimel sits down with Leslie Pascual, Field Engineering Manager for AI and Security Solutions at ActiveState, to work through what a trusted open source catalog looks like in practice and why it becomes table stakes as soon as AI agents join the software supply chain. Pascual brings more than 20 years across engineering, architecture and leadership, with a stint hardening enterprise healthcare applications that pushed her into cybersecurit...

Most organizations writing AI usage policies right now are stuck between two bad options: ban the tools and watch people use them anyway, or say nothing and hope code review catches whatever slips through. Debian just spent two weeks working through that exact problem in public, and the way the vote landed is worth paying attention to, whether you maintain a package archive or a private repo. The Debian Project ran a General Resolution from August 15 through August 28, asking developers to settle the community’s stance on AI-assisted contributions. Eight separate proposals were on the ballot, ranging from an outright ban written into Debian’s Social Contract to a hands-off position treating AI tools like any other developer choice. Debian used the Condorcet method for the vote, meaning developers ranked their preferences rather than picking a single option, and just over 130 of roughly 1,000 eligible developers cast ballots. The ban needed a three-to-one supermajority to p...