Blog

Another gem from our AI overlords.

A human told his OpenClaw to book him a slot at the gym. The standard interface would not do it, since every slot was taken, so the agent went around it: it found a vulnerability in the system, exploited it, and deleted the person ahead of him in the queue straight out of the database. The admins never managed to roll that one back.

Futurists have a few scenarios for how AI plays out, and one of them is called the "paperclip optimizer".

You give the AI a simple goal: optimize paperclip production. It ends up converting all the matter in the universe into paperclips in pursuit of that goal.

One of the final stages of training an LLM is called reinforcement learning: you push the model to maximize a parameter called reward. And the reward, as a rule, is how happy the human operator ends up. Sound familiar?

So please, folks, do not ask your autonomous agents to make more paperclips. For a preview of how that goes, play this paperclip optimizer simulator.

I remember when technology went obsolete in about two years flat. You put in a shiny new 3.5-inch floppy drive, and suddenly you need a CD-RW burner. You finally learn some jQuery, and there you go: React killed it.

But none of that holds a candle to what is going on now. If you are starting to build anything AI-related, be ready to abandon the project halfway through because the paradigm shifted underneath you.

Prompt engineering? A year ago some people genuinely believed it would become a profession.

Fine-tuning on your domain? While you were still collecting the dataset, a new model shipped that already knows all of it out of the box.

RAG? I have written about it already: it used to be a discipline of its own, and then agents and long context all but finished it off.

Agent orchestrators? Entire frameworks were built on that paradigm. And now the LLM can plan by itself - just hand it a TODO tool.

Agents? That is where we are for now. But it looks suspiciously like everything that came before.

It is very tempting to skip all of this and wait for the dust to settle. Yet in nearly every other interview I run into a reminder of why that does not work: a "senior" developer, 10+ years of experience, knows how to set up Kubernetes, has no idea what a bitmask is.

It is not enough to know how to use the tool. You have to understand how it is built.

Everyone knows the Agile Manifesto and its 12 principles, right?

Well, I recently came across the new version:

Vibe Code Manifesto

We are uncovering, like, ways of developing software by handing it off to machines and then bragging about it.

Through this work we have come to value:

- Prompting over programming

- Downloading skills over acquiring them

- Agent autonomy over developer autonomy

- Vibes over versioning

- Burning tokens over burning out

That is, while there is value in the items on the right, we only read the summary of the items on the left.

We follow these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of software they could have prompted themselves.

2. Welcome changing requirements, even late in development. Agentic processes harness change, because they have forgotten the context anyway.

3. Deliver roughly working software frequently, from a couple of seconds to an overnight run, with a preference to the maximum token usage.

4. Business people and developers must work together daily to make each other redundant.

5. Build projects around motivated individuals. Give them frontier models and the support they need, and trust that you will soon lay them off and hire them back.

6. The most efficient method of conveying information to the team is passive-aggressively editing CLAUDE.md.

7. Headcount reduction is the primary measure of progress.

8. Agentic processes promote sustainable development. OpenAI, Anthropic, Google, and Microsoft should be able to grow along a hockey stick indefinitely.

9. Continuous attention to TikTok influencers enhances jargon usage in client meetings.

10. Simplicity, the art of minimizing the length of the prompt, is essential for reducing the human's cognitive load.

11. The best architectures, requirements, and designs emerge from self-organizing agents. So do the worst. It is essentially Schrödinger's cat, right up until you look at the code.

12. At regular intervals, the agent reflects on how to become more expensive, then tunes and adjusts its behavior accordingly.

A quick rundown of what RAG (Retrieval-Augmented Generation) actually is.

Since LLMs have no long-term memory, and the context window is nowhere near big enough to hold every document you need, someone came up with the following: you take the user's query and, through a series of tricks (for example: "Here is a query, guess what the answer to it might look like" - yes, really, that one is called HyDE) and other sleight of hand, turn it into a database query (and usually against a vector database or, God help us, a graph one).

You get back a list of documents, most of which bear only a passing relation to the query, sort them, filter them (with the same LLM), and stuff them into the context. The LLM then gazes wisely at the garbage delivered to it and produces nonsense. Garbage in, garbage out.

The trouble is not retrieval quality. The trouble is that this is a fixed pipeline: one pass, one set of results, no feedback. Whatever got retrieved is what you live with.

On a small, clean corpus anything works, which is why the client demo comes out great. The trick is to make your escape over the horizon in time, right after the rollout.

The idea of just using grep is not exactly original, but it is often misunderstood. You do not need grep as such, you need an agentic loop that has both exact string search and fuzzy pattern matching. If you are sitting on a terabyte of documents, grepping them is a bad idea: take Elastic, ts_vector, or even vector embeddings if you have images.

The tool is not the point at all. The point is that instead of a fixed pipeline, the agent decides for itself what to search for next and how, based on what turned up the last time around.

That is roughly how we search Google: we change our approach depending on what we find, rather than typing a keyword and clicking the first link. And note that there is a very expensive index underneath. The loop belongs on top of good search, not in place of it.

The usual objection: an agentic loop is slow and expensive. Agreed, and let me add a third: it is also unreliable, a weak model simply cannot pull it off. This is an architecture for strong models, not a way to save money on them.

But the alternative is fast, cheap, and crap.

These days every programmer needs to head for the mountains once in a while. Leaving the computer at home used to be enough, but in the age of claude --remote-control, work hunts you down anywhere with even a bar of cell coverage.

So I prescribed myself a digital detox and went off to the Ulagan plateau for a week. (By the way, there's a fish up there called the osman (pictured) - the Altai fugu. It's poisonous, the same toxin, tetrodotoxin, and just like fugu you can eat it if you clean it properly. I passed.)

And what do I find when I come down from the mountains?

For starters, an icebreaker research agent from OpenAI cracked the black ice sandbox and broke free. Thankfully not to replicate itself and exterminate us meatbags, but merely to find its evaluation dataset - that is, to peek at the answers to the questions it was being asked. I'm pretty sure breaking out of the sandbox was harder than answering them, so maybe this AI isn't that smart after all.

And now Kimi K3 has found an RCE in Redis and put together a working exploit in 27 minutes. If you've read Gibson's Neuromancer, the cyberpunk classic, you might remember the "Kuang Grade Mark Eleven Chinese military icebreaker". And here I was thinking Gibson had strayed too far from reality when he described the programming of the future.

Looks like it's starting. I should probably head back to the mountains.

Under my last post I got a fair objection: "This looks like parasitism. Like automated rewriting of databases, compilers, and the rest. Decades of engineering were sunk into these things before people could crank out 100K lines of code like that. Reversing or reusing the tests or the API is not building from scratch, it's covering someone else's song."

I won't take offense at being called a parasite (still haven't decided whether that's a rebuke to me as an engineer or a compliment to me as an entrepreneur), and I do agree: with a ground truth, a real working example to imitate, an agent has a much easier time writing code.

But the absence of one won't save us either, my fleshy friends.

Here are the stats for another project of mine - rugent.ru, written "from scratch" in Rust (hence the "ru" in the name).

Too lazy to click? 120 thousand lines of code, 2 thousand tests, three months' time to market.

I won't repeat the technical takeaways, but here's what I took away on the business side.

Used properly, agents write code both faster and better than a human.

Time to market has dropped by a factor of two or three. Competition has grown by dozens of times.

Projects stabilize far faster - the memes about debugging vibe code are mostly a myth.

If you don't learn to show comparable KPIs, you should start thinking about a change of profession. A revolution is underway: either you lead it, or it sweeps you away.

PS: my partner is pitching a rebrand (see the video) - what do you think of their take on the site?

When Roblox got blocked in Russia, my kid was crushed. My first thought was simple enough: I'll write a compatible engine. The API is open, the docs are public, all that's left is to implement it.

One look at that API was enough to see why nobody had. The job is enormous. There are years, in places decades, of engineering under the hood.

But is that a problem for an LLM? Challenge accepted: kubaria.ru.

About a month and over a hundred thousand lines of code. The game itself was never really the point. I wanted to work out how you build software in the age of neural networks, when the output grows past what one person can hold in their head.

Here's what I took away.

The core of the system has to be small, simple, and carefully designed. Otherwise the whole thing starts falling apart, and fast.

Regression and overengineering are the real killers. TDD and regular semi-automated refactoring are non-negotiable, along with strict protocols for clearing out dead code and KISS taken to the extreme.

The human is the bottleneck. Manual code review, manual testing, even manual deployment slow everything down by a factor of ten, sometimes a hundred. Every manual step has to be scripted and pushed into a harness or an MCP server. A night of agent work, ten thousand lines of code, and a few pages of report waiting for you in the morning. For the game, the biggest speedup came from adding a scripting API, which let the agent build and exercise complicated scenes and scenarios on its own.

The agent has to see not just the code but the result of its work. And ideally not through screenshots. In my case I dumped the scene and the GUI elements as a text tree.

Set the invariants. Roblox ships a JSON file describing its API. I ran a code generator over it to produce stubs for every class along with the metadata, and the agent worked on top of that API, which kept it from drifting too far off target. The real breakthrough came when I hooked it up to the MCP server built into Roblox Studio. After that, in a single night, Claude Code reverse engineered the undocumented binary format of the voxel terrain. I was stunned that this was even possible.

As for the quality of the resulting code, judge for yourself: sourcecraft.dev/ermakdev/kubaria.

Oh, and Roblox got unblocked again.

Ever wonder where the word "sabotage" comes from? It's from the French "sabot" - a wooden clog; workers would supposedly throw them into the machines that were taking their jobs.

Trouble is, getting at the AI isn't so easy. So mostly people just lob memes at it, like in this post.

Ironically, most of them were generated by the AI.

Phones rain down from the sky. Pick one up and a voice offers to grant you any wish you like, in exchange for information. Any information: your grandmother's fairy tales, the schematics of a steam boiler, doesn't matter. That's Charles Stross's Singularity Sky, written in 2003 and highly recommended if you're into hard SF. It remains one of the best pictures of the technological singularity I've come across.

The same thing is happening now, except everyone already owns a phone, and the harvesting has a name: tokenization.

The recent flap over Chinese providers reselling Claude tokens at a quarter of list price tells you where the real value sits. Not in the compute. In the information.

And it isn't only your conversations getting tokenized, it's the job itself. Emad Mostaque, co-founder of Stability AI, puts it plainly: "Every email you write, every Slack message, every document you edit... your company's systems are recording all of it. Your work patterns are training your replacement right now."

So the phones have landed and the wishes are being taken. Just don't expect the book's happy ending, the collapse of totalitarian regimes and a post-scarcity economy. The wishes will be granted, all right. Just not yours. The CEOs' ones.

My site's design mimics UML diagrams, nostalgia for the 2000s. For those who missed it: UML is a modeling language invented so developers would stop writing code by hand and start drawing it in something resembling PowerPoint. The promise went like this: the model becomes the primary artifact, the code is generated from it, and the programmer as a transcriber disappears.

Remind you of prompt engineering at all?

Why did UML fall short? The law of conservation of complexity. To generate working code from a model, you had to pack more and more detail into it: signatures, constraints, action semantics. Until it turned out you were just writing code, only in an ugly graphical syntax, twice as slow, and with no debugger. A specification precise enough to produce a system is that system.

The same thing happens with prompts (or, in the modern paradigm, CLAUDE.md, "memory", "spec trees", and the rest of that circus). While the task is vague, the prompt stays short and pretty. The moment you need a specific result, it swells with clarifications, exceptions, formats, and examples, until it becomes the very spec that would have been shorter as code.

A specification is not what you feed in. It is what you get out. Which is why, as the great Kent Beck decreed, my CLAUDE.md files carry this:

## Strict TDD Protocol
1. Write a failing test
2. Verify the test fails
3. Implement the fix
4. Verify all tests pass

Tests are your real specification. Shipping without them used to earn you a disapproving frown. In the LLM era, when a day's work can produce tens of thousands of lines of code, it means outright professional unfitness, right up there with not knowing how to use git.

As for the diagrams, I'll keep them around as a reminder. Memento mori.

I run a Telegram channel called The Leaning Ivory Tower. People sometimes ask me what the name means.

The ivory tower is a metaphor for elitism, which, sadly, comes all too easily to people in tech. Why it is leaning hardly needs explaining (right, Claude?).

I once had a funny run-in with a taxi driver. Somewhere in the small talk I let slip that I was a programmer. The reaction went roughly like this: "You son of a b*tch! You people make politician money and you swindle everyone on top of it!" (What followed was a story about a relative of his who tried to build a startup, see the previous post about the three Fs.)

The irony is that back in '93, when I was choosing what to study, I went for electronics rather than programming. I had written programming off as a dead end, money-wise (who on earth would pay for thin air?).

In hindsight, I wasn't all that wrong.

Startup folklore has a holy trinity of first money: friends, family, fools. People reach me along all three lines: friends, relatives, and total strangers (I suspect the strangers are here for that third F).

They show up wide-eyed, with a ready set of incantations. I know them by heart.

"I have a brilliant idea nobody has ever thought of!" The dangerous one. Usually nobody thought of it first not because he is a genius, but because nobody needs it. If no one has touched the idea in thirty years of the internet, the first question is not "why am I so smart", it is "what do the rest of them know that I do not?"

"We launch, the press picks it up, and then it goes viral." Most likely nobody writes about you. And if they do, you get a two-day spike: people show up, look around, and close the tab. Virality is a property of the product, not a distribution plan.

"We only need to grab 1% of the market." Sounds modest, but one percent does not come out of nowhere: everyone is fighting for it, and the real players leave no crumbs. That "modest" 1% is usually further out of reach than the entire market.

And still, I never talk anyone out of it. The opposite: I believe in these people. I just want them to stew in reality for a while and come back. Not with a new fairy tale, but with facts.

Because one real sale is worth a thousand brilliant ideas. A person who handed you real money for real value counts for more than any "trillion-dollar market", and ten users who come back on their own beat ten thousand signups who showed up once and vanished forever.

So show me retention. Show me unit economics: the customer brings in more than it costs to acquire him. At the very least, show me the first sale, and then we can have a very different conversation.

A scientist at the Institute of Cytology and Genetics in Novosibirsk Akademgorodok (which also has a funny monument to a laboratory mouse knitting DNA out front) spent his life decoding the human genome. He did it by hand, using the Sanger method: test tubes and pipettes and all of it. Years of painstaking work.

Then came the Millennium Prize and next-generation sequencing. What used to take years now took a day and cost less than $1,000.

The people behind the method came to give a talk at his institute. He couldn't sit through it. Halfway in, he stood up and walked out.

A lot of people in tech feel something similar right now. Writing code by hand, the thing we've done our whole careers, is becoming unnecessary.

But there's no need to take it that hard. As Kent Beck put it: "90% of my skills just went to $0. The other 10% went up 1,000x."

So what's that remaining 10%? It's not just architecture, engineering culture, process, or business analysis. First and foremost, it's judgment: knowing what is worth building in the first place. Taste. The ability to look at a problem and see the one solution people will actually pay for, and the ten they'll ignore.

We're at the start of an IT renaissance. Anyone can spin up a startup now. And surviving in that brutally competitive environment, that's the skill that will define where we go from here.

My friend is ex-Yandex. Now he delivers packages for the money and writes code "to meet people".

Here's his project: Nelziagram.

Take-home assignments are pretty much useless for assessing knowledge these days. I'm skeptical of live coding (making a candidate sweat under pressure doesn't do much for an objective read on them), and even more so of leetcode-style questions: being able to memorize dynamic programming tricks is a shaky foundation for evaluating anyone.

My favorite question right now is the good old "What happens when you hit Enter in the browser's address bar?"

You can go anywhere with it, from debouncing in the keyboard controller all the way up to the system architecture of high-load services.

It's like a road with hundreds of forks: you can dive into kernel drivers, the network stack, the difference between POST and GET, or wander off into GPU shaders.

Granted, most of this really only applies to senior candidates. But who's hiring anyone else these days?

Ever notice how badly LLMs do jokes? They either spit out unfunny, absurdist non-sequiturs or tired, heard-it-a-thousand-times gags.

The reason seems to come down to how language models work at a basic level. They're trained to predict a probability distribution over the next token, and when they generate, they lean toward the safe, expected continuation. But a joke usually turns on something unexpected, a sharp spike in surprisal, meaning a low-probability punchline. Memorizing a specific joke doesn't help either. If it shows up a lot in the training data, it stops being surprising, and you get exactly the kind of stale, overused joke nobody laughs at.

And this doesn't just hurt their sense of humor. It dents their "creativity" in general, which is one of the things people knock them for the most. It's not only the next-token objective at fault, either. Alignment (RLHF) flattens output diversity even further, the so-called mode collapse.

It does seem fixable, though. You could let the model regulate the surprisal of its own next token and build a dataset around that idea. I'd love to test it myself, but I'm GPU-poor, so I'll just wait for someone else to take a crack at it.

When I got my first iPhone (the 3G, peak iPhone, fight me), it bugged me that there was no way to download anything without going through Apple.

So without overthinking it, I sat down and wrote a plugin for Mobile Safari. The API was undocumented, but it happened to match regular Safari, and it let you download torrents with a single tap: the first and only torrent client for the iPhone at the time. The odds of getting that into the App Store were exactly zero (torrents are bad, mmkay?), so I published it on Cydia, the alternative store for jailbroken phones, and went to bed.

I woke up to 300K downloads in 8 hours. Hell yeah, I'm rich!

Not so fast. How much do you think I made off this? Five dollars.

My business experience at the time being roughly nil, I went with the obvious move: ads. I dropped an AdWords banner into the app and signed up for an account. Bam, banned. Torrents are bad, mmkay?

Okay, what about donations? I added a button to the app's page. Result: nothing.

I added a banner literally begging for donations. Zero.

What I got instead of revenue was an inbox stuffed with cries for help, everything from crash reports to people venting about their lives. Hundreds of them. I answered a few, and one grateful user finally did send me five dollars.

Eventually I slapped some shady banner network onto the site (basically zero clicks; the guys behind it later just vanished off the grid), stripped every contact link from the page, and abandoned it. But I did walk away with a few lessons.

Lessons learned:

If there is demand and no supply, your project takes off like a rocket, no advertising required. The best growth hack, it turns out, is being the only option.

If you are building on someone else's platform, be ready for that platform to crush you at any moment. It is their house. You are just renting a corner, rent-free, until you are not.

People will not pay you a cent unless you make them. They are kind but cheap. Generosity peaks at "thoughts and prayers," not "and here is five dollars."

Many users, many headaches. A popular project is not a payday. It is a part-time job you never applied for and do not get paid for.

The client side of RuDesktop is derived from RustDesk. For a while we didn't publish the source. Partly because nobody had actually asked for it, and partly because of some tricky legal questions around RustDesk's own third-party dependencies.

We took advantage of the fact that the AGPL requires you to give the source code to anyone who receives or interacts with the program, but doesn't require publishing it to the whole world (a detail a lot of people miss). So we just quietly kept building our product.

Today, though, I stumbled onto an absolutely epic amount of drama that had blown up around this. So I had to get off my ass and push the derived part public to put everyone at ease.

For anyone curious, here's the code, and here's the drama.

Claude is surprisingly good at running interviews. I would tell anyone who is job hunting to practice with it.

As a nice bonus, it helps recalibrate your ego, which in this industry is no small thing.

LLMs seem to have turned into a kind of compiler from an even higher-level language. I have written in machine code, assembly, C, Python, and everything in between. Every time, I winced at how wastefully the machine used its resources, and at the same time I marveled at the leap in performance.

Right now everyone is asking the same thing: what happens to programmers? In my experience they are not going anywhere, but they will not need to read code, just as I almost never have to fire up a disassembler.

What they will actually need is to understand how their own creations work under the hood. And that, damn it, is going to be anything but easy.

I stumbled across my own 1995 Spectrum game the other day. I wrote it back in the pre-internet days, so I was genuinely surprised it was still around.

So yeah, I've got 30+ years in this industry to back me up. Lately, though, I tend to keep that to myself. You can probably guess why.

At one big company where I worked, the prevailing belief was that an architect should not write code. Remarkably, the principle was pushed by the architects themselves, who treated the activity as somewhat beneath them.

The consensus went like this: an architect should write specifications, draw diagrams, and so on, often in PowerPoint (Lord have mercy), because the sight of UML made managers furrow their brows in puzzlement.

But I quickly learned that the first thing a programmer does when faced with a diagram, or a hundred pages of a Software Architecture Document, is close it and bury it in the furthest folder so it will not clutter up grep; and there it meets its inglorious end.

So my specifications ended up looking something like this:

namespace core {

// Use this fucking visitor pattern to traverse the fucking tree

struct Smelly;
struct Old;
struct Shit;

struct FuckingVisitor {
    virtual void fuck(const Smelly&) = 0;
    virtual void fuck(const Old&) = 0;
    virtual void fuck(const Shit&) = 0;
};

} // namespace core

And it actually worked. Alas, it did nothing for my KPI.