William Cameron | Beyond the Keyboard

On 16 October, GitHub made open-source licence compliance generally available for GitHub Enterprise Cloud repositories using GitHub Code Security. The capability allows enterprises to define a central licence policy, apply it through repository rulesets and block pull requests when new or changed dependencies do not comply. This is more than another supply-chain control. It shifts licence management from periodic audit into the daily engineering workflow. Licence risk has traditionally arrived too late Many organisations discover licensing problems during procurement, a customer due-diligence exercise, an acquisition or a release audit. By then, an unsuitable dependency may be deeply embedded in the product. Replacing it can require architectural work, retesting and an awkward conversation about why the issue was not identified earlier. The failure is rarely that engineers ignored policy. More often, the policy lived in a legal document, spreadsheet or specialist scanning too...

On 6 October, GitHub made stacked pull requests generally available. The feature allows engineers to break one substantial change into a sequence of dependent pull requests, review each layer independently and merge all or part of the stack while preserving the dependency order. This sounds like a workflow convenience. For engineering leaders, it is more consequential. Pull request size is one of the quiet variables shaping delivery speed, review quality and operational risk. Stacks offer a way to reduce batch size without forcing engineers to wait for every intermediate change to reach the main branch. Used well, they can shorten feedback loops and make architectural intent easier to review. Used badly, they can turn one opaque change into five interdependent queues. The problem is not large pull requests alone Most teams already know that large pull requests are difficult to review. The reviewer must reconstruct more context, defects hide amongst mechanical changes and feedba...

On 30 September, GitHub and npm removed a small but important obstacle to token-free package publishing. npm trusted publishing configurations can now receive an opt-in permission to manage distribution tags such as latest , next and beta using short-lived OpenID Connect credentials. The feature will not dominate technology headlines. It should nevertheless prompt an immediate review in organisations that publish JavaScript packages. Until now, teams could use trusted publishing for the release itself, yet still need a long-lived npm access token to promote a staged version, move a prerelease channel or perform a rollback by changing a tag. One residual secret was enough to preserve a material attack path. The real change is the trust model Traditional release automation starts with a stored credential. A person creates an npm token, places it in a CI secret store and relies on process controls to keep it valid, scoped and rotated. The workflow presents that bearer token to n...

On 21 September, Belgian security company Aikido released an open-weight model designed for cybersecurity work that can run locally, without sending source code to an external model provider. The announcement is one product release, but the underlying question is becoming strategic for every software organisation using AI: where is your code allowed to go? Engineering leaders have spent years classifying customer data, production credentials and regulated records. Source code has often received less precise treatment. It may be private, but it is routinely copied into local tools, build systems, SaaS scanners, support tickets and now AI assistants. As AI becomes part of development and security workflows, that ambiguity is no longer sustainable. The decision is not simply whether cloud AI is safe or local AI is better. It is about choosing an execution boundary that matches the sensitivity of the code, the capability required and the controls the organisation can genuinely operate. ...

Most engineering teams are described through seniority, discipline or reporting lines. We count frontend developers, backend developers, platform engineers, Staff Engineers and Engineering Managers. Those labels are useful for organisation design, but they say surprisingly little about how a team actually creates value. A more revealing view is to look at the forces engineers bring to the software lifecycle. Healthy teams need four of them: discovery, delivery, protection and renewal. Think of the people who naturally lead those forces as the Four Horsemen of Software Development: the Pathfinder, the Builder, the Guardian and the Steward. These are not fixed personality types, and nobody should receive one as a permanent label. Strong engineers can operate in several modes. The framework is useful because it exposes imbalance. Many teams have plenty of Builders but no Steward, or a powerful Guardian who is engaged only when a release is already in trouble. 1. The Pathfinder The Pat...

Chrome 154 entered the stable channel on 22 September 2026. On its own, that is a routine browser update. What makes it strategically important is that it marks the operating reality of Chrome's new two-week release cycle, replacing the four-week milestone cadence that has existed since 2021. Google's stated rationale is reasonable: smaller releases, faster access to platform improvements and a shorter gap between fixes becoming available and reaching users. Chrome 154 also contains 108 security fixes, illustrating why browser vendors want the ability to move quickly. For web engineering organisations, however, doubling the frequency of stable milestones changes more than a calendar. It compresses the time available to detect compatibility risks, validate critical journeys and respond before a change reaches a large percentage of customers. The wrong response is to double the amount of manual regression testing. The right response is to redesign browser compatibility as a con...