A couple of months ago I was in a long design session with a team. We were sketching a fairly ambitious system on a whiteboard — boxes, arrows, contracts between services, all the usual moves. When time ran out and we packed up, I looked back at what we'd built.
The easy parts of the system were specified beautifully. The pieces that involved deterministic logic, clear schemas, retries, and well-understood failure modes were tight. The hard parts — the ones that required real thinking about ambiguous behavior and edge cases — had been absorbed into a single box. The label inside the box was some variant of "LLM does this." We had not designed the inside. We had named it, drawn a perimeter around it, and moved on.
I'm calling this the Lazy Boundary: instead of finishing the design, you draw a box around the part you don't want to think about and declare it the LLM's problem.
It's seductive in a way that nothing in the pre-LLM world quite was. Before, if an under-specified ticket made it to an engineer, the engineer would float it back up looking for answers. They had to — the code wouldn't write itself. With LLMs in the picture, you get plausible deniability. When the system misbehaves, you push the ticket back down with "improve your prompts," and the architectural shrug becomes someone else's problem.
The trade-off is real. Outside the box, you get what deterministic code gives you: predictable behavior, low latency, low cost per call, auditability, debuggability, and tests that actually mean something. Inside the box, you get flexibility and the ability to handle inputs you couldn't have enumerated. You also get non-determinism, higher per-call cost, slower responses, and a debugging story that often comes down to staring at logs and guessing.
LLMs belong in some boxes. The anti-pattern isn't using them; it's letting the boundary be drawn by fatigue rather than by design. A boundary chosen for the right reasons — "we genuinely cannot enumerate the inputs here, and the cost of being wrong is bounded" — is engineering. A boundary chosen because it's 5 p.m. and the whiteboard is full is avoidance.
The discipline is to keep asking one question of every LLM-shaped box: why is this still inside? Each time you can answer it, the box gets a little smaller, and a little more of the system becomes fast, cheap, and explicable. The boundary is a design decision. Treat it like one.