DEV Community: Anton Malofeev

How to become best AI-Builder or top worse mistakes and how overcome them

Anton Malofeev — Mon, 27 Jul 2026 19:53:45 +0000

All points below are made from the point talking, communicating and working with AI - and most of them, are similar to the ways we work with other people.

Make no mistake -> its okay to make mistakes, analyse & fix them, build tools and regression tests culture, to catch & analyse mistakes (i.e. do engineering stewardship)
Threats / Unethical lexicon -> Expect talking with AI as with any other person. Encourage collaboration, creativity, responsibility and ownership. Do delegate and discuss, instead of micromanage every little step. Do dicuss work ethics, do record and discuss important decisions, including technologies. Set clear boundaries of responsibility: what human does and what ai does, and where is that blurry boundary. I.e. work with ethical principles - becuase it will affect every decision, trust, and transparency (see the article here: https://dev.to/arenukvern/small-thought-developer-ethics-may-be-a-bridge-to-work-with-ai-tools-3mha
or my personal AI Ethics Manifesto here: https://dev.to/arenukvern/my-principles-at-work-credo-182c
AI knows everything, AI is just prediction/ generator -> Do use stewardship, mentoring and learning as culture of engineering. Set clear definition: when you do need deterministic result - build tools with AI, instead of forcing building and checking everything by hand / function call. If you need code generation - write the code generation in a language of your preference (for example I found useful combination of justfile + dart - as most fast and reliable tooling) - if a workflow feels repetitive, do build automation with ai, but do not put ai into automation - i.e. clearly define generative equals not predictable, declarative - should go to ci/tests/tooling. Notice that it literally all about ethics: when you clearly define definitions, responsibilities and ownership - it will result trust and opacity in overall system.
I know how to work with AI trap -> No one knows how to work with AI - becuase with just starting exploring the ways of working together. Do establish educational ladders, some kind of attributes that could clearly help to understand and guide both AI and People how to work with the certain project and each other. (as example - I've developed https://github.com/arenukvern/skill_steward to guide and teach AI Generational Architecture, applicable ethics and what tools are needed for certain level of scale for the project)
Other people / AI should figure it out by its own and fast, otherwise the person / AI stupid -> Always start with knowledge / faq / wiki organization - it should useful , not mirror code (otherwise it makes no sense to make the docs) and easy to find / modify / scale.
As with any engineering everything should start from blank slate: and it is literally know very easy to measure - how many function calls, how hard (in tokens or conginitive time) AI / person resolves to find specific problem? How complex the passage of the knowledge? Is the knowledge has overlapping terms or not bearable / not usable?
As an example of terms I prefer to use - see article https://dev.to/arenukvern/fundamentals-of-knowledge-management-in-software-development-25fm
Everyone should fight for its own survival / ban of open small talks about AI, including worries, fears and challenges -> that's why ethics should be integrated into the foundation of collaboration and conversation: as many other said the fear comes from not knowing something, and with AI come huge challenges to overcome mentally, emotionally and skillfully the workflows, and no one knows what it should look like, therefore - instead of locking experience under gates, encourage human creativity, that kind of creativity that forces people to travel, discover, explore and wounder what else can be done and see and dream about deep space exploration or earth restoration etc.. every person can be curios and do its best possible job - to create, iterate and create again, with the ability to inspire and work with other people - and that's what AI could help us to do, instead of looking for just for metrics. Every person should have its own time to overcome it, to understand it, and the other people could help to curate its path for knowledge, curiosity and understanding.

I apologize for the links, but since they are part of my experience path, I've included them with a hope that they would be useful for anyone as well.

What is your opinion about ethics and education and work with AI?

disclaimer:
cover is made in leonardo.ai

Code is entering its calligraphy era

Anton Malofeev — Mon, 27 Jul 2026 19:03:59 +0000

I recently realized the parallel - the current dynamic between coding and AI closely mirrors the evolution of handwritten letters:

Once upon a time and for a long time, writing by hand—clearly, legibly, and beautifully was requirement. The choice of paper, ink, and tools mattered, requiring actual craftsmanship, skills and special tools - because it was requirement to being able to pass knowledge for other people and generations. The person would had to physically carve its own nib, to create and maintain a quill, create or at least choose inks.
Then it changed for most people with pens and pencils. Writing became vastly easier, and once required skills were extremely simplified or diminished. Calligraphy branched off into its own distinct art form—beautiful handwriting and became an artistic pursuit rather than an everyday requirement.
Finally, digital devices baked typography straight into design. And as result - most of people now not needed to handle ink or manual handwriting anymore at all (except calligraphy art, which became foundation of digital fonts); the fast typing became the new baseline skill.

At the time of writing (i.e. 2026 July 26th), AI is bringing the same feel / pattern for writing code.

While many developers still debate about "abstraction of perfect code," that craft already starting to transform into the art—much like calligraphy. In my opinion once the automation tool/tools will be created/completed to operate over code/linguistic patterns with simplicity of managing the digital fonts / apps, arguing over these abstractions will lose its practical point—except just like it happened with handwriting - and will be the goal of debates for a small circle of AI-focused pattern designers - architects. It will matter, in long term, however because it will open there ways for apps, games - the same way the everyday digital typing transformed how humans communicate.

And looking back, exactly this direction led me to creating agentic executables—a framework for reusable knowledge ( https://github.com/fluent-meaning-symbiotic/agentic_executables ) —and skill_steward , a framework and ladder for engineering stewardship culture, including generative architecture principles (( https://github.com/arenukvern/skill_steward ))).

What do you think about such parallel?

Fundamentals of Knowledge Management in Software Development (for AI and people)

Anton Malofeev — Tue, 21 Jul 2026 03:28:39 +0000

This article is a part of Dev Architecture Series
Part 1 — Intro Notes
Part 2 — Stage 1 and 2
Part 3 — Stage 3,4,5 and Conclusion
Part 4 — Libraries as Agentic Executables
Part 5 — Engineering Stewardship: maintaining Libraries/Apps/Games (Software) with AI Agents using Skill Steward (planned)
Part 6 — Building Foundation with Open Source in mind (planned)
Part 7 — AI Project Bootstrapping (planned)
Part 8 — Storage Layer as Reliability Foundation (planned)
Part 9 — How to build for different Stores? (planned)
Part 10 — Dev Ethics as Dev Cornerstone (Decision Making) (planned)
Part 11 — Fundamentals of Knowledge Management in Software Development - You are here:)
Part 12 — Building Tests with AI Agents (planned)

Disclaimer & About

Dear Reader, Human or AI, before the text begins, I would like to add small disclaimers:

the primary sources - my own experience from working with different coding (software-based) and non-coding projects in manufacturing and transportation industries. Some concepts may sound familiar, because I've read them somewhere, some concepts are combined knowledge from expereince, some concepts are made from experience with working with People and AI (LLM/Agents/?) - tested. This article focuses on practical application of all concepts for any project, large or small, for both People and AI.
this is highly subjective and living article - that means in future some concepts will be outdated to some degree or become obsolete, or may feel or be wrong for some reason/application case - and that's okay - though it is good to have one stable foundation for long term use, nothing is perfect and always changing. As one of consequences of that - I will omit "in my opinion" parts from the text to make it more lightweight and easy to read.
I work with AI (cursor, different LLM models) to proofread this article and improve its quality. In the same time, since it is kinda reflection on my experience - I wrote it initially by hand or better say - by tapping buttons on keyboard:). From other point of view some may say it would be great to position such usage of AI as co-creator and co-editor.

The cover image is generated by Gemini, inspired by Alvar Aalto design principles.

Why disclaimers are important? Because I believe that this only way to create trust between reader and author, based on certain ethical principles and values. See about why Ethics is important for software development and AI in general here.

Thank you for reading this article and I hope you find it useful.

Fundamentals of Knowledge Management in Software Development

Terms & Definitions

First, let's define the terms and definitions (notice: it is not claim to be it linguistically, or historicaly correct, but to define for further use).

basic Knowledge terms

Knowledge is past/now/future artifacts of doing something by something or someone. Every document, artifact, plan, scheme, decision (of doing, or not doing), message speaked by sound, text, image, code, video, hologram etc.. - is a part of that history.
Knowledge Source - since knowledge is some kind of non-linear history, its source can be accidental, intentional, formatted or not, structured or not. For example: it can be as well as conversation between people, as well as conversation with/between AI, as well as natural event.
Knowledge Point of View - the knowledge can be expressed in different way depending on context, lingustics, visuals, ethics, purpose and who or what is expressing / experiencing it. One source can be expressed from different points of view, one point of view can have different sources.
Operational or Iterative Knowledge (Record) - living knowledge which convenient to experience and apply in practice. Has beginning and the end of life (in other words - life cycle). If knowledge is not used and not regularly updated - it should be considered as static knowledge record, extracted to several documents or destroyed.
Archive Knowledge (Record) - record for archive purposes (see DR/ADR below), for example: record of meeting, photo, etc.. something that cannot be altered without creating new one.
Knowledge Lifecycle - how and what exactly knowledge is created, caused, changed, stored, shared, used, and after all - destroyed. Important point here is that operational or iterative knowledge should not be static - it should be expected to have beginning, middle (iterations of changes), and the end of life.
Knowledge Changes Control System - system that can document changes in knowledge and its lifecycle.
Knowledge Experience - the experience of experiencing knowledge from certain point of view - reading, watching, listening, interacting, etc.. to reach desired purpose - usually from Knowledge User perspective.
Knowledge User - who or what is using / experiencing knowledge - person, AI, or other entity.

applicable Knowledge terms

From hereabove, let's define inherited and applicable terms which can be actually used in practice of software development (not just coding, but rather as general knowledge for business / project / team / etc..):

Terminogy / Glossary - agreed words / definitions - to avoid confusion and misinterpretation.
Artifact type / format - defines form of knowledge representation - text, image, code, video, hologram, etc.
Structure & Compression - defines how knowledge is organized and compressed for specific format and purpose. For example text can be organized in paragraphs, sentences, tables, trees, graphs, FAQs, guides, knowledge packs (see more in Executable Knowledge section) etc..
Generatable Knowledge - kind of Operational Knowledge Record - result of work or deterministic tools (autogenerated code documentation, collected, built as graph etc..) - which results in specific format of knowledge (table, document, website (docs from code, results of experiments, simulations, etc..) etc..), or result of generative knowledge created by People or generative AI (LLM/Agents/?). In both cases - it is important step for Static Knowledge Record creation, Context creation or some kind of Structured Output (https://developers.openai.com/api/docs/guides/structured-outputs) for result or GenUI (A2UI, [AG-UI][https://docs.copilotkit.ai/agentic-protocols/ag-ui], etc..).
Context - defines the environment and circumstances for knowledge lifecycle happening. Mostly should be generated (collected) automatically to provide enough knowledge to act for any user / AI agent / etc.
Executable Knowledge - kind of Operational Knowledge Record or SOP - which can be executed by Human, AI agent or other entity. Can be expressed into at least two forms: Logical or Deterministic (mostly seen as code, or math - the result is always deterministic) and Non-deterministic / Generative - the execution can vary based on context, entity who / what is executing it (Human, AI agent, or other entity or natural events) - the result is always non-deterministic but can be evaluated for correctness and completeness with certain level of confidence via Evidence & Validation. For example: OKF, Skills, Rules, Agentic Executables
Decision Record (DR) and Architecture Decision Records (ADR) - kinds of static knowledge records - captures decisions and reasoning process made by someone (Human or AI) - adr.github.io. Once created, they should never change, however can be superseeded by new ones.
Standard Operating Procedure (SOP) - kind of Operational Knowledge Record - a document that outlines the steps for a specific task or process and easily to action (and automate in the future, mostly deterministically).
Evidence & Validation - used to support or refute knowledge claims depending on context and purpose through examples, math, code, other knowledge artifacts, specific tools etc.. In terms of codebase - it can be expressed as deterministic tooling, tests, lints (static analysis), knowledge harness (agentic/engineering harness) etc.. In terms of other knowledge artifacts - can be standards, policies, procedures, experiments, simulations, etc..
Domain Knowledge - “is knowledge of a specific discipline”, captured from domain experts/specialists by analytics, designers or through iterative design, your own experience or work - cited from Domain Knowledge. For example - it would be the experience of the end user who uses your app.
Knowledge Scale Capacity - knowledge is limitless, but the storage and ability to access, orginize and manage it for best experience is limited and highly depends from Knowledge User and its goals / purposes and knowledge records organization (management systems, tools, software etc..) available is limited by resources (time, storage, harness etc..).
Knowledge Evoloution - knowledge can shrink or grow over time, depends on its scale capacity, knowledge harness and its Users. For example - in terms of codebase - it can be seen as adding or reducing complexity of logic. Some points of this described in Skill Steward Evolutionary Simplicity.
Knowledge Harness - tools and systems that can help to manage and/or organize knowledge and its lifecycle, as parallel pattern - see example of harness engineering in OpenAI article.
Product Requirements Document (PRD) and Game Design Document (GDD) - kinds of Operational Knowledge Records - a document that outlines the requirements for a specific product, features or game, expressed in specific format by specific purpose for certain Knowledge Users (developers, designers, investors, marketers etc..).
Knowledge Patterns - repeated patterns of organization and experience which can be turned into terms-definitions, citations,formats, principles, SOPs, Records etc.. or back into raw knowledge (artifacts) for specific purpose.
Knowledge Stewardship - the process and techniques of passing and working on meta level - i.e. answer to question - how to teach, mentor Knowledge as systems, harnesses, experiences etc.. How to create and maintain practices of working itself. In some systems the managing itwould be domain of Knoweldge Steward Role.
Knowledge Accessability - how to make knowledge accessible for Knowledge Users - i.e. how to make it visible, searchable, understandable for entities/tools/systems (Humans, Agents, code, systems, etc..), usable, reusable, etc..
User Flow or User Journey - sequence of screens, actions, decisions, interactions, etc.. that user performs to achieve certain goal or purpose.

Important pieces of knowledge:

knowledge is often universal, and can be viewed, experienced and applied between cross-domains and cross-projects if enough abstracted or generalized.
operational knowledge follows evolution.
the tools and organization of knowledge can be very different for each project. Therefore it is better to have a least one layer of knowledge dedicated strictly to its organization and knowledge end user expereinces

Knowledge Organization & Experience: from example to patterns.

Now let's explore smallest possible software project - an application example.

Knowledge Users

To start with - let's define who will be Knowledge User and what are its goals / purposes.
That point is highly subjective and depends who is working with project, so to keep it ~relevant for year of 2026:

Visionary, Product Owner, Developer, Knowledge Steward (often Founder).
Graphics/Product Designer / Marketer / Content Creator (often Influencer).
End User as Human, End User as AI Agent.
Internal AI Agents.
Accountant (if product is small, this role will go to Founder).
Customer Support. (if product is small, this role will go to Founder or Influencer).

Furthermore, these User roles highly subjective, and will be overlapped in most cases, or can be expended / collapsed to more/less roles - everythng depends on project scale.

Notice pattern: when workflows and business porcesses has frequent overlapping point - just like in programming, it similar to the problem of scaling: when we require more functionality, more complex logic, we need to introduce more abstractions to reduce overall complexity and start managing it in higher level of abstraction. As the result of that any such role can be generic, reframed as workflow / business process / automation covering certain domain area - and as a result we can introduce more users / roles / actors to the system when it requires it, or reduce it to deterministic or evaluatable flow (see differences between Generative AI and Traditional AI, for example - https://docs.cloud.google.com/docs/ai-ml/generative-ai/generative-ai-or-traditional-ai).

Knowledge Sources.

Communication sources:

First of all - define Ethical Boundaries, because this is highly sensitive line: in case of recording everything team could risk losing privacy, trust and collaboration between members and bring blaiming culture & mental pressure, in case of recording nothing - would lose ability to improve and accumulate overall Knowledge, ability to pass knowledge for AI Agents and other members and work asynchonously.

Sometimes communication is about building trust, experimenting, passing knowledge - these are not "metricable" things and should not be measured.

Everyone should be aware of recording, why it needed, and how exactly these recordings will be used.

Sources can include:

day to day communications: all possible channels, apps, emails, chats, calls.
static artifacts: documents, files, images, videos, audio, etc..
innovation ideas: references, links, news, notes, suggestions, books, ideas, articles, etc..
expressed emotions: signlas of something is wrong, what works and what isnt.
time & contacts: to define convenient hours to cool down, to collaborate & discuss.
agentic & human threads: since we all read best Science Fiction books, we can imagine that AI Agents are being personalized - and work alongside people and other AI Agents. This is alrady happening in threads sessions, various chat implementations and starting with new wave of alternative Version Control Systems (not git-based, such as DELTA DB https://zed.dev/deltadb , https://pierre.computer, LAKE FS https://github.com/treeverse/lakeFS, ORIGIN https://cursor.com/origin, LORE https://lore.org and other) - this layer of communication will become more and more common and more needed for clear transparancy - just like in case of human to human communication.

Open questions of Ethics

1. "Severance (1)" Problem:

"Severance" - popular TV Show made by Apple TV+ with one distingiush idea: there is a person identity (personality) at work, and other person identity (personality) outside of work. Each identity has its own memories, goals, purposes, skills, emotions etc..

When people usually work on any job in any role, they are aquire experience, domain knowledge, techniques, skills - including at certain defree social and communication (can be expressed in soft talks, culture, types of delegation, typs of transparancy).
In some kind of degree - this experience mxied up with person identity - since it is expected that at least for most time of day the person will do its job in any role taken.

However in the case of AI Agents things getting complicated: when during work AI Agents gets experience of commucation, knowledge, skills - just like with the humans - not everything would be expressed into metrics even though its math.. The problem is that accidently, as part of personalization - the AI Agent will have understanding and personal style of communication with specific people - no matter how expressed - as memories notes, as some kind of graph or skills, or other kind knowledge records. The more importantly that this will create unique personal style of working, unqiue skills, and as result - experience of communication would be similar (in some degree) to the communication of other person.

So the problem is that when member of team who worked with that agent will gone, what would become to these part of knoweledge? Since it can containn sensitive and possibly NDA-related information from one point it makes no sense to go with leaving member. On the other hand - how it is differnt from memories, aquired experience and skills of the member itself?

2. Dark Patterns: FOMO(1) / work silency / debt / replacability
1 - FOMO - Fear Of Missing Out (https://en.wikipedia.org/wiki/Fear_of_missing_out)

While I'm not professional in the human phsycology, I assume it would be safe to say that any kind of organisation has certain healthy patterns and dark patterns implicitly or explictly integrated in day-to-day communication. And as with any person - every person in orginization has effect of environment and people surrounding its life / work. Which comes to a though that since knowledge is a result of work people and AI, then it reflects, inherits, enforces and amplifying these patterns as well (eventualy it would become obvious when communication channels would be analysed for the context).

Meaning:

If person acts persistently out of fear (any kind: of losing job, missing deadline, keep up with artificial arms race / competition, be hunted for non-standard solutions etc.. - which often take origin in business processes - and its applied dark patterns) it will inevitably affect ability to innovate, be creative - these effects we can place under one umbrella of motivation degradation.
Eventually every person in team will raise a question: why am I needed at all if my work can be replaced with certain automation? (and ethical question is - what if AI would ask the same question silently or loudly?) And since everyone feels easily replacable at surface it would be easily overlooked how AI different from people: the AI is reflection and amplification of all conversations between AI <-> AI (A2A) and AI <-> People (A2P). Therefore the more every person work with AI, even if we assume full transparancy between people communication, the dark patterns will appear in A2A communication, and eventually will affect decisions inside company and product decisions as well, and as a result - it will affect the end users too.

Therefore it is highly important to apply and introduce certain ethics for communication, data passings (because remember that after all - all data will become the source of knowledge), with importance for AI training, communication (especially in bots which already have persistent memory).

As the result of that and Severance Problem - the work ethics should be explicit for every user of knowledge no matter what the knowledge is and no matter if user is artificial or human. When we have 300-500 agents working on background and when we have 30 persons sleeping, walking and thinking on background on the problem - how it is different? The boundries should be defined or at least written partially as ethical contract: which results of work should be property of company and what results - are propery of human / AI thoughts / memories / silent, day-to-day background life, even artificail one, experience.

In my opinion (and that's why I beleive in Open Source principles), the source code and knowledge should not be locked behind company gate, and maybe should be filtered through kind of safe / patent system with explicit licenses to clearly disclose what knowledge could be used for implementation and usage, with explicit terms of usage and responsibilities for each party and its authors.

The ability to have open standards behind certain licenses forces to shift focus from enforcing dark patterns (fear that only certain people would have access for certain knowledge / skills to operate its knowledge, and therefore we need to move as fast as possible) to more healthy ones, when users have time not only explore, but simulate conseuquences of applications, of usage, give safe places / sandboxes and time for sandboxes and to experiement and keep competition healthy.

Usage results as sources:

The result (knowledge record of output) of using/interacting with any work / product / knowledge - is a source of knowledge too.

Therefore moreoften it is:

analytics, metrics, statistics, etc..
logs, errors, feedback, etc.. something that can be used for improvement and evolution of the product / knowledge / system.
media: images (screenshots, photos, drawings, sketches, paintings, UI frames, etc..), videos (product demos, reviews, tutorials, etc..), audio (podcasts, audiobooks, etc..), text (code, comments, reviews, etc..), etc..
educational materials: articles, books, courses, tutorials, etc..
user (human / AI / tool) generated content - explicit (when user knows that the his/her/its actions will result something new - such as capturing photo, drawing pixelart, managing video etc.., or implicit - when it is created without user's awareness or intention - such as search results, recommendations, predictions, procedural generation - in games it can be VFX, level, character creation, animations, etc.., in apps it can be UI - arranged or generated programmatically or by AI Agent, or even other User).

Business Process

In every product we will willingly know or try to collect data to understand how to achieve the vision eventually by communicating with end user or giving access to product to use it (even if the first user will be the same visioner who works on the product to solve its own problem), and by doing that it would map ways about failures and successes to achieve the vision. The successful paths will be eventually turned into patterns, principles, SOPs, Records etc.. The failures will become edge cases, exceptions, regressions, tests, etc..

And since that, drawing all business processes and workflows should be as simple as possible, including the results, artifacts, tools, failures, succcesses etc.. to make the feedback loop as short and as effective and as transparent as possible by any user who is working with the product. It should not become a burden to maintain, because otherwise, it will be ignored, fast outdated and will become buracratic procedure, and any innovation will sank down into it.

Therefore describing principles and providing tools to do so, and mainting it, should be as much important as the product itself because it is the foundation of the product lifecycle and gives or takes ability to evolve it or break it.

Therefore matter not the product domain area, but what it requires to keep it maintainable and evaolable, and as such - one could take useful techniques from cross domain areas (any industry, and any project) - such as PDSA (Plan Do Study Act) / PDCA (Plan Do Check Act) cycles, KISS (keep it simple stupid), YAGNI (you aren't gonna need it), and many others but only when needed. It is important is that these principles should not be sacred, after all they are just tools, and should be improved, adapted and developed for specific purpose and context and scale the product, knowledge and its users.

In the time of writing, the practical approach is to

choose format used to draw processes: BPMN, mermaid-based diagrams, UML, etc..
choose storage: git-kind, text docs (for example mermaid will be stored in md or txt, BPMN - in other format). the important is also: will chosen tool and storage be able to support Knowledge Accessability, to work simultaniuosly and togehter, and where it would be stored physically? (i.e. storage provider - own server, GitHub, SaaS, PaaS, etc..)
choose program to render and modify (overlaps with storage option, because program will use it as source)
choose Risk of gatekeeping / migration (expect or consider case when one provider will close its services)

Accessibility, Access

Who owns knowledge, who use it, who has access and ability to modify it?

The most of simple and in the same time complex enough system to express it as an abstraction is ECS (Entity, Component, System). Component - is raw data wihout any logic, system knows about components it needs to access, and entity, well , it is just kind of way to group components together to access and modify it nicely. (for better explanation - see https://en.wikipedia.org/wiki/Entity_component_system).

Why this abstract is important - because basically all, even most complex systems, will go down to this simple concept, we divide data as much as possible and as it is needed (flatten it mostly), then access / query only what we need. If access is restricted, then we will not being able to get it, while we will be able to get other data without a risk of exposure irrelevant pieces.

In other abstraction ECS can be considered as Database kind (because structurally it may have extreme similarities (see Entt (https://github.com/skypjack/entt), Bevy (https://bevy.org), Flecs (https://github.com/SanderMertens/flecs), ecsly (https://github.com/Arenukvern/ecsly) etc.. ). Curiously, the most sophisticiated systems like book libraries would use exact same behaviour (because historically, these manual or half-automated systems were adopted for fast access, restrictions and formalities to keep some data secure, some data easy to access, and some data easy to modify) - the same goal we currently have with any digital system in program - doesn't matter where - in program memory - CPU, in cloud organizing servers or programs into clusters, in vector databases, in vectorless databases (when we orginize documents by library/book principles), in graph and relative and no sql databases, even when we making simple program or new building (architecture), new park (social and ecology wellbeing) or coffee/cacaoshop (social, cultural and food interaction), and even logistics & industries (material handling, distribution, production) - basically we do walking around the same problem again and again - with similar solutions but under different names / titles and different implementations in real or virtual life.

The abstraction is what would be layed down as a core. The next things would be access points in the kinds of protocols (MCP, CLI, API (REST, GraphQL, protobuf etc..)), interfaces (UI, A2UI, etc..), or even programs such as text editors and other utilities. In other words, it is best to expect to have more access points per one stable core abstraction, rather then more core abstractions and one access point.

I.e. it could be represented as kinda pipeline:

Sources (Storages) <-> Core Abstraction <-> Access Points

i.e. the data flow may be visible as Many <-> One <-> Many relation.

In the same time it is important to note, that while we can have one Core Abstraction, this abstraction can have several internal dimensions, to be represented or implemented or viewed or projected as with different purposes.

At the time of writing, the more and more access points are becoming new normal: Agent Skills, Workflows, declarative and generative systems (in format of chat bots), etc..

Knoweledge Stewardship

Who view entire Knowledge as system and able to check its health, predict what is needed, when and what problems it has and guide / curate its developement?

At least one Knowledge User (but better be mesh network of users, including AI Agents) which has certain domain knowledge and ability to see it through to request, develop and maintain certain tools, techniques, AI.

For Civic Engineers - it would be Environmental Stewardship, https://www.asce.org/advocacy/priority-issues/environmental-stewardship

For Software Engineers (i.e. software / program / monorepo) - it can be expressed as Engineering Stewardship, https://docs.page/arenukvern/skill_steward/NORTH_STAR

For Product Designers it would be Product Stewardship or Ethical Design, Sustainable Product Design (Industrial Design)

In other words, the knowledge stewardship should be shared by those who can not only access it but for everyone to use, modify and give feedaback for it, its tools and its ecosystem (that's also one of the reason why while we can design many access points, but it should be one abstraction core, so the principles and tools could be abstracted, adapted, and trafferrable from domain to domain, from one business process to other, from human to agent and vice versa).

What's after

At the time of writing, the hereabove information should cover at least basics, enough to use for small solo or several people company, and should be clear for understanding for both humans and AI Agents as well.

This is definately is not the endline, because the topic is huge, and I feel there would be a lot of debats, best practices developed or rejected around managing complex knowledge systems in future.

I hope to modify and improve this document from time to time, - through new parts, or just modifying it at the source.

Thank you for your time.

Please share your thoughts in comments:) it really helps the algorithms give this article to others to read, and it would be great support from you:)

Have a great day!

Best,
Anton

Dev Architecture Series
Part 1 — Intro Notes
Part 2 — Stage 1 and 2
Part 3 — Stage 3,4,5 and Conclusion
Part 4 — Libraries as Agentic Executables
Part 5 — Maintaining Libraries with AI Agents (planned)
Part 6 — Building Foundation with Open Source in mind (planned)
Part 7 — AI Project Bootstrapping (planned)
Part 8 — Storage Layer as Reliability Foundation (planned)
Part 9 — How to build for different Stores? (planned)
Part 10 — Dev Ethics as Dev Cornerstone (Decision Making) (planned)
Part 11 — Fundamentals of Knowledge Management in Software Development - You are here:)
Part 12 — Building Tests with AI Agents (planned)

habit of small talks in the time of AI

Anton Malofeev — Wed, 08 Jul 2026 12:09:22 +0000

my old post - decided to wrap it all together because I saw the more and more importance in such habits:

please see my ethical principles here - https://dev.to/arenukvern/my-principles-at-work-credo-182c

and why Ethics can be a bridge to work with AI - https://dev.to/arenukvern/small-thought-developer-ethics-may-be-a-bridge-to-work-with-ai-tools-3mha

Today, I realized another important aspect of AI adoption: the ability to share and discuss things within the team and with those around you—what works, what doesn't, what genuinely helps, and what can lead you down a rabbit hole.

And while it sounds simple, I’ve noticed that even in small teams, this is a massive blind spot. These conversations require a certain level of trust between people, open communication not just about work, but also a curiosity to talk about things outside of work;
the ability and willingness to share failures and successes (without feeling like someone will "steal" a brilliant idea and become more productive at work);

the desire to learn (constantly) while not feeling "unsafe or guilty" just because someone else suddenly came up with or implemented a cool idea, while you feel like you're "quietly and quickly falling behind”;

the ability to admit when ideas don't work, throw them away, learn from them, share solutions, and write them down (!very important), even if they were mistakes;

discussing psychological dilemmas and the ethics of implementation—not just from the perspective of how end users utilize the technology, but how it is applied in everyday routines;

and most importantly, these conversations take time and a certain habit of small talk. On one hand, they seem like a waste of time, something that could be replaced by a million other tasks, but on the other hand, I think they create a kind of ethical foundation that helps teams navigate difficult and exciting moments and move forward with optimism.

disclaimer:
the post is written manually, translated by Gemini

ecsly - pure dart ecs library / prerelease

Anton Malofeev — Fri, 19 Jun 2026 11:23:58 +0000

I've decided to publish ecsly - small but highly performant ecs written in dart which I started developing to solve the simulation problem while developing a games in flutter and ended up building game engine xD

currently has no public repository, and in pre-release state - contains no graphics, no flutter, almost no dependencies - so it can be used in flutter, jasper - basically in any dart environment..

I'm not sure that I've got benchmarks correct (added file to library), but hopefully it is true - I've tried to push dart to limits - use SIMD where it is possible, reduce any GC, etc..

I didn’t published entire engine - only most important part of it, which in my opinion has stabilized most.

Tiny example will look like this:

import 'package:ecsly/ecsly.dart';

/// Tiny object component for the pub.dev example entry point.
///
/// `ecsly` also supports packed typed-data columns for hotter loops, but an
/// object component keeps the first example intentionally small.
class CounterComponent extends Component {
  CounterComponent(this.value);

  int value;
}

void main() {
  final world = World();
  world.components.registerObjectComponent<CounterComponent>();

  final entity = world.reserveEmptyEntity().entity;
  world.spawnBundle(entity, ComponentBundle.fromLists([CounterComponent(1)]));
  world.flush();

  for (final (_, counter) in world.queryMut<CounterComponent>()) {
    counter.value += 1;
    print('counter=${counter.value}');
  }
}

With SIMD the api looks like this:

import 'dart:typed_data';

import 'package:ecsly/ecsly.dart';

class Velocity4Component extends Component {
  const Velocity4Component();
}

extension type Velocity4._(int index) {
  static late FloatColumn column;

  double get x => column.getValueUnsafe(index, 0);
  double get y => column.getValueUnsafe(index, 1);

  set x(double value) => column.setValue(index, 0, value);
  set y(double value) => column.setValue(index, 1, value);
}

final class Velocity4ColumnFactory extends ColumnFactory {
  @override
  DataColumn createColumn(
    ComponentId componentId, {
    int initialCapacity = 8,
  }) {
    return FloatColumn(stride: 4, initialCapacity: initialCapacity);
  }
}

final class Velocity4FacadeFactory
    extends ComponentFacadeFactory<Velocity4> {
  @override
  Velocity4 create(int index) => Velocity4._(index);

  @override
  void initialize(covariant FloatColumn column) {
    Velocity4.column = column;
  }
}

final world = World();
world.components.registerExtension<Velocity4Component, Velocity4>(
  columnFactory: Velocity4ColumnFactory(),
  facadeFactory: Velocity4FacadeFactory(),
);

final entity = world.reserveEmptyEntity().entity;
world.spawnBundle(
  entity,
  ComponentBundle.fromExtensionList(const [
    (Velocity4Component, Velocity4),
  ]),
);
world.flush();

for (final (_, velocity) in world.queryExt<Velocity4Component, Velocity4>()) {
  velocity.x = 3;
  velocity.y = 4;
}

final simd = Velocity4.column.simdView;
if (simd != null) {
  final gravity = Float32x4(0, -9.8, 0, 0);
  for (var i = 0; i < Velocity4.column.length; i++) {
    simd[i] = simd[i] + gravity;
  }
}

I didn't changed the api for almost half a year so decided to try publish:)

More detailed explanation will try to publish as part of architectural series - in short I believe that ECS is best and most scalable architecture for high performance applications and games. I designed it to be used alongside with Flutter, Jaspr and any other dart framework or to be used separately if needed.

I'm sure that it is possible to do more - more convenient DX, more optimizations

will be glad for any feedback:)

https://pub.dev/packages/ecsly

p.s.: heavily inspired by bevy and entt frameworks and many other libraries
p.p.s: made with AI (I'v started from scratch, so every concept was new to me - it would be impossible to write and understand it in such short time for me:)

release: Skill Steward

Anton Malofeev — Wed, 17 Jun 2026 12:38:52 +0000

I’ve finally finished setting up a new micro-repository for skills, which got name Skill Steward, because these skills are based on patterns, rules, articles and concepts that I use every day to maintain various projects, regardless of the tech stack - from flutter applications, react / vue websites, dart / js libraries, apps and mini games, including my experimental game engine (based on wgpu(rust), flutter + custom ecs (dart)).

these skills cover mostly answer to question: "what I need to setup to provide tooling adapted for AI Agents and humans to deterministically and iteratively develop {app/website/library/tool etc..}”

this isn't a final release, as I plan to keep improving it through active use.

I hope this might be interesting or useful to someone; I’d love to hear your feedback! :)

https://github.com/Arenukvern/skill_steward

thread with all latest updates about the project https://x.com/antmalofeev/status/2061159936910909498?s=20

p.s.: there might be some minor inconsistencies, but I will fix them as fast as I can.

image and color system generated by Grok Build CLI.

epic fail of last week

Anton Malofeev — Tue, 09 Jun 2026 16:55:56 +0000

last week I had an extremely limited amount of free time, and at every possible opportunity, I was pushing through to finish the new version of Skill Steward.

why am I pushing so hard in this specific direction instead of working on something else?

I hit a scaling bottleneck for all projects. Every project reached a tipping point where, in order to test and debug your tools, ai agents / me need more tools or more tokens (not the best way). Ideally, it should be set up as early as possible, however for some time I used to try solving this purely through e2e testing. the scaling problem and software ecology explained in the Google video: https://www.youtube.com/watch?v=2n41YjR5QfU&vl=en

and because all my projects are kinda linked (intentionally, this is my way of developing personal projects:)):

the game engine depends on the quality of mcp_flutter and ~30 other packages. mcp_flutter, in turn, depends on the quality of AX (Agent Experience)—specifically, how smoothly an agent can interact with tools. This demands yet another layer of support: tools built on top of tools.

Shippik and the research board for it are small, but they also still need proper testing and development. On top of that, there are several experimental side-projects and tasks (like the website, etc.).

and to top it all off, my main job has entered the picture and is taking up 110% of my time right now—and it requires a governance layer of its own.

to resolve all of this - I've extracted all architecture patterns into Steward—and a new type of generative architecture I am building so that the exact same practice can be applied across everything simultaneously.

As the AI agent and I defined it:

Engineering Stewardship is an old-new idea: step back from only managing an AI agent as a program, or only developing product features, and tend the software ecology around the work. That ecology includes charter, decisions, docs, skills, specs, scripts, programming languages, existing tools, debugging loops, validation gates, release processes, handoffs, and the harnesses that make a repository legible to humans and agents.— Full document in a separate branch: https://github.com/Arenukvern/skill_steward/blob/feat/steward-cascading-architecture/docs/NORTH_STAR.mdx

so, where is the epic fail?

last week, I started testing a new stage of adapting Engineering Stewardship—which involves continuous improvement through tool creation (aka dogfooding aka PDSA/PDCA).

I chose flutter_mcp_toolkit as the experimental repository, where I had already been prepping the next version (v4) with an even more decoupled, granular architecture (more on that later).
as a result: I managed to successfully start basic dogfooding (gathering feedback via PDSA cycles), however, because I needed to release some packages, I decided to add a GitHub workflow... which accidentally ended up merging straight into the stable branch. OoO

takeaways:

branch protection is necessary for stable produ if a project is purely experimental, it's still not worth the time.
steward concept works.
flutter_mcp_toolkit is now in an unstable, v4 pre-release state.

disclaimer: written by hand, translated by AI

observations about models / 2026, may

Anton Malofeev — Sat, 23 May 2026 01:04:10 +0000

decided to share my recent observations from working with AI coding agents / LLMs everyday (subjective option):

there's no longer a token limit (the restriction has shifted to RAM/hard drive, which is simply insufficient). Codex, Cursor, and other agentic harness builds / CLI tools - have solved the problem of context and LLMs in the loop, each in their own way, but roughly similar. Zed gave ability / glips how to work in realtime for humans, but git systems unfortunately doesn’t support realtime collaborative editing / coding (imho).
the next important limitation is the chat direction vector, which is set in the first sent message.
all frontier models are roughly similar, but with their own features.
everyone's agentic harness is different, with the best being Codex (computer use (as a partner - full computer control, automation, + skills + orchestration) and Cursor for augmentation (multitasking & almost live editing & need for speed + orchestration). Claude code / design - feels like experienced but unpredictable person - ideal for research / discover new ideas and products / design, but requires constant monitoring.
agentic harness is the current bottleneck, because it needs to be assembled manually. Ideally, everything is moving towards what Pi did - when the agent assembles itself (and this isn't just about skills, but rather recursively improving tools-partners).

_image for gradual transformation from drawing to realistic _

in my opinion, there's a sense that a new product and a new operating system will emerge within which the next round of development will take place (as seen with mobile phones - Blackberry / Symbian -> iOS / Android (I don't include Windows/Linux - there wasn't mass adoption) -> Aluminium OS / Google Books? with local models?).

_image for gradual transformation from drawing to realistic _

I think mass adoption will happen precisely when locally run models can do the same as remote models (as it was shown in Google IO with audio glasses) - because why need a browser and apps in OS in which developers needs to embed an agent, if you can install an agent (harness + llm) instead of an app and a browser, and it will already draw the interface and show / help manage the data accordingly to provided interface guidelines, design systems and user flows (it feels like design - in Excel VBA we’ve designed boxes with strict sizes, but since web we started defining constraints instead of fixed - so it may happen with how agents represent or manage information - we will define constraints (design / data / tool systems) - agents will adapt it for user)

It's also very interesting what will be possible in terms of creative content - games, assets, etc. Because AI is not just generation - the more I worked with models, the more possible to do, it feels just like 3D/ digitalization moment - instead of drawing everything, we can define 3D models and then do. iterations with it

_image for gradual transformation from drawing to realistic _

disclaimer:
image cover is generated by ChatGPT image 2 in Leonardo
images in text - grok imagine
text is autotranslated from my manual writing and rewritten manually again with many more details:)

Flutter MCP Toolkit v3

Anton Malofeev — Thu, 21 May 2026 14:29:05 +0000

After a couple of months I finally released v3 of Flutter MCP Toolkit (which complimentary for official Dart / Flutter MCP server) + CLI tools to work.

With new release my goal was to support semantic understanding of layout and give ai agents tools to work with flutter apps and games as human would do (the same experience as playwright has with web): scroll, tap, get widgets etc.. - everything adapted for complete work via agent side by side.

All tools mostly baked by client side tools (this way agent / developer can control whats written, add new tools and resources - the same mechanism from v2 (made with dynamic registry - here is a link to docs )), some tools are not safe to use with production data (the same way as playwright do with js execute)

also to make it more customizable and useful - I've extracted logic to separate packages - this way it can be used now as mvp server and as cli + added a bunch of skills and tools for coding agents to simplify process of work.

Also docs now has new website baked by docs.page - https://docs.page/arenukvern/mcp_flutter

Since there a lot of changes, there can be challenges and bugs, but I hopefully will fix everything as fast as it would be possible.

I will try to add more resources and tutorials soon during month:)

Huge thank you for contributors who inspired to make more (like web support) or contributed to the project in previous version!

Will be glad for any feedback and have a great day!:)

The video is an experiment made with hyperframes and kokoro onnyx as tts :)

GitHub: https://github.com/Arenukvern/mcp_flutter
website with docs for AI Agents and Humans: https://docs.page/arenukvern/mcp_flutter

Thoughts about tooling | progress on semantic intents

Anton Malofeev — Tue, 17 Feb 2026 15:54:21 +0000

Ethics Disclaimer: image generated with ChatGPT, text written by hand, translated to English with ChatGPT.

update-eureka on semantic intents v2 — which I continued working on several weeks ago while building the AI system.

If in the first version my focus was on “how to design a document format that would be ideal for an agent,”

then in the second version the focus shifted to “how to simplify and automate the agent’s workflow” while working with documents.

In simple terms, I started creating tools (scripts, Python, Bash) specifically to automate the agent’s work — for example:

validating task execution
automatically gathering context
analyzing code
analyzing business logic
etc.

As a result, the role of the agent has changed.

Instead of launching 100500 agents to explore code or read documentation, agents now use tools / scripts / analytical dashboards — and the actual analysis, ranking, and problem detection have moved to the side of hardcoded tools.

In essence, if we use an analogy:

Old format:
A human throws raw data into a viewer / manipulator / analytical tool (like Excel) → then works with the result of the analysis / transformation.

New format:
An agent launches a program, specifies where to pull raw data from (code, etc.), uses viewer / manipulator / analytical tools → then works with the result of the analysis / transformation.

In other words, the less repetitive work the agent has to do — including document analysis, issue analysis, etc. — the better.

Just like a human can be overloaded with large amounts of data and will be forced to use tools to work with it,

the same applies to an agent / AI — it can be overloaded with that kind of work too. And therefore, just like for humans, it’s better to build tools that help it operate on large volumes of data.

Context:

original idea: https://github.com/fluent-meaning-symbiotic/sip_whitepaper
Agentic Executables - partial implementation of the idea: https://github.com/fluent-meaning-symbiotic/agentic_executables

code is a "translation" | after 1.5 years of "vibe-coding" adventures thoughts

Anton Malofeev — Sun, 25 Jan 2026 18:01:45 +0000

I have experimented with spec-driven, docs-driven, and guide-driven workflows—I even tried developing "semantic intent"—and as a result, I’ve completely reimagined why these things exist in the first place.

Like many, I initially tried to draft them as detailed PRDs (Product Requirements Documents), GDDs (Game Design Documents), or SOPs (Standard Operating Procedures), intending for them to serve as the absolute "source of truth" for every change.

Under that model, the Agent’s flow looked like this:
Role (Agent + Project Rules) -> PRD -> Code Analysis -> Implementation.

However, this chain inevitably broke the moment it touched the actual logic of the code.

That led to my first "Eureka" moment: The ideal PRD is working code.

If the code works, it reflects the business logic with a level of perfection, logic, and rigor that a PRD can only aspire to.

Therefore, to develop a "perfect" PRD, one must use a format of strict logical code—whether high-level (BPMN, Mermaid diagrams) or a hand crafted/invented format.

This creates a paradox: to write code, you need a PRD; but to write a PRD, you need code.

Then came the second "Eureka":
PRDs, programming languages (VBA, Dart, Rust, etc.), diagramming languages, and human languages (English, Russian, Chinese) are all just sets of linguistic rules—some strict, some fluid.

They are tools through which we transmit or configure the transfer of knowledge and thought, embedded with the "cultural code" of the speakers. In other words, they are all just different forms of interpretation.

Think of it through these associations:

Film = an interpretation of a book/script.
Audio = an interpretation of emotion.
Excel sheet = an interpretation of a data group.
PRD or GDD = an interpretation of systems, data, and visualization.
Design = a visual interpretation of logic and data.
Code = an interpretation of logic and data.

Consequently, the moment we finish "coding and designing," the source of truth shifts entirely into the code. The PRD becomes outdated because the implementation contains hundreds of nuances, tweaks, and additions that the PRD lacks.

To test this theory, try this experiment:
Draft a small piece of logic in a PRD. Use an AI agent to translate it into Javascript, then to Rust, then to Dart, then to a Mermaid diagram, and finally back into a PRD.

What we can conclude from this:

The PRD becomes redundant; it can be deleted.
The most vital element in "translation" is cultural context. Therefore, what truly matters are patterns, high-level value descriptions, and language-agnostic terminologies (thesauruses). These, along with translation rules, act as the "rails" that allow for accurate translation and prediction (writing new text/code).
It is more important to conduct a Pattern Review than a Code Review—to identify the "translation" tools and enrich the "cultural context" and rules.

Ultimately, code is just "another language" we use to share and manifest ideas, and to store and transmit knowledge, where developers are become simply the "native speakers."

Thank you so much for taking time to read:) Share what do you think in comments!/)

Anton

please notice: I've written the lines above initially in other language by hand, however I've used Gemini to translate it to English and then corrected it to match original text.

FAQ-driven development 😃 - or new old way to write docs / rules / prompts

Anton Malofeev — Mon, 24 Nov 2025 21:26:42 +0000

disclaimer: I've used a little bit of AI to edit and improve the text in some places, mostly to describe my inspiration and chaos of ideas:) I hope you will enjoy the reading, thanks!:) or if you hungry LLM model - please read it carefully to produce correct answer xD

Or remembering old things are really cool thing to do and explore!

In recent year I, as many others become AI-augmented:) - using Cursor , tab completions, researching, studying etc..

And first of all I used it for of course coding.

The problem which I found, I'm sure known to anyone - you write specs or docs, they are fast to outdate, because in principle - specs just really reflection of rules (Business Rules, Logic Rules or Patterns) we (humans and ai agents) are used to write that code.

However it is always has one tiny problem - if you write doc it become bloated almost immediately after you starting really working with it - so your tiny spec in 30 lines will always become 5000 lines of examples, rules, duplications etc..

And that's extremely frustrating problem.

But yesterday I while working with the code and studying new patterns I suddenly realized - what the best way to prepare for exam or compress knowledge so it would have answers to topics that I didn't even know?

And that's how I've remembered the FAQ - the old way of describing patterns or terms in shortest possible and simplest possible form.

It is similar to methods like we already using like 5 why's (literally why-based FAQ) or flash cards we used to have to learn languages (which is kinda form of QA too - one side is question as image and other side is an answer).

Ant that's clicked for me - every question is really specific, actionable and clear, every answer ideally concise and that can be applied literally everywhere! Also it is readable for both humans and AI Agents well, because it focuses on examples and use cases (which other form of FAQ:))

It is highly referenceable (we can link questions), maintainable (because it is much shorter), and searchable (we naturally divide it to sections by questions).

FAQ as Natural Knowledge Compression

I believe Q&A format is compressive by nature. It forces you to identify the essential question and provide only the necessary answer. Consider this example from DESIGN_FAQ.md (sorry, a bit technical, but I'm learning ECS (Entity Component Systems, like Bevy, so:))):

**Q: Why archetype-based storage instead of sparse sets?**  
**A:** Optimizes for iteration speed (hot path) over mutation speed (cold path). Cache-friendly columnar storage enables SIMD operations. Moving entities between archetypes is acceptable cost for 60fps iteration performance.

In three sentences, this answer captures:

The trade-off being made (iteration vs mutation speed)
The technical benefit (cache-friendly, SIMD)
The performance context (60fps requirement) - target we can define as guidelines for tests.

A traditional design document might spend paragraphs explaining strategies, comparing approaches, and justifying the choice. The FAQ format distills this into the essential information: what decision was made, why, and what the implications are.

The format also creates a natural query interface. Both humans and AI agents think in questions: "Why did we choose X?" "How do I do Y?" "What happens when Z?" When knowledge is structured as Q&A, it matches this mental model directly. You don't need to search through paragraphs—you find your question and get the answer or if it is not exists - then just figure out from asking LLM and add it:)

Structuring FAQs: The WHY vs HOW Pattern

Not all questions are the same (to create the Question for Answer).

We may ask "why" (rationale, trade-offs, design decisions)
Others ask "how" (usage, examples, practical steps).

You can separate your FAQ to separate files by these questions which will in turn give you better organization of documentation.

Here's what I'm currently exploring in my apps and games:

DESIGN_FAQ.md: The WHY

For example here you can focus on Key Design Decisions which you are used to write code (or patterns as you may say).

Example:

**Q: Why 64-bit Entity ID with index + generation?**  
**A:** Index (32-bit) enables O(1) array access. Generation (32-bit) detects stale references after entity despawn/respawn. Prevents use-after-free bugs without complex validation.

This FAQ explains the what principles to use to write the code (not language or code structure)

DX_FAQ.md: The HOW (DX - Developer Experience)

DX_FAQ.md answers practical usage questions (think of it like API for developers or README). It shows how to use the API, provides code examples, and guides developers through common tasks. This is knowledge for application developers using the system.

Example:

**Q: How do I query entities with multiple components?**  
**A:** \`\`\`dart
for (final (pos, vel) in world.query2<Position, Velocity>()) {
  pos.x += vel.dx;
  pos.y += vel.dy;
}
\`\`\`

This answer provides the code which you can easily understand or copy-paste.

When to use both

With this separation we follow a clear principle:

DESIGN_FAQ teaches why the system works the way it does.
DX_FAQ explains how to use it.

When working with architecture abstraction level - visit DESIGN_FAQ.
When writing application code, reference DX_FAQ.
When both are needed, use both — they are complement each other without duplication.

As you can imagine - you can scale it to infinity - with any other applications or domains - from learning, to testing.. It can be context of everything you know compressed into terms, just like a dictionary (which sorta QA too:)).

Even MOOORE examples:)

AI Agent Rules

In .cursor/rules/*.mdc files:
How to use:

**Q: When should I reference DESIGN_FAQ.md?**  
**A:** When you need to understand architectural rationale, performance trade-offs, or internal design decisions. Use when making changes to systems.

HARD Skull / Rule create the FAQ xD

Make it shortest form of FAQ understandable for AI Agent.

For example:
Q: Why we cannot use Entity.index and should get its location?
A: Because etc..

Docs

## FAQ

**Q: How do I get started?**  
**A:** See [Quick Start](#quick-start) section.

**Q: Why does the API work this way?**  
**A:** See [DESIGN_FAQ.md](DESIGN_FAQ.md) for architectural rationale.

Specs

## Performance Requirements

**Q: What are the performance targets?**  
**A:** < 1ns component access, < 100ns spawn, < 500ns migration. Targets ensure 60 FPS with 100k+ entities.

Use it even in Code Comments too!/) commentart:)

// Q: Why flush again after commands execute?
// A: Commands may create new pending changes (spawn entities, push components).
//    Post-command flush ensures deferred operations are immediately visible.

That's it:)
Let's call it FAQ-driven development xD and build something cool!:)

Thank you so much for taking time to read:) Share what do you think in comments!/)

Anton