[ HARDWARE ]
[ Ecosystem ]
Let's start from ecosystem. Windows, Linux, and macOS all have their strengths, but my main requirements are:
- Stability and reliability, so I can focus on work instead of rebooting or troubleshooting Wi-Fi, Sound, or Bluetooth drivers - so Linux is out.
- Well-supported, and well-documented UNIX development environment - so Windows is out.
So macOS it is.
[ Hardware Requirements ]
Let's go to the hardware requirements. I need a machine that can run multiple tools at once without slowing down, and that can handle large codebases and datasets. Supporting Machine Learning and AI workloads is also a plus.
- In 2026, to run all the tools I need, 16GB RAM is the absolute minimum.
- SSD storage is a must for fast boot times and quick access to files.
- A high-resolution display is important for productivity.
- GPU support is a plus for machine learning and AI workloads.
- Long battery life is important for working on the go.
Right now I work on a MacBook Pro 14" with M4 Pro chip and 24GB RAM, which fulfills all the requirements above. I also have a 4K external monitor, mechanical keyboard, and mouse for a more comfortable and efficient workflow.
- Split is roughly 60% external monitor + mechanical keyboard + mouse
- 40% laptop as-is. No trackball, no split keyboard — I have many sides, but not that many.
[ Karabiner ]
Where the OS actually gets tuned is keyboard shortcuts.
It lets me add custom shortcuts, remap keys, and create complex modifications. For example, I have a rule that allows me to switch between English and Ukrainian keyboard layouts with a single keypress.
Language switching is bound directly. No cycling, no counting presses — you press the key for the language you want and you're already there.
- Ctrl+E jumps straight to [E]nglish
- Ctrl+U straight to [U]krainian.

FIG.1 — one keybind, one destination — no rotation involved
{
"description": "Switch to English input source with Control + E",
"manipulators": [
{
"from": {
"key_code": "e",
"modifiers": { "mandatory": ["control"] }
},
"to": [{ "select_input_source": { "language": "en" } }],
"type": "basic"
}
]
}
[ Mission Control ]
The same logic runs the desktop layout. I keep six Spaces, each hard-assigned to one thing. Ctrl+1 - Ctrl+6 jump straight to the matching Space. No "next/previous desktop" cycling here either, same reasoning as the language switch: a direct destination beats a direction you have to count.
- browser
- IDE - my main editor, where I do the bulk of my coding and debugging
- terminal - my main workspace, where I run Claude Code, git, and other CLI tools
- free space for DB/Redis GUIs and OrbStack - my dev tools, local servers, and containers
- Slack - work chat, async comms, and incident response
- Obsidian - my 2nd brain, where I keep my notes and plans.

FIG.2 — Ctrl+[number] beats Ctrl+left/right, every single time
Ctrl+A pulls up the Mission Control overview when I actually need to see all six at once. Every window fills its Space at 100%, but I keep them in windowed-fill mode rather than native macOS fullscreen — same usable area, but the menu bar and dock stay one motion away instead of a whole gesture away.

FIG.3 — six desktops, six fixed jobs — the same one is always in the same place
[ TERMINAL ]
My main working tool and my main terminal is Warp. No tmux, no zellij, no herdr, no multiplexer at all, even though I've used a few of them and they all worked fine. But we are living in 2026, not in the wild 2010s. Warp already has tabs, workspaces, and project-grouped sessions natively, with an AI layer on top. I have no nostalgia for multiplexers, sorry ;)

FIG.4 — tabs grouped by project, not by panes I have to remember the layout of (branch names blurred, not a leak)
One deliberate exception: Neovim gets its own terminal app entirely — Rio or Ghostty, kept separate from Warp. Not because Warp can't run it fine, but because I don't want my editor's session sharing chrome, history, and AI panels with everything else I'm doing. It's not the 90s, my machine can afford a second terminal app just so nvim gets a clean box to live in.
[ EDITOR, BRIEFLY ]
Three editors plus one thing that isn't really an editor. We will dive deep into Claude Code and nvim in future posts. In the meantime, here's the rough split of my time:
- Neovim gets 20% of my time.
- Zed - 15% of time, because it's fast and occasionally I have a mood for it.
- My old buddy VS Code - 15%. It was my first IDE and some habits just don't leave.
- The other 50% is Claude Code, and for that half of my week I don't open an editor at all. The work happens in the terminal, in diffs, in review — the editor becomes optional infrastructure instead of the default starting point - this is the reason why terminal has to be modern, fast, and AI-enabled.

FIG.5 — nvim, mid-config — fittingly, the plugin on screen is the one that hides my secrets
Almost all my IDEs are configured with the same philosophy: minimal, fast, and keyboard-driven. I don't need a million panels and toolbars, no terminal embedded in the IDE, no DB connectors, no Git GUI, no debugger panels — I have other tools for all of that. I just need a fast editor that can handle large files and projects. If I cannot find a plugin or theme that fits my needs, I write one myself. I have a few of those.
[ AI TOOLING ]
I've been using Claude Code for almost two years now — long enough that opening a traditional IDE feels like the exception, not the default. I run it straight in the terminal, doing the actual work: planning, multi-file changes, the stuff that used to mean opening an IDE and doing it by hand. To stay aware of what a session is actually doing, I use the ccstatusline plugin, which keeps session cost, model, and context usage visible so I'm not flying blind on a long-running task. GitHub Copilot's inline autocomplete still runs alongside it for the moments I'm typing directly — the two aren't competing, they're solving different-sized problems: Copilot finishes your line, Claude Code finishes your ticket.
[ THE ACTUAL WORKFLOW ]
My working day:
- Review Claude Code — whatever overnight/async sessions did while I wasn't looking, leaving feedback or new instructions where needed.
- Then Slack: blockers, incidents, and whatever business or engineering questions came in overnight.
- Then New Relic and Rollbar for anything performance- or error-shaped, plus a daily AI-generated report that's already combed through the logs for me so I'm reading a summary instead of raw noise.
- Then PR review. I prefer to do it in the browser default GitHub format. When I see GitHub, my brain switches to "code review mode" and I can focus on the diff, and it is easier for me to think about bottlenecks, edge cases, and the overall quality of the code.
- Then JIRA for tickets, planning, and triage.
- Then finally I check my own plan for the day written in Obsidian — which is a whole separate post, because "second brain" is a real thing, and it deserves a real writeup.
[ EVOLUTION ]
My setup has been stable for years at its core, but I'm not precious about it — I'll happily give a new tool a real two-to-three month trial to see if it actually brings something new and cool to the workflow. Most of them don't survive contact with what I already have. Raycast got a fair shot and never earned a place — Spotlight already does what I need, and a second launcher just for the sake of having a "better" one wasn't worth the context-switching. Same story with a git GUI — not VS Code's, not LazyVim's — terminal git stays, mostly because I trust what I can see happening over what a panel summarizes for me. My latest churn: Rio → Ghostty → Rio, right back to where I started after giving Ghostty a genuine try. That's the pattern — I'm open to switching, the current setup just keeps winning.
[ ELSEWHERE ]
GitHub · LinkedIn · Dev.to · Substack · 4thwithme.dev/blog
May the --force be with you. See you next week.
Top comments (0)