On Customizable software.
Much of how we built software has changed over the past year or so. Agents are much more capable than they were even just 6 months ago. It’s kind of surreal how trivial it’s gotten to customize software to your own liking. For instance, I use codex++, a tweak system that allows you to somewhat customize the Codex MacOS desktop app. I’ve built plugins to do things like use Pierre’s new diffs tool instead of the native diff viewer Codex supports or any of the existing tweaks such as support for /goal feature. These are relatively trivial though so I wanted to document my experience using agents for slightly more complex features.
I use Zed as my primary editor these days. It’s gotten much better since when I tried it out maybe 2 years ago. Basic primitives generally work well. I also use their Agent Context Protocol(ACP) integration which allows me to use my existing Codex/Claude subs in Zed’s agent panel. The codex ACP, via the subscription, however doesnt quite work in remote projects. That was frustrating because the whole point of the setup was to use Codex naturally from inside Zed, not to manage a separate auth mode only because the project happened to be remote. It would work fine for local zed projects, but you’d have to use an API key for remote projects.
Tracing the bug
I had an initial hypothesis that either Zed was explicitly disabling the browser-based login path for remote projects or The Codex ACP adapter only knew how to authenticate through a local browser callback flow and had no headless fallback. Armed with the hypothesis, I spun up codex. Code archaeology, root-cause analysis, patching, validation, issue triage, fork setup, release wrangling, and PR prep was all driven by GPT 5.4 and 5.4-mini interchangeably.
“Codex in Zed” is really several systems glued together. Zed knows how to install and launch registry agents, codex-acp is the ACP adapter process Zed actually talks to and upstream Codex owns the real auth flows and token storage behavior. Codex added support for device-auth which is what made it possible to fix. The PR is here but the gist of it was keeping local projects on the existing browser callback login flow, in NO_BROWSER mode, keep ChatGPT auth available and switch the headless path to device-code auth instead of hiding it. I definitely did not want to wait until Zed releases this fix, if at all, so I just patched the binary that contains this fix, and it’s been my primary way of using it.
Rust compile times are insane
This is my first time using Rust for a relatively large project, and man those compile times are brutal. This was not even a giant from-scratch product build. It was a targeted patch in a repo that pulls in a serious dependency graph through upstream Codex. Even when the code changes were modest, the build and link cycles were long enough that they shaped the entire experience. That changed how the agent workflow felt.
There was one point where we tried to produce polished release assets and got dragged through:
- missing
pkg-config - missing
libssl-dev - missing
libcap-dev - a stale apt repository on the Ubuntu box
- fork release workflow assumptions that only made sense in upstream CI
That whole stretch made the session feel less like “AI is doing software for me” and more like “AI is helping me stay in the loop while I fight the usual systems bullshit.”
What building with agents felt like
A few things stood out to me.
First, the best use of the agents was not raw generation. It was disciplined persistence. We kept narrowing from symptom to mechanism: From figuring out where does Zed decide this is headless to where is the ChatGPT method filtered. Does upstream Codex already support device code or is this a Zed limitation, a codex-acp limitation, or both?
Second, the models were useful as research and synthesis partners, especially when I already had a hunch but needed to ground it in code. They were good at turning a vague suspicion into a concrete explanation with file paths and behavior. Third, the systems boundary still matters a lot. The agent was most effective when the task was scoped, source-backed and verifiable. It was less magical when the task turned into orchestration across GitHub, local builds, remote VMs, and release asset handling. Still helpful, just less elegant. And fourth, I found myself wanting a better “long-running task” feel. When compilers are going and release assets are uploading, you do not need more intelligence so much as better ergonomics around waiting, status, and recovery. There’s still so much to innovate here.
Where I landed
The whole thing took maybe 5 hours, and most of it was actually I/O from either the LLM or the compilers, not my “processing speed”. It was also a good reminder that the hard part of agent-assisted engineering is often not the coding. It is the long tail: build systems, environment mismatches, release mechanics, and staying clearheaded while waiting for Rust to compile half the planet.