Claude Reverse-Engineers Direct2D from Scratch: 180,000 Lines of Vibe Code in Practice

A Technical Challenge 20 Years in the Making

Paint.NET is a widely popular free image editing application for Windows, independently maintained and developed by Rick Brewster for over 20 years. For a long time, the software couldn't run properly on Linux (via the WINE compatibility layer), and the biggest roadblock was Direct2D — Microsoft's 2D graphics rendering API.

Direct2D is a hardware-accelerated 2D graphics rendering API introduced by Microsoft in the Windows 7 era, part of the DirectX technology family. It replaced the older GDI/GDI+ rendering pipeline and fully leverages the GPU for anti-aliased text rendering, vector graphics drawing, image effects processing, and more. Direct2D's API surface is enormous, encompassing hundreds of interfaces and thousands of methods, plus a complete built-in image effects library (blur, color matrix, blend modes, etc.), each backed by precise mathematical algorithms. This is precisely why the WINE project has never been able to fully implement it — the sheer volume of work is staggering, and every rendering behavior must be faithfully reproduced.

WINE (Wine Is Not an Emulator) itself is an open-source compatibility layer project with over 30 years of history, designed to let Linux and macOS users run Windows applications without a Windows license. It's not a virtual machine or emulator — instead, it translates Windows API calls into POSIX system calls at runtime. After years of continuous development, WINE can adequately support Win32 APIs, partial DirectX 3D rendering (translated to Vulkan via projects like DXVK), and many common Windows programs. However, Direct2D support has always been a notable weak spot — WINE's Direct2D implementation covers only a small fraction of the API, far from sufficient to run applications that deeply depend on it.

According to Paint.NET author Rick Brewster's explanation posted on the official forum, Direct2D support on WINE has always been incomplete and is virtually impossible to fully implement. Making matters worse, Paint.NET's architecture is deeply dependent on Direct2D, and there's no way to simply "turn it off." This meant Linux users have long been left out in the cold.

Now, this long-standing problem has found a surprising solution: Paint.NET ships with a clean-room reverse-engineered rewrite of Direct2D, built from scratch and activated specifically under the WINE environment (triggered via the /wine parameter). This code is packaged in PaintDotNet.Windows.Direct2D1.Managed.dll.

180,000 Lines of Code Written Entirely by AI

What truly caught the tech community's attention is the "author" behind this Direct2D rewrite — Rick Brewster explicitly stated that the work was done by AI assistant Claude, saying "without it, this would not have happened — not now, not ever."

The scale of this codebase is staggering: approximately 180,000 lines of code. For context, Brewster mentioned that the rest of the Paint.NET project totals about 700,000 lines — accumulated over more than 20 years. In other words, Claude generated code in a relatively short period that amounts to a quarter of a mature software project's total volume.

What's even more noteworthy is that this wasn't simple boilerplate code generation. The Direct2D rewrite involved extensive reverse engineering of graphics algorithms, particularly the implementation of its built-in effects library, which required precise reproduction of various mathematical formulas. Brewster expressed that he was impressed by Claude's "quite smart and tireless reverse engineering work" in this area.

Why Clean-Room Reverse Engineering Matters

So-called "clean-room reverse engineering" is a legally safer method of software reimplementation — rather than directly copying the original code, it involves analyzing behavior and interfaces to independently reimplement the same functionality. This approach is widely adopted in the open-source community (including the WINE project itself) to mitigate intellectual property risks.

This strategy dates back to Compaq's reverse engineering of the IBM PC BIOS in the 1980s — that landmark effort gave birth to the entire IBM PC-compatible industry. The classic process works like this: one group (the "analysis team") studies the original software's external behavior, input/output relationships, and public documentation, then writes a functional specification; a completely separate group (the "implementation team") writes entirely new code based solely on that specification, never having seen the original source code. This "Chinese wall" design is widely recognized as legal under U.S. copyright law, since copyright protects the specific expression of code rather than the functional ideas behind it. The WINE project itself is a textbook example of clean-room reverse engineering — the entire project has never used any of Microsoft's source code.

In this case, using AI to perform this kind of work requires both understanding the target API's behavioral specifications and producing entirely new implementation code. Claude's role here effectively served as both the analysis team and the implementation team in a traditional clean-room reverse engineering process.

The Real Experience of Vibe Coding: Trust and Risk Coexist

When describing this development process, Brewster used a currently trendy term — vibe coding. This concept was first coined by OpenAI co-founder Andrej Karpathy in February 2025, describing an entirely new way of programming: instead of writing and reviewing code line by line, developers describe their intent in natural language to an AI, accept the generated code, judge correctness by running results, and paste error messages back to the AI for fixes when things break. Karpathy described it as "fully surrendering to the vibes, embracing exponential growth, and forgetting that code even exists." The concept quickly sparked heated debate in the developer community — supporters believe it dramatically lowers the barrier to programming, while critics worry it will produce massive amounts of unmaintainable "black box code" riddled with security vulnerabilities.

Brewster was candid: "Most of this code is what you'd call 'vibe coded.' What I mean by that is it hasn't been thoroughly reviewed — it's more of a 'trust me bro' style. I can't possibly review 180K lines of code; that's way, way too much."

This honesty reveals a core contradiction in current AI-assisted programming: output speed far outpaces human review capacity. When AI can generate tens of thousands of lines of code in a short time, traditional code review workflows become unsustainable. Developers are forced to strike a balance between "trusting the AI" and "verifying line by line." Brewster's case perfectly illustrates both sides of vibe coding — it genuinely unlocks unprecedented productivity, but also introduces unprecedented uncertainty.

Claude's Performance: Genius and Flaws Side by Side

Brewster's description of Claude's performance is remarkably vivid: "Sometimes Claude is working with the fervor of 10 freshly unchained Einstein-level genius 10x programmers. And other times... well, not so much."

He cited several specific examples where the AI needed "babysitting":

• Resource management errors: Claude at one point didn't properly handle the COM-equivalent AddRef() operations for reference-counted objects. COM (Component Object Model) is a binary interface standard Microsoft introduced in 1993 that remains a cornerstone of Windows system programming to this day — Direct2D, DirectWrite, Media Foundation, and other modern Windows APIs are all built on COM. COM objects use manual reference counting for lifecycle management: each object maintains an internal counter, calling AddRef() increments it by one, calling Release() decrements it by one, and when the count reaches zero, the object is automatically destroyed. This mechanism seems simple but is in fact one of the most notorious sources of bugs in Windows development — forgetting to call Release() causes memory leaks, an extra Release() leads to dangling pointers and crashes, and tracking every reference transfer in complex object graphs is extremely error-prone. This explains why Brewster needed to specifically correct Claude's handling in this area.
• Poor design decisions: Brewster mentioned that he had to "slap" Claude a few times to correct some very bad design or architectural decisions.

These details illustrate that while AI can handle massive volumes of work, system-level programming, low-level resource management, and overall architectural design still require experienced human engineers to oversee every step. AI excels at pattern matching and code generation, but for problems requiring holistic systems thinking — such as object lifecycle management, thread safety, and memory models — it still lacks reliable judgment.

Three Key Takeaways for AI-Assisted Programming

This case provides a real, credible reference point for the red-hot field of AI-assisted programming, and what makes it especially valuable is that it comes from a seasoned independent developer with 20 years of experience — not a marketing pitch.

First, AI can tackle "impossible" tasks. A technical obstacle that had plagued Paint.NET for years was overcome with AI's help. Reverse engineering tasks that require massive amounts of repetitive, pattern-based work are precisely where AI shines. Direct2D has hundreds of interfaces and methods; implementing them one by one would be an impractical workload for any individual developer, but for AI, this kind of highly structured, repetitive engineering falls right in its sweet spot.

Second, scale creates a review dilemma. 180,000 lines of insufficiently reviewed code entering a production environment is itself a warning sign. Brewster responsibly marked this feature as "extremely experimental." The software engineering field has long used "defect density per thousand lines of code" as a metric — even high-quality commercial software averages 1-25 defects per thousand lines. 180,000 lines of insufficiently reviewed code means potentially hundreds or even thousands of bugs, some of which may involve security vulnerabilities. This poses a serious challenge to traditional quality assurance systems.

Third, the human role is evolving. It's shifting from "writing code" to "guiding, correcting, and gatekeeping." Brewster acted more like a technical director or architecture reviewer than a front-line coder. His experience remained indispensable — it was precisely that experience that enabled him to identify the COM reference counting errors and poor architectural decisions. This role shift also implies that a developer's core competitive advantage in the future may no longer be coding speed, but rather the vision for system design, the intuition for problem diagnosis, and the ability to judge the quality of AI output.

Conclusion: AI Produces, Humans Judge

Paint.NET's attempt at WINE/Linux support is a vivid demonstration of AI's programming capabilities and an honest record of its limitations. It proves that AI can accomplish extremely challenging system-level work under the guidance of a professional developer, while also reminding us that amidst the celebration of productivity leaps, the risks around code quality, maintainability, and security must not be overlooked.

For the developer community, this may signal a new development paradigm taking shape — AI handles production, humans handle judgment. How to establish reliable trust and verification mechanisms between the two will be a critical challenge for the future of software engineering. When a single person can accomplish in weeks what previously required a team years to complete with AI's help, the economics of software development, organizational structures, and even quality standards all need to be redefined.