Description
Overview
AI coding tools (LLMs, code assistants, AI agents) are rapidly becoming part of the developer workflow across the software industry. Open source communities are beginning to grapple with how these tools intersect with their development processes โ from code generation and review assistance to documentation, debugging, and large-scale refactoring. This microconference will bring together maintainers, developers, and tooling experts to discuss the practical realities, policies, risks, and opportunities of AI-assisted development in the open source ecosystem.
The goal is not to debate whether AI tools will be used โ developers are already using them โ but to align on how communities should adapt their processes, what guardrails are needed, and where these tools can deliver the most value with the least risk.
Example Subtopics
- AI-assisted code generation and review โ practical experiences, failure modes, and disclosure norms
- Large-scale refactoring with AI assistance, such as C-to-Rust conversions
- AI for debugging, crash analysis, and root cause identification
- Policy and process implications: attribution, copyright, licensing, and trust in AI-generated contributions
- AI-powered test case generation and fuzzing guidance
- Building project-aware AI tooling with domain-specific context and integration with existing development infrastructure
Key People Who Should Attend
- Major subsystem and project maintainers who are receiving AI-assisted contributions and need to make policy decisions
- Developers actively using AI tools in their open source workflows who can share real-world experiences
- AI tooling developers building tools targeted at open source and systems-level development
- Linux Foundation / legal experts for the policy, licensing, and attribution discussion
Previous Related Sessions
While there has not been a dedicated AI microconference at LPC before, related discussions have touched on adjacent topics in microconferences such as Kernel Testing & Dependability, Rust for Linux, and Toolchain. This would be the first session to bring together the AI-specific cross-cutting concerns that span all of these areas.
Expected Outcomes
- Community alignment on disclosure and attribution requirements for AI-assisted contributions
- Identification of high-value, low-risk use cases where AI tools should be encouraged
- Concrete next steps for building project-aware AI tooling
- Framework for evaluating AI-generated code in the review process
-
Roman Gushchin (Google)06/10/2026, 10:00
Current status of Sashiko. Also in this block: #140 "Citation Needed: Treating the kernel's AI review context like code" (Fuad Tabba), and Chris Mason and others on review prompts.
Go to contribution page -
06/10/2026, 10:45
Open discussion with everyone: feedback on Sashiko and feature requests.
Related talks: #140 Fuad Tabba (Google); #166 Andrea Righi (NVIDIA); #298 Konstantin Sinyuk (Intel)
Go to contribution page -
Aleksandr Nogikh (Google)06/10/2026, 11:15
[Syzbot][1] reports around 2,000 new fuzzer-detected findings in the Linux kernel each year. Even for straightforward bugs where the root cause is obvious, the manual effort of drafting, testing, and sending patches constitutes a significant effort on the kernel developers side.
To facilitate this process, we have launched an AI-assisted fix generation [workflow][2] in syzbot built around...
Go to contribution page -
Andrea Righi (NVIDIA)06/10/2026, 12:00
AI-assisted tooling is increasingly becoming part of Linux kernel development workflows, particularly for patch review and feedback generation. Sashiko has become the de facto standard for reviewing publicly posted patch series on mailing lists.
While Sashiko can also be used beyond the mailing-list workflow, its design is primarily optimized around upstream review interactions. This can...
Go to contribution page -
Jarod Wilson (Red Hat)06/10/2026, 12:15
The Problem: CVEs
Go to contribution page
- CVEs: Common Vulnerabilities and Exposures
- February 2024, Linux kernel project becomes the Linux kernel CVE Numbering Authority (CNA)
- The number of Linux kernel CVEs skyrockets
- Red Hat customers expect CVE fixes/mitigations, with some having Service Level Agreements for delivery within X number of days, depending on severity
- Red Hat did not get an increase in... -
Yuan Tan (NebuSec)06/10/2026, 12:30
AI-assisted tools are producing an increasing number of Linux kernel bug findings. While these tools can uncover genuine bugs, many findings still require validation before they can be treated as actionable issues. Reports may be false positives, lack a working reproducer, duplicate existing issues, or fail to trigger under the reported conditions.
We would like to share our experience...
Go to contribution page -
Josef Bacik (Facebook)06/10/2026, 12:45
Open discussion led by Josef with the audience on using AI fix generation effectively.
Related talks: #447 Aleksandr Nogikh; #482 Yuan Tan; #315 Jarod Wilson
Go to contribution page -
Mr Wander Costa (Red Hat)06/10/2026, 13:00
Analyzing kernel crash dumps with drgn is powerful but demands fluency in drgn's Python API, kernel data structure layouts, and the right helper functions for each subsystem. drgn-mcp is an MCP (Model Context Protocol) server that exposes drgn's debugging capabilities as structured tools that AI assistants can call, enabling kernel developers to investigate crash dumps through natural language...
Go to contribution page -
Josef Bacik (Facebook)06/10/2026, 13:15
Session wrap-up and next steps.
Go to contribution page -
Fuad Tabba (Google)
AI patch review is already here. Sashiko, the reviewer bot now running on many of the kernel's mailing lists, finds real bugs. On a hard subsystem it also invents them: an architectural detail that does not exist, reported confidently as a bug. Marc Zyngier described this on the list recently. An agent that gets "creative about specifications" is particularly annoying, he wrote, because the...
Go to contribution page