I have recently started going down the path of using Claude AI to develop tools that I have wanted for literally years. One of the first things I have needed on occasion is to be able to connect to the Unifi API’s and pull data. So begins the spiral into the abyss and the deep dive into things I have never done before. I loaded up Visual Studio Code, attached Github and Claude AI to it and started. The thing that stood out to me first was how easy it was to tell Claude what I wanted and it got to building. The first run was pretty good and it was usable but not entirely good enough. I started with a prompt starting with my goal.

Initial Prompt:

I would like a python app that can be accessed using a web url that connects to a Unifi UDM runing version 10.2.x using the API interfaces and pull the configuration into a table that I can see using the url. I want it to pull the name of the device, clients connected, ports list, firewall policies, groups, wifi networks and any other relevant UDM configuration information. I would like switch statistics, as well as access points and related information. I would like to use this to pull the configuration off of the UDM and view it through the web.

Authentication to the UDM

This prompt built an app, scaffolded the code. and produced an app that worked but I had to put the username and password inline so I asked Claude to add a credential button and put anything required for authentication into it. It was visible all the time and since I didn’t want to type in the creds every time I asked it to save it. It ran through and then created an configuration that saved the settings to the site. It took the initiative and also built code to encrypt the credentials at rest.

Analyzer

The original prompt generated an App that pulled the configuration, but what to do with it sparked some ideas. I wanted it to look at the config and tell me if I was using best practices and if there was anything I needed to be aware of so it could be remediated. I sent another prompt asking Claude to build it based on Unifi’s best practices and pointed it to the documentation that supported it. Claude started work on it and produced something that is functional but over time I will refine it as new API endpoints are exposed and put in my best practices into the scan.

Config Lookup

This what was built with the first prompt, I refined the data by telling Claude to sort by Name, change the IP address to sort by the IP value and the same with the MAC Addresses so that by default everything was in alphabetical order on load by Name and then I could sort as I needed to. This made the config pull work as expected. It also made it easier to lay out things so that I could get value quickly without having to pull the config more than once.

Interfaces

I started getting in the flow and wanted to see if I could ask it to do something that I didn’t think was possible. I asked Claude to create a tab called Interfaces and I wanted it to pull all the Interfaces such as Ports and Virtual Network Ports back. If I could do packet sniffing on the port I wanted it to kick it off and return the PCAP. I also wanted it it allow me to analyze it in AI using a JSON export as well as be able to open the PCAP in wireshark. Claude went to work and built the code to logon to the device using SSH, kicking off a TCP Dump and then created another tab called PCAP viewer that by default gives you a high level analysis. I wanted to push it further, since I knew it could logon and do the packet captures it could do more. I then asked Claude to create a message log viewer on the device, something I don’t do often but when I need it, I need it. Claude started spinning and created a button for live logs and when I click on it while connected to a specific device. The live log opens in another window so you can watch the messages come in in real time. It initially was sequential on the packet dumps, I then told Claude to change the packet scanning to run in parrallel so that I could see both sides of the connection if possible. Claude made the changes and it worked exactly as I expected. I thought that the live log was pretty cool, but with the PCAPs as well it solved a few problems.

Lessons Learned

Like with many things, the first time you do something, you do it wrong out of the gate. I learned the following things that will help me as I start building more tools. These are things to keep in mind that will save you time and produce a better configuration quicker.

  • Know what the end result should be, know what you are looking for and how to pull the information you need to support your app. Understand the process of what you are trying to accomplish, if you can write it down you can ask Claude help to build it. If you don’t know what you want, you’ll get something you don’t want and have to iterate much more to get a workable solution.
  • If you have examples of the API code, that helps a lot. You can feed that into Claude so it doesn’t have to look for it. This is especially helpful in moving faster with API’s that are not well documented which is unfortunately the bulk of most API’s unfortunately. If you have Swagger or other API documentation that can be accessed over the internet, point Claude to that.
  • Github is your friend, create a new repository and during development set it as Private until you have something you would like to release. It helps with versioning, rolling back changes and backing up your code.
  • Test and make changes that improve your workflow. Think of how you would like to use the application and ask Claude for complex changes as well as the simple ones like renaming columns or buttons, what the order of it should be.
  • Test after each change or at least every few. Sometimes changes can break working parts of the code and its better to fix them in the beginning and then adding features later when you get an idea.
  • Refactor your code periodically and before publishing to GitHub, it helps keep your code clean.
  • Publish to Github and mark it as Public if you’d like or keep it Private for your own use.
  • Claude or other AI coding agents are awesome, but have patience. You only have so many tokens to use a day so it may take you a bit before you have a workable application.

The thing I liked the most is that what I would ask a developer for I can have AI do it. My ideas are on my timeline not someone else’s. If I get a wild idea, I can try it without costing resources other than my own. It allows me build useful tools without knowing how to code. This frees up time for developers to code for others that don’t understand how to use the tools, the process, and the expected outcome.

If you want to check out the final v1 product click here.