Looking for work: CTO, Engineering Manager, Tech Lead

I recently wrapped up my sabbatical — time to look for a job.

If you need a technical leader who can both do the heavy lifting and steer the ship, get in touch — I'd be happy to chat. If you're building a startup, get in touch too.

The scope of the work and the degree of influence over the outcome matter more to me than the role's title. If you have a challenge or a problem with no clear solution (in your team, processes, or code), tell me about it. I'll get to the heart of it, and together we'll work out what the end result should look like and map out how to get there. If needed, we'll train / develop / hire a team. And what to call the role — we'll figure that out along the way.

My CV and GitHub.

You can find plenty of details about my 20-year adventure in software development (including 13 years in gamedev) on this blog. For example, there's a series of posts on my views on management, as well as my annual reports.

A few things worth knowing about me beyond what's in the CV:

Software development isn't just my job — it's also my hobby. That gives me a slightly broader perspective and more varied experience.
I see a product as an emergent system of people, "machines" and processes, and account for how they affect each other.
I believe in self-organization, autonomy, and transparency in how people and teams work.
I don't push others to do things I'm not willing to do myself — I always try to lead by example.
I do what needs to be done; I delegate what can be delegated.

What I'm looking for:

A small or medium-sized company building its own product. Let's say up to 200 people.
Fully remote work.
European time zones, or thereabouts.
Equity / stock options / profit sharing, with clear criteria for earning them.

If you're working on any of the following, it'll be easier for us to work something out:

Deep tech, R&D.
Non-trivial applications of LLMs, agents, and other AI.
Indie or experimental gamedev, tools for gamedev.
Procedural generation in the broad sense, including story generation, virtual influencers, etc.
Rust, including Rust for the web.

What I'm not considering:

In-office work.
Outsourcing or staff augmentation.
Companies operating in sanctioned countries in any capacity.
Products in ethical gray areas: crypto, gambling, dating services, etc.

If I sound like a good fit, drop me a few lines about your product, team, and the challenge you'd like my help with:

Telegram: t.me/Tiendil
LinkedIn: linkedin.com/in/tiendil
Email: a.eletsky@gmail.com

2026-10-14

Monsters & Memories player activity dashboard

The Monsters & Memories developers have made some of the game's metrics public, including subscriber counts. That kind of openness is rare in the industry and deserves a lot of respect. Sadly, the official statistics page shows only the current metrics, not the history. To fix that, I started collecting hourly snapshots of the data. One thing led to another, and four days later I'd vibe-coded a whole dashboard.

Dashboard: tiendil.github.io/monsters-and-memories-stats

Repository: github.com/Tiendil/monsters-and-memories-stats

Here's what you'll find:

Overview: online players, DAU, MAU, and subscribers.
Player activity: server populations, starting-area populations, and activity heatmaps by weekday and hour.
Engagement: how online player counts, DAU, MAU, and subscriptions relate to each other.
Trends: server growth, busiest hours, and starting-area activity (will be available after a few weeks of data collection).

Since the game has only recently entered Early Access, there isn't much history yet, but I hope the dashboard grows into a valuable resource for players and game developers alike.

P.S. Huge respect to the M&M devs. Who doesn't dream of making their own MMO, complete with elf girls and monetization? Real numbers help keep those dreams grounded.

2026-10-06

, , , , ,

Results of the 2024–2026 sabbatical

In 2023, Yuliya made a table of 1000 labs (!), chose one, moved to Germany, and started doing a PhD there. For a year, we flew back and forth between Poland and Germany, realized it was terribly inconvenient and expensive, so I quit Palta and, at the beginning of 2024, moved to Germany as a trailing spouse.

"What a great excuse to take another sabbatical", I thought, and so I did. Two and a half years later, it's time to ~~look for a job~~ take stock.

In this post, you'll find a full report on all the resting I managed to get done: what was planned, how the plans changed, what was achieved, and what was not.

In short: blog updated, 68 posts written, 20 books read, 4 new open-source projects built, more than 400 GitHub stars earned, feeds.fun made genuinely usable and ready for monetization, my own approach to management formulated, some weird but interesting courses on intellectual property development completed, AI figured out, coding agents coding, my wife's eye twitching.

A few links to better understand the post:

What are sabbaticals and why I take them.
This is my second full sabbatical; here is the report on the first one.

DepMesh — making file dependencies part of project architecture

Coding agents often need to answer practical questions before making changes, such as:

Which tests should be read before modifying this file?
Which specifications govern this module?
Which modules does this code import?
Which artifacts are affected by this specification change?
etc.

In other words, the agent must discover all dependencies between files and add them to the context to complete the task correctly.

To answer such questions, the agent must think, form a plan of action, execute it, and analyze the results. All of this consumes tokens, context, and time, without guaranteeing completeness and correctness of the result.

For example, the agent must decide how to search for each specific type of dependency. Sometimes, as in the case of import chains, the agent must read and parse the source code to understand which modules it imports, then generate paths to the corresponding files and read them — this is resource-intensive and inefficient.

The result of such "agentic search" is not guaranteed, the agent may forget to grep by function name and lose an important dependency, or miss a niche spec because it decided it is not needed in this particular case.

Moreover, for searching, the agent uses a bunch of tools, every one of which, by its very use, increases token consumption and eats up context. For the same task, the agent may choose different tools or call them with different parameters from time to time, which kills predictability and reproducibility of the result.

The standard ways to improve the situation are to integrate LSP or something similar as an agent tool, or to deploy one of the countless RAG systems. This helps, but does not solve all problems. For example, it does not guarantee completeness, minimality, and determinism of the result.

Meanwhile, since ancient times we have had a huge pool of utilities and libraries for file searching and source code analysis that can do the same work quickly and efficiently, without any LLMs. Each of them works much better than a probabilistic model in its specific area.

It would be great, I thought, to have a single abstraction over all these tools that provides the agent with a universal interface for extracting all dependencies between files (whatever you configure) and does not require it to think about what to search for or how to search for it.

So, it could be used, for example, like this:

> depmesh dependencies -r governed_by -r tested_by ./depmesh/cli/application.py

## governed_by

Specifications that apply to the artifact.

- @/specs/architecture/entities.md
- @/specs/architecture/errors.md
- @/specs/architecture/modules_layout.md
- @/specs/architecture/naming.md
- @/specs/architecture/static_analysis.md
- @/specs/architecture/tests.md
- @/specs/behavior/cli.md
- @/specs/behavior/file_paths.md

## tested_by

Tests that verify the artifact.

- @/depmesh/cli/tests/test_application.py

As a result, DepMesh was born.

Donna is ready to use

In February, I released Donna (the original post) — a CLI tool to run agent workflows as state machines and describe them in Markdown files.

Since I was developing it simultaneously with learning how to work with agents, Donna came out as an overcomplicated, versatile monster. It had many features, all of which were useful, but in total, they restricted the developers' environment too much and required too much time to learn.

So, after I gained some experience, I decided to follow the Unix philosophy and refactor a single monolithic tool into a set of smaller tools with single responsibility. New Donna is the first one of them (and the second is depmesh — I'll tell about it in a separate post).

New Donna exists to solve the control flow problems of agents in the long run. The logic is as follows:

Most development work is repetitive on the meta level: "run this tool, do something with the output, run another tool" or "implement function A, implement tests for function A, implement function B, …".
Some parts of that work require advanced reasoning, others do not.
Agents are ~~almost~~ good at reasoning, but not so good at keeping the whole process in mind, remembering what they did, what they should do and in which order, etc.
Therefore, we should separate the reasoning part from the control flow part — let agents focus on what they are good at, and keep the control flow to traditional automation tools.

Donna runs predefined workflows as deterministic state machines, so the agent can focus on reasoning, code generation, and other agentic work.