Thinking Traps from the pre-agentic age
Just like water is invisible to fish, so are habits that I’ve built up over the years before agentic coding.
Only last week did I wake up to the fact, that yes, even invisible parts of the process need to be re-examined.
Here are some of the things I found – if you have any to share, I’m all ears!
If you only have one minute, the guiding idea here is this:
What do I assume that the agent doesn’t know about?
tmux for everything
I use tmux for everything I do, because it turns the terminal into a tool more powerful than any desktop application could be – you get:
infinite scrollback,
persistent execution environments,
infinite terminal real-estate,
easy, global key bindings,
full automation access to everything.
The thing is, I’ve gotten so used to tmux, that I stopped “seeing” it.
It just became muscle memory, invisible like air.
For a reason I don’t remember, I became aware again of being inside tmux and realized: of course, the agent is not aware! It can’t be!
So telling the agent that it has access to tmux unlocked all of the benefits above for the agent:
managing long-running processes is not an issue anymore,
giving it access to the history of failed commands in context allows it to make better decisions going forward,
execution context/history persist across context windows
If you want to try this out yourself, here is the prompt I use to inform that agent about this:
You are running inside tmux (${SRC}) - from now on, when you need to execute commands, you run them in ${DEST}.
To inspect the output, capture the contents of ${DEST}:
```
# capture visible area
tmux capture-pane -p -S 0 -E -
# capture 200 lines before visible output until the end
tmux capture-pane -p -S -200
```
When using the bash tool, you must run all commands through tmux.
Replace ${SRC} with where the commands should go and ${DEST} with where it’ll find the output (often these will be the same).
For example, if you have one session named x, then setting SRC and DEST to `x:1.1` will run commands in the first pane of the first window in that session, scraping that for the output.
This is similar in spirit to giving the agent access to the browser to inspect the results of frontend code changes – here we just apply the same idea to the terminal.
Next up: finding a remote-control extension for VSCode and testing whether I can use the same trick there.
The ecosystem is too small…
This one bit hard – I found myself opposing a technology, because it looked like it does not have much of an ecosystem around it.
The problem space was well-known: interactive terminal applications, it’s just that in node.js land there aren’t many options to do this well compared to Go and Rust.
So the natural impulse was to “pick the right tool for the job”.
Careful! This is pre-agentic thinking!
Porting over libraries while staying in the same programming paradigm/problem domain is essentially free now.
The cost of porting over e.g. charmbracelet’s ansi terminal library to node.js is minimal - the only challenges to solve are accessing the underlying platform (e.g. Windows) portably, but that too can be handled as a separate problem by an agent.
Once this work has been done, libraries that build on top of that can be ported over…
And so on, until you reach the level of abstraction you were looking for originally.
Of course, this requires skill and practice, but “let’s rewrite X in $LANGUAGE” has rarely been cheap enough to actually follow through.
The crucial bit here which makes this approach work is that you already have an objective definition of correct.
Namely: whatever the library you are porting does, is correct.
This allows the agent to self-correct and iterate toward a solution.
Have you identified any “thinking traps” in your own thinking?
What are they?
If not – where would you look first?