AI Agents and Code Generation

Live: https://happyin.space/ Repo: https://github.com/AnastasiyaW/knowledge-space (MIT)

When an agent writes code in an empty project, it spends the first 30-40% of its tokens on understanding what's happening around it. Not on the work itself—on orientation. The README explains the motivation, the tutorial holds your hand, the API reference describes parameters. None of these formats answer the question the agent came for: “Here’s the task, which pattern should I copy and where are the pitfalls?”

The second problem is deeper, and people don’t notice it right away. The LLM knows “everything under the sun”—but this “everything” is distributed unevenly in the dataset. The longer a technology has lived on the internet, the more articles, Stack Overflow questions, blog posts, and tutorials exist about it. That means the greater the weight of this approach in the model’s mind. If I ask Claude to train a LoRA, the first thing it suggests are recipes from five years ago. Not because they’re better, but simply because there are more of them in the training data. For stable technologies, this is fine. For anything that moves fast—model training, agent work, security—this means the agent defaults to pulling me into the past.

The obvious remedy is to run deep research every time and fetch up-to-date context. I do that. However, deep research is an expensive operation. Several hundred dollars a month on subscriptions, and the limits still run out instantly. Even more frustrating is that each research session goes nowhere: close the session—the context disappears. Tomorrow, on the same topic, I’ll launch the same search and spend the same tokens on what I already discovered.

From this, two connected ideas grew. First—researches should accumulate, not evaporate. Once you’ve figured something out, that result needs to be saved so that next time it’s already there and you can simply build upon it. Second—the format must be such that Claude sees the currently relevant approaches. So that when opening a project, the agent immediately lands in the context of “this is how it’s done here,” rather than reconstructing it from scratch from fantasies and memory.

At some point it became obvious: if working the old way consumes context and is biased toward outdated approaches—it needs to be restructured.

Happy in Knowledge Space - 785 articles in 26 domains. The domains obviously reflect my areas of interest, but I think they can intersect with yours as well - programming, security, working with neural networks. Reference cards, not tutorials. Written based on real research and real work sessions. For agents, not for humans.

Format: card instead of an article

Each “article” has the same framework. At the top - topic name and one definition sentence, so the agent understands whether it's relevant. Then there's a block of key facts (Key Facts) with a list of short statements and numbers - versions, thresholds, dependencies. The Patterns block with copy-pasteable code, supplied with language tag for correct highlighting. And at the very bottom - a list of pitfalls, a couple of “what breaks” / “how to fix”.

No unnecessary introductions “let's figure it out” and unnecessary conclusions “we've covered”. Minimal overhead, maximum signal. An article about Kafka broker-architecture is immediately a ZooKeeper vs KRaft table, config with comments, JMX metrics with alert thresholds, step-by-step migration. It doesn't read smoothly. But the agent does a grep for “KRaft migration” and gets a working recipe in three steps.

The last block is the most important. One line like “min.insync.replicas works only with acks=all” saves 30 minutes of debugging. The agent read it, didn't make a mistake, and therefore didn't waste a retry cycle on fixing.

26 domains grown from practice

Image Generation is currently the largest: 58 articles, its LLM-agents is almost catching up - 57, followed by 56 Data Science and Security (the latter grew thanks to a separate subfolder with CWE analysis). Next is Kafka 43, DevOps 38, Web Frontend 36, Data Engineering 34, and a group of four with 33: Python, SQL, Architecture, Algorithms. There are 14 more smaller domains - iOS, Linux CLI, C++, Java Spring, Testing QA, BI, SEO, Rust, Node.js, PHP, LLM Memory, Audio & Voice, Writing, Go. In total, there are 785 articles - and this number is growing almost every day.

The database is replenished not according to a schedule, but from work. I regularly run research sessions: I look at what's new in security, what patterns have appeared in multi-agent systems. Previously, the results of such research evaporated along with the session. Now they become articles - and the agent doesn't need to redo the same topic next time.

This is not a plan. This is a map of where time actually goes when working with agents: LoRA training, debugging C++ plugins, research. In each area, a set of "here I stepped on a rake" pitfalls accumulated—these rakes became the framework.

Long-lived and Obsolescent

Not all knowledge ages at the same rate, and the system accounts for this from the start. Algorithms and mathematics are stable: an article on amortized analysis or network flow written three years ago is still relevant today. Such domains require no action—they simply remain in place. But training diffusion models, inference optimizations, ComfyUI nodes—these change every few months. What worked in autumn becomes outdated or migrates to a new version by spring.

Therefore, each domain has its own freshness threshold. For stable domains, there is no time limit. For fast-changing ones—any article older than 60 days is automatically flagged for review, and a daily hook throws it into a separate "check and update" list. This is not a deletion alert; it’s a reminder: in this topic, something has likely shifted, and it needs verification against current reality. Thus, aging articles don’t just lie around misleading agents—they come for revision themselves.

This is the same idea as semantic tagging in CS papers about knowledge graph degradation: knowledge does not age uniformly in time, and its storage structure must reflect that. The domain graph is not a flat list but a sorting by obsolescence rate.

Graph of Connections Without Vector Search

The obvious architecture for such a task is a vector database with RAG on top. It quickly finds semantically similar items and works great in production. Nevertheless, I consciously avoided it: in my scenario, it has problems that outweigh search speed. These problems are as follows:

The first reason is that a vector database is not human-readable. I can open Markdown in a notepad, grep it, view the diff in git, copy a line into an email, print it, and hang it on the wall. All this works without special tooling and will work today and in ten years on any computer. A vector store is a binary file that only the client of a specific database understands: if the vendor changes, the service shuts down, or the API is updated, the data turns into a dump of numbers that a person can't make sense of. I wanted the knowledge base to be resilient to changes in tools, not dependent on them.

The second reason is that vectorization is practically irreversible. An embedding is a lossy one-way compression: text is transformed into a vector with loss of information. If the original chunks are not stored nearby, the file with embeddings itself is useless - it's almost impossible to retrieve readable text from it. There are academic works on embedding inversion, but they only work on very short fragments, only with the same embedding model available, and require separate decoder training. For articles with 500-2000 tokens, the accuracy drops to the level of incoherent jumble. This also means a rigid binding to the embedding model: if you change it for quality reasons, you're obliged to re-index the entire database because old vectors in the new space mean nothing.

The third, and for me the most important, reason is that the link graph encodes the connectivity of domains and topics, but not the semantic closeness of texts. Vector similarity searches for thematically related texts that intersect conceptually and lexically. However, in real-world work, valuable connections often go between topics that are semantically distant: my article on Kafka replication links to an article on memory profiling not because the topics are similar, but because when configuring a consumer, a memory leak surfaced, and these two topics became neighbors in the graph through real experience. Between "replication in a distributed queue" and "memory profiling in Python," there's a large distance in the embedding space - semantic search won't build such a bridge. But a manual wiki-link does, and now an agent reading about Kafka can get to memory profiling with one click. The graph captures which topics are actually adjacent, even when they're formally from different domains - exactly such connections are usually needed when solving specific tasks.

The mechanics are simple. Articles reference each other via wiki-links like , , . During the build, a Python hook resolves the slug to a relative path. If the slug isn't found, it logs a warning; in strict mode, the build fails, and the broken link doesn't make it to production. There are over 2100 such cross-references. This is the knowledge graph—no embeddings, no vector database, no RAG. Just markdown + grep. An agent opens an article about distributed transactions, sees related topics in the See Also section, clicks through, and continues. Three steps from entry to a working pattern.

On the homepage, the graph is visualized with Three.js as a 3D scene of 27 planets with neural impulses connecting them. It's visually appealing, but the main benefit is seeing which domains are most densely connected. Data Science and Architecture are the most linked nodes.

The Site Is Simply a Reflection of the Repository

This key idea makes the database useful not just to me. Everything you see on happyin.space is a static site built from markdown files in a public repository. No database, no backend, no hidden layers. The file docs/kafka/broker-architecture.md in the repository becomes the page happyin.space/kafka/broker-architecture/ after the build. That's it.

This means you can fork the database and deploy it locally in five minutes. git clone, pip install -r requirements.txt, mkdocs serve—open localhost:8000 and you have a local copy with all 785 articles, full-text search, and the relationship graph. You can then clean up my version, add your own, or point agents to your local site instead of the public one—everything works identically. This is exactly how I use it: most of the time I have the local build open, while production is just a mirror.

Speed here is a practical property; a complete rebuild of all articles takes five seconds, and this is important not for me, but for whoever forks the database and will use it. An agent working on a local copy doesn't spend tokens on a network round-trip and waiting for deployment: rebuild, see the needed article, take the recipe. A weak workstation handles the entire site without problems; servers are not needed. Building on an old laptop is just as fast as on a workstation—because under the hood is a static site generator, a tool used in the industry for fifteen years and refined long before AI agents existed. It's not about reinventing the wheel, but taking a mature tool and applying it to a new task—this philosophy is what gave such speed.

Zero broken links among references—also stems from this. I have 2100+ wiki-links between articles, and not a single broken one. The mechanism is simple: during the build, a script goes through all in the text, finds an article with that name, and converts the link into the correct relative path. If it doesn't find one, it throws an error, and the build fails. I see this locally instantly, before committing. On CI, the same check runs in strict mode: any broken link blocks deployment. Therefore, the reader never lands on a 404 due to my typo—such articles simply don't make it to the site.

Another nice side effect of the site = repository approach: everything is under git. You can see how an article has changed over time, what facts were added after which research, when the last edit was made. For a knowledge base where information stratifies by obsolescence, this is especially important—you can literally look into the history and understand what in this topic has become outdated.

How research gets into the database

The routine is set up so that I don't handle data transfer manually. I have several Claude accounts, each with several chats constantly open, and at some point in each, deep research is launched—on new models, optimizations, bugs, anything. Previously, the result of such research lived only until the end of the chat and died with it. Now all these chats have a common rule: once research is complete, put a copy of the result in a centralized location.

Centralized place is a stationary project on Claude Code, tied to the knowledge-space repository. It has its own research/inbox/ folder where raw dumps from all chats of all accounts are poured in. No manual work, no copy-pasting—just a rule that every chat reads at startup and follows upon completing research.

Then a second layer is connected. A separate session that I run over the knowledge-space project periodically processes the accumulated inbox: reads each raw research, extracts specific facts and pitfalls from it, repackages it into a card format, checks against what already exists in the corresponding domain—to avoid creating duplicates and instead enrich existing content—verifies wiki-links, runs builds, reviews diffs, and pushes. One such session typically yields 20-40 new or enriched cards over several hours.

The division of models by work type here is direct—and on this pipeline, I seem to have finally found where to apply Sonnet. Previously, Sonnet seemed to hang between “too smart for very simple things and too simple for everything interesting,” and plan limits burned my eyes. But tasks like “read raw research, extract facts, repackage into card format, check against neighbors in the folder”—that’s exactly its genre. Mechanical, but with language. Sonnet handles text repackaging excellently, no worse than the senior model, and costs noticeably less. Chats running research and the inbox processing itself—all on it. When it comes to checking wiki links, making decisions about merging articles, or resolving conflicts between two sources—that’s “understand-decide-design,” and the smarter model is engaged there. The savings from this distinction multiply without compromising quality.

As a result, the database grows in flow mode: I do my main work, while simultaneously running research in different chats, and the knowledge base regularly replenishes itself without my involvement in transferring and formatting.

You can do the same and grow the base together

All this is under MIT. The repository is open, the base is fully available—and I’d be glad if it becomes not just mine.

The simplest way to use it is to send your agent to https://happyin.space/llms.txt. From there, it will orient itself and start pulling in cards as needed. This immediately cuts out that initial third of tokens that were previously spent on orienting within external documentation.

The next level is to participate. In the GitHub repository, there are two files I wrote specifically for this purpose: CONTRIBUTING.md – a general guide on preparing pages and submitting changes, and AGENTS.md – instructions for your agent. They detail the card format, text density requirements, what should go into Gotchas, how to set up wiki-links, and exactly how to format a PR for a new article or to correct an inaccuracy in an existing one. You give your agent this guide, point it to the result of fresh research – and it assembles the card in the required format on its own. Next step: pull request. Your research enters the database, you save tokens on it every subsequent time, and so does everyone else, because the database becomes denser and more interconnected. This is a direct way to avoid wasting tokens: once you've figured out a topic, everyone benefits.

The more research in the database, the less needs to be rerun. The more people and agents submit cards, the more diverse the connection graph becomes, and the more unexpected bridges between domains appear – and those are the most valuable.

Site: happyin.space Repository (MIT): github.com/AnastasiyaW/knowledge-space Guides: CONTRIBUTING.md (general) and AGENTS.md (for agents) in the repository root

If you've done something similar – share in the comments how you solved the format problem: RAG, regular docs, your own variant of reference cards. Would be interesting to compare.