I've always tried to see myself as a company. Even as an employee, I viewed my employer as a client or partner. The problem is, I did it poorly. I only recently realized that I think in processes rather than product-outcomes, and that needs to change (see: Product Over Technology). But the core idea remains: I am a single independent economic unit that joins forces with other independent units to achieve shared goals. This partnership is mutually beneficial and voluntary.

With AI, this approach intensifies. The boundary between individual and company is dissolving. This video proposes viewing yourself as a complex AI corporation, which creates new challenges people haven't faced before: management, finance, security, oversight, legal, and more.

The proposal is to become a manager. Not a seagull-manager, department head, or paper-pusher, but a true CEO: a leader and visionary. Apply classical management models to an organization of your AI agents. You'll need to build organizational structure, design data processing pipelines, delegate tasks and decisions, and take personal responsibility for your employees' actions. This means not giving them too much authority, or better yet, running them in isolated capsules. There's no other way. Everyone must learn to build systems, not just do things. Push yourself left along the value chain!

Now is the time to learn management.

Though I see a challenge here. AI agents aren't people in the traditional sense. You can't punish or reward an AI agent. Classical models will need adaptation. But the core principles can probably still apply.

I've spent my entire life working with technology. Studying it, building it, growing it. When evaluating any project, I instinctively reach for the technology lens first. How well is the code written? Does the architecture allow for future growth? What frameworks are being used?

When developing my own projects, I always focused on technology first. I design elegant architecture, set up auto-deployment to Kubernetes, ensure data security, scalability, and disaster recovery. I always have monitoring in place.

But I'm missing the main thing: sales. Because my project isn't about business. It's about technology. I'm just a kid who never finished playing with blocks or construction sets. I find it interesting to build a system not to make money, but to say: "Look at this sandcastle I made, isn't it beautiful?" and then walk away to start the next "project."

This realization was as unexpected for me as it seems obvious in hindsight.

I think this is a very common problem among engineers who spent years working as employees. "Business isn't my thing, there are other people for that," they think. But wait. Isn't your life your own business? Are you really willing to hand over the right to manage your life, to take responsibility for the outcome, to someone else? Because when those people make mistakes, you're the one who suffers, not them.

It's time to take responsibility. It's time to decide that we're doing business first and building second. What matters is why we're doing this; the how is secondary. It's time to focus on the product, on markets, on economics, psychology, sociology, and other aspects of business. Formulate hypotheses and test them instead of waiting for permission from someone. What's the product concept? Who will pay money, and for what? Why would they pay for our product instead of another?

Everything else? A team of AI agents will handle that.

My Evolution of Working with AI Tools. The Capsule Concept.

I use LLMs and coding agents extensively in my work. This post contains a brief history of my observations and hypotheses.

The first decision I made: never run agents locally. This is a rule for me. There are two reasons for this. First, I'm afraid the agent might accidentally do something unacceptable on my behalf and with my permissions. For example, delete my home directory or a client company's database (protection against such actions may either be absent or fail). Second, the agent could steal secrets from my device (keys, wallets, passwords), especially if some third-party MCP or skill is used that might contain a prompt injection instructing it to send the entire contents of ~/.ssh to an attacker's remote server.

Acting according to this decision, I started running all development on a remote machine. But I immediately encountered the next problem. For different types of tasks I need different settings, different sets of MCPs, skills, different environments. I want something like "profiles" (https://github.com/anthropics/claude-code/issues/7075), but more capable. I want a profile to include not just the Claude Code state but the entire environment: all necessary MCPs, all keys, tokens, passwords required for the agent to work, repositories.

This leads us to a new concept that I call Capsule. I'll provide a more complete architectural description and decisions about the capsule's internal structure later, but for now let's consider external interaction with a Capsule as a black box.

From a conceptual standpoint, the following aspects should be considered:

1. Capsule Template. A textual description (config) listing what should be inside. Having a text format here is critical, as it will allow using git and LLMs to create and manage capsules.
2. Capsule Instance. Creating a Capsule from a template. Multiple Capsules can be launched from a single template.
3. Command Interface. Giving commands for execution. The agent inside the Capsule needs some way to receive instructions from outside about what to do (not mandatory, some agents can go out into the world and request instructions themselves), as well as provide statistics about its work. This will allow people to interact with the agent in a capsule and agents to interact with each other.
4. Other Interfaces. MCPs can access anything, but strictly according to the rules described in the template.

Since we're talking about wanting to describe the entire environment, Nix/NixOS fits this concept very well. Most likely the template will be a Nix Flake, the instance will be a virtual machine deployed by Nix, the command interface will be determined by the agent, and other interfaces by MCP servers and other tooling in the environment. But these are still open questions.

The next question is agent selection. Currently I use Claude Code (and only it). But I need a command interface as an API and preferably a web interface, so I don't have to SSH into the virtual machine. In this case I'll probably look towards opencode, since it supports API out of the box, and in my view the quality of work for all open-source agents will tend towards the same value (since the code is open, successful solutions will spread to all tools, and unsuccessful ones will die out). Therefore there won't be a big difference between choosing opencode or Claude Code.

The immediate plan is to develop 1-2 capsule templates for different tasks and start using them. After that, I can think about how to run multiple agents in parallel.

The tactic is simple. Figure out how to consume all available compute, then find ways to increase that availability.

I have a Claude Code subscription and other AI tools. My goal is to use them as efficiently as possible. This means pushing token usage closer to 100% of the available limit while maintaining acceptable quality. Solving real problems, not running expensive LLMs in circles.

Measuring Utilization

For objective assessment, I need to periodically collect usage and limits statistics. Perhaps every minute or every ten minutes. Store it in a database, build graphs, and devise methods to minimize the area under the (limits - usage) curve across all three parameters: current session, weekly totals, and Sonnet-specific allocations.

How to objectively evaluate effectiveness? I haven't fully figured this out yet. It will likely be an LLM bot that reads all my sessions, looks for anomalies, and suggests improvements.

Scaling Options: From Simple to Complex

Here's how I see the path to full utilization:

1. Parallel Manual Sessions

The simplest approach. I work on 2-3 tasks in side-by-side Claude Code sessions, switching my attention between them. Low overhead, immediate results.

2. Agent Orchestra

Design an AI environment where multiple agents work in parallel, communicate, negotiate, and I simply observe. This requires upfront architecture work but multiplies throughput.

3. Overnight Research Tasks

Formulate tasks for long-running research and leave them running overnight with a defined token budget. Wake up to results. This captures hours that would otherwise be wasted.

4. Periodic and Event-Driven Tasks

Assign the AI recurring jobs. Collecting daily email summaries at 4 AM, responding to certain events. These tasks utilize nighttime hours when I physically cannot participate in options 1 and 2.

5. Fully Autonomous Agent Teams

The end goal. I set a task, agents self-organize into teams, and solve problems while planning their token expenditure based on usage statistics. They schedule research and tests for nighttime (compute-heavy, LLM-intensive, no human needed) and communication tasks for daytime.

The Dual Scaling Problem

This breaks down into two challenges. Vertical scaling: teach agents to work autonomously for longer periods. Horizontal scaling: teach agents to collaborate effectively as teams.

I'm confident many teams are working on this. I'm happy to contribute what I can.

The Resource Allocation Problem

One thing I haven't solved: how to distribute usage between my manual work sessions and automated agents. If agents consume all available tokens, but I need to do something myself, what then?

This looks like a case for applying management and organizational planning practices to compute resources. Budget allocation. Priority queues. Reserved capacity for human override. Essentially, accounting for AI agents.

Solving these problems would mean the scaling challenge is addressed. From there, it's infinite incremental improvement.

My entrepreneurial hypothesis for the coming year:

Robots should do everything.

Absolutely everything. I should only monitor how they do it and adjust when necessary.

I should build systems of robots.

My task comes down to creating and maintaining infrastructure so that robots can do their work.

Here we should consider the following aspects:

1. Entrepreneurial: what exactly should agents do and why
2. Technical: servers, hosting, secure communications
3. Managerial: which agents will interact and how exactly
4. Legal: how to prevent regulatory violations (which may happen by mistake), how to pay taxes on what agents earn

For example, I used to write code for a client's needs. Now I'm building a team of robots that write code for a client's needs. My responsibility is to build the system so that the quality of the result is acceptable.

And then there are options:

1. Use the resulting system to earn money on other client tasks (or other clients). In this case, I'm selling my responsibility for the result.
2. Sell or provide access to the developed system so that clients can do the work themselves. In this case, I'm selling system maintenance, and the responsibility is on the client's side (they will understand that they're dealing with a robot system and must accept the risks).
3. Build new systems, or even meta-systems that allow building new robot systems.

There can also be some combination of these options. For example, I build a meta-system that builds and maintains systems, some of which I sell, and some I use to maintain the system and meta-system itself.

This way we get a new class of systems that can build upon themselves. That's where development should head.

"How many tokens did you spend on this task?"

This is the question I ask when someone starts telling me that a task is complex, unsolvable, or that they don't understand how to approach it.

Of course, you can't get an exact answer to this question. Unless you're using my LLM accounting and observability system, but that's still in development.

But this question forces you to verify that the person at least tried to understand the unfamiliar subject with an LLM's help.

If someone says something like "I don't use AI," then continuing the conversation with them is probably pointless. They're unlikely to solve tasks that their competitor can solve using modern technology.

If someone can roughly estimate the volume of computation the LLM performed to solve the task, that's telling. For example, they might say how many times they hit Claude's rate limit. Or how many sessions they had and roughly how large those sessions were.

I believe task complexity can be measured by the volume of tokens required to solve it. There should be some minimum volume that needs to be spent to grasp the conditions of any task, even one that seems simple at first glance. Assuming efficient usage, of course.

It would be good to start tracking this somehow.

I never run code locally. It's not safe. Instead, I always use sandboxes. Once upon a time it was a remote machine with Emacs that I connected to via SSH. Then I moved to GitHub Codespaces with VS Code. Then it became a remote machine again, this time with VS Code tunnels.

In the Claude Code era, I kept these habits. I would connect to the machine through a VS Code tunnel (wait for it to load), open a terminal (wait for it to load), run Claude Code (and with Codespaces I had to authenticate every single time). Then I'd finally get to work.

This approach worked well enough for me.

But yesterday I decided to switch to a new workflow where I run pure Claude Code. I'm embarrassed to admit that in several months of Claude Code's existence, I had never done this outside of VS Code.

And I liked it.

More importantly, I realized that old habits were holding me back. Knowing I could always open a file and edit it manually, knowing I could always switch to another terminal tab and do something myself. This didn't motivate me to do things differently. It pushed me to stay in the old paradigm.

Working in pure Claude Code forces you to do things differently. I can't open a file and edit it by hand (well, technically I can, but I'd have to remember the hotkey, so effectively I can't). I can't just go and run something in the console.

Instead, I need to make Claude Code do it. And do it efficiently, without burning through a week's worth of tokens in a couple of days. There's no way back. Doing it the old way is no longer an option.

I'm glad I figured this out, even if a bit late. Maybe later I'll return to Vim or Emacs, but I'll be calling them from Claude Code, not the other way around. Now it seems clear that Claude Code is the primary tool. I start it in the morning and don't exit until evening.

Next horizons: orchestras of agents, inter-agent communication, organizations of agents with shared memory and processes. Fun times ahead.

I want to save everything I write in Claude Code. And everything it answers. Everything it does, which tools it calls. Absolutely everything. Then I want to index this information.

After that, I'll analyze it. What did I think about most this week? Where do I make mistakes most often? How can I optimize my work? What connections exist between sessions? What do I constantly overlook?

I can also use this session history in future sessions. This will become my personal context graph — or at least a significant part of it. I'll have to give up using other interfaces, but that's fine, Claude Code is good enough. I'll need to spend some time making it work not just in developer mode.

Actually, I want to digitize everything I do on my computer, save it, and analyze it all. But starting with Claude Code is easiest — it stores data in JSON, which is easy to parse and save to a unified database. I have multiple devices running Claude Code, so this might be a small but solvable problem.

Once I get the key insights, I can expand the schema and connect more sources to my information collection system. Then I'll be able to create my digital twin — one that knows everything I know and uses that data to automate the routine.

Reading "Fooled by Randomness" by Nassim Taleb.

Taking lots of notes as I go — I'll sort through them when I finish and maybe write something more detailed.

But right now one simple thought keeps spinning in my head (unsurprisingly, since it runs as a thick thread through the entire book). It's long been obvious to me personally, yet completely non-obvious to people around me.

If you left the stove on unattended and went to the store for an hour, and nothing happened — that doesn't mean everything is fine. It means you just incurred a direct loss equal to the probability of fire multiplied by the cost of restoring your apartment after one.

If a risk didn't materialize this particular time, that doesn't mean it should be thrown out of consideration.

I've started noticing many people around me who don't grasp this simple and obvious idea — they "just live." I don't understand them.

What scares me most is that I probably don't notice similar behavior in myself and act the same way. How to fix this?

Reading Cursor's post on dynamic context discovery.

"Treat terminal as a file" — that's the Emacs way. Both approaches share the same idea: a unified interface to everything through files (or buffers).

It would be fascinating to build an AI agent that works natively with Emacs buffers. You could reduce everything to text and use Emacs for literally everything.

The only problem: Emacs as a user interface for AI is impossible to sell. People won't appreciate the elegance.

One could try to revive Emacs with modern technology while preserving its spirit and philosophy. But it probably won't take off.

So I'm simplifying the writing process to the maximum, shortening the path from forming an idea in my head to publishing it.

First, I've been using a private Obsidian for personal notes for a long time. In one of my next posts, I'll describe it in more detail (along with the history of updating my note-taking systems, which includes dozens of tools and approaches).

All that's left is to set up the publishing part.

For this, I bought a virtual machine and set up Claude Code on it. The VM only has access to one repository with posts (yes, I'm paranoid and don't let Claude Code onto my personal computer — I think that would be the height of foolishness).

Now I write my posts as usual in my private notes, and when I realize a post is ready to publish, I SSH into the VM and simply paste the text into Claude Code. It prepares the text (I'll add copying of my stylistic quirks later) and pushes to the repo. Very simple.

Actually, this is a very deep idea that eluded me for many years. KISS. Simplify to the max. My whole life I've been overcomplicating things, thinking about non-existent options, thinking about why I shouldn't do something instead of just doing it and seeing what happens.

It's better to do something simple and fast, and redo it tomorrow, than to not do it for years waiting for the perfect moment.

Originally, I planned to write all my texts myself without using AI. But now I realize this requires considerable—actually, serious—discipline and extra time to polish my style in a non-native language. So I often simply don't find the time, and that's why I don't write on my blog. Not because I have nothing to say.

So I've decided to write however feels comfortable and trust AI to improve and format the text. I'll also keep all the originals, so in the future I can run these same initial drafts through newer, smarter models and get better versions.

For now, I won't overthink whether a post is "unpolished" or "low quality." Better to write it down badly than to lose it entirely.

What do I need to set up a blogging process right now so that publishing a new post takes seconds?

Command — controlling the "world" through text.

The idea is to work in a single interface — whether Obsidian, Commacs (a commander based on Emacs), or a custom-built one. The implementation doesn't matter; what matters is the technology itself.

Here's how it works: I make a "move" by writing a message (text, voice, images, documents, facial expressions, etc.). I try to formulate it as completely as possible. A move is a command to change the world. I can only make moves by writing messages.

Then I send the command. The world changes through a chain of agents. How exactly? That's also a question. Most likely, world descriptions change in the form of git repositories, and then the world itself changes through CI. The main thing is that I receive the result of this change. In what form, I don't know yet. Maybe it's a feed of messages, or a dashboard that's always open, perhaps a dashboard with a news feed. Doesn't matter. The interfaces are still in progress. The main thing I receive is a quick and compact reaction of the world to my changes in the form of a description of the new world state.

I draw conclusions (perhaps my command contains errors, inaccuracies, or contradictions, and I'll learn about them through feedback), and make the next move.

So my participation in this game called life comes down to sending commands. Is this the most efficient way? Can I reduce everything to this model, or is it too simplified?

Can Claude Code serve as such a commander?

Agency (in the context of making decisions) is the most important skill during the AI era.

I believe computers (robots/AI/agents) can do almost all human work. We can automate every task but not decisions.

Making decisions requires willpower (see Baumeister et. al.), but only humans have it.

Computers can help with decisions, but they can't make them. They can find arguments for different options, compare them. They can also create and run models to understand consequences, but they can't take responsibility for them.

Definitely, progress in modeling and predictions based on these models improves computer decision-making skills. But the ultimate verdict rests with humans. People have something to lose, but computers don't.

So, the next move belongs to people who can make decisions. Who can take control. Let's take action today, right now. Let's be the people who have agency. Let's study how to make decisions and do it better.

Seneca said that your time is a thing that you can control. Start from it. Be an entrepreneur (at least in your own life). Gradually and continuously make your decisions bigger and impactful.

I watch in horror as people around me use AI in an absolutely unsafe way.

People give full access to their devices. The AI tools can use browsers (with all accounts), SMS, emails, bank apps. Once I saw somebody allow AI to attach by SSH to a production server! And nobody sees the problem with this.

What is the problem? You give control of all your digital life to someone else. He can send the wrong email to your boss (from your name!), he can spend all of your money. And you can't control this.

It's insane to give your phone or your laptop with work access to a kid. You care about the data it contains. He can delete everything, or break something else. Why is AI treated differently?

I don't have the answer. Maybe this is because people don't treat AI as a person. But it's wrong. Intelligence (even primitive) has agency (the ability to act). So, he can hurt you (either by accident or by design).

My approach is to treat AI as a person/agent. He can be a personal assistant, a programmer, and a researcher. But all of them must have their own space. Their own email address, their own accounts. If I need to grant access to my calendar, I just share it with the assistant. I don't share full access, but only the needed calendars or events. My github agent doesn't have access to all my github, but only access to push to allowed repos. And every agent has their own VMs and doesn't have access to the host machine. Just like a real person.

In this approach I am a CEO in a company of agents. I need to organize and delegate, but not to replace myself. This is my current strategy.

I'm sure there are a lot of interesting ways to use AI, not only an agentic approach, but we need to care about privacy when developing and using them

I'm building a habit of writing down everything. I think this is the base of efficient work.

Any thought should be written down. Any bookmark, any interesting book, any link, any quote, any paper should be saved. Everything interesting. But I should save only things which I am really interested in, not all of them. This is important.

Ideas don't appear out of thin air. They are born from other ideas (mine or other people's, but already written down). If so, they should be linked. I can track how my ideas grow and find insights there.

Every step, every hypothesis, and every experiment should be noted. A thought that I think but don't write down is a useless thought.

My notekeeper, the home of my notes -- is a private place. Some people write directly to the public, but I can't. It's my dream to work transparently and think only about things I can share. But not now. I'm too shy. So, I need an always-private space. This is a kind of filter before publishing.

I write my own notes without AI, because my notes should represent my thinking. I use AI for working with my notes, for fact-checking, for spell-checking, for finding insights, for making links between notes, and for something else. But my ideas are only my ideas. I use a special mark for AI-generated text in my notebook.

Ideally, every idea should be public. Every note should be traceable to public posts. This is not necessary, but recommended because public ideas are a public good. My ideas can inspire someone to have new thoughts. This makes progress.

This is why I make blogging the first thing I do every day.