Prompt Engineering for Architects: Using LLMs to Validate System Design Constraints

The hardest part of software engineering isn't writing code. It's realizing - three months into production - that your beautiful, clean architecture collapses under real-world race conditions.

Traditional design reviews are imperfect. Your colleagues are polite. They have their own deadlines. They might nod along to your "eventually consistent" proposal without calculating the exact latency penalty.

But an LLM has no social anxiety. It has read every post-mortem on the internet. It knows every way Kafka can lose messages and every way a distributed lock can fail. The problem is, by default, LLMs are trained to be helpful and agreeable.

To get real value, you need to break that conditioning. You need to prompt the AI to be hostile.

The "Hostile Architect" Persona

To get high-quality critique, you need to force the LLM out of its "helpful assistant" mode. You need to define a persona that is expert, cynical, and hyper-critical.

We aren't asking for code generation; we are asking for Falsification. We want the AI to prove us wrong.

The Core System Prompt

Don't just paste your requirements. Use this prompt structure to turn ChatGPT or Claude into the toughest reviewer you've ever met:

Practical Example: The "Simple" Rate Limiter

Let’s say you are designing a rate limiter for a high-traffic API. You propose a simple solution using Redis to count requests.

Your Proposal to the LLM:

The "Helpful" AI Response:

The "Hostile Architect" Response:

See the difference? The hostile persona saved you from a production bug.

The Solution: Atomic Rate Limiting in Java

Based on the "Hostile Architect's" feedback, we know we need atomicity. We can't use simple GET and SET. We need to use a Lua script (for Redis) or a Token Bucket algorithm implemented purely in memory if we are avoiding network hops.

Here is how you might implement a thread-safe, robust Token Bucket in Java to satisfy the architect's demand for atomicity and handling "bursts" correctly.

import java.time.Instant; import java.util.concurrent.atomic.AtomicLong; import java.util.concurrent.atomic.AtomicReference; public class TokenBucketRateLimiter { private final long capacity; private final double refillTokensPerSecond; private final AtomicReference<State> state; // Immutable state object to ensure atomicity via CAS (Compare-And-Swap) private static class State { final double tokens; final long lastRefillTimestamp; State(double tokens, long lastRefillTimestamp) { this.tokens = tokens; this.lastRefillTimestamp = lastRefillTimestamp; } } public TokenBucketRateLimiter(long capacity, double refillTokensPerSecond) { this.capacity = capacity; this.refillTokensPerSecond = refillTokensPerSecond; // Start full this.state = new AtomicReference<>(new State(capacity, System.nanoTime())); } public boolean tryConsume() { while (true) { State current = state.get(); long now = System.nanoTime(); // 1. Refill tokens based on time passed long timeElapsed = now - current.lastRefillTimestamp; double newTokens = Math.min(capacity, current.tokens + (timeElapsed / 1_000_000_000.0) * refillTokensPerSecond); // 2. Check if we have enough tokens if (newTokens < 1.0) { return false; // Rejected } // 3. Attempt to atomically update state State next = new State(newTokens - 1.0, now); if (state.compareAndSet(current, next)) { return true; // Allowed } // If CAS failed, loop again (optimistic locking) } } }

Why this satisfies the Hostile Architect:

1. Atomicity: It uses AtomicReference and "Compare-And-Swap" (CAS). There is no window where two threads can read the same state and act incorrectly.
2. No "Fixed Window" Spike: The token bucket smoothes out bursts naturally.
3. Low Latency: It runs entirely in-memory, avoiding the network round-trip penalty of the naive Redis approach (though for a distributed system, you would eventually need to port this logic to a Redis Lua script).

The Feedback Loop

The key to this workflow is the Loop.

1. Draft: Create your design.
2. Attack: Feed it to the "Hostile Architect" LLM.
3. Refine: Update your design based on the flaws found.
4. Verify: Ask the LLM, "If I implement this fix, what breaks next?"

Conclusion

AI is a tool for leverage. If you use it to just "write code," you are using a Ferrari to deliver pizza. Use it to think. Use it to simulate the worst-case scenarios that your optimistic human brain tries to ignore.

The next time you are designing a system, don't ask the AI if it works. Ask it how it breaks.

\