The death of search traffic is a chance for the return of old-school internet
There is steadily growing whining about the negative impact of AI answers in Google Search (and other AI tools) on website traffic. Stack Overflow seems dead already; Reddit is planning to wall itself off and hide posts behind a login.
According to platform owners, death is coming for everyone. Pretty much like it was when Google started showing snippets from posts directly in search results. Only scarier and more deadly.
As I see it, this is not a problem, but an opportunity.
- Obviously, communication platforms won't go extinct — people still need to talk with each other somewhere — it is a basic need.
- Last time (and the time before that, and the time before that), dinosaurs that refused to adapt died, while the young and energetic survived.
- Erecting artificial walls has never helped anyone. Except maybe for CEOs who could get another year or two of bonuses for hitting outdated KPIs before retirement.
So, we need to find a new model for platforms.
And to me, it is obvious: social platforms should be about social interaction. Not about silent feed consumption.
People who want to communicate on your platform simply cannot go anywhere else as long as they want to communicate within the ecosystem you created.
People who are (pro)active (that is, who interact with others) are worth more and matter more to advertisers — they are opinion leaders and a source of feedback. Targeting ads at them may be more profitable. They may also have more money to spend.
From that POV, public access to your content and its summaries in search are a good thing: they spread the word about you and bring (motivated) people to you.
Google, OpenAI, and others aren't your competitors, since they are not social platforms — they are personal tools. Google, for example, tried several times to become such a platform (Google+, experiments with Google Reader) and failed.
Optimization for views has enshittified the internet, exactly as you'd expect from over-optimization for the wrong KPI.
The death of passive user monetization gives the internet a chance to heal. And, of course, a chance for new major platforms to emerge.
In other words, we need to shift our KPIs from "how much content users consume" to something like "how actively users interact with each other" => make it easier for people to interact/communicate.
P.S. By the way, if a person posts something to the internet, they usually want their opinion to be seen by as many people as possible. Therefore, restricting access to a platform will only lead to a gradual decrease in the number of people who post/respond.
Looking for work: CTO, Engineering Manager, Tech Lead
One more time.
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.
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
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.
Results of the 2024–2026 sabbatical
Idiomatically spending a 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.