William Cameron | Beyond the Keyboard

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

On 10 September, GitLab released critical patches for its Community and Enterprise editions. The most serious issue, CVE-2026-85706, was assigned a CVSS score of 10.0. Under certain conditions, an unauthenticated attacker could use the repository commits API to read arbitrary files from a GitLab server. One day later, the US Cybersecurity and Infrastructure Security Agency added the vulnerability to its Known Exploited Vulnerabilities catalogue based on evidence of active exploitation. The immediate response is straightforward: affected self-managed installations should be upgraded to GitLab 19.1.8, 19.2.6, 19.3.2 or later, and potentially exposed systems should be investigated rather than treated as safe simply because a patch has now been applied. The more important leadership lesson is broader. Source-control and delivery platforms are no longer developer tools at the edge of the estate. They are tier-zero infrastructure: systems whose compromise can provide a route into much of t...

This week’s $200 million funding round for enterprise coding-agent company Factory, reportedly valuing the business at $5 billion, is another sign that AI-assisted development is moving beyond autocomplete. The emerging product is no longer simply a faster way to write a function. It is an agent capable of reading a codebase, planning changes, editing several files, running tests and preparing work for review. For web developers, that shift is significant. Modern applications contain far more than JavaScript components: infrastructure configuration, analytics, accessibility rules, automated tests, deployment pipelines and security controls all sit within the same delivery system. An agent that can reason across those boundaries may remove hours of repetitive work. Dependency upgrades, test scaffolding, documentation, migration preparation and first-pass bug fixes are increasingly realistic candidates for delegation. But the more interesting challenge belongs to engineering managers. ...

The Engineer Who Stops Owning Only the Code For much of a software engineer’s career, progression appears straightforward. Junior Developer. Developer. Senior Developer. Perhaps Staff or Principal Engineer. Engineering Manager. Head of Engineering. CTO. Artificial intelligence has introduced another destination: Chief AI Officer — CAIO . At first glance, it seems like a role intended for machine-learning researchers, data scientists and people who have spent their careers building neural networks. That assumption misses what may become one of the most important aspects of the role. A successful CAIO does not necessarily need to be the person who can build the best model. They need to be the person who can answer a much bigger question: How should this organisation use AI to become better? That creates an interesting career opportunity for experienced software engineers. The journey from Senior Developer to CAIO isn't about abandoning engineering. It is about repeatedly wi...