Introduction

This blog is about adventures that I undertook using Codebuddy to create a SketchUp plugin for work. SketchUp plugins are written in Ruby, but I have never used Ruby before, and I had never used SketchUp before. Within two days, I was able to far surpass what the company had already written for their plugin. But after the two days, I still hadn't written a single line of code! Thanks to Codebuddy and GitHub Copilot.

Initial Challenges

This was an interesting project because I wasn't just doing it for web development, which I'm very well familiar with. It was a plugin for a completely different sort of desktop application. It was definitely challenging.

In hindsight, doing a bit more research on how plugins like this are typically put together would have been very beneficial. The platform had far more limitations than I anticipated, which required some unconventional solutions. For instance, creating UI elements was particularly challenging due to limited options. One of the best methods turned out to be using HTML dialogs, which are essentially embedded HTML browsers within the application. This approach worked quite well, but it took some time to discover. Simply asking Codebuddy to create various components sometimes worked, but it was often not the most effective way and led to confusion, especially since I was new to this type of project.

It was confusing at first, considering I had never created a plugin like this before and had no idea how it was meant to be put together. One thing I needed to understand was that most of the UI work would likely require dialogs, which are essentially embedded browser windows. This method actually offered the most flexibility. Codebuddy suggested this approach, but I was resistant because I didn't think that was the limitation or the correct way to make these components. In the end, it was indeed the best way to achieve the flexibility I needed. However, my resistance caused me to lose some time because I tried to find other ways to accomplish the same thing. So, the takeaway here is that it's probably better to do some research into how things are typically done on a new platform. You can't always trust the AI to give you the right answer. Though in this case the AI was correct, as there really wasn't any other way to do it.

A Key Litmus Test to Determine If You're on the Right Track

If the AI starts hallucinating heavily, this is often a key indicator that you might be going down the wrong path. Work TOGETHER with the AI to come up with a solution, but do at least a bit of research so you at least have an inkling that the AI is responding correctly. This isn't a requirement of course, but you might find yourself with a few false starts if you don't at least get the lay-of-the-land with some old school documentation (or blog) reading first.

Balancing Codebuddy and GitHub Copilot

It was really nice to be able to have GitHub Copilot as an autocomplete option in this particular project because not everything was comfortable to be done with Codebuddy on its own. Codebuddy tends to be better at generating vast swaths of code or modifying multiple files to implement larger features. When there's just a little thing you have to do, you already know exactly what to do and where it needs to get done - autocomplete is definitely preferred. In my case I didn't know Ruby at all and I didn't know the syntax, that's when GitHub Copilot tends to shine brightly so having an autocomplete option alongside Codebuddy is quite valuable.

The Importance of Common Architectures

One of the most important things for any project that uses AI is to allow the AI to write code the way it wants to. You should request that it writes code in ways that are quite popular and common. It's not a good idea to try to come up with complicated architectures that are not widely used. You want to use simple and straightforward code structures that are used by many people because the training data is based on these sorts of structures. The AI will tend to organize the code this way naturally so really you just need not resist it.

Lessons Learned from OAuth2 Authentication

I wanted to create a web server on the plugin side to receive the authentication code, but this ended up having problems in browsers. Codebuddy had suggested using OAuth2 authentication, which would have been the correct course of action, but I wanted it to be simpler, so I didn't take that route. Unfortunately, I ended up finding out why that is the more popular option, because I had to rewrite that whole section to be more in line with what is done in an OAuth situation rather than creating a server on the plugin side. My solution did work (and we even used it for a while), but unfortunately it didn't work with every browser type, and specifically Safari gave us some trouble. This was an interesting case where I resisted the AI's insistence that we do it in accordance with best practices because I was afraid of the complexity that might entail.

Final Thoughts

Reflecting on this project, several key points and takeaways stand out:

• Initial Research: Crucial for understanding platform limitations and best practices. The SketchUp platform had unexpected restrictions, especially in creating UI elements. Doing some minimal research before embarking on an AI driven project is key to being able to guide the AI effectively.
• Balancing AI Tools: Codebuddy excels at generating large code chunks and handling complex modifications, while GitHub Copilot is invaluable for smaller, precise tasks where the exact syntax is needed. Other autocomplete AI tools may also provide good if not better results.
• Common Code Structures: Allowing AI to write code in commonly used ways is beneficial, as AI tools perform best with familiar code structures.

I have since written some Ruby code myself, and I'm quite proud of the plugin in its current state and I continue to develop it using both Codebuddy and Copilot. Integrating it with the webapp has also been a fun and interesting challenge... for Codebuddy. :D