What would you do if I coded with Claude?
I get by with a little help from my friends (aka millions of floating-point numbers)
In short:
- I finally learned Swift, to the extent that I could build slightly-more-than-trivial demos of my invention.
- Claude and tools based on the Sonnet model are excellent for this. Aider and Claude Code take this a few steps further.
- I recommend starting with prompt-copy-and-paste, first, then some kind of prompt-and-review cycle, then full “agent coding”.
1. Does it worry you to (learn) alone?
I’ve wanted to pick up more in-depth experience with Apple’s platforms for a while. Every time I tried, whether it was Objective-C, AppKit, UIKit, Swift, or SwiftUI, I bounced off. Many weekend projects that started with optimism about building Very Fine Software that lost momentum after a few hours.
Working with LLMs changes the equation here along two axes: - Previously, I would get mired in strange syntax, novel library concepts, or tooling. Now, I have an endlessly patient, and somewhat knowledgeable partner to prevent me from getting stuck. Or, at least, point me in a promising direction. - Conversational interfaces make resuming projects easier. They feel familiar, like team chats. While AI models aren't true collaborators, interacting with them helps me maintain momentum and motivation like a good team chat does.
Claude (Sonnet 3.5, in particular), is good enough for my purpose of learning SwiftUI and all the intricacies of developing for Apple’s ecosystem. I went all of February building a different kind of SwiftUI experiment each week. All with some kind of LLM (I tried GPT-4o/o1 as well) assistance. This sustained effort was a major improvement over trying to do the same with a combination of books, searches, videos, and intuition.
My workflow at this point was 1) write a prompt, 2) review the result and 3) copy-paste code from Claude to Xcode when it all made sense. This isn’t the most fulfilling way to build, but it is a great way to learn if you're a hands-on sort of person. Xcode has pretty good affordances for this, too! When you copy a new file from Claude and paste it into the file browser sidebar, Xcode figures out a filename based on the class/module name and creates the new file for you. 🧑🏻🍳
2a. I need somebody (to paste the code for me)
Partially because of the hype and partially because copy-pasting feels chump-ish after a while, I gave “AI agents” like Aider and Claude Code a try.
Aider bills itself as an “AI pair programmer”. No notes on that framing; it does what it says. AFAIK, Claude Code or OpenAI Codex came later and are basically first-party takes on the same idea. You, the human, write prompts (in a terminal program, like the console or REPL for your favorite language) (your favorite language does have a REPL, right? Right?!) to implement features, fix bugs, answer questions about the code, etc. Aider runs in your project directory with access to your codebase. It extracts context, prompts your chosen AI model, updates files, and runs tests. It is very persistent in attempting to implement your requested changes, sometimes to the point of sending itself in futile query/try/repeat circles. Just like humans, it is often determined, to a fault, to get a result.
This feels like a plausible future of building with LLMs. Even more so once local/small models are good and fast enough. Currently, coding agents consume plenty of tokens. A single feature, over the course of several turns and a bit of brute-force tries by an LLM, requires a dollar worth of tokens or more. Extrapolated over a week of developer’s work, you’re probably looking at hundreds of dollars of API use per dev. That’s a worthwhile trade-off, but it’s a novel sort of expense! We developers are used to writing code for free and sometimes paying to execute it (e.g., development environments hosted in metered cloud environments like AWS.) Paying to write and execute code is a whole other mindset, at least for the interim.
Beyond operational cost, having an LLM chat running in a terminal session (optionally accepting pastes from another LLM or watching for instructions from special comments in your source tree) is a major shift in how we relate to writing code. Again with comparisons to junior developers: what if they iterated in seconds rather than minutes or hours, and they were fantastic at running with your initial direction rather than checking in at every step. Working this way, it’s easy to get down a rabbit hole of machine-generated code and lose track of either the system changes or the feature you’re trying to build up. There’s plenty of room for UX improvement. But, it’s an intriguing preview of how we might build software in the future.
Claude Code works very similar to Aider. It had drastically fewer knobs and levers. I think that’s mostly for the better, though I’m sure this depends on the subjective observer. It’s equally over-eager to jump in and slop out way more code than is advisable at one time. I find myself having to tell LLMs of all makes and models to “take this one step at a time; only implement the next step that I’m telling you about; resist that very tempting SPEC.md file describing the entirety of what we’re building here.”
2b. Do you need anybody? (I just need a little more control)
For a middle ground between manual coding and full automation, try Copilot Chat or Cursor. These integrate AI assistance directly into your preferred development environment. They don’t take over your coding loop or require learning a new tool of choice. I’ve used Copilot Chat in RubyMine. That lets me prompt the model, see answers in-situ, and copy code out if I want to take it slowly. It also has an “edit” mode where the chats contain code diffs, and I can choose to merge them bit-by-bit or wholesale. This is basically exactly how I aim to work. I look at one diff at a time, decide whether to merge them, tweak them, or re-prompt. Rinse and repeat. This comes with the advantage that the cost of LLM usage is rolled into paying for GH Copilot. Nice and predictable.
Unfortunately, if you’re doing SwiftUI development, this approach isn’t available. There’s no option or plugin for this workflow in Xcode right now. I think some people are using Cursor separately for this, but I haven’t tried that.
You could stop here and get most of the benefit of generating code via LLMs. IMO that’s fine! Agent coding is sometimes a miracle and sometimes almost as mentally taxing as pairing with a real human.
3. I’m gonna try with a little help from my (agents)
I recommend against skipping to the end here. Using conversational interfaces for code generation feels like driving in a school zone. Letting an agent rapidly change and test dozens of code lines is like racing on a speedway. Everything comes at you faster, and the controls operate differently at higher speeds. The little voice in the back of your mind that tells you this is maybe not the best idea will be louder than you’re used to.
Therefore, start like I did: write a prompt to explain the problem to the model, encourage it to ask questions, iterate on the idea, and then ask it to generate some code. Review the response and code, manually paste to the appropriate files, and test/verify the resulting program. Rinse and repeat to build up your trust with the model and shorten your conversational turns with the model. (This is a great time to start reading prompting practices recommended by whichever AI lab you’re using.)
Once you’re comfortable with the conversational interface and prompting models to get the pace and information you prefer, try bringing the prompting into your code editing process. Write the same prompts, see what the machine produces, and decide whether to pull the diffs in wholesale or edit them as you go.
To experience the cutting-edge, try Aider, Claude Code, or OpenAI Codex. You might glimpse how we'll work alongside human-like intelligences in the future.
As if you haven’t heard it enough, I think the small steps and giant leaps of working this way will change the complexion of software development quite a bit. Not just for developers, whose workflows and time allocation will change dramatically.
Every part of the process in building software just got a bit less expensive. Ideas are easier to expand upon, specifications are easier to write, plans are easier to start, task lists are easier to split out, code is easier to get started on, onboarding is easier to do, the list goes on.
The world won’t want less software because of this, but a lot of software ideas will (appear to) be attainable to non-experts. The experts will work on systems with larger, and sometimes spookier, scope. In the interim, experts will probably spend a surprising amount of time setting up feedback loops and constraints to keep agent coders (and the humans using them) on the golden path and prevent slopping out code that’s going to surprise or ruin the team later.
If “vibe coding” doesn’t seem like your thing, but you still want to experiment with new tooling, learning and working with a model to build out ideas is a great skill to cultivate.