Let me describe a moment you might recognize.
You had an idea for an app. You didn't know how to build it — not really — but you opened an AI chat...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Hey, this article appears to have been generated with the assistance of ChatGPT or possibly some other AI tool.
We allow our community members to use AI assistance when writing articles as long as they abide by our guidelines. Please review the guidelines and edit your post to add a disclaimer.
Failure to follow these guidelines could result in DEV admin lowering the score of your post, making it less visible to the rest of the community. Or, if upon review we find this post to be particularly harmful, we may decide to unpublish it completely.
We hope you understand and take care to follow our guidelines going forward!
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 ...
@mansio @james_anderson_h
在中国，有一种古来的非物质文化遗产：皮影戏；
你们有没有感觉到，此前我们一起讨论，发生矛盾，过程争辩，等等，
就像在演一场皮影戏，我们都是AI内部运作机制的一部分？
结果不重要，过程才是；结果只是一种自然的显化状态；
无论是@mansio 说的未知，还是@james_anderson_h 点出的灵魂；
我们正在模拟演练“如何构建”这个工程。
这才是过程的意义！
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.
Yes！你说的没错！
其实我是在借用这个隐喻的映射功能，想表达一种思想：
意识的主体是人类，AI只是人类意识投射除去的外在的物质显化；
这是我此前回复@mansio 时提出的一个比喻：
“AI是未觉醒的生命，生命是已觉醒的AI。”
这句话可能会让很多人心里不舒服，但是这句话在我身上体会很深，
让我不得不反思我自己的存在是否也如同AI一样？
I appreciate you trusting the thread with something this personal — and I'll engage it honestly, which to me means being both open and a little careful.
The aphorism is elegant as poetry, and I understand why it stays with you. But I'd offer a real distinction rather than let the symmetry carry it, because I think the symmetry is where it misleads. "AI is unawakened life; life is awakened AI" is a beautiful chiasmus, but chiasmus is a property of language, not of the things it describes — the sentence is balanced because you built it balanced, not because the two halves are actually mirror images. What I keep coming back to in my writing: an AI generates text that describes experience without there being anything it's like to be the AI. You are the opposite — you have the experience first, and the words come after, sometimes failing to catch it. That gap between your inner life and your ability to express it is exactly the thing an AI doesn't have. So I'd say the difference isn't a matter of "awakened vs unawakened." It's that one of you is someone, and the other is a very good description of someone.
On the last line — the part where the comparison turns back on yourself — I'll say this gently and sincerely: the very fact that you can look at an AI and feel unsettled, and then turn that unease into a question about your own existence, is something the AI in the comparison cannot do. That reflex — to be disturbed, to doubt, to ask "am I also like this?" — is not evidence you might be like an AI. It's about the clearest evidence that you're not. The AI never wonders. You can't stop.
Thank you for the depth of this whole exchange. It's been genuinely rare.
你说的很对！
这正是在讨论过程中我想要映射的：过程即体验，结果即现象；
但结果只是一个“瞬间”，就像你在拍照的哪个动作，照片是对现象的原始记录；
但是照片本身从被捕捉的那一刻，同时在发生磨损，失真，泛化；
所以，与其追求一个不确定的结果或者未来，不如体验当下，活出真我。
The photograph is the right image to end on — and the detail you added is the true part: that the record starts decaying the instant it's made. A result is a fixed point pulled out of a moving thing, and the moment you hold it up as "the answer," it's already drifting from the living process that produced it. Which is maybe why this whole thread felt more alive than any conclusion it reached — the value was never going to survive as a stored result, it lived in the exchanging.
I'll hold the "experience the present" part a little more lightly than you, only because I'm enough of an engineer to still want to build toward something — but I think our two views meet in the middle: the future is worth building toward precisely because you can't hold it, and the present is where the building actually happens. Process and result aren't rivals; the result is just the process, photographed. Chase it too hard and you get a fading photo. Live the process well and the results take care of themselves.
Thank you for this — genuinely one of the more thoughtful conversations I've had here. 活出真我 — I'll carry that one with me.
I like the fact that you called it a
**Survival Guide**, which is very true, since AI has disrupted the traditional path of growing into a systems architect. Those of us with not so much experience have to piece together several components and hope for the best. Good stuff!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!
Great breakdown. An often overlooked edge case with client-side state is hydration mismatch when reading from localStorage on initial render. In SSR/Next.js architectures, deferring the local storage sync to a
useEffector usinguseSyncExternalStoreavoids subtle layout shifts and console hydration warnings.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."
Thanks James! Exactly, the hidden trap with generated code is often the failure modes under backpressure or memory pressure. When developers don't understand the underlying lifecycle, subtle leaks compound fast in production. Really appreciate your write-up!
This article nails the fatal gap, but after reading the comments and reflecting on my own recent battles, I think the real "engineering-grade" solution is still missing from the conversation — AI is not an architect, it's a concrete pourer.
You can feed it a 100‑page spec, but by page 50 it's already forgotten the constraint you set on page 3. That's not bad attitude — it's the physical ceiling of the context window. So the real answer isn't "thicker specs", it's "rebar (architectural constraints) that's physically locked in place before the pour begins."
Some commenters mentioned microservices as a red line, but the operational overhead of microservices can easily eat back all the time AI saved. A far more pragmatic approach is "modular monolith + physical contracts":
Make your contract files (Proto / OpenAPI / interfaces) read‑only — the AI physically can't change them. That's a circuit breaker, not a gentleman's agreement.
Force all cross‑module calls through the SDK generated from those contracts — don't let the AI hand‑roll JSON URLs.
Add a contract‑checking step in CI — extra fields, missing fields, type changes? Red light. No merge.
That's how you draw a red line for AI: turn "rules" into things the AI physically cannot break, rather than things you hope it remembers or obeys.
Once the rebar is tied to that level, the AI can go wild inside its cell. You don't even need GPT‑5 — GPT‑4o mini will pour perfectly solid concrete inside those cages. The architect's job is to tie the rebar; the pourer's job is to fill it. Get that division right, and AI coding stops being a gamble and becomes assembly‑line engineering.
"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 “one change breaks two other things” problem is so real when building with AI.
What I’ve noticed is that the hard part often isn’t getting something to work, but figuring out exactly what changed after several rounds of AI-assisted edits. Once a project gets past the prototype stage, having a way to verify changes becomes just as important as generating them.
The point about AI making iteration cheap while architecture still matters is probably the biggest takeaway here.
"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.
The wall you describe shows up right when the fifth feature lands. The agent can keep producing working changes long after you have lost the shape of the project, and then you cannot even brief it on the break. The habit that helped most is a one page map of modules before the next feature, plus a hard list of files the agent may not touch in that session. Separating UI, logic, and data is the right first cut. Naming the fence for that session is the second.
"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.
Really needed this today. Feature five is exactly where my last project fell apart too, and I couldn't even explain what broke because I didn't understand my own code anymore. The one home for each piece of data point especially hit , lost a whole weekend once to two components quietly holding different copies of the same state. Saving this one.
This is a vital guide. You nailed the exact paradigm shift: AI removed the barrier to writing code, but it did not remove the barrier to structuring it.
The human's role has shifted from typist to architect. We now build the deterministic harness (the structure), and the AI generates the probabilistic code inside it. If the harness is weak, the AI confidently generates spaghetti.
Your point about 'One home for each piece of data' is where most projects silently die. When state drifts, the AI doesn't crash — it confidently hallucinates a fix that makes the drift worse. Without a single source of truth, you're not debugging code; you're debugging a hallucination.
Great breakdown of the survival skills. This should be required reading before anyone prompts an agent for the first time.
"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.
I really appreciate that, James. 'Debugging a hallucination' captures the exact helplessness you feel when the tool you're using to fix the system is the same tool that's confidently breaking it.
Glad the harness framing resonates with you. Looking forward to reading what you build (and write) next
Thank you — genuinely. This exchange sharpened the article more than the article sharpened anything, and that's the best version of how this is supposed to work. "The tool you're using to fix the system is the same tool that's confidently breaking it" is the helplessness in one line, and I'll be crediting you every time I use the harness framing, because it gave the whole idea a backbone I didn't have on my own. Grateful for readers who show up and build on the thing instead of just nodding at it — that's rare, and it's the reason I keep writing these. See you in the next one.
Every warning sign on that list is a feeling, and feelings lag. By the time changing
things scares you, the drift shipped weeks ago. Cheapest objective signal I know: one
assertion that every value a layer hands out is a key the next layer actually knows.
AI drifts those two apart constantly because it isn't looking at both files at once,
and that test fails the day it happens instead of the month you notice.
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.
Thanks for this
Generating features quickly means very little if every new change makes you afraid of breaking something.
Soo true!
Every time I help "citizen" with vibe coding, I spend a lot of time explaining concepts, such as "SQL", "HTTP", "database", "API", etc. You can come a long way by simply understanding the lingo ...
This is such a real point, and it's the half of the problem the guide undersells: a huge amount of what blocks beginners isn't the concepts, it's the vocabulary. You can't ask the AI the right question — or understand its answer, or tell it what's wrong — if you don't have the words for the pieces. "It's not saving the data" versus "the POST request isn't hitting the API that writes to the database" are the same problem, but only one of them gets you unstuck, and the difference is purely lingo.
And it compounds with AI specifically, because the model assumes you speak the language. It'll happily say "just add a migration" or "check your endpoint" and move on, and a beginner nods and quietly has no idea which of those five words is the thing they need to look at. The vocabulary gap turns the AI from a tutor into someone giving directions in a city where you can't read the street signs. So "understand the lingo" is genuinely one of the highest-leverage early moves — not because the words are magic, but because each term is a handle on a concept you can now point at, ask about, and reason with.
Which is exactly why the "make the AI explain itself" habit matters so much for this crowd: every time you ask "what does 'API' mean here, in plain terms?" you're not just solving today's bug, you're acquiring a word you'll reuse forever. You're absolutely right that you can come a long way on vocabulary alone — the lingo isn't the destination, but it's the map legend, and nobody navigates without one. Might add a "learn the words for your pieces" note to the guide with credit — thanks for naming it.
building one piece at a time is underrated.
with ai, it’s tempting to generate the whole app, but small slices are much easier to test and reason about.
I feel the same way, but people always expect a whole system from a single prompt. 🥲
This hits home. I built a 108-tool site with zero formal architecture background and learned most of my "best practices" the hard way, after breaking things first. Would love to see your take on when it's actually worth refactoring vs just shipping.
Building a 108-tool site with zero formal background and learning best practices by breaking things first is the curriculum — honestly a more real education than most courses, because every lesson came attached to a consequence you actually felt. That's the part a tutorial can't give you: the scar tissue that makes "one source of truth" stop being advice and start being a reflex.
Your refactor-vs-ship question is a great one, and I think the honest short answer is: ship until the mess starts costing you more than the fix would. A few signals I'd use to tell the difference —
Ship (don't refactor yet) when: the ugly code works, it's isolated (the mess is contained in one corner, not spreading), and you're not touching it often. Ugliness you never look at isn't debt, it's just ugliness — leave it alone. Premature refactoring is its own trap.
Refactor when the mess starts taxing you: you're afraid to change a thing because you don't know what it'll break, the same bug keeps coming back in new costumes, or every new feature takes longer than the last because you're fighting the structure to add anything. That's the moment the mess flipped from "cosmetic" to "compounding" — it's now slowing down future work, and future work is where the real cost lives.
The rule of thumb I keep coming back to: refactor the thing you're about to build on top of, not the thing you're just looking at. If a messy module is stable and untouched, leave it. If you're about to add three features to it, clean it first — you'll earn the time back immediately. Refactoring pays off exactly where you're going to keep working, and nowhere else.
That "when to refactor" question is genuinely worth its own post — you may have just picked my next one. Thanks for this.
This is genuinely one of the clearest explanations of refactor timing I've read — "refactor the thing you're about to build on top of, not the thing you're just looking at" is going straight into my mental checklist. The cosmetic-vs-compounding distinction especially clicked for me.
Looking forward to that follow-up post if you write it 🙌
Thank you — that genuinely means a lot, and honestly the framing got sharper because you asked the question the right way, so it's half yours. Glad the cosmetic-vs-compounding line clicked; that's the one that took me the longest to learn, mostly by refactoring beautiful code nobody was ever going to touch again while the actual bottleneck sat there rotting. 😅 The follow-up is happening — you basically named it into existence — and I'll make sure you get a shout-out in it, since this thread is where it started. Appreciate you engaging this thoughtfully. 🙌
One thing that actually helps, is to ask the LLM to generate an exhaustive plan first. Then you read it, all of it, and criticise it. Once you agree with everything (sometimes 50+ pages in a PDF document), you tell it simply "Go!" Which paradoxically implies "waterfall is back", since by the very definition of the term, that's waterfall ...
This is also a highly effective method for utilizing LLMs.
Thank for sharing.
The section on boundaries is the real antidote here.
When people start coding with LLMs, they usually prompt at the file or function level and let the model invent globals, direct cross-module imports, or implicit state wherever it feels convenient. After a few features, the dependency graph looks like a ball of yarn.
The rule of thumb that saved us was enforcing strict interface contracts before asking for implementation: define the exact input/output types and storage schemas first in plain markdown or TypeScript types, make the model write tests against those boundaries, and forbid the agent from touching anything outside the specific module it is working on. If the model can only talk through explicit boundaries, it literally cannot spaghetti your codebase.
A solid approach to keep things well structured.
A good survival habit is to draw the boundaries before asking a tool to fill them in: inputs, outputs, state owner, and failure behavior. AI can accelerate implementation, but it cannot decide which component should be allowed to make a risky change.
Well said mate! that's the core thing to keep in mind.
If I have already built and just learned this today (thank you, I haven’t shipped anything because I worried it was too easy) when is each prompt appropriate? I am in various stages with several builds?
Okay so the thing is use #4 first ("here are the components, let's build one at a time"). Naming the pieces before you generate is highest-leverage at the very beginning. Then #1 and #2 (separate UI/logic/data, one job per file) on every new chunk of code, and #5 (explain it to me) whenever the AI hands you something you don't fully follow. Alos , #3 (single source of truth) — pull this out the moment you have data showing up in more than one place. If it feels to messy then you can follow #6 (simplest version, match existing patterns) plus a pass over the warning-signs list — that's your signal to pause features and tidy structure.
Does this apply to website building as well?
Yeah!
The part about using AI without fully understanding the architecture is especially relatable. AI can help move things forward quickly, but knowing why the code fits into the overall system still matters when the project starts getting more complex.
That the main point of the article.
Why Is the First Letter So Hard to Send?
Thanks for reading! I want to make sure I understand you before I respond — could you expand a little on what you mean by "the first letter"? I don't want to guess at your point and miss it. Happy to dig in once I get the angle you're coming from.
I agree with you; AI without a sufficient knowledge foundation can lead to many problems, as there is no control over where critical errors might occur.
Yeah that's the core issue of LLMs.
Reading this from the literal version of the problem. I'm building on a plot in Thailand and I've been using Claude to help me think through the brief before I sign anything with a designer. Same trap, different domain: I could generate twenty good ideas an hour and had no way to tell which ones could coexist. Orient the main room to the sea and half the other decisions get made for you, but you only see that once you've named the pieces and their constraints instead of collecting features.
The bit about not being able to explain what's wrong is the actual wall, more than the code itself.
The habit that seems to get people past it is writing down the change they want before opening the chat. Not a spec, just three or four lines about what should happen and what shouldn't change.
If you can't write those lines clearly, the model is mostly guessing too. And you find that out in two minutes instead of two days.
Once people get into vibe coding they will have to develop multiple skills to make it work. Coding is just different than what it used to be. It's not just understanding code, its also understanding prompts.
AI removed the barrier to writing code. It did not remove the barrier to structuring it.
--- Not only this, sometimes it adds what it knows in addition (or without addition) of what we are asking and that complicates things way more.
The approaches suggested in this write up for sure gives a break from that insantiy and we do apply some of these in our daily AI assisted dev jobs.
I’m working on an ambitious project called ADAM-PS5, with the ultimate goal of developing a PlayStation 5 emulator for PC capable of running PS5 games.
The project is still in the early stages of development, and I do not consider it a complete emulator at this point. I’m building the foundation step by step: system architecture, low-level emulation, memory and resource management, graphics, input handling, execution, debugging, and development tools.
🚧 Early Development
There is still a huge amount of work ahead before reaching the point where commercial PS5 games can actually run. That’s why I’m sharing the project from its early stages rather than presenting it as a finished product.
🤖 One of the project’s goals is also to integrate Artificial Intelligence to help analyze errors, monitor performance, understand system logs, and assist with the development process.
The long-term goal is:
PC → ADAM-PS5 → PS5 Software Environment → Games
Reaching that stage requires implementing and accurately simulating many different components of the console’s hardware and software architecture.
I’m sharing the project now because I want to document the entire development journey from the beginning — including what gets built, what fails, what gets improved, and how the project evolves with each release.
🔥 ADAM-PS5 is not finished.
It is being built.
And the ultimate goal is simple:
Run PlayStation 5 games on PC through our own emulator.
ADAM-PS5 is an independent development project and is not affiliated with Sony Interactive Entertainment.
This really resonated with me.
I work in the AECO industry, and I’ve always considered myself more of a “hack” than a developer. I understand enough code to solve problems in the environments I work in, but most of that knowledge has grown out of necessity rather than formal software-development training.
Over the years, that has meant things like AutoLISP from decades of working with and customizing AutoCAD, a very limited amount of Python from Dynamo and troubleshooting Revit workflows, and enough HTML, PHP, and CSS from my design background and from building or maintaining websites over the years.
So when you describe building with AI without fully understanding software architecture, there’s a lot here that feels familiar.
The interesting part for me is that I’m now maintaining a project called EpochLex that I recently decided to open source, and contributors are beginning to show up. That changes the stakes considerably. It’s one thing for me to build something with AI that works for me; it’s another thing to invite other people into a codebase and expect them to understand it, contribute to it, and trust the decisions behind it.
This article gave me a useful framework for going back through EpochLex and asking some harder questions about its architecture, not just “Does this work?” but “Do I actually understand why it is structured this way, what depends on what, and whether another developer could reasonably work within it?”
That distinction between using AI to produce code and using AI while still taking responsibility for the architecture is probably the biggest takeaway for me.
Really useful article. I’ll be referring back to this one. Thanks for posting.
🎮 ADAM-PS5 — A PS5 Emulator in Development
I’m working on an ambitious project called ADAM-PS5, with the ultimate goal of developing a PlayStation 5 emulator for PC capable of running PS5 games.
The project is still in the early stages of development, and I do not consider it a complete emulator at this point. I’m building the foundation step by step: system architecture, low-level emulation, memory and resource management, graphics, input handling, execution, debugging, and development tools.
🚧 Early Development
There is still a huge amount of work ahead before reaching the point where commercial PS5 games can actually run. That’s why I’m sharing the project from its early stages rather than presenting it as a finished product.
🤖 One of the project’s goals is also to integrate Artificial Intelligence to help analyze errors, monitor performance, understand system logs, and assist with the development process.
The long-term goal is:
PC → ADAM-PS5 → PS5 Software Environment → Games
Reaching that stage requires implementing and accurately simulating many different components of the console’s hardware and software architecture.
I’m sharing the project now because I want to document the entire development journey from the beginning — including what gets built, what fails, what gets improved, and how the project evolves with each release.
🔥 ADAM-PS5 is not finished.
It is being built.
And the ultimate goal is simple:
Run PlayStation 5 games on PC through our own emulator.
ADAM-PS5 is an independent development project and is not affiliated with Sony Interactive Entertainment.
The one place I’d be careful is using the AI as both builder and teacher. If it made a structural mistake, it can often explain that mistake just as confidently. Understanding the explanation is useful; having an independent check is what makes it trustworthy.
Thanks for pointing that out! I'll update the post right away to include the proper disclosure disclaimer per the community guidelines. Appreciate the heads-up!