NikCreate

It’s been awhile due to a busy schedule, but over the course of a few weekends since December, I’ve had the opportunity to test out Github Copilot’s ability to assist with code development and continue exploring Generative AI’s ability to assist in app development. At first, I decided to start another Alexa skill called NickLife, which I could ask Alexa how my day was and have it pass data from Fitbit to OpenAI’s API to get a natural language response. After getting the integration working and a mediocre response at some point in December, I decided to shift focus to creating a webapp for a feature I’d found myself wishing Fitbit had: exercise logging.

Fitbit is great for logging steps and aerobic exercises, even having integrations with Peleton to sync bike rides. It can store data on food eaten with a useful database of nutrition facts, syncs nicely with my Pixel Watch to log my sleep and with my Withings scale to track my weight and body composition. For an app, I use for so much, I find myself with a lot of nitpicks of it. As I discussed last time, they’re Alexa skill couldn’t log food data, leading me to develop my own. While collecting a lot data, there aren’t a lot of customization options for graph displays, for instance to see weight and food eaten in the same graph, or macros vs body composition. This has led to me thinking about exporting the data, creating my own UI and adding graphs for tracking weight lifting over time, which fitbit had no support for beyond a “notes” section when adding an activity, which only tracked time and calories burned while I wanted to track my weight and reps on different exercises.

So, NickLiftWeight was born as a start. I’d create a web app to track how many reps I could do for different weights in a React/Node JS web-app that would give me another missing piece to my tracking system along with an opportunity to see what I could with new AI tools, in this case, Github CoPilot.

NickLiftWeight – Site Walkthrough

Let’s take a look at the site itself first. Authentication is handled with Oauth via Google (currently restricted to approved emails).

After signing in with your Google account, you’ll be greeted with a dashboard displaying your exercises broken down for 5 different categories – Chest, Arms, Back, Legs and Abs. Clicking on one of the Category buttons will display graphs showing max and average weights over time for that category.

Users can log workout to add a list of exercises for a day, each exercise consisting of a list of weight/rep pairs.

If an exercise the user does isn’t present, they can add a custom exercise by setting the exercise name and category.

Over the course of development, I’ve gotten used to logging my workouts into the site making it somewhat of a success for me.

The frontend you see above is written in ReactJs . On the backend, there are two tables in DynamoDB, one for user’s weightlifting sessions and one for their exercises. A Node server handles taking user requests and interacting with the database as well as the Google login, which is also used for associating workouts and exercises with the user who logged them.

Overall, I’m pleased with the simplicity of being able to log weights and reps and have graphs to look at for them. I can see a couple of potential next steps for improving this. First, the graphs don’t display nicely and I tend to keep track of exercises first on my notes app and then load them on the computer as I get home. It would be cool to have a mobile app which I can log to over the course of the workout and submit when done. Part of my long term goal is to have this be one section of a larger app which also contains my Fitbit data and lets me compare diet, exercise, weight and sleep to try and draw better conclusions on my health strategy.

Github Copilot

For development of this app, I switched between Github Copilot, GPT 4, and falling back on my coding skills. Github Copilot is a very neat tool which provides LLM capabilities in your code editor, in my case, VSCode. It provides the ability to ask questions of your codebase as well as edit your code based on prompts you give it. This sounds scary and awesome, however the limitations are quite frustrating when it comes to speed of turning an idea into an app. The first key breakdown of that cool description I provided is that these are separated into two very different LLM features.

• Chat – appears in the toolbar in VSCode and let’s you ask questions of GPT-4 (at the time of this writing) and provides an “@workspace” which provides the LLM with files from your codebase as part of its knowledge base.
• Code-editing – In VSCode, you can open inline chat with CTRL+I in order to get a chat box which can generate or edit code within the file opened, previewing the changes and letting you accept or reject them.

So, when opening the Chat tab, it can’t make any changes to files and acts basically as if you had a ChatGPT window open in your code editor. The ability to ask questions of your codebase with the workspace command is good when it works, but it was hit or miss and the chat would often respond by saying that it didn’t know my specific implementation and would show how a feature might look, ignoring a lot of the benefit that should come from its ability to access the code base. Still, a lot of the time it is able to fetch files and determine where a bug may come from. Lastly, after awhile of having a chat open, you may start seeing

Encountered an error while deciding what workspace information to collect: failed.

This seems to be due to context getting too big, and took me awhile to realize I just needed to start a new chat to get it working again.

Regarding the inline chat, it does help with coding specific tasks, if you know what kind of function to make or line to write, it can make specific changes for you, but it more so speeds up code writing rather than helping turn an app idea into code from the start. Nevertheless, being able to write loops or functions in English and having a proposal for a code change appear is definitely quite helpful. I think the biggest frustration I currently have is that the editing chat is tied to a specific file. The chat where you can ask a question of the whole workspace wouldn’t be able to make the change, and a lot of context switching is required. If the core chat had the ability to open referenced files and allow the user to approve all desired changes across files, that would go a long way.

For now, the inconsistencies led me to using ChatGPT for a better experience, where I uploaded files I thought would be relevant along with error messages or screenshots from my app to help with debugging. Disappointingly, this provided a better experience much of the time, and there were only a few occurrences where I needed to figure out a bug without AI.

All in all, Github Copilot is a very neat product that could become incredibly powerful with a bit more tuning but for the time of this development had a lot of frustrating aspects. I’m sure this is far from the end of in-editor AI, so I’m excited to keep playing around and keep an eye out for updates. Both ChatGPT and Github Copilot’s chat were surprisingly good at explaining how to start building the features I wanted and providing starting code along with deployment steps, and working through bugs in the generated code. Still, even with trying to let AI do all the work, there were still a lot of bugs to work through and it’s still a ways from instantaneous idea-writing to app generation.

Lastly, one cool thing I enjoyed was ChatGPT’s ability to reason with CSS files and screenshots from my site, and how it could provide suggestions for code updates based on the image it saw. Imagining a world where you can have an AI monitoring your screen and making suggestions without requiring constant uploads or workspace commands seems exciting and I can definitely see that happening in the future. For now, I’m excited to continue testing new AI tools that come along and trying to speed up the process of turning an idea into an app.