Half of Spotify ’s pull requests are already generated automatically.
Not as a demo. Not in a prototype. In production engineering workflows.
That number made me rethink how software development is changing.
Looking at today’s models and what they can do, I keep wondering how organizations are adjusting software development to this new reality. I have spent more than two decades delivering software. And I do not remember a time when it has been this easy to build – and iterate toward – a working solution that creates real business value.
The democratization of software development
Not long ago, building applications was reserved for highly skilled engineers.
Low-code and no-code platforms tried to democratize the craft. They worked well for small tools. But once an application became large, complex, regulated, or security-sensitive, experienced engineers were still required.
Generative AI changes that equation. Today the first working version can often be produced much faster – sometimes even by less experienced builders – provided they have the right scaffolding: clear requirements, guardrails, and a strong verification loop.
This creates an uncomfortable question for the market. For years, software houses filled capacity and capability gaps inside organizations. But what happens when part of that gap is filled by specialized AI agents rather than external development teams?
Evidence that agent-driven development is already happening
A useful data point comes from Anthropic’s 2026 labor-market research. The report introduces an “observed exposure” metric that combines theoretical LLM capability with real usage patterns.
According to the study, current systems already cover about 33% of tasks in the “Computer & Math” category, while programming roles show exposure up to 75% of tasks.
The key point is not “33% today, 75% tomorrow.”
It is that the structure of work is already shifting.
We also have credible engineering evidence that agent-driven workflows can operate at scale. Spotify has described an internal Fleet Management platform that automates large portions of maintenance work such as dependency upgrades, configuration updates, and simple refactors. Since mid-2024, roughly half of Spotify’s pull requests have been generated automatically.
Later they integrated a background coding agent (“Honk”) into the pipeline. Their engineers report 60–90% time savings for certain migrations and more than 1,500 agent-generated pull requests merged into production.
What is interesting is how the workflow actually looks.
Employees start tasks through Slack or GitHub. A workflow agent gathers context and prepares a prompt. A coding agent generates a pull request. Engineers review the result and request adjustments if needed.
The unit of work remains a reviewable artifact — a pull request — not a magical “done” button.
The governance challenge for technology leaders
Tooling is now aligning with this model.
In 2026, Visual Studio Code introduced multi-agent workflows where developers manage multiple agents in one environment. GitHub Copilot’s cloud coding agent can implement features from high-level descriptions, generate pull requests, and iterate based on code review feedback.
Even here, the process remains fundamentally review-driven and governance-controlled.
And this creates a new challenge for technology leadership.
When agents dramatically increase the volume of generated code, traditional change management and review processes may no longer scale. CIOs and CDOs will need new governance models that keep systems safe without slowing innovation.
For some people, this trend is exciting. For others, it is unsettling.
I find myself somewhere in the middle — trying to understand what is possible while still delivering safe solutions that generate value.
My anchor is simple: We build applications for users, not for developers.
Code does not need to be perfect. It needs to be correct enough, maintainable enough, and safe enough.
From writing code to writing intent
The shift from writing code to writing intent introduces new risks.
Research has shown that AI coding assistants can both introduce security mistakes and increase developer overconfidence. One large study presented at ACM CCS found that developers using AI assistance produced less secure code in most tasks while simultaneously believing their code was more secure.
That observation matches my own experience. The hard part is no longer typing code. The hard part is specifying clearly and verifying relentlessly.
In a recent proof-of-concept where I tried to build an application without writing code manually, several things became obvious.
I switched from coding to writing specifications – and then verifying the generated output. When I invested time in the specification (architecture rules, testing requirements, security constraints), the generated code became much more stable.
Verification also became tiring. Repeated reviews of the same files created “attention decay”: early iterations were detailed, later ones less so.
Initial configuration turned out to be crucial. The more standards were externalized — testing, security policies, architecture conventions — the more predictable the agent became.
This is why spec-driven development resonates with me.
The approach recognizes that “vibe coding” works well for prototypes but becomes unreliable for serious systems. The specification becomes a living source of truth.
The security boundary
Security remains the area where I am least willing to “delegate and forget.”
Authentication and authorization are good examples. They are critical components that are easy to implement incorrectly and often written only once during the lifetime of an application.
When I prototyped these flows with an agent, it required multiple iterations before the solution looked correct – and I still wanted a human-grade review before trusting it.
This is a reminder that even in agent-driven development, accountability cannot be automated away.
Three levels of agent maturity
So the real question becomes: Where are you in this transformation?
I increasingly see three maturity levels emerging.
- Accelerated autocomplete – AI predicts the next line or block of code.
- Synchronous agents – Developers collaborate with agents during implementation using natural language.
- Asynchronous agents (agent workflows or swarms) – You hand over a specification, agents work independently for longer periods, and return a working solution for review.
The last level is not “hands-free software development.” It is hands-on intent and governance.
If agents can generate code faster than humans can review it, the real constraint in software development shifts from creation to governance and verification.
That raises a few uncomfortable questions for technology leaders:
- Where do you draw the delegation boundary? Which parts of your system are acceptable for agent-generated code – and which require human authorship?
- What becomes your control point? If code volume increases dramatically, do you govern through code review, automated tests, architecture constraints, or executable specifications?
- What is the new unit of accountability? When an agent produces a pull request, who ultimately owns the decision to merge it?
- How does your operating model change when development speed is no longer the bottleneck? Do your security, QA, and change-management processes scale to this new pace?
The organizations that answer these questions early will likely gain a major advantage.
Those that do not may discover that their governance model – not their technology – becomes the real constraint.
I would genuinely like to hear how others are approaching this transition. Or are you already experimenting with something beyond that?
Leave A Comment