Using Claude Code, web edition
Like everybody else, I spent the holidays coding with Claude
Over the holidays I started trying out Claude Code for web. Until now I’d avoided it based on early reports that its sandboxed environment and network restrictions were too limiting for meaningful work.
So I was a bit surprised to find it totally revolutionary.
Entirely from my phone, I’ve now used it to:
Cross off a dozen backlogged to-dos in my personal productivity tool1
Explore and abandon an idea
Streamline a maintenance-mode project’s deployment workflow2
Explore another idea and get somewhere with it3
Design and implement a Python library
Of course, these all have some substantial commonalities. They’re all either greenfield projects, or existing projects where I’m comfortable with a pretty flat commit → review → auto-deploy workflow. In all cases I don’t need to build and run the code myself to review it, and where applicable I’m happy to let CD kick in after a merge. They’re all projects with roughly zero code-level collaborators. They don’t have tremendously lengthy or complex install/build steps. And they don’t require public network access or autonomous research to understand, extend, or validate the code.
But I don’t want to undersell this. Those properties cover an enormous amount of potential work!
Delegating the backlog
Specifically, what’s most revolutionary here is the mental model.
Between doing it all on my phone; simultaneously running multiple asynchronous sessions; ending each session with a Github pull request that I can also review from my phone; and being able to finish something without ever cloning or running the code locally — I genuinely feel like I can fire off coding projects when I’m not working, and with very little cognitive overhead.
This in turn means that it’s starting to feel cheaper to just get something done rather than filing it onto a to-do list or keeping it in the back of my head.
The vanishing to-do list
It’s tempting to jettison my personal to-do list in favor of just doing things. But it seems pretty dangerous too. The to-do list is a useful tool for slowing down and prioritizing. Without that buffer, I worry this could accidentally turn into a kind of personal accelerationist treadmill that I didn’t sign up to be on.
The analogy with other “now I can do this from my phone, from anywhere” paradigm shifts over the past twenty years also makes me nervous. If just building stuff away from my keyboard becomes sufficiently low-lift, will I just build stuff while refreshing my email and Twitter?
I wonder if part of the solution here is making sure that “writing to my to-do list” remains at least as easy as getting things done.
A two-part workflow
For several of these projects my actual workflow was a bit more involved:
First, have a lengthy freeform discussion with ChatGPT or Claude about some broad topic
Eventually, export that entire conversation as JSON or markdown
And paste it into a file in a (potentially new & empty) Github repo
Then start a Claude Code for Web session and tell it to read the conversation and make & implement a plan
The initial conversation is pretty hands-on, and step two is (absurdly) impossible to do from my phone4. So for this workflow, the mental model is more “frontload the thinking” rather than pure delegation. But it worked extremely well!
Disposable code
I mentioned above that one of my Claude Code Web successes this week was exploring and abandoning an idea.
It started as a conversation with Claude Code about how Github PRs make it hard to see the per-commit red→green sequences that tell a TDD narrative. Claude then eagerly built a standalone app & database with Github integration; a separate Github comment automation; and a browser extension to tweak the Github UI.
Then we chatted a bit more about it and ditched the idea altogether.
Along the way I never ran or even meaningfully reviewed any of the code.
This felt productive in a new way. Building complete implementations is so cheap. The activation energy is so low. It’s not even vibe coding, because I didn’t look at the outputs either! Instead I was able to just treat the extensive, probably-fully-working end-to-end code we produced as some disposable notes jotted down incidentally during a conversation, rather than a “project” or a “script” or a “prototype” or an “artifact.” And now that’s one less idea kicking around in my head or on my to-do list.
I’ve always thought of code as not just a tool but also a text that was written by someone with a point of view — so someone should probably be reading it, hopefully with a critical lens. From that perspective, this shift is extremely discomfiting! But I think I need to get used to it.
Including:
Substantial features: Gantt charts and a configuration UI for kanban boards
UI improvements: better mobile layouts and mobile-specific interactions
Code cleanup: rewriting the overly complex API client layer
Bugfixes: one was a minor daily annoyance for the past year!
Code quality: finally adding tests, linting everything, and hooking up CI with green builds to Github Actions
This was a very silly one! For one website we had built, someone else now edits code and content directly in our Github repo, but our Vercel account refuses to auto-publish because I don’t want to pay for the extra Vercel collaborator seat. So until now we’ve just used a clunky workaround where they make edits and then tell me when they want me to review & publish them.
Now we just have a workflow that runs on all pushes and hits a Vercel deploy hook URL, so their commits will automatically build and publish right away.
It’s about monitoring a handful of Instagram accounts for new posts and then ingesting them for processing & display on a website. I’ve wanted to do this for a while but kept putting it off because I knew doing all the Instagram bits even for a proof of concept would be too annoying.
For this step only, I need to get over to my laptop and then use a Chrome extension like ExportGPT or my Claude Conversation Exporter.