Following up on my previous post about automating month-end, I want to pull back the curtain on the project that really started it all. It involves a massive company reconstruction, a "manual hell" task, and a midnight breakthrough that tripled my productivity. The Problem: A Reconstruction Hangover On January 1, 2026, our company underwent a major reconstruction. Customers were assigned new sales reps, but the final list of who owned which account wasn't finalized until April. In the meantime, we kept invoicing as usual. The invoices were correct, but the Sales Rep field on the historical records was now wrong. To fix it, we had to go back and update thousands of already invoiced sales orders. The Manual Workflow (or: How to lose your mind): 1. Search for the Sales Order. 2. Click Invoice. 3. Click Rebill. 4. Change the Sales Rep. 5. Click OK. 6. Hit Esc to exit. 7. Repeat... hundreds (or thousands) of times. Enter Claude Code & Playwright I had just started using Claude Code on March 19th after watching @Jake Van Clief ’s videos. Two weeks later, this assignment landed on my desk in the middle of my usual accounting duties. Since I didn’t have backend API access to D365 F&O, I turned to the Playwright MCP. If I couldn't talk to the database directly, I’d have Claude "drive" the browser just like a human would. The Automation Logic: - Open Chrome to the D365 Sales Order URL. - Open the filters tab. - Add filter information (Customer account, dates for Q1 2026, and identifying which sales orders had the wrong rep). - Execute the "Rebill" click-path automatically. The "Aha!" Moment at 00:30 AM It worked, but it was real slow. D365 isn't exactly a speed demon. My boss was happy ("as long as we don't have to do it, I don't care how slow it is"), but I knew we could do better. Earlier that day, I was running it in one browser and it was taking forever. While the kids were finally asleep that night, I had an idea: Can I run this on more than one tab?

In Part 1, I was riding high. I had Chrome, Edge, and Firefox all running simultaneously, tripling my speed on a massive D365 rebilling project. I felt like I’d cracked the code to being "efficiently lazy." Link: Mini-Series Part 1: The "Manual Hell" Rebill Project · Clief Notes But the victory was short-lived. I was driving the car at 100mph, but I didn't realize how much fuel I was burning. The Crash: 3 Hours to Zero The next morning, I fired up all cylinders. It was beautiful—until it wasn't. In under 3 hours, I burned through my entire token allotment. I was dead in the water with a 1.5-hour wait until my limits reset. With the clock ticking and sales reps still needing updates, I had to go back to doing it manually. And that’s when the "Aha!" moment happened. The "Tab" Breakthrough While I was clicking and typing manually to pass the time, I realized something: I wasn't really using the mouse. I was mostly hitting Tab and Shift-Tab to navigate the D365 fields. I asked Claude: "Can Playwright just 'Tab' through the browser instead of searching for elements and taking screenshots for every move?" Claude’s answer: YES. My jaw dropped. From "Visual Driving" to "Macro Speed" The old workflow relied on Claude "seeing" the screen via screenshots to make sure it was in the right spot. It was accurate, but heavy. I had Claude rewrite the interior workflow to a deterministic loop: 1. The Setup: I open the URL, set the filters, and select the first row. 2. The Loop: * Tab to Invoice → Enter. 3. Repeat. I added small buffers (100ms between tabs, 4s for page loads) to ensure D365 could keep up. See the video for how the flow runs in real life! The Result: 90% Savings & 10x Efficiency I asked Claude to evaluate the two methods. The numbers were staggering: Old "Visual" Flow: - Tool Calls: ~500 calls per 50 orders - Token Usage: 100% (High Burn) - Logic: Screenshot-dependent (Slow)

Most software is built by people who will never use it. They are guessing what their users need, then guessing whether they got it right. That gap is why so many tools feel almost-right. Almost the workflow you wanted. Almost the shortcut you would have built yourself. The fingerprint is missing because the maker's hands were never in the work. Pushing Squares started from the opposite direction. I am a colourist and a director. CRUSH, CBA, FUZZ, SUBTRACKT, REFRAKT. These plugins exist because I needed them on a real timeline that day. The first user is always me. The shipping bar is "would I install this tomorrow on a paying job". This changes the design surface in three ways: 1. The defaults are right because the maker lived inside them. Setting a default is a guess about the most common case. If you are the most common case, you are not guessing. 2. Features earn their slot in the panel. Anything that does not save time on a real shot gets cut. There is no marketing reason to keep a feature the maker themselves never reaches for. 3. The bug list is short and honest. You feel every regression because you hit it the next morning at 2am. This is not a no-code argument. It is not "everyone should learn to ship code". It is a positioning argument. The closer the maker is to the work, the less translation has to happen between intention and tool. AI changes the cost of this. Building the thing you needed used to take a development team and six months. Now it takes a directed run with Claude and an afternoon. The bottleneck moves from technical capability to taste, judgment, and knowing what the work actually demands. So if you are using a tool every day and feeling the gap, the gap is the brief. The next person to fix it should be you. The closest hand to the work makes the truest tool_ // A<3