Do you think laziness is bad? Let me offer you a different perspective. I don't think it's good or bad; I see it as a force. We can harness this force to achieve more—just like nature uses it to make us smarter.
Do you think laziness is bad? Let me offer you a different perspective. I don't think it's good or bad; I see it as a force. We can harness this force to achieve more—just like nature uses it to make us smarter.
Hey there, fellow developers! 👋
I've got some exciting news (and a bit of housekeeping) to share with you all. If you've been using Betalgo.OpenAI, you'll want to stick around for this.
First things first: I'm updating the PackageId and Namespace of Betalgo.OpenAI. Why, you ask? Well, the new official OpenAI library decided to use the same namespace, and we can't have that kind of identity crisis, can we?
So, moving forward, the package will be named Betalgo.Ranul.OpenAI, aligning with my broader project, Ranul-Tinga. This toolset aims to support different AI services under one roof, including the SDKs I've built for Anthropic and potentially others.
Shared Models and Mappers in Future Versions: While not in this version, future updates will introduce shared models and mappers. This will help developers shift between AI models with less friction. Stay tuned!
Expect Refactoring: There will be significant refactoring in the library. While I'll try to minimize the impact on you, some renaming and adjustments might be necessary. I apologize in advance; I promise it's for the greater good!
Utilities Library Update: The utilities will move to another library and probably get more updates.
Models May Move: Models might move to another project or even another repository. I need to plan how different repositories will use shared objects.
More Online Tools: I'm working on more online tools that you can use with your projects during development or after deployment.
Now, let's talk about the elephant in the room—the Microsoft Official Library versus Betalgo.OpenAI. You might be wondering why I'm continuing to develop my own library when there's an official one out there. Well, grab a cup of tea(or coffee, no judgment here), and let's dive into it.
Initially, I aimed for Betalgo.OpenAI to match the interface of the OpenAI Python library, thinking it would make the transition smoother for developers familiar with it. This approach also allowed developers to use OpenAI documentation and Python samples easily with the .NET library. However, I've realized that what developers really need is ease of use and simplicity.
Therefore, I'm shifting my focus to make Betalgo.Ranul.OpenAI even more user-friendly, prioritizing straightforward usage over strict interface matching. The goal is to reduce the learning curve and make it easier for developers to integrate AI into their projects quickly.
While tools like Semantic Kernel and the Official Microsoft Library are powerful, I find their interfaces a bit overcomplicated for my taste. Don't get me wrong—they have their merits—but sometimes you just want to get things done without unnecessary complexity.
I've automated some parts of the development process and continue to improve them. While fully automating the entire process remains a developer's dream, these improvements have helped streamline development and enhance productivity. Automating everything isn't quite feasible yet, especially when dealing with rapidly evolving AI APIs, but every little bit helps.
One of the biggest hurdles in developing AI libraries is dealing with lagging documentation compared to the actual production code—and let's not forget the lack of changelog documentation. Often, I have to test every field individually or sift through example codes to spot missing or incorrect fields. Relying solely on API documentation or generating code from official YAML files? A pipe dream at this point.
Many AI providers use Python, which isn't type-safe. When you're consuming the API with a type-safe language like C#, it becomes a manual implementation nightmare. This challenge has, oddly enough, kept me motivated to continue developing my own library rather than fully embracing the official one.
The official library boasts auto-generated code from YAML files for quicker updates. In theory, this should allow for instant updates whenever the API changes. In practice, however, it's not that simple. When I tried this approach, it slowed me down due to conflicts and discrepancies. Instant updates sound great, but given the current state of documentation and real-time API changes, it's more of a myth than reality.
Yesterday, I had the pleasure of attending the OpenAI London DevDay. Feeling lucky to be there is an understatement! Last year, I hoped to fly to San Francisco for their DevDay but couldn't secure an invitation. This time, fortune favored me.
Most of the sessions covered familiar ground, but they included some extra details that were quite insightful. And yes, I might have taken a few too many stickers and pins—but who doesn't love swag?
Meeting fellow developers and the OpenAI team was the real highlight. The conversations broadened my perspective and answered questions I'd been pondering for a long time. This was invaluable and has hopefully paved the way for speeding up the real-time API implementation.
Speaking of which, it's nearly ready! Hold your horses; I know many of you are eagerly waiting, just as I am. I have lots of ideas I want to test, and I'm as eager as you are to complete the implementation. It's coming soon and should support all features, including tools.
If you'd like to get updates about the Ranul toolset, you can:
Your feedback and real-world use cases are invaluable as we continue to improve and expand these tools. Whether you're an AI enthusiast, a seasoned developer, or just getting started, I hope these libraries make your journey a bit smoother—and maybe even fun!
This marks the first installment of my AI Updates Series. Creating and updating these libraries has been a journey filled with challenges, late-night coding sessions, and perhaps one too many cups of tea. But hey, who needs sleep when you have code to write and AI models to tame?
Stay tuned for more updates—in another blog post, I'll compare code examples to show you just how seamless the experience can be with Betalgo.Ranul.OpenAI.
As always, happy coding! 🚀
Cheers,
Tolga
Betalgo.Ranul.Anthropic
Hey there, fellow developers! 👋 I'm excited to share a new tool I've been working on that I think many of you, especially those working with AI in the .NET ecosystem, will find useful.
As some of you might know, I previously created the Betalgo.OpenAI library for working with OpenAI's API. That experience got me thinking about other AI services, particularly Anthropic's Claude. After mulling over the idea for a while (and getting sidetracked by other projects), I finally decided to dive in and create a .NET library for Anthropic's Claude AI.
You might notice that unlike my previous OpenAI library, this one uses a different namespace: Betalgo.Ranul.Anthropic
. This is part of a larger project called Ranul-Tinga (more on that in a future post!), which aims to create a universal API for accessing various AI providers.
Creating this library came with its share of interesting challenges. Here's a peek into some of the hurdles I encountered and how I approached them:
Anthropic's documentation is generally good, but like most APIs, it had its nuances. Some information was distributed across different sections, requiring a bit of detective work to piece everything together. It's a common challenge in the fast-moving world of AI development, where keeping documentation perfectly up-to-date is a Herculean task. Who knows, maybe AI will solve this problem for us in the future!
While Anthropic's API shares similarities with OpenAI's, there are notable differences. One major issue I've encountered with some AI APIs is their lack of consideration for strongly typed languages. Anthropic's API fares better in this regard, but there were still some areas that required careful thought to integrate smoothly with .NET's type system.
A significant challenge was figuring out the best way to introduce API fields to developers while keeping the library flexible for potential future changes. It's a delicate balance between providing a robust structure and maintaining adaptability.
I set myself the challenge of allowing developers to use the library with minimal lines of code. The goal was to make it easy to read and less daunting to start using. In theory, you can now create a constructor, call the messaging method with a new message request, and print it to the screen in just three lines of code.
var messageRequest = new MessageRequest {
Messages = [Message.FromUser("What is the capital of France?")],
Model = "claude-3-opus-20240229",
MaxTokens = 100
};
var messageResponse = await anthropicService.Messages.Create(messageRequest);
if (messageResponse.Successful) Console.WriteLine(messageResponse.ToString());
Moreover, I put a lot of effort into minimizing runtime dependencies. This approach, which will be a key differentiator of the Ranul-Tinga project from other AI frameworks, reduces the reliance on runtime code. It's one of my pet peeves when a project heavily depends on runtime evaluation, so I tried to avoid this as much as possible. The result is a more predictable and easier-to-debug library.
These challenges shaped the development process and ultimately led to some of the unique features of this library. It's been an exciting journey of problem-solving and optimization, always with the end-user - you, the developers - in mind.
Interestingly, I used my previous project, Mergy, to help create the README file for this library. I'm also planning to use it to generate wiki pages. It's gratifying to see a tool I created becoming useful in my own development process.
Now that the library is ready, the next step is to let developers know it exists. I'm planning to reach out to the Anthropic team – perhaps they'd be interested in including this SDK in their documentation.
Creating this library has been an interesting journey, full of challenges but also rewarding insights. I hope it will make working with Anthropic's Claude AI easier for .NET developers.
I'm excited to see what you'll build with this library. Whether you're an AI enthusiast, a seasoned developer, or just getting started with integrating AI into your applications, I hope this tool makes your journey a little smoother.
Give it a try and let me know what you think. Your feedback and real-world use cases will be invaluable as we continue to improve and expand this library.
Happy coding! 🚀
Tolga.
GitHub Repository: Link to the .NET Library for Anthropic Claude repository
Hey folks! I wanted to share a project I put together for the Build with Claude contest in June 2024. Anthropic challenged developers to create something using their API in just two weeks, with a chance to win $10k in API credits.
Mergy is a browser extension that combines and optimizes GitHub repository contents into a single text file. It's designed to work with Claude, an AI assistant. Here's what it does:
This tool helps developers quickly give Claude context about an entire codebase, making it easier to work with AI on programming tasks.
While working on a .NET SDK for Claude, I kept running into a common issue. Whenever you start a new project or use a new library, Claude doesn't know your codebase. Claude Projects lets you upload code for context, but there were a few annoyances:
I decided to create Mergy to solve this problem. The idea was to scan a folder, collect relevant files, filter them based on rules, and create a single optimized file for Claude Projects. With Claude's help, I put together a basic console application in about half a day.
The console app worked, but it wasn't very user-friendly. Users would need to clone a project and download an app just to use it. So, I decided to turn Mergy into a browser extension instead. This would make it easier for people to use, regardless of their operating system.
For the extension's look, I tried to match Claude AI's style. I used Midjourney to create some simple icons for settings, sync, and download, with a bit of tweaking in Photoshop. They're not professional-grade, but they do the job.
One interesting aspect of this project was how much I built with Claude's assistance. Almost all of the code was written with Claude's help. I only had to code manually when I hit Claude's usage limit. It felt a bit like going back to the "old school" way of programming.
I decided to take Mergy a step further by creating a client app. This would allow people to use the knowledge via API instead of just through Claude Projects. And this is where things got really interesting.
Here's the cool part: I used Mergy itself to download knowledge about its own source code, as well as the Betalgo Ranul Anthropic .NET SDK. Then, I asked Claude to create a .NET client app for me based on this knowledge. And you know what? It worked surprisingly well!
This was a real-world test for Mergy, and it held up nicely. It was pretty satisfying to see the tool I built being used to create something new. The fact that Claude could understand the codebase well enough to generate a functional client app was a good indication of the potential of this approach.
I think this was a neat demonstration of Mergy's capabilities. It wasn't just a theoretical tool anymore - I actually needed to use the extension in a real-world scenario, and it delivered. This experience helped validate the concept behind Mergy and showed its practical value in AI-assisted development.
Mergy is now available on GitHub, free and open-source. It's a small project, but it might save you some time when preparing code for Claude Projects or, as I've discovered, for other AI-assisted coding tasks.
This project was an interesting way to explore AI-assisted development. It's far from perfect, but it was a good challenge to work on. If nothing else, it shows how AI tools like Claude can help even in the process of building tools for AI integration.
If you're working with Claude Projects or looking to leverage AI in your development process, give Mergy a try. It might make your workflow a bit smoother. And if you see room for improvement, contributions are always welcome!
Who knows? You might end up using it to build something interesting, just like I did with the client app. The possibilities are pretty exciting.
After getting the main functionality working, I made a quick demo video and wrote this blog post.
Github Mergy Client: betalgo/MergyClient: (github.com)