A few months ago I shared our Q1 AI update and, more recently, some thoughts on our new PDP release at Collecting Cars. Looking back, both stories were really about the same thing. A relatively small engineering team shipping more than I would have thought possible even a year ago.
At the time, the conversation was mostly about acceleration. Today, I’m finding myself thinking about something different. For most of my career engineering teams have been trying to squeeze another 10bhp out of the engine; Better frameworks, CI, testing, skills…
Then, seemingly overnight, someone handed us a turbocharger. Since Claude Opus 4.5 dropped, we’ve seen AI influence within our codebase rise from around 56% to nearly 90%. Our estimated human-to-AI multiplier has moved from 1.6x to over 8x, and commits are up over 50%.
The BOOOOOST and acceleration are intoxicating!
But anyone who has modified a car knows doubling the power is only half the job. Suddenly you start asking awkward questions about the brakes, cooling, tyres and suspension. AI feels a bit like that.
Q1 was about proving we could accelerate engineering.
Q2 and beyond is shaping up to be about ensuring acceleration doesn’t outpace control.
That means evolving three things together. How we build software, how we maintain confidence in what we’re building, and how we defend the systems our customers trust us with.
1. Agentic Engineering
The obvious story is that we’re using Cursor, Claude Code and rolled our own “AutoDev”. The more interesting story is that engineering work is increasingly being delegated.
Cursor has shifted from being an autocomplete tool to an engineering partner. For most of our engineers, usage is now overwhelmingly agentic rather than tab completion.
Claude Code works alongside us in the Anthropic Apps (desktop and mobile 🤯), terminal and vsCode, helping explore architectures, review PRs, write specifications, generate tests and plan larger pieces of work.
More of the team are starting to favour Claude Code over Cursor. Our new CFO will also be as Claude Team’s is proving cheaper than Cursor.
We’re increasingly creating specifications and tests first, allowing agents to work within clearer boundaries and giving reviewers confidence that intent remains aligned. And, always iterating and compounding skills and knowledge in the codebase.
AutoDev is being built and used to close loops that traditionally consumed engineering time. Taking simpler/routine Jira tickets to PRs; investigating errors surfaced in logs, resolving package updates and migrating simpler pages to NextJS.
Bugbot reviews code alongside humans.
Our recent PDP launch straddled both worlds. The challenge is that output is no longer the bottleneck.
2. Confidence Engineering
The bottleneck has shifted. It used to be writing code. Today, it is maintaining confidence in a codebase changing faster than ever before. PR reviews have become less about checking implementation details and more about asking different questions.
- Does this make sense?
- Does it improve the architecture?
- Will it compound positively over the next six months?
- Have we accidentally introduced debt that future humans and future agents will struggle to untangle?
Perhaps surprisingly, understanding worries me less than I expected. We have guardrails in place. We document decisions and context. We increasingly write code and specifications that teach both humans and AI WHY something exists, not simply what it does.
We don’t want engineers reviewing keystrokes. We want them reviewing judgement. AI writes code quickly. Confidence still compounds slowly, and can erode all too quickly.
3. Defensive Engineering and Adaptive Security
The third point may end up being the most important.
Whether it’s Mythos, Fable, or simply increasingly capable offensive AI systems, it feels inevitable that the volume of vulnerabilities, exploits and patches will rise. Recent NPM compromises have been genuinely frightening. The dependency chains many of us have accumulated over the last decade suddenly look a lot less comfortable.
Attackers don’t need to find every vulnerability. They only need to find one. Defenders need to continuously understand and maintain thousands of moving parts. The asymmetry already existed. AI feels like it is increasing it.
Some mitigations appear sensible until they collide with reality e.g. a fourteen-day cooling period for newly released packages sounds prudent. Until an AI-assisted attacker identifies a critical exploit three days after release and delaying updates becomes the riskier decision.
These are no longer static policies. They’re trade-offs that need continual reassessment. Fortunately, we have more tools available than ever before.
- Claude and Cursor skills help review code and look for security issues
- Dependabot helps surface updates
- Bugbot catches issues
- Autodev can take on more routine patching
- Datadog gives us far better observability than we currently exploit, and I’m keen to allow Claude and Cursor to reason over that data to help engineers understand systems faster, identify patterns earlier and learn from our resident DevOps Wizard.
We also need to become more disciplined about reviewing the packages we depend on, reducing unnecessary exposure and shrinking our attack surface wherever possible.
For years we’ve been encouraged to shift security left. AI forces us to shift it everywhere.
Final Thoughts
I don’t think engineering leaders can afford to think about AI purely as a productivity tool.
- Attackers will use it
- Maintainers will use it
- Developers will use it
- The Business will use it
- Customers will start to use it!
Customers will increasingly expect the reliability and pace it enables. The organisations that thrive won’t necessarily be the ones producing the most code. They’ll be the ones that can increase the rate of change without decreasing trust.
At The Collecting Group , we’re still figuring this out. But it already feels like the conversation is moving beyond “How do we use AI to write more code?” towards…
How do we build engineering organisations capable of thriving when change itself becomes abundant?
I’d love to hear how others are approaching this. Has code review become a confidence exercise rather than a correctness exercise? Are you seeing similar concerns around dependencies, patching and AI-assisted attackers?
Or, have I simply spent too much time staring at agent logs, package manifests and Datadog dashboards?
Olly Brand 