​

I am tracking this in public because nobody else is.

Every tutorial I found assumed you already knew what a terminal was. Every "build with AI" post skipped straight to the output. Nobody documented the part where you type ls - la instead of ls -la and spend twenty minutes confused about why nothing works.

That is the part worth documenting.

The honest starting point

I started last week with a YouTube video from a senior engineer who ships 40 to 50 pull requests a day using an agentic workflow built entirely in the terminal. His tools: WezTerm, tmux, Neovim, Codex CLI, OpenCode, Treehouse, Lavish, and a PR pipeline called no-mistakes.

His background: two decades of engineering at some of the largest software systems ever built.

My background: seven years translating technical work for a living. I have never committed code to a repository.

I decided to build his setup anyway.

What actually happened

By the end of the week, here is what was working on my machine:

• WezTerm installed and configured with Lua. This is the terminal emulator — the window where everything runs.
• zsh as my shell. This is the interpreter that reads commands. I did not know the difference between a terminal emulator and a shell until day two.
• tmux running with splits, panes, and persistent sessions. I practiced detach, attach, copy mode, and clipboard integration.
• Codex CLI installed and loading my global agent instructions. I used it to inspect and edit files in my practice repository.
• OpenCode installed through Homebrew. I corrected the binary path after it pointed to an old install.
• GitHub CLI authenticated and working. I created my first public repository.
• gh-axi installed as a token-efficient GitHub wrapper for agents.
• Treehouse installed and tested. I created an isolated worktree, practiced branching inside it, and learned why you must create a branch before committing inside a worktree.
• Lavish AXI installed and working. I generated my first visual planning artifact.
• no-mistakes installed and initialized. I pushed a branch through the full pipeline: intent, rebase, AI review, test, document, lint, push, PR, CI monitoring. PR #2 was created automatically on GitHub.

That is the full Kun Chen stack. Operational in one week. Starting from zero.

What surprised me

Three things I did not expect.

First: The environment is harder to set up than to use. Once everything was running, the actual workflow made sense. The friction was entirely in the installation and configuration. This is the part that stops people before they start.

Second: The concepts are not actually technical. Git tracks changes the way a document version history works. A branch is a parallel draft. A pull request is a structured review. A worktree is a second copy of your draft open in a different window. The mental model is accessible. The vocabulary just sounds intimidating.

Third: The macOS permissions issue is real and invisible. Codex, Terminal, and WezTerm did not have Full Disk Access by default. That caused silent failures I could not explain for hours. Enabling Full Disk Access and restarting fixed it. Nobody talks about this.

Why this matters for your work

I am a TPM. My job is to understand how technical work gets done and coordinate the people doing it.

For seven years, I have operated at the edge of engineering without being inside it. I knew what a PR was. I did not know how to make one.

That gap is getting more expensive.

The people who understand how AI-assisted engineering actually works — not in theory, not in demos, but in a real terminal with real commits — are going to have a different kind of influence in the next few years. Not because they write more code. Because they understand what their agents are doing.

That is why I am building this in public.

The named concept: The Adjacency Advantage

You do not need to become an engineer to benefit from learning how engineers work.

You need to close the adjacency gap — the distance between your current mental model and the mental model of the people you coordinate, lead, or work alongside.

Most ICs in operational and program roles have never touched the tools. They have opinions about tools. They write documents about tools. But they have not felt what it is like to run a command, watch it fail, and figure out why.

That experience changes how you think. It changes the questions you ask. It changes the credibility you carry in rooms where technical decisions get made.

You do not need to ship production code to close the adjacency gap. You need one week.

What I'm doing next

The next steps in Kun's workflow are gnhf (good night, have fun) and firstmate. These are the tools that let you run multiple agents in parallel and manage them from a single point of coordination.

I will document both as I go.

If you want to follow along, my GitHub is public: github.com/thewyattbrocato​

Everything is in the open. The commits, the confusion, the progress.

What is the closest you have gotten to the technical work in your job? Hit reply and tell me. I am genuinely curious where people draw the line.

P.S. If this is useful, forward it to someone on your team who thinks this world is not for them. It definitely is.

​