The hidden cost of the Apex feedback loop

The loop you don't notice anymore

Here's a sequence every Salesforce developer runs dozens of times a day, mostly without thinking about it:

1. Change one line of Apex.
2. Deploy to a sandbox or scratch org.
3. Wait for the deploy to finish.
4. Run the test — in the Developer Console, or sf apex run test.
5. Wait for the test to queue and execute.
6. Read the result.
7. Switch back to your editor and remember what you were doing.

On a good day, steps 2 through 6 take two or three minutes. On a bad day — a large metadata set, a slow org, a test that has to spin up async jobs — it's five to ten. You've stopped noticing because it's just how Apex works. That's exactly why it's expensive: invisible costs don't get optimized.

The arithmetic nobody does

Let's do the back-of-the-envelope math. Say you run that loop 40 times on a normal coding day — a conservative number if you're actually iterating, debugging, or doing anything test-driven. Say each round-trip averages three minutes of deploy-and-run.

40 loops/day  ×  3 min/loop   =  120 min/day
120 min/day   ×  5 days       =  10 hours/week
10 hrs/week   ×  46 weeks      =  ~57 working days/year

Roughly a quarter of your coding time, spent watching a progress bar. And this is the optimistic version — it ignores the days the sandbox is down, the deploy that fails on an unrelated validation rule, and the scratch org that expired overnight.

But the clock time is the part that's easy to defend against ("it's only three minutes"). The expensive part is what those three minutes do to your head.

The real tax is on focus, not the clock

Three minutes is precisely the wrong length of time. It's too long to sit and stare at, and too short to context-switch into anything useful. So you check Slack. You read an email. You glance at another ticket. By the time the test result comes back, the mental model you'd built — the exact reason you made that change — has evaporated, and you spend thirty seconds rebuilding it before you can even read the result.

Programmers have a name for the state where this doesn't happen: flow. Flow requires that the gap between "I did a thing" and "I see the result" stays under about a second. Past that, your attention leaks. The Apex loop blows through that budget on every single iteration, all day. You don't lose the three minutes — you lose the flow the three minutes interrupts.

The loop shapes your code, too

This is the cost almost nobody talks about. When feedback is slow, you unconsciously optimize to run the loop less often. That sounds responsible. It isn't — it warps your design decisions:

• You batch changes. Instead of one small, verifiable change, you make five and deploy once — so when it breaks, you have five suspects instead of one.
• You under-test the boring paths. Writing a test means another full loop, so the null check and the empty-list case quietly go uncovered.
• You avoid refactoring. A refactor is a hundred tiny verifications. At three minutes each, nobody does it, so the class that should have been split three years ago is now 2,000 lines.
• You debug by System.debug. Adding a log line and redeploying feels faster than reasoning carefully — so the codebase accretes debug statements and the real cause stays hidden.

Slow feedback doesn't just make good practices slower. It makes them feel irrational, so people stop doing them. The loop is a design force.

The thought experiment: what if it were instant?

Forget tooling for a second and just imagine the loop took one second instead of three minutes. What changes?

You'd make smaller changes, because verifying one is free. You'd write the edge-case test because it costs nothing to run it. Refactoring becomes safe, because the safety net fires instantly on every keystroke. You'd stop reaching for System.debug and start stepping through the actual execution, because you can. Test-driven development stops being an aspiration you gave up on and becomes the path of least resistance.

None of that is a productivity hack. It's just what happens to human behavior when you remove the friction. Every ecosystem that closed this gap — save the file, see the result — saw the same shift. Apex is one of the last places it hasn't happened yet, and the reason is purely mechanical: the runtime lived in the org, and the org lived in the cloud.

Where this is going

The fix isn't a faster sandbox or a better deploy pipeline — those shave seconds off a loop that's structurally minutes long. The fix is to move the runtime next to the editor so the org stops being on the critical path of every change. That's the entire premise behind Nimbus: an Apex runtime on your laptop that runs your existing tests in milliseconds, with the org reserved for the things that actually need it — staging, integration, deployment.

You don't have to take my word for the arithmetic. Point it at a project you already have and run the suite once. The number that comes back — and how it feels — makes the case better than any blog post.