Paint.NET rewrites Direct2D with Claude: 180,000 lines

Paint.NET holds around 700,000 lines of code written over more than twenty years. Its author, Rick Brewster, has just added 180,000 in one go, and he did not write them: they are a from scratch reimplementation of Direct2D, the Windows 2D graphics API, generated with Claude so the editor can run on WINE under Linux.

The quote comes via Simon Willison on his weblog, taken from the announcement Brewster posted on the Paint.NET forum. What made the message travel is not the volume of code but the bluntness with which its author explains what he did with it afterwards: nothing. He has not reviewed it.

The underlying problem: Direct2D on WINE

Direct2D is the GPU accelerated 2D rendering layer Paint.NET uses to draw almost everything on screen. On WINE, the compatibility layer that runs Windows binaries on Linux, that API has never been complete. Brewster puts it plainly: Direct2D has always been the biggest hurdle for Paint.NET on WINE, and it is clear it will never be finished enough for what the program needs. Turning it off was not an option either, because the editor depends on it.

The way out was an internal reimplementation, clean room reverse engineered, living in PaintDotNet.Windows.Direct2D1.Managed.dll and triggered by passing the /wine flag. It is an alternative code path that only comes into play when someone asks for it explicitly, in one specific environment.

180,000 lines nobody has read

Brewster describes the result as "vibe coded", in "trust me bro" style, and his justification is purely arithmetic: he cannot review 180,000 lines of code because it is far too much. That figure is roughly a quarter of all of Paint.NET, a product maintained by a single person for two decades.

That is the number worth keeping. It is not that code review stopped mattering: it is that generating code got so cheap that reviewing became the bottleneck. A competent human reviewer manages a few hundred lines an hour before they start looking without seeing. 180,000 lines is months of full time work for someone who already has another job, which is maintaining the other 700,000.

Why the risk is acceptable here

Four factors contain the problem, and they are worth separating from the headline:

1. The functionality did not exist. The alternative to this code was not a reviewed version, it was Paint.NET continuing not to work on Linux.
2. It is isolated behind a flag and its own DLL, on a path that is never touched when running on Windows.
3. Support is labelled extremely experimental by the author himself, so the contract with the user is explicit.
4. The domain is verifiable. A render can be compared pixel by pixel against real Direct2D output, without reading the code that produced it.

Change any one of those four and the calculation breaks. 180,000 unreviewed lines in a payments backend, on a path enabled by default, is not the same decision.

Who this is useful for

For any team deciding where it will accept unaudited generated code. The useful questions are the ones above: is the alternative not having the feature at all? Is the code isolated? Does the user know? Can the output be verified without reading the implementation? When all four answers line up, accepting the code is defensible. When they do not, it is back to classic review and generating less.

We find this a more honest case than most, because Brewster documents the method and his confidence level instead of selling the result. The open question is not whether the code works today, but who debugs it two years from now, when a rare rendering case fails and nobody, human or model, remembers why that function was written the way it was.