The Code Nobody Wrote

In my last two articles (found on Linkedin), I drew on research from the World Economic Forum (WEF) and Anthropic to argue that AI is not coming for the channel as a whole, but for the one-dimensional parts of it, faster than most partner programme designs acknowledge.

 

I also argued that there is a window. A gap between what AI can theoretically do and what it is actually doing in professional settings today, and the leaders who use that window deliberately will redefine their competitive landscape.

 

This week, I want to make that argument concrete. A vivid illustration of what this transition actually looks like is not in an economist’s model or a think-tank report, but happening right now, inside the engineering organisations of the technology vendors that partner ecosystems are built around.

 

This should change how you think about your product strategy, your partner enablement, your security posture, and the pace at which you expect everything around you to move.

 

Two years ago, a senior software engineer typically split their week across a predictable set of tasks: writing code, reviewing code, debugging code, and making architectural decisions. Today, AI coding agents handle the first three. Spotify ‘s co-CEO stated it plainly on their Q4 earnings call. The company’s best developers have not written a single line of code since December.

 

That is a clarion call which connects directly to what the Anthropic labour market research I covered last week found: computer programmers register 74.5% observed AI exposure, the highest of any occupational category in the study. The researchers noted that the leading automated task for that group is writing, updating, and maintaining software programmes. The Anthropic data and the Spotify anecdote are telling the same story from different angles.

 

What’s emerging across the smartest engineering organisations is a fundamental reprioritisation. The human role in software development is shifting from writing code to designing systems, choosing infrastructure, and deciding how services interact. The phase where humans still exercise genuine judgement is moving upstream — to architecture, to design, to the decisions that determine how a system behaves before a single line is generated.

 

Innovation cycles are compressing dramatically as a result. A feature that previously consumed two full development sprints now ships in days. The velocity that technology vendors and more significantly their partners can bring to market has accelerated by an order of magnitude.

 

For leaders of B2B technology businesses, this is not background noise. This is the ground shifting beneath your product strategy, your go-to-market motion, and your partner ecosystem simultaneously.

 

Here is where the story gets more complicated and more urgent.

 

The acceleration of AI-generated code is running directly into a structural vulnerability that predates it. Product security engineers are outnumbered by developers 300-to-1 at most technology companies.

 

That ratio existed before AI code generation tripled the volume of code being produced. CrowdStrike ‘s 2024 State of Application Security Report found that over half of all major code changes (50% median, 54% mean) do not undergo full security review.

 

Those numbers were already uncomfortable. Add AI-generated code at scale, and the arithmetic becomes troubling.

 

The pattern the WEF described — technology advancing faster than human oversight can keep pace — is playing out in real time in the software security domain. The capability gap is not just between what AI can do and what it is doing. There is a second gap: between the speed at which code is being generated and the speed at which it is being reviewed, tested, and hardened.

 

Let’s be direct about why this matters for partner and channel leaders, because the implications extend beyond what is typically framed as a ‘vendor engineering problem’.

 

Partners are building practices on products that are moving faster than ever, with a widening security surface.

 

The compression of innovation cycles is genuinely good news for a significant portion of this ecosystem. Partners who build managed services around products will have more to offer customers, faster. The velocity of new capability creates new conversations, new upsell opportunities, and new reasons for customers to invest in the expertise that a good partner brings to deployment and adoption.

 

But that same velocity means the product your partners certified on six months ago may bear limited resemblance to the product they are selling today. Partner enablement programmes designed around annual certification cycles are structurally misaligned with a product development cadence that now operates in days. The partners who will thrive are those who build continuous learning capability into their operating model.

 

The security exposure in your ecosystem is a partner programme problem, not just a product problem.

 

When over half of major code changes are shipping without full security review, and the volume of code generation is accelerating, the downstream consequence lands in your customers’ environments. Your partners are frequently the first line of human response when a vulnerability is exploited. They are the ones who receive the call. They are the ones managing the incident response conversation with a CISO who is looking for answers.

 

FIRST’s (Forum of Incident Response and Security Teams) 59,000 projected vulnerabilities for 2026 are not abstract. They are future support tickets, future incident calls, future conversations about whether your technology can be trusted at enterprise scale. The partners in your ecosystem who have invested in genuine security capability, not just a security certification, but a practice, a methodology, a team, are building the most durable competitive moat available in the current environment. The ones who haven’t are accumulating a liability they may not yet see on their balance sheet.

 

The shift from writing to designing is the same shift we identified in the channel in my last article.

 

What is happening in engineering organisations is structurally identical to what the Anthropic research identified happening in sales, customer service, and marketing roles across the economy. The tasks that AI automates are the repeatable, pattern-following, execution-layer tasks. The tasks that remain become more consequential as a result, requiring genuine judgement, contextual understanding, and the ability to make consequential decisions in conditions of ambiguity.

 

In software engineering, that means architecture and design. In the channel, it means trusted advisory relationships, business outcome consulting, and the ability to sit in a room with a customer and actually understand what they are trying to achieve.

 

The partners who are investing in that kind of depth – in their people, in their methodologies, in their customer relationships – are equipping themselves to survive the AI transition and becoming more valuable as the execution layer around them is automated. The partners who are not will discover that the tasks which previously justified their margin are the tasks that AI is doing first.

 

If you run a partner programme, the software engineering parallel surfaces an uncomfortable question about your product organisation, or that of the vendors you rely on as a telco, distributor, aggregator.

 

How much of your go-to-market investment is predicated on product stability and predictability that the upstream engineering velocity is quietly undermining? How are you assimilating and communicating accelerated release cycles to the partners who have built practices, certifications, and customer commitments around previous versions? Are your partner enablement investments keeping pace with your development cadence or are you asking partners to sell and support a product that is evolving faster than you are enabling them to understand it?

 

The security dimension is even more direct. If your product has a 54% rate of major changes shipping without full security review, your security-specialised partners will eventually be managing the consequences. The ones who are good — the ones you most want recommending and deploying your technology — will notice. And the ones who notice will make decisions accordingly, about where they invest their practice-building effort, about which vendor relationships they prioritise, and about what they tell their customers.

 

The most consequential architectural decisions in software now happen before the code is generated. The most consequential decisions in partner programme design happen in the same place: upstream, in the design of the ecosystem, before the execution layer runs.

 

Both the WEF and the Anthropic research point to the same underlying truth. Technology changes the execution layer faster than it changes the judgement layer. Organisations and ecosystems that understand this and invest accordingly will navigate this transition well.

 

Those that are waiting for the dust to settle are already behind.

 

This is the third in a series of articles examining AI’s implications for leaders of B2B technology businesses that depend on partnership ecosystems and channel models. The previous articles drew on research from the World Economic Forum and Anthropic’s Labor Market Impacts of AI report.

 

The conversation continues on this site.