DEV Community: Kamil

Who Benefits Most From AI?

Kamil — Tue, 11 Aug 2026 17:09:00 +0000

I recently came across a post that started a chain of thought for me. The claim was that senior developers — people with many years in the industry — gain the most from AI tools, while their junior colleagues have far more to lose than to gain by leaning on them.

I've been thinking about it since.

Disclaimer: I'm by no means a senior in the tech space. I value and understand that knowledge gained through experience and hardship has tremendous value and shouldn't be overlooked. But being on the other side of that line is probably what makes the question worth asking out loud.

Chapter I — Use It or Lose It

Let me start with the obvious part: what we don't use atrophies eventually. This is true across fields and industries and has stood the test of time. Muscles, languages, mental arithmetic, sight-reading music. Why would tech be different?

The version of the argument I keep hearing goes something like this. Experienced developers have seen enough issues and bugs to spot when AI is suggesting something that won't work. A junior raises their first PR and gets thirty comments asking them to fix things they didn't know were problems. That kind of foresight can't be bought or simulated — it's paid for in incidents, bad deploys, and reviews that stung a bit.

So far, so good. But there's a hole in it, and it's the same hole "use it or lose it" always has.

If atrophy is real, it applies to everyone.

The senior's advantage isn't a permanent trait. It's accumulated capital. It was built by reading a lot of code closely, sitting with bugs longer than was comfortable, and being wrong enough to develop taste. If that same person spends the next three years reviewing generated code at speed instead of writing and debugging it themselves, that capital doesn't sit there gathering interest. It depreciates like anything else.

Which changes the question. It's not "who benefits most?" It's "who can afford this, and for how long?"

Chapter II — What Juniors Actually Lose

I don't think the risk for junior developers is that they'll know less. You can look things up. The risk is more specific, and it's worth naming precisely.

What juniors are missing isn't knowledge. It's an evaluation function — the ability to look at a plausible-looking solution and tell whether it's actually right.
That's the whole game with these tools. The output is fluent and confident whether or not it's correct. A senior reads a suggestion and somethings stand out: that error handling is wrong, that query is going to hurt at scale, that's not how this library actually behaves. A junior reads the same suggestion and it looks... fine. It looks like code. It compiles.

And here's the uncomfortable part: the evaluation function gets built by doing exactly the work the tool removes. You learn what bad code feels like by writing bad code and then living with it. You develop a sense for where bugs hide by hunting one badly for two days before finding it.

There's a term for this in learning research — desirable difficulty. Struggle that feels inefficient in the moment is often the thing that makes the learning stick. AI is extremely good at removing precisely that kind of friction.

Chapter III — Replacing the Attempt vs. Reviewing It

I don't want to land on "juniors shouldn't use AI," though, because I don't believe it and it isn't what actually happens.

Juniors were never learning through pure suffering anyway. They were learning through suffering with feedback — a senior on the PR, someone pairing with them, a review that explained the why. The struggle mattered because someone was there afterwards to tell them what the struggle meant.

So the useful line isn't AI vs. no AI. It's:

Does the tool replace my attempt, or respond to it?

Ask it to write the function before you've thought about the problem, and you've outsourced the thinking. Write your version first, then ask what's wrong with it, and you've gained a reviewer with infinite patience. Same tool, opposite outcomes. The order of operations is the whole thing.

This is also where the point I keep coming back to lives. Working with AI genuinely helps when you're rubber-ducking through a problem, or when you want to ask every question you have without worrying that you sound like you don't know what you're doing. That's real, and I don't think people who've never been the most junior person in the room appreciate how real it is.

But it comes with a cost worth naming. A junior's questions are signals. They tell the team where the gaps are, what onboarding missed, who's stuck this week. When all of those questions go to a chat window instead, the team loses that signal — and the junior loses a hundred small chances to build a relationship with someone who could actually mentor them.

Ask the model. Then still ask the person.

Chapter IV — Which Skills Are Safe to Lose?

Every abstraction we've adopted has cost us a skill, and we mostly decided it was worth it. Very few of us write assembly by hand. Most of us couldn't manage memory manually under pressure. Compilers, IDEs, garbage collection, Stack Overflow — each arrived with someone predicting the rot of a generation of programmers.

Sometimes they were right, and it didn't matter.

So maybe the better question isn't whether AI causes skill atrophy. It obviously does; everything does. The question is which skills are load-bearing.

My rough attempt at the line:

Probably safe to outsource — syntax recall, boilerplate, the argument order of a standard library function, the flags for a CLI you touch twice a year.

Not safe to outsource — telling whether code does what you think it does. Holding a system in your head. Debugging something nobody has written a blog post about. Knowing which question to ask.

The first list is lookup. The second is judgment. Tools have always been fine at replacing lookup. This is the first one that convincingly imitates judgment, which is what makes it different, and what makes it worth being deliberate about.

Chapter V — So, Who Benefits Most?

I started this with someone else's claim: seniors gain the most, juniors have the most to lose. Four chapters later I'm not sure it's a question about seniority at all. I think it's a question about what you're spending, and whether you've ever looked at the price.

I don't have an answer for you. I'm not convinced the answer transfers between people anyway. But these are the questions I've ended up asking myself, and I'd rather hand them over than pretend I've resolved them.

If your judgement is capital, when did you last add to it? Not spend it — add to it. Reviewing generated code at speed draws down the reserve. What's been topping it back up?

When you reach for the tool, is it replacing your attempt or responding to it? Be honest about the order of operations. Most of us know which one we did.

Which of the skills you're shedding are lookup, and which are judgement? And would you notice the difference before the moment you actually needed it?

What's the last thing you did the hard way on purpose? If nothing comes to mind quickly, that's information.

And the one sitting underneath all of them: what are you optimising for? Shipping this week, or still being worth something in five years? Both are legitimate. Plenty of people have good reasons to choose the first — deadlines are real, rent is real. But it's a trade, and trades go badly when you don't know you're making one.

So — who benefits most from AI?

My best guess is: whoever knows what it's costing them and has decided the price is worth paying.

Which one is that for you?

One keystroke to a project: building a tmux session launcher with fzf

Kamil — Sun, 02 Aug 2026 15:19:27 +0000

I hit Ctrl-F more than any other key combination on this machine.

It runs a shell function called fts — "find tmux session," which is not a good name but it's four years too late to change it. I press it, a fuzzy finder opens listing every project directory I have, I type a few characters, and I'm sitting in a tmux session for that project with the panes already laid out. If the session already existed, I'm back in it exactly where I left off. If what I typed doesn't exist yet, it offers to create it.

Somebody watched me do this over a screen share recently and asked what was going on. So: here's the whole thing, the four tools it's built on, and a breakdown of every part that isn't obvious.

What you'll end up with:

One keystroke from anywhere to any project
Fuzzy search across every repo you own, with a live directory tree preview
Type a name that doesn't exist → it offers to scaffold and place it
Never accidentally start a second tmux session for a project you already have open
The same window/pane layout in every project, every time

The problem it solves

Before this, starting work looked like:

cd ~/repo/work/some-project-i-half-remember-the-name-of
tmux new-session -s some-project
# split some panes, badly, slightly differently each time

Three or four commands, one of which needed me to remember a path. None of it hard. All of it friction at exactly the wrong moment — the moment you've decided to start something, which is the moment you're most likely to get distracted instead.

I'd also collected tmux sessions named 0, 1, 2 and some-project-2, because I kept starting new ones instead of attaching to the one already running.

So the goal wasn't really speed. It was making the right thing the automatic thing.

Prerequisites

Four tools plus zsh. All four are worth having on their own, and three of them are things you'll reach for daily once installed.

Tool	Version I'm on	What it does here
tmux	3.6a	The terminal multiplexer. Holds the sessions, windows and panes.
fzf	0.67.0	The fuzzy finder. Every picker in this function is fzf.
fd	10.3.0	A faster, friendlier `find`. Generates the list of directories.
eza	0.23.4	A modern `ls`. Draws the tree preview inside fzf.
zsh	5.9	The shell. `read -q` and the `zle` keybinding are zsh-specific.

Install

macOS (Homebrew):

brew install tmux fzf fd eza

Debian / Ubuntu:

sudo apt install tmux fzf fd-find
# eza needs its own repo on older releases — see eza-community/eza#installation
# and note the fd binary is called `fdfind` on Debian; symlink or alias it to `fd`

Arch:

sudo pacman -S tmux fzf fd eza

Why these, specifically

fd over find. The important part isn't speed, it's that fd respects .gitignore by default. Without that, the picker list is 90% node_modules and the whole thing is unusable. You can do the same with find and a pile of -prune flags, but you'll write them once and never touch them again.

eza over tree. eza --tree --level=2 --color=always --icons is one command that gives a colourised, icon'd, gitignore-aware two-level tree. tree can get close but not with the same flags-to-output ratio.

fzf. No substitute. --print-query in particular — covered below — is what makes the create-if-missing flow possible at all.

tmux ≥ 1.8 for the commands used here. Anything from the last decade is fine.

Bash instead of zsh?

The function is mostly POSIX-ish, but three bits are zsh:

read -q "confirm?Proceed? [y/N] " → in bash: read -n 1 -p "Proceed? [y/N] " confirm
<<<"$fzf_out" (herestring) → bash has this too, you're fine
The zle widget at the end → bash equivalent is bind -x '"\C-f": fts'

Everything else ports directly.

The full function

Copy-paste this into your ~/.zshrc. The only thing you need to change is FTS_ROOT — mine is ~/repo, with projects grouped one level deeper into work, learning, college, openSource.

# ---- fts: find tmux session ----
FTS_ROOT="${FTS_ROOT:-$HOME/repo}"

fts() {
  local dir query selection fzf_out

  # --print-query: line 1 = typed query, line 2 = selected match
  fzf_out=$(fd --type d . "$FTS_ROOT" 2>/dev/null | fzf \
    --height 40% \
    --reverse \
    --print-query \
    --prompt="Directory: " \
    --preview 'eza --tree --level=2 --color=always --icons --ignore-glob "node_modules" {}' \
    --preview-window=right:50%)

  query=$(sed -n '1p' <<<"$fzf_out")
  selection=$(sed -n '2p' <<<"$fzf_out")

  if [[ -n "$selection" ]]; then
    dir="$selection"
  elif [[ -n "$query" ]]; then
    # No match, but something was typed → treat it as a new project name
    local sanitized
    sanitized=$(echo "$query" | tr -cs 'a-zA-Z0-9_-' '-' | sed 's/^-//;s/-$//')
    [[ -z "$sanitized" ]] && return

    local parent
    parent=$(fd --type d --max-depth 1 . "$FTS_ROOT" 2>/dev/null | fzf \
      --height 30% \
      --reverse \
      --prompt="Create '$sanitized' inside: ")
    [[ -z "$parent" ]] && return

    dir="${parent%/}/$sanitized"

    echo "Creating $dir"
    read -q "confirm?Proceed? [y/N] " || { echo; return }
    echo
    mkdir -p "$dir"
  else
    return  # escaped out — do nothing
  fi

  local session_name
  session_name=$(basename "$dir" | tr ' ./:' '_' | tr -s '_')

  # Already running? Attach and stop.
  if tmux has-session -t "$session_name" 2>/dev/null; then
    if [[ -n "$TMUX" ]]; then
      tmux switch-client -t "$session_name:main"
    else
      tmux attach-session -t "$session_name:main"
    fi
    return
  fi

  # Window 1 (main): single pane
  tmux new-session -d -s "$session_name" -c "$dir" -n main

  # Window 2 (dev): big left pane, two stacked on the right
  tmux new-window   -t "$session_name"       -c "$dir" -n dev
  tmux split-window -h -t "$session_name:dev" -c "$dir"
  tmux split-window -v -t "$session_name:dev" -c "$dir"
  tmux select-pane  -t "$session_name:dev" -L

  tmux select-window -t "$session_name:main"

  if [[ -n "$TMUX" ]]; then
    tmux switch-client -t "$session_name"
  else
    tmux attach-session -t "$session_name"
  fi
}

# ---- bind it to Ctrl-F ----
fts-widget() {
  BUFFER="fts"
  zle accept-line
}
zle -N fts-widget
bindkey '^F' fts-widget

Then source ~/.zshrc and hit Ctrl-F.

The rest of this post is what each part is doing and why.

Step 1: the picker, and the `--print-query` trick

fzf_out=$(fd --type d . "$FTS_ROOT" 2>/dev/null | fzf \
  --height 40% \
  --reverse \
  --print-query \
  --prompt="Directory: " \
  --preview 'eza --tree --level=2 --color=always --icons --ignore-glob "node_modules" {}' \
  --preview-window=right:50%)

Flag by flag:

--height 40% — fzf renders in the bottom 40% of the terminal instead of taking the whole screen. Your scrollback stays visible, which makes it feel like a prompt rather than a mode you've entered.
--reverse — list grows downward from the prompt at the top. Personal preference; try both.
--prompt="Directory: " — labels what you're picking. Matters more once you have several fzf-driven tools and they all look identical.
--preview — runs a command on the highlighted line. {} is substituted with that line.
--preview-window=right:50% — where the preview goes.

The preview was a late addition and it changed how the tool feels. When you've got three directories with similar names, two levels of tree tells you instantly which one is the real project and which one you abandoned in March.

Now the important flag. --print-query.

By default fzf prints what you selected. With --print-query, it prints two lines: what you typed, then what you selected. If your query matched nothing, line two is empty.

query=$(sed -n '1p' <<<"$fzf_out")      # line 1
selection=$(sed -n '2p' <<<"$fzf_out")  # line 2

That's the whole trick. An empty line two isn't a failure — it's a different intent. You didn't fail to find a project, you named one that doesn't exist yet. The picker becomes a creator with no second command and no flag, and I never have to decide which mode I'm in before I start typing.

Three branches follow:

if   [[ -n "$selection" ]]; then  # picked something → open it
elif [[ -n "$query"     ]]; then  # typed something unmatched → create it
else                              # nothing at all → do nothing

That third branch matters as much as the others. Hitting Esc has to be completely free. A tool you reach for reflexively needs a zero-cost way to back out, or you stop reaching for it reflexively.

Step 2: creating a project, carefully

This is the only place fts touches the filesystem, so it's the only place it asks permission.

sanitized=$(echo "$query" | tr -cs 'a-zA-Z0-9_-' '-' | sed 's/^-//;s/-$//')

tr -cs 'a-zA-Z0-9_-' '-' reads as: take the set of alphanumerics, hyphen and underscore; -c complements it (so we're now matching everything not in that set); replace those with -; -s squeezes runs of the replacement into one.

So my new API client!! becomes my-new-API-client-, and the sed trims the leading/trailing hyphen → my-new-API-client. It's there because I type project names in prose and don't want to think about casing or spaces.

parent=$(fd --type d --max-depth 1 . "$FTS_ROOT" 2>/dev/null | fzf \
  --height 30% --reverse --prompt="Create '$sanitized' inside: ")

A second fzf, this time --max-depth 1, to pick which top-level bucket it lands in. That's my taxonomy, but the idea generalises: a new directory needs a home, and picking one from a list beats typing a path.

read -q "confirm?Proceed? [y/N] " || { echo; return }

read -q is zsh's single-keypress read — it returns 0 only on y/Y, and the text after the ? is the prompt. It's the last gate before anything is written. I'd keep it even though it costs a keystroke every time, because a fuzzy finder that silently creates directories on a typo is one you learn to distrust.

Step 3: naming the session

session_name=$(basename "$dir" | tr ' ./:' '_' | tr -s '_')

tmux session names can't contain . or : — those are its own separators for windows and panes, so mysession:dev already means something. Spaces are legal but painful to type in -t targets. All three get mapped to _, and tr -s '_' squeezes runs down to one so my..project doesn't become my__project.

Step 4: the check that stops duplicate sessions

if tmux has-session -t "$session_name" 2>/dev/null; then
  if [[ -n "$TMUX" ]]; then
    tmux switch-client -t "$session_name:main"
  else
    tmux attach-session -t "$session_name:main"
  fi
  return
fi

This is the highest-value block in the function. has-session exits 0 if a session by that name exists — check first, attach if it's there, build only if it isn't. fts on a project I opened this morning is a two-keystroke return to exactly where I was. fts on a fresh one builds it. Same command either way, and I never have to know which case I'm in.

The $TMUX gotcha. $TMUX is set whenever you're inside a tmux session. If you are and you call attach-session, you get nested tmux — a session rendered inside a session, two status bars, and a prefix key that now goes to the wrong one. What you actually want from inside tmux is switch-client, which moves your existing client to a different session.

Every tmux helper script I've written has needed this branch eventually. If you write your own, put it in from the start.

Step 5: building the layout

tmux new-session -d -s "$session_name" -c "$dir" -n main

tmux new-window   -t "$session_name"       -c "$dir" -n dev
tmux split-window -h -t "$session_name:dev" -c "$dir"
tmux split-window -v -t "$session_name:dev" -c "$dir"
tmux select-pane  -t "$session_name:dev" -L

tmux select-window -t "$session_name:main"

Two flags carry most of the weight:

-d creates the session detached, so all the setup happens off-screen. Without it you'd watch the panes get built.
-c "$dir" sets the working directory for the session and every window/pane created with it. Without this everything starts in $HOME and you cd four times.

The targeting syntax is session:window — "$session_name:dev" means "the window called dev in this session". split-window -h splits horizontally (side by side), -v vertically (stacked). select-pane -L moves focus to the pane on the Left.

What you get:

┌─ main ────────────────┐   ┌─ dev ──────────┬──────────┐
│                       │   │                │  server  │
│      (NeoVim)         │   │   (editor /    ├──────────┤
│                       │   │    scratch)    │   logs   │
└───────────────────────┘   └────────────────┴──────────┘

main is one full-width pane — editor, or an agent, or whatever I'm actually doing. dev is a big left pane with two stacked on the right: dev server top, tests or logs bottom.

The last select-window returns to main, so dev sits pre-arranged and waiting the first time I switch to it rather than needing setup mid-flow.

I'm not proposing this layout — it's just the one I converged on. The value isn't the arrangement, it's that it's the same arrangement every time, so my hands know where things are without looking.

Step 6: binding it to a key

Running fts still meant typing fts. Three characters, but three characters at the shell prompt, competing with whatever I was half-typing.

fts-widget() {
  BUFFER="fts"
  zle accept-line
}
zle -N fts-widget
bindkey '^F' fts-widget

This is zle, the Zsh Line Editor:

BUFFER is the current command line as a string. Assigning to it replaces whatever you'd typed.
zle accept-line presses Enter for you.
zle -N fts-widget registers the function as a widget so it can be bound.
bindkey '^F' fts-widget maps Ctrl-F to it. ^F is zsh notation for Ctrl-F.

Ctrl-F normally moves the cursor forward one character in emacs mode. I never used it — right arrow exists. Check what you're overwriting with bindkey | grep '\^F' before you take a binding, but do take one. The difference between a three-character command and a keystroke is the difference between a tool you use and a tool you use without thinking about it, and only the second kind actually changes anything.

Bash version:

bind -x '"\C-f": fts'

Troubleshooting

"Nothing shows up in the picker." fd respects .gitignore and skips hidden directories. If your projects live somewhere ignored, add --hidden --no-ignore — you'll want a --exclude .git alongside it.

"sessions have weird truncated names." basename on a path with a trailing slash returns something you didn't expect. ${dir%/} strips it; add that if you're feeding paths in from elsewhere.

"I get two status bars." That's nested tmux — see the $TMUX check in step 4.

"read -q : command not found." You're in bash. Use read -n 1 -p "Proceed? [y/N] " confirm and test [[ $confirm == [yY] ]].

"The preview is blank." eza isn't installed or isn't on PATH inside fzf's subshell. Test with eza --tree --level=2 . first.

Making it yours

The two things most worth changing:

The root. Set FTS_ROOT in your .zshrc before the function, or export it per-machine. If your projects aren't under a single tree, feed fzf multiple fd calls:

{ fd --type d . ~/repo; fd --type d --max-depth 2 . ~/work; } | fzf ...

The layout. Everything in step 5 is just tmux commands. Want three windows? Add another new-window. Want a server running the moment the session exists?

tmux send-keys -t "$session_name:dev.{top-right}" 'bun dev' C-m

C-m is Enter. Note the {top-right} rather than a pane number — tmux accepts positional pane targets, and they're worth using here because numeric indices depend on whether you've set pane-base-index 1 in your tmux.conf. I have, so dev.1 on my machine is the left pane and on a default install it's the top right. Positional targets don't care.

I don't actually do this — different projects have different start commands and I'd rather type it than have the wrong one fire — but it's one line if you want it.

What I'd still change

Some honesty, since it's easy to write a post like this and imply the thing is finished:

Session names collide on basename. ~/repo/work/api and ~/repo/learning/api both want to be api, and the second silently attaches to the first. I've been lucky rather than careful. The fix is to derive the name from the path relative to FTS_ROOT — work_api, learning_api.

It doesn't know about git worktrees. They show up as ordinary directories, so you can end up with a session per worktree and nothing in the name telling you which branch you're in.

Every project gets the same two windows. A Go CLI and a Next.js app get identical treatment. A .tmux-layout file it checked for would be the obvious next step; I keep not writing it because the generic layout has been fine.

None of these have cost me enough to fix, which is worth stating plainly. This is a tool that's been good enough for a long time, not one that's been polished.

Takeaways

If you don't want fts specifically, take the shape:

Find the friction that isn't hard, just repeated. Mine was four commands and a remembered path. It never registered as a problem because no single instance was one.
Make the right thing automatic, not just fast. The has-session check is the most valuable line here and it has nothing to do with speed — it makes the correct behaviour the one that takes no thought.
Handle the miss. --print-query turned "you typed something that doesn't exist" from an error into a feature. Plenty of tools have a branch like that sitting unused.
Bind it. An unbound tool is one you have to decide to use.

The whole thing lives in my .zshrc between an alias block and a function that opens the current repo's PR page in a browser. No tests, no repo, no README. Best return-on-effort code I've written this year, and it took an afternoon.

Not everything has to be a project.

If you build a version of this, I'd genuinely like to see it — especially the layout section, since that's the part everyone does differently.

Did I really build this?

Kamil — Sat, 01 Aug 2026 17:14:37 +0000

Lately I've been thinking about the things we build with AI. And I keep landing on the same question. Did I really build this? Or did I just foresee it being built?

Chapter 1 — Confusion

The steps are always the same. I get an idea, or I see something online and think "I bet I could make that, or at least put my own spin on it." New project, Neovim, agent pane on the side.

And then I sit there.

I stare at the empty screen and the blinking cursor for a while, and eventually I give in and explain the idea to Claude Code, and watch it try to build something out of a prompt I hadn't really thought through yet.

While it Ponders and Ruminates, I get this vague feeling. Am I the creator of this project? Can I say it's mine? I'm in the passenger seat doing the directing, sure. Making the calls on what goes in and what stays out. But at what point do I stop being the creator, or even the orchestrator, and start being the approver of a machine's output?

Some of you will say that's just the nature of coding with AI now. Less about writing code, more about understanding the system behind it. Fair enough. An agent writes more code in a minute than I could in thirty and I'm not going to sit here and argue with that.

I started learning to code at a funny time. I was working my way through The Odin Project, getting to grips with web development, and ChatGPT was released at the end of that same year. The ground shifted while I was still figuring out the basics.

I remember being away on holiday, four hours into a flight with no internet, working on a Christmas-themed programming assignment. I spent the whole flight trying to simulate the mechanics of falling snowballs and get the engine working under the hood, while also questioning why our professor had us learning Java in BlueJ of all things. Still haven't figured that one out.

I remember that project to this day. The frustration and the satisfaction in equal measure. Five years later I can still recall the exact feeling of getting it to behave the way I wanted, and how completely mine it felt.

Chapter 2 — Connection

That flight wouldn't be a problem now. It would be a Wi-Fi purchase.

I've shipped more in the last year than in the two or three before it combined. Things that used to sit in a "someday" note get built on a Saturday. And most of them work. I want to be clear that this isn't a complaint about quality, because the code is usually fine. Sometimes it's better than what I'd have written on my own.

But I notice I don't feel much about them.

For a while I assumed that was about understanding. That if I read the diffs properly, if I could hold the whole system in my head the way I used to, the feeling would come back. So I tried it. Reviewed one project line by line like I was being paid to do it, and by the end I understood it completely.

It still felt like something I'd found rather than something I'd made.

So it wasn't understanding I was missing. It was connection to the thing. And the connection came from the hours.

I keep coming back to that phrase, hours in the saddle. Pilots log them. Riders log them. Nobody logs how much of the manual they've read, because reading the manual isn't the thing. The hours are the thing. You put the time in and slowly you stop thinking about the machine and start thinking through it.

That's what those four hours on the plane bought me. Not knowledge about falling snowballs, which honestly I could have got off one page of documentation. A feel for that specific program. By the end of the flight I knew where everything was because I'd put it there. I knew which part was held together with tape because I was the one who taped it. When something broke I didn't really debug it so much as reach for it, the way you reach for a light switch in your own house in the dark.

I don't have that with the projects I've built this year. I know where the files are because I looked. I know how the auth flow works because I read it back. It's all correct and none of it is in my hands.

And it isn't credit I'm after, or authorship, nothing that grand. It's just the ordinary familiarity that comes from spending long enough with something that it stops being separate from you.

You can be handed an understanding of a system. Nobody can hand you a feel for one.

Chapter 3 — Now what

I don't have a good ending for this, which is part of why I wanted to write it down.

The obvious answer is to go back to doing it all by hand, and I don't buy that. I've seen what I get done now compared to three years ago and I'm not giving that up to feel more authentic about it. The hours weren't precious in themselves either. Plenty of them went on things I'd happily never do again.

So I've been trying things instead. They're all the same question asked in different ways: what do I keep for myself.

Writing the first version myself and letting the agent take it from there, on the theory that the early hours are the ones that stick. Picking one part of each project, the part I actually care about, and refusing to hand it over. Going slower on the things I intend to keep and fast on the things I don't. Going back to something I don't recognise and rewriting a piece of it by hand just to get dirty in it, even though the code was fine as it was.

Some of that helps. Though I can't tell yet whether it helps because it works, or because it makes me feel better, and I'm suspicious of anything I can't tell that about.

Maybe the feeling doesn't come back in the same form. Maybe it moves somewhere else, into problems rather than programs. That would be fine, I think. I'd just like to know.

For now, the honest answer to did I really build this is: some of them, yes. Some of them I watched get built.

I'm still working out how to tell which is which before I start, rather than a month after I've finished.