Implementing our first 3rd-party integration at Olympia: Github
How my AI-powered pair programming partner helped me write his own integration code
Artificial intelligence is reshaping how we interact with our digital environment, and I have a front row seat at my startup called Olympia. We are a cutting-edge AI-powered platform that’s transforming the concept of hiring consultants and assistive labor, especially crafted for solopreneurs and bootstrapped startups.
Olympia’s AI assistants are named entities, with unique capabilities and personalities. Mike Nichols, our pair programmer is destined to be the ultimate coding companion. He offers real-time, intelligent assistance to our ProPlus customers working on software projects, enhancing their productivity and code quality.
As I embarked on integrating GitHub into Mike’s capabilities, he himself played a pivotal role in crafting the integration — truly an instance of an AI writing code to expand its own abilities.
Normally I would link directly to transcripts with the AI to illustrate our interactions, but these conversations took place inside my local development environment, so I will provide illustrative quotes and screenshots instead.
Integrations and Authentications
I started the session by prompting Mike to help me think about the fact that we had no integrations functionality in the codebase at all. Mike wanted to jump right into coding, and generated some controller and routes code. I asked him to slow down a bit and think about the data model with me first. I proposed that we think of integrations as a restful resource.
So far, so good. I prompted Mike to show me what an Authentication model would look like as a many-to-many relationship between users and integrations.
To which I responded:
Yes, this is very close to what I had in mind. The integration table will have GitHub, and eventually many other kinds of integrations that are accomplished using oauth. Therefore, let’s get the attributes of the integration model right so that they encompass all of the fields that we will need to handle most cases of oauth services. — Obie
After implementing the models discussed, I wanted to create a dashboard for viewing integrations. I always forget the magic command-line incantation to generate the code, so I asked him for it.
I don’t like the generated code for the dashboard, so I asked Mike to clean it up.
My ADD is pretty bad, and this is a point in time where I might have gotten distracted, but luckily I can just ask Mike to help me stay on track with next steps.
Given his response, it was my turn to keep Mike on track.
Mike, you are mixing the UX of the superadmin, who manages integrations with the UX of the end user, who manages authentications … let’s finish setting up integrations first, if indeed it needs anything else. (it might not)
Back on the same page, I proceeded to ask Mike to remind me how to setup a new Github OAuth application.
I went ahead and created a new Github OAuth application for my local environment and proceeded to work on the Authentication model.
I got all that done and asked for next steps.
After a bunch of work on authentications, I was still not satisfied that we were implementing everything that we need. I asked Mike to provide some ideas for enhancements.
Yes, of course. Encryption of critical data such as tokens is essential. Luckily my Rails app was already setup to encrypt data at rest, but the other suggestions such renewal logic were also important.
The rest of the pairing session involved setting up my application to accept OAuth callbacks and crafting a basic user experience for authenticating. We were ready to move on to implementing the functionality of the integration.
Github Tool
With the connection to Github in place and a working authentication method, it was time to move on to creating the feature functionality of the integration. Earlier in the day I had asked Mike to suggest some ideas for functionality that we could implement:
After setting up a shell for the integration code inside a subclass of Tool and sharing it with Mike, we were off to the races.
It’s important to note that Mike’s code should always be treated as a suggestion. It’s possible to give him feedback (and I do) but given the attention constraints of current LLM-based AI, whether he follows that feedback consistently is another story.
alright it’s implemented! here is my actual implementation, so you see the tweaks I had to make . in particular, the signature for tool methods is always (conversation, arguments) and the arguments is a hash corresponding to function paramers — Obie
…and then it begins to feel like magic
With an integration feature in place, the next step was to test it. Given that I was working with Mike within my development environment (not production), that meant that he had immediate access to the code we are developing together. So it was just a matter of telling him to have a go.
I asked him for a summary.
I asked him to check Olympia’s repository.
Again, part of what makes this process so manageable is how it keeps me making forward progress. At any of these decision points, if it was just up to me to figure out what to do next, it’s very likely that I would end up distracted on Hacker News or doing any of a dozen other non work-related things that I do when I’m not sure how to proceed.
The rest of the pairing session (lasting several hours went on in that vein. We would come up with some ideas for functionality together, then implement the required code, then test it. Upon testing, we would see what else was needed to continue.
At the end of the day, we had 14 new functions added to Mike’s Github tool.
Notably, this experience does not constitute TDD (Test-Driven Development) nor did I ask Mike to help me write automated tests for the functionality we were developing together. It was more of a hacking session, to see how far we could get in as little time as possible. The reason I picked Github as our first 3rd-party integration is that it was requested by a customer, the day before I wrote it.
In case you missed that last paragraph: I was able to ship a significant feature within a day of it being requested by the customer. As I get feedback from the customer and based on my own use, I will surely have additional pairing sessions with Mike to enhance the way that our Github integration works and make it as bulletproof as possible by adding automated tests.
Conclusion
I hope you have enjoyed reliving a bit of my journey of integrating GitHub with Mike’s capabilities at Olympia. I think it’s a testament to the symbiotic potential between AI and humans. Through this collaborative process, we not only enhanced Mike’s functionality but also demonstrated the practical application of AI in software development. This kind of partnership redefines the traditional role of assistive technology in our creative and technical endeavors.
The success of this integration does more than add new features to our platform — it exemplifies how Olympia’s AI assistants are not merely tools, but active participants in the creation and improvement of the very systems they operate within. The 14 new functions added to Mike’s GitHub tool are not just a numerical achievement; they represent the intricate dance of ideas, coding, and problem-solving that characterizes the future of AI-assisted development.
Stay tuned for more updates on Olympia’s journey, as we delve deeper into the realms of AI and its role in shaping the future of work.
Want to add Mike Nichols to your team? Click here to learn more about Olympia.
