# Claude Code and no-code agents are just making bad system design > Source: > Published: 2026-09-08 17:00:50+00:00 # Claude Code and no-code agents are just making bad system design Writing the implementation is the easy part; the hard part is the architectural judgment. When a model generates a feature, it looks "done" because the code is clean and the UI is there, but the underlying system design is often a disaster waiting to happen. We're seeing a trend where the friction of writing code has vanished, but the cognitive load of designing the system has actually increased because we're now debugging "invisible" architectural gaps instead of obvious syntax errors. ## The "invisible" data corruption trap When you ask an LLM agent to build a customer database with orders and shipping addresses, it'll spit out tables in seconds. But it won't ask you about data normalization or the business logic of address ownership. For example, does the address belong to the user profile or the specific order? If the AI defaults to the former and a user updates their address after an order is placed, you've just corrupted your historical shipping records. You won't get a 500 error or a crash—you'll just get silently wrong data. That's a schema design failure, not a coding bug. ## State persistence isn't a coding problem A prompt-generated checkout flow is a dream in a five-minute demo. But real-world usage involves session persistence across devices. I've seen "AI-built" features where a user adds an item to a cart on mobile, switches to a laptop, and finds an empty cart because the agent didn't account for cross-device state synchronization. Decisions about where state lives and how it's synced across sessions have to be made before the first line of code is written. You can't just "prompt" your way into a robust session management strategy. ## The 429 error and the "happy path" fallacy Most AI-generated API integrations are written for the "happy path." If you're using a third-party payment API and it returns a `429 Too Many Requests` or a timeout, a basic AI-generated function will likely just throw an unhandled exception. This isn't a bug to be patched; it's a design decision. You have to decide: - **Retry logic:** Does the system implement exponential backoff? - **Queueing:** Should the request be pushed to a message queue? - **Degradation:** Does the UI show a "service temporarily unavailable" message or just crash? None of these architectural choices are implied by a prompt like "connect to the Stripe API." ## Security boundaries are the hardest to spot "Let users manage their own profiles" is a classic prompt that looks great in a demo with one test user. However, without a conscious design for access control, you often end up with IDOR (Insecure Direct Object Reference) vulnerabilities. If user A can change a `userId` in a GET request to view user B's data, that's a failure in security architecture. Because the code "works" and the feature is "complete," these gaps often slip through to production because they don't announce themselves until you have actual multi-tenant traffic. Essentially, AI hasn't replaced the engineer; it has just shifted the engineer's job from writing syntax to auditing architecture. If you're using these tools for a real-world deployment, you need a deep dive into the system design before you let the AI start generating files. [Next Using a single database for graph RAG is way more efficient than →](/en/threads/8995/)