PyCoder’s Weekly included over 1,500 links to articles, blog posts, tutorials, and projects in 2025. Christopher Trudeau is back on the show this week to help wrap up everything by sharing some highlights and uncovering a few hidden gems from the pile.

We share the top links explored by PyCoder’s readers. We also dig into trends across all the articles and stories this year. We highlight a few gems that we didn’t cover on the show and a couple that explore the overall themes of the year.

We hope you enjoy this review! We look forward to bringing you an upcoming year full of great Python news, articles, topics, and projects.

Topics:

• 00:00:00 – Introduction
• 00:01:52 – Django 6.0 released
• 00:02:58 – The Inner Workings of Python Dataclasses Explained
• 00:03:40 – Going Beyond requirements.txt With pylock.toml and PEP 751
• 00:04:58 – Django vs. FastAPI, An Honest Comparison
• 00:05:46 – How to Use Loguru for Simpler Python Logging
• 00:06:47 – Narwhals: Unified DataFrame Functions
• 00:08:32 – Observations and statistics for the year of articles
• 00:13:23 – Data Validation Libraries for Polars (2025 Edition)
• 00:18:53 – Video Course Spotlight
• 00:20:25 – Create Temporary Files and Directories in Unittest
• 00:22:27 – Capture Stdout and Stderr in Unittest
• 00:24:59 – I don’t like NumPy
• 00:26:34 – Python performance myths and fairy tales
• 00:31:05 – Congratulations on making through 2025!

News:

• Django 6.0 released - Django Weblog

Top PyCoders Links 2025:

• The Inner Workings of Python Dataclasses Explained – Discover how Python dataclasses work internally! Learn how to use __annotations__ and exec() to make our own dataclass decorator!
• Episode #249: Going Beyond requirements.txt With pylock.toml and PEP 751 – What is the best way to record the Python dependencies for the reproducibility of your projects? What advantages will lock files provide for those projects? This week on the show, we welcome back Python Core Developer Brett Cannon to discuss his journey to bring PEP 751 and the pylock.toml file format to the community.
• Django vs. FastAPI, An Honest Comparison – David has worked with Django for a long time, but recently has done some deeper coding with FastAPI. As a result, he’s able to provide a good contrast between the libraries and why/when you might choose one over the other.
• How to Use Loguru for Simpler Python Logging – Real Python – In this tutorial, you’ll learn how to use Loguru to quickly implement better logging in your Python applications. You’ll spend less time wrestling with logging configuration and more time using logs effectively to debug issues.
• Narwhals: Unified DataFrame Functions for pandas, Polars, and PySpark – Narwhals is a lightweight compatibility layer between DataFrame libraries. You can use it as a common interface to write reproducible and maintainable data science code which supports pandas, Polars, DuckDB, PySpark, PyArrow, and more.

Featured Links:

• Data Validation Libraries for Polars (2025 Edition) – Pointblank - Given that Polars is so hot right now and that data validation is an important part of a data pipeline, this post explores five Python data validation libraries that support Polars DataFrames. Through contrasting and comparison, the post puts forward which of them are best for specific use cases.
• Python: Create Temporary Files and Directories in Unittest – Sometimes, tests need temporary files or directories. You can do this in Python’s unittest with the standard library tempfile module. This post looks at some recipes to do so within individual tests and setUp().
• Python: Capture Stdout and Stderr in Unittest – When testing code that outputs to the terminal through either standard out (stdout) or standard error (stderr), you might want to capture that output and make assertions on it.
• I don’t like NumPy – This opinion piece talks about why NumPy gets difficult fast. Two dimensions to your array? No problem, the calc is mostly self evident. Add a couple more dimensions and it gets messy fast. See also the associated HN discussion, which also includes possible solutions.
• Python performance myths and fairy tales – This post summarizes a talk by Antonio Cuni who is a long time contributor to PyPy, the alternate Python interpreter. The talk spoke about the challenges and limits of performance in Python and how the flexibility of dynamic languages comes at a cost. See also the associated HN discussion.

Additional Links:

• Episode #224: Narwhals: Expanding DataFrame Compatibility Between Libraries
• Episode #272: Michael Kennedy: Managing Your Own Python Infrastructure
• Episode #510 - 10 Polars Tools and Techniques To Level Up Your Data Science
• ty
• waelstow: Python unittest utilities. Includes output capture, test discovery, and directory relocation.
• PyPy
• spylang · GitHub

Level up your Python skills with our expert-led courses:

• Filtering Iterables With Python
• Using Functional Programming in Python
• NumPy Techniques and Practical Examples

Support the podcast & join our community of Pythonistas

Steve Martin: Coaching Product Owners to Be the Voice of the Customer

In this episode, we refer to Henrik Kniberg's "Product Owner in a Nutshell" video and Product Ownership by Geoff Watts.

The Great Product Owner: Rob Gard's Customer Obsession

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

"The role of the PO really is to help the team empathize with the user, the customer of the product, because that's how they can develop great solutions." - Steve Martin

Rob Gard worked at a fintech firm and is now CPO of a major fintech company. Steve describes him as having a brilliant mind and being a real agileist—someone Steve learned a huge amount about Agile from. Rob's defining characteristic was his absolute obsession with the user. Everything focused on customer pain points. Working with engineering teams serving military customers, Rob held regular workshops with those customers to understand their pain firsthand. He was literally the voice of the customer, not theoretically but practically. Rob pushed and challenged teams to be more innovative, always looking for better ways of providing better software. His gift was communication—specifically, briefing the team on the problem rather than just reading out stories in refinement sessions. This is the anti-pattern many Product Owners fall into: going through the motions, reading requirements without context. Real product ownership, as Rob demonstrated, is telling a story that helps the team empathize and understand the pain. When teams can internalize customer problems, they develop better solutions. Rob's ability to communicate the problem into the minds of teams enabled them to serve customers more effectively. This is the essence of great Product Ownership: not being a proxy for management, not juggling multiple teams, but being deeply connected to customer pain and translating that pain into context the team can work with.

Self-reflection Question: Do your refinement sessions tell stories that help the team empathize with customer pain, or do you just read out requirements?

The Bad Product Owner: Proxies for Management Instead of Customer Advocates

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

"They weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte

Steve emphasizes that Product Owners often have great intentions but struggle due to lack of training and coaching. The anti-patterns are systemic: commercial managers "dressed up" as Product Owners without understanding the role. Project managers transitioning to PO roles—though Steve notes PMs can make really good POs with proper support. The most damaging pattern is Product Owners spread across multiple teams, having very little time to focus on any single team or their customers. These POs become proxies—representing the voice of senior management rather than the voice of the customer. They cascade requirements downward instead of bringing customer insights upward. The solution isn't to criticize these struggling Product Owners but to help them understand their role and see what good looks like. Steve recommends Henrik Kniberg's "Product Owner in a Nutshell" video—15 minutes, 15 years old, still profoundly relevant. He also points to Product Ownership by Geoff Watts and formal training like CSPO or IC Agile Product Ownership courses. The fundamental issue is meeting Product Owners where they are, providing coaching and support to transform them from management proxies into customer advocates. When POs understand their role as empathy builders between customers and teams, everything changes.

Self-reflection Question: Is your Product Owner the voice of senior management or the voice of the customer?

[The Scrum Master Toolbox Podcast Recommends]

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

Buy Now on Amazon

[The Scrum Master Toolbox Podcast Recommends]

About Steve Martin

You can link with Steve Martin on LinkedIn.

Steve is an Agile Coach, mentor, and founder of The Agile Master Academy. After over 14 years leading Agile transformation programmes, he's on a mission to elevate Scrum Masters—building high-performing teams, measurable impact, and influence—and raising industry standards of Agile mastery through practical, evidence-led coaching. You can also find Steve's insights on his YouTube channel: Agile Mastery Show.

Rakshana Balakrishnan, Cloud infrastructure Product Manager at Oracle

In this episode, we’re joined by Rakshana Balakrishnan, Principal Product Manager at Oracle Cloud Infrastructure and we explore the evolving role of product management in today’s fast-moving, GenAI-powered tech landscape. She shares tips on what it takes to be a product manager today, and provides sound ideas for claiming your seat at the table.

Share Episode
         
         "Those memes are not going to make themselves."

Dorota, CEO of Authress, joins us to roast the 2025 DORA Report, which she argues has replaced hard data with an AI-generated narrative. From the confusing disconnect between feeling productive and actually shipping code to the grim reality of a 30% acceptance rate, Warren and Dorota break down why this year's report smells a lot like manure.

We dissect the massive 142-page 2025 DORA Report. Dorota argues that the report, which is now rebranded as the "State of AI-Assisted Software Development", feels less like a scientific study of DevOps performance and more like a narrative written by an intern using an LLM prompt. The duo investigates the "stubborn results" where AI apparently makes everyone feel like a 10x developer, where the hard results tell a different story. AI actually increases software and product instability — failing to improve.

The conversation gets spicy as they debate the "pit of failure" that is feature flags (often used as a crutch for untested code) and the embarrassing reality that GitHub celebrates a mere 30% code acceptance rate as a "success." Dorota suggests that while AI raises the floor for average work, it completely fails when you need to solve complex problems or, you know, actually collaborate with another human being.

In a vivid analogy, Dorota compares reading this year's report to the Swiss Spring phenomenon — the time of year when farmers spray manure, leaving the beautiful landscape smelling...unique. The episode wraps up with a reality check on the physical limits of LLM context windows (more tokens, more problems) and a strong recommendation to ignore the AI hype cycle in favor of a much faster-growing organism: a kitchen countertop oyster mushroom kit.

• AI as an amplifier truism fallacy
• DORA 2025 Report
• DevOps Episode: VS Code & GitHub Copilot
• Where is the deluge of new software - Impact of AI on software products
• Impact of AI on Critical Thinking

• Warren - The Maximum Effective Context Window
• Dorota - Mushroom Grow Kit

TL;DR
Engineers spend more time understanding code than writing it.

LLM-based tools help, but in different ways.

This article compares modern AI tools for code understanding and explains when to use which one, based on cognitive bottlenecks rather than features.

For most software engineers, the dominant cost of development is not writing new code but understanding existing systems: navigating large codebases, reconstructing intent, tracing behavior across layers, and assessing the impact of change.

Empirical studies consistently show that developers spend a substantial portion of their time on comprehension, information seeking, and coordination rather than coding itself, based on large-scale field studies of professional developers’ daily activities and measured comprehension tasks (here, and here). Program-comprehension research further demonstrates that understanding code imposes significant cognitive load and is influenced by factors such as vocabulary, structure, and “naturalness”.

That is why having new tools to understand large codebases is so important, especially at big enterprises and organizations with lots of apps and services. Modern enterprise environments present unique challenges. They operate with multi-decade legacy systems, polyglot architectures, security and compliance constraints, and large-scale team structures that demand tools with much more rigor than consumer-grade AI assistants.

In 2025, we have seen a rise in the popularity of tools using LLMs to explain how an application's source code works or to auto-document it. Unlike traditional static analysis, which relies on explicit rules, models, and predefined abstractions, LLM-based analysis leverages learned representations to interpret code semantics and intent. This allows context-aware code analysis (e.g., detecting insecure patterns or summarizing complex logic) with a flexibility beyond hard-coded rules.

This article explores why LLMs and agent-based tools are a natural fit for program comprehension—and where they still fall short. Based on my own research and hands-on experimentation, I compare a selected set of commercial and open-source tools using a qualitative lens. Rather than reviewing outputs line by line, the goal is to clarify each tool’s strengths and trade-offs and offer practical guidance on when to use which tool, depending on the stage of understanding and the developer’s workflow.

Advantages of using LLMs and agents for code understanding

LLMs are particularly effective at reducing the friction of initial comprehension: summarizing functions and modules, explaining unfamiliar APIs or idioms, and translating low-level implementation details into higher-level intent.

When combined with agents, their impact extends beyond isolated snippets to repository-scale understanding. Agentic workflows characterized by iterative planning, tool use, retrieval, and validation enable incremental, multi-step exploration of codebases, rather than single-pass analysis.

Research and early industrial practice show that structure-aware context (e.g., symbols, call graphs, dependencies, and history) significantly improves the relevance and usefulness of explanations compared to flat context windows, as demonstrated in repository-level and IDE-integrated code understanding studies. These capabilities are especially valuable for onboarding, legacy modernization, bug localization, and code migrations, where the primary challenge is knowing where to look rather than what to type.

Disadvantages and limitations

Despite their fluency, LLMs do not reliably demonstrate deep semantic understanding of code. Several empirical studies show that models often rely on surface-level lexical or syntactic cues and can fail under small, semantics-preserving transformations, a limitation demonstrated in semantic fault localization and robustness evaluations of code-focused models. This creates a risk of false confidence: explanations may sound convincing while being subtly incorrect or incomplete.

Controlled experiments with experienced professional developers have shown that AI-assisted workflows can increase task completion time due to verification overhead and context mismatch, even when participants report higher perceived productivity.

As a result, comprehension gains are highly sensitive to retrieval quality, grounding mechanisms, and task context.

LLM-based Tools for Code Understanding

My exploration of LLM-based tools for code understanding started with DeepWiki, which I have been using since its early release. As my interest shifted toward analyzing private repositories and experimenting more deeply with the underlying mechanics, I began looking for open-source alternatives. This led me to deepwiki-rs and later OpenDeepWiki. After starring OpenDeepWiki on GitHub, one of the authors of Davia reached out, which introduced me to a different, more collaborative approach to AI-assisted documentation. I later encountered PocketFlow Tutorial Codebase Knowledge through a technical report, and finally Google Code Wiki when it was publicly announced, which I followed closely given its enterprise positioning.

Although all of these tools aim to reduce the cost of understanding large codebases, they approach the problem from different angles.

DeepWiki and Google Code Wiki focus on automatically generating structured, navigable wikis from repositories, optimizing for rapid orientation and high-level understanding.

deepwiki-rs emphasizes architecture-first documentation, producing explicit C4 models and structural views that support reasoning about system boundaries and change impact.

OpenDeepWiki takes a more infrastructure-oriented approach, positioning itself as a structured code knowledge base that can be queried by both humans and agents and integrated into broader tooling ecosystems.

In contrast, Davia acts as an interactive, human-in-the-loop workspace, where AI agents help generate and evolve documentation collaboratively rather than producing a static artifact.

Finally, PocketFlow Tutorial Codebase Knowledge reframes repositories as pedagogical artifacts, prioritizing approachability and onboarding through tutorial-style explanations.

Together, these tools form a representative cross-section of current approaches to AI-assisted code comprehension, making them well-suited for a qualitative comparison across dimensions such as mental model formation, grounding and trust, freshness over time, and workflow fit.

Qualitative dimensions comparison

When comparing AI tools for code understanding, it helps to step back and ask a simple question:

What part of the thinking process does this tool actually make easier?

Reading and understanding code is not a single activity but a sequence of cognitive steps. From getting oriented to building confidence, to keeping that understanding up to date as the system evolves.

The qualitative dimensions below reflect those realities and explain why different tools shine in different situations.

Mental model formation is about how quickly a tool helps you answer the big-picture questions: What is this system? How is it structured? What are the main responsibilities and flows? Tools that excel here reduce the initial cognitive load by externalizing architecture and intent, allowing engineers to move from confusion to clarity without reading every file. This is especially valuable when joining a new project or revisiting a codebase after time away.

Grounding and trust address a different concern: Can I rely on what this tool is telling me? Clear explanations are useful, but they only become actionable when they are tied back to concrete code: files, symbols, and implementation details that can be inspected and verified. Tools with strong grounding make it easy to validate claims, while weaker grounding forces engineers to double-check everything manually, reducing trust and limiting real productivity gains.

Freshness over time reflects the reality that code changes constantly. Even the best explanation loses value if it no longer matches the current state of the system. Some tools provide powerful snapshots of understanding, while others focus on keeping documentation and explanations synchronized with ongoing code changes. This dimension matters most in fast-moving teams, where stale understanding can be more dangerous than no documentation at all.

Workflow fit recognizes that developers ask different questions at different moments. Early on, they want orientation; later, they want precision; sometimes they want learning, other times impact analysis or review support. Tools differ not in overall quality, but in which stage of understanding they optimize. A good fit aligns the tool with the user’s context: new contributor, experienced engineer, architect, or platform team rather than assuming one-size-fits-all comprehension.

Taken together, I hope these dimensions help explain why no single AI tool “wins” across all scenarios. Each makes deliberate trade-offs to reduce a specific kind of cognitive friction, and understanding those trade-offs is key to choosing and using the right tool effectively.

Mental model formation

Mental model formation is about how quickly and accurately a tool helps a developer answer the fundamental question: “What is this system, and how does it fit together?” Different tools approach this problem in distinct ways.

• DeepWiki excels at orientation speed: it synthesizes structure, responsibilities, and flow into wiki-style narratives and diagrams with almost zero setup. Ideal for “what is this repo?” moments.

• Google Code Wiki goes further by maintaining architectural summaries that stay synchronized with code changes, reducing documentation drift.

• deepwiki-rs is strongest when architecture matters more than narrative: C4 models and explicit component relationships help senior engineers reason about system boundaries and change impact.

• Davia and OpenDeepWiki emphasize semantic structure (entities, relations, graphs) over prose, which supports deeper, iterative understanding rather than instant summaries.

• PocketFlow deliberately simplifies architecture into tutorials, trading completeness for approachability.

In a nutshell: DeepWiki and Google Code Wiki optimize time-to-orientation, deepwiki-rs and OpenDeepWiki emphasize structural correctness, and PocketFlow prioritizes learnability.

Grounding and trust

Grounding and trust determine whether an engineer can act on what an AI tool says. Is the output yielded by the tool instantly actionable and linked to specific source code files and line numbers? Can a modernization architect trust the architectural diagrams generated by the tool?

• Google Code Wiki places a strong emphasis on grounding by design: its chat answers and wiki pages are explicitly linked to current repository artifacts—files, symbols, and definitions—and are regenerated as the code evolves. This tight coupling between explanations and source code reinforces trust and helps reduce hallucination risk, particularly in fast-moving codebases where stale documentation is a common failure mode.

• OpenDeepWiki also scores highly on grounding, primarily through its use of structured representations such as knowledge graphs and its ability to act as an MCP (Model Context Protocol) server. Rather than presenting explanations in isolation, it is designed to expose explicit relationships between code elements, making it well-suited as a grounded context provider for downstream agents and tools.

• DeepWiki provides stronger grounding than a purely narrative system: its generated pages explicitly reference relevant source files and often include line-level citations, enabling engineers to verify architectural claims against the actual implementation. However, because DeepWiki represents a snapshot of the repository at indexing time, its output is best treated as a grounded but temporal hypothesis—accurate and traceable, yet requiring awareness of potential drift as the codebase changes.

• deepwiki-rs approaches grounding through explicit, architecture-first artifacts rather than conversational explanations. Its outputs, such as C4 diagrams, component boundaries, and cross-references, are derived directly from static analysis of the source code, which makes their grounding relatively strong and inspectable. This tool implements a 4-step pipeline to generate documentation that includes C4 models of the codebase.

• Davia exhibits variable grounding characteristics that depend largely on the underlying AI agent and integration context (e.g., Copilot, Cursor). When paired with agents that perform structured retrieval and symbol-level navigation, Davia can support strong traceability; when used with weaker or less-contextual agents, grounding quality correspondingly degrades.

• PocketFlow is intentionally weaker on grounding by design. Its primary goal is pedagogical clarity and onboarding, favoring simplified explanations and conceptual walkthroughs over exhaustive traceability to every file or symbol, which makes it effective for learning but less suitable for verification-heavy engineering tasks.

Freshness & evolution

Freshness and evolution capture how well a tool preserves understanding as a codebase changes over time. For enterprises, this is a critical factor where yesterday’s explanation can quickly become misleading.

• Google Code Wiki is explicitly designed to regenerate content continuously as code changes, which is its defining advantage.

• deepwiki-rs and OpenDeepWiki can be re-run to refresh docs, but this is typically batch-driven.

• DeepWiki reflects repo state at analysis time; freshness depends on re-indexing.

• Davia shines in interactive evolution: docs can be edited, refined, and co-created alongside agents.

• PocketFlow outputs static tutorials unless the pipeline is rerun.

If “docs rot” is your core pain point, Google Code Wiki is uniquely positioned. Documentation becomes outdated when three things drift apart: 1) code changes frequently (PRs, refactors, dependency updates), 2) docs are regenerated manually or periodically, 3) no automatic coupling exists between code deltas and documentation updates.

Even AI-generated docs rot if they are: snapshot-based, re-run manually, and detached from the CI/repo lifecycle. DeepWiki, Davia, deepwiki-rs, and OpenDeepWiki operate as snapshots, even if they are very good snapshots.

On the other hand, Google’s Code Wiki is designed to continuously update a structured wiki for code bases where each wiki section and chat answer is hyperlinked to code files, classes, and functions (Code Wiki, 2025).

Workflow fit

Workflow fit describes how well a tool aligns with the moment an engineer is in and the type of question they are trying to answer, whether they are onboarding, validating changes, reviewing code, or planning modernization.

Taken together, these dimensions and personas show that adopting LLM-based tools for code understanding is less about choosing the ‘best’ tool and more about choosing the right one for a given moment.

Key takeaways

LLMs and agent-based tools are best understood as cognitive amplifiers for code comprehension, not as replacements for human judgment or engineering expertise. Across tools like DeepWiki, Google Code Wiki, Davia, and OpenDeepWiki, their strongest and most defensible value is not in producing “answers,” but in compressing the early phases of understanding: helping engineers orient themselves, explore structure, and form testable hypotheses about how a system works.

In practice, these tools help engineers move faster from ‘I don’t know this system’ to ‘I know where to look and what to verify. They do this by externalizing structure and intent: surfacing architectures, highlighting key files and relationships, and guiding engineers toward “where to look next.” This aligns with broader DevOps and software delivery research showing that practices which improve team flow and feedback loops (such as shorter lead times, faster deployment frequency, and effective collaboration) correlate strongly with organizational performance and developer productivity beyond raw coding speed (as documented in the yearly DORA reports).

However, sustainable impact depends on how these tools are integrated, not on model capability alone. The most effective setups ground explanations in concrete code artifacts (files, symbols, line ranges), leverage structure-aware context (architecture, dependencies, knowledge graphs), and explicitly frame AI output as a starting point for validation rather than an authoritative source. Snapshot-based wikis, continuously regenerated documentation, and agent-driven knowledge layers each solve different parts of the problem and must be chosen deliberately based on workflow and organizational needs.

Finally, teams that succeed with LLMs for code understanding are those that measure the right outcomes. Metrics such as time-to-locate relevant code, time-to-explain a subsystem, onboarding speed, and review latency better reflect real comprehension gains than lines of code generated or tasks automated. When adoption is guided by these understanding-centric outcomes, LLMs and agents can deliver durable, compounding benefits rather than short-lived productivity illusions.

Sources note

This article draws on peer-reviewed program comprehension research, recent empirical studies on AI-assisted development, and primary documentation from the tools discussed. All claims are supported by publicly available sources linked inline.