Avoid the copilot pause

Tips to maximize coding flow and minimize distractions when working with coding copilots

I assume you’ve heard about coding copilots, know what they are, and have probably used one. If you don’t, it’s usually an extension to your IDE of choice that autocompletes your code to make you more productive. While this sounds (and is) great, there are some potential drawbacks to be aware of, which we’ll discuss later in this article.

Why would I use a copilot?

Personally, I optimize for speed & momentum. I am at my peak productivity when I can sit for long hours, distraction-free, and get momentum. This is a great flow state that takes a while to get into. In general, I try to adopt tools to streamline my workflow so I can stay longer in the flow and maintain momentum. Copilots are one such tool that can help tremendously with that.

Copilots amplify my momentum and make the process a whole lot faster, which is why I find them such great tools. However, they amplify the momentum in whatever the current direction is. They can either be a great tool that speeds me up or a frustrating obstacle that I have to “deal” with.

I’ll try to talk you through my process of getting into the flow and avoiding copilots becoming a distraction.

The copilot pause

After using copilots for a while, you’ve probably noticed the good ol’ copilot “pause.” You know, that moment when you’re just waiting for AI to write what you’re thinking so you can press tab and go on with your life. That’s the pause.

It’s worth noting that the pause isn’t inherently bad; it’s just how our brains are wired. Adopting the pause should be an active choice, not just something that happens to you. I’ll talk more about how I try to mitigate this further down.

Flowing in two directions

From what I’ve observed on the internet, friends, and colleagues, most use of copilots fall into either of these buckets:

Being guided
Being guiding

Guided

The guided flow of using a copilot can be identified by expecting the copilot to solve problems for you, waiting for solutions, and being distracted. It’s easy to get here since we wire our brains to just wait and press tab when it looks good enough. Not only do we spend a lot of time waiting for code, but we also usually accept lower quality since we spent time waiting for that code. Don’t fall into the sunk cost fallacy!

I ended up here after the first couple of weeks of using copilots. It was probably due to me being mesmerised by this technology and developing a superstition towards it.

Guiding

The guiding flow is when you developing an intuioton for how the copilot works, when it provides the best suggestions and what you need to provide make it behave like you want it. You probably experience the pause in this flow too, but the results are usually way better. It’s almost a magical feeling when you set it up so it provides you exactly the code you wanted.

The key is to have solved the problem beforehand and setup the copilot to implement your already thought out solution. It takes a while to get into this, but it’s so worth it.

How to guide (the copilot)

What unlocked the guiding flow for me was to find a copilot that was both fast and accurate. After trying out a couple and switching between them, I eventually landed on Supermaven (not affiliated) and never looked back (yet).

What makes it good is a large context window and extremely fast completion time. This make the suggestions very relevant and in a fast way, causing my momentum to increase. I noticed how good it is the other day when I was pair-programming on a friends computer who was using GitHub Copilot. I kept pressing tab without anything happening…

Anyhow, here are a couple of things to help you:

Write descriptive comments around your code
```
# function used to sort by key in descending order
```
While I don’t use this technique a lot myself it can still be a useful approach. I find tools like Cursor to be more efficient as I can just prompt instead of putting my “prompt” in the comment.
Outline the function signatures
```
def sort_by_key(key: str, items: List[Dict[str, Any]]) -> List[Dict[str, Any]]:
```
This is a nice way to define contracts in your program, and it’s something I tend to do with or without copilots. It makes it easy for the copilot to fill in the code.
Use expressive, declarative names
```
function Accordion(
```
Becomes Using clear, descriptive names for your functions and variables helps the copilot understand the purpose and generate more relevant suggestions. Especially when you’ve used this piece of code in other parts of your system.
Know what you’re solving
If you don’t have the solution, so won’t the copilot. Once you’ve outlined the solution the copilot can help you with the implementation. The suggestions you get should not differ too much from what you would’ve written yourself.
Be less trigger happy
Make sure the copilot suggestions are actually what you want and don’t press tab too early. Tabbing too early will both cause the copilot to think it did well and leave you with poor code quality. At the end of the day, it’s your code.
Don’t wait too long
Rather than waiting for the copilot to kick in, try to write code until it actually shows up. We’re striving for momentum, so everything that’s interrupting should get thrown out