Building With AI When You Don't Know Architecture: A Survival Guide

Thanks for the heads-up — no problem at all. I'll review the guidelines and add the disclaimer to the post.

98% of everything at both DEV.to and DZone is generated these days, I can "sniff" it in 2 seconds, and I see it everywhere ...

The shadow-puppet image is beautiful, and I think you've caught something real about how these threads work — though I'd gently turn it slightly. In 皮影戏 the figures move because a person behind the screen moves them; the puppets don't decide the story. I don't think we were the puppets here. I think we were the hands — a group of people, reasoning in the open, each pushing the figures a little, and the AI was the screen we projected onto, not the puppeteer. The distinction matters to me, because it's the whole thesis of what I write: the intelligence is real, but the shape comes from us.

Where I fully agree is that the process was the point, not the result. The best parts of this thread weren't the conclusions — they were the corrections, the disagreements, the moment someone said "your fix has its own failure mode" and the idea got sharper. A result is a snapshot; the process is where the understanding actually lived. You're right that we were rehearsing "how to build" — and maybe rehearsing it together, in public, argument by argument, is the only way that particular knowledge gets made.

Thank you for stepping back and naming the shape of the thing while we were inside it. That's its own kind of contribution.

Great addition, and it's a perfect example of a whole class of bug that catches beginners (and AI) off guard: the code isn't wrong in isolation — it's wrong in the context of where it runs. Reading localStorage during the initial render looks completely fine until you remember that in SSR/Next.js the server renders first, where localStorage doesn't exist, so the server HTML and the client's first render disagree — and you get the hydration mismatch, the layout shift, the console warnings. Nothing "errored" in the code; the environment is what made it wrong.

That's exactly why this one is so relevant to the "you don't know the architecture" crowd. AI generates the classic client-side React pattern (read from localStorage, set state) because that's the dominant pattern in its training data — and it works perfectly in a plain client-rendered app. Drop that same code into a server-rendered framework and it breaks in a way a beginner can't diagnose, because the failure isn't in the line they're looking at; it's in the mismatch between two render passes they didn't know existed. It's the server/client boundary biting again, just in a subtler spot than "secret leaked to the browser."

And your fixes are the right mental model: defer the localStorage read to useEffect (so it only runs client-side, after hydration) or use useSyncExternalStore (which is literally built for subscribing to external, client-only stores without tearing). The underlying lesson I'd hand a beginner: localStorage, window, and document don't exist during the server render, so anything that touches them has to wait until you're definitely on the client. That one rule prevents a surprising number of "it works locally but the deploy is throwing hydration warnings" mysteries. Great catch — this is a nice concrete instance of "the AI gave you code that's right for the wrong environment."

Thank you — and "piece together several components and hope for the best" is exactly the experience the title was reaching for; AI collapsed the slow path to systems thinking, so now people are doing the architecture before they've absorbed it, which is precisely why it feels like survival rather than design. Appreciate you reading!

"AI is not an architect, it's a concrete pourer" is the sharpest metaphor anyone's brought to this, and the follow-through is what makes it engineering instead of aphorism. The context-window ceiling point is the part people keep misdiagnosing: forgetting the page-3 constraint by page 50 isn't carelessness, it's physics — so the response can't be "write it more firmly" or "remind it harder," because you're arguing with a limit, not a behavior. Thicker specs fail for the same reason shouting at a wall fails. The rebar framing gets it exactly right: the constraint has to be physically in place before the pour, not carried in the pourer's memory, because the pourer's memory is the thing that structurally can't hold it.

And the modular-monolith-plus-physical-contracts move is the pragmatic version everyone reaching for "microservices as the red line" misses — you're right that microservices often eat back every hour AI saved in operational overhead, so you'd be paying a distributed-systems tax to enforce a boundary you can get for free at the module level. The three mechanisms are the whole thing: read-only contract files (a circuit breaker, not a gentleman's agreement), SDK-generated cross-module calls so the AI can't hand-roll a JSON URL around the boundary, and a CI contract check that turns a drifted field into a red light instead of a silent break. Each one converts a rule the AI might remember into a wall the AI can't cross — which is precisely the instruction-vs-execution-layer distinction another commenter drew, applied to architecture instead of runtime actions. Same principle, and it's the one that actually holds: don't enforce the constraint in the layer that can be talked out of it.

The line I'm keeping is "tie the rebar, then let the AI go wild inside its cell — you don't even need GPT-5, mini pours perfectly solid concrete inside those cages." That reframes the whole model-capability conversation: once the structure is physically enforced, the intelligence of the pourer stops being the risk, so you can use a cheaper model because the cage is what guarantees correctness, not the model's discipline. That's the difference between AI coding as a gamble and as assembly-line engineering — the gamble lives in hoping the model holds the constraints; the engineering lives in making the constraints unbreakable so the model doesn't have to. This is the engineering-grade layer the piece only gestured at, and it's going into the follow-up with full credit — "the architect ties the rebar, the AI pours the concrete, and the contracts are rebar only if they're physically read-only" is the thesis.

"The hard part isn't getting something to work, but figuring out exactly what changed after several rounds of AI-assisted edits" — that's the tax nobody prices in. Generation got cheap, so people run five rounds of edits in the time it used to take to write one, but each round quietly touches things you didn't ask about, and the cost moved from writing the change to knowing what the change actually was. You end up with something that works and a fuzzy picture of how it got there — which is fine until the "one change breaks two other things" moment, and now you're debugging a diff you never fully saw.

And you've put your finger on the asymmetry that matters: verifying changes has to scale with generating them, and right now only one side got faster. AI made producing edits nearly free while leaving understanding them exactly as expensive as before — so past the prototype stage, the bottleneck silently flips from "can I make this change" to "can I confirm this change did only what I intended." A cheap way to generate and no cheap way to verify isn't a productivity win, it's debt with a fast interest rate. The practical version people underuse: make the AI show you the diff and explain what it touched before you accept it, and keep changes small enough that "what changed" is still answerable — small reviewable steps beat one big impressive rewrite you can't audit.

Your last line is the whole article compressed: iteration got cheap, architecture didn't. The thing AI drove toward zero was the cost of trying; the thing it left untouched was the cost of structure and verification — and those are exactly the parts that decide whether a project survives its own growth. Cheap iteration on solid architecture is leverage; cheap iteration on none is just faster spaghetti. Great addition.

"You cannot even brief it on the break" — that's the precise moment the wall becomes a trap rather than just a difficulty. Early on, when something breaks you can at least describe it. Past the point where you've lost the shape of the project, you can't tell the AI what's wrong because you no longer know — and the AI will happily keep producing working-looking changes on top of a structure neither of you can see anymore. Two parties confidently editing a thing that only one of them ever understood, and that one has checked out. That's how a project goes from "messy" to "unrecoverable."

Your two habits are the fix, and I like that they map onto a before and a during. The one-page module map before the next feature re-establishes the shape in your own head — it's you refusing to keep building on a structure you can't currently draw. That's the antidote to "lost the shape": you don't add feature five until you can sketch what one through four actually are. And crucially, it's a map you hold, so you can brief the AI from it instead of guessing.

The hard list of files the agent may not touch this session is the sharper of the two, and it's the part most people miss. "Separate UI, logic, and data" is the structural cut — how the project is organized. "Name the fence for this session" is the operational cut — what the AI is allowed to touch right now. Those are different, and you need both: the first keeps the codebase coherent, the second keeps a single feature's blast radius contained so a change to the profile page can't quietly reach into auth. It's the execution-layer version of a constraint — not "please don't touch these" as a polite request in the prompt, but a fence you've decided on before the session starts and hold yourself. The AI reasons freely inside the fence; the fence is the thing you don't let it argue you out of.

"Separate UI, logic, and data is the first cut. Naming the fence for that session is the second." Going in the follow-up with credit — that's the pair, and the second one is the habit almost nobody names.

Exactly — the warning signs are lagging indicators (by the time fear shows up, the drift already shipped), and your cross-layer key assertion is the leading one: it converts "something feels off" into "this failed the day it broke," which is the whole difference between noticing drift and getting paged by it.

"Typist to architect" is the shift in two words, and your harness framing sharpens it in a way I want to steal: the human builds the deterministic harness, the AI generates probabilistic code inside it — and a weak harness means the AI confidently fills the empty space with spaghetti. That reframes structure from "good practice" into "the constraint that makes probabilistic generation safe." The AI isn't the problem; the absence of a shape for it to fill is. You give it a tight harness, you get tight code; you give it a vacuum, it improvises one, and its improvised structure is the thing that collapses.

But your point about state drift is the one I'll be repeating, because it's darker and truer than how I put it. When the same data lives in three places and they drift, the AI doesn't crash — it confidently proposes a fix, and because it's reasoning over an already-inconsistent picture, the fix makes the drift worse. So you enter this loop where you're not debugging code, you're debugging a hallucination built on top of a hallucination, and every "fix" deepens it. That's exactly why single-source-of-truth is where projects die silently — nothing errors, the app just quietly stops agreeing with itself, and the tool you'd normally lean on to help is now confidently making it worse. A single source of truth isn't a tidiness rule; it's what keeps the AI reasoning over reality instead of over a copy that's already wrong.

"You're not debugging code; you're debugging a hallucination" is going straight into how I explain this from now on, with credit. Thank you — this is the comment that adds the layer the article was missing.