noDirection llc

Given how relatively new AI Assisted programming is to this industry, we wanted to see exactly how useful it can be by creating a new mobile app from scratch. We had an app idea that we wanted to create using React Native so this was as good of a time as any to build this out with some AI assistance. At the time of writing this article, we are about a third of the way done with this new app and have completely reset our expectations on how to use this new technology.

Lets layout the foundation for this project before we dive into our expectations and what we really learned from this experience. We are building out a Crowd Sourcing Mobile Application that we will be able to re-use for virtually any crowd sourcing concept. This will be similar to how game engine companies operate, the build the engine and a sample game on top of it to demonstrate its capabilities. The content for the product for the initial release is just the short game; this concept has a long game that goes far beyond a singular app.

Now that we have some context on what we are creating, lets jump right into our developer experience. We wanted to see how far we could push AI to do things for us and at the start of the project, we are incredibly impressed! We started out with this simple but complex request to GitHub Copilot.

Create a react native app that uses a firebase google login and google maps and a bottom navigation menu. This application must use the react native paper ui toolkit.

We were incredibly impressed by what it gave us in response!
1. It told us out how create a Google Firebase Account from scratch with step by step instructions.
2. It renders code for 3 base pages for the application so that the app would display a login, menu and map.
3. It gave us instructions on how to implement our custom Google Firebase account settings into the generated code

Boy were we impressed so far. We wanted to take it another step further and ask it to now render the command line statements to create the app workspace that we would insert the code and instructions into.

Now render the command line statements to create this project

The response continues to exceed our expectations so far all while starting to make us worry that our jobs may be in jeopardy in the new 10 years. This statement rendered all of the command line statements that we needed to run in order to create this project and it worked perfectly.

Now that we got the project up and running, we wanted to prototype the entire thing out before we started our real programming. This is when GitHub Copilot was incredibly helpful! We wanted to create a bunch of semi-functional dumb pages that we could share with all of our tested to prove out the User Experience before we started investing a lot of time into coding. I have never prototyped an app so fast in my life! I would create screens with simple statements like “Create a page that displays a map with 3 buttons that overlay the map” and Poof! Done! It took me all of a few hours to step through and refine all of the pages that I wanted to create.

Now that we had our app skeleton and sample pages created, it was time to start the real work. This is the point that our reliance of Github Copilot started to shift from a “Create this and be happy” role to “Help me figure this out” role.

For example, we had a page with a map and buttons overlaying the map. We wanted to add a new button that would automatically center the map to the users location and also drop a pin on the page for them to visualize where they were at. We noticed that Github Copilot would write the code to perform these actions, but in the process it would remove additional code that is deemed as not relevant which we really wanted to keep. Now I am sure that it was simply executing instructions that we gave it but as your logic grew in our pages, it was more and more difficult to rephrase our instructions so that it did not destroy other logic that is working fine.

Another thing that we noticed that was a problem is that it would often inject “import” statements in the at the top of the code that it would render but if you accepted the changes, it would inject the new code in the middle of the page, leaving you with a broken page that you had to re-factor. Even with having to refactor code, the end result was additional working code that we introduced into our application that worked well.

The biggest complaint I have about it is that it does not understand libraries and compatibilities. When creating projects and you specifying the libraries that you require, the versions and compatibilities are often not aligned. Now this is a small complaint because if you are a developer creating an app, I would have the expectation that you already understand this and can solve for this yourself.

The real pain comes from the general instructions that you give for a page which require Github Copilot to render UI Components when you are using a specific UI Toolkit. Say for example that you are using “React Native Paper UI Toolkit” for your app and need to render UI Components for sed page. The Paper Toolkit has small deviations from our standard components which it struggles to render properly such as the Button Component. The Paper UI Toolkit button component renders the values in a templated form <Button>my button name</button> versus a parameter form <Button Title=”my button name” />.

We found that when we tell it to do all of these things using “React Native Paper UI Toolkit” to render content with a button that it would often not be able to decern between “React Native” and “Paper UI Toolkit” so we continued to evolve how we gave it our instructions. Since this is nothing but underlying math algorithms figuring out how to write code from our instructions, we would reduce our instructions to actions and key words such as “Paper”. So a successful statement would look more like this: “Create a Button that does X, Y, and/or Z with Paper Toolkit”, purposely excluding generic terms such as “react native”.

What we found out through this experience is that Github Copilot is EXACTLY what they say it is. It is a Copilot and nothing more at this time however that is not saying that it lacks value because that is the furthest from the truth. Frankly saying that it is “just a Copilot” does it a dis-service because it is immensely invaluable to the development process.

This product is all about expectations, if you expect this to create the product for you then you are barking up the wrong tree. If you simply want a force multiplier while developing products then you have found your soul mate!

After coming to reality with Github Copilot’s abilities, we really started to hit our groove in regards to not wasting time on relying on this to do things that it cannot do.

Use cases when we love using Github Copilot:

• Writing small snippets of code – We use it to write small snippets of code such as loops, sorting methods, etc.. Things that it has been trained on with millions of samples which is mostly gets correct however even when it does not align with your intent, it is typically incredibly easy to adjust the code which is still exponentially faster than writing it from scratch.
• Prototyping a new Page – It is so much easier and faster just to tell Github Copilot what we want on the page rather than typing it out.
• Unit Tests – It makes writing unit tests so much faster because it can get most of it correct right off the bat and you simply have to take them over the finish line with any custom coverage you want to add.
• New Libraries – Learning new libraries is so much easier because you can simply tell it how you want to use a library that you have minimal experience with and “poof” the example code is there.
• Explaining Code – It does a great job at explaining complex code to you when you are struggling to understand another developers complex, short hand code, etc.

Use cases when we don’t use Github Copilot for:

• Extending on complex code – We found it typically attempts to re-write or remove code that does not pertain to its intent.
• Writing complex classes – We just need to stop being lazy because there are just too many micro decisions that need to be made to complete most complex regions of code. Its great to get you started but you are still in the drivers seat.
• Creating our initial projects – We struggled a lot getting projects with many dependencies setup properly. It is not good at aligning dependencies and understanding library short comings, etc..
• Resolving complex broken code – Most of the time when we are stuck, it is not because we don’t understand how to form simple lines of code, its because of an underlying library constraint or conflict. It is not the best at resolving issues like that which require a lot of digging and evaluations of external libraries, their versions and what they changed in each version, etc.

If you are a programmer, be-it as a hobby, aspiring programmer, or paid then the answer is an overwhelming yes. The service costs $10 per month which is honestly feels like pennies on the dollar relative to the service that it provides. If you still struggle with that, then ask yourself the next time you buy a luxury item at the Grocery such as a “Christmas Ale” which is the costs 2 months of this service. Now think about how much more free time you would have to drink that Christmas Ale because you can getting your work done faster! Its really a win-win for you.

If you are like us, sometimes you get “writers block” which slows down your flow, having a tool to mitigate things like that and keeping your velocity high is invaluable. It reduces your time coding the simple stuff so you can keep pushing the big picture forward with maximum focus.

Additionally, this can be treated as a learning tool, teaching you new ways to write code, new ways to approach problems, and new ways to view how to engineer your overall solutions. This is the easiest way to get you out of writing code and solutions the only way you know how.

This is one product that I will never part ways with as it is exponentially increasing my productivity in more ways than just writing code.