DEV Community: Anton Malofeev

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

Reimagine Libraries management as Apps using Agentic Executable framework

Anton Malofeev — Mon, 13 Oct 2025 00:57:02 +0000

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 - You are here:)
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 — Domain Knowledge (Agent Domain Context) (planned)
Part 12 — Building Tests with AI Agents (planned)

Libraries as Agentic Executables

Can you imagine you can install / configure and uninstall libraries (in any language and framework) as easy as any app or game on your phone or computer?

This article is about how we can achieve this.

Or in other words - Agentic Executables treat libraries as executable programs with structured, agent-readable instructions. Instead of relying on human documentation, AI agents follow standardized .md files to install, configure, integrate, update, and uninstall libraries autonomously.

If you prefer to see how it works - please see the video

This problem follows three part structure:

Why (The Problem)
How (The Solution)
Implementation Architecture
How to use it Today?
Conclusion
Links

If you want to jump to the implementation architecture, click here.
If you want to use it Today? click here.

Let's start with the Why (The Problem) part.

Why (The Problem)

In the current time and year of writing this article, for any development project (i.e. coded project), we usually use libraries or packages to reuse code effectively.

Some of the libraries, usually configurable ones, often have extensive documentation and examples not only how to install, but how to configure, use, test and uninstall it.

The common installation, configuration and usage pattern may look like this:

use CLI or package manager to install/find the library
read the documentation of what we need to do to use it.
analyze your codebase to see how we can integrate it.
try to apply the actual code from the library to your codebase and your solution (from codebase structure/architecture point of view)
configure the library if needed.
try to test (visually or using tests) to see if it works.
modify the code if corrections are needed.
add tests or configuration if needed.

The more important - all instructions / documentation is written for humans.

And usually, most of these steps, we try to follow as humans - step by step.

However, with the rise of AI Agents - what if we will treat libraries and packages not as abstract reusable parts of code, but as the executable programs? Programs with the same ability to be installed, configured, used and uninstalled as usual apps or games on phone?

If you imagined it - let's call it "Agentic Executables" (below - "AE") and dive into the how we can create / maintain them:)

How (The Solution)

As first thing, let's establish meta rules to create and modify files of AE:

AE Domain Knowledge - terms, concept, principles of what is AE to give enough context for AI Agent. This file will help us to maintain the files.
Installation creation with three logical steps:

1. Installation (using CLI or package manager)
2. Configuration
3. Integration

Usage creation.
Uninstallation creation.

With all of that, let's define the principles of working with AE.

Working principles:

Core Principles

Agent Empowerment - AE docs written for AI, not humans. Therefore AI agents can work autonomously without or under minimal human intervention
Modularity - Clear, reusable instruction steps and pieces.
Contextual Awareness - Sufficient domain knowledge tailored made for AI Agent and ready to be used with end project.
Reversibility - Clean uninstallation restores original state
Validation - Built-in verification steps
Language / Framework Agnostic - Works across all ecosystems and languages

Core Idea

The core idea is to pass meta rules to AI Agent to give him ability to:

maintain the library executables (basically - meta instructions)

1.1 The basic terms & domain knowledge (what is AE and how it works) - ae_context.md
GOAL: To maintain ae_bootstrap and ae_usage files
USER: Maintainer of the library

1.2 The drop file to maintain the library executables - ae_bootstrap.md.
GOAL: To create ae files structure and maintain it.
USER: Maintainer of the library

1.3 The drop file to use ae files in library - ae_usage.md
GOAL: To use ae files of this library.
USER: User (in other words - developer who uses this library)

ability to install / uninstall / update (basically, one time to use rules)

2.1 Installation, Configuration, Integration files - ae_install.md
GOAL: To install, configure and integrate the library.
USER: User

2.2 Uninstallation file - ae_uninstall.md
GOAL: To uninstall the library.
USER: User

2.3 Update file - ae_update.md
GOAL: To update the library from old version to new one.
USER: User

ability to use the library frequently / or depending of its usage needs. Created via ae_use.md file.

3.1 Usage file - the rule, adapted to the library name. For example, for library name go_router and Cursor AI usage it can be a rule in the path go_router_usage.mdc. During installation to User Codebase , AI Agent needs to ask User what AI Agent should be used, and place / name it according to it. For example, if User wants to use Cursor AI, AI Agent should place this rule to the path .cursor/rules/go_router_usage.mdc.
GOAL: To use the library frequently / or depending of its usage needs.
USER: User

The AE files structure:

root/
├── ae/
│   ├── ae_context.md
│   ├── ae_bootstrap.md
│   ├── ae_use.md

The library AE files will be located in the root/ai_use folder.
At the end this would be the structure of the library AE files:

root/
├── ai_use/
│   ├── ae_install.md
│   ├── ae_uninstall.md
│   ├── ae_update.md
│   ├── ae_use.md

Implementation Architecture

To implement this solution, I've created a registry of AE files to centralize them and make them easily accessible for developers.

Here is how it works in high level:

Workflow Overview

Library Author                  Registry                   Developer
      │                            │                           │
      ├─► Create AE files          │                           │
      ├─► Submit to registry ─────►│                           │
      │                            │◄───── Fetch AE files ─────┤
      │                            │                           │
      │                            │                   AI Agent executes
      │                            │                   installation

To make it easy to use, I've designed an MCP server for giving AI tools to access and support AE ecosystem for developers and library authors.

Let's start with end developers example: how they can use AE files.

With MCP server, the workflow is pretty straightforward:

Installation workflow example:

The same workflow works for other actions like usage, uninstallation, update.

As you can see, every action is executed by AI Agent, and with MCP server, it is easy to use and maintain.

Library Author workflow:

Almost the same workflow works for library authors - they can just ask AI Agent to bootstrap or update AE files, and AI Agent will do the rest.

One exception is that to submit AE Files to the Registry, we still need to send PR to the Registry repository.

(I think we can automate it in the future).

That's it:)

In the time of writing this article, the registry I've started testing registry and MCP server on personal projects and with some bugs (of course) install / uninstall / configure already works.

How to use it Today?

You are Developer:

First you need to install MCP server.
To do this, please drop https://github.com/fluent-meaning-symbiotic/agentic_executables/blob/main/agentic_executables_mcp/ae_install.md file to your AI Agent or install it manually.
Second, use it:

to install library (make sure it is in registry) write to your AI Agent: create a plan to instal "library_name" as ae
to uninstall - create a plan to uninstall "library_name" as ae
to update - create a plan to update "library_name" as ae
to use - create rules for {AI Agent} to use "library_name" as ae

That's it:)

You are Library Author | Maintainer:

to bootstrap / update - create a plan to bootstrap / update "library_name" as ae
to submit to registry - create a plan to submit "library_name" to registry as ae

That's it:)

Conclusion

Please share your thoughts in the comments (that will be great support and motivation for me)! :-)
If you want to discuss / use it / have ideas to improve it - create issue or pull request to the repository: https://github.com/fluent-meaning-symbiotic/agentic_executables or jump in to discord server: https://discord.gg/y54DpJwmAn

Thank you for your time and have a great day!

Anton

How to conduct a useful technical interview (based on my personal experience (subjective opinion))

Anton Malofeev — Mon, 15 Sep 2025 13:15:15 +0000

First of all, you need to understand who and for what tasks you are looking for.

For example, if you need a developer who can adjust and adapt to tasks, then you should ask about what techniques/methods they use to learn something new, how often they are interested in new things themselves – you can ask how they would conduct research, and if they have had similar experience.

If you "urgently need a developer" for "this task for a week" you must definitely consider that they will need to get familiar with the codebase and the project itself (adaptation time) – and it’s good if this takes a week or two. Ask a developer does he have such experience, and how comfortable he would work in such case (because any urgent cases usually are the most stressful ones).

You also may ask does the developer had experience to reorganize planning, to organize more non-stressful process and if he had such - how exactly?

If you need a developer "to build an app from scratch," it’s better to ask if they have such experience, how much they interacted with designers/products, if they have experience in design development, client communication, and if they have their own codebase.

The best way to conduct an interview in this case is to describe a small business task (as a complete application) and ask them to estimate what will be required in terms of architecture, tasks, planning, and team interaction to complete the project.

In all cases, it’s worth asking about motivation (of course, besides the financial aspect), priorities, and future growth (where the person roughly aims to get and why).

Why this is important:

In my opinion, everything depends on what kind of people are gathered in the team – how they will work together, whether there will be synergy – sharing experience between developers/designers/products.

A very important point when evaluating tasks is not that such a task has already been done, but who exactly will do it – someone may already have experience in similar tasks, for someone this particular domain will be unknown, and edge cases will be resolved later...

Share your experience in the comments :)

Flutter app AI centric architecture for small startups. Part 3 - Stages 3–5

Anton Malofeev — Thu, 28 Aug 2025 00:17:52 +0000

Thoughts about scalable code structure based on developer as user philosophy combined with iterative design using AI.

Dev Architecture Series
Part 1 — Intro Notes
Part 2 — Stage 1 and 2, Previous
Part 3 — Stage 3,4,5 and Conclusion - You are here:)
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 — Domain Knowledge (Agent Domain Context) (planned)
Part 12 — Building Tests with AI Agents (planned)

Introduction

In the first part of this series, we defined key terms and principles. In Part 2, we walked through Stage 1 and Stage 2. If you missed them, check out the Part 1 — Intro Notes and Part 2 — Stage 1 and 2

Note: after using Cursor AI and other different agents for about a year it’s become obvious that some changes are needed, therefore I will continue architecture series in future (so the content become a plan xD) — if you have any thoughts — please leave comment:).

Let’s continue our journey!

Stage 3 — Feature Iterations

Team: 2 Developers

Main focus: Test and try features for specific domains to make these domains logically complete.

While this part is quite small for changes — and may not contain any radical changes in structure, I think it’s quite important on this stage to follow two principles:

Keep refreshing, refining, and updating domain knowledge from testing and using the application.
Keep every small feature implementation separate from the screen where it is placed. Treat the screen as a layout where you place widgets, and it would be much easier to reuse any feature-related widgets, as they will behave as self-contained micro applications.

Stage 4 — Scaling

Team: 2–3 Developers

In my opinion, there are two paths at this stage:

Path 1 — Scaling to Other Platforms

This stage means that we need to publish it to stores on several platforms simultaneously.

In that case, we will have to deal not only with different factors: platform, adaptive, responsive factors (https://docs.flutter.dev/ui/adaptive-responsive/best-practices)

That means, it would be better to make the following changes to the structure.

First, move the whole data layer (folders with prefixes data) and core into a new package “core”.

/packages/
├── core/ // or data layer
│   ├── core.dart
│   ├── src/
│   │   ├── core/ // I prefer to keep core as a separate package, as it often has tendency to be reused in other projects, and this way it would be easier to separate it in future to a separate package.
│   │   │   ├── utils/
│   │   │   ├── extensions/
│   │   │   ├── hooks/
│   │   │   ├── l10n/
│   │   │   └── side_services/
│   │   ├── data_local_api/
│   │   ├── data_remote_api/
│   │   ├── data_repositories/
│   │   ├── data_models/
│   │   │   ├── api_dto/
│   │   │   └── {domain}_models/
│   │   ├── data_states/
│   │   ├── di/

Second, move the whole ui_kit into a separate package.

/packages/
├── ui_kit/
│   ├── ui_kit.dart
│   ├── UI_KIT_README.md
│   ├── atoms/
│   │   ├── ATOM_README.md
│   ├── molecules/
│   │   ├── MOLECULES_README.md

Third, take a look at domains and features and where they are placed.

What you can find is that if most of the features were separated from screens inside flows, it is quite easy to separate every screen to the following functionality:

View Layouts // <- layout where features were placed.
Flow logic // <- navigation between views
Features // <- business implementation

Then, move all domain-related logic — layouts (optional), flow (optional), features to a new package “ui_domains”.

This will be your foundation, where all features, sharable layouts, and flows for domains are written. Think of it like a box of blocks, which separately have some independent functionality within a scope of a specific domain.

Because every platform has its own layouts, flows can be different. For example, where in mobile you will push several screens, in desktop you may open just one window.

Then, depending on your end goal, create a separate app for every platform you need.

For example, you can end up with the following structure:

Abstract code structure

/
/apps/
├── {platform}_app/  // <- separate applications with new entry main, which can use different layouts, based on ui_domains package.
/packages/
│   ├── core/
│   ├── ui_kit/
│   ├── ui_domains/ // <- this new package will be used in all apps
│   │   ├── src/
│   │   │   ├── ui_{domain}/
│   │   │   │   ├── {DOMAIN}_KNOWLEDGE.md
│   │   │   │   ├── {flow}/
│   │   │   │   │   ├── {feature_name}/
│   │   │   │   │   ├── ├── {feature_name}.dart // barrel file with conditional exports, which are extremly useful for platform dependent features https://dart.dev/tools/pub/create-packages#conditionally-importing-and-exporting-library-files
│   │   │   │   │   ├── ├── {feature_name}_{platform}/
│   │   │   │   │   ├── layouts/ // <- typically you may have different layouts for same features, so it is make sense to place it directly in the flow folder. But in same time, if you need to move to different place - thats fine too - since in my opinion, that's more business/design related decision.

Example code structure

/
/apps/
├── desktop_app/
├── web_app/
├── mobile_app/
/packages/
├── core/
├── ui_kit/
├── ui_domains/
│   ├── src/
│   │   ├── ui_payments/ // <- domain
│   │   │   ├── ui_payments.dart // <- barrel file with exports
│   │   │   ├── PAYMENTS_KNOWLEDGE.md // <- domain knowledge
│   │   │   ├── pay/ // <- flow
│   │   │   │   ├── qr_pay/ // <- feature
│   │   │   │   │   ├── qr_pay_feature.dart // <- feature barrel file with conditional imports
│   │   │   │   │   ├── qr_pay_ios/ // <- platform feature implementation
│   │   │   │   │   ├── qr_pay_android/
│   │   │   │   │   ├── qr_pay_web/
│   │   │   │   ├── provider_pay/ // <- feature
│   │   │   │   │   ├── provider_pay.dart // <- feature barrel file
│   │   │   │   │   layouts/ // <- flow layouts
│   │   │   │   │   ├── desktop/
│   │   │   │   │   ├── mobile/
│   │   │   ui_profile/ // <- domain
│   │   │   ├── ui_profile.dart // <- domain barrel file
│   │   │   ├── PROFILE_KNOWLEDGE.md // <- domain knowledge
│   │   │   ├── auth/ // <- flow, but as you can imagine, if it will outgrow just auth logical domain, the transform it into a domain and move up.
│   │   │   │   ├── login/ // <- feature
│   │   │   │   ├── ├── login_ios/
│   │   │   │   ├── ├── login_android/
│   │   │   │   ├── ├── login_web/
│   │   │   │   ├── registration/
│   │   │   │   ├── ├── registration_ios/
│   │   │   │   ├── ├── registration_android/
│   │   │   │   ├── ├── registration_web/
│   │   │   │   │   layouts/ // <- flow layouts
│   │   │   │   │   ├── desktop/
│   │   │   │   │   ├── mobile/
│   │   │   ├── settings/ // <- flow
│   │   │   │   ├── settings.dart // <- flow barrel file
│   │   │   │   ├── customization/ // <- feature
│   │   │   │   ├── ├── customization_ios/
│   │   │   │   ├── ├── customization_android/
│   │   │   │   ├── ├── customization_web/

The difference will depend on what features are represented. For example, some iOS native functionality may not just work or not exist on Linux desktop. Therefore, you will need create a Linux implementation specific to a feature or construct an entirely different experience using only some of iOS features and separate it into independent package.

The great documentation how to write native plugins and packages is described in flutter website (https://docs.flutter.dev/packages-and-plugins/developing-packages).

Path 2 — Same App, Different Configurations

Another way to scale your application by having different flavors. https://docs.flutter.dev/deployment/flavors . But at the same time, if the differences are huge, it would be reasonable to reconstruct them as different apps.

So in contrast with Path 1, I think in this path you may have the same layouts, but new domains, new flows, and new specific to new apps features. The important part, that you may or may not include domains, flows or features to different apps.

Abstract code structure

/
/apps/{mobile_app_with_different_flows}/
/packages/
│   ├── core/
│   ├── ui_kit/
│   ├── ui_domains/
│   │   ├── src/
│   │   │   ├── ui_{domain}/
│   │   │   │   ├── {DOMAIN}_KNOWLEDGE.md
│   │   │   │   ├── {flow}/
│   │   │   │   │   ├── {feature_name}/
│   │   │   │   │   ├── {experimental_feature_name}/
│   │   │   │   ├── {experimental_flows}/
│   │   │   │   │   ├── {feature_name}/
│   │   │   ├── ui_{experimental_domain}/
│   │   │   │   ├── {DOMAIN}_KNOWLEDGE.md
│   │   │   │   ├── {flow}/
│   │   │   │   │   ├── {feature_name}/
│   │   │   │   │   ├── ├── {feature_name}_{platform}/

Example code structure

/
/apps/
├── mobile_app_spring_edition // <- separate applications with new entry main, which can use different layouts, based on ui_domains package.
├── mobile_app_with_gamification/
├── mobile_app_with_ai/
/packages/
├── core/
├── ui_kit/
├── ui_domains/
│   ├── src/
│   │   ├── ui_payments/
│   │   │   ├── ui_payments.dart
│   │   │   ├── PAYMENTS_KNOWLEDGE.md
│   │   │   ├── pay/ // <- flow
│   │   │   │   ├── galactical_pay/ // <- experimental feature
│   │   │   ├── scan_and_pay/ // <- experimental flow
│   │   │   ui_ai_chatbot/ // <- experimental domain
│   │   │   ├── ui_ai_chatbot.dart
│   │   │   ├── AI_CHATBOT_KNOWLEDGE.md
│   │   │   ui_waiting_game/
│   │   │   ├── ui_waiting_game.dart
│   │   │   ├── WAITING_GAME_KNOWLEDGE.md
│   │   │   ui_picture_board/
│   │   │   ├── ui_picture_board.dart
│   │   │   ├── PICTURE_BOARD_KNOWLEDGE.md

Stage 5 — Scaling Application Domains

Team: 3–6 Developers

Lastly, let’s talk about what you can do if a feature grows too big, and you have enough resources to maintain it independently.

Since from the start, you have separated the domains clearly, you have several options:

Extract the domain as a package
Extract specific flows as a package
Extract specific features as a package

Abstract code structure:

/packages/
├── core/
├── ui_kit/
├── ui_{domain}/
│   ├── {DOMAIN}_KNOWLEDGE.md
│   ├── src/
│   │   ├── {flow}/
│   │   │   ├── {feature_name}/
│   │   │   │   ├── {feature_name}_{platform}/
│   │   │   ├── layouts/
│   │   │   │   ├── {layout_name}/

Example — moving ui_payments domain to packages:

/packages/
├── ui_payments/
│   ├── ui_payments.dart
│   ├── README.md
│   ├── PAYMENTS_KNOWLEDGE.md
│   ├── src/
│   │   ├── provider_pay/ // <- flow
│   │   │   ├── provider_pay.dart // <- feature
│   │   │   ├── ├── provider_pay_ios/ // <- platform feature implementation
│   │   │   ├── ├── provider_pay_android/
│   │   │   ├── ├── provider_pay_web/
│   │   │   │   layouts/
│   │   │   │   ├── desktop/
│   │   │   │   ├── mobile/
│   │   │   pay/ // <- flow
│   │   │   ├── qr_pay/ // <- feature
│   │   │   │   ├── qr_pay_feature.dart // <- feature
│   │   │   │   ├── ├── qr_pay_ios/ // <- platform feature implementation
│   │   │   │   ├── ├── qr_pay_android/
│   │   │   │   ├── ├── qr_pay_web/
│   │   │   │   layouts/
│   │   │   │   ├── desktop/
│   │   │   │   ├── mobile/

In any case, since on the previous stage you already have an independent data layer as a package + an independent ui_kit, your task is quite simple — treat all and plug them as APIs, and use them the same you use any Flutter widget or any pub package.

This way, you will still have non-broken dependencies (remember the combination: barrel files + clear and visible separated boundaries between data layers and ui, domains, flows and features), while maintaining flexibility to scale, research, and develop. Hooray!

Conclusion

In my opinion, if you are an indie developer, you can start small and grow. For a team with several developers, a designer, and analyst, and especially if you have a predefined design, it would be better to start from later stages, as you already have more resources at hand and can handle larger complexity.

But, also, I think this approach works both ways. For example, if your business is in crisis mode and your developer team is shrinking, basically that will mean that you do not have enough resources to keep huge infrastructure. In that case, in my opinion, it would be extremely helpful to go gently back to early stages and continue from there — that may save you from burnout. And don’t forget about your ideas in prototypes — maybe they will save your team one day:)

I hope this approach will give you inspiration to iterate, integrate, or to look at your projects from different perspectives and to give more quality to the end user.

If you found this useful, please share and leave your thoughts in the comments, and have an amazing journey ahead!

Thoughts about scalable code structure based on developer as user philosophy combined with iterative design using AI.

Flutter 💙 Cursor: setting up Background Agent

Anton Malofeev — Wed, 09 Jul 2025 22:25:44 +0000

If you prefer to use Jules (Google AI Agent ), check out this article.

Short story — Cursor introduced AI Agents which allows you to run any tasks in background the same way as in IDE with the same setup.
To give proper setup for AI Agent, we need to setup container the same way you would do for your own computer.

Let’s get started:

Open Cursor Settings (the panel may be placed in different place, since it depends on how you customized your interface, so you could use Command+Shift+P to open command panel and type “cursor settings”).
Open Background Agents panel

Give Cursor GitHub Access for your sepcific repository. Click Go To GitHub to allow access to.

Select your repository, to allow access to. Notice: for public repositories owned by organizations, you will have to fork the repository to your personal repositories.

After allowing access, make sure you click refresh and you should see Access Granted.

Click Base Environment and then Setup machine interactively.

Wait until you see the chat interface

Write to agent the command to install required dependencies. Use agent mode, so agent could verify setup and update other dependencies if needed.

I used the following script:

Hi. Please install Flutter & Dart.

Use the command below:

# Install Dart SDK (using apt, official Google repo)
sudo apt-get update
sudo apt-get install -y apt-transport-https wget
wget -qO- https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo gpg --dearmor -o /etc/apt/keyrings/dart.gpg
echo "deb [signed-by=/etc/apt/keyrings/dart.gpg] https://storage.googleapis.com/download.dartlang.org/linux/debian stable main" | sudo tee /etc/apt/sources.list.d/dart_stable.list
sudo apt-get update
sudo apt-get install -y dart
# Add Dart to PATH
export PATH="$PATH:/usr/lib/dart/bin"
# Clone Flutter
cd /opt && sudo git clone https://github.com/flutter/flutter.git -b stable
sudo chown -R $USER:$USER /opt/flutter
export PATH="$PATH:/opt/flutter/bin" && cd /workspace
flutter pub get

After Agent finished the job, click Take Snapshot

Add command flutter pub get or any script you usually use to get all dependencies in your project

After that, verify that everything works

That’s it! Now you can use background agent from any accessible ui point (from settings, from tab, pwa app or cursor website).

I hope this concept proves useful :-)

Please share your thoughts in the comments :-) This will help make this article visible to others and will be great support and motivation :-)

Thank you for your time and have a good day!

Anton

DEV Community: Anton Malofeev

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

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

FAQ as Natural Knowledge Compression

Structuring FAQs: The WHY vs HOW Pattern

DESIGN_FAQ.md: The WHY

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

When to use both

AI Agent Rules

HARD Skull / Rule create the FAQ xD

Docs

Specs

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

Reimagine Libraries management as Apps using Agentic Executable framework

Libraries as Agentic Executables

Why (The Problem)

How (The Solution)

Working principles:

Core Principles

Core Idea

Implementation Architecture

Workflow Overview

Installation workflow example:

Library Author workflow:

How to use it Today?

You are Developer:

You are Library Author | Maintainer:

Conclusion

Links:

How to conduct a useful technical interview (based on my personal experience (subjective opinion))

Flutter app AI centric architecture for small startups. Part 3 - Stages 3–5

Introduction

Stage 3 — Feature Iterations

Stage 4 — Scaling

Path 1 — Scaling to Other Platforms

Path 2 — Same App, Different Configurations

Stage 5 — Scaling Application Domains

Conclusion

Flutter 💙 Cursor: setting up Background Agent