DEV Community: Egor Kosaretskiy

Optimizing the Pilot: My Terminal-First AI Agent Workspace

Egor Kosaretskiy — Sat, 11 Jul 2026 16:26:56 +0000

The missing layer

Everyone is talking about how AI agents have changed their workflow, how to properly orchestrate them, which frameworks to use, how to chain them together. That conversation is useful. But there is a different layer that nobody seems to be discussing: the actual UX of fast, fluid interaction with your agents while they are running, whether you are managing one or ten.

The industry's answer in 2026 is visual dashboards, orchestration UIs, and reasoning panels. Beautiful, well-designed tools that show you what the agent is doing, surface its reasoning, and let you intervene at each step. I tried several of them. They are well-built. I still went the opposite direction.

My workspace is a terminal. And it is faster than anything I have tried with a GUI.

This is not about being contrarian. It is about what actually keeps you in flow when you are juggling multiple agentic sessions simultaneously. Two tools made that possible for me.

Home row mods

The first and most important prerequisite is home row mods. If you are not familiar: your home row keys (A, S, D, F on the left and J, K, L, ; on the right) act as regular letters when tapped, but become modifier keys (Ctrl, Alt, Shift, Super) when held. On a Mac you set this up with Karabiner-Elements.

This sounds like a minor ergonomic tweak. It is not. It eliminates the constant hand movement that breaks your flow. Instead of reaching to the corners of your keyboard every time you need a modifier, your fingers never leave the home row. The modifiers are already at your fingertips.

The reason this matters so much in an agentic workflow is that switching between panes, tabs, and sessions is something you do constantly. Every switch is a key combination. If every key combination requires moving your hand, the friction compounds quickly. With home row mods it does not. The interaction becomes almost unconscious.

This is the prerequisite to everything else. It enables truly multilayered, fluid interaction with a terminal multiplexer.

Zellij

Zellij is the king of terminal multiplexers. Some of you know tmux. Tmux is powerful but turning it into a proper workspace takes significant effort: you need a theme, a status bar plugin, sensible keybindings, session management config. It is a project on its own. Zellij works out of the box.

When you open Zellij for the first time it shows you the keybindings. There is nothing to configure before it is usable. From there you get:

Panes split horizontally or vertically within a tab, each running an independent shell or process
Tabs for grouping related panes, named and navigable with a single keypress
Sessions that persist and can be attached and detached at will
Instant copy by simply highlighting text — no extra keypress required

What makes this exceptional for AI agent workflows is that each Claude Code session runs in its own pane. You see all of them at once. You navigate between them with Alt+h/j/k/l. When an agent finishes and you want to give it a new task, you are one keypress away regardless of which pane you are currently in. When you want to fullscreen a single pane to read a long response, that is one keypress too. Everything is composable and immediate.

Configured with home row mods in mind, you can navigate through every layer of the multiplexer — tabs, panes, sessions — without moving your hands at all.

What this looks like in practice

A typical session for me looks like this: three panes open, each running a separate Claude Code task. Left pane refactoring one module, top-right writing tests, bottom-right digging into a bug. I check in on each one, give direction where needed, and move on. The navigation between them takes less than a second and zero mental overhead.

This is the part the GUI tools have not solved. They are excellent at showing you what a single agent is doing. They are not designed for the physical experience of driving multiple agents in parallel at speed.

Most people are optimizing the agents. I am optimizing the pilot.

If you try this setup, start with home row mods first. It takes a week or two to stop accidentally triggering modifiers when you mean to type a letter, but once it clicks, going back feels like typing with oven mitts on. Then add Zellij. The combination changes how fast you can actually work.

nixlab: Own Your Compute

Egor Kosaretskiy — Tue, 30 Jun 2026 18:28:57 +0000

GitHub

How it started

This project has been cooking for a while. It started with a Dreams of Autonomy video back in 2024 that sent me down the homelab rabbit hole. I bought a pair of Beelink mini PCs and set out to replicate the setup, but the result left me deeply unsatisfied. NixOS was used only to configure the initial cluster bootstrap, not for actual service deployment. That was not what I signed up for.

Getting the hardware into Kazakhstan was kinda difficult. I had to contact customs, pay import taxes, fill out a couple of forms. Shout out to Beelink for helping out and covering shipping costs.

Building around constraints

With the hardware on the desk, I started working within the constraints of what I already had. The approach I landed on: custom systemd services that apply Helm charts right after Colmena pushes a NixOS config update to a node. It felt clunky at first, but it grew on me. Eventually it became natural. Colmena handles the declarative system layer, the activation scripts handle the Kubernetes layer. One colmena apply and the whole stack converges.

The full cluster (MetalLB, Longhorn, nginx ingress, Pi-hole, cert-manager, WireGuard VPN, Nextcloud, and more) is declared in a single vars.nix file. Adding a node means copying a hardware config template, filling in an IP and a disk, and applying. Everything else is derived automatically.

Every boot wipes / via a btrfs rollback in the initrd. Only /persist survives. Nodes are always in a known-good state, and state that matters is explicitly declared.

No kubectl apply by hand

Helm charts are never applied manually. When you run colmena apply or nixos-rebuild switch, a NixOS activation script fires before the system even finishes switching. It takes every service definition, which are Nix attrsets rendered to YAML at build time via nixhelm and nix-kube-generators and baked into the Nix store, writes them to /var/lib/kubernetes/manifests/, and restarts a k8s-deploy systemd oneshot service.

That service polls the Kubernetes API until it responds, creates all required namespaces, then walks through the deployment groups in dependency order: core infrastructure first, then networking, DNS, TLS, VPN, and finally apps. Each group writes a sentinel file when it succeeds, so a partial failure reruns only what did not finish. The deploy is a side effect of a system rebuild.

Isolating it from my dotfiles

The homelab config lives inside my larger dotfiles repo, shared with everything I use daily. To publish it, I had to strip it down and isolate only the homelab parts so anyone could clone it and replicate the setup without needing the rest of my personal config. That cleanup turned out to be useful on its own: it forced me to make the template actually self-contained.

Why own a homelab

The practical reasons are obvious: self-hosted storage, ad blocking, a VPN, full control over your services. But for me the larger reason is ideological.

Compute is becoming as essential to daily life as food and water. The more people outsource that to large corporations, surrendering their data, their workflows, their dependencies, the more fragile and unfree we become as a society. Owning your compute, even on a small scale, is a meaningful act. It keeps you literate about the infrastructure that runs your life, and it keeps that infrastructure under your control.

That is probably a lot to read into a pair of Beelink mini PCs. But I think this kind of effort is part of a larger mission, and I hope nixlab makes it a little easier for someone else to start.

High velocity ML development with Nix and AWS

Egor Kosaretskiy — Fri, 26 Jun 2026 20:02:20 +0000

GitHub | Download slides if you have been to my talk

The need for speed

Over the past several years I have developed severe ADHD by consuming short-form content. Instead of fixing it by exercising proper habits, meditating, or whatever, I decided to lean into it. I read somewhere that ADHD also comes with superpowers: it is possible to catch a flow state (hyperfocus) where you can concentrate on something long enough to actually get things done. But this flow is fragile. It needs a constant feeling of speed and forward momentum.

Preserving that state pushed me to eliminate every break and barrier between a thought and actual code running on a machine. A couple of years ago I kept catching myself distracted and unable to write code even when my head was already running, so I invested time, money, and skill into a split keyboard and blind typing on the Miryoku layout. Then it bothered me that navigating an IDE was slow and forced me to keep track of where everything lives and how to configure and run things, so I built my own editor with Neovim. Even then, developing on common Linux distros like Ubuntu felt inefficient: installed packages quickly polluted the system, projects conflicted over different dependency versions, and there was no guarantee you could reproduce your environment if you came back to a project months later. That is when I discovered Nix and rebuilt my system, declarative, reproducible, and easy to manage. Local development became nearly frictionless. The obvious next step was bringing that same fluidity to the cloud.

The idea: unified environments

I finally decided it was time to make Nix work on the cloud for my ML applications. Nix is built around reproducibility and seamless environments that are quick to spin up, and that property should hold equally well on a remote instance as on a local machine. This is the central idea behind nix-ml-solo: a fully unified environment between any cloud resource and any local machine, so a data scientist never has to think about which machine they are developing on.

devenv.nix is the single source of truth. Change values here and they flow everywhere: Terraform resource names, S3 buckets, ports.

let
  project       = "nix-ml-solo";   # all AWS resource names derive from this
  environment   = "dev";
  mlflowPort    = 5000;
  jupyterPort   = 8888;
  inferencePort = 5001;
in
{ ... }

Switching from local development to a full cloud setup is one line:

# env.INFRA_MODE = "cloud";  # uncomment this

In local mode everything runs on your machine and AWS costs are essentially zero (S3 only). Flip to cloud and the same environment materializes on an EC2 NixOS VM and inside SageMaker containers, bit-for-bit identical, because they all share the same Nix closure. MLflow runs on EC2 and is accessed via SSH tunnel, so your tracking URI stays localhost:5000 regardless of where the training job actually runs. DVC handles data through an S3 remote that both your laptop and SageMaker pull from directly.

Architecture

The stack

The setup is intentionally minimal but fully viable: MLflow + DVC + SageMaker. Experiment, log, deploy. I think this is the core MVP for any ML workflow. Pipeline orchestration, feature engineering, and data ops are on the roadmap. The project is open source at github.com/thatbagu/nix-ml-solo.