I’m a laggard, so I only recently started using a LLM to help with coding.1 Of course I’ve seen all talk online that makes you feel like an idiot if you haven’t fully outsourced your coding to the AI. But it never really resonated, so I didn’t bother.
Recently a reader of the blog friend convinced me to get over my aversion to new things and try it out. I used Claude, because he said it’s the best. I was pleasantly surprised!
Despite all the “you have to use AI or you’re ancient” talk online, I haven’t seen much practical “here’s some practical ways to use it in your day job”. So this post is an attempt at that, by sharing some things that have worked and some that haven’t. If you’ve ever coded with an LLM this is probably old news, but I think most people still haven’t so it might be interesting to them.
I’ve only included screenshots of my prompts for the sake of brevity, you can run the same prompts to see (broadly) what answers I got.
1. Programming tasks that aren’t domain-specific
I think there’s broadly two kinds of task in programming.
Tasks that are specific to your domain.
Tasks that aren’t.
For the first category, the solutions will probably involve using internal private APIs, working within your domain model, and catering your solution to the specific needs/requirements of your users. Lots of the programming I do feels like it fits into this category.
But not all of it! There are a lot of tasks where the approach is fairly generic, and there’s probably enough information on the internet (that the LLM is trained on) to devise a good solution to it, without any domain specific context. For these sorts of tasks, I was impressed at how good Claude at is at outlining the architecture, and writing the code.
For example, this prompt led to a good introductory explanation into how to approach this sort of problem:
And this one surely saved me days of working out from scratch:
Given that most of the code Claude would have trained on for this sort of problem is written in Python, the main challenge was times that it didn’t translate that code to Ruby well, this led to odd syntax errors or confusing approaches. But I know Ruby well enough to work through that (sometimes with Claude’s help).
What I learned from this is that if you have a task that is not domain specific, Claude can probably describe the architecture and write a good draft of the code for you. I haven’t done that yet but I imagine this would work particularly well for DevOpsy style tasks where you are trying to do things more like everyone else, and less catering to your own specific domain.
2. Dependency management
I couldn’t for the life of me get webpack to compile a bundle when referencing a specific NPM package. These prompts gave me some useful suggestions:
I got 10 suggestions total, and one of them was useful (I’d already tried about half). This one identified an error message which meant nothing to me, but something to Claude.
I was able to fix the first error based on its advice, this lead to a second error
Which I was also able to fix based on its help!
My takeaway from this was that a good way to think about Claude is like a colleague you have, that has read and memorised every single post on Stack Overflow. It was just suggesting all sorts of random stuff. Some I’d tried already, but lots of things I didn’t even know you could try. It was much quicker to have Claude list all the steps than to have to read through deep archives of Stack Overflow until I found the one thing that would help.
(Technically this is a subset of the first category.)
3. Debugging / figuring out APIs
All of these led to much better explanations, much faster than Googling would have. No follow up prompts on any of them.
This one I used when I wanted to answer someone else’s question, but didn’t have a good example handy:
This one several people spent days on, I only tried the prompt after the fact, but it guessed the root cause exactly right. That said, it’s possible that I would have worded the prompt differently if I wrote it before knowing the answer. But I was impressed at how it didn’t seem phased by me referencing (relatively) obscure libraries.
A big challenge I’ve faced is remembering to use Claude instead of Googling (or just doing nothing), this is a good example of that, where if anyone had thought of asking Claude 3 days earlier we would have saved 3 days.
4. Things that weren’t great
These prompts gave incorrect or unhelpful answers, which isn’t that surprising in hindsight. In both cases I had to do a fair bit of Googling and sleuthing to work out the correct answer.
This one led to advice that didn’t work at all. I think that is because the true answer is “you need to rethink the problem”, so it’s a bit of a null hypothesis which Claude couldn’t handle well.
At this point it suggested deterministic encryption, which works okay for matching emails (eg. for auth purposes) but not for fuzzy or like-based search.
The solution it proposed was to split messages into n-grams, deterministically encrypt those, and then search that, which I’m pretty sure is not right.
5. Conclusions
After a few weeks my takeaway is that using Claude certainly makes it easier to write code, but writing code was never the hardest bit. You still need to be able to ask the right questions. In fact that’s even more important now, because if you ask the wrong question - or if you don’t understand the question you’re asking - Claude will happily lead you down a bad path.
If you are asking the right questions then Claude (or probably any LLM) is a great tool to help you refine your thinking and get closer to a good solution.
I think this is much better than Github Copilot, Cursor, and other tools that are focused on writing the code for you. To me they are automating the easy bit (sometimes not very well, particularly if you care about the craft of programming). I don’t really need help with that, and to be honest I think most people would be better off just learning to write the code rather than being dependent on that.
To me the useful conversations with colleagues are those where you bounce around an idea, or try to dig deep into something to understand it. For those sorts of conversations Claude is a fantastic way to flesh out your thinking, particularly if the topic is not one that’s in a narrow domain. You also get a lot of value just from writing your question down; there’s lots of prompts that I half-wrote and never sent.
I’m paying $20/month for Claude, and I’m pretty happy with that.2
I wasn’t always like this, I used to love fads.
If you work for me, please expense it. Turn Copilot off too!
love this article, and totally agree on it's about understanding your problem and asking the right questions (and sometimes breaking down your question to smaller pieces), it's the same thing no matter asking your teammates or LLM for help. do you have any advice for junior devs to develop on this kind of skill faster?
i also found copilot often gives me the same/similar answer to a free gpt, but we are paying $250 for that. happy to switch it to claude