When you don’t validate inputs, don’t be surprised when the system gets abused.
Context
In my previous refactor, I removed a core anti-pattern:
Default behavior:
→ say yes
→ be available
→ be helpful
That fix exposed something deeper.
The real issue wasn’t just over-availability.
It was the absence of boundary checks.
The Bug: No Input Validation
For a long time, my system operated like this:
Incoming request → accept → execute
No filtering.
No validation.
No consideration of cost.
Everything got processed.
Requests, expectations, emotional load—queued and handled in real time.
I thought this made me “reliable.”
In reality, it made me unprotected.
What Happens Without Boundary Checks
In software, if you don’t validate inputs, two things happen:
Bad data gets in
The system becomes unpredictable
Human systems behave the same way.
Without boundaries:
unreasonable requests feel normal
disrespect gets reclassified as personality
urgency is assigned by whoever asks first
You don’t control the system anymore.
You just maintain it.
The API Problem: People Probe for Limits
Here’s the part I didn’t understand before:
People don’t always consciously exploit you.
But they do test for limits.
Like hitting an API endpoint:
Request → response
Adjust → request again
If the system always returns:
200 OK
Then the behavior escalates.
small asks become bigger asks
favors become expectations
access becomes assumed
Not because people are malicious.
Because the system allowed it.
The “Nice” Misconfiguration
I had configured my system like this:
Boundary checks: disabled
Rate limiting: none
Access control: open
And then I was surprised when:
I felt drained
people expected more
saying no felt disruptive
But from the outside, the system was working exactly as designed.
The Cost of No Validation
- Priority Corruption
Without boundaries, your priorities get overwritten by external input.
Whoever asks first—or loudest—wins.
- Silent Resentment
When you say yes against your own capacity, the system logs it:
Accepted request ≠ aligned decision
That mismatch turns into resentment over time.
- Identity Drift
If everything gets accepted, nothing is chosen.
And if nothing is chosen, you disappear from your own decision-making.
The Fix: Implement Boundary Checks
I didn’t try to “be less nice.”
I added validation.
- Request Evaluation Layer
New flow:
Incoming request
→ evaluate (Do I want this? Do I have capacity?)
→ optional response
Not everything passes.
- Explicit Rejection Handling If (request ≠ aligned) → return: No
No long explanations.
No defensive reasoning.
Just a clean response.
- Access Control
Not everyone gets the same level of access.
Access levels:
- earned
- limited
- revoked
This used to feel harsh.
Now it feels accurate.
- Rate Limiting
Immediate response is no longer the default.
Response time = intentional
Urgency is no longer assigned externally.
What Changed
Once boundary checks were in place:
fewer bad inputs reached execution
expectations recalibrated
some “users” stopped making requests altogether
That last part matters.
When a system stops being easy to exploit, it stops attracting exploitative behavior.
Reframing “Nice”
The old model:
Nice = always accessible
The updated model:
Respectable = selective + clear
And a hard truth:
If your system never rejects a request,
it’s not kindness.
It’s misconfiguration.
Takeaway
Boundaries aren’t about controlling other people.
They’re about defining what your system accepts.
If you don’t implement boundary checks, the world will write your rules for you.
And it won’t optimize for your well-being.
Status
Boundary checks: enabled
Default response: not guaranteed
System integrity: improving
Series: Behavioral Anti-Patterns
Previous: Deleting the “Nice” Anti-Pattern
Next: Unbounded Processes: The Hidden Cost of Always Saying Yes
Top comments (7)
This is such a clever and immediately relatable way to translate software concepts into human behavior.
The “boundary checks” metaphor is especially strong because it reframes being nice from unlimited availability into intentional, validated access.
I loved the API comparison—when every request returns “200 OK,” it makes perfect sense that expectations can gradually escalate.
The sections on priority corruption, silent resentment, and identity drift brilliantly capture what happens when external input constantly overrides internal priorities.
The shift from “be less nice” to “add validation” is such a powerful reframing: boundaries don’t eliminate kindness, they make it sustainable.
And “If your system never rejects a request, it’s not kindness. It’s misconfiguration” is an absolute mic-drop of a takeaway.
This one lands cleanly.
The API metaphor is especially effective: people probe for limits the same way clients test endpoints. If the system always returns 200 OK, escalation is inevitable—not because people are malicious, but because the interface allowed it. That distinction removes the moralizing and focuses on system design.
The three costs you named—priority corruption, silent resentment, and identity drift—are precise. When everything is accepted, nothing is actually chosen, and you slowly disappear from your own decision-making.
The updated model (“Respectable = selective + clear”) feels like the right replacement for the old “nice = always accessible” configuration. And the observation that some “users” simply stop making requests once boundary checks are enabled is both practical and telling.
Strong entry in the series.
YESSSSSSSSSSSSS >>>>>>>>>> "Boundaries aren’t about controlling other people.
They’re about defining what your system accepts.
If you don’t implement boundary checks, the world will write your rules for you.
And it won’t optimize for your well-being"
The line that stayed with me: "Accepted request ≠ aligned decision." Framing resentment as the system logging a mismatch between what you agreed to and what you actually wanted is a useful way to see it. Resentment stops looking like a character flaw and starts looking like a signal that a boundary check was skipped.
I also liked the API probing analogy, especially the point that people don't always consciously exploit you, they escalate because the system keeps returning 200 OK. That's a fairer and more accurate account than "people take advantage," and it makes the fix feel less adversarial.
One addition: boundary checks work better when they're communicated, not just enforced. In software, a good API returns a clear error with a reason code so the caller can adjust. People often can't adjust to a limit they've never been told about. A short, warm, non-defensive no ("I can't take that on this week, but I could do X") gives them the chance to recalibrate, and it filters for who respects the boundary. Your point that some users stop making requests then reads as information about them, not a sign the system failed.
I'd also gently note that the "earned, limited, revoked" access model fits some relationships better than others. With close family or a partner, a permissions framing can feel transactional, and the more useful check may be "is this reciprocal over time?" than "who gets what tier."
Thanks for the clear, practical write-up. The "world will write your rules for you" line is one I'll remember.
The “boundary checks” metaphor makes this idea especially clear: the problem isn’t simply being helpful—it’s allowing every request to reach execution without evaluating whether it belongs there.
A few highlights stood out:
The line “If you don’t implement boundary checks, the world will write your rules for you” captures the larger lesson beautifully.
A healthy system doesn’t need to process every request that reaches it.
Sometimes integrity looks less like improving execution and more like deciding what never gets executed in the first place.
Thank you for sharing this amazing writing here on DEV.to cheers!
Great essay thank you!