PyCon US 2026 Recap

Table of contents:

• PyCon from my seat: a Dawn-focused view of the event.
• Security-first, local-first
• Python Advancement
• Where Python Runs: a placeholder stub for future blog posts
• AI Adoption
• Who is the AI Engineeer?
• Our Trusted Software Foundations' Reticence to Pick up The AI Cause

There are a few themes I saw at PyCon US:

• (1) Practical adoption of AI
• (2) Pin your dependencies, audit your packages / make security accessible to everyone
• (3) Traveling to the US was too high of a barrier to much of our community
• (4) To cut through the noise, companies are trying to reach us in person

I discuss a few of these themes and explore others in my conference recap.

The hallway track had a overarching sentiment of concern and confusion. The tides have turned in the last decade where bootcamp grads could stumble into their first full-time developer job after a 6-month program. Now, with a cascade of massive layoffs every 6-18 months, every developer felt dispensable. It is about output, productivity, and momentum. Missing from the equation outside of the conference is consistency, caution, and developer training; which PyCon US tried to bring it back. We're all expected to lasso the AI bull without a manual. The anxiety in the conversations were palpable with the sentiment hitting more junior, more severely.

Despite the general consternation about the state of the industry, the community spirit was there. Three of the four keynotes strongly rebuked AI-slop and encourage revisiting time-honored truths of open source software: we build software for the same reason we build community, to solve human-centered problems.

We're at a huge moment in Anaconda's trajectory. We're stepping back into developer tools that solve the most frustrating onboarding considerations for Pythonistas. Just as Anaconda Navigator (classic GUI experience shipped with the Anaconda Distribution) helped scientists, data scientists, analysts and domain experts to wrangle their Python environment then get out of their way for advanced Python needs -- resilient environments across hardware, operating system, toolchain, runtime; we're doing the same for adding non-deterministic, model artifacts in your software.

The Anaconda product launch gives the key to how the experts in advanced computing in Python thinks the ecosystem can go about it, themes we've had for the last 13 years:

• Local-First, Cloud and Architecture as needed (Anaconda Desktop, Outerbounds Acquisition)
• Rapid Experimentation (Anaconda Agent Studio, conda-pypi partnership with the ecosystem)
• Build how you want (Anaconda CLI, conda-pypi partnership with the ecosystem)
• Trusted Artifacts and thoughtful guardrails (Anaconda Models, Anaconda MCP)

I had a lot of conversations about the tools people are using. I created Building Intelligent Apps with Anaconda 10-part module taking the Anaconda ecosystem from conda first-principles (why conda?) and exploratory data analysis (EDA) to multi-agent architecture with an evaluation loop. Demo-led developer adoption was incredibly helpful.

The past 4 years, I've been building community and unblocking developers as they invoke Python at runtime. The way I learn, I pull back the layers to share what's happening lower in the stack:

• Why is Python on Windows different than Python on Linux?
• Python module distribution is getting harder for the maintainer, catering to the increased expectations in developer experience; how do maintainers collaborate and simplify?
• Where can Python run? WebAssembly and on-device are platforms that actively being explored

The past year, I've gotten deeper into the levels of abstraction from physical hardware to user intentions:

• Extensions that bypass runtimes?
• Layers that are substitutes for each other
• Novel hardware for unusual purposes

I spoke about this in more in my talk How many spoons does your environment cost?.

Historically these considerations were where scientific computing tool builders provide solutions for the scientific Python community -- the work is not done. The community actively working within the Core Python governance to build new solutions and upstream existing solutions for the huge, multifaceted group under the "Scientific Python" umbrella. I am honored to have led a panel for Scientific Python Panel.

I made so many friends and it was a pleasure to see them shine in every corridor of the conference. Authenticity, Authenticity, Authenticity:

• DEI Panel
• Djangonaut Space Keynote
• Hope Keyote
• CPython Keynote

The average developers feels typically unprepared to know "best practices" in their own software set up. It was common for people in the hallway track to know about the LiteLLM/Trivvy and other GitHub credential supply chain attacks. The fear isn't paired with enough actionable insights; many times thats an awareness gap, but with the rapidly changing landscape its hard to know whats enough.

Repeat after me: "Security is a practice, not a product" -- or a practice and a product.

Do what you can: pin and audit your dependencies is the start.

Developers who used to stick their head in the sand, use sensible defaults and be a small enough target to not be in hacker cross-hairs, are more actively considering how to adopt best practices in their tools. A continuation from 2FA push of the last few years, a headlines were "pin and audit your dependencies" and "enable and seek out Trusted Publishing."

Sovereign AI, owning ones stack and control of the full application, has been showing up more and more in my conversations. This is a spectrum rather than a singular checkbox that aims to give control, visibility, reproducibility, and no data egress. For individual developers looking for control when there's rapid iteration and experimentation, they're reaching for local-first tools and small language models.

One of the best parts of PyCon is to hear from the maintainers. This year was particularly sensitive to the fact that CPython and the work of the Python community can feel behind-the-scenes and secret, and where news is shared its not easily digested.

Core Dispatch: A new podcast devoted to the regular digest of Python core development. PyPodCats, Core.py, Python Bytes and (shameless plug) Sad Python Girls Club returning this summer.

DPO Alternatives / Solutions: discuss.python.org is notoriously hard to digest and follow along. The time it takes to catch up on threads, the format for even-handed discussions and tenor of the conversations exclude the curious novice and burn out the experts.

What are people watching in the Python ecosystem? Packaging seemed to be a less contentious year.

• PEP 703 - Making the GIL Optional (Free-threaded Python)
• PEP 810 - (The Bakery / wheel variants)
• Lockfile spec (not yet a PEP)
• PEP 751 - Lockfiles
• PEP 723 - Package Metadata

I'll have a separate blog post diving into this more, but I'm excited about WebAssembly and edge compute.

Is AI inevitable? If I posit "yes," I think it removes the agency of individual developers to choose how they build and invalidates any paths to just not. It also just accepts the active harm AI is causing as inevitable and forgets the non-deterministic systems that existed before 2023. But it is everywhere, hard to avoid and reduces the friction for lots of developers. I'm not in the betting business, but I think there will be a practical application that follows this hype wave and we'll point AI to the tasks that are otherwise inaccessible or burdensome.

More time for fun things? Early indications say, "no." We're just working more and with fewer breaks (source: https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-workers-time-uc-berkeley-haas-researchers-found-the-opposite)

AI productivity tools are nearly unavoidable, with it being integrated into every search engine and remaining close to a chat interface.

In three of the four keynotes, the massive increase in code contributions -- pull requests, contributors and lines of code were discussed without seeing an increase in quality. The metrics we used to understand directionally the health of a community are now not serving us. It illustrates a real bottleneck in human systems and a threat vector from a security standpoint (more code, more opportunities for security issues especially with unreviewed code or widely adopted patterns).

There is still no answer to support developers who only want to use open, attributed, licensed data sources. We just stopped talking about attributing code and opting in. Meanwhile more and more companies slip in terms of service considerations to expand the available data. The intersection between capitalism and AI is inextricable. We're seeing AI as a force-multiplier for all existing systems, including technocracy. The momentum has suppressed the conversation.

I have personally decided to continue to navigate the AI world, which means that I owe myself the intellectual honesty to contend with the imperfect system and push it towards auditable and opt-in by default. There is commercial and public good that can come from this change.

I can admit, I am not able to navigate this perfectly.

People are desperate for measured opinions from trusted voices.

The "AI Engineer" is a fuzzy identity that shifts based on context and discussions. There's more to explore about who, what, when, where and why; but one thing is clear: the "ideal customer profile" are "builders" -- too broad an umbrella for old go-to-market cycle. Marketers and start ups can't trust job titles, because the title changes based on the context. Focus on the middle layer of entrepreneurs, consultants, influencers and educators -- AI adoption starts here and will middle out. I have a special place in my heart for Django developers "perfectionists with deadlines," who I've had awesome conversations about AI in production solving problems that the rest of the ecosystem is still quibbling over how to approach. These aren't apps with AI for AI's sake, but delivering on value that a fast and stochastic system gives, generative solutions with guardrails.

Influencers and consultants - they're the only group that has the flexibility to experiment in rapid iteration, are trusted for their experimentation and are used to shipping. Similar to the way Django grew, through the consultant and agency layer who built credibility, wrote books and ran conferences; and created patterns for enterprise to adopt.

AI is being developed as a sidecar to existing workflows with practical infrastructure considerations. Proposed by the community and validated by the program committee, the conference schedule said "AI must fit into existing paradigms". In response to the hype cycle, the pragmatism requires us to absorb, adapt, don't replace.

What a "sidecar" means technically? In distributed systems, a sidecar is a process that runs alongside the main application that handles cross-cutting concerns without being the critical path. Its allowed to fail gracefully and be updated independently with a clean interface.

Currently Enterprise and larger organizations are not ready for the advanced scenarios. Where the experimenters have pushed technology is far beyond the demonstrable use cases of the vast majority of software providers. Patterns like self-healing environments, multi-agent orchestration with role specialization and ontology-informed agent/tools are far beyond the appetite of enterprises exploring AI. The technical capability exists, but the organizational foundation doesn't exist for it to be built, evaluated, deployed, monitored and maintained reliably.

Interest in fitting in the existing paradigm, experts are not letting go of traditional software models. Pydantic, Pydantic AI and Logfire (OpenTelemetry) wins here.

Pydantic AI > LangGraph > LLamaIndex Pydantic is winning with sensible defaults and alignment with traditional principles of software engineering.
I am joining the many superfans emerging rooting for Pydantic-AI. It gives structured validation at the boundary between your existing code and the LLM output. LangGraph and LlamaIndex want to be the application. You are now forced to think in graphs or retrieval pipelines first. Developers want low friction and experimentation alongside what is already there.

Local and small language models are the next, the barrier is just too high. How do I get it to run on my hardware, with my constraints and actually get it to solve my problems reliably? As I've been playing with local-first development, I haven't come to really good answers outside of experiments that do not translate to other domains easily.

Check out the awesome presentation from Gwyn Pena and Pamela Fox walking through small language models optimized for reasoning; unlocking the ability to use SLMs for agents.

In the opposite direction, scaling AI systems has the same bottleneck of large data machine learning systems, with GPU enabled compute. Through my conversations in the hallway track, I'm not seeing load bearing business systems that are leveraging GPU in generative ways (slop and spam excluded) beyond processing large data; which existed in the traditional ML world. I'm excited to extend this conversation into the hallways of PyData London and PyCon Italia. The developers who are experimenting with generative AI for their own workflows are excited about demo machines like the NVIDIA Jetson machines and Mac minis.

What we're talking about when titles change are more than just job posts and toolchain shifts; its philosophy, community and pragmatic re-aligning to ecosystem shifting under their feet. and The developers who are shifting titles are looking for jobs or are in tight cycles with an audience looking for the AI developer. The rest of the ecosystem is remaining sticky to their titles pre-2023.

How do we expect The Python Software Foundation, The Linux Foundation, NumFOCUS, and The Cloud Native Computing Foundation to respond to this AI surge?

Personally, I hope they hurry up and embrace it with pragmatic takes. An AI track at PyCon US is an excellent start, but as I've said many times when I Chair of the PSF -- I see the role of these foundations to provide the metaphorical table and snacks for community discussion. Its the space and the norms that keep conversations democratic, thoughtful and in partnership with industry rather than in response to.

Embracing AI conversations does not mean embracing AI. It is creating a space for conversations to happen and for Python to continue to be the lingua franca.

How should the organizations do it? I'd still like an emergent technology working group. To learn more about what working groups are, check out my blog post.

Disclosure: Written entirely by a human, in conversation with Claude Sonnet 4.6 and many humans.

Please let me know if you see any typos or errors.