Posts

Agent-Scale Repositories Move the Bottleneck From Git to Engineering Governance

Agent-Scale Repositories Move the Bottleneck From Git to Engineering Governance On 5 November, GitHub described a new Git storage architecture designed for a development model in which thousands of software agents can work on one repository concurrently. In internal testing, GitHub says the system supported 5,000 concurrent agents and 7,200 pushes per second while maintaining low-latency reads. Those numbers are deliberately beyond the needs of almost every engineering organisation today. Their importance is not that teams should attempt to reproduce them. It is that a major software delivery platform is rebuilding its foundations around an expected increase in autonomous, parallel change. If source control can absorb that volume, the constraint moves elsewhere. For engineering leaders, the emerging challenge is no longer whether agents can produce and push code. It is whether the organisation can evaluate, integrate, operate and own the resulting changes safely. Git concurre...

Node.js 26 Is LTS. Runtime Upgrades Must Become an Engineering Capability

Node.js 26 Is LTS. Runtime Upgrades Must Become an Engineering Capability Node.js 26.13.0 entered Long Term Support on 28 October under the codename Lithium. The release line will receive updates until the end of April 2029. That creates a new default for teams starting services and a clear migration target for organisations running older versions. The tempting response is to open an upgrade ticket, assign it to a platform team and treat completion as evidence that the runtime estate is healthy. That misses the more important leadership question: can the organisation move between supported runtimes routinely, without turning every transition into a programme? Runtime currency is not housekeeping. It is an engineering capability that determines how quickly a company can absorb security fixes, adopt framework releases and keep its delivery platform supportable. LTS is a starting signal, not a deadline Node.js 26 becoming LTS does not make Node.js 24 or 22 immediately unsafe. ...

PHP2Shell Is a Test of Whether Your Runtime Estate Is Actually Governed

On 21 October, the PHP project released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS 4.0 at 9.2 and can allow unauthenticated remote code execution. The project's guidance is unusually direct: there are no complete mitigations, and updating is the only safe choice. Patched releases are available for supported PHP 8.2, 8.3, 8.4 and 8.5 branches. The incident is already being called PHP2Shell, but the strategic lesson is not about the nickname or the exploit mechanics. It is about whether an engineering organisation can identify, patch and prove the state of every production runtime under urgent conditions. A version number is not an estate inventory Leaders often ask, "Which PHP version do we run?" and receive a reassuring single answer. Real estates are rarely that simple. The production runtime may appear in container base images, serverless layers, build agents, command-line workers, scheduled jobs,...

Open-Source Licensing Is Moving Into the Merge Gate

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

Stacked Pull Requests Are Now Mainstream. Your Review Model Needs to Catch Up

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

npm Closed the Last Token Gap in Trusted Publishing. Now Remove Your Release Secrets

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

Your Source Code Is Now an AI Data-Boundary Decision

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