How to Skip the Boring Bits of Coding // BrXnd Dispatch vol. 055
How to Skip the Boring Bits of Coding // BrXnd Dispatch vol. 055
A guest post about coding with AI
You’re getting this email as a subscriber to the BrXnd Dispatch, a (roughly) weekly email at the intersection of brands and AI.
One of the fun things about the world of AI these days is finding your people. For me, those are the hackers and thinkers who are moving beyond just reading headlines and actually getting their hands dirty with AI. Lately I’ve been trying to feature more of these folks like James, Jenny, and Nathan. Paul Ford is very much one of those people. Paul, if you haven’t run across him, is both a world-class engineer and a world-class writer (he’s one of two people in history to be given the entirety of an issue of BusinessWeek).1 He and his co-founder Rich hosted me on their podcast last week.
Anyway, Paul had a great newsletter this week, and I asked if he’d be up for me republishing it. Thankfully, he was, and I’m happy to bring you some other voices. As a shout-out, Paul and his company, Aboard, will be hosting an event during NYC Climate Week on September 25th, where they will show everyone how to use data, software, and AI, including Aboard, to adapt to climate change. If you’re interested, you can RSVP here.
Onto Paul’s post.
— Noah
PS - As always, thanks for reading, subscribing, and supporting. If you have questions or want to chat, or if you’re at a brand looking for AI help, please be in touch.
Over the last few months, there’s been a lot of buzz about using AI to help you write code, and tools like Cursor and Aider have started gaining traction. It seems that something big is happening; as long-time open-source developer Simon Willison put it in a recent blog post, “I still keep hearing from people who are skeptical that AI-assisted programming…has any value. It's honestly getting a little frustrating at this point—the gains for things like rapid prototyping are so self-evident now.”
Recently, I’ve been taking these systems out for a spin. I don’t program professionally any more, but I still like to code creatively: To learn what’s new, and to hash out ideas. As a result, I have a decade-old folder with nearly 100 little projects that are in various states of completion. What could AI make of them?
The way “AI coding” works is pretty varied, but at its essence, you describe what you want, and then the system tries to put it together for you. Sometimes it can be ambitious and set up lots of files and scaffolding (“Build me a web app with admin tools that lets me manage a collection of video files”); other times, you can type “make the button red” and it’ll make the button red.
It doesn’t always work. In one experiment, I wanted a little circular knob that could spin on the screen. Claude made a misshapen oval, then an even smaller oval. I kept saying, “No, a circle,” and it kept making worse ovals. Finally, I realized it had inserted styling code in two places. I erased some, and everything worked. I’ve had this experience a million times as a programmer—one variable overriding another—so it took me a minute or two to fix. If I was just starting out, it might have taken me hours.
At least so far, the hardest part of AI-assisted programming is getting that initial prompt right. It’s always been challenging to turn an idea into software, and that hasn’t changed—and you need to know how code works to move it along. This is very different from a lot of generative AI, where you tell the system, “Draw a dog in a hat” and it does that, filling in the blank page. With programming, you’re the architect and the bot is a carpenter that won’t ask too many questions. That’s fine if you know exactly how things should look and can direct accordingly, but less fine when you’re vague and then the carpenter puts the windows into the floor. You should have been more specific.
Now back to those (nearly) hundred projects. Most of them are incomplete because I didn’t want to deal with finishing them. “Finishing” includes: Writing documentation, adding tests, setting up the right environment variables in the right places, configuring things, incorporating admin tools, or doing lots of thorny little tweaks to how a database works. None of these projects are very important. They’re bits of JavaScript code, music-generator things, tiny experiments in displaying text, stuff I did to prove a point. At the same time, they’re not doing anyone any good just sitting around in a folder. Some should be on GitHub, in case anyone wants to make fun of them.
And here this new stuff works really well. It’s great at finishing things up and making them a little more credible. This is the part of programming where big efforts often fail—documentation, configuration, testing, maintenance. And with these tools, it’s often breathtakingly easy to accomplish tasks that are cognitively not that challenging but kind of dreadful. To the point that ten years of little projects, rather than being a weird personal archive, now represent a kind of fun hobby effort—I wonder how many I can put out there, in good shape, for people to stare at?
I’ve watched so, so many software efforts die in the clinch. The number of things to check off before launch seems to grow infinitely and people burn out. On big projects, they often quit—because few things are more demoralizing than software that doesn’t ship. I never, ever expected a tool that would offload the boring parts to quite this degree, and for it to emerge so suddenly. I think we’re just starting to figure out what that means. But for me, it’s a folder full of ideas that’s suddenly alive again.
If you know how a computer works but are easily bored and have trouble doing the tedious parts of programming, you should look into these tools. This is a wonderful technology for tech flibbertigibbets.
Flibbertigibbetly,
Paul