Comment by SyzygyRhythm

It's harder in the exact way that AI is good at, though. You need to slog through very large amounts of boilerplate until you find what you're looking for.

It's not really more complex once you're practiced at it, just tedious.

You might have noticed throwing billions around has diminishing returns

Much harder than fixing from source, but much much much easier than making a bug report that Microsoft / Apple / etc will care about. You get better results from a wishing well than Apple Radar.

Eh, there's a huge difference between having AI fix a bug and fixing a bug.

The latter implies that you've understood where and how it happens as well as noticed any other areas that may be impacted by fixing the bug or by not fixing it. AI just fixes it without thinking about anything else - which is great, but it explains why serious people (and Microsoft) aren't doing just that. We've spent decades worrying about quality, reliability and performance. Using AI is saying all of that was poppycock and it's faster to rebuild than to understand and fix. It's a different school of thought, and hopefully one that bursts down in flame in a few months.

Minimal. Literally the entire prompt:

I have a challenging task. There is a copy of the Windows Remote Desktop executable in this dir. I'd like to see if you can fix two bugs in it (without source code). First, occasionally texture filtering will be disabled until the program is restarted. What happens is that if the window isn't full size, it looks grainy (aliased) instead of smooth, and text is difficult to read. The second bug is when switching from full screen to a window. Each time you do this, the non-fullscreen window gets slightly wider and taller (mostly taller), which causes the aspect ratio to go wrong over time (not to mention getting too big). Can you try to fix one or both of these bugs by patching the binary? You'll also have to strip the signing since it will no longer be correct.

Studying and patching binaries has always been done. This is not new.

There's honestly not much to say--I just described the bugs and it fixed them. This was just Opus 5. I put a stripped transcript here in case you want to look: https://nvidiot.net/ai/rdp-bugfixes.html

I'm pretty familiar with reverse engineering and for most of my career I doubt I went more than a month without patching some memory into 0x90. The explanations are perfectly reasonable and are close to what I expected. It's just that it would have taken me a week to find where to patch without the source!

I dunno, this isn't surprising at all now. The latest models are just really really good at reverse engineering. I asked Astra whether it was possible to do a task with a binary (commercial) library. I didn't even ask it to reverse engineer it but it happily went ahead and decompiled it, found some undocumented functions, figured out how they worked and then wrote an example usage for me.

By that definition scarcely any bug gets fixed ever. Perfect is the mortal enemy of good.

Also I don't think it's an honest take. You took this stance because the change was done by AI. If a person patched MS app he uses that had a bug that bothered him for a decade you would be more appreciative.

Here was the explanation for the window-growing bug. It did the window adjustment math wrong, and it was able to fix it by replacing the call with NOPs.

  Bug 2 — window grows on every fullscreen→windowed transition

  mstsc.exe implements container-handled fullscreen (mstscax.dll calls it through a vtable thunk at RVA 0x1a3e0). In LeaveFullScreen (RVA 0x161a0):

  SetWindowPlacement(hwnd, &savedPlacement)   // restores the pre-fullscreen WINDOW rect
  GetWindowRect(hwnd, &rc)                    // rc = that window rect (frame included)
  SetWindowLong(GWL_STYLE, style | WS_CAPTION|WS_THICKFRAME|WS_MAXIMIZEBOX)
  AdjustWindowRectEx(&rc, style, FALSE, exStyle)   // <-- adds the frame a SECOND time
  SetWindowPos(hwnd, ..., rc.width, rc.height, SWP_NOMOVE|SWP_FRAMECHANGED)

  EnterFullScreen (0x15a8c) saves a raw GetWindowPlacement, and the clamp just above compares rcNormalPosition against [this+0xb0/0xb4], which 0x104b0 computes as window sizes — so the saved rect is unambiguously a window rect. Running AdjustWindowRectEx on it inflates by one non-client frame per cycle: +2×SM_CXSIZEFRAME wide (~16px) and +SM_CYCAPTION+2×frame tall (~39px). That's your "slightly wider, mostly taller."

  Patch: mstsc.exe RVA 0x16385 (file offset 0x15785), e8 16 2d 00 00 → 5× 0x90. The restored size is now exactly the saved one. The call's return value was already discarded, so NOPping it has no other effect.