There is a thing that happens, after a couple of weeks of working with coding agents at a steady pace, where you stop thinking of yourself as the person typing and start thinking of yourself as the person seeing. The Latin word for vision is visio, “I see”; the Italian visione and English vision both keep that. It’s a much older idea than the modern “mission statement on a slide” usage. It means: I have, in my head, a picture of where this should go.
Read more
I’ll be honest. When I started thinking about which other languages SwiftBash should run, JavaScript was about fifth on my list. I’m a Swift person. I’m a Cocoa person. I’m somewhere between indifferent and faintly hostile to npm. The idea of “let’s drop a Node-compatible runtime into the bash shell” sounded exactly like the kind of project I would shake my head at on someone else’s GitHub.
Read more
When I was building SwiftBash I made surprisingly quick headway on the basic CLI utilities — jq, awk, sed, grep. Each one is a small, well-scoped language, and once you sit down with the spec it really is just a parser and an evaluator.
Then I hit a wall. The two CLIs I reach for most as a working developer aren’t tiny languages — they’re gh and glab, the GitHub and GitLab clients. And right next to them, the granddaddy of all dev CLIs: git. These aren’t 2,000-line tools. gh alone is roughly fifty thousand lines of Go, with subcommand trees, OAuth flows, REST + GraphQL clients, pagination, archive extraction, jq filtering — the works. Reimplementing all of that by hand felt like a year of evenings.
But the source code is right there on GitHub. And I have a coding agent. So I began to wonder: shouldn’t Opus 4.7 1M (extra-high) be able to translate cli/cli into Swift for me, given the original as ground truth?
A few days ago I introduced SwiftBash — a sandboxed bash interpreter written in pure Swift. At the end of the four-green-checkmarks post I promised the next instalment would be about something else: SwiftScript, the same idea but for Swift itself.
It’s exactly that. Real Swift syntax, walked by a tree-walking interpreter, no LLVM, no codegen, no Process/fork/exec — meant for the places where Swift as a compiled binary isn’t an option.
After this success with an AST for bash, I figured, let’s up the game and try the same with Swift Syntax. My Claude Opus has proven time again that it has the necessary tenacity to make any stupid idea come true.
Read moreA few hours again, four little checkmarks lit up next to a commit in SwiftScript‘s GitHub Actions:
That’s a Swift package — written in Swift, depending on swift-syntax, exposing a Swift API — building and running its full test suite on all four platforms Swift officially supports today.
Every coding agent I use — Claude Code, Codex, even PI — leans on the same tool: /bin/bash. PI in particular runs almost exclusively through bash, no sandbox in sight. There’s a good reason for that. Bash is one of the most heavily represented languages in any pre-training corpus on the planet, and LLMs write it fluently. If you give a model a file to manipulate, a folder to inspect, or a one-shot pipeline to assemble, the answer that falls out is almost always a few lines of shell.
The downside is the friction. Unless you live in YOLO mode, you spend half your day clicking Allow on find, grep, sed, and cat prompts. Codex in the cloud sidesteps this by spinning up a fresh container per task. On my Mac, both Codex and Claude Code happily edit my actual files — and even with git worktrees, I’ve ended up with stray uncommitted changes on main more than once.
15 years ago, I started my first open source project on GitHub. Originally it was called NSAttributedString-Additions-for-HTML but later I renamed it to DTCoreText. I had switched to maintenance mode 8 years ago, because I had no interest in putting more work into an Objective-C code base.
Before I figured out how to use macros to enable SwiftMCP, I experimented a lot with SwiftSyntax and built a project that I called SAAE – Swift AST Abstractor & Editor. Such it lay forgotten on a public GitHub repo. So I figured, it would deserve a new coat of paint and a better name.
Read moreMy last update post was just two weeks ago, but the pace hasn’t slowed down. If anything, it’s accelerated. The common thread? Real problems encountered while building real things — my client project, the Post mail daemon, and a surprise from Apple that I’ll get to at the end.
Read moreInstead of writing blog posts about individual package updates, I think I’ll be changing things up a bit. My agents do a better job than me in summarizing the changes for individual releases, so I will from now on group them together, referencing the release notes on GitHub.
Read moreLicense:
