Insider Scoop: Our Co-founder's Take on GitHub Copilot 🔥

GitHub Copilot is a quintessential development tool that our team absolutely loves. This week, Helicone’s co-founder, Cole, shares how he uses Copilot in daily operations, and the most counterintuitive principle he learned while running a startup.

No BS, no affiliations. Just genuine opinions from Helicone’s co-founder.

An Intro

Two weeks ago, on Microsoft’s earnings call, CEO Satya Nadella announced that GitHub Copilot has 1.8 million paying subscribers. But it doesn’t stop there - Copilot’s growth is accelerating. In just a year, it has doubled its user base, from 45% of Fortune 100 companies that were using GitHub Copilot to now 90%.

Why do you love GitHub Copilot?

As a developer, I need tools to be intuitive, fast, and most importantly, built into my workflow. GitHub Co-pilot significantly speeds up my development time. In addition:

1. I don’t need to remember all syntax specifics - more language-agnostic.
2. I don’t need to type out boilerplate code.
3. I find it helpful for ideating. If I feel stuck, it often suggests ideas that get my brain going.

Share the backstory of how Helicone discovered Copilot.

As a developer, GitHub Co-pilot naturally became part of my suite of tools. Some companies have concerns about protecting their intellectual property and are hesitant to store their code externally. However, as an open-source company, this is not a concern for us.

How does Helicone use Copilot day-to-day?

We use GitHub Copilot frequently as it is integrated into our daily workflow. As a company, we provide access to Copilot for every developer on our team. The efficiency gains far outweigh the cost.

If you’re working in a startup, I definitely recommend purchasing a GitHub Copilot subscription for your team.

How has Copilot transformed Helicone’s workflow?

• Automate boilerplate code. Or find the correct syntax for different programming languages, which significantly speeds up my development time.
• Receive implicit feedback. If I don’t like a suggestion, I simply don’t hit tab. It is built completely into my workflow, so it does not impede me in any way.

This feature would be a perfect addition to almost all products. For instance, having similar suggestions while typing in Notion would be amazing.

What are your tips to get the most out of Copilot?

• Accept shorter recommendations. GitHub Copilot is best at handling boilerplate code that is quite obvious and seen often but may struggle with longer and more complicated logic that requires an understanding of different contexts.
• Learn to prompt suggestions. Sometimes GitHub Copilot doesn’t always show suggestions when you need one, try typing a few characters to prompt it. For example, typing con will suggest console.log, and adding ' to console.log(' will prompt it to write a message for the log and print out important variables.

Who would you recommend Copilot to?

I recommend GitHub Copilot to every company and every developer. For open-source companies like Helicone, the efficiency gain from using GitHub Copilot is substantial, making it a worthwhile investment.

🌶️ What’s a hot take you have about Copilot?

People often argue that GitHub Copilot prevents developers from learning syntax. I think the future of programming lies in collaborating with AI and focusing more on higher-level logic than the intricacies of programming languages.

While having a copilot is great, I’d recommend to not rely too heavily on Copilot. Instead:

• Think critically. Don’t accept everything it suggests. Complex problems require a deeper understanding of context.
• Use where it truly increases efficiency. Like handling boilerplate code.
• Review the code carefully. Aimlessly accepting recommnedations can decrease productivity and introduce more bugs.

🌶️ What’s the most counterintuitive principle you’ve learned from working at a startup?

Embrace bugs as part of the development process.

This is probably not something you’re used to in a corporate setting where weeks are spent on extensive testing and QA.

At Helicone, we launch features in beta and get feedback quickly to make sure it’s something that people want. This allows us to see how people are actually using the features and iterate based on real-world use cases, even if it means having potential bugs. Over-engineering, especially in the early stages, can often lead to a “perfect” product that ultimately no one asked for.

However, handling critical parts of the codebase is different. For critical components like our proxy service, we conduct rigorous testing. We barely release new code for it, wrap everything in try-catch blocks and use Cloudflare Workers to ensure reliability. As a result, we have been maintaining an uptime of 99.9999% over the last year.

For non-critical parts of the codebase, take the risk of having bugs. It’s okay to be embarrassed about having bugs in beta releases. If people love your product enough, they’re generally forgiving, especially if the bugs don’t affect their core business operation.