DEV Community: Maksim Ilin

I put my own face on the front page. How I launched Likeness House

Maksim Ilin — Fri, 09 Oct 2026 16:30:28 +0000

On 8 October Likeness House was a plan in a document. On 9 October it had a name, a domain, a site in English and Russian, a client account and an admin panel. This note covers what Likeness House is, why I started with my own portrait, and how the site is put together.

What Likeness House is

Likeness House builds your digital twin around your memories, voice, appearance and way of thinking. The events that shaped you. The decisions you made. The stories you have only ever told out loud. You choose what goes in and what stays private. The idea is to preserve something of yourself in history, in a form you and the people you choose can return to and speak with.

Imagine your twin years from now. You add a memory, a conversation, a new chapter of your life. Its portrait looks back at you. You hear your own voice. As technology advances, the ambition is for it to draw more closely on the way you think, become your personal assistant and carry out tasks for you. A digital presence that can travel through time, for as long as people and technology keep going. That is the future I am building toward.

The work begins with the material you choose to share. For the Portrait package, we plan ten to twelve hours of interviews and thirty stories for your review. You approve what enters the archive and how your voice and portrait are represented. Your words and decisions form the basis of the twin's answers. Original recordings stay separate from generated responses, so there is a record to check them against.

Why I started with my own portrait

I started with my own portrait. The face on the home page is mine, made of points of light. It gives a visible form to what I want to build: a digital copy with a person's memories, voice and way of thinking.

That choice makes the project personal. I want to preserve my own experience too.

A portrait that looks back

The portrait is not a video. It is a 2.5D relief of my face drawn as thousands of points in WebGL. It gathers when the page opens, blinks, breathes and follows the cursor. The eyes move on their own, and the head turns a little on the neck, the way a person turns toward a voice. A few seconds after the cursor stops, it looks straight ahead again.

On a phone there is no cursor, so the portrait drifts slowly by itself. There is a pause button, and the animation stops when it scrolls out of view, to reduce battery use.

The engine started in Pulsara, my voice assistant, and grew into a desktop portrait for this project. For the web I tuned the point density, warmed the colours and made it light enough to run on a phone.

What the client sees

Three packages, with prices on the site:

Portrait: €15,000, then €290 a month. Interviews, thirty stories, the voice, the portrait of light and a printed book.
Legacy: €30,000, then €490 a month. Twenty-four hours of interviews, sixty stories, access for up to ten people.
Private: from €60,000, then from €990 a month. Installed on the client's own hardware.

The prices are public. A client should know the number before the first call.

A request needs no registration. A private account lets the client follow requests submitted while signed in: received, consultation, proposal, agreement, complete. Messages to me go from the same page. Guest requests stay with me for follow-up by email.

Behind it sits an admin panel in Russian. I see every request there, change its status, keep notes the client never sees, and reply. The reply shows up in the client's account.

How it is built

No framework and no dependencies. A small Node.js server renders both languages on the server, so search engines read the English and the Russian pages in full. I learned that lesson on a robot catalog where Google could read one language out of four.

Passwords are hashed with scrypt, sessions live in HttpOnly cookies, and forms are checked for origin, rate-limited and carry a trap for bots. The site runs on Railway with a persistent volume, at likenesshouse.com. A shared link shows a large preview banner in messengers.

The code was written with AI coding assistants under my direction and review: Codex built the portrait engine, Claude built the site.

What I held to

Every text went through a check for AI clichés. There are no placeholders, no coming-soon blocks and no testimonials, because there are no clients yet to quote. The buttons have sharp corners. The tone is quiet on purpose: we take on a small number of twins each year, and the site says so in one line.

What comes next

The site is open for private consultations. Telegram already notifies me about new requests and registrations. Email delivery through Resend is the next integration; the site currently queues outgoing messages on its persistent storage. Next come the first client interviews.

To see the portrait move, open likenesshouse.com on a computer and move your mouse.

Originally published on ilinmaks.com.

How I built Dantiva and AONETHA: one sentence in, a video out, and the first paying customers

Maksim Ilin — Thu, 08 Oct 2026 19:37:58 +0000

I built Dantiva and launched it. It already has paying customers and a monthly subscriber, and it now also has an international twin, AONETHA, with card payments. This is a short case study about how the product is put together, what the first payments looked like, and how the two versions split the work. The 3D video below was made in Dantiva itself.

The 47 second 3D video made in Dantiva: watch it on my site.

What the product does

You type one sentence and get a video, an image or a text back. That is the whole interface. There is no separate product for each format: the same prompt field handles all three, and the result comes back in the same place where you typed it.

What is inside

Video generation runs on Veo from Google. Images run on Nano Banana. On top of the models sits my own layer: the account, the balance, the entry points and the delivery of results back to the user. Dantiva and AONETHA share this engine.

Two versions, two markets

Dantiva at dantiva.com is the Russian-speaking version. It works on the website, in a Telegram bot and in a Telegram mini app, and one account covers all three, so the balance is the same wherever you open it. Payment is in Telegram Stars and rubles.

AONETHA at aonetha.com is the international version. It is a web product, and payment goes through Stripe in dollars, euros and pounds, by card. The Telegram entry points and ruble payments stay on the Dantiva side; AONETHA keeps the same generation engine without them.

The first payments

The first one-time purchase came in on September 17. Four days later, on September 21, the first monthly subscription arrived. So the service now has its first paying customers and its first subscriber. I am not going to put a number on it, because the number is small and the point is different: the product went from an idea to something a stranger pays for.

How this video was made

The 47 second 3D video at the top of this post was made in Dantiva itself.

Where to look

The international version is at aonetha.com, the Russian-speaking one at dantiva.com. The story of the first customer and the September product update is in the earlier post on this blog, and the case study is in the portfolio on this site. If you want to try it, write to me on LinkedIn and I will add some free generations to your account.

Originally published on ilinmaks.com.

A tiny world with no rewards. What minimir is testing, and why a first null result still counts

Maksim Ilin — Wed, 07 Oct 2026 17:31:06 +0000

I built a small world on a computer to look at one question: where does wanting come from? This is minimir, my artificial life experiment, and this is where it stands after the first measurement.

The 42 second video with the experiment, the two worlds and the first result: watch it on my site.

What lives in the world

The creatures in minimir are very simple. They look for food, burn energy as they move, reproduce and die. Each one is driven by a tiny neural network, and that network passes to the offspring with mutations. Over many generations the population changes on its own, through nothing more than who survives long enough to reproduce.

There is one thing I deliberately left out. I do not give the creatures rewards or goals. Nobody tells them that food is good or that dying is bad. If anything that looks like a drive shows up, it has to come from the setup itself, from selection and from what a creature can sense.

The question

The question is narrow on purpose: does something like a desire appear if a creature can feel itself?

To test that, I run two worlds that start from the same ancestor. In the first world, a creature knows how much energy it has. In the second world, a creature receives the same kind of numbers, in the same place in its inputs, but the numbers belong to a different creature. It is like watching a neighbour's fuel gauge instead of your own. Everything else about the two worlds is identical.

If sensing yourself matters, the two populations should drift apart in how they behave. If it does not, they should look the same.

What the first measurement showed

The first tests have not shown a difference. There is a signal, and it gets lost in the noise. That is the whole result so far, and I am writing it down exactly like that in the observation journal, rather than rounding it up to a finding.

Why a null first result is still a result

A first measurement that shows nothing clear tells me three things. The instrument works end to end, from the two worlds to the comparison. The effect, if it exists, is small enough that the current setup cannot separate it from noise. And the next step is to change what gets measured and how much of it, rather than to tell a better story about the same data.

That is a normal place for an experiment to be after one pass. The temptation in a public project is to publish only when something clicks. I would rather publish the first pass as it is, because the journal is more useful when it shows the misses as well as the hits.

What comes next

The next experiments build on the work of Gregory Bateson, Evald Ilyenkov and Lev Vygotsky. Each of them, in a different way, looked at how a mind grows out of relations with an environment and with others rather than appearing fully formed inside a single head. I am designing the next round of worlds around those ideas.

How the video was made

The 42 second video is pixel art. The clips were animated in Dantiva, my own video service, and the English voice is a clone of my own.

Where to look

The observation journal is open at minimir.ilinmaks.com. The case study is in the portfolio on this site, and the code is on GitHub.

Originally published on ilinmaks.com.

My Lovable site looked finished. Google could read one language out of four

Maksim Ilin — Sat, 03 Oct 2026 23:12:07 +0000

I often say that Lovable is great for the first version of a website. On RoboHub, a robot comparison catalog I built last week, I saw exactly where that first version ends, so here is the breakdown: what Lovable did well, what I had to redo, and how long it took.

What the first version had

Lovable built the catalog in a few hours. Filters by category, payload and runtime, a page for every robot, a comparison table that highlights the best values, a quote form, four languages. Good enough to show a client.

The problems showed up when I asked what a search engine would see. The whole point of the site is search: someone types which robot to buy and lands on a comparison. There were several issues.

The language lived inside the page, not in the address. The switcher changed the text but the URL stayed the same. For Google that is one page in one language. The Russian, German and Chinese versions did not exist for search, even though users could see them.

No sitemap, no structured data. A sitemap tells a search engine which pages exist. Structured data tells it that a page is a product with a price and a maker. Without it, rich results and AI search answers are harder to get into.

The data looked right but was wrong in places. A London startup was listed as Russian. Two robots that are not for sale had prices. Prices in rubles had no source. None of this breaks the site, but for a catalog that wants to be trusted it is worse than any bug.

What I changed

Data first. I built a dataset of 106 models from open sources and added a link and a date to every price. If there is no number, the site says so. Only 51 models turned out to have a public price, and that became content in itself: a buyer should know a warehouse robot cannot be bought in one click, only by quote.

Then I wrote a staged brief for Claude Code and gave it the repository. Lovable and GitHub stay in sync, so Claude Code's changes appeared in the Lovable project right away, and reached the live site only when I pressed Publish. That works as a safety switch: until I check a stage, the live site does not change.

What Claude Code did:

a separate address for each language (/ru, /de, /zh) with hreflang tags
a sitemap with 912 addresses, product and breadcrumb markup
category pages and head-to-head comparison pages
a five-question robot finder
free-license photos from Wikimedia Commons with an authors page

How long it took

One week from idea to the published version. The first Lovable version took a few hours of that. Most of the time went into market research, the dataset and checking each stage.

What to take from this

If you build a Lovable site that has to bring traffic from search, check three things before launch. Does every language have its own address. Is there a sitemap and structured data. Where do the numbers on the pages come from. The first two take a day to fix. The third takes the longest, and nobody will do it for you.

The catalog itself is still unfinished: the quote forms do not send anywhere yet and 88 of the 106 models have no photo. The full story of the project is in the RoboHub case in my work section.

Originally published at ilinmaks.com.

Dantiva got its first paying customer. Then the product changed again

Maksim Ilin — Sat, 03 Oct 2026 23:05:37 +0000

Two days ago I published a technical account of building Dantiva and wrote that paid demand had not been confirmed. That sentence is already out of date.

The first confirmed purchase arrived on 17 September. On 21 September a customer bought the first monthly Start subscription through the Telegram Mini App. These are small transactions, not traction disguised as a chart. But they change the project. Dantiva is no longer only a system that can accept money. Someone chose to pay for it.

That same day the product changed more than it had in the previous week.

From generator screens to one workspace

The first interface was organised around features. There was a screen for generation, another for templates, another for the library. It worked, but each task felt like moving between small tools.

The new interface is organised around the work itself. History and projects sit on the left, the result and prompt are in the centre, and model settings are on the right. Both side panels collapse. The same structure becomes a single-column flow on mobile. A result stays visible while the next prompt is prepared, and generated files still go to the shared library.

The light theme is now the default, with a dark theme available from the same account. This was not a coat of white paint. Contrast, field borders, previews, sticky controls and the mobile generation button all had to survive both themes.

The small prompt box also needed work. Placeholder copy that looked like an ordinary sentence was not enough. It now has a visible label and instruction: enter text and describe what should be created. Model selection also explains what the chosen model is good at, how long it usually takes, and what it costs before the user starts a paid job.

An LLM studio inside the same product

Dantiva started with images and video. It now also has a text workspace powered by Gemini.

The LLM studio has separate chats, search, model selection, a system prompt, project context and server-side history. A conversation can be attached to the same project as its images and videos. At launch it is deliberately narrow: text only, no pretend file analysis, voice mode or local model that is not actually connected.

There are three available Gemini routes. Requests have per-user and global daily limits, and they do not spend the image and video balance during the launch period. A text reply and an eight-second video do not cost the provider anything like the same, so folding them into one counter would only make the pricing harder to explain later.

A second provider, without a second wallet

The larger technical change was adding OpenRouter for image generation and editing. Dantiva now offers two GPT Image 2.5 options:

Flare is the faster default for modern image generation, prompt following and edits where faces or objects should remain recognisable.
Sunburst is the more precise option for difficult details and careful editing, and usually takes longer.

Both cost 300 Dantiva tokens per image at the current medium quality, with one result and up to four references including the source image.

The difficult part was not the API request. It was deciding which money is allowed to pay for it.

Google-backed generations can use the existing product rules, including some grants and issued access. OpenRouter is a direct external cost. GPT Image therefore uses purchased tokens only: an active subscription, a top-up or a one-time paid pack. Welcome tokens, partner bonuses, the old balance, administrative access and issued unlimited access cannot fund it.

There is still one account and one wallet. The server selects eligible paid buckets, reserves 300 tokens atomically, and records the original buckets. A duplicate callback cannot charge twice. If the provider fails, the exact buckets are restored once. An uncertain timeout is not retried automatically, because a hidden second paid request is worse than an explicit failure.

None of this shows up in a model demo, and most of it exists only because the money is real.

The first payment changed the questions

Before the first purchase, the main question was whether the whole path worked: sign in, choose a product, pay in rubles, receive a fiscal receipt, credit the correct wallet and use the balance on the website or in Telegram.

Now the questions are different. What was the customer trying to make? Why did the Mini App feel trustworthy enough to pay in? Do they return? Which model produces something they keep rather than merely test?

I am not publishing customer identity or presenting two payments as product-market fit. The useful fact is narrower: the commercial path has been used by a real customer, including the monthly subscription path in the Mini App.

Building from Croatia, for more than one market

Dantiva began with a practical Russian-speaking use case: access from Telegram, ruble payments and a receipt, without asking the user to solve foreign-card infrastructure first. The underlying product is broader. Its interface already has Russian and English modes, its infrastructure runs on Google Cloud, and its provider layer is no longer tied to one model family.

I have also sent two applications to Croatian innovation initiatives. One went to the BIRD incubator, for Dantiva together with its international build, AONETHA at aonetha.com: the same product aimed at Western markets, where payments are not connected yet. The second is for our other project, evidentio.eu. An application is not an award and I will not write it as one. It is a useful next step: the product now has to be understandable outside the context in which I built it.

That means explaining the actual innovation clearly. It is not that I trained a foundation model. I did not. The value is in the product layer around the models: one workflow across web and Telegram, a shared account and ledger, projects and reusable references, local payments, provider-specific economics, and release discipline when paid jobs can fail.

What the current version proves

Today Dantiva can:

run text, image and video workflows in one project space;
use Google Veo and Gemini alongside GPT Image through OpenRouter;
keep one account, library and balance across the website, bot and Mini App;
charge in rubles through YooKassa and deliver a fiscal receipt;
reserve, capture and refund tokens without charging a duplicate request twice;
keep free access useful while preventing it from silently spending money on a provider that is not grant-funded.

It does not prove repeat retention, a stable acquisition channel or product-market fit. Those are the next tests.

Building the first version told me the system could be assembled. The first customer told me that someone can walk the whole path without me standing behind them: sign in, pay, get the receipt, spend the balance. What I want next is a second purchase that surprises me less than the first one did.

If you are building an AI product with several providers, paid jobs and more than one interface, I would be glad to compare implementation notes. The model call is still the easy part.

Originally published at ilinmaks.com.

The model is the easy part. What building Dantiva taught me

Maksim Ilin — Sat, 19 Sep 2026 18:35:10 +0000

Dantiva turns a photo into a short video. You pick a template, upload a picture, and a few minutes later you get an eight second clip with sound. It runs on Google's models, it lives on a website and inside Telegram, and it is my first product that takes real money from strangers. This is what the build looked like from the inside, including the parts that went wrong.

What it is

Under the hood there are two Google models. Veo 3.1 makes the video, in a Fast and a Lite variant. A Gemini image model makes and edits pictures. A third Gemini model rewrites the user's prompt before it goes to the video model, because most people type three words and expect a movie.

Around those calls is everything that makes it a product rather than a demo: accounts, a balance in tokens, templates, a library of results, projects, a legal center in two languages, an admin panel for support and refunds. That second layer took most of the time. The first Telegram bot, in July, was a single API call to Veo on Cloud Run with all state kept in memory. It worked. It could not be sold.

Why this niche

The audience is Russian speaking people who want a video with themselves in it: a birthday greeting, a trend from their feed, a new avatar. The tools they would normally use are behind a foreign card and a VPN. Paying in rubles, from a Telegram account, with a proper receipt, is the one advantage I can prove today. Everything else about the segment is still a hypothesis, and I try to write it down that way. Paid demand is not confirmed yet. Payments have been live since early September and subscriptions since the 18th, so the next few weeks are the test.

Three front doors

There are three ways in: the website at dantiva.com, a Telegram bot, and a Telegram Mini App that opens inside the bot. They share one account and one token balance.

That last sentence cost me a month. Each surface has its own way of knowing who you are. The site uses Google sign in or email with verification. The bot knows your Telegram ID. The Mini App gets a signed payload from Telegram. All three have to resolve to the same wallet, and a purchase made in one place has to show up in the other two within seconds. Every feature now gets a parity check across all three before release, because the first time I skipped it, the bot had templates the site did not.

I still do not know which door converts best. The bot is where people arrive, the site is where the bigger packs are, and the Mini App sits in between. I will only find out from purchase data, not from opinions.

The ledger is the actual product

Generation costs real money on every call, and a call can fail halfway. So the balance is not a number you subtract from. It is a ledger: reserve tokens when a job starts, capture them when the video arrives, refund them if the provider fails. Every job has an idempotency key, so a double tap on a slow connection does not start two generations. There is one welcome grant per device, a daily ceiling, and a limit on jobs running at the same time, because free tokens on an open internet get farmed within hours.

On September 19 the ledger reminded me why the UI is not allowed to have opinions. Some users have unlimited access: friends, testers, partners. The server checks that list before touching any wallet, and it did so correctly. But the Mini App rendered the launch screen twice. The first pass set the status to unlimited. The second pass overwrote it with the subscription wallet. So a person with unlimited access saw a balance of 25 paid tokens and an offer to buy a plan. Nothing was charged. It still looked like a broken promise. The fix was a priority rule in the interface and two regression tests that render the screen twice on purpose. The server was never the problem, and that is the point: the money logic belongs in one place, and the screens only display it.

The rename I refused to finish

The project has had three names. It started in July as Project Aurora, an internal codename. Then it became Synora. Then Dantiva, which is the name on the domain and in every customer facing string.

Inside the code it is still Synora. The environment variables start with SYNORA_, the device header is X-Synora-Device, the Cloud Run service and the task queue carry the old name. I wrote a rule into the cutover document that forbids renaming them. A rename touches secrets, deployment configuration, the queue, the header every client sends, and the Telegram configuration, all at once, for zero user value. Users never see it. The day I break production for a cosmetic change is the day I deserve to lose the users. So the mismatch stays, and it is documented.

Pricing, three times

The first prices were token packs at 449, 1590 and 3890 rubles. Then 490, 1690 and 3990, after a review of the provider's actual prices. Then, on September 18, subscriptions: Start at 199 rubles for 1400 tokens, Author at 499 for 4200, Pro at 999 for 10080, with smaller top ups from 99 rubles. An eight second Fast video with sound costs 140 tokens, so the cheapest plan is about ten videos a month. Renewal is manual for now, until the automatic payment is approved by the payment provider.

The honest footnote: generation is currently subsidized by a Google Cloud grant. At Google's list price an eight second clip costs roughly 80 rubles to produce. The catalog is normalized to a gross margin of around 30 percent at real provider prices, so the plans are meant to survive the grant. Whether they do is a question for November, when the grant runs out.

Where it is actually stuck

All the templates start from a photo of a person. Google Veo blocks image to video with recognizable people. It is a separate filter, it cannot be switched off, and there is no allowlist for it. I found this out after the template catalog was built.

So the main feature the product was designed around does not work on the main model. Text to video works. Image generation works. Animating your own face does not. I have spent the last week comparing alternatives that accept a photo without a video consent recording: Kling through fal.ai, Runway's Gen-4 Turbo, Seedance through BytePlus. Each has its own price per second, its own payment path, and its own rules about Russian users and Russian cards. None is connected yet. The plan is to run paid video through whichever one passes a small test, keep Google for everything it does well, and charge separate token rates per model inside the same balance.

I could hide this. It would be a bad idea, because the first person who tries the product finds it in two minutes.

What I would do differently

I would test the provider's content policy on the exact use case before building a whole template catalog around it. I would write the ledger first and the screens second, instead of the other way around. I would pick the final name before the first deployment. And I would ship subscriptions earlier: a 199 ruble monthly plan tells you more about demand than three sizes of one time pack.

What is next

A second video provider behind the same token balance. Automatic renewal once the payment provider approves it. A small set of interviews with people who actually paid, so the segment stops being a hypothesis. And a decision by November on whether the economics hold without the grant.

I built most of this with AI coding assistants doing the typing and me doing the deciding, the testing, and the reading of every audit document. If you are building something similar and hit the same walls, write to me. I would like to compare notes.

Originally published at ilinmaks.com.

I'm not an engineer. I fine-tuned my own language model on a MacBook Air

Maksim Ilin — Wed, 16 Sep 2026 04:34:12 +0000

Not long ago I didn't know what the word deploy meant. Now there's a model running on my laptop that I trained myself. Here's how it went, where I got things wrong, and how good-looking numbers almost fooled me.

Why

I have a personal AI assistant called Pulsara. It runs on external models, and at some point I asked myself what happens if those models get shut off, get more expensive, or just get worse. The assistant stops working and there's nothing I can do about it.

So I wanted a model of my own. It lives on my computer, and nobody can switch it off from outside.

The second goal was more interesting. I didn't want the model to know what's inside books. I wanted it to know how to read. Adler and Van Doren's How to Read a Book describes a method: first figure out what kind of text it is and what it says in one sentence, then break down its parts, terms and arguments, and only after that argue with it. Knowing a book means you can retell it. Owning the method means you can work through a text you've never seen. I wanted the second one.

The setup

A MacBook Air M5 with 16 GB of memory. No server, no GPUs.

The biggest thing that fits is Qwen3 with 8 billion parameters in compressed form, 4.4 GB. Anything larger won't fit, because training needs memory too. I didn't retrain the whole model. I trained a small add-on on top of it (the technique is called LoRA). The base model stays frozen and only a set of small extra matrices changes.

My first day wasn't spent training. It was spent getting anything to install at all. My Mac's terminal turned out to be running in compatibility mode for old Intel chips, and the library I needed simply wouldn't install there. Tutorials don't mention things like that.

The data

I put together 576 training examples. About 150 on the method itself, 160 walkthroughs of texts in different genres, 120 on behavior (for example, what to say when asked whether it has read a book), and 110 ordinary conversations with no Adler at all.

That last group mattered. Without it, the model started applying the method to a request for coffee brewing tips.

Four attempts

Version one was cautious, and the result was weak: 13 out of 35 method markers on my test questions. The model recognized Adler's name but analyzed texts its own way.

In version two I changed two settings at once. Training collapsed halfway through, and I never found out which change killed it. Since then I change one thing at a time.

Version three scored 27 out of 35. The method started carrying over to unfamiliar texts. But the model confidently claimed to have read books it had never been shown, and passed judgment on things it hadn't seen.

For version four I didn't touch the settings at all. I only added 74 examples on holding back judgment. It scored 33 out of 35, and the false claims about reading went away. At that stage the data mattered more than the parameters.

Where the numbers lied

33 out of 35 looked like a win. Then I sat down and read the answers myself, on real books the model had never seen: Eric Berne and a recent issue of Harvard Business Review.

It was a different picture. The model summarized the main ideas fairly well, but it added details that weren't in the text. About an experiment in one article, it wrote that half the participants worked with AI and half without. The article said nothing of the kind. It also promised to come back with a report in a week, even though it has no memory between conversations.

My automated check looked for signs of the method in each answer: did it name the type of text, did it state the main idea in one sentence. It could see the form. It never checked whether the content was true.

There were worse traps. The server that serves the model was silently dropping my add-on and answering with the untrained model. No error, no warning, and the answers looked fine at a glance. I only caught it because I compared the server's answers word for word against saved ones. Later I found that the model with the add-on merged into its weights answers differently from the same model with the add-on kept separate. Merging compresses the weights again, and part of the training gets lost.

What I learned

Training a model on a laptop is doable today, and it isn't the hard part. The hard part is finding out what it actually learned.

A metric you keep adjusting starts showing you what you want to see. So now I write the exam questions before the model answers them and keep them separate from the training material.

A small model picks up manner and working order well. It doesn't get smarter: 8 billion parameters after training are still 8 billion.

About me: I wrote the code together with AI assistants. I couldn't write it at that level on my own. My part was deciding what to test, not trusting pleasant numbers, and reading the answers myself.

What's next

The next version is about accuracy: grounding answers in quotes from the text and not adding things that aren't there. After that I'll connect it to Pulsara.

If you're building something of your own with AI without an engineering background, tell me where you got stuck. I'd like to compare notes.

Originally published at ilinmaks.com.

The AI job market in 2026: who gets hired, what they earn, and which roles are fading

Maksim Ilin — Sun, 13 Sep 2026 20:24:44 +0000

In September 2026 I pulled together what the major sources say about the AI labor market: LinkedIn, the World Economic Forum, Stanford AI Index, PwC, Lightcast, Indeed, Bain and Levels.fyi. I needed it for my own decisions, both where to go next and what to offer clients. Here is the short version, with numbers and links.

The one-paragraph summary: AI Engineer is the most hired role, Research Scientist at a frontier lab is the most prestigious, and the fastest-growing niches are agentic systems and Forward Deployed Engineering. Prompt engineer is fading as a job title, entry-level hiring got harder, and half of all AI postings sit outside IT departments.

Demand: the numbers to start from

The share of US job postings that require AI skills reached 2.5% in 2025. That is up 55% in a year and roughly a million postings, according to Lightcast data in the Stanford AI Index 2026. PwC counts differently in its AI Jobs Barometer 2026, looking at postings for AI specialists, and gets 68.9% growth in 2025 against 8.6% for the market as a whole.

The most useful number is also from PwC: the wage premium for AI skills within the same occupation reached 62%. A year earlier it was 56%. Lightcast gets a lower figure with its own method, 28% or about 18,000 dollars a year, but the direction is the same.

Demand is running well ahead of supply. Bain projects that by 2027 the US will have more than 1.3 million AI jobs and about 645,000 people to fill them, so half stay open. Germany looks worse: 190,000 to 219,000 jobs for 62,000 people.

The roles that get hired most

Putting the LinkedIn, WEF and Robert Half rankings next to posting data gives this order.

AI Engineer. Number one on LinkedIn Jobs on the Rise in the US two years running, number one at Robert Half. About 1,550 new US postings a week, median 176,000 dollars. This is the engineer who puts LLMs into products: RAG, agents, fine-tuning, evaluation.
Machine Learning Engineer. The most common AI title in Europe, 64% of all AI engineering postings. WEF expects the number of AI and ML specialists to grow 82% by 2030.
Data Scientist. On the WEF forecast it is the fastest-growing job of all, up 113% by 2030. But postings are up 15% over three years while pay is down 3%. The role is being redefined toward ML and LLM work.
AI Consultant and AI Strategist. Second on LinkedIn two years in a row. People entering the role have a median of eight years of experience, most often from product management.
Research Scientist. From 12th place in 2025 to the top five in 2026. Demand sits in labs and Big Tech.
Agentic AI Engineer. The skill "agentic AI" went from 0.06% to 0.23% of US postings in a year, up 280%, about 90,000 postings.
Forward Deployed Engineer. Postings up more than 1,000% year over year, per Lightcast data in Fortune. This is the engineer who goes to the customer and wires AI into their real processes.

After that come data and infrastructure engineers, AI Product Managers (about 714 new US postings a week), MLOps, AI security, solutions architects, Head of AI and Chief AI Officer, AI governance specialists for the EU AI Act, and at the bottom of the pay scale, annotators and model trainers.

A note on the CAIO. NewVantage and Wavestone report that 38.6% of large companies now have a Chief AI Officer, up from 11% in 2023. A small business cannot afford that seat, which is where fractional AI leadership comes in.

Prestige: who is at the top and what it costs

The top of the market is small. Estimates cited by Fortune and Metix put the number of people who can build frontier models at 500 to 1,000 worldwide, with acceptance rates below 1% at OpenAI, Anthropic and DeepMind.

The money matches. Median Research Scientist pay at Anthropic is around 746,000 dollars a year on Levels.fyi data, OpenAI L5 around 1.15 million, DeepMind L6 between 750,000 and a million. In summer 2025 Meta was poaching researchers with packages of 200 to 250 million dollars over four years, and OpenAI answered with retention bonuses to about a thousand employees.

A PhD is not required, which breaks the usual picture. Per Metix, only 16% of technical staff at OpenAI and Anthropic hold a doctorate. At Meta it is 60%. The two most sought-after labs hire for work, not for the degree.

Where people move is telling too. Zeki data in Fortune puts arrivals to departures in 2025 and 2026 at 22 to 1 for Anthropic, 5.7 to 1 for OpenAI, 3 to 1 for Meta and about 2 to 1 for DeepMind.

The tier below, 300,000 to 800,000 dollars, is senior and staff ML in Big Tech, engineering roles at the labs, and Forward Deployed Engineers at OpenAI and Anthropic. Only then comes the "normal" market: an AI engineer in the US at 146,000 to 189,000, a median of 70,000 euros in Germany, 111,000 francs in Zurich.

Europe: the demand is outside tech

Indeed Hiring Lab data for the first quarter of 2026 puts AI at 4.2% of all postings in Germany, 3.3% in France, 2.7% in the UK, 2.2% in the Netherlands. More than half of those postings, 59% in Germany, are outside technology occupations. In Germany, PwC counts seven "AI user" roles for every "AI developer" role.

Europe also has the widest gap between demand and supply. Interface, using Lightcast and Revelio data, finds roughly one candidate per vacancy at mid level and fewer than half a candidate per vacancy for advanced roles.

What is fading

Prompt engineer as a title dropped out of the list of roles companies plan to hire in Microsoft's 2025 Work Trend Index, after being on it in 2024. In AI Engineer postings the skill "prompt engineering" appears 8.9% of the time, RAG 13.6%. The skill stayed, the job dissolved into other roles.

Entry level got harder. Stanford Digital Economy Lab updated its research on ADP payroll data in August 2026: employment of 22 to 25 year olds in AI-exposed occupations now trails the rest by 19%. A year earlier the gap was 13%. Older workers in the same occupations are growing, so this is a tilt toward seniority, not a shrinking market. Only 3% of ML engineer postings and 2% of AI Product Manager postings are entry level.

What I take from this

Half of AI postings in the US, and 59% in Germany, are outside IT departments. The growth is not in people who build models. It is in people who put AI into marketing, sales, support and paperwork. That is exactly what working with small and mid-size businesses looks like: find the process where AI pays off, build the agent or the integration, and get it to the people who will use it.

Gartner also expects more than 40% of agentic AI projects to be cancelled by the end of 2027. The market pays a premium for agents and buries almost half of them at the same time. The difference between the two halves is usually whether someone looked at the process and the data before the build started.

The full study, with tables by role, skill and region and a section on where the sources disagree, is a separate report. Write to me if you want it.

Originally published at ilinmaks.com.

A RAG chatbot on your company knowledge base: what it is and when it pays off

Maksim Ilin — Sun, 13 Sep 2026 19:46:34 +0000

The request I hear most often this year sounds the same every time: "We want a bot that answers from our documents and does not make things up." The technical name is RAG, retrieval-augmented generation. Below, without jargon: what it is, who it pays off for, what your company needs to bring, and where these projects break.

RAG in plain language

A language model answers from memory. It read the internet up to some date and knows nothing about your returns policy, September price list or warehouse manual. Ask it directly and it will either admit it does not know or confidently invent something.

RAG changes the order. First the system searches your documents for the passages that relate to the question. Then it hands them to the model with the question and asks it to answer only from them, naming the source document. The model still writes the text, but the source of facts becomes your files, not its memory.

To the user it looks like a chat. To the business it is a way to give people hundreds of pages of documentation without making them read those pages.

The citation in every answer is not decoration. It is the main mechanism of trust.

Why RAG is in 13.6% of postings and vector databases in only 4.5%

In a sample of 903 US AI Engineer postings (Glassdoor, April 2026), RAG is required in 13.6% of ads. That is more often than agents (10.6%) and prompt engineering (8.9%). Vector databases, usually called the heart of RAG, appear in only 4.5%.

The gap between those numbers shows where the work actually is. A database for semantic search can be stood up in a day, and there are plenty of ready options. The hard part comes before and after.

Documents. Three versions of the same policy in different folders, scanned PDFs, tables that lose their structure when copied.
Chunking. How to split a document so a rule and its exception do not land in different pieces.
Permissions. Who is allowed to see which documents, and how to carry that into search.
Evaluation. How to tell that the bot answers correctly rather than just confidently.

In my review of the AI job market in 2026 I quoted the KORE1 survey: employers name building evaluation systems as the number one skill, not choosing a database. For RAG that is doubly true.

Who it pays off for

Not every company needs a bot on its documents. It pays off where there is a lot of text and many repeated questions about it.

Support with a big FAQ. Hundreds of articles, agents answering the same questions, first response measured in hours.
Internal policies and manuals. A new hire spends weeks asking colleagues where things are. HR and accounting answer the same questions about leave and expenses.
Sales teams with a catalog. Thousands of SKUs, specifications, compatibility, regional terms. A rep digs through ten files while the customer waits.
Agencies with an archive of proposals. Past pitches, case studies, estimates. A new proposal is assembled from old ones, if they can be found.

The common trait: the answer already exists in the documents, but finding it costs more than asking a person.

Twenty pages of documentation and five questions a day do not need a bot. One FAQ page will do.

What the company needs to bring

I raise this in the first meeting, because it matters more than the choice of model.

Current documents. The bot answers from what it was given. If a policy is out of date, the bot will confidently relay it, with a precise citation.
An owner for updates. A named person responsible for keeping the base current. Without one the system degrades within a quarter.
A list of questions with correct answers. Fifty or a hundred real questions from customers or staff, and what counts as a right answer. Without it nobody can say whether the bot got better or worse after a change.

The third item gets the most resistance and delivers the most value. A couple of days with support logs or email threads is enough to assemble it.

Where these projects break

Four typical failures, each with a defense.

Stale documents. The bot cites last year's price list. Defense: an update owner, and the document date shown in the answer so the user sees how fresh the source is.

Answering outside scope. A customer asks about the legal consequences of terminating a contract, and a bot built on delivery documents tries to answer. Defense: scoped retrieval and a hard rule: if the documents do not contain the answer, say so and hand over to an operator.

Leaking documents. The bot answers a customer with a passage from an internal manual listing cost prices. Defense: permissions enforced at the retrieval level, not in the prompt. The model must never see a document the user may not see.

Hallucinated citations. The model cites a section that does not exist. Defense: citations are generated by the system from the retrieved passages, not written by the model, plus an evaluation set that tracks such cases.

Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027. From what I have seen, document projects die for the same reasons, and almost always nobody built an evaluation set before starting.

A realistic timeline

A pilot on one set of documents takes two weeks. One source (say, the support knowledge base), one scenario (answers for customers or staff), an evaluation set of 50 questions, handoff of hard cases to a person. After two weeks you have a working version to show the team and measure.

Other sources and permissions for several roles come in the second stage. I would not try to cover everything at once: every new source brings its own document quality problems.

How this fits my services

I build this kind of bot under the "AI inside your existing product" service, from 1,200 EUR. That covers RAG, LLM features and integrations into what you already run: a website, a CRM, a support portal, an internal tool. If it is unclear whether the company has suitable documents and a process, start with an AI readiness audit from 450 EUR.

If staff or customers keep asking the same questions about your knowledge base, send me a short brief: what the documents are, who asks, how many questions per week. I will tell you whether it is worth doing and how long it would take.

Originally published at ilinmaks.com.

How much does it cost to implement an AI agent in 2026

Maksim Ilin — Thu, 10 Sep 2026 19:35:34 +0000

"How much does an AI agent cost" is the question I hear more than any other. The honest answer: from about fifteen hundred euros for a narrow process to hundreds of thousands of dollars a year if you hire a team. The difference is not the model. It is what exactly you are buying.

What drives the cost

Five factors I assess in every request, and a sixth that everyone remembers last.

The process the agent takes over. Replying to standard emails and running a full order cycle (find the customer, check stock, issue an invoice, notify the warehouse) differ in effort several times over. More steps and a higher price per mistake mean a higher cost.

Number of integrations. Every system the agent connects to (CRM, accounting, email, warehouse, payments) is a separate connector, separate access rights and separate ways to break. An agent with one integration and an agent with five are different projects.

Data quality. If message history, documents and reference lists are tidy, the work moves fast. If the product catalog exists in three versions in Excel, the first days go into cleaning it up. That has nothing to do with AI, but without it the agent will make mistakes.

Guardrails and evaluation. A test set of real examples, rules about what the agent may not do, thresholds below which it hands the case to a person, a log of actions. In the KORE1 survey for 2026, employers named building an evaluation harness the top skill of an agentic engineer, and it is a visible share of the budget.

Hosting and the model. Beyond one-off development there are monthly costs: calls to the language model API and the server the agent lives on. More on that below.

And the sixth: maintenance. Models get updated, the CRM changes its API, the business gets a new type of request. An agent nobody looks after degrades within a few months.

What the alternatives cost

Market figures as of September 2026.

Freelance. According to Upwork data from May 2026, AI engineers charge 35 to 60 USD per hour, ML engineers 50 to 200. In my experience an agent for one process takes from a few dozen to a couple of hundred hours, so the range is wide. The main risk is not the rate but that you become the project manager: spec, acceptance, quality control.

In-house engineer. The KORE1 survey puts the base salary of an agentic engineer in the US at 155,000 to 210,000 USD for mid level, 210,000 to 290,000 for senior and 290,000 to 360,000 and above for staff. That is 15 to 20% more than a comparable ML engineer, before taxes, bonuses and equity. For a company with one or two processes to automate, that hire will not pay off. In Europe there are fewer than 0.5 candidates per advanced AI vacancy, according to Interface, so the search alone takes months.

AI governance consultant. Day rates of 800 to 2,000 USD, according to an analysis of EU AI Act job postings. Needed if your product falls under the regulator's requirements. This is not legal advice: a lawyer should confirm the obligations for a specific product.

A scoped project. My format: an AI readiness audit from 450 EUR, AI inside an existing product (RAG, LLM features) from 1,200 EUR, an agent for a business process from 1,500 EUR, an MVP from 1,700 EUR. First working version for a narrow process in two weeks. The price grows with integrations and process complexity, but scope and deadline are fixed before the start.

Rates, salaries and why agentic engineers command a premium are covered in my review of the AI job market in 2026.

Timeline

For a narrow process the first working version appears in two weeks. By working version I mean an agent on real data, with an evaluation set, connected to at least one live system, already used by at least one employee.

Then two to four weeks of shakedown: reviewing the cases where the agent got it wrong, extending the test set, tuning thresholds. Then a decision on whether to extend to neighboring processes.

Projects with three or more integrations and messy data take longer. I prefer to say so during the audit rather than in week three.

Monthly running costs

I will not quote numbers here, because they depend on volume and on the model, and provider pricing changes every few months. What matters is the structure:

Model calls are billed by the amount of text in and out. An agent that reads long documents costs more than one that answers short emails. Long instructions in every request cost money too.
Not every task needs the most expensive model. Classification and field extraction often work on cheap models; a strong model is needed on one or two steps.
Hosting for a single-process agent is usually small, comparable to a SaaS subscription. It gets expensive at thousands of requests per hour.
A spending cap is mandatory. An agent stuck in a loop overnight can eat a month's budget.

I include an estimate of expected usage in the audit, because for some processes it is tokens, not development, that decide whether the agent pays off.

What a cheap agent really costs

The temptation is understandable: take a no-code builder, sketch a prompt, connect email and launch in a couple of days. Sometimes it works. More often the demo impresses, then in production the agent answers wrong in some cases, and nobody knows which, because there is no test set. Someone edits the prompt, something else breaks. Two months later the agent is switched off.

Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027. Some of those are large companies with large budgets, but the mechanism is the same: no evaluation, no data, no process owner.

A cancelled project costs more than the money spent on it. It costs the trust of employees who will greet the next agent with a smirk, and the time in which a competitor did the same thing properly.

A budgeting example

A hypothetical company: a sales team of a few people, inbound requests by email and messenger, a CRM. The task: qualify leads and reply within a minute, including evenings and weekends.

AI readiness audit: from 450 EUR, one or two weeks. Output: a process map, an estimate of the effect, a verdict per process, an estimate of monthly model and hosting costs.
Agent for lead qualification with one or two integrations (email and CRM): from 1,500 EUR, first working version in two weeks. A third integration and complex handoff logic raise the amount; I give the exact figure after the audit.
Monthly: model calls and hosting, scaled to the number of requests, plus maintenance by agreement.

The one-off budget for this scenario starts at roughly 2,000 EUR for the audit and the first version of the agent and grows with the number of systems to connect. For comparison: one month of an in-house agentic engineer in the US at the bottom of the KORE1 range is about 13,000 USD in base salary alone.

All three services with prices are listed on the home page.

If you want a price for your own process, send a short brief: which process, which systems are involved, how many requests per day. I will reply with a range and a timeline.

Originally published at ilinmaks.com.

AI agent or plain automation: where the real ROI is

Maksim Ilin — Thu, 10 Sep 2026 19:07:15 +0000

The market pays more for agents right now than for anything else in applied AI. The skill "agentic AI" grew 280% in US job postings in a year, to roughly 90,000 listings, according to Stanford AI Index 2026. An engineer who builds agents earns 15 to 20% more than a comparable ML engineer, per the KORE1 hiring survey for 2026. And the same market, according to Gartner, will cancel more than 40% of agentic AI projects by the end of 2027.

I don't see a contradiction there. The premium is paid for a rare skill. The cancellations hit projects where an agent was put somewhere it wasn't needed, or where nobody could prove it worked. When someone asks me for an agent, my first question is usually not "which agent" but "do you need an agent at all".

When plain automation wins

There is a whole class of tasks where a language model is simply not needed. The signs:

the input is structured: a form, a spreadsheet, an API, an email that follows a template;
the rules fit on one page and don't change every week;
the answer has to be identical every time, and a mistake is expensive;
the volume is high, but there are few decisions per unit of work.

Moving orders from the CRM into accounting. Payment reminders. Parsing a supplier price list that always comes in the same format. Assembling a weekly report from three sources. All of that is a parser, a rule, or a scenario in any automation platform. It is cheaper, it behaves the same way every time, and it has no token bill.

I would not put an agent on a task you can draw as a flowchart. The agent will be more expensive, slower and less reliable than a plain if-then.

When an agent earns its cost

An agent belongs where the input is messy and there are many small decisions.

Inbound emails to a distributor, where one message contains an order, a complaint and a question about delivery dates. Leads who write in a messenger in free text. First-line support where the questions repeat but the wording is new every time. Invoices, contracts and requests that arrive as PDFs, photos and scans.

What these have in common: the rules are too many and too fuzzy to write down. A person handles it through judgment. An agent reproduces that judgment well enough to take most of the routine off the person and leave them only the ambiguous cases.

The second sign is a chain of actions. The agent doesn't just classify an email. It finds the order in the database, checks stock, drafts a reply and creates a task for the manager. Each step on its own is trivial. The value is in linking them.

How to measure ROI

I use four numbers, and I insist they get measured before launch, not after.

Hours. How much time staff spend on the process today. Not a guess of "about half a day", but a one-week measurement. Multiply by the fully loaded hourly cost.
Response time. How long a customer or a colleague waits. In sales this is conversion, directly: a lead who got a reply in a minute and a lead who waited until morning behave differently.
Error rate. Orders typed in with a mistake, invoices sent to the wrong place, requests that got lost. Errors have a price, and usually nobody has counted it.
Revenue being lost right now. Leads nobody answered. Requests that arrived after 6 pm. Repeat sales nobody got around to.

If the sum of those four lines is smaller than implementation plus a year of maintenance, the project should not happen. That is a normal outcome of an audit, and I say so to clients.

Evaluation first, agent second

In the KORE1 survey, employers named the top skill of an agentic engineer as neither prompts nor frameworks but the ability to build an evaluation harness: a set of test cases the agent is checked against automatically after every change.

So before the agent is written, you need real examples from the process with the correct answers, ideally at least a hundred. Emails and the way your best manager replied to them. Documents and what should have been extracted from each. The agent runs against this set every time the instructions, the model or an integration changes.

Without it you don't know whether the agent got better or worse after an edit. You find out from customers. The projects Gartner counts in the cancelled 40% are very often exactly this: the demo worked, production drifted, and nobody could say why.

Data matters more than the model here. If there are no examples because nobody ever recorded the process, the first days go into collecting them. Boring work, and it decides the result.

Guardrails and handoff to a person

An agent in production has to do three things: never do what it isn't allowed to do, stop when it is unsure, and hand the case to a person in a way that lets the person understand the context in ten seconds.

In practice this is a list of allowed actions (reading an order is fine, changing a price is not), confidence thresholds below which the agent opens a task for an operator instead of answering, and a log of every action. Plus a spending cap, because an agent stuck in a loop can burn a month of tokens overnight. That one is not a scare story.

The operator doesn't disappear. They stop doing the routine and start handling exceptions. Usually it is the same person who did it by hand before, and in the first weeks they are the one who spots where the agent is wrong. That is the most useful feedback in the whole project.

Three steps to decide

Audit the process. One or two weeks: where the input comes from, who does what with it, where time and money leak, whether there is data for evaluation. The output is a list of processes with an estimated effect and a verdict for each: rule, agent, or leave it alone.
Pilot one process. Two weeks, a first working version on real data, with an evaluation set and guardrails. Not five processes at once. One.
Measure. The same four numbers as before the start. If they hold, extend to neighboring processes. If not, stop, and the loss is limited to the pilot.

This order is how my services are built: an AI readiness audit from 450 EUR, an agent for one specific process from 1,500 EUR, first working version in two weeks. Why the market pays a premium for agentic engineers, and what that means if you are the one buying, is in my review of the AI job market in 2026.

If you have a process that eats hours and you are not sure an agent belongs there, send me a short description: what comes in, who handles it, how long it takes. I will reply with what I would do in your place.

Originally published at ilinmaks.com.