dce/davideisinger.com
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add links

Browse Source
This commit is contained in:
David Eisinger
2025-11-06 00:11:21 -05:00
parent 7bfbf5d020
commit 0899b91eb2
9 changed files with 1985 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

418
static/archive/evanhahn-com-6hstph.txt Normal file
View File

@@ -0,0 +1,418 @@
Scripts I wrote that I use all the time
by [1]Evan Hahn
, posted Oct 22, 2025
In my [2]decade-plus of maintaining my dotfiles, I’ve written a lot of little
shell scripts. Here’s a big list of my personal favorites.
Clipboard
[3]copy and [4]pasta are simple wrappers around system clipboard managers, like
pbcopy on macOS and xclip on Linux. I use these all the time.
# High level examples
run_some_command | copy
pasta > file_from_my_clipboard.txt
# Copy a file's contents
copy < file.txt
# Open a file path from your clipboard
vim "$(pasta)"
# Decode some base64 from the clipboard
pasta | base64 --decode
[5]pastas prints the current state of your clipboard to stdout, and then
whenever the clipboard changes, it prints the new version. I use this once a
week or so.
# High level example
pastas > everything_i_copied.txt
# Download every link I copy to my clipboard
pastas | wget -i -
[6]cpwd copies the current directory to the clipboard. Basically pwd | copy. I
often use this when I’m in a directory and I want use that directory in another
terminal tab; I copy it in one tab and cd to it in another. I use this once a
day or so.
File management
[7]mkcd foo makes a directory and cds inside. It’s basically mkdir foo && cd
foo. I use this all the time—almost every time I make a directory, I want to go
in there.
[8]tempe changes to a temporary directory. It’s basically cd "$(mktemp -d)". I
use this all the time to hop into a sandbox directory. It saves me from having
to manually clean up my work. A couple of common examples:
# Download a file and extract it
tempe
wget 'https://example.com/big_file.tar.xz'
tar -xf big_file.tar.xz
# ...do something with the file...
# Write a quick throwaway script to try something out
tempe
vim foo.py
python3 foo.py
[9]trash a.txt b.png moves a.txt and b.png to the trash. Supports macOS and
Linux. I use this every day. I definitely run it more than rm, and it saves me
from accidentally deleting files.
[10]mksh makes it quick to create shell scripts. mksh foo.sh creates foo.sh,
makes it executable with chmod u+x, adds some nice Bash prefixes, and opens it
with my editor (Vim in my case). I use this every few days. Many of the scripts
in this post were made with this helper!
Internet
[11]serveit starts a static file server on localhost:8000 in the current
directory. It’s basically python3 -m http.server 8000 but handles cases where
Python isn’t installed, falling back to other programs. I use this a few times
a week. Probably less useful if you’re not a web developer.
[12]getsong uses yt-dlp to download songs, often from YouTube or SoundCloud, in
the highest available quality. For example, getsong https://www.youtube.com/
watch?v=dQw4w9WgXcQ downloads that video as a song. I use this a few times a
week&mldr;typically to grab video game soundtracks&mldr;
[13]getpod similarly uses yt-dlp to download something for a podcast player.
There are a lot of videos that I’d rather listen to like a podcast. I use this
a few times a month.
[14]getsubs downloads the English subtitles for a video. (There’s some
fanciness to look for “official” subtitles, falling back to auto-generated
subtitles.) Sometimes I read the subtitles manually, sometimes I run getsubs
https://video.example/foo | ollama run llama3.2 "Summarize this", sometimes I
just want it as a backup of a video I don’t want to save on my computer. I use
this every few days.
[15]wifi off, wifi on, and wifi toggle are useful for controlling my system’s
wifi. wifi toggle is the one I use most often, when I’m having network trouble.
I use this about once a month.
[16]url "$my_url" parses a URL into its parts. I use this about once a month to
pull data out of a URL, often because I don’t want to click a nasty tracking
link.
url 'https://evil.example/track-user-link?url=https%3A%2F%2Furl-i-want-to-visit.example&track=06f8582a-91e6-4c9c-bf8e-516884584aba#cookie=123'
# original: https://evil.example/track-user-link?url=https%3A%2F%2Furl-i-want-to-visit.example&track=06f8582a-91e6-4c9c-bf8e-516884584aba#cookie=123
# protocol: https
# hostname: evil.example
# path: /track-user-link
# query: url=https%3A%2F%2Furl-i-want-to-visit.example&track=06f8582a-91e6-4c9c-bf8e-516884584aba
# - url https://url-i-want-to-visit.example
# - track 06f8582a-91e6-4c9c-bf8e-516884584aba
# hash: cookie=123
Text processing
[17]line 10 prints line 10 from stdin. For example, cat some_big_file | line 10
prints line 10 of a file. This feels like one of those things that should be
built in, like head and tail. I use this about once a month.
[18]scratch opens a temporary Vim buffer. It’s basically an alias for $EDITOR $
(mktemp). I use this about once a day for quick text manipulation tasks, or to
take a little throwaway note.
[19]straightquote converts “smart quotes” to “straight quotes” (sometimes
called “dumb quotes”). I don’t care much about these in general, but they
sometimes weasel their way into code I’m working on. It can also make the file
size smaller, which is occasionally useful. I use this at least once a week.
[20]markdownquote adds > before every line. I use it in Vim a lot; I select a
region and then run :'<,'>!markdownquote to quote the selection. I use this
about once a week.
[21]length foo returns 3. (I should probably just use wc -c.)
[22]jsonformat takes JSON at stdin and pretty-prints it to stdout. I use this a
few times a year.
[23]uppered and [24]lowered convert strings to upper and lowercase. For
example, echo foo | uppered returns FOO. I use these about once a week.
[25]nato bar returns Bravo Alfa Romeo. I use this most often when talking to
customer service and need to read out a long alphanumeric string, which has
only happened a couple of times in my whole life. But it’s sometimes useful!
[26]u+ 2025 returns ñ, LATIN SMALL LETTER N WITH TILDE. A quick way to do a
lookup of a Unicode string. I don’t use this one that often&mldr;probably about
once a month.
[27]snippets foo cats ~/.config/evanhahn-snippets/foo. I use snippet arrow for
→, snippet recruiter for a quick “not interested” response to job recruiters,
snippet lorem to print a “Lorem ipsum” block, and a few others. I probably use
one or two of these a week.
REPL launchers
Inspired by Ruby’s built-in irb REPL, I’ve made:
• [28]iclj to start a Clojure REPL
• [29]ijs to start a Deno REPL (or a Node REPL when Deno is missing)
• [30]iphp to start a PHP REPL
• [31]ipy to start a Python REPL
• [32]isql to start a SQLite shell (an alias for sqlite3 :memory:)
Dates and times
[33]hoy prints the current date in ISO format, like 2020-04-20. I use this all
the time because I like to prefix files with the current date.
[34]timer 10m starts a timer for 10 minutes, then (1) plays an audible ring
sound (2) sends an OS notification (see notify below). I often use bb timer 5m
to start a 5 minute timer in the background (see bb below). I use this almost
every day as a useful way to keep on track of time.
[35]rn prints the current time and date using date and cal. I probably use it
once a week. It prints something like this:
4:20PM on Wednesday, October 22, 2025
September 2025
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
Audio and video and pictures
[36]ocr my_image.png extracts text from an image and prints it to stdout. It
only works on macOS, unfortunately, but I want to fix that. (I wrote [37]a post
about this script.)
[38]boop (an alias, not a shell script) makes a happy sound if the previous
command succeeded and a sad sound otherwise. I do things like run_the_tests ;
boop which will tell me, audibly, whether the tests succeed. It’s also helpful
for long-running commands, because you get a little alert when they’re done. I
use this all the time.
[39]sfx foo basically just plays ~/.config/evanhahn-sfx/foo.ogg. Used in boop
and timer above.
[40]tunes uses mpv to play audio from a file. I use this all the time, running
tunes --shuffle ~/music.
[41]pix uses mpv to show a picture. I use this a few times a week to look at
photos.
[42]radio is a little wrapper around some of my favorite internet radio
stations. radio lofi and radio salsa are two of my favorites. I use this a few
times a month.
[43]speak reads from stdin, removes all Markdown formatting, and pipes it to a
text-to-speech system (say on macOS and espeak-ng on Linux). [44]I like using
text-to-speech when I can’t proofread out loud. I use this a few times a month.
[45]shrinkvid is an ffmpeg wrapper that compresses a video a bit. I use this
about once a month.
[46]removeexif removes EXIF data from JPEGs. I don’t use this much, in part
because it doesn’t remove EXIF data from other file formats like PNGs&mldr;but
I keep it around because I hope to expand this one day.
[47]tuivid is one I almost never use, but you can use it to watch videos in the
terminal. It’s cursed and I love it, even if I never use it.
Process management
[48]each is my answer to xargs and find ... -exec, which I find hard to use.
For example, ls | each 'du -h {}' runs du -h on every file in a directory. I
use this infrequently but I always mess up xargs so this is a nice alternative.
[49]running foo is like ps aux | grep foo but much easier (for me) to read—just
the PID (highlighted in purple) and the command.
[50]murder foo or murder 1234 is a wrapper around kill that sends kill -15
$PID, waits a little, then sends kill -2, waits and sends kill -1, waits before
finally sending kill -9. If I want a program to stop, I want to ask it nicely
before getting more aggressive. I use this a few times a month.
[51]waitfor $PID waits for a PID to exit before continuing. It also keeps the
system from going to sleep. I use this about once a month to do things like:
# I want to start something only after another process finishes
waitfor 1234 ; something_else
# I started a long-running process and want to know when it's done
waitfor 1234 ; notify 'process 1234 is done'
[52]bb my_command is like my_command & but it really really runs it in the
background. You’ll never hear from that program again. It’s useful when you
want to start a daemon or long-running process you truly don’t care about. I
use bb ollama serve and bb timer 5m most often. I use this about once a day.
[53]prettypath prints $PATH but with newlines separating entries, which makes
it much easier to read. I use this pretty rarely—mostly just when I’m debugging
a $PATH issue, which is unusual—but I’m glad I have it when I do.
[54]tryna my_command runs my_command until it succeeds. [55]trynafail
my_command runs my_command until it fails. I don’t use this much, but it’s
useful for various things. tryna wget ... will keep trying to download
something. trynafail npm test will stop once my tests start failing.
Quick references
[56]emoji is my emoji lookup helper. For example, emoji cool prints the
following:
😛
😒
😎
🪭
🆒
[57]httpstatus prints all HTTP statuses. httpstatus 204 prints 204 No Content.
As a web developer, I use this a few times a month, instead of looking it up
online.
[58]alphabet just prints the English alphabet in upper and lowercase. I use
this surprisingly often (probably about once a month). It literally just prints
this:
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
System management
[59]theme 0 changes my whole system to dark mode. theme 1 changes it to light
mode. It doesn’t just change the OS theme—it also changes my Vim, Tmux, and
terminal themes. I use this at least once a day.
[60]sleepybear puts my system to sleep, and works on macOS and Linux. I use
this a few times a week.
[61]ds-destroy recursively deletes all .DS_Store files in a directory. I hate
that macOS clutters directories with these files! I don’t use this often, but
I’m glad I have it when I need it.
Grab bag
[62]catbin foo is basically cat "$(which foo)". Useful for seeing the source
code of a file in your path (used it for writing up this post, for example!). I
use this a few times a month.
[63]notify sends an OS notification. It’s used in several of my other scripts
(see above). I also do something like this about once a month:
run_some_long_running_process ; notify 'all done'
[64]uuid prints a v4 UUID. I use this about once a month.
What about your scripts?
These are just scripts I use a lot. I hope some of them are useful to you!
If you liked this post, you might like [65]“Why ‘alias’ is my last resort for
aliases” and [66]“A decade of dotfiles”.
Oh, and [67]contact me if you have any scripts you think I’d like.
[68][logo_white]
• [69]About me
• [70]Contact
• [71]Projects
• [72]Guides
• [73]Blog
• [74]RSS
• [75]Newsletter
• [76]Mastodon
Unless noted otherwise, content is licensed under the [77]Creative Commons
Attribution-NonCommercial License and code under the [78]Unlicense. Logo by
[79]Lulu Tang. Profile photo by [80]Ali Boschert-Downs.
References:
[1] https://evanhahn.com/
[2] https://evanhahn.com/a-decade-of-dotfiles/
[3] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/copy
[4] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/pasta
[5] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/pastas
[6] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/cpwd
[7] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/zsh/.config/zsh/aliases.zsh#L38-L41
[8] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/zsh/.config/zsh/aliases.zsh#L43-L51
[9] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/trash
[10] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/mksh
[11] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/serveit
[12] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/getsong
[13] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/getpod
[14] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/getsubs
[15] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/wifi
[16] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/url
[17] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/line
[18] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/scratch
[19] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/straightquote
[20] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/markdownquote
[21] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/length
[22] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/jsonformat
[23] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/uppered
[24] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/lowered
[25] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/nato
[26] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/u+
[27] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/snippets
[28] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/iclj
[29] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/ijs
[30] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/iphp
[31] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/ipy
[32] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/isql
[33] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/hoy
[34] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/timer
[35] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/rn
[36] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/ocr
[37] https://evanhahn.com/mac-ocr-script/
[38] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/zsh/.config/zsh/aliases.zsh#L53-L61
[39] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/sfx
[40] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/tunes
[41] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/pix
[42] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/radio
[43] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/speak
[44] https://evanhahn.com/use-text-to-speech-if-you-cant-proofread-aloud/
[45] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/shrinkvid
[46] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/removeexif
[47] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/tuivid
[48] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/each
[49] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/running
[50] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/murder
[51] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/waitfor
[52] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/bb
[53] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/prettypath
[54] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/tryna
[55] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/trynafail
[56] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/emoji
[57] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/httpstatus
[58] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/alphabet
[59] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/theme
[60] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/sleepybear
[61] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/ds-destroy
[62] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/catbin
[63] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/notify
[64] https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/uuid
[65] https://evanhahn.com/why-alias-is-my-last-resort-for-aliases/
[66] https://evanhahn.com/a-decade-of-dotfiles/
[67] https://evanhahn.com/contact/
[68] https://evanhahn.com/
[69] https://evanhahn.com/
[70] https://evanhahn.com/contact/
[71] https://evanhahn.com/projects/
[72] https://evanhahn.com/guides/
[73] https://evanhahn.com/blog/
[74] https://evanhahn.com/blog/index.xml
[75] https://buttondown.com/evanhahn
[76] https://bigshoulders.city/@EvanHahn
[77] https://creativecommons.org/licenses/by-nc/4.0/
[78] https://unlicense.org/
[79] http://luluspice.com/
[80] https://www.instagram.com/boschertdowns/

130
static/archive/justin-searls-co-y5dsjo.txt Normal file
View File

@@ -0,0 +1,130 @@
[1]
justin․searls․co
[2][ ]
[3]Posts [4]Casts [5]Links [6]Shots [7]Takes [8]Tubes [9]Clips [10]Spots [11]
Slops [12]Mails
[13]About [14]Search [15] Subscribe
[16]Posts [17]Casts [18]Links [19]Shots [20]Takes [21]Tubes [22]Clips [23]Spots
[24]Slops [25]Mails
[26]About [27]Search [28] Subscribe
• [29]Work
• [30]GitHub
• [31]YouTube
• [32]LinkedIn
• [33]Instagram
• [34]Mastodon
• [35]Twitter
Tuesday, Nov 4, 2025 [36]
Software is supply-constrained (for now)
Fantastic [37]write-up by Nowfal comparing AI's current moment to the
Internet's dial-up era. This bit in particular points to a cleavage that far
too few people understand:
Software presents an even more interesting question. How many apps do you
need? What about software that generates applications on demand, that
creates entire software ecosystems autonomously? Until now, handcrafted
software was the constraint. Expensive software engineers and [DEL:their
:DEL] our labor costs limited what companies could afford to build.
Automation changes this equation by making those engineers far more
productive. Both consumer and enterprise software markets suggest
significant unmet demand because businesses have consistently left projects
unbuilt. They couldn't justify the development costs or had to allocate
limited resources to their top priority projects. I saw this firsthand at
Amazon. Thousands of ideas went unfunded not because they lacked business
value, but because of the lack of engineering resources to build them. If
AI can produce software at a fraction of the cost, that unleashes enormous
latent demand. The key question then is if and when that demand will
saturate.
Two things are simultaneously true:
1. The creation of custom software has been supply-constrained throughout the
entire history of computing. Nobody knows how many apps were never even
imagined—much less developed—due to this constraint, but it's probably fair
to say there's an unbelievably massive, decades-long backlog of unmet
demand for custom software
2. We aren't even six months into the [38]Shovelware era of coding agents.
Exceedingly few developers have even tried these things; the tooling is so
bad as to be counterproductive to the task; and yet experienced early
adopters (like me) have concluded today's mediocre agents are already
substantially better at writing software
It's long been my view that the appropriate response to the current moment is
to ride this walrus and leverage coding agents to increase the scope of our
ambitions. By the time software demand has been saturated and put us out of
jobs, the supply of programmers will already have tapered off as the next
generation sees the inflection point coming.
In the short term, the only programmers actually losing their jobs to "AI" are
those who refuse to engage with the technology. Using coding agents effectively
is a learned skill like any other—and if you don't keep your skills current,
fewer people will want to hire you.
[39] wreflection.com
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Got a taste for hot, fresh takes?
Then you're in luck, because you'll pay $0 for my 2¢ when you [40]subscribe to
my work, whether via [41]RSS or your favorite [42]social network.
I also have a monthly [43]newsletter where I write high-tempo,
thought-provoking essays about life, in case that's more your speed:
[44][ ] [45][Sign up]
And if you'd rather give your eyes a rest and your ears a workout, might I
suggest my long-form solo podcast, [46]Breaking Change? Odds are, you haven't
heard anything quite like it.
© 2025 Justin Searls. All rights reserved.
References:
[1] https://justin.searls.co/
[3] https://justin.searls.co/posts/
[4] https://justin.searls.co/casts/
[5] https://justin.searls.co/links/
[6] https://justin.searls.co/shots/
[7] https://justin.searls.co/takes/
[8] https://justin.searls.co/tubes/
[9] https://justin.searls.co/clips/
[10] https://justin.searls.co/spots/
[11] https://justin.searls.co/slops/
[12] https://justin.searls.co/mails/
[13] https://justin.searls.co/about/
[14] https://justin.searls.co/search/
[15] https://justin.searls.co/subscribe/
[16] https://justin.searls.co/posts/
[17] https://justin.searls.co/casts/
[18] https://justin.searls.co/links/
[19] https://justin.searls.co/shots/
[20] https://justin.searls.co/takes/
[21] https://justin.searls.co/tubes/
[22] https://justin.searls.co/clips/
[23] https://justin.searls.co/spots/
[24] https://justin.searls.co/slops/
[25] https://justin.searls.co/mails/
[26] https://justin.searls.co/about/
[27] https://justin.searls.co/search/
[28] https://justin.searls.co/subscribe/
[29] https://searls.co/
[30] https://github.com/searls
[31] https://youtube.com/@JustinSearls
[32] https://linkedin.com/in/searls
[33] https://instagram.com/searls
[34] https://mastodon.social/@searls
[35] https://twitter.com/searls
[36] https://www.wreflection.com/p/ai-dial-up-era
[37] https://www.wreflection.com/p/ai-dial-up-era
[38] https://justin.searls.co/shovelware/
[39] https://www.wreflection.com/p/ai-dial-up-era
[40] https://justin.searls.co/subscribe/
[41] https://justin.searls.co/rss/
[42] https://justin.searls.co/posse/
[43] https://justin.searls.co/newsletter
[46] https://justin.searls.co/casts/breaking-change/

85
static/archive/macwright-com-rbiipx.txt Normal file
View File

@@ -0,0 +1,85 @@
[1]Tom MacWright
2025@macwright.com
[2]Tom MacWright
• [3]Writing
• [4]Reading
• [5]Photos
• [6]Projects
• [7]Drawings
• [8]Micro⇠
• [9]About
What if people don't want to create things
2025-10-21
Almost my whole career distills down to ‘making creative tools’ of one sort or
another: [10]visualizations, [11]maps, [12]code, [13]hardware. I try to live a
creative life too - between music, photos, drawing, writing, and [14]sewing I
have some output. Never enough, but it’s something.
When I look back on [15]TileMill in 2010, [16]Mapbox Studio, Observable, the
whole arc: I can’t help but worry about the supply of creativity in society. In
particular:
If we give everyone the tools to build their dreams, very few people will use
them.
That’s it. Only tools that are both free, easy to learn, and ideally profitable
really take off and become commonplace: TikTok has a lot of ‘creators’ because
the learning curve is shallow and making videos is socially and economically
beneficial.
But few people want to make maps. Few people even think about the fact that
anyone makes maps. The same goes for so much in society: the tools for making
[17]fonts are free and learnable, but to use them you need time and effort.
Beautiful data visualizations are free to make, with lots of resources and
opportunities, but the supply of people who really love and know [18]D3 is a
lot lower than I expected it would be.
I worry about this when it comes to software, too. I love [19]home cooked apps
and [20]malleable software but I have a gnawing feeling that I’m in a bubble
when I think about them. Most people’s lives are split into the things that
they affect & create, and the things that already exist and they want to tune
out and automate, and our lives might be tilting more toward the latter than
ever before. It’s so possible to live without understanding much of the built
environment or learning to build anything.
It’s not a personal issue: surely this comes downstream from a lack of free
time, a cutthroat economic system, and companies that intentionally lock down
their products - operating systems that only run approved software, coffee
machines that only accept [21]proprietary coffee pods.
But some of it is a personal inclination: the hesitance to share one’s art or
writing or to tinker. It’s a shift of values from what you can make to [22]what
you can own. It’s a bigger cultural thing that I could ever wrap my head
around, but I do think about it a lot.
References:
[1] https://macwright.com/
[2] https://macwright.com/
[3] https://macwright.com/writing
[4] https://macwright.com/reading/
[5] https://macwright.com/photos/
[6] https://macwright.com/projects/
[7] https://macwright.com/drawings/
[8] https://macwright.com/micro/
[9] https://macwright.com/about/
[10] https://observablehq.com/
[11] https://www.mapbox.com/
[12] http://val.town/
[13] https://config.com/
[14] https://macwright.com/2025/09/27/porteur-bag-2
[15] https://tilemill-project.github.io/tilemill/
[16] https://www.mapbox.com/mapbox-studio
[17] https://fontforge.org/en-US/
[18] https://d3js.org/
[19] https://www.robinsloan.com/notes/home-cooked-app/
[20] https://www.inkandswitch.com/essay/malleable-software/
[21] https://en.wikipedia.org/wiki/Keurig
[22] https://www.theguardian.com/technology/ng-interactive/2025/oct/21/why-the-manosphere-clicked-for-young-men-a-visual-deep-dive

288
static/archive/simonwillison-net-yekorg.txt Normal file
View File

@@ -0,0 +1,288 @@
[1]Simon Willison’s Weblog
[2]Subscribe
Vibe engineering
7th October 2025
I feel like vibe coding is [3]pretty well established now as covering the fast,
loose and irresponsible way of building software with AI—entirely
prompt-driven, and with no attention paid to how the code actually works. This
leaves us with a terminology gap: what should we call the other end of the
spectrum, where seasoned professionals accelerate their work with LLMs while
staying proudly and confidently accountable for the software they produce?
I propose we call this vibe engineering, with my tongue only partially in my
cheek.
One of the lesser spoken truths of working productively with LLMs as a software
engineer on non-toy-projects is that it’s difficult. There’s a lot of depth to
understanding how to use the tools, there are plenty of traps to avoid, and the
pace at which they can churn out working code raises the bar for what the human
participant can and should be contributing.
The rise of coding agents—tools like [4]Claude Code (released February 2025),
OpenAI’s [5]Codex CLI (April) and [6]Gemini CLI (June) that can iterate on
code, actively testing and modifying it until it achieves a specified goal, has
dramatically increased the usefulness of LLMs for real-world coding problems.
I’m increasingly hearing from experienced, credible software engineers who are
running multiple copies of agents at once, tackling several problems in
parallel and expanding the scope of what they can take on. I was skeptical of
this at first but [7]I’ve started running multiple agents myself now and it’s
surprisingly effective, if mentally exhausting!
This feels very different from classic vibe coding, where I outsource a simple,
low-stakes task to an LLM and accept the result if it appears to work. Most of
my [8]tools.simonwillison.net collection ([9]previously) were built like that.
Iterating with coding agents to produce production-quality code that I’m
confident I can maintain in the future feels like a different process entirely.
It’s also become clear to me that LLMs actively reward existing top tier
software engineering practices:
• Automated testing. If your project has a robust, comprehensive and stable
test suite agentic coding tools can fly with it. Without tests? Your agent
might claim something works without having actually tested it at all, plus
any new change could break an unrelated feature without you realizing it.
Test-first development is particularly effective with agents that can
iterate in a loop.
• Planning in advance. Sitting down to hack something together goes much
better if you start with a high level plan. Working with an agent makes
this even more important—you can iterate on the plan first, then hand it
off to the agent to write the code.
• Comprehensive documentation. Just like human programmers, an LLM can only
keep a subset of the codebase in its context at once. Being able to feed in
relevant documentation lets it use APIs from other areas without reading
the code first. Write good documentation first and the model may be able to
build the matching implementation from that input alone.
• Good version control habits. Being able to undo mistakes and understand
when and how something was changed is even more important when a coding
agent might have made the changes. LLMs are also fiercely competent at
Git—they can navigate the history themselves to track down the origin of
bugs, and they’re better than most developers at using [10]git bisect. Use
that to your advantage.
• Having effective automation in place. Continuous integration, automated
formatting and linting, continuous deployment to a preview environment—all
things that agentic coding tools can benefit from too. LLMs make writing
quick automation scripts easier as well, which can help them then repeat
tasks accurately and consistently next time.
• A culture of code review. This one explains itself. If you’re fast and
productive at code review you’re going to have a much better time working
with LLMs than if you’d rather write code yourself than review the same
thing written by someone (or something) else.
• A very weird form of management. Getting good results out of a coding agent
feels uncomfortably close to getting good results out of a human
collaborator. You need to provide clear instructions, ensure they have the
necessary context and provide actionable feedback on what they produce.
It’s a lot easier than working with actual people because you don’t have to
worry about offending or discouraging them—but any existing management
experience you have will prove surprisingly useful.
• Really good manual QA (quality assurance). Beyond automated tests, you need
to be really good at manually testing software, including predicting and
digging into edge-cases.
• Strong research skills. There are dozens of ways to solve any given coding
problem. Figuring out the best options and proving an approach has always
been important, and remains a blocker on unleashing an agent to write the
actual code.
• The ability to ship to a preview environment. If an agent builds a feature,
having a way to safely preview that feature (without deploying it straight
to production) makes reviews much more productive and greatly reduces the
risk of shipping something broken.
• An instinct for what can be outsourced to AI and what you need to manually
handle yourself. This is constantly evolving as the models and tools become
more effective. A big part of working effectively with LLMs is maintaining
a strong intuition for when they can best be applied.
• An updated sense of estimation. Estimating how long a project will take has
always been one of the hardest but most important parts of being a senior
engineer, especially in organizations where budget and strategy decisions
are made based on those estimates. AI-assisted coding makes this even
harder—things that used to take a long time are much faster, but
estimations now depend on new factors which we’re all still trying to
figure out.
If you’re going to really exploit the capabilities of these new tools, you need
to be operating at the top of your game. You’re not just responsible for
writing the code—you’re researching approaches, deciding on high-level
architecture, writing specifications, defining success criteria, [11]designing
agentic loops, planning QA, managing a growing army of weird digital interns
who will absolutely cheat if you give them a chance, and spending so much time
on code review.
Almost all of these are characteristics of senior software engineers already!
AI tools amplify existing expertise. The more skills and experience you have as
a software engineer the faster and better the results you can get from working
with LLMs and coding agents.
“Vibe engineering”, really?
Is this a stupid name? Yeah, probably. “Vibes” as a concept in AI feels a
little tired at this point. “Vibe coding” itself is used by a lot of developers
in a dismissive way. I’m ready to reclaim vibes for something more
constructive.
I’ve never really liked the artificial distinction between “coders” and
“engineers”—that’s always smelled to me a bit like gatekeeping. But in this
case a bit of gatekeeping is exactly what we need!
Vibe engineering establishes a clear distinction from vibe coding. It signals
that this is a different, harder and more sophisticated way of working with AI
tools to build production software.
I like that this is cheeky and likely to be controversial. This whole space is
still absurd in all sorts of different ways. We shouldn’t take ourselves too
seriously while we figure out the most productive ways to apply these new
tools.
I’ve tried in the past to get terms like [12]AI-assisted programming to stick,
with approximately zero success. May as well try rubbing some vibes on it and
see what happens.
I also really like the clear mismatch between “vibes” and “engineering”. It
makes the combined term self-contradictory in a way that I find mischievous and
(hopefully) sticky.
Posted [13]7th October 2025 at 2:32 pm · Follow me on [14]Mastodon, [15]Bluesky
, [16]Twitter or [17]subscribe to my newsletter
More recent articles
• [18]A new SQL-powered permissions system in Datasette 1.0a20 - 4th November
2025
• [19]New prompt injection papers: Agents Rule of Two and The Attacker Moves
Second - 2nd November 2025
• [20]Hacking the WiFi-enabled color screen GitHub Universe conference badge
- 28th October 2025
This is Vibe engineering by Simon Willison, posted on [21]7th October 2025.
Part of series [22]How I use LLMs and ChatGPT
29. [23]Tips on prompting ChatGPT for UK technology secretary Peter Kyle - June
3, 2025, 7:08 p.m.
30. [24]Designing agentic loops - Sept. 30, 2025, 3:20 p.m.
31. [25]Embracing the parallel coding agent lifestyle - Oct. 5, 2025, 12:06
p.m.
32. Vibe engineering - Oct. 7, 2025, 2:32 p.m.
33. [26]Claude can write complete Datasette plugins now - Oct. 8, 2025, 11:43
p.m.
34. [27]Getting DeepSeek-OCR working on an NVIDIA Spark via brute force using
Claude Code - Oct. 20, 2025, 5:21 p.m.
35. [28]Video: Building a tool to copy-paste share terminal sessions using
Claude Code for web - Oct. 23, 2025, 4:14 a.m.
[29] code-review 13 [30] definitions 35 [31] software-engineering 59 [32] ai
1658 [33] generative-ai 1463 [34] llms 1430 [35] ai-assisted-programming 265
[36] vibe-coding 52 [37] coding-agents 88 [38] parallel-agents 6
Next: [39]Claude can write complete Datasette plugins now
Previous: [40]OpenAI DevDay 2025 live blog
Monthly briefing
Sponsor me for $10/month and get a curated email digest of the month's most
important LLM developments.
Pay me to send you less!
[41] Sponsor & subscribe
• [42]Colophon
• ©
• [43]2002
• [44]2003
• [45]2004
• [46]2005
• [47]2006
• [48]2007
• [49]2008
• [50]2009
• [51]2010
• [52]2011
• [53]2012
• [54]2013
• [55]2014
• [56]2015
• [57]2016
• [58]2017
• [59]2018
• [60]2019
• [61]2020
• [62]2021
• [63]2022
• [64]2023
• [65]2024
• [66]2025
References:
[1] https://simonwillison.net/
[2] https://simonwillison.net/about/#subscribe
[3] https://simonwillison.net/2025/Mar/19/vibe-coding/
[4] https://www.claude.com/product/claude-code
[5] https://github.com/openai/codex
[6] https://github.com/google-gemini/gemini-cli
[7] https://simonwillison.net/2025/Oct/5/parallel-coding-agents/
[8] https://tools.simonwillison.net/
[9] https://simonwillison.net/2025/Sep/4/highlighted-tools/
[10] https://til.simonwillison.net/git/git-bisect
[11] https://simonwillison.net/2025/Sep/30/designing-agentic-loops/
[12] https://simonwillison.net/tags/ai-assisted-programming/
[13] https://simonwillison.net/2025/Oct/7/
[14] https://fedi.simonwillison.net/@simon
[15] https://bsky.app/profile/simonwillison.net
[16] https://twitter.com/simonw
[17] https://simonwillison.net/about/#subscribe
[18] https://simonwillison.net/2025/Nov/4/datasette-10a20/
[19] https://simonwillison.net/2025/Nov/2/new-prompt-injection-papers/
[20] https://simonwillison.net/2025/Oct/28/github-universe-badge/
[21] https://simonwillison.net/2025/Oct/7/
[22] https://simonwillison.net/series/using-llms/
[23] https://simonwillison.net/2025/Jun/3/tips-for-peter-kyle/
[24] https://simonwillison.net/2025/Sep/30/designing-agentic-loops/
[25] https://simonwillison.net/2025/Oct/5/parallel-coding-agents/
[26] https://simonwillison.net/2025/Oct/8/claude-datasette-plugins/
[27] https://simonwillison.net/2025/Oct/20/deepseek-ocr-claude-code/
[28] https://simonwillison.net/2025/Oct/23/claude-code-for-web-video/
[29] https://simonwillison.net/tags/code-review/
[30] https://simonwillison.net/tags/definitions/
[31] https://simonwillison.net/tags/software-engineering/
[32] https://simonwillison.net/tags/ai/
[33] https://simonwillison.net/tags/generative-ai/
[34] https://simonwillison.net/tags/llms/
[35] https://simonwillison.net/tags/ai-assisted-programming/
[36] https://simonwillison.net/tags/vibe-coding/
[37] https://simonwillison.net/tags/coding-agents/
[38] https://simonwillison.net/tags/parallel-agents/
[39] https://simonwillison.net/2025/Oct/8/claude-datasette-plugins/
[40] https://simonwillison.net/2025/Oct/6/openai-devday-live-blog/
[41] https://github.com/sponsors/simonw/
[42] https://simonwillison.net/about/#about-site
[43] https://simonwillison.net/2002/
[44] https://simonwillison.net/2003/
[45] https://simonwillison.net/2004/
[46] https://simonwillison.net/2005/
[47] https://simonwillison.net/2006/
[48] https://simonwillison.net/2007/
[49] https://simonwillison.net/2008/
[50] https://simonwillison.net/2009/
[51] https://simonwillison.net/2010/
[52] https://simonwillison.net/2011/
[53] https://simonwillison.net/2012/
[54] https://simonwillison.net/2013/
[55] https://simonwillison.net/2014/
[56] https://simonwillison.net/2015/
[57] https://simonwillison.net/2016/
[58] https://simonwillison.net/2017/
[59] https://simonwillison.net/2018/
[60] https://simonwillison.net/2019/
[61] https://simonwillison.net/2020/
[62] https://simonwillison.net/2021/
[63] https://simonwillison.net/2022/
[64] https://simonwillison.net/2023/
[65] https://simonwillison.net/2024/
[66] https://simonwillison.net/2025/

394
static/archive/spf13-com-enwyvy.txt Normal file
View File

@@ -0,0 +1,394 @@
[1]spf13
Menu
• [2]Home
• [3]About
• [4]Topics
• [5]Presentations
•
Search for Blog [6][ ]
Why Engineers Can't Be Rational About Programming Languages
[7]
[8]Steve Francia 3 Nov 2025
[9]Programming-Languages [10]Leadership [11]Engineering-Culture [12]Management
[13]Economy
✨
Series Overview
This is the first entry in a series on the true cost of a programming language.
The Leadership Blindspot: How Identity Drives Multi-Million Dollar Technical
Debt
A programming language is the single most expensive choice a company makes, yet
we treat it like a technical debate. After watching this mistake bankrupt
dozens of companies and hurt hundreds more, I’ve learned the uncomfortable
truth: these decisions are rarely about technology. They’re about identity,
emotion, and ego, and they’re destroying your velocity and budget in ways you
can’t see until it’s too late.
Early in my career, I worked at Takkle, a promising social network. A sudden
departure vaulted me from lead engineer to VP of Engineering, leading a team of
12. While we were delivering on all our goals, I was in my early 20s and lacked
experience, a risk our board wanted to fix. They pressured our CEO to recruit a
CTO with more experience. I looked forward to learning from him; he was a well
known figure in the Perl community and arrived with a stack of O’Reilly “camel”
books.
One of his first acts was to pronounce our language, PHP, the wrong choice. He
decreed a switch to Perl. This decree happened after what felt to me like a
sham analysis comparing PHP and Perl.
Our velocity collapsed. Our team had to not only learn a new language but
rebuild from scratch, delaying our product by nine months. Our monthly burn
rate jumped from $200K to $500K as we more than doubled our size to make up for
the lost velocity while building the new Perl based system, which halved our
runway.
Our CTO did deliver, at least on some of his promises. We built a beautiful
system, one I was truly proud of. But it was too late. By the time we finally
launched, the market opportunity had vanished. Facebook had now expanded beyond
colleges, and we were at the end of our monitary runway. The increased spend
had shortened our runway by half, and we didn’t have enough momentum with the
new site to reach the milestones required to raise more money.
I’ve often wondered: What if we had just stuck with PHP? We had a fine system
and real momentum. We would have launched much earlier at a fraction of the
cost. PHP was good enough for Facebook; why not us?
But the question that haunted me was: Why did such an experienced leader make
such an terrible mistake?
Promises Made
• Switching to Perl would unlock the architecture we needed
• Rebuilding from scratch would accelerate hiring and quality
Reality Delivered
• Velocity collapsed as the team relearned and rebuilt everything
• Burn rate jumped from $200K to $500K per month
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The Pattern Repeats
As my career progressed I saw this same pattern over and over. As Languages
Product Lead at Google, my group included C++, Java, Go, and Python. At
MongoDB, I managed teams writing in 13 different languages. In both places I
saw brilliant engineers arguing past each other, armed with conflicting data,
all of it true, but none of it complete. At Google Cloud, I saw these same
challenges across our customers.
Fast forward two decades from Takkle, and I had déjà vu. I watched as a VP of
Engineering presented to leadership why his team needed to build their next
system in Rust. The presentation eerily paralleled that Takkle experience. In
that old presentation, nearly every reason the CTO gave for Perl was truer of
PHP at the time. Now, every single reason given for choosing Rust in this
presentation, Go was objectively better at. As an example: they cited “easy
build and deploy” as a Rust advantage. It’s true that this is a strength of
Rust, but Go’s nearly instant cross compilation and single static binary is
even stronger than Rust in this specic critera with Rust’s very long build
times.
It’s not that I think they should have chosen Go, Go would have been the wrong
choice for their situation, and I believe Rust was the right choice. But what
struck me was how broken their reasoning was. If they were making a logical
argument, surely they would have considered Go and in doing so with their
presented criteria they would have realized Go was a better option and, at the
very least, refined their critera.
I pulled the VP aside after the meeting. “Walk me through how you evaluated
other language candidates,” I said. His face went blank. “We&mldr; didn’t
really look at any others,” he admitted. “Everyone’s talking about Rust.” There
it was: a 50 million dollar decision made on hype, about to be green lit.
For me this was the moment of epiphany, finally an answer to the question for
the beginning of my career. The presentation didn’t share an analysis, they
hadn’t done one; it was a justification for a choice already made. This was a
decision based purely on hype, emotion, and identity.
Every Technical Debate Is Really Two Conversations
In every language discussion, two conversations are happening simultaneously.
The Visible Conversation: “Rust has memory safety without garbage collection.”
“Go has faster compile times and easier deployment.” “Python has the richest ML
ecosystem.”
The Invisible Conversation: “I am a Rust programmer.” “I want to become a Rust
programmer.” “I cannot imagine being someone who doesn’t choose Rust.”
If you just read that and thought “well, my last language choice was different,
I was being rational,” your invisible conversation is running right now,
defending itself while you read this sentence.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
My CTO at Takkle was having the invisible conversation. Every point in his
visible Perl analysis was technically true, but it felt like a sham because it
was only there to cover the much deeper invisible conversation. He wasn’t
evaluating languages. He was protecting an identity he’d spent a decade
building. What our company paid $300K per month extra for wasn’t better
architecture or faster hiring. We paid for the opportunity for him to be a Perl
CTO instead of a PHP CTO. That was the real transaction. The rebuild was just
the payment plan.
That VP’s Rust presentation listed “easy build and deploy” as an advantage,
technically true, but Go is objectively better on that specific criterion. If
they were truly having the visible conversation, they would have caught that.
They would have at least considered Go in their analysis.
They hadn’t. Because they weren’t having that conversation at all. And they
were about to spend $50 million on the invisible one.
The Neuroscience of Why You Can’t See Your Own Bias
In one of the most [14]fascinating studies done in the past 20 years,
researchers set out to understand why people cling to beliefs even when
confronted with overwhelming contradictory evidence. What [15]they discovered
fundamentally changed our understanding of human decision making.
The researchers recruited participants and first identified which beliefs were
central to each person’s identity—their core political views, their fundamental
values, the beliefs that defined who they were. Then, while participants lay in
an fMRI scanner, the researchers presented them with carefully constructed
challenges to these identity based beliefs, alongside challenges to beliefs the
participants held but weren’t central to their sense of self.
The brain scans revealed something remarkable: these two types of challenges
activated completely different neural pathways.
When a peripheral belief was challenged, something the person believed but
wasn’t core to their identity, the brain’s reasoning centers activated
normally. Participants could consider the evidence, weigh the arguments, and
sometimes even change their minds.
But when an identity based belief was challenged, the brain responded as if
under physical attack. The amygdala, your threat detection system, the same
system that fires when you encounter a predator or a physical danger, activates
immediately. The insular cortex, which processes emotional pain and disgust,
lit up with activity. Most tellingly, the brain’s Default Mode Network, the
system that maintains your sense of self and personal narrative, went into
defensive mode, working to protect the existing identity rather than evaluate
the new information.
In other words, your brain wasn’t weighing evidence. It was defending itself
from an existential threat.
The researchers’ conclusion was stark: “To consider an alternative view, you
have to imagine an alternative version of yourself.”
Your brain can’t objectively evaluate challenges to identity based beliefs
because doing so requires temporarily dismantling the neural architecture that
defines who you are. It’s not a matter of being more rational or trying harder.
The mechanism that would allow you to see the bias clearly is the same
mechanism the bias has compromised.
Think about what this means in practice. Every time an engineer evaluates a
language that isn’t “theirs,” their brain is literally working against them.
They’re not just analyzing technical trade offs, they’re contemplating a
version of themselves that doesn’t exist yet, that feels threatening to the
version that does. The Python developer reads case studies about Go’s
performance and their amygdala quietly marks each one as a threat to be
neutralized. The Rust advocate looks at identical problems and their Default
Mode Network constructs narratives about why “only” Rust can solve them.
We’re not lying. We genuinely believe our reasoning is sound. That’s what makes
identity based thinking so expensive, and so invisible.
We’ve Built Our Industry Around the Wrong Conversation
We call ourselves Pythonistas, Gophers, Rustaceans, we wear these labels like
badges, sometimes we even wear literal badges (t-shirts, stickers, etc).
There’s a reason so many of our surnames come from people’s crafts: Potter,
Smith, Brewer. What we do becomes who we are. What looks like decorative labels
are really decision making frameworks that operate beneath conscious thought.
We’ve built our entire industry around the visible conversation. We train
engineers to debate technical merits. We create decision frameworks based on
feature matrices. We think if we just gather enough benchmarks and case
studies, we’ll make the right choice.
But the invisible conversation is much stronger. It’s why my CTO chose Perl.
It’s why that VP chose Rust. And it’s operating in your next language decision
right now, invisible and unexamined.
The moment you hire a Rust developer to evaluate languages, you’ve already
chosen Rust. You’ve just added a $2 million feasibility study to make the
predetermined decision feel rational.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The Real Cost
The question isn’t whether this bias exists, the science is conclusive. The
real question is: can you afford to let it make your decisions?
Because the invisible conversation has a price tag. Industry research suggests
that technology stack decisions account for 40-60% of total development costs
over a product’s lifecycle. [16]Research by Stripe found that developers spend
42% of their time on technical debt. When you let identity drive that decision
you’re mortgaging your velocity, your budget, and your runway to pay for
someone’s sense of self.
The visible conversation is about technology. The invisible conversation is
about identity. And the invisible conversation always wins.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
A New Framework: Language as Economic Decision
So how do we win, when the invisible conversation is constantly working against
us?  Change the conversation entirely.
Instead of asking “which language is best?” we need to ask “what is this
language going to cost us?” Not just in salaries, but in velocity, in technical
debt, in hiring difficulty, in operational complexity, in every dimension that
actually determines whether you survive.
Reframe it from a technical debate to an economic one. And unlike identity,
economics can be measured, compared, and decided without anyone’s ego being
threatened.
Choosing a programming language is the single most expensive economic decision
your company will make. It will define your culture, constrain your budget,
determine your hiring pipeline, set your operational costs, and ultimately
dictate whether you can move fast enough to win your market.
We need a framework that makes the invisible costs visible. One that lets us
have the economic conversation instead of the identity conversation. One that
works whether you’re choosing your first language or evaluating a migration.
Our industry has never really had that framework&mldr; Until now.
Up Next
In my next post, I’ll introduce the 9 Factors of a Language’s True Cost: a
comprehensive framework for evaluating language decisions based on economics,
not identity. You’ll learn how to quantify the hidden costs, predict long term
impact, and make defensible decisions that your team can align behind,
regardless of their language preferences.
On this page
On this page
• [18]The Leadership Blindspot: How Identity Drives Multi-Million Dollar
Technical Debt
• [19]The Pattern Repeats
• [20]Every Technical Debate Is Really Two Conversations
• [21]The Neuroscience of Why You Can’t See Your Own Bias
• [22]We’ve Built Our Industry Around the Wrong Conversation
• [23]The Real Cost
• [24]A New Framework: Language as Economic Decision
• [25]
• [26]
• [27]
• [28]
You may also like
[29]See all Programming-Languages
12 Sep 2025 [30]
[31]How Benjamin Franklin Invented Machine Learning in 1720
Benjamin Franklin discovered gradient descent 250 years before we had the
mathematics to describe it.
28 Apr 2011 [32]
[33]My Favorite Rands Posts
If you don’t know Rands (real name Michael Lopp), you should. His blog is full
of excellent …
22 Mar 2010 [34]
[35]Finding the Right People
Since I began at Open Sky a few weeks ago I have been tasked with building out
a great team. …
Steve Francia
For 3 decades, I’ve helped transform breakthrough ideas into trusted platforms
now used by more than 50% of the world’s developers. I’ve scaled this impact
through leadership at [36]Google, [37]MongoDB, [38]Docker, and [39]Two Sigma as
Managing Director, VP, and Product Leader shaping the tools that power modern
software development.
My approach is simple: listen deeply, build elegantly, and maintain a healthy
disregard for the impossible.
This philosophy guided me through architecting [40]MongoDB’s user experience
that sparked mass adoption, scaling [41]Go from 400K to 4.5 million developers
at [42]Google, pioneering [43]container standards at [44]Docker, and directing
AI platform innovation at [45]Two Sigma.
While technical problems are exciting to solve, I’ve learned that it’s the
human stack: the teams, cultures, and communities we build that truly
determines lasting impact. Here, I share lessons on building products and teams
that not only work, but endure and inspire.
• [46]
• [47]
• [48]
2025 © [49]spf13. All Right Reserved. Published with [50]Hugo.
References:
[1] https://spf13.com/
[2] https://spf13.com/
[3] https://spf13.com/about
[4] https://spf13.com/topics
[5] https://spf13.com/presentation
[7] https://spf13.com/about/
[8] https://spf13.com/about/
[9] https://spf13.com/tags/programming-languages/
[10] https://spf13.com/tags/leadership/
[11] https://spf13.com/tags/engineering-culture/
[12] https://spf13.com/tags/management/
[13] https://spf13.com/tags/economy/
[14] https://dornsife.usc.edu/news/stories/which-brain-networks-respond-when-someone-sticks-to-a-belief/
[15] https://www.nature.com/articles/srep39589
[16] https://stripe.com/reports/developer-coefficient-2018
[18] https://spf13.com/p/the-hidden-conversation/#the-leadership-blindspot-how-identity-drives-multi-million-dollar-technical-debt
[19] https://spf13.com/p/the-hidden-conversation/#the-pattern-repeats
[20] https://spf13.com/p/the-hidden-conversation/#every-technical-debate-is-really-two-conversations
[21] https://spf13.com/p/the-hidden-conversation/#the-neuroscience-of-why-you-cant-see-your-own-bias
[22] https://spf13.com/p/the-hidden-conversation/#weve-built-our-industry-around-the-wrong-conversation
[23] https://spf13.com/p/the-hidden-conversation/#the-real-cost
[24] https://spf13.com/p/the-hidden-conversation/#a-new-framework-language-as-economic-decision
[25] https://twitter.com/intent/tweet?text=Why%20Engineers%20Can%27t%20Be%20Rational%20About%20Programming%20Languages&url=https%3a%2f%2fspf13.com%2fp%2fthe-hidden-conversation%2f
[26] https://www.facebook.com/sharer/sharer.php?u=https%3a%2f%2fspf13.com%2fp%2fthe-hidden-conversation%2f
[27] http://pinterest.com/pin/create/button/?url=https%3a%2f%2fspf13.com%2fp%2fthe-hidden-conversation%2f&media=https%3a%2f%2fspf13.com%2f&description=Why%20Engineers%20Can%27t%20Be%20Rational%20About%20Programming%20Languages
[28] https://www.linkedin.com/shareArticle?mini=true&url=https%3a%2f%2fspf13.com%2fp%2fthe-hidden-conversation%2f&title=Why%20Engineers%20Can%27t%20Be%20Rational%20About%20Programming%20Languages&summary=The%20neuroscience%20of%20why%20we%20make%20million%20dollar%20decisions%20based%20on%20identity%2c%20not%20data.&source=Why%20Engineers%20Can%27t%20Be%20Rational%20About%20Programming%20Languages
[29] https://spf13.com/tags/programming-languages/
[30] https://spf13.com/p/how-benjamin-franklin-invented-machine-learning-in-1720/
[31] https://spf13.com/p/how-benjamin-franklin-invented-machine-learning-in-1720/
[32] https://spf13.com/post/my-favorite-rands-posts/
[33] https://spf13.com/post/my-favorite-rands-posts/
[34] https://spf13.com/post/finding-the-right-people/
[35] https://spf13.com/post/finding-the-right-people/
[36] https://google.com/
[37] https://mongodb.com/
[38] https://docker.com/
[39] https://www.twosigma.com/
[40] https://mongodb.com/
[41] https://go.dev/
[42] https://google.com/
[43] https://www.opencontainers.org/
[44] https://docker.com/
[45] https://www.twosigma.com/
[46] https://twitter.com/spf13
[47] https://github.com/spf13
[48] https://www.linkedin.com/in/stevefrancia/
[49] https://spf13.com/
[50] https://gohugo.io/

614
static/archive/steipete-me-ayczze.txt Normal file
View File

@@ -0,0 +1,614 @@
[1] Skip to content
[2] Peter Steinberger
• [4] Posts
• [5] About
• [6] Search
•
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Just Talk To It - the no-bs Way of Agentic Engineering
Published: 14 Oct, 2025
• 23 min read
| [8]Edit on GitHub
[curve-ange]
I’ve been more quiet here lately as I’m knee-deep working on my latest project.
Agentic engineering has become so good that it now writes pretty much 100% of
my code. And yet I see so many folks trying to solve issues and generating
these elaborated charades instead of getting sh*t done.
This post partly is inspired by the conversations I had at last night’s [9]
Claude Code Anonymous in London and partly since [10]it’s been an AI year since
my last workflow update. Time for a check-in.
All of the basic ideas still apply, so I won’t mention simple things like
context management again. Read my [11]Optimal AI Workflow post for a primer.
Context & Tech-Stack
I work by myself, current project is a ~300k LOC TypeScript React app, a Chrome
extension, a cli, a client app in Tauri and a mobile app in Expo. I host on
vercel, a PR delivers a new version of my website in ~2 minutes to test.
Everything else (apps etc) is not automated.
Harness & General Approach
I’ve completely moved to codex cli as daily driver. I run between 3-8 in
parallel in a 3x3 terminal grid, most of them [12]in the same folder, some
experiments go in separate folders. I experimented with worktrees, PRs but
always revert back to this setup as it gets stuff done the fastest.
My agents do git [13]atomic commits themselves. In order to maintain a mostly
clean commit history, I iterated a lot on [14]my agent file. This makes git ops
sharper so each agent commits exactly the files it edited.
Yes, with claude you could do hooks and codex doesn’t support them yet, but
models are incredibly clever and [15]no hook will stop them if they are
determined.
I was being ridiculed in the past and called a [16]slop-generator, good to see
that running parallel agents [17]slowly gets mainstream.
Model Picker
I build pretty much everything with gpt-5-codex on mid settings. It’s a great
compromise of smart & speed, and dials thinking up/down automatically. I found
over-thinking these settings to not yield meaningful results, and it’s nice not
having to think about ultrathink.
Blast Radius 💥
Whenever I work, I think about the “blast radius”. I didn’t come up with that
term, I do love it tho. When I think of a change I have a pretty good feeling
about how long it’ll take and how many files it will touch. I can throw many
small bombs at my codebase or a one “Fat Man” and a few small ones. If you
throw multiple large bombs, it’ll be impossible to do isolated commits, much
harder to reset if sth goes wrong.
This is also a good indicator while I watch my agents. If something takes
longer than I anticipated, I just hit escape and ask “what’s the status” to get
a status update and then either help the model to find the right direction,
abort or continue. Don’t be afraid of stopping models mid-way, file changes are
atomic and they are really good at picking up where they stopped.
When I am unsure about the impact, I use “give me a few options before making
changes” to gauge it.
Why not worktrees?
I run one dev server, as I evolve my project I click through it and test
multiple changes at once. Having a tree/branch per change would make this
significantly slower, spawning multiple dev servers would quickly get annoying.
I also have limitations for Twitter OAuth, so I can only register some domains
for callbacks.
What about Claude Code?
I used to love Claude Code, these days I can’t stand it anymore ([18]even tho
codex is a fan). It’s language, the [19]absolutely right’s, the 100% production
ready messages while tests fail - I just can’t anymore. Codex is more like the
introverted engineer that chugs along and just gets stuff done. It reads much
more files before starting work so even small prompts usually do exactly what I
want.
There’s broad consensus in my timeline that [20]codex is the way [21]to go.
Other benefits of codex
• ~230k usable context vs claude’s 156k. Yes, there’s Sonnet 1Mio if you get
lucky or pay API pricing, but realistically Claude gets very silly long
before it depletes that context so it’s not realistically something you can
use.
• More efficient token use. Idk what OpenAI does different, but my context
fills up far slower than with Claude Code. I used to see Compacting… all
the time when using claude, I very rarely manage to exceed the context in
codex.
• Message Queuing. Codex allows to [22]queue messages. Claude had this
feature, but a few months ago they changed it so your messages “steer” the
model. If I want to steer codex, I just press escape and enter to send the
new message. Having the option for both is just far better. I often queue
related feature tasks and it just reliably works them off.
• Speed OpenAI rewrote codex in Rust, and it shows. It’s incredibly fast.
With Claude Code I often have multi-second freezes and it’s process blows
up to gigabytes of memory. And then there’s the terminal flickering,
especially when using Ghostty. Codex has none of that. It feels incredibly
lightweight and fast.
• Language. [23]This really makes a difference to my mental health. I’ve been
screaming at claude so many times. I rarely get angry with codex. Even if
codex would be a worse model I’d use it for that fact alone. If you use
both for a few weeks you will understand.
• [24]No random markdown files everywhere. [25]IYKYK.
Why not $harness
IMO there’s simply not much space between the end user and the model company. I
get by far the best deal using a subscription. I currently have 4 OpenAI subs
and 1 Anthropic sub, so my overall costs are around 1k/month for basically
unlimited tokens. If I’d use API calls, that’d cost my around 10x more. Don’t
nail me on this math, I used some token counting tools like ccusage and it’s
all somewhat imprecise, but even if it’s just 5x it’s a damn good deal.
I like that we have tools like amp or Factory, I just don’t see them surviving
long-term. Both codex and claude code are getting better with every release,
and they all converge to the same ideas and feature set. Some might have a
temporary edge with better todo lists, steering or slight dx features, but I
don’t see them significantly out-competing the big AI companies.
amp moved away from GPT-5 as driver and now calls it their [26]“oracle”.
Meanwhile I use codex and basically constantly work with the smarter model, the
oracle. [27]Yes, there are benchmarks, but given the skewed usage numbers, I
don’t trust them. codex gets me far better results than amp. I have to give
them kudos tho for session sharing, they push some interesting ideas ahead.
Factory, unconvinced. Their videos are a bit cringe, I do hear good things in
my timeline about it tho, even if images aren’t supported (yet) and they have
the [28]signature flicker.
Cursor… it’s tab completion model is industry leading, if you still write code
yourself. I use VS Code mostly, I do like them pushing things like browser
automation and plan mode tho. I did experiment with GPT-5-Pro but [29]Cursor
still has the same bugs that annoyed me back in May. I hear that’s being worked
on tho, so it stays in my dock.
Others like Auggie were a blip on my timeline and nobody ever mentioned them
again. In the end they all wrap either GPT-5 and/or Sonnet and are replaceable.
RAG might been helpful for Sonnet, but GPT-5 is so good at searching at you
don’t need a separate vector index for your code.
The most promising candidates are opencode and crush, esp. in combination with
open models. You can totally use your OpenAI or Anthropic sub with them as well
([30]thanks to clever hax), but it’s questionable if that is allowed, and
what’s the point of using a less capable harness for the model optimized for
codex or Claude Code.
What about $openmodel
I keep an eye on China’s open models, and it’s impressive how quickly they
catch up. GLM 4.6 and Kimi K2.1 are strong contenders that slowly reach Sonnet
3.7 quality, I don’t recommend them as [31]daily driver tho.
The benchmarks only tell half the story. IMO agentic engineering moved from
“this is crap” to “this is good” around May with the release of Sonnet 4.0, and
we hit an even bigger leap from good to “this is amazing” with gpt-5-codex.
Plan Mode & Approach
What benchmarks miss is the strategy that the model+harness pursue when they
get a prompt. codex is far FAR more careful and reads much more files in your
repo before deciding what to do. [32]It pushes back harder when you make a
silly request. Claude/other agents are much more eager and just try something.
This can be mitigated with plan mode and rigorous structure docs, to me that
feels like working around a broken system.
I rarely use big plan files now with codex. codex doesn’t even have a dedicated
plan mode - however it’s so much better at adhering to the prompt that I can
just write “let’s discuss” or “give me options” and it will diligently wait
until I approve it. No harness charade needed. Just talk to it.
But Claude Code now has [33]Plugins
Do you hear that noise in the distance? It’s me sigh-ing. What a big pile of
bs. This one really left me disappointed in Anthropic’s focus. They try to
patch over inefficiencies in the model. Yes, maintaining good documents for
specific tasks is a good idea. I keep a big list of useful docs in a docs
folder as markdown.
But but Subagents !!!1!
But something has to be said about this whole dance with subagents. Back in May
this was called subtasks, and mostly a way to spin out tasks into a separate
context when the model doesn’t need the full text - mainly a way to parallelize
or to reduce context waste for e.g. noisy build scripts. Later they rebranded
and improved this to subagents, so you spin of a task with some instructions,
nicely packaged.
The use case is the same. What others do with subagents, I usually do with
separate windows. If I wanna research sth I might do that in a separate
terminal pane and paste it to another one. This gives me complete control and
visibility over the context I engineer, unlike subagents who make it harder to
view and steer or control what is sent back.
And we have to talk about the subagent Anthropic recommends on their blog. Just
look at this [34]“AI Engineer” agent. It’s an amalgamation of slop, mentioning
GPT-4o and o1 for integration, and overall just seems like an autogenerated
soup of words that tries to make sense. There’s no meat in there that would
make your agent a better “AI engineer”.
What does that even mean? If you want to get better output, telling your model
“You are an AI engineer specializing in production-grade LLM applications” will
not change that. Giving it documentation, examples and do/don’t helps. I bet
that you’d get better result if you ask your agent to “google AI agent building
best practices” and let it load some websites than this crap. You could even
make the argument that this slop is [35]context poison.
How I write prompts
Back when using claude, I used to write (ofc not, [36]I speak) very extensive
prompts, since this model “gets me” the more context I supply. While this is
true with any model, I noticed that my prompts became significantly shorter
with codex. Often it’s just 1-2 sentences + [37]an image. The model is
incredibly good at reading the codebase and just gets me. I even sometimes go
back to typing since codex requires so much less context to understand.
Adding images is an amazing trick to provide more context, the model is really
good at finding exactly what you show, it finds strings and matches it and
directly arrives at the place you mention. I’d say at least 50% of my prompts
contain a screenshot. I rarely annotate that, that works even better but is
slower. A screenshot takes 2 seconds to drag into the terminal.
[38]Wispr Flow with semantic correction is still king.
Web-Based Agents
Lately I experimented again with web agents: Devin, Cursor and Codex. Google’s
Jules looks nice but was really annoying to set up and Gemini 2.5 just isn’t a
good model anymore. Things might change soon once we get [39]Gemini 3 Pro. The
only one that stuck is codex web. It also is annoying to setup and broken, the
terminal currently [40]doesn’t load correctly, but I had an older version of my
environment and made it work, with the price of slower wramp-up times.
I use codex web as my short-term issue tracker. Whenever I’m on the go and have
an idea, I do a one-liner via the iOS app and later review this on my Mac.
Sure, I could do way more with my phone and even review/merge this, but I
choose not to. My work is already addictive enough as-is, so when I’m out or
seeing friends, I don’t wanna be pulled in even more. Heck, I say this as
someone [41]who spent almost two months building a tool to make it easier to
code on your phone.
Codex web didn’t even count towards your usage limits, but [42]these days sadly
are numbered.
The Agentic Journey
Let’s talk about tools. [43]Conductor, [44]Terragon, [45]Sculptor and the 1000
other ones. Some are hobby projects, some are drowning in VC money. I tried so
many of them. None stick. IMO they work around current inefficiencies and
promote a workflow that just isn’t optimal. Plus, most of them hide the
terminal and don’t show everything the model shows.
Most are thin wrappers around Anthropic’s SDK + work tree management. There’s
no moat. And I question if you even want easier access to coding agents on your
phone. The little use case these did for me, codex web fully covers.
I do see this pattern tho that almost every engineer goes through a phase of
building their own tools, mostly because it’s fun and because it’s so much
easier now. And what else to build than tools that (we think) will make it
simpler to build more tools?
But Claude Code can Background Tasks!
True. codex currently lacks a few bells and whistles that claude has. The most
painful omission is background task management. While it should have a timeout,
I did see it get stuck quite a few times with cli tasks that don’t end, like
spinning up a dev server or tests that deadlock.
This was one of the reasons I reverted back to claude, but since that model is
just so silly in other ways, I now use [46]tmux. It’s an old tool to run CLIs
in persistent sessions in the background and there’s plenty world knowledge in
the model, so all you need to do is “run via tmux”. No custom agent md charade
needed.
What about MCPs
Other people wrote plenty about MCPs. IMO most are something for the marketing
department to make a checkbox and be proud. Almost all MCPs really should be
clis. I say that as someone [47]who wrote 5 MCPs myself.
I can just refer to a cli by name. I don’t need any explanation in my agents
file. The agent will try $randomcrap on the first call, the cli will present
the help menu, context now has full info how this works and from now on we
good. I don’t have to pay a price for any tools, unlike MCPs which are a
constant cost and garbage in my context. Use GitHub’s MCP and see 23k tokens
gone. Heck, they did make it better because it was almost 50.000 tokens when it
first launched. Or use the gh cli which has basically the same feature set,
models already know how to use it, and pay zero context tax.
I did open source some of my cli tools, like [48]bslog and [49]inngest.
I do use [50]chrome-devtools-mcp these days [51]to close the loop. it replaced
Playwright as my to-go MCP for web debugging. I don’t need it lots but when I
do, it’s quite useful to close the loop. I designed my website so that I can
create api keys that allow my model to query any endpoint via curl, which is
faster and more token-efficient in almost all use cases, so even that MCP isn’t
something I need daily.
But the code is slop!
I spend about [52]20% of my time on refactoring. Ofc all of that is done by
agents, I don’t waste my time doing that manually. Refactor days are great when
I need less focus or I’m tired, since I can make great progress without the
need of too much focus or clear thinking.
Typical refactor work is using jscpd for code duplication, [53]knip for dead
code, running eslint’s react-compiler and deprecation plugins, checking if we
introduced api routes that can be consolidated, maintaining my docs, breaking
apart files that grew too large, adding tests and code comments for tricky
parts, updating dependencies, [54]tool upgrades, file restructuring, finding
and rewriting slow tests, mentioning modern react patterns and rewriting code
(e.g. [55]you might not need useEffect). There’s always something to do.
You could make the argument that this could be done on each commit, I do find
these phases of iterating fast and then maintaining and improving the codebase
- basically paying back some technical debt, to be far more productive, and
overall far more fun.
Do you do spec-driven development?
[56]I used to back in June. Designing a big spec, then let the model build it,
ideally for hours. IMO that’s the old way of thinking about building software.
My current approach is usually that I start a discussion with codex, I paste in
some websites, some ideas, ask it to read code, and we flesh out a new feature
together. If it’s something tricky, I ask it to write everything into a spec,
give that to GPT-5-Pro for review (via chatgpt.com) to see if it has better
ideas (surprisingly often, this greatly improves my plan!) and then paste back
what I think is useful into the main context to update the file.
By now I have a good feeling which tasks take how much context, and codex’s
context space is quite good, so often I’ll just start building. Some people are
religious and always use a new context with the plan - IMO that was useful for
Sonnet, but GPT-5 is far better at dealing with larger contexts, and doing that
would easily add 10 minutes to everything as the model has to slowly fetch all
files needed to build the feature again.
The far more fun approach is when I do UI-based work. I often start with sth
simple and woefully under-spec my requests, and watch the model build and see
the browser update in real time. Then I queue in additional changes and iterate
on the feature. Often I don’t fully know how something should look like, and
that way I can play with the idea and iterate and see it slowly come to life. I
often saw codex build something interesting I didn’t even think of. I don’t
reset, I simply iterate and morph the chaos into the shape that feels right.
Often I get ideas for related interactions and iterate on other parts as well
while I build it, that work I do in a different agent. Usually I work on one
main feature and some smaller, tangentially related tasks.
As I’m writing this, I build a new Twitter data importer in my Chrome
extension, and for that I reshape the graphql importer. Since I’m a bit unsure
if that is the right approach, that one is in a separate folder so I can look
at the PR and see if that approach makes sense. The main repo does refactoring,
so I can focus on writing this article.
Show me your slash commands!
I only have a few, and I use them rarely:
• /commit (custom text to explain that multiple agents work in the same
folder and to only commit your changes, so I get clean comments and gpt
doesn’t freak out about other changes and tries to revert things if linter
fails)
• /automerge (process one PR at a time, react to bot comments, reply, get CI
green and squash when green)
• /massageprs (same as automerge but without the squashing so I can
parallelize the process if I have a lot of PRs)
• /review (built-in, only sometimes since I have review bots on GH, but can
be useful)
And even with these, usually I just type “commit”, unless I know that there’s
far too many dirty files and the agent might mess up without some guidance. No
need for charade/context waste when I’m confident that this is enough. Again,
you develop intuition for these. I have yet to see other commands that really
are useful.
What other tricks do you have?
Instead of trying to formulate the perfect prompt to motivate the agent to
continue on a long-running task, there’s lazy workarounds. If you do a bigger
refactor, codex often stops with a mid-work reply. [57]Queue up continue
messages if you wanna go away and just see it done. If codex is done and gets
more messages, [58]it happily ignores them.
Ask the model to write tests after each feature/fix is done. Use the same
context. This will lead to far better tests, and likely uncover a bug in your
implementation. If it’s purely a UI tweak, tests likely make less sense, but
for anything else, do it. AI generally is bad at writing good tests, it’s still
helpful tho, and let’s be honest - are you writing tests for every fix you
make?
Ask the model to preserve your intent and “add code comments on tricky parts”
helps both you and future model runs.
When things get hard, prompting and adding some trigger words like “take your
time” “comprehensive” “read all code that could be related” “create possible
hypothesis” makes codex solve even the trickiest problems.
How does your Agents/Claude file look like?
I have an Agents.md file with a symlink to claude.md, since Anthropic decided
not to standardize. I recognize that this is difficult and sub-optimal, since
[59]GPT-5 prefers quite different prompting than Claude. Stop here and read
their prompting guide if you haven’t yet.
While Claude reacts well to [60]🚨 SCREAMING ALL-CAPS 🚨 commands that threaten
it that it will imply ultimate failure and 100 kittens will die if it runs
command X, that freaks out GPT-5. (Rightfully so). So drop all of that and just
use words like a human. That also means that these files can’t optimally be
shared. Which isn’t a problem to me since I mostly use codex, and accept that
the instructions might be too weak for the rare instances where claude gets to
play.
My Agent file is currently ~800 lines long and feels like a collection of
organizational scar tissue. I didn’t write it, codex did, and anytime sth
happens I ask it to make a concise note in there. I should clean this up at
some point, but despite it being large it works incredibly well, and gpt really
mostly honors entries there. At least it does far far more often than Claude
ever did. (Sonnet 4.5 got better there, to give them some credit)
Next to git instruction it contains an explanation about my product, common
naming and API patterns I prefer, notes about React Compiler - often it’s
things that are newer than world knowledge because my tech stack is quite
bleeding edge. I expect that I can again reduce things in there with model
updates. For example, Sonnet 4.0 really needed guidance to understand Tailwind
4, Sonnet 4.5 and GPT-5 are newer and know about that version so I was able to
delete all that fluff.
Significant blocks are about which React patterns I prefer, database migration
management, testing, [61]using and writing ast-grep rules. (If you don’t know
or don’t use ast-grep as codebase linter, stop here and ask your model to set
this up as a git hook to block commits)
I also experimented and started using [62]a text-based “design system” for how
things should look, the verdict is still out on that one.
So GPT-5-Codex is perfect?
Absolutely not. Sometimes it refactors for half an hour and then [63]panics and
reverts everything, and you need to re-run and soothen it like a child to tell
it that it has enough time. Sometimes it forgets that it can do [64]bash
commands and it requires some encouragement. Sometimes it replies [65]in
russian or korean. [66]Sometimes the monster slips and sends raw thinking to
bash. But overall these are quite rare and it’s just so insanely good in almost
everything else that I can look past these flaws. Humans aren’t perfect either.
My biggest annoyance with codex is that it “loses” lines, so scrolling up
quickly makes parts of the text disappear. I really hope this is on top of
OpenAI’s bug roster, as it’s the main reason I sometimes have to slow down, so
messages don’t disappear.
Conclusion
Don’t waste your time on stuff like RAG, subagents, [67]Agents 2.0 or other
things that are mostly just charade. Just talk to it. Play with it. Develop
intuition. The more you work with agents, the better your results will be.
[68]Simon Willison’s article makes an excellent point - many of the skills
needed to manage agents are similar to what you need when [69]managing
engineers - almost all of these are characteristics of senior software
engineers.
And yes, [70]writing good software is still hard. Just because I don’t write
the code anymore doesn’t mean I don’t think hard about architecture, system
design, dependencies, features or how to delight users. Using AI simply means
that expectations what to ship went up.
PS: This post is 100% organic and hand-written. I love AI, I also recognize
that some things are just better done the [71]old-fashioned way. Keep the
typos, keep my voice. [72]🚄✌️
PPS: Credit for the header graphic goes to [73]Thorsten Ball.
New posts, shipping stories, and nerdy links straight to your inbox.
[75][ ] [76][ ] Subscribe
2× per month, pure signal, zero fluff.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| [78]Edit on GitHub
• [79] ai
• [80] claude
• [81] engineering
• [82] productivity
Share this post on:
[83]Share this post on X [84] Share this post on BlueSky [85]Share this post on
LinkedIn [86]Share this post via WhatsApp [87]Share this post on Facebook [88]
Share this post via Telegram [89]Share this post on Pinterest [90]Share this
post via email
Back to Top
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[92]
Next Post
Claude Code Anonymous
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[93] Peter Steinberger on Github [94]Peter Steinberger on X [95] Peter
Steinberger on BlueSky [96]Peter Steinberger on LinkedIn [97]Send an email to
Peter Steinberger
[98] Steal this post ➜ CC BY 4.0 · Code MIT
References:
[1] https://steipete.me/posts/just-talk-to-it#main-content
[2] https://steipete.me/
[4] https://steipete.me/posts
[5] https://steipete.me/about
[6] https://steipete.me/search
[8] https://github.com/steipete/steipete.me/edit/main/src/content/blog/just-talk-to-it.md
[9] https://x.com/christianklotz/status/1977866496001867925
[10] https://x.com/pmddomingos/status/1976399060052607469
[11] https://steipete.me/posts/2025/optimal-ai-development-workflow
[12] https://x.com/steipete/status/1977771686176174352
[13] https://x.com/steipete/status/1977498385172050258
[14] https://gist.github.com/steipete/d3b9db3fa8eb1d1a692b7656217d8655
[15] https://x.com/steipete/status/1977119589860601950
[16] https://x.com/weberwongwong/status/1975749583079694398
[17] https://x.com/steipete/status/1976353767705457005
[18] https://x.com/steipete/status/1977072732136521836
[19] https://x.com/vtahowe/status/1976709116425871772
[20] https://x.com/s_streichsbier/status/1974334735829905648
[21] https://x.com/kimmonismus/status/1976404152541680038
[22] https://x.com/steipete/status/1978099041884897517
[23] https://x.com/steipete/status/1975297275242160395
[24] https://x.com/steipete/status/1977466373363437914
[25] https://x.com/deepfates/status/1975604489634914326
[26] https://ampcode.com/news/gpt-5-oracle
[27] https://x.com/btibor91/status/1976299256383250780
[28] https://x.com/badlogicgames/status/1977103325192667323
[29] https://x.com/steipete/status/1976226900516209035
[30] https://x.com/steipete/status/1977286197375647870
[31] https://x.com/imfeat7/status/1977246145278583258
[32] https://x.com/thsottiaux/status/1975565380388299112
[33] https://www.anthropic.com/news/claude-code-plugins
[34] https://github.com/wshobson/agents/blob/main/plugins/llm-application-dev/agents/ai-engineer.md
[35] https://x.com/IanIsSoAwesome/status/1976662563699245358
[36] https://x.com/steipete/status/1978104202820812905
[37] https://x.com/steipete/status/1977175451408990379
[38] https://wisprflow.ai/
[39] https://x.com/cannn064/status/1973415142302830878
[40] https://x.com/steipete/status/1974798735055192524
[41] https://steipete.me/posts/2025/vibetunnel-first-anniversary
[42] https://x.com/steipete/status/1976292221390553236
[43] https://conductor.build/
[44] https://www.terragonlabs.com/
[45] https://x.com/steipete/status/1973132707707113691
[46] https://x.com/steipete/status/1977745596380279006
[47] https://github.com/steipete/claude-code-mcp
[48] https://github.com/steipete/bslog
[49] https://github.com/steipete/inngest
[50] https://developer.chrome.com/blog/chrome-devtools-mcp
[51] https://x.com/steipete/status/1977762275302789197
[52] https://x.com/steipete/status/1976985959242907656
[53] https://knip.dev/
[54] https://x.com/steipete/status/1977472427354632326
[55] https://react.dev/learn/you-might-not-need-an-effect
[56] https://steipete.me/posts/2025/the-future-of-vibe-coding
[57] https://x.com/steipete/status/1978099041884897517
[58] https://x.com/steipete/status/1978111714685063640
[59] https://cookbook.openai.com/examples/gpt-5/gpt-5_prompting_guide
[60] https://x.com/Altimor/status/1975752110164578576
[61] https://x.com/steipete/status/1963411717192651154
[62] https://x.com/steipete/status/1973838406099874130
[63] https://x.com/steipete/status/1973834765737603103
[64] https://x.com/steipete/status/1977695411436392588
[65] https://x.com/steipete/status/1976207732534300940
[66] https://x.com/steipete/status/1974108054984798729
[67] https://x.com/steipete/status/1977660298367766766
[68] https://simonwillison.net/2025/Oct/7/vibe-engineering/
[69] https://x.com/lukasz_app/status/1974424549635826120
[70] https://x.com/svpino/status/1977396812999688371
[71] https://x.com/Alphafox78/status/1975679120898965947
[72] https://x.com/rohanpaul_ai/status/1977005259567595959
[73] https://x.com/thorstenball/status/1976224756669309195
[78] https://github.com/steipete/steipete.me/edit/main/src/content/blog/just-talk-to-it.md
[79] https://steipete.me/tags/ai/
[80] https://steipete.me/tags/claude/
[81] https://steipete.me/tags/engineering/
[82] https://steipete.me/tags/productivity/
[83] https://x.com/intent/post?url=https://steipete.me/posts/just-talk-to-it
[84] https://bsky.app/intent/compose?text=https://steipete.me/posts/just-talk-to-it
[85] https://www.linkedin.com/sharing/share-offsite/?url=https://steipete.me/posts/just-talk-to-it
[86] https://wa.me/?text=https://steipete.me/posts/just-talk-to-it
[87] https://www.facebook.com/sharer.php?u=https://steipete.me/posts/just-talk-to-it
[88] https://t.me/share/url?url=https://steipete.me/posts/just-talk-to-it
[89] https://pinterest.com/pin/create/button/?url=https://steipete.me/posts/just-talk-to-it
[90] mailto:?subject=See%20this%20post&body=https://steipete.me/posts/just-talk-to-it
[92] https://steipete.me/posts/2025/claude-code-anonymous
[93] https://github.com/steipete
[94] https://x.com/steipete
[95] https://bsky.app/profile/steipete.me
[96] https://www.linkedin.com/in/steipete/
[97] mailto:peter@steipete.me
[98] https://github.com/steipete/steipete.me