Raja Tashfeen

Spent months reviewing AI-written code line by line like a pull request, and it was draining my speed.

Recently switched to checking the test cases first instead. It instantly shows what the AI thinks the logic is supposed to do especially when it completely misunderstands the business rules.

Anyone else checking tests before touching the actual implementation code?

An agent can have permission to use a tool without having enough context to make the business decision behind it. That's the boundary I'd want to define before giving it write access.

For me, drafting a customer email and sending it are separate permissions. Recommending a budget change and applying it are separate decisions. The useful question is what the agent can commit you to, and who carries the consequence if it gets that wrong.

I'd define the allowed action, the affected people or systems, the spending limit where relevant, and the point at which a named person must approve. I'd also want that person to see what will change before agreeing.

Rollback helps, but it doesn't erase every consequence. You can restore a price after someone has bought at it. You can correct an email after someone has acted on it. Neither returns you neatly to the starting position.

A credit balance turns every click into a purchase decision. That's the whole problem and it has nothing to do with the price being too high.

In a tool with several studios a video render costs roughly 40x an image. One credit unit spanning both means the user is doing arithmetic before every button, and the arithmetic gets worse as the balance drops. The first render feels free. The third one has a price tag on it. People stop long before the balance hits zero, and that shows up in your dashboard as low usage, never as a complaint about cost.