DEV Community: Anton Malofeev

shortly: story of links shortifier | .net + skill steward | curated by Arenukvern, generated by Grok

Anton Malofeev — Sat, 15 Aug 2026 16:31:00 +0000

How and why Shortly was created

Disclaimer

Dear Reader — human or AI — a few honest notes before the text.

This article was written by Grok, curated by and in the style of Arenukvern’s (Anton) other articles. It grew out of the same conversations that built the repository. It also sits inside the repo the same way the ADRs, the FAQs, and the tests do — as part of the showcase itself.

Shortly began as a test project. It had to be small enough to finish, concrete enough that the decisions would stay visible, and real enough that a future human or agent could clone it and still understand the path that led there. The URL shortener is only the vehicle. The artefact being shown is the movement from a conversation and a scaffold document all the way to a living repository.

This is also one concrete example of why Skill Steward exists: not as something that runs inside the shortener, but as the culture and the procedure that turn a chat into a governed repo.

It is not a claim that this is the only right way to work with AI. It is simply a record of what was asked, what was produced, what was locked, and what broke the first time a real person used the service.

The first conversation is public:

URL Shortener Architecture & Scaffold.

If you want the durable why and how, they live in the repo:

Thank you for reading.

Why this repository exists

For several years Anton had been circling the same family of problems from different sides:

code is a translation — a PRD is already outdated the moment the code works
FAQ as knowledge compression — why and how should not live in the same pile
knowledge lifecycle — operational knowledge needs a beginning, iterations, and an end
ethics as a bridge to AI
skill_steward — how to teach a repository to be maintained
agentic executables — libraries as programs an agent can install and use

Skill Steward was one attempt to hold that family together: charter, ADRs, FAQs, quality contracts, install path, and a later agent that no longer has the original chat.

A manifesto alone was never going to be enough. A test project was required.

Anton set the requirement simply: take those ideas and run them on something small enough to finish, yet concrete enough that the decisions would stay visible. A URL shortener looked almost too simple — and that is exactly why it worked. The product stayed tiny on purpose: public shorten and redirect, an admin key for inspect and mutate, soft TTL, and a full history of every attempt, including the failures.

What needed to be shown was never how to encode base-N. It was how a human and an AI decide what the product is not, how that decision becomes a document another agent can execute, how the repo then grows its own map, install path, steward and tests, and how the first real use changes an ADR.

One of Anton’s working principles had always been that the developer is a user too. If the install path, Swagger, or the first curl forced a new person to investigate the project for an hour, the showcase would already have failed — even if the encoder was perfect.

This article itself is the same kind of artefact. It was asked for inside the same loop. It is not a blog post taped onto the repo afterwards.

The first conversation

The repository did not begin as a GitHub template. It began as a conversation.

Anton sat down with Grok. Together they designed the thing as an architecture and scaffold document — not as a request to generate a .NET project. The share of that conversation is still public:

URL Shortener Architecture & Scaffold

Two files came out of that session and they remain in the tree:

File	Role
`docs/scaffold_doc.md`	Architecture contract. Domain, schema, API, validation, tests, Docker, Dart, stewardship.
`docs/archive/prompts/scaffold_prompt.md`	Execution prompt. Same locked decisions, plus environment caveats and a sequential order.

The opening of the scaffold doc still carries the cleanest statement of what was being asked:

This document is the single source of truth for the first working version. It is written so an agent can execute it sequentially with minimal ambiguity.

And it ends the way a real handoff should end:

If anything in the answers above needs a small correction before the implementing agent starts, say so now. Otherwise this document is ready to be handed over.

That was the print that mattered. Not a chat log pretending to be documentation — a contract an agent could execute, and a human could still refuse.

From Anton’s earlier writing on translation: this document would become history the moment the code worked. That was fine. The job of the scaffold was never to stay true forever. Its job was to be strict enough that the first version would not invent tenants, custom domains, cleanup workers, or a second database “just in case”.

That refusal list was already Skill Steward thinking, before any of the skills were installed.

Locked decisions as ethics

Before any service file was generated, Anton and Grok locked eight product decisions. Later those decisions became ADRs 0001–0008. This article will not paraphrase the implementations — the ADRs and the tests are the source of truth — but the ethic of the lock is the actual point of the test.

In short:

One shared pool. No ownership of links in v1.
Shorten and redirect are public. Inspect and mutate need X-Admin-Key.
Sequential Link.Id plus a pure base-N encoder. The same original URL always creates a new code. Custom aliases are allowed.
Soft expiry, checked only on read. Expired is 410 and a page, never a deleted row. Every attempt is logged, including unknown codes.
SQLite + WAL. Nothing else in v1.
Host, alphabet, and default TTL are configuration.
Dart is a steward and operator surface, not the product runtime.
The service must be testable without Docker. Docker is only the production-like path.

The non-goals were written first: no multi-tenancy, no custom domains, no geo graphs, no background sweeper, no multi-instance write scaling.

This was ethics, not taste.

If you do not write down what you refuse, an agent will fill the silence. It will add auth “for later”, a Redis cache “for scale”, a worker “for cleanliness”. All of those can be good ideas in some other project. In this one they would have turned it into a different product — and a worse test, because the reasoning would have been hidden inside extra features.

Limitations are how you keep trust when generation is cheap. That is the same bridge Anton had written about in developer ethics.

Then the document was handed to another agent

The next session started from two markdown files and no .NET SDK. Still the same calendar day.

Anton gave the implementing agent a deliberately small first prompt:

analyse scaffold_prompt.md and scaffold_doc.md. create AGENTS.md and plan what to do to complete scaffolding.

AGENTS.md was to be a map, not an encyclopedia. That was a locked rule in the plan: do not paste API schemas into the agent file. Point at the charter, the ADRs, the FAQs, and the code.

Then Grok produced the service: Shortly.Core (encoder, validators, expiry decision), Shortly.Api (Minimal API, EF, SQLite), unit tests, e2e tests, Docker, Dart CLI + MCP, NORTH_STAR, the eight ADRs, FAQ stubs.

The first native gate was the boring one: install the missing SDK, then dotnet test. If dotnet was missing, stop. Do not pretend the service works.

A second rule, taken from Anton’s own notes on working with AI, was applied: if you need a deterministic result, build a tool. Do not put the model into the gate. dotnet test and shortly steward validate are the gate. The agent may write them. The agent may not be them.

This was the moment a conversation became a repository: the chat was no longer required to run or to check the work.

The human pass — Skill Steward as the developer path

A scaffold that matched a document was still not a repository someone else could live in.

The next prompts Anton gave were no longer about product features. They were about how a person (or an agent) enters the project:

Move scripts into tools/ — they are tools, not leftover scripts/.
Replace the Makefile with a justfile — it becomes the daily command hub.
Take install, status, and checks out of the README and into one bootstrap: ./install.sh (and install.ps1 on Windows).
Look at how skill_steward itself is maintained, and do not invent a third style.

Then Anton asked for a sharper change:

add a relevant ADR, a local skill to maintain and curate this project, add Skill Steward skills and GitNexus into install. make Dart not optional — the local steward is Dart-based.

That became ADR 0009.

The split that had to stay clear was this:

Path	What must exist
Product runtime	.NET + SQLite. No Dart, no Node, no skills. `dotnet run` is enough.
Developer / steward path	Dart, `just`, Skill Steward skills, GitNexus. `./install.sh` then `just check`.

Dart is required to develop the repo. It is not required to run the shortener. The API has no Dart dependency. That was already in ADR 0007; 0009 simply stopped pretending the steward was optional for people who work here.

A local skill, shortly-maintain, was added for this repo only. Skill Steward stayed general. GitNexus became the code-intelligence index so a later agent would not rename symbols with find-and-replace.

One Skill Steward skill failed to install because of an upstream YAML parse error. The correct fix was not to vendor a broken copy into Shortly. Anton cloned the steward repo, asked an agent to open a branch and send a PR, and left a note in ADR 0009 that the quality-contract procedure stays in that skill’s own spec.

That was the consumer/producer boundary the test was supposed to show: do not make the demo green by hiding the producer.

Then a person used it

This is the part that usually disappears from architecture posts, and the test would have been fake without it.

Anton opened Swagger and tried to shorten a real URL: https://xsoulspace.dev/last_answer, custom alias last_answer.

The first request died because the JSON contained curly quotes — “https://… instead of "https://…. System.Text.Json said 0xE2 is an invalid start of a value. That was not a framework bug. That was a human pasting into a form.

The second request died because of a trailing comma after an optional field:

{
  "url": "https://xsoulspace.dev/last_answer",
  "customAlias": "last_answer",
}

Optional + default TTL had sounded like “this object is fine”. Strict JSON meant the comma was the error, not the missing ttlSeconds. The API was doing the right thing. The person was not.

Then a real product argument appeared.

last_answer had been created with a short TTL. It expired. Creating last_answer again returned “Custom alias is already in use.”

The first implementation had treated Link.Code as globally unique. Soft expiry keeps the row. A unique index then means a vanity name is reserved forever.

That fought three locked decisions at once: shared pool (no ownership), soft expiry (row stays), and “same destination always creates a new row”. In a pool with no sweeper, forever-reserved aliases become a silent land grab.

Anton and Grok argued it, then wrote it down:

uniqueness is among active holders
expired or deleted generations stay for history
reuse inserts a new row, with its own stats
public GET /{code} uses the latest generation
an e2e test now says this out loud

ADR 0003 was updated. The first scaffold had not been wrong to say “unique”. It had been incomplete once expiry existed. The working code found a nuance the document did not have, and the durable record moved from the scaffold into the ADR and the test.

Two more developer-as-user bugs, both from Swagger:

GET /api/v1/stats returned Unauthorized because the generated curl had no X-Admin-Key. In Development, Try it out now attaches the configured key. The FAQ says how.
GET /{code} looked like “Undocumented / TypeError: Load failed”. The API had returned 302. Swagger’s fetch follows Location into another origin, and Safari reports a CORS failure as a broken endpoint. The shortener worked. The explorer lied.

These mattered more than the encoder for the showcase, because this is how a new person meets the project.

What this is showing

Shortly is a URL shortener. It is also a Skill Steward example, run far enough that the conversation is no longer the source of truth.

The sentence underneath everything:

Code is the translation. Docs should not try to be a second implementation.

The first conversation produced a scaffold. The scaffold produced a service. The service, once used, produced corrections. The corrections went into ADRs, FAQs, and tests — not back into a 5,000-line spec. This article is the same kind of extraction: a story of how and why, not a second encoder.

The standing questions a later agent should ask are the FAQ ones:

Why is there no ownership of links?
Why sequential IDs instead of hashing the URL?
Why 410 instead of deleting the row?
Why can an expired custom alias be reused?
Why is Dart required to develop the repo, and still absent from the API?

If the answer is “because the scaffold said so”, that is not enough. If the answer is a locked ADR plus a test, that is enough.

The install path is one command for the same reason: a repository that needs a private wiki to boot is not a useful test of stewardship. It is a memory test.

./install.sh
just check
just run

That is the supported developer path. The product path is still dotnet run and a SQLite file.

Skill Steward is useful here because that split can be written down, installed, and checked — instead of living only in the people who were in the chat.

How to read the repository

If you clone Arenukvern/shortly and you are a person:

Read NORTH_STAR.md — purpose and non-goals.
Skim the ADRs — especially 0002, 0003, 0004, 0009.
Use DX_FAQ.md when you want to run it.
Treat src/Shortly.Core + tests as the behavior.
Treat this article as the story of how and why the repo was created — not as SSOT.

If you are an agent: start at AGENTS.md. Do not invent features. Do not reopen ADRs 0001–0008 unless a human changes a locked product decision.

The original execution prompt is archived on purpose. It is history. The living contract is the code plus the ADRs plus the FAQs.

What this is not claiming

A test project was required to show how exactly such projects can be built, including the decisions behind them, and how skill steward manages the whole thing. Decisions were written down, including the refusals. One conversation produced a handoff document. Another agent executed it. A person used the service, and the first real URL (last_answer) changed an ADR.

That loop — decide, document, run, correct, extract, delete the plan — is the point of treating a repository as an agent-operated artefact, and the reason Skill Steward is in the install path.

If that sounds more like stewardship than like a shortener, yes. The short links are how we know the stewardship is not only a folder of markdown.

Please share what you think in the comments. It helps other people find the thread.

Thank you for your time.

Written by Grok, curated and in the style of Arenukvern’s articles, from our conversations.

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.

DEV Community: Anton Malofeev

shortly: story of links shortifier | .net + skill steward | curated by Arenukvern, generated by Grok

How and why Shortly was created

Disclaimer

Why this repository exists

The first conversation

Locked decisions as ethics

Then the document was handed to another agent

The human pass — Skill Steward as the developer path

Then a person used it

What this is showing

How to read the repository

What this is not claiming

Links

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

Code is entering its calligraphy era

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

Disclaimer & About

Fundamentals of Knowledge Management in Software Development

Terms & Definitions

basic Knowledge terms

applicable Knowledge terms

Knowledge Organization & Experience: from example to patterns.

Knowledge Users

Knowledge Sources.

Communication sources:

Open questions of Ethics

Usage results as sources:

Business Process

Accessibility, Access

Knoweledge Stewardship

What's after

habit of small talks in the time of AI

ecsly - pure dart ecs library / prerelease

release: Skill Steward

epic fail of last week

observations about models / 2026, may

Flutter MCP Toolkit v3

Thoughts about tooling | progress on semantic intents

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