Engineering managers, VP Engineering, and tech leads at SaaS companies where developers are already using AI coding tools informally without a written policy. Spotify's co-CEO disclosed on the Q4 2025 earnings call that its senior engineers have not written manual code since December, using Claude Code and an internal AI system called Honk. That disclosure is now the named public benchmark your board and investors will reference.
Every engineering organisation has a version of the same informal decision: a developer starts using an AI coding tool, recommends it to a colleague, and within a quarter it is embedded in the workflow without anyone having answered who owns the IP on generated code, which data the tool processes, or whether the company’s contracts allow it.
On February 12, 2026, Spotify co-CEO Gustav Söderström disclosed during the company’s Q4 2025 earnings call that the best developers at Spotify “have not written a single line of code since December,” using an internal system called Honk, built on Anthropic’s Claude Code, that lets engineers fix bugs and ship features from a phone on a morning commute.1
Relve rates this 75/100, a meaningful signal for Engineering managers and tech leads at companies where AI coding tool adoption is already happening informally and a written policy has not been produced because nobody wanted to be the person who slowed the team down.
The Spotify disclosure is not a productivity story. It is a policy story. The question it forces for every Engineering manager is not whether to adopt AI coding tools. That decision has already been made informally by someone on the team. The question is whether the adoption is documented before a board member, a client, or a legal dispute asks who owns the output.
Spotify’s no-code engineering disclosure is one of three moves that pushed founders into three simultaneous policy decisions this quarter. The series also covers Marketing, Ops, and Creative.
How AI Coding Went From Individual Habit to Named Enterprise Benchmark
The shift from AI-assisted coding to AI-generated coding happened faster than most engineering organisations formalised a response. GitHub Copilot launched in 2021 as an autocomplete tool.
By late 2025, Spotify’s most senior engineers were generating entire codebases from a prompt without opening an IDE. That is not a marginal productivity improvement. It is a role change.
Spotify’s internal Honk system, built on Claude Code workflows, enables engineers to trigger code changes directly from Slack on a mobile phone during a commute. Söderström said on the earnings call: “An engineer at Spotify on their morning commute from Slack on their cell phone can tell Claude to fix a bug or add a new feature to the iOS app.”
Spotify shipped over 50 features in 2025 while managing 761 million monthly active users. That output figure validates the productivity claim in a way a blog post cannot.
The earnings call disclosure matters specifically because of where it was made. A co-CEO stating this on a public earnings call is not a developer blog post or a conference talk. It is a board-level signal.
Boards and investors read earnings transcripts. When a board member at your company asks about AI coding tool adoption, they will have read the Spotify disclosure. The question is whether your Engineering manager has a written answer ready or is constructing one under pressure.
Spotify is not alone. Shopify CEO Tobi Lutke circulated an internal memo in April 2025 requiring teams to prove AI cannot do a task before requesting new headcount.2 Amazon, Google, Microsoft, and Salesforce all cut engineering headcount in early 2026 while simultaneously increasing AI investment.
The AI agent deployment timelines that were measured in months 18 months ago are now measured in weeks. Spotify’s disclosure is the most public confirmation of a shift that is already underway at scale.
Four stages of AI coding tool adoption and where enterprise engineering is now:
- Stage 1 and Autocomplete (2021–2023): GitHub Copilot suggests the next line. Developer writes, AI assists. IP ownership question is simple: the developer wrote it.
- Stage 2 and Chat-assisted coding (2023–2024): Developer describes what they want, AI generates a block. Developer reviews and approves. IP question gets harder: who owns a function the developer did not write?
- Stage 3 and Agentic coding (2024–2025): Developer writes a prompt, AI generates multiple files, opens pull requests, and runs tests. Developer reviews output, not code. IP question is unresolved at most companies.
- Stage 4 and Full session generation (December 2025–): Senior engineers at Spotify have not written manual code since December. AI generates all code. Engineers design, prompt, and review. IP question is now a board-level liability if it has not been answered in writing.
Spotify shares rose 14.7% on Q4 earnings day.3 Investors priced in the operational leverage of AI-assisted development before most engineering teams had a policy discussion about it. The market already has a position on what this capability is worth. Engineering organisations that have not formalised a policy are not neutral. They are carrying undocumented exposure on a category the market has already valued.
Posts from the r/technology community on Reddit
A METR study on AI coding productivity found that perceived gains diverge significantly from measured ones in controlled conditions. The study used early 2025 models, not the December 2025 tools Söderström referenced. The Spotify claim is real. The METR finding is also real. Engineering managers adopting at pace should build measurement into the pilot rather than taking either data point at face value.
Three Engineering Decisions the Spotify Disclosure Made Unavoidable
An Engineering manager is preparing for a board meeting. A board member has read the Spotify disclosure and asks: “Our senior developers are using AI coding tools. What is our policy on IP ownership for code they generate?” The Engineering manager does not have a written answer.
The tools were adopted informally six months ago because they made the team faster. Nobody stopped to write down who owns what the AI produces. That undocumented adoption is not a technology failure. It is a policy gap that was invisible until the board asked the question.
| Dimension | Before February 12, 2026 | After February 12, 2026 |
|---|---|---|
| AI coding tool adoption at enterprise scale | Informal, individual-level use without a named public benchmark at a major company confirming full session-level adoption | Spotify’s Q4 2025 earnings call creates a named public benchmark and boards and investors will now reference it when asking about engineering productivity and tooling policy |
| IP ownership of AI-generated code | Ambiguous and most engineering teams using AI coding tools had not answered this question formally in writing | Spotify’s disclosure elevates the question to board level and any engineering team without a written IP position is carrying undocumented liability on every AI-generated line in production |
| Developer role definition | Senior developer defined by coding output and lines written, PRs opened, features shipped by hand | Bottleneck has moved from writing code to reviewing, prompting, and designing agent workflows and evaluation criteria for hiring and performance assessment need revisiting |
| Sprint velocity measurement | Velocity measured by story points per sprint assuming human-written code at standard output rate | AI-assisted development changes the baseline and 50+ features shipped in 2025 at Spotify with 7,323 employees sets a new reference point for output-per-head expectations |
Decision 1 and Write the AI Coding Tool Policy Before the Board Asks for It
The policy does not need to be comprehensive. It needs to exist in writing before someone outside the engineering team asks the question. Söderström said it plainly: “When I speak to my most senior engineers, the best developers we have, they actually say that they haven’t written a single line of code since December.” That statement is now in the public record.
A board member or investor who reads it will ask whether your team has the same capability and whether it is governed. Three items are sufficient for a first-version policy.
First, the approved tools list: which AI coding tools are approved for production use. Claude Code, GitHub Copilot, and Cursor are the three with the most enterprise deployment evidence. Second, the IP ownership position: who owns code generated by approved tools under the company’s contract tier with each vendor. Third, the review date: a six-month trigger to revisit. Not a permanent rule.
Three things the AI coding tool policy must answer in writing:
- Approved tools: which AI coding tools are approved for use in production codebases. Claude Code, GitHub Copilot, and Cursor are the three with the most enterprise deployment evidence. Name which are approved, not which are banned.
- IP ownership: who owns code generated by approved AI tools under the company’s contract tier with each vendor. Check each vendor’s terms for the specific tier the company is on and IP terms vary between free, standard, and enterprise tiers.
- Review date: a six-month trigger to revisit the policy. Not a permanent rule. The tooling landscape and vendor terms are changing fast enough that a permanent answer written today will need updating before year end.
Decision 2 and Benchmark AI-Assisted Velocity Before Resetting Hiring Assumptions
Most engineering teams adopted AI coding tools without capturing baseline velocity data before adoption. Output increased, but because no measurement was in place beforehand, the gain cannot be quantified with confidence.
That gap becomes a problem when a headcount decision needs to be justified or when a board member asks what the team’s output-per-head actually is compared to Spotify’s. A 30-day pilot on one service, measuring four numbers, produces the data the policy review will need in six months.
Spotify shipped over 50 features in 2025 with 7,323 full-time employees globally at a record 33.1% gross margin. That output-per-head figure is what boards will cite as a reference point. Engineering managers who have not run a velocity benchmark cannot answer the comparison with confidence.
Revising hiring criteria for senior engineering roles is a six-month policy review item, not an immediate action. The Spotify disclosure changes what the criteria should measure, but rushing a criteria change before the team has run a velocity benchmark produces the wrong criteria. Measure first, then revise.
Decision 3 and Define What Human Review of AI-Generated Code Actually Means
The productivity paradox named in the research is specific: software is being generated faster than humans can sometimes validate it, shifting pressure from writing code to reviewing and approving it. Most teams applying AI coding tools at scale are using the same review process they used for human-written code.
The volume and pattern of AI-generated output is different enough that the same process does not produce the same quality guarantee.
The review standard for AI-generated code needs to answer three questions before any team scales adoption. What does an adequate review pass look like? How many review cycles does AI-generated code require versus human-written code? Who is responsible for security review of AI-generated code before it reaches production? None of those questions have been answered in writing at most companies using AI coding tools today.
Spotify’s engineering leadership named the risk directly: software is being generated faster than humans can sometimes validate it. Shipping AI-generated code without a defined review standard is not an engineering productivity decision. It is a quality and security decision being made by default. Define the review standard before the output volume makes a retroactive standard impossible to enforce.
What Most Engineering Managers Are Getting Wrong About This Disclosure
Spotify hit a record 33.1% gross margin in Q4 2025. That is the number that explains the disclosure.
A company that ships 50+ features while holding 7,323 employees and expanding margin simultaneously is not doing so with the same cost structure as a company where senior developers write all their own code. The no-code disclosure is the operational explanation for how those three numbers coexist.
Most coverage framed this as a productivity story or a jobs replacement story. The more useful read is a cost structure story. Engineering teams with formal AI coding tool adoption are on a fundamentally different cost curve per feature shipped. That is not a prediction about the future. It is what the Spotify Q4 numbers describe now.
Söderström’s warning is the part most Engineering managers are not accounting for: “The tricky thing is that we’re in the middle of the change, so you also have to be very agile. The things you build now may be useless in a month.” That is not a caution about AI quality.
It is a caution about over-engineering the policy response before the tooling has stabilised. The METR study finding that perceived gains diverge from measured ones supports the same caution. Write a policy with a six-month review trigger. Do not build a permanent infrastructure mandate around tooling that is still changing weekly.
The Decision Engineering Cannot Keep Deferring
The policy answers three questions in writing: which tools are approved, who owns the IP on generated code, and when the policy is reviewed. It does not need to be comprehensive. It needs to exist before a board member, a client, or a legal dispute asks the question.
- Name the approved AI coding tools and Claude Code, GitHub Copilot, Cursor, or a named alternative. List only what is approved.
- Check each approved tool’s vendor contract for IP ownership terms at the tier the company is on and free, standard, and enterprise tiers have different terms
- Confirm data residency: where is source code processed and stored under each vendor’s infrastructure?
- Set a six-month review trigger date, not a permanent rule. Name the person who owns the review.
- Brief the engineering lead and the legal team before publishing, not after
The benchmark captures the data the policy review will need in six months. Pick one service or workflow. Measure four numbers before and after AI coding tool adoption. Do not reset hiring assumptions or sprint baselines before this data exists.
- Pick one greenfield service or one maintenance workflow, not both simultaneously
- Measure four numbers for 30 days: PRs per sprint, review time per PR, time from spec to deployment, engineer hours spent on manual coding vs reviewing AI output
- Define the review standard for AI-generated code before the pilot starts and what does an adequate review look like? How many passes? What does a reviewer check for?
- Output: a written benchmark result that becomes the baseline for the six-month policy review and any hiring criteria revision
The AI coding tool landscape will have changed enough by October to December to warrant a full policy review with real data rather than estimates. Run the review against three inputs: the velocity benchmark from August to September, updated vendor terms for each approved tool, and any new tooling that has reached enterprise deployment evidence since June.
- Pull the velocity benchmark data from the 30-day pilot and compare against the pre-adoption baseline
- Check each approved tool’s vendor terms for any changes to IP ownership, data residency, or pricing since the policy was written
- Review the approved tools list against any new entrants that have reached enterprise deployment evidence in the past six months
- Revise hiring criteria for senior engineering roles based on the benchmark data, not before it
- Publish the updated one-page policy with a new six-month review date
Bottom Line
The Spotify disclosure did not create an AI coding tool adoption question for engineering teams. It made the existing undocumented adoption visible by putting a named public benchmark on what formalised adoption looks like at scale.
Most engineering managers will treat this as a story about Spotify’s productivity. The managers who treat it as a policy trigger will have written answers before a board member, client, or legal team asks for them.
The practical advantage goes to teams that write the one-page policy in June to July and run the velocity benchmark in August to September. Both steps happen before any board question, client audit, or IP dispute makes the documentation urgent rather than optional.
Engineering managers who write a one-page AI coding tool policy in June to July and run a velocity benchmark in August to September will have documented answers when a board member, client, or legal dispute asks who owns the code and how much faster the team actually is; those who leave adoption informal will be answering those questions under pressure without data.
References
2 Let’s Data Science, “Spotify Developers Haven’t Written Code Since December,” March 27, 2026.
3 Pressvia, “Spotify developers stop manual coding for AI orchestration,” February 15, 2026.
