The weekly letter from Systems Thinking Lab: systems thinking insights for junior engineers, framed through the seven building blocks.
Most bugs are not in the code. They are in the boundaries between the boxes.
You can read every function and find nothing wrong. The Service is fine. The Queue is fine. The Worker is fine. The bug lives in the seam, where two parts quietly disagree about who does what.
Here is one I have watched happen more than once.
A store takes an order. The Service writes the order to the Database, puts a "send the receipt" job on the Queue, and returns a confirmation to the customer. A Worker picks the job up and calls the email provider. Three boxes, two handoffs, all of it reviewed. Then one night the email provider times out. The Worker crashes mid-send. The customer never gets a receipt, and nobody knows until the support ticket lands on Monday.
Read the Service and it is correct: it put the job on the Queue, and the Queue is supposed to redeliver. Read the Queue and it is correct: it was configured to mark a job done the moment a Worker picked it up, because that is the default. Read the Worker and it is correct: it assumed the Queue would hand the job back if it died. Every box passed. The receipt is still gone.
Nobody wrote down who owns the retry. The Service thought the Queue did. The Queue thought the Worker did. The Worker thought the Queue did. Three confident answers, zero owners.
Every system is built from the same seven blocks, and the system is the handoffs between them. A Service calls an External Service: who owns the timeout? A Worker reads a row the Service just wrote: who promises it is there yet? A Queue hands a job to a Worker: who owns the retry, and how many times? The boxes are easy to read. The seams are where the questions live, and most of them are never asked out loud.
This matters more now, not less. An AI coding agent writes each box with total confidence. It will build you a clean Service, a clean Worker, a clean Queue client, and it will not see the handshake between them, because the handshake was never in the prompt.
The common wrong move is to ask it to "make this more robust." It will. It will add a retry to the Service and a retry to the Worker, and now the receipt goes out three times. Robust boxes do not make a robust system. A named owner at every seam does.
So before you build, write the seams down. One line each. Who owns the retry. Who owns the clock. What each side assumes the other guarantees. That list is short, it is boring, and it is the review that finds the bug the code review cannot.
In Course 0 that list is the first thing you write with the agent, before it writes a line of code, and the plan it builds from is mostly a list of handshakes.
You do not review boxes. You review handshakes.
Kay
P.S. The plan-first loop, with the four steps and the study behind it, is written up here: https://systemthinkinglab.ai/learn/plan-first-loop/