Ariel Frischer: writing

From ~/.claude to ~/.omp: nine months of agent workflow

2026-09-30T00:00:00Z

My home directory tells the story better than I can. There’s a config folder for every coding agent I moved into this year, and each one holds a slightly different idea of how I should work.

Jan~/.claude/ one agent, a task list with approval gatesfirst sessions Jan 5 · config under git Jan 24 · dstask skill Jan 29
Apr 28~/.codex/ Beads and worktrees show upAGENTS.md on May 20 already says: worktree by default for substantial work
Jul 31~/.jcode/ a small team with job titlesroot agent, workers, research lane · Aug 13: a worktree for every repo change
Sep 20plain plans become the default; Autospec is opt-inlast completed Autospec implement run: Sep 5
Sep 24~/.omp/ Opus 5.5, a lighter process, and a setup that edits itselfOpus 5.5 daily driver Sep 25 · phone app fork Sep 27

These eras overlap. I never deleted a folder, and Claude Code came back in September. But the center of gravity moved four times.

~/.claude/ (January): one agent and a task list

The first CLAUDE.md was mostly about manners. One of its rules: “Patterns: propose, don’t impose.” If code was drifting toward an abstraction, the agent should mention it and ask, not refactor on its own.

Tracking came a few days later. On January 29 I added a dstask workflow skill with approval gates, and a line saying Autospec, my spec-driven development CLI, was for “medium+ features”. The same commit added a self-improve skill. I wanted the agent to learn from its mistakes from day one. It took until September to get that working, which is its own section below.

Off to the side: OpenCode (January to July)

OpenCode never got a folder in my home directory. Its config lives in ~/.config/opencode/, so it’s missing from the list above. It still ran about 3,600 sessions between January and July.

Most of those weren’t me typing. My OpenClaw bot launched OpenCode from its own workspace for background jobs like news summaries and research notes, on free models: mostly MiniMax M2.5 from February to April, then DeepSeek V4 Flash. It went quiet in August.

~/.codex/ (from late April): Beads and worktrees

Codex is where the structure started. By May 20 my AGENTS.md already had the three rules that survived every era since:

Track work in Beads. One issue per outcome, with scope, acceptance criteria, and handoff notes. The agent can pick up where the last one left off.
Isolate substantial work in a Git worktree. Agents stay out of my main checkout. A nowt escape hatch skipped the worktree for tiny fixes.
Size the planning to the task. Obvious one-sitting work skipped Autospec. Roughly 2 to 5 design decisions or 3 to 10 files meant a full spec.

~/.jcode/ (from late July): a team with job titles

Jcode is where it turned into an org chart. My workflow doc from that era sums it up in one line:

Beads hold memory. Worktrees hold code. Subagents hold noise.

One Bead, one branch, one worktree per outcome. A root agent owns the plan, routing, approvals, and integration. Workers do one bounded job and never delegate further. On August 13 the worktree rule tightened from “substantial work” to every change that touches a repository.

root agentplans · routes · approves · integrates

workerone bounded change
in its own worktree

research lanefile discovery,
fact-gathering

reviewera different model
than the author

The shape since Jcode. Workers report back; only root closes the Bead.

This is also when volume went through the roof. Here’s every session each agent left on disk, by month:

OpenCode Codex Jcode omp Claude Code

Jan

368 Feb

626 Mar

1,126 Apr

799 May

1,516 Jun

939 Jul

1,824 Aug

10,729 Sep

2,692

Sessions, not tasks: one task that spawns subagents writes several. OpenCode counts come from its session database, the rest from session files. Claude Code only has January and September files left.

August was the swarm month: 10,191 Jcode session files. Every one of those runs costs something, so my rules now say one worker by default, and at most three in parallel when the pieces are truly independent.

~/.omp/ (since September 24): Opus 5.5 and less process

Two things changed at once. I moved to Oh My Pi (omp) as my main harness, and on September 25 I made Claude Opus 5.5 my daily model.

Opus 5.5 is good enough that most of my process started to feel like ceremony. Autospec is the clearest example. I built it, it has 144 stars, and I barely use it now. On September 20 plain Markdown plans became my default, and the last Autospec implement run that finished is from September 5. For most features, the extra specify, plan, and tasks stages were time I spent waiting on a model that would’ve gotten it right from a short plan. I still reach for Autospec on big, interdependent, multi-milestone work. That’s rare.

The same week, dstask finally left my skills folder. Beads had done its job for months.

Here’s what a tracked change looks like today:

Beadscope and acceptance
criteria

worktreeits own branch,
away from main

Opus 5.5 plansand owns
the change

workersSol codes,
Luna researches

reviewby the model that
didn't write it

merge-wtlands it and
closes the Bead

Job	Model
Root: planning, orchestration, hard calls	Claude Opus 5.5, medium effort
Scoped implementation with clear tests	GPT-6.1 Sol, medium
Code review	Whichever of Opus or Sol didn’t write it
Research, file discovery, checklists	GPT-6 Luna, max effort

Too many agents, so config became its own job

Look at that list again: Claude Code, Codex, Jcode, omp, plus OpenCode and OpenClaw on the side. Every model release meant editing the same instructions, roles, and skills in half a dozen formats, and they drifted apart every time.

So I built profile-mango. One profile describes my models, effort levels, roles, instructions, and skills, and mango writes it into each agent’s native config, whether that’s ~/.omp/ or ~/.config/opencode/.

profile.yamlmodels · roles · instructions · skills

Claude Code

Codex

OpenCode

Oh My Pi

OpenClaw

Hermes

The Opus 5.5 switch on September 25 was a new profile, opus55-claude, applied to every agent with mango use.

All of it is also in Git. A systemd timer runs a small repo-sync tool every 30 minutes. It commits and pushes ~/.claude, ~/.jcode, ~/.omp, ~/.openclaw, and ~/.profile-mango, session files included, to private GitLab repos. It does the same for the tracked files in ~/.config, and exports OpenCode’s session database to a repo of its own first. That’s where every number in this post comes from: nine months of config history and sessions, still on disk and in Git.

The setup edits itself now

This is the part I tried in January and only got working this month. The loop:

I correctan agent

→

same turnit fixes the skill
or AGENTS.md at fault

→

profile-mangocommits it, installs
it everywhere

→

next sessionstarts with
the fix

← and the next correction starts it again

Three rules make it work:

Fix the source, not the symptom. When I correct something a skill or instruction should have covered, the agent edits that skill or the project’s AGENTS.md in the same turn, checks the edit against my correction, and tells me what it changed.
Codify on the third repeat. A tracker counts recurring task shapes. The second time something comes up, the agent proposes a shortcut. The third time, it builds the lightest thing that fits: a flag on an existing skill, a Make target, or a new skill if the job needs judgment.
Remember across sessions. omp’s local memory saves facts from finished turns and recalls the relevant ones when a new session starts.

An insights skill sits on top of that. It reads my session logs and writes reports with recommendations, and I decide what to take. Between September 25 and 30, ~/.profile-mango got 15 commits to skills and instructions. One of them trimmed my global omp AGENTS.md from 3,602 words to 1,451.

New hands: omp on my phone

The newest piece isn’t on the laptop at all. I forked Happy, an open-source mobile client for coding agents, and added omp support: ariel-frischer/happy.

phoneHappy app

⇄

laptophappy daemon

⇄

omplive TUI, or a
tmux session

My normal omp session on the laptop mirrors itself to the phone. Messages from the phone go into that same session, and steer it if a turn is running.
Sessions I start from the phone run omp in a detached tmux session I can attach to later.
Agent questions show up as forms on the phone and in the terminal. The first answer wins.
Tool calls, subagent progress, and images show up live.

I wrote it over three days, September 27 to 29. It’s a personal, experimental fork, not affiliated with the Happy maintainers.

What I’d tell someone starting now

Most of what I built in the middle was scaffolding for weaker models. What survived all four folders is small:

A ticket with acceptance criteria an agent can be graded against.
An isolated workspace per change.
One agent with the authority to say “done”.
A rule that turns every correction into a permanent fix.

Add process when a model keeps getting something wrong, and take it away when a better model stops needing it. I added a lot of process this year. The best change of the last month was cutting a lot of it.

Autospec 0.12: a model per stage, and when I actually reach for specs

2026-09-29T00:00:00Z

Autospec is a Go CLI that makes a coding agent work through four stages instead of one long chat: specify, plan, tasks, implement. Each stage writes a YAML file you can read, edit, and validate before the next one runs.

Watch the 44-second demo

curl -fsSL https://raw.githubusercontent.com/ariel-frischer/autospec/main/install.sh | sh

autospec run -s "Add user authentication with OAuth"   # write the spec
# review specs/001-user-auth/spec.yaml
autospec run -pti                                       # plan, tasks, implement

It started from GitHub’s SpecKit. The difference is that the artifacts are YAML, so the CLI can check them, and the orchestration happens in one Go binary instead of in a chat window.

What’s new in 0.12

A different model for each stage. Planning and implementation are different jobs, so now you can set models.<stage> in the config. Use a strong model for the plan and a cheaper one for the grind, or the other way around. The rules for which setting wins are now written down, so a flag, a profile, and a config file won’t quietly fight each other.

Named profiles. Switch a whole config set with --profile. That makes it easy to keep, say, a careful profile and a cheap profile side by side.

Jcode support. Jcode joins Claude Code, Codex, and OpenCode as a supported agent. There’s also an experimental, opt-in runner that talks to Jcode through its Go SDK instead of shelling out.

Smaller fixes that matter day to day:

Specs are found correctly inside linked Git worktrees.
autospec doctor checks for the agent you actually configured.
History works with project-local state, and status handles empty phases.

When I use it (and when I don’t)

I built Autospec, and it’s no longer my default for everything.

In early 2025 I used it for any medium-sized feature. Models have gotten good enough that a clear Markdown plan from the main agent covers most medium work. Extra stages cost time when the task is already obvious.

Where Autospec still earns its place is large, interdependent work: several milestones, lots of moving parts, and a real risk the agent drifts halfway through. There, having a spec and a task list that a program can validate, plus fresh bounded sessions per task, beats one enormous conversation.

My rule of thumb:

Clear task, one area of code: skip it, write a short plan.
Big feature across many files or milestones: autospec run -a.

Try it

MIT licensed. Native binaries for Linux and macOS; Windows works through WSL. You need Git and one of the supported agent CLIs. Run autospec doctor first; it’ll tell you what’s missing.

kb 1.4: stop guessing whether your RAG settings help

2026-09-29T00:00:00Z

kb is a CLI that turns a pile of documents into something you can search and ask questions about. Point it at your notes, docs, and PDFs, and you get hybrid search plus answers with sources. Everything lives in one SQLite file.

Version 1.4 adds the feature I wanted most: a way to measure whether a change actually helps.

The quick version

curl -LsSf https://github.com/ariel-frischer/kb/raw/main/install.sh | sh

kb init
kb add ~/notes ~/docs
kb index
kb ask "what are the recommended deployment patterns?"

It reads 30+ formats (Markdown, PDF, DOCX, EPUB, HTML, email, subtitles, and more), and can index source code too if you turn that on. Search combines vector similarity with SQLite full-text search. kb fts gives you keyword-only results with no API cost at all.

It can also run fully local. Use local embeddings, a local cross-encoder for reranking, and a local model for query expansion. The only step that needs an LLM is the final answer in kb ask, and that can be Ollama.

What’s new: `kb eval`

RAG tuning is mostly vibes. Swap an embedding model, turn on reranking, and you probably eyeball three queries and call it better.

kb eval runs kb’s real retrieval pipeline against public BEIR datasets, which come with human relevance judgments. You get nDCG, recall, MRR, precision, latency, and dollars spent for each mode.

kb eval                                   # scifact, fts + hybrid
kb eval nfcorpus --mode fts,hybrid,rerank
kb eval scifact --budget 2                # cap spend for this run

Two things I cared about:

It never touches your index. Eval corpora and indexes live in their own directory.
It has a hard spend cap. The default is $10 total across runs. A run gets refused up front if its estimated cost won’t fit, and it stops early if actual spend gets close.

Here’s the reference run on SciFact: all 300 test queries, local embeddings, no LLM steps, $0.

mode	nDCG@10	Recall@10	MRR@10
keyword only	0.697	0.816	0.663
hybrid	0.759	0.897	0.721

Hybrid wins on this dataset. Now that’s a number, not a feeling.

Other changes in 1.4

Better keyword search. FTS now matches any of your terms and skips stopwords, instead of requiring every word to appear.
ChatGPT subscription support. Set llm_provider = "chatgpt" and LLM steps run on your ChatGPT plan through the Codex login. No API key needed.
New defaults. GPT-6 Luna for chat, a ModernBERT cross-encoder for reranking, and Qwen3 for local query expansion.

It also ships an MCP server (kb mcp), so Claude Code and other agents can search your knowledge base directly. My own agents are told to check kb before they start grepping through docs.

Try it

MIT licensed, Python 3.12+. The minimal install skips PDF and Office support to keep dependencies light; add kb[all] if you need them.

If you run kb eval on your own settings and find something that beats hybrid, open an issue. I want to know.

Locus: I'm building a software factory, and right now it mostly breaks

2026-09-29T00:00:00Z

Locus is a Go CLI I’ve been building that takes a coding task and runs it through a declared workflow until it becomes an accepted Git change. You pick the agent (Codex or Jcode), the model, the steps, and the checks. Locus runs the worker in an isolated worktree, checks what it handed back, merges it, and closes the task.

That’s the pitch. Here’s the honest status: it’s pre-release, Linux only, and most runs fail. I don’t have a real use case for it yet either. I’m writing this anyway because I want it to work, and I’d rather build it in public than polish it in private.

What it does

The core idea is that the agent writing code is the easy part. What Locus owns is everything around it:

Task in. A prompt, a local task file, or a Beads board.
Sealed run. The workflow YAML gets compiled, validated, and frozen before anything executes, so the run you approved is the run you get.
Isolated worker. Each task gets its own Git worktree.
Independent checks. Locus runs your checks itself (make test, make lint, make build) instead of trusting the agent when it says “done”.
Serial integration. Merges happen one at a time, then the task provider gets updated.
Local ledger. Every intent, receipt, and check result goes into a SQLite file, so a crashed run can be recovered instead of guessed at.

prompt / task file / Beads
          │
          ▼
workflow YAML → compile → sealed run
          │
          ▼
worktree + agent (Codex / Jcode)
          │
          ▼
checks → merge → update task → ledger.sqlite

IndyDevDan’s super-simple-software-factory sums up the idea in four words: “agent proposes, code disposes.” The agent can say whatever it wants. The controller decides what’s true.

Why it breaks

In an August snapshot of 435 indexed runs, 111 completed, 206 failed, and 76 got blocked. The default Go workflow finished 79 of 201.

Those numbers aren’t all that useful on their own, because the failures mostly weren’t bad code from the model. When I looked through the failure archives, the top reasons were:

Reason	Count
Final candidate check failed	22
Worker didn’t claim `merge_ready`	10
Stage routed to handoff	9
Branch mismatch	6
Missing result commit	6
Session recovery failed	5

Most of that is plumbing. Locus treats “agent finished”, “candidate is valid”, “checks passed”, “merge completed”, and “task closed” as five separate facts. That’s what makes it auditable. But every translation between those facts is a place where good work can get rejected or mislabeled.

My own architecture review counted eight overlapping failure vocabularies and six lifecycle enums with 37 states between them. That’s the real bug. I built a system strict enough to catch agents lying, and in the process it started catching itself.

What I’m changing

The plan is to make it smaller, not smarter:

One lifecycle, one failure vocabulary. The runner interprets what happened, once. Everything else just reads it.
Sequential is the golden path. Parallel waves showed up in 6 of 425 runs. They can come back once single-task runs finish unattended.
Green base first. Capture baseline check health, so a test that was already broken doesn’t count as the agent’s regression.
Keep the safety core. Sealed approval, runner-observed Git, receipts, and recovery all stay. They’re the whole reason Locus exists.

None of that is shipped yet. I haven’t measured an improvement, so I’m not claiming one.

Where I want it to go

The goal is simple enough to say: a software factory architecture a small business can actually run. Hand it a backlog, get back reviewed, merged changes, on a laptop or in the cloud.

Right now it’s fully local. State lives in SQLite plus files on disk, process tracking reads Linux /proc, and the dashboard only binds to 127.0.0.1. Before a cloud version makes sense, three things have to be true:

Local runs complete reliably without me babysitting them.
A candidate and its evidence survive the worker’s machine going away.
There’s one runtime path, so “cloud” doesn’t turn into a second engine to maintain.

If you’ve built something like this, or tried and hit the same wall, I’d love to hear what architecture held up for you. I’ll post again when the simplified runner either works or teaches me something new.

Why I use a different AI model for each coding job

2026-09-29T00:00:00Z

Every few weeks a new model tops a leaderboard, and I used to switch my whole setup to it. After a summer of that, I stopped asking which model is best. Now each model gets the job it’s good at, and the rest of this post is why.

Benchmarks don’t agree

I run coding benchmarks on my own machine, and the results jump around.

On Jcode Bench (the model has to cut instruction counts on three small C functions, and every output is checked for correctness), GPT-5.6 Sol averaged 4.07 and Claude Opus 4.8 averaged 3.76 in my July run.
A week earlier, in a single run, Opus 4.8 beat Sol on all three tasks. It also took about 1,423 minutes to Sol’s 60.
The benchmark’s README says scores wobble by about 0.1 between runs. A lot of “wins” are smaller than that.

Public charts don’t settle it either. On the GPT-6 charts I used, Sol and Luna swap places depending on whether you look at FrontierCode or DeepSWE.

The numbers are fine. They’re measuring different things.

The tool around the model matters too

The same model scores differently depending on the coding tool running it. With GPT-5.6 Sol on high effort, Codex beat Jcode by about 1.3x on my benchmark. With Opus 5, Jcode was behind Claude Code at medium effort and slightly ahead at high effort, but took more than three times as long.

So “which model is best?” is really three questions: which model, in which tool, at what effort level.

What I use for what

Job	Model	Why
Main agent: planning and writing code	Claude Opus 5.5, medium effort	Strong on benchmarks and feels fast
Research, finding files, mechanical checks	GPT-6 Luna, max effort	Cheap enough to run at max effort
Hard problems	Opus 5.5, high effort	Only after medium effort actually failed
Code review	Not Sonnet, not Luna	Neither is good enough at review yet

What got me here:

Good judgment costs a lot. I usually like GPT-6 Astra’s judgment best, but it burned through credits so fast I couldn’t use it every day. I bring it in for specific problems now.
A cheap model that plans well can’t necessarily build well. Luna writes solid plans. That doesn’t make it a replacement for Sol or Opus when the code has to be ready to merge.
Your subscription decides how many agents you can run. In September I moved from ChatGPT’s $200 plan to Claude Max 20x, same price, to make Opus 5.5 my daily model. Now the weekly usage cap, not per-token pricing, limits how many agents I run at once.

If you’re setting this up yourself

Think of it like staffing a team. You don’t pay your most senior engineer to grep through files, and you don’t let the newest hire approve code review.

Pick one default model, give the cheap repetitive work to a cheaper one, and check again when a new model comes out. Just don’t rebuild everything because one leaderboard changed.

profile-mango: one profile for all your coding agents

2026-09-29T00:00:00Z

I use several coding agents, and every new model release meant updating four config files in four formats. Claude Code wants one thing, Codex wants TOML, OpenCode wants its own agent files. My instructions, subagent roles, and skills drifted apart every time.

profile-mango fixes that. You describe your setup once in a YAML profile, and mango writes it into each agent’s native config.

How it works

curl -fsSL https://raw.githubusercontent.com/ariel-frischer/profile-mango/main/install.sh | sh

mango init                     # starter profile in ~/.profile-mango
mango doctor                   # which agents you have installed
mango install default --all    # preview only; nothing is written yet

The preview ends with the exact command to apply it. mango backs up whatever it replaces, and mango undo puts it back.

A profile bundles four things:

A model route: which model and effort to use.
Subagent roles: worker, planner, research, and so on, each with its own model.
Global instructions: whole files like AGENTS.md and CLAUDE.md.
Skills: skill folders copied into each agent’s skill directory.

Actual provider and model names live in a separate local bindings file. So the profile stays shareable and never holds credentials.

Switching models is one command:

mango route set local --model gpt-6-sol --effort medium
mango use default

What it supports

Claude Code, Codex, OpenCode, Pi, Oh My Pi, OpenClaw, and Hermes. Each agent gets what it can actually support. Pi only takes a model and one instructions file, for example, while Codex gets named profiles, role subagents, and skills. Anything an agent can’t take gets listed as skipped instead of silently dropped.

What’s new in 0.2

Per-agent role overrides. Keep one shared route, but give a single agent’s research role a different model.
Placeholders in instructions and skills. Your AGENTS.md can reference the current route’s models, so the text stays accurate when you switch.
Stale-name warnings. If you replace a model but a profile still mentions it by name, mango tells you.
OpenClaw skills. Installs skills and can manage per-agent skill allowlists.
Safer ownership checks. mango can tell the difference between you editing a field it owns and an agent just rewriting its config file.

What it isn’t

It isn’t a manager for every agent setting. MCP servers, credentials, sessions, plugins, keybindings, and themes stay in each agent’s own config, and mango never reads or writes them. Portable permission rules can be declared, but no agent installs them yet.

That limit is on purpose. The portable slice (models, roles, instructions, skills) is the part that changes every time a new model ships. Everything else changes rarely enough to leave alone.

Try it

MIT licensed, written in Go. If you’d rather let your agent drive it:

npx skills add ariel-frischer/profile-mango --skill profile-mango -g

Neovim is Essential

2024-05-14T00:00:00Z

Introduction

Over the last 6+ years of my programming journey, I’ve come to understand that Neovim is the most productive tool I’ve used. Neovim is a lightweight editor that runs in the terminal. At first, it traps unsuspecting victims from exiting, but sooner or later, you won’t want to leave. Neovim is a fork of the popular vim repository, it has widespread adoption, and it has special “vim” bindings that make text editing and navigation easy, ergonomic, and effective.

You can navigate to the beginning of each word with the w key, or the end of each word with e - these are called vim motions. Vim commands + motions allow for effective code editing for example d is the deletion command paired with w will delete the word under the cursor. Neovim is keyboard-centric it saves so many keypresses and so using the mouse is discouraged and truly unnecessary. Once the vim bindings are ingrained in your head, you’re able to swiftly edit code at the speed of thought.

Yes, the transition from regular editors like VSCode is not easy or straightforward but was 1000% worth it. I find myself preferring to edit text everywhere with vim, whether in the browser or in the command line. Both are now possible with software like firenvim and “vi” mode for zsh. It’s so much faster that I actually feel uncomfortable going back to the “normal” way of text editing.

There is a learning curve, not just with the bindings but also with setting up language servers, plugins, etc. I wouldn’t say it’s a super steep learning curve; it’s more of an easy-medium difficulty. It took me about two weeks to become productive with vim bindings and start efficiency editing code. Initially, FlashDevelop was my first go-to editor back in the day, followed by VSCode. VSCode was great it had built-in language support, syntax highlighting, debugger, extensions etc… However, it wasn’t until I stumbled upon a YouTube channel, probably ThePrimeagen, that I saw Neovim in action and had that “Aha” moment. The way he navigated through files and edited code was like watching a master pianist at work. I knew right away that Neovim would be an invaluable tool for any programmer.

If you’re just starting out and would like to learn vim bindings without needed all the neovim configuration you can try out VSCode with the Neovim extension. Alternatively, you can use preconfigured neovim setups listed lower in this article. Although VSCode is an excellent beginner friendly editor, it is not as fast or lightweight as Neovim and is a bloated electron app. For many reasons, it will never be as good as Neovim.

Why Neovim?

Customizability

Neovim’s core architecture is unparalleled as it was designed with modularity and customization in mind. You can tweak it to create a coding environment that suits your workflow perfectly. I constantly create small lua functions and give them key bindings to solve any custom repetative tasks. The plugin ecosystem is insane in a good way, you can essentially get all the features you want and build them in modular fashion.

Efficiency and Speed

The efficiency and speed that Neovim provides are remarkable. The keyboard-centric design minimizes context switching and keystrokes, keeping you in the coding flow. The analogy of “gliding through a piece of paper with scissors” really encapsulates the experience. Once you get accustomed to the key bindings, the speed at which you can write, edit, navigate, and execute code is astounding.

At my last company there were constant incidents so an emphasis on quickly resolving them was invaluable. Neovim allowed me to manipulate code and lists of strings effortlessly which comes in clutch when resolving incidents. Need to dedup a list of strings? Do a visual highlight and run :sort u to dedup the list. Need to format a list in a specific way or do any repetative set of keystrokes? Use vim macros! Need to combine a bunch of lines into one paragraph, do a visual highlight and run :join or :j the shortcut for it. You can pipe terminal commands into neovim and manipulate the text as well. The control you get is unparalleled as your vim/terminal knowledge expands.

Community

Neovim boasts a vibrant and supportive community. The discussions on GitHub, Reddit, and other forums are immensely helpful. Whenever I faced an issue or needed help customizing my setup, a solution was just a post or a search away. Moreover, the community continually contributes to the rich plugin ecosystem, making Neovim ever-evolving.

Cross-platform and Extensible

Being cross-platform, Neovim is a versatile choice for teams working across different operating systems. Its extensibility is another strong point. I’ve integrated it with other tools and technologies, creating a seamless workflow regardless of the platform.

Modern Features

Neovim has embraced modern features like built-in LSP (Language Server Protocol), providing IDE-like features such as auto-completion, linting, and much more. It’s like having the best of both worlds-the simplicity and speed of a text editor, with the robust features of an IDE.

The Neovim Plugin Ecosystem

The plugin ecosystem has exploded in the last few years thanks to neovims clever decision to use lua instead vimscript which was used for the older vim. Some of the most popular plugins include:

Telescope.nvim: Highly extendable fuzzy finder.
nvim-treesitter: Parser generator tool and an incremental parsing library. It can build a concrete syntax tree for a source file and efficiently update the syntax tree as the source file is edited.
NerdTree: File system explorer for navigating the file system and opening files.
nvim-cmp: Completion engine plugin that aims to provide full support for LSP completion and offers powerful customizability.

Fuzzy finders, like telescope and fzf can jump to any token, symbol, buffer, module, or file in a project in a fast, sane, and intuitive manner. This is just the tip of the iceberg, checkout dotfyle for trending plugins. Installing + configuring packages manually is time intensive and not efficient this is where plugin managers come in clutch. The fastest current plugin manager seems to be Lazy.nvim nowadays but there are many to choose from: awesome-neovim#plugin-manager.

Pre-configured Neovim Repositories

For those who find the initial setup of Neovim daunting, there are pre-configured repositories available that can significantly ease the transition. Projects listed below offer ready-to-use configurations that come with a curated set of plugins and settings. These repositories are designed to provide a robust starting point, allowing you to experience the power of Neovim without the hassle of manual configuration. You can always customize these setups further to suit your specific needs.

Kickstart - A starting point for Neovim that is small, single-file, documented, and modular. This config is meant to be used as by YOU to begin your Neovim journey; remove the things you don’t use and add what you miss.
LunarVim - LunarVim is a highly customizable Neovim distribution that aims to provide a good starting point for personal configuration with sensible defaults. It includes a variety of plugins for code completion, linting, and a user-friendly status line, among others.
AstroVim - AstroVim is a modern Neovim configuration aimed at providing a simple, out-of-the-box, fully functional Neovim setup. It focuses on minimalism and modularity, allowing users to easily add or remove features as needed.
NvChad - NvChad is a minimalistic Neovim setup that focuses on performance and aesthetics. It comes with a custom UI and a selection of plugins that are tailored for a smooth development workflow.
SpaceVim - SpaceVim is a community-driven vim distribution that seeks to manage collections of plugins in layers. It has a modal interface similar to spacemacs, focusing on providing features for multiple programming languages and an extensive set of plugins.

General Features

Easy to Customize: Neovim’s API (Application Programming Interface) is well-documented, easy to find, and versioned, making it simple to extend and customize.
Works with Any Language: Neovim uses MessagePack for structured communication, allowing extensions to be written in any programming language.
Safe and Efficient Plugins: Remote plugins run as separate processes, ensuring they are safe and do not slow down Neovim.
Embed Neovim Anywhere: You can embed Neovim in GUIs, IDEs, and web browsers, using it as an editor or script host.
Easy Lua Plugins: Creating plugins in Lua is as straightforward as creating them in Vimscript. You can even write your configuration in a file called init.lua.
Better Syntax Highlighting: Neovim’s parsing engine produces an Abstract Syntax Tree (AST), enabling faster and more accurate syntax highlighting, code navigation, refactoring, and text manipulation.
Built-in Language Server Protocol (LSP) Client: Neovim includes an LSP client for advanced code inspection and refactoring, such as going to definitions, finding references, and formatting code.
Great Default Settings: Neovim comes with strong default settings that work well out of the box.
Consistency: Neovim works the same way on all platforms with one build type and one command.
Modern Terminal Features: Neovim supports modern terminal features like cursor styling, focus events, and bracketed paste.
Built-in Terminal Emulator: Neovim includes a terminal emulator, allowing you to run terminal commands directly within the editor.

Last Remarks

Everything I’ve listed here is just an introduction, neovim has so many built-in features I’m still learning new and exciting features after 6+ years of usage. Neovim has profoundly impacted my career as a Software Engineer and makes coding enoyable. The flexibility, efficiency, and productivity gains should make it a compelling choice for any developer. I encourage up and coming software engineers and/or writers to just try Neovim and enjoy your new supertool. Its not just an editor, its a game changer, and for me - it is absolutely essential.

References

Nix & NixOS - First Impressions

2024-05-02T00:00:00Z

Introduction

I picked up NixOS out of curiosity to see what all the hype was about, and I’m blown away. As a software engineer who has tried too many Linux distributions, I was quite skeptical. I can confidently say now my distro search is over, NixOS is my final destination. So what is Nix/NixOS? The Nix terminology can be confusing to newcomers, so let’s clear that up. This article will cover my first impressions, the Nix ecosystem, installation, usage examples, and the pros and cons of NixOS.

Nix* Ecosystem

Nix encompasses several distinct but interconnected components, each serving a unique purpose within the ecosystem:

Nix (The Package Manager)

Nix is a purely functional package manager meaning packages are built by functions, don’t have side-effects, and never change. Nix builds packages in isolation from each other and stores them in the Nix store in unique cryptographic hash subdirectories. This method allows multiple versions of a package to be installed simultaneously and prevents the rigmarole of conflicting software (Python v3.x, I’m looking at you). You don’t need NixOS to run the Nix package manager; you can get started on macOS and Windows (WSL).

Nix (The Programming Language)

Nix is also a functional programming language, which means if you start with the same input, you are guaranteed to get the same output. This simple principle gives Nix its reproducibility anywhere and enables long build times to be skipped by using a cache system. If your build configuration input is identical to someone else’s build input and that is in the cache, you don’t need to build from source; you just pull the output from the cache.

NixOS (The Linux Distribution)

NixOS is a free, open-source Linux distribution that uses the Nix package manager to manage software in the system. NixOS is based on an immutable design and atomic update model and uses a declarative configuration system for reproducibility and portability.

Nixpkgs (The Package Repository)

Nixpkgs is a GitHub repository that is the largest package repository in the world. It allows the Nix package manager to install any package by name instead of referencing some obscure GitHub repo. It is the culmination of years of hard work meticulously building up a foundation of packages, making installation of any package in any language simple. An increasing number of contributors constantly create new package builds that keep Nix up to date.

Those are the main tools, but the ecosystem is vast. Check out the full wiki page here.

Installation of NixOS

I had a spare USB drive and turned it into a bootable drive with NixOS using the Rufus tool. For my default Windows laptop, I partitioned the drive into two for dual-booting. This gives me a partition to install Linux while keeping windows for gaming.

The installation process was straightforward. I booted into the USB and followed the installation instructions, which installed NixOS. There is a known issue/non-issue where it seems like the installer is stuck at 46% but that process just takes a while - there is a clickable log button that will show you the commands its running to reassure the installer is not stuck. The installer has many desktop environments. I chose KDE Plasma, but you can switch to whatever you want later with a simple line change in your configration.nix file. After installation, I rebooted, and it just worked out of the box.

Post-Installation Setup

I needed Firefox, so I added it to my configuration.nix and rebuilt with nixos-rebuild switch, and voila, it just existed in my start menu. That was my first “holy-cow” moment. I was used to spending a darn week installing all my programs, going through websites one by one, clicking next, next, next, agree, next, done. Previously, I would need to run multiple CLI commands which are all DIFFERENT depending on which package manager your distro is using and install them in the correct order because this program needs this program as a dependency. Nix saved me from that pain I was dreading.

So I went ham and added a bunch of common packages. It all worked on the first try. It felt stable somehow, and the icing on the cake was the BLAZINGLY fast build time. I couldn’t really believe it was all working so smoothly; I was conditioned into random software breaking in Linux. After the first few days, I was quite satisfied with my system and thought that was it, but no, there is way more icing to this cake.

The Power of Nix

The distillation of all configuration in one file empowers users with simplicity, portability, and modularity. The NixOS approach streamlines system management, allowing for stable deployment on different machines. The modularity of Nix enables users to customize, extend, or reuse configurations with ease. Such a system not only simplifies the setup and maintenance of software but also significantly reduces the complexity associated with managing dependencies and system-specific variations.

Running an Old Windows Game

Recently, I wanted to revisit an old game I developed in 2012. To run this Windows-based executable on NixOS, I needed Wine, a Windows compatibility program. Using nix-shell -p wine, I quickly installed Wine CLI. Then ran my game with wine my_game.exe, and it just worked. When you exit nix-shell, the wine program is no longer available and did not clutter my user space. If you want to install anything permanently, you can; if you need to run a quick one-off, you can. Nix is clean and handles environment isolation brilliantly.

As a side note there is this incredible repository NixThePlanet which allows you to run “medieval” operating systems with a single nix command.

Stability and Reliability

NixOS introduces the concept of “generations,” allowing you to roll back to previous versions of your system while booting. If anything breaks or is not running as intended, you can always revert to a previous generation. Surprisingly, my new ASUS laptop, manufactured with Windows in mind, actually crashes way more often than NixOS. I believe there is some issue with the Nvidia hybrid settings on Windows that causes constant crashes, giving the blue screen of death (BSOD).

Common Issues and Troubleshooting

While NixOS has many advantages, it is not without its challenges:

Learning Curve

There is a steep learning curve that involves learning the Nix language and all the details of the Nix ecosystem. As a software developer that has dabbled in Linux distros, I really would never recommend this to any Linux beginner. I would recommend it to software developers that really value stability and portability or any intermediate/advanced Linux users that want the same.

Documentation

Unfortunately, the documentation is not good enough, but as more folks start embracing Nix, it should gradually improve.

Limited Binary Compatibility

NixOS doesn’t use the traditional /bin, /sbin, /lib directory structure but instead uses its own store paths. This can lead to compatibility issues with binary packages that expect a traditional Linux filesystem layout. In my case this did cause issues with my Neovim configuration some Mason binaries did not work as usual but I was generally able to solve the issue quickly by installing the binaries through the nixpkgs repo instead - they were all available and easy to lookup.

Integration with Other Systems

Because of its unique approach, integrating Nix or NixOS with tools and platforms expecting a more conventional Linux environment can be more involved. Although there probably is a Nix way to get it running, it may become time-consuming. However, once it is set up, it should work forever. I hope as Nix continues to grow, we will begin to see more integration and simpler compatibility.

Conclusion: Embracing the Nix Philosophy

This is all just putting my feet in the water; there is much more to the Nix ecosystem that makes life simpler as a software engineer. If you’re thinking about trying NixOS, I say just give it a shot. It will give you stability, easy reproducibility when adding a new machine, and peace of mind. The Nix philosophy has changed the way I view systems and software. This is how software should be.

Ariel Frischer: writing

From ~/.claude to ~/.omp: nine months of agent workflow

~/.claude/ (January): one agent and a task list

Off to the side: OpenCode (January to July)

~/.codex/ (from late April): Beads and worktrees

~/.jcode/ (from late July): a team with job titles

~/.omp/ (since September 24): Opus 5.5 and less process

Too many agents, so config became its own job

The setup edits itself now

New hands: omp on my phone

What I’d tell someone starting now

Autospec 0.12: a model per stage, and when I actually reach for specs

What’s new in 0.12

When I use it (and when I don’t)

Try it

kb 1.4: stop guessing whether your RAG settings help

The quick version

What’s new: kb eval

Other changes in 1.4

Try it

Locus: I'm building a software factory, and right now it mostly breaks

What it does

Why it breaks

What I’m changing

Where I want it to go

Why I use a different AI model for each coding job

Benchmarks don’t agree

The tool around the model matters too

What I use for what

If you’re setting this up yourself

profile-mango: one profile for all your coding agents

How it works

What it supports

What’s new in 0.2

What it isn’t

Try it

Neovim is Essential

Introduction

Why Neovim?

Customizability

Efficiency and Speed

Community

Cross-platform and Extensible

Modern Features

The Neovim Plugin Ecosystem

Pre-configured Neovim Repositories

General Features

Last Remarks

References

Nix & NixOS - First Impressions

Introduction

Nix* Ecosystem

Nix (The Package Manager)

Nix (The Programming Language)

NixOS (The Linux Distribution)

Nixpkgs (The Package Repository)

Installation of NixOS

Post-Installation Setup

The Power of Nix

Running an Old Windows Game

Stability and Reliability

Common Issues and Troubleshooting

Learning Curve

Documentation

Limited Binary Compatibility

Integration with Other Systems

Conclusion: Embracing the Nix Philosophy

Resources for Learning Nix

What’s new: `kb eval`