Best Practices for AI Assisted Programming

Best Practices for AI Assisted Programming

Do you wish you could write code faster and more accurately?  You might not be using your LLM enough.

I am a software engineer with 20 years of experience.  Over the last few weeks, I have been going to hackathons and events in San Francisco, and coding with all kind of teams. 

I often find myself writing code faster and more accurately than my peers, who I know are *much* smarter and better programmers than I am. And it wasn’t always this way.  A year or two ago, I couldn’t develop nearly as much software in a day as I can now.

What I noticed is that many engineers aren’t incorporating AI code writing tools as they code.  And this is slowing people down, – especially in a hackathon in environment.  I think a lot of folks  haven’t really figured out how good the code-writing tools are, or how to use them effectively.  They are writing code the way I _used_ to do it.  AI generated code works great at hackathons, and people don’t take advantage of it enough. 

Here are three patterns I see engineers doing:

  • reading the documentation
  • writing complicated algorithms by hand
  • using a libraries they already know

These are all really good things! Reading the docs is a really good thing! And so is being able to write a complicated algorithm.  And so is using what you know!

But you can use AI to dramatically speed up and improve your experience with all of this, by adopting a few simple tricks.

  • Put the docs into the AI, before reading the documentation
  • Let AI draft the algorithm before scanning it with your eyes
  • Learn new libraries and tools so you can find and use the best ones, before resorting to the familiar.

Or, as I think of it: put/let/learn. 

let AI draft the algorithm before reviewing it by hand

Often, when I am writing code, I what is supposed to come next.  And I can express it clearly in english language.  It might be that I need a for loop that modifies a variable, or I might need to call a common really well known library ( like, if I want to make my app sleep ).  It’s so much easier to type ‘for loop’ than the whole syntax that varies slightly from language to language.    It can also solve one of the hardest problems in programming – naming things. It’s surprising how often the AI gets it right, especially if your code is already clean and well organized.

Most stuff has been done before by someone.  But that doesn’t necessarily mean you have done it.  LLMs are really good at figuring out the most common way to do a thing, which is usually what you want to do.  This is great for setting up a system that you know you want, but don’t know how to implement.  If you need a small event-dispatcher or A* algorithm, you can let the AI draft one for you. You have the advantage of simple, open-source code, without having to become an expert in event-dispatch architectures.  Or whatever.  It’s also great for brainstorming.  Sometimes you know one or two ways to solve a problem, the AI can give you a comprehensive list, and can help you weigh your options.

Just like any developer on your team, you can help the AI by giving it a nice place to work!  The cleaner your code is, and the more clear the patterns are, the more likely the AI will repeat your pattern, and write the thing that you actually want.  I think of it like setting up dominoes to fall – if it’s super obvious to you as a human what should come next, the computer will see it also.  The difference is that a computer can write in a few seconds what could take you a few minutes ( or much longer ! ) .  The more clear naming conventions you use in your code, the more likely the AI will generate something that just fits in.

learning new libraries and tools so I can find and use the best ones

There are at least a zillion software libraries today, and it’s impossible to know all of them, and it’s not always clear which ones will be important.   LLMs can let you quickly write idiomatic library code.  This works especially well in commonly used libraries.  If you want to draw a chart in pandas/numpy, but have never used either library since you graduated college, it’s a great way to get the basics written for you. If you know its possible to write abetter chart in d3, but you don’t actually know d3, the llm can get you set up fast.

AI lets me work quickly in domains where I am not an expert.  For example. I have studied a lot of python and a lot of typescript.  But I recently had to work in Ruby.  It’s amazing how quickly 20 years of programming experience becomes useless when you switch languages. If I want to do a simple thing in ruby, like writing a for loop, I have to go look up how to do it.  And then, 1 hour later, when I need another for loop, I have to go look it up again.  It’s amazing to be able to write small snippets in python, which I know really well, and then switch right over.  You can do this too!

Put the docs into the AI, before reading the documentation

You should jam as much relevant information as you can into the prompt.  You can use something called RAG ( think of it like what you use to clean the kitchen ) to make sure you get the right stuff in the prompt.  Cursor, the IDE I use as of April 2024, has it built in, so you don’t need to think about it too much.   

As of April 2024, I am using an IDE called cursor.  It’s basically Visual Studio Code, but with really good AI integration.  Cursor is a big step up from GitHub co-pilot, which you may have tried before, because it allows you to have full conversations, and to augment the AI with your own documentation.   The conversational interface is really important, and one of the reasons why copilot often falls short.  The AI usually gets it wrong the first time, and you need to iterate with it a few times to really tell it what you want.  Often I want to ask questions about a library, or do some brainstorming.

Here is a hot trick, which I like to call the ‘at’ trick: When I start using a new library, or programming language, or repo, the first thing I will do is tell Cursor to index the documentation.  It’s some one-time set up but it pays off really quickly.  Then, anytime I have a question about the library, I can tag the library in my query, and cursor can figure out the relevant parts.  This is a huge trick for figuring out how to write idiomatic code in a library you haven’t used before.     Why is it called the ‘at’ trick? Because you can just type ‘@‘ to index documentation.

A word of warning

The AI is not perfect.

The final trick is to read what it writes!  At the end of the day, you are still the human, and you know what you are trying to do better than the computer does.  60% of the time the computer gets it right the first time, and I use those as learning opportunities.  Usually I gain an insight into the idiomatic way to solve a problem, or a new library I didn’t know about.  20% of the time it does something obviously wrong, like making code that obviously won’t compile, or simply not answering your question.  Usually a rewording of the problem can fix this. 

The most dangerous is when is does something subtly wrong.  For example, if you ask it to write A*, it can write something that looks mostly like A*, but doesnt quite work correctly. This can be really hard to debug. It can also generate code that’s an overly verbose, or that catches errors that should be thrown up the stack.  This cn lead to really subtle problems, where the code looks like it’s fine most of the time, and then fails silently later on.  This requires plenty of vigilance and thought – or hours spent debugging – which is what we wanted to avoid from the beginning.   


In summary, using AI to write code can solve some big problems.  My three main things are writing code, brainstorming, and learning libraries. And then I remed her to set up my IDE, give the AI good context, and to read what it writes.   

Just remember put/let/learn

  • Put the docs into the AI, before reading the documentation
  • Let AI draft the algorithm before scanning it with your eyes
  • Learn new libraries and tools so you can find and use the best ones, before resorting to the familiar.

Give cursor a try, and don’t forget the ‘at’ trick. 

And soon you’ll be writing quicker and better code! 

Happy coding!