Here are a couple scripts that will achieve it (courtesy of opencode and the new codex-5.3 model).

It’s tailored to my setup:

• macos
• Kitty terminal emulator
• tmux running locally

Example invocation:

./tmux-notify-return.sh <title> <message>

It’s probably a little brittle, but I think it will address a pain point I’ve been facing with a flurry of agents running across different tmux windows and panes.

Here are the scripts:

tmux-return.sh

What it does: click-handler script run by Notification Center; activates Kitty, switches the correct tmux client/window/pane, and retries briefly to avoid focus races.

#!/usr/bin/env bash
set -euo pipefail

if [[ $# -lt 4 || $# -gt 5 ]]; then
  echo "Usage: $0 <client_tty> <socket_path> <target_win> <target_pane> [target_pane_id]" >&2
  exit 2
fi

client_tty="$1"
socket_path="$2"
target_win="$3"
target_pane="$4"
target_pane_id="${5:-}"

TMUX_BIN="/opt/homebrew/bin/tmux"
OSA_BIN="/usr/bin/osascript"

"$OSA_BIN" -e 'tell application id "net.kovidgoyal.kitty" to activate'

for _ in 1 2 3 4 5 6 7 8 9 10; do
  "$TMUX_BIN" -S "$socket_path" switch-client -c "$client_tty" -t "$target_win" || true
  "$TMUX_BIN" -S "$socket_path" select-window -t "$target_win" || true

  if [[ -n "$target_pane_id" ]]; then
    "$TMUX_BIN" -S "$socket_path" select-pane -t "$target_pane_id" || true
  else
    "$TMUX_BIN" -S "$socket_path" select-pane -t "$target_pane" || true
  fi

  if [[ -n "$target_pane_id" ]]; then
    current_pane="$("$TMUX_BIN" -S "$socket_path" display-message -p -c "$client_tty" '#{pane_id}' 2>/dev/null || true)"
    [[ "$current_pane" == "$target_pane_id" ]] && exit 0
  else
    current_pane="$("$TMUX_BIN" -S "$socket_path" display-message -p -c "$client_tty" '#{session_name}:#{window_index}.#{pane_index}' 2>/dev/null || true)"
    [[ "$current_pane" == "$target_pane" ]] && exit 0
  fi

  sleep 0.1
done

exit 1

tmux-notify-return.sh

What it does: captures the tmux pane running this command (TMUX_PANE), then sends a clickable notification whose click runs tmux-return.sh back to that captured pane.

#!/usr/bin/env bash
set -euo pipefail

# Send a clickable macOS notification that returns you to the tmux pane
# where this command was run.
TMUX_BIN="/opt/homebrew/bin/tmux"
NOTIFIER_BIN="/opt/homebrew/bin/terminal-notifier"
RETURN_SCRIPT="/path/to/tmux-return.sh"

if [[ "${1:-}" == "-h" || "${1:-}" == "--help" ]]; then
  echo "Usage: $0 [title] [message]"
  echo "  title   Notification title (default: Return to tmux pane)"
  echo "  message Notification body  (default: Click to jump back in Kitty)"
  exit 0
fi

title="${1:-Return to tmux pane}"
message="${2:-Click to jump back in Kitty}"

if [[ ! -x "$TMUX_BIN" ]]; then
  echo "tmux not found at $TMUX_BIN" >&2
  exit 1
fi

if [[ ! -x "$NOTIFIER_BIN" ]]; then
  echo "terminal-notifier not found at $NOTIFIER_BIN" >&2
  exit 1
fi

if [[ ! -x "$RETURN_SCRIPT" ]]; then
  echo "return script not executable: $RETURN_SCRIPT" >&2
  exit 1
fi

# Capture the pane that is actually running this process when possible.
# In tmux shells, TMUX_PANE is stable even if the user navigates away later.
source_pane="${TMUX_PANE:-}"

if [[ -n "$source_pane" ]]; then
  target_win="$("$TMUX_BIN" display-message -p -t "$source_pane" '#S:#I')"
  target_pane="$("$TMUX_BIN" display-message -p -t "$source_pane" '#S:#I.#P')"
  target_pane_id="$("$TMUX_BIN" display-message -p -t "$source_pane" '#{pane_id}')"
else
  target_win="$("$TMUX_BIN" display-message -p '#S:#I')"
  target_pane="$("$TMUX_BIN" display-message -p '#S:#I.#P')"
  target_pane_id="$("$TMUX_BIN" display-message -p '#{pane_id}')"
fi

client_tty="$("$TMUX_BIN" display-message -p '#{client_tty}')"
socket_path="$("$TMUX_BIN" display-message -p '#{socket_path}')"

if [[ -z "$client_tty" || -z "$socket_path" || -z "$target_win" || -z "$target_pane" || -z "$target_pane_id" ]]; then
  echo "failed to capture tmux target metadata" >&2
  exit 1
fi

printf -v q_client '%q' "$client_tty"
printf -v q_socket '%q' "$socket_path"
printf -v q_win '%q' "$target_win"
printf -v q_pane '%q' "$target_pane"
printf -v q_pane_id '%q' "$target_pane_id"

exec_cmd="$RETURN_SCRIPT $q_client $q_socket $q_win $q_pane $q_pane_id"

"$NOTIFIER_BIN" \
  -title "$title" \
  -subtitle "$target_pane" \
  -message "$message" \
  -execute "$exec_cmd"

Some of my recentish posts are already dated and seem obvious now:

• https://matthewbilyeu.com/blog/2025-08-04/agentic-git-bisect
• https://matthewbilyeu.com/blog/2025-07-10/coding-with-agent-helper-scripts

I’ve been having this feeling on and off since 2022, but I need to check most impulses to build any significant low-level (close to the model) customization on top of what’s offered. It’s invariably only a matter of (short) time until the foundation models overcome the next crop of limitations and the harnesses fill more ergonomic gaps. It feels like Skills are getting to a good place, but there’s still quite a lot of thrash around security best practices, MCP vs direct CLI/SDK/cURL, orchestration, and agent to agent communication.

 This command uses a binary search algorithm to find which commit in your project’s history introduced a bug. You use it by first telling it a “bad” commit that is known to contain the bug, and a “good” commit that is known to be before the bug was introduced. Then git bisectpicks a commit between those two endpoints and asks you whether the selected commit is “good” or “bad”. It continues narrowing down the range until it finds the exact commit that introduced the change.

In fact, git bisect can be used to find the commit that changed any property of your project; e.g., the commit that fixed a bug, or the commit that caused a benchmark’s performance to improve.

In the hands of an AI agent coding assistant like Claude Code, git bisect can quickly find that property change event for you with very little intervention. Connect it to tools like Jira and GitHub and code archaeology is much faster.

A technique that helps is to prompt the agent to write a small helper script to test some functionality — like interfacing with an API or database or evaluating an algorithm with particular inputs. The agent can then invoke that small script itself quickly, view debug output, and plan its next move. It takes me out of that loop and makes the whole experience smoother. It’s not quite a unit test or full integration test, just some throwaway code to give the agent a feeler into the environment.

The first time I programmed a computer I was in high school. I learned to write small Visual Basic programs in an elective class called Computer Programming. Instantly, I “got it” (though at the time it wasn’t crisply articulated in my mind): that a program was a machine that operated on information rather than matter; that writing code was like building such a machine; and that the computer could automate any informational work that could be precisely described to it. Writing code was the way to conjure informational machines.

As I learned, there was a long while where I didn’t really know what I was doing. I didn’t grasp recursion or object orientation too well at first. As I did my many assignments and projects, I was feeling my way through the dark. In those days I did plenty of guess and check debugging. And this continued as I exposed myself to new languages, paradigms, and technologies. I didn’t always immediately know whether or not some code I’d cobbled together would do the thing I wanted, but I knew what I wanted it to do. I could explain it pretty clearly in English, and I could tell whether the goal had been sufficiently satisfied when I ran the program and the tests passed. This was not exactly fun, but it triggered some reward circuit in my brain. Run the code: it fails; tweak this part: it fails differently, interesting; move that there: it works!

These two paths intertwined and developed into a love of building: first, the slow satisfaction of inventing something useful that essentially existed only in the world of ideas, and second, the pleasant thrum of hitting goal after goal.

Once I’d actually more or less figured out what I was doing, the shine wore off a bit. I understood that software could merely appear to run correctly while containing subtle logical bugs. And that the trial and error approach is often slower in the long run than RTFMing. The systems I was building with other people were valuable, but creating professional grade software took a really long time and required a lot of diverse expertise. I don’t think I became disillusioned, but rather the reality of the labor of software engineering set in. I saw that it wasn’t much of a game.

Lately, though, I’m starting to feel like the advent of agentic AI and vibecoding has reignited in me some of the appeal of creating software. I recently saw this take somewhere: “vibecoding is like gambling”. It was meant to be derisive, and it’s kind of true, but it’s that chance aspect that makes vibecoding fun. You ask the agent to do something repeatedly, feeding it back resultant errors and additional context, and nudging it till it gets the right answer. It reminds me of the pleasure I felt long ago when I would stay up late just fiddling with a program until it ran.

With generative AI, I can turn ideas into programs much faster than before and without the chore of learning some API I may never need again, or some library that will be obsolete the next time I reach for it. Seeing a working prototype takes minutes instead of days, and the fast feedback loop between my brain and the UI gets me easily into a flow state (I felt similarly when I worked in Clojure). It feels empowering and exciting. For the time being, I’m energized by the new AI-backed software generation tools.

To be clear, what I get out of vibecoding is orthogonal to craft, which is a different kind of pursuit. I don’t know whether or to what extent craftsmanship is compatible with AI-assisted coding. I think it still requires some clarity of thought to work with these new tools effectively, and there is a bit of an art to it. But I also have to imagine that with more powerful foundational coding models and more capable agentic systems, the human developer will be even further removed from production. There are all kinds of implications for what this will mean for the career of software engineering, which I’ve written about before. For knowledge workers generally, on a long time horizon, this de-emphasis on production may turn us from creators into curators; rather than build the system we may just tune the system, by thumbing up or down its decisions. On the other hand, maybe it could allow us to unleash our imaginations.

I (vibe)coded this small local web application to let you easily query the datasets and view and download the results.

Check it out here:

https://matthewbilyeu.com/phila-data-explorer/

If I find some time I’d like to make an mcp server for it as well.

Despite AI advancements I don’t think plant identification is solved.

Take the above plant, a weed that started growing near my house.

• The iPhone photo built-in identification says this is Jesuit’s tea
• ChatGPT says “That plant looks like epazote (Dysphania ambrosioides), a pungent herb commonly used in Mexican and Central American cooking” (this is aka Jesuit’s tea)
• Seek by iNaturalist says Pennsylvania pellitory

Based on more research I’m inclined to say Seek was right, that this random weed is Pennsylvania pellitory.

Aside from referencing other photos and examining the stem and leaves closely, I found this helpful website describing Pennsylvania pellitory:

It is called Glaskruid in Dutch and Cucumber weed in parts of the USA. Both helpful common names as it kind of looks glassy when held to the light (translucent) and it has a mild cucumer taste.

The weed on my property did have these properties (I smelled it before tasting it).

ChatGPT doubles down on its incorrect answer:

I wonder how Seek got it right while the other two didn’t. Aside from it probably using a better model fine-tuned on lots of plant photos, I believe it incorporates time of year and location info as well.

But why do we typically flip a fair coin? The  average coin flip gives each person a 50% probability of having their way, but that might not make sense.

Suppose one of the two parties has a much stronger preference, or a stronger argument — perhaps the stronger position shouldn’t automatically win, because that would ignore the other party’s valid preferences and arguments, even if they’re weaker.

Say I’m merely in the mood for a burrito but you are really craving pizza. By flipping an unfair coin that approximates our relative preferences we’re still letting chance take the wheel, but in a way that better aligns with the situation. Maybe we could flip a coin that has a 30% chance of landing on burrito but a 70% chance of landing on pizza.

Or say that in some disagreement we both have solid arguments for our position, but I admit your arguments are slightly stronger. I don’t want to fully concede, but I may be willing to flip a coin that gives your preferred outcome a 60% chance.

Of course we don’t have easy access to unfair physical coins, but anyone reading this blog most likely has a computer in their pocket that can do unfair coin flips easily.

Maybe this is a weird robotic way to interact with people when common sense fairness and communication will do, but for low stakes disagreements I think unfair coin flipping could be a time saving tool that leaves both parties feeling accounted for.

• Minimal distraction: there technically is internet access on many flights, but it costs money, so access is disincentivized. The only available media are the built-in entertainment options or whatever you bring along. There’s minimal range of movement so you can’t even go for a walk or have a look around.
• Hard to sleep: you can’t simply snooze because it’s quite uncomfortable and you’re forced to be sitting
• Can’t leave
• Predetermined duration: you know approx how long you’ll be sitting there, making it possible to plan focus blocks

Maybe one day there will be a flight passenger simulator where you can go get strapped in for 7 hours, offering the deep focus afforded by a flight without the dry air, pressure changes, cost, etc.