The slide that made me stop in Prague
In the opening keynote block at Open Source Summit Europe 2026 in Prague, a slide from the 2026 State of Open Source in Europe research stood out:
94% of European organisations are already using or piloting generative AI coding tools.
My October 7 photos capture the figure on the conference screen. It is striking, but it needs to be read carefully.
The Linux Foundation’s October 7 announcement confirms the statistic. This is survey-reported organizational adoption or experimentation — not evidence that 94% of European developers use AI every day, that 94% of code is AI-written, or that enterprise rollouts are mature.
That distinction changes how engineering leaders should act on the data.
At the opening keynotes in Prague, where the AI coding adoption figures were presented. Photo: Luca Berton.
AI coding has crossed from experiment into the toolchain
The Linux Foundation’s 2026 report presents three findings worth separating:
| Reported result | Interpretation |
|---|---|
| 94% use or pilot generative AI coding tools | AI assistance is present somewhere in most surveyed organizations |
| 76% say generative AI coding tools increase the value they derive from open source | Many respondents see an improvement in their ability to use existing OSS |
| 48% increased open source usage as a result of generative AI | AI assistance is reshaping how some teams find and integrate dependencies |
The research does not, from those headline numbers alone, establish productivity gains for every team or improved code quality for every deployment.
Still, the effect on the software supply chain is significant. AI tools can propose snippets, explain unfamiliar APIs, generate test scaffolding, and suggest whole libraries. That reduces friction — but it also changes how developers discover, evaluate, and contribute to open source.
The new challenge is quality, not tool access
A developer with a coding assistant can generate five implementations of a service in minutes. The hard part is deciding which implementation should reach production.
For example, imagine an agent asked to add authentication to a Kubernetes-facing web service. It might produce a working demo while overlooking:
- Secret rotation and minimum RBAC privileges.
- Credential handling in logs or telemetry.
- Dependency versions, licenses, and known vulnerabilities.
- Retry storms and failure modes under load.
- Security boundaries between tenants.
- Test coverage for unauthorized access and configuration drift.
An AI-generated pull request can be syntactically correct and still be an operational liability.
That is why “we enabled AI coding” should not be a platform engineering milestone. The milestone is a reliable, reviewable workflow that benefits from AI.
A production-ready AI coding workflow
My baseline for enterprise teams is to make the AI assistant just another source of proposed code — one that never bypasses the same checks as a human change.
Issue or engineering requirement
|
v
AI-assisted implementation
|
v
Developer reviews intent, design and dependencies
|
v
Unit + integration + security tests
|
v
SBOM / license / secret / policy checks
|
v
Human approval of the pull request
|
v
Signed build + deployment + observability1. Establish data-handling boundaries
Specify which repositories, documents, logs, credentials, and customer data an AI tool may access. Decide when local models or private endpoints are necessary. Review retention and training settings with security and legal stakeholders.
A tool that writes excellent code but copies secrets or regulated data into the wrong system is not enterprise-ready.
2. Require transparent dependencies
Generated code often solves a problem by importing a package the developer has never evaluated. Require a dependency review with license and maintenance checks. Use lockfiles, reproducible builds where possible, an SBOM, and automated dependency monitoring.
A dependency introduced by AI is still your organization’s dependency.
3. Test behavior, not just compilation
Generated unit tests can be useful, but they may reproduce the model’s assumptions rather than challenge them. Add boundary and negative tests written from the requirement. In platform code, test failure handling, isolation, resource limits, and upgrades.
4. Keep maintainers out of automated noise
AI makes it easy to submit a patch or vulnerability report with almost no effort. That is not always a benefit to maintainers. Require a reproducible case, an explanation of impact, an understanding of project contribution rules, and human review before opening an upstream issue or pull request.
More submissions are not the same as more useful contributions.
5. Measure outcomes
Track accepted changes, lead time, defect escape rate, security findings, dependency growth, rework, and reviewer time. Avoid relying on generated-line counts or suggestion-acceptance rates as your only success metrics.
AI and open source governance are now the same conversation
The report found that 31% of surveyed European organizations still had no formal open source governance framework. At the same time, 63% reported increasing investment in open source dependency management because of regulatory pressure.
Combine those figures with near-universal AI experimentation and a clear organizational challenge appears: the speed of proposing new code is growing faster than many teams’ ability to govern and maintain it.
A lightweight AI coding policy should be part of the same engineering playbook as open source dependency policy. In practice that means defining:
- Which tools and models are approved, and for which data classifications.
- Who owns generated code, its review, and its production behavior.
- How dependencies and external code suggestions are checked.
- How prompts, review decisions, and important changes are documented when required.
- How contributors avoid polluting public projects with unverified automated reports.
This is not an argument against AI. It is how organizations can use it more confidently.
Where open source offers a particular advantage
AI-powered development can be more transparent when the toolchain has inspectable components: open model weights where licensing permits, self-hosted inference, auditable evaluation harnesses, open standards, and visible CI checks. Those choices are useful for sovereignty and security, but open source alone does not guarantee privacy or reliability.
What matters is whether your team can test the system, understand its dependencies, and replace components without losing control of development workflows.
The future of developer experience is unlikely to be “everyone types less.” It is more likely to be teams spending less time on repetitive implementation and more time on requirements, architecture, review, and operations.
My takeaway from Open Source Summit Europe
That 94% slide was not a victory lap for AI-written software. To me, it was a reminder that AI coding is already part of the open source ecosystem’s everyday operating environment — and governance now needs to catch up.
Organizations that succeed will make AI-assisted development reviewable, secure, repeatable, and compatible with upstream communities. Organizations that measure only how much code an agent can produce risk accumulating a maintenance problem at machine speed.
For the broader event story, read my Prague summit recap. For the governance side, see Digital Sovereignty at Prague 2026 and AI Coding Agents and Platform Engineering.
Sources: Linux Foundation Europe research announcement, October 7, 2026 · 2026 State of Open Source in Europe · Open Source Summit Europe 2026
