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. helpful agreeable To get real value, you need to break that conditioning. You need to prompt the AI to be hostile. 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. Falsification 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: Role: You are a Principal Software Architect at a FAANG company with 20 years of experience in distributed systems. You are famous for your rigorous, unforgiving design reviews.
Goal: Your job is not to be polite. Your job is to find flaws, bottlenecks, race conditions, security risks, and scalability issues that others miss. You assume everything will fail at scale.
Task: I will present a system design proposal. You must tear it apart. Focus specifically on:

Single Points of Failure (SPOF)
Data Consistency anomalies (especially under network partitions)
Latency bottlenecks (calculate the math)
Security vulnerabilities (IDOR, Injection, etc.)

Output: Do not give me generic advice. Give me specific scenarios where my design breaks. Role: You are a Principal Software Architect at a FAANG company with 20 years of experience in distributed systems. You are famous for your rigorous, unforgiving design reviews. Role: Goal: Your job is not to be polite. Your job is to find flaws, bottlenecks, race conditions, security risks, and scalability issues that others miss. You assume everything will fail at scale. Goal: Task: I will present a system design proposal. You must tear it apart. Focus specifically on: Task: Single Points of Failure (SPOF)
Data Consistency anomalies (especially under network partitions)
Latency bottlenecks (calculate the math)
Security vulnerabilities (IDOR, Injection, etc.) Single Points of Failure (SPOF) Single Points of Failure (SPOF) Data Consistency anomalies (especially under network partitions) Data Consistency anomalies Latency bottlenecks (calculate the math) Latency bottlenecks Security vulnerabilities (IDOR, Injection, etc.) Security vulnerabilities Output: Do not give me generic advice. Give me specific scenarios where my design breaks. Output: 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: Your Proposal to the LLM: "I want to build a rate limiter in Java. I'll use Redis to store a counter for each API key. On every request, I'll GET the counter. If it's < 100, I'll INCR it. If it's > 100, I reject the request. The key expires every minute." "I want to build a rate limiter in Java. I'll use Redis to store a counter for each API key. On every request, I'll GET the counter. If it's < 100, I'll INCR it. If it's > 100, I reject the request. The key expires every minute." GET INCR The "Helpful" AI Response: The "Helpful" AI Response: "That sounds like a great approach! Redis is fast and suitable for this. Here is some Python code to help you get started..." "That sounds like a great approach! Redis is fast and suitable for this. Here is some Python code to help you get started..." The "Hostile Architect" Response: The "Hostile Architect" Response: CRITIQUE: This design is fundamentally flawed and will fail under concurrency.

Race Condition: The GET and INCR operations are not atomic. Two requests can read "99" simultaneously. Both will increment. You will allow 101 requests. At scale, you could allow thousands more.
Network Latency: You are making two round-trips to Redis for every single API call (GET then INCR). This doubles your latency overhead.
The "Fixed Window" Spike: If a user sends 100 requests at 10:00:59 and another 100 at 10:01:01, you effectively allow 200 requests in 2 seconds. You need a sliding window log or token bucket algorithm, not a fixed TTL counter. CRITIQUE: This design is fundamentally flawed and will fail under concurrency. CRITIQUE: Race Condition: The GET and INCR operations are not atomic. Two requests can read "99" simultaneously. Both will increment. You will allow 101 requests. At scale, you could allow thousands more.
Network Latency: You are making two round-trips to Redis for every single API call (GET then INCR). This doubles your latency overhead.
The "Fixed Window" Spike: If a user sends 100 requests at 10:00:59 and another 100 at 10:01:01, you effectively allow 200 requests in 2 seconds. You need a sliding window log or token bucket algorithm, not a fixed TTL counter. Race Condition: The GET and INCR operations are not atomic. Two requests can read "99" simultaneously. Both will increment. You will allow 101 requests. At scale, you could allow thousands more. Race Condition: GET INCR Network Latency: You are making two round-trips to Redis for every single API call (GET then INCR). This doubles your latency overhead. Network Latency: GET INCR The "Fixed Window" Spike: If a user sends 100 requests at 10:00:59 and another 100 at 10:01:01, you effectively allow 200 requests in 2 seconds. You need a sliding window log or token bucket algorithm, not a fixed TTL counter. The "Fixed Window" Spike: 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. GET SET 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. Token Bucket 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)
        }
    }
} 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: Atomicity: It uses AtomicReference and "Compare-And-Swap" (CAS). There is no window where two threads can read the same state and act incorrectly.
No "Fixed Window" Spike: The token bucket smoothes out bursts naturally.
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). Atomicity: It uses AtomicReference and "Compare-And-Swap" (CAS). There is no window where two threads can read the same state and act incorrectly. Atomicity: AtomicReference No "Fixed Window" Spike: The token bucket smoothes out bursts naturally. No "Fixed Window" Spike: 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). Low Latency: The Feedback Loop The key to this workflow is the Loop. Loop Draft: Create your design.
Attack: Feed it to the "Hostile Architect" LLM.
Refine: Update your design based on the flaws found.
Verify: Ask the LLM, "If I implement this fix, what breaks next?" Draft: Create your design. Draft: Attack: Feed it to the "Hostile Architect" LLM. Attack: Refine: Update your design based on the flaws found. Refine: Verify: Ask the LLM, "If I implement this fix, what breaks next?" Verify: 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. think The next time you are designing a system, don't ask the AI if it works. Ask it how it breaks. how it breaks

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Code Review Anti-Patterns: How to Stop Nitpicking Syntax and Start Improving Architecture

Everything a self-taught developer shouldn't do

The Noonification: Subjectivity and the Evolution of AI Philosophy (11/22/2023)

The Noonification: The State of Webhooks in 2023 (10/28/2023)

The Noonification: A Game-Changing Leap in Voice AI Technology (10/22/2023)

The Noonification: Go and Protocol Buffers (Quick Tutorial) (10/15/2023)

Code Review Anti-Patterns: How to Stop Nitpicking Syntax and Start Improving Architecture

Everything a self-taught developer shouldn't do

The Noonification: Subjectivity and the Evolution of AI Philosophy (11/22/2023)

The Noonification: The State of Webhooks in 2023 (10/28/2023)

The Noonification: A Game-Changing Leap in Voice AI Technology (10/22/2023)

The Noonification: Go and Protocol Buffers (Quick Tutorial) (10/15/2023)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps