# Welcome > A working guide to building real software through structured AI collaboration — documented from one real project, open for others to test and extend. *** ## What You Will Find Here This handbook documents a methodology called **Neural Coding** — a way of building software where the practitioner's primary skill is not programming, but the ability to articulate intent, evaluate proposals, and make architectural decisions. It emerged from a concrete project: [Mnemosyne Neural OS](https://github.com/yaka0007/Mnemosyne-Neural-OS), a 290,000-line production desktop application built by a single person with no prior coding background. That is one case. This handbook is the attempt to extract what can be generalized from it. > 📖 **Two GitBooks — One Ecosystem** > > * **This book** (methodology): [mnemosyne-os.gitbook.io/neural-coding-by-mnemosyne-os](https://mnemosyne-os.gitbook.io/neural-coding-by-mnemosyne-os/) > * **Mnemosyne OS Docs** (the system built with this methodology): [mnemosyne-os.gitbook.io/mnemosyne-os-docs](https://mnemosyne-os.gitbook.io/mnemosyne-os-docs/) Some of what follows has been tested repeatedly. Some of it is still being refined. The honest position is that Neural Coding is a documented practice — not an established field with decades of peer review. *** ## A Concrete Starting Point Before anything else, here is the difference in practice. The same goal, described two ways: **Approach A:** > "Build a search engine for my notes." **Approach B:** > "Build a semantic search that works offline via a local model if available, then falls back through four cloud providers in a defined order. If the index was built with a different embedding model than the current query, detect the mismatch and use text scoring instead of returning wrong results. Never fail silently. Always expose which provider was used." Both approaches produce code. The second is more likely to hold up in production. The gap between them is not technical knowledge. It is the habit of thinking through failure paths, constraints, and edge cases before asking the AI to build anything. That habit — and how to develop it — is what this handbook is about. *** ## Who This Is For This handbook is most useful for people who: * Have a specific system they want to build and understand the domain deeply * Can reason across interacting parts of a system * Are willing to reject proposals that work technically but are architecturally wrong * Have patience to re-articulate a problem three or four times until the result is right It is less useful for people who: * Want to try AI coding without a specific goal in mind * Expect the AI to make architectural decisions autonomously * Are looking for a quick productivity boost on tasks they already know how to do If the second list sounds like you, traditional AI coding tools and tutorials are a better fit. This is not better — it is different. *** ## What This Does Not Solve Neural Coding has real limits. They are worth knowing before investing in the approach. **It does not eliminate technical debt.** AI-produced code makes the same tradeoffs as human-produced code. Patterns drift, consistency erodes, and decisions made in one session can contradict decisions made in another. Active management is required. **It does not scale indefinitely without domain mastery.** The quality of what gets built is bounded by how precisely the practitioner can describe what they need. Vague domain understanding produces vague systems, regardless of AI capability. **It is slower than vibe coding at the start.** The investment in constraint articulation and architectural review means early progress feels slower. Systems built this way tend to be more stable over time, but the upfront cost is real. **It has not been tested at team scale.** Everything documented here comes from solo Neural Coding. Multi-practitioner patterns, handoffs, and review workflows have not been validated in practice. **It requires ongoing vigilance.** An AI agent that produced excellent results last week will produce inconsistent results this week if context is not re-established. Session discipline is not optional. *** ## The Status of This Handbook This document is based on five and a half months of a single practitioner building a single project — starting from zero coding experience, first contact with AI development tools in mid-November. That makes it: a credible starting point, an honest documentation of one approach that worked, and an invitation for others to test, challenge, and extend it. It does not make it: peer-reviewed, universally applicable, or complete. The goal is to make the methodology explicit enough that others can evaluate it — and, ideally, apply it to their own problems and report back what worked and what didn't. *** ## How to Use This Handbook **Read Chapter 1** to understand what Neural Coding is and how it differs from related approaches. It is short. **Read the Three Pillars** (Chapters 2.1–2.3) in order. They build on each other. **Jump to Anti-Patterns** if you are already working and hitting problems. These are the most practical sections. **Bookmark the Glossary** as a reference. Terms are used consistently throughout, and the glossary defines them precisely. *** ## Contribute Your Case This handbook is built from a single documented case. That is its current limitation and its open invitation. The critique "one practitioner, one project" is fair. The methodology is documented precisely enough that others can apply it — and what's needed now is the second case, the third, the one that breaks the pattern or confirms it. **If you are building something significant with AI assistance:** * Do you make architectural decisions the AI cannot make alone? * Do you veto proposals regularly, and is your veto based on judgment rather than preference? * Has your AI collaboration produced something structurally coherent over months, not just days? If yes — document it. Even informally. Even just a short write-up of what worked and what didn't. **What's especially useful:** * Cases where Neural Coding *didn't* apply, and why * Contexts with a team (not solo) where the dynamics changed * Projects outside software — design, research, writing * Anti-patterns you discovered that aren't in Chapter 3 **To share a case or start a conversation:** → Open an issue on [github.com/yaka0007/Mnemosyne-Neural-OS](https://github.com/yaka0007/Mnemosyne-Neural-OS)\ → Or write directly to The methodology will be as strong as the cases that test it. One is just the beginning. *** *Published under* [*CC BY 4.0*](https://creativecommons.org/licenses/by/4.0/)*. Share freely with attribution.* *→ Read the system built with this methodology:* [*Mnemosyne OS Documentation*](https://mnemosyne-os.gitbook.io/mnemosyne-os-docs/) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://mnemosyne-os.gitbook.io/neural-coding-by-mnemosyne-os/introduction/readme.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.