Subscribe
Share
Share
Embed
A podcast about AI and network operations. How network engineers and network operations can benefit and improve their productivity by using LLMs and associated tools.
Searching for null0
Episode2: Network Engineers and Using AI Development Tools with Ryan Booth
December 3rd, 2024
Length: 38:41 Minutes
Kirk Byers (00:00)
Welcome to this recording, this episode of AI and network operations. I have Ryan Booth, who is an engineering manager at Juniper. He works in AI and ML solutions and we are going to talk today about developer tools and developer practices, processes that you can use to be more productive using AI and LLM.
Ryan's been working on a project over the last few weeks that sounds pretty interesting. We wanted to talk about what he was doing and then we'll segue into discussions about these tools, things I've been doing and see if we can help people improve their productivity with these new LLMs, new AI tools. Ryan, what have you been working on for the last few weeks?
Ryan Booth (00:36)
For a while now, the better part of this year, I've really been digging into taking in really building out solid AI applications or how can we leverage AI inside of applications to make them more fluid or provide that interaction between users or even provide extra value to the application and here recently over the past few months I've really been digging into how do us as software developers integrate AI into our workflows? How do we use it to improve our workflows and how do we use it to improve our software development overall? I've been tackling it both from kind of how would a project manager look into it, but also, how would a software developer actually writing code look into it as well?
Ryan Booth (01:26)
I've been playing around with a bunch of different tools and seeing stuff and I found a number of them…you can get on ChatGPT or Copilot or any of these and you can get it to spit out some relatively good starting points and applications that do stuff. You know, you can very quickly spin up a Flask application, no problem. But I really wanted to test out how far down the rabbit hole this could go. How much can AI handle of a real world software problem? Over the past month or so, a little less than a month, I've really put it to its paces. I've focused on a tool under VS Code called Cline or it used to be called Claude AI.
Kirk Byers (02:10)
Claude Dev.
Ryan Booth (02:11)
I'm sorry, Claude Dev. Thank you.
It's been the tool that I've seen the most hands off exposure to. I don't have to do much with it. I set up a project. I want to solve this problem and build this app that'll help people out in the world in a specific use case, and I want to build the full app. I do not want to write one line of code and I want the Cline to be able to build everything for me.
Kirk Byers (02:38)
So you're inside VS Code here and you have this Cline chat window and you start describing to Cline what you want it to build for you. I assume probably using the tech stack and languages that you want it to create the thing in.
Ryan Booth (02:41)
Yeah and when I started out, I was trying to be as vague as possible or as little detail as possible and then see how much detail I had to go into.
Starting the project off, you know, I was able to get probably about 75 % of the work done for me in the matter of three days at maybe four or five hours a day max. It's starting out with simple stuff like, I want a web-based application that's running inside of containers. It's going to be running fast API for the back end. Don't worry about the front end. We'll do that later.
Going into the details, I want to use async functions to handle any type of long lasting task, task management, Redis for queuing, blah, blah, blah, blah. Breaking it down into details like that, [I] was able to get something set up very quickly with everything I needed.
Kirk Byers (03:52)
A couple of question statements on Cline. My understanding of Cline is that you're wiring into an LLM back end, frequently this is Claude Sonnet. Is that what you were using for the API back end?
Ryan Booth (04:06)
Yeah, to break down what my stack is or settings are within Cline is it's using OpenRouter to handle the connectivity back and forth to various AI models
Kirk Byers (04:18)
That's basically a routing layer to the LLM that lets you plug in different ones depending on which one you want to use.
Ryan Booth (04:23)
Yep, exactly. The first reason you really get into that is you start hitting token limits or when you're going directly to an LLM, you get token limits or you get issues with it. OpenRouter can also have the intelligence to say, “Hey, this is a coding question. Let's go to 3.5 Sonnet. Or this, this is a good question that ChatGPT can handle, or maybe a lower end model can handle it to save you a little money.” So it does good in that.
But yeah, OpenRouter and then I pointed exclusively to Anthropic's Sonnet 3.5 because hands down that's the best coding model out there. I have been getting a lot of feedback that there's some open source models that you can host locally that are pretty popular. So if you want to host locally, use something like Ollama.
Kirk Byers (05:14)
Mm-hmm.
Ryan Booth (05:15)
In Ollama, some of the coding ones out there right now are doing pretty good as well. So those need to, I need to test those a little more, but everything I've done is 3.5 Sonnet.
Kirk Byers (05:24)
So Ollama is the loader, it lets you load a model. Do you know what open source models people were mostly using? Is this Llama 3.2? Is this something else?
Ryan Booth (05:34)
Yeah, it's, Ollama is going to be mostly focused on Llama based models out there. Ollama is probably the most popular one out there. Obviously. Let me see, that's the one I know about the most. It's kind of escaping me right now, what are some of the other better models? I'd probably have to look them up.
Kirk Byers (05:50)
The other one that I hear about but less than Llama is Mistral. I've seen the same thing that you've seen that I heavily prefer Claude Sonnet 3.5 for all my coding practices. I would probably recommend to anybody, if they are getting what they view as not great coding results, I would recommend they figure out a way to try Sonnet 3.5.
It's a nominal cost. Like I pay for Claude.ai and I also pay for Claude's API fees, but that's $40 a month and certainly for me, for the productivity, it is worth way more than $40 a month to pay for those. But I have had really good results with Sonnet and that seems to be the general consensus that I hear from most people is that's Sonnet 3.5. If I look on Reddit and see what people like using Sonnet 3.5 comes out as a frequent recommendation.
Ryan Booth (06:32)
Yeah, absolutely.
Ryan Booth (06:49)
I did look it up so we could have it in the podcast. If you do want to host locally and you either can't afford or you don't want to pay for those models…
Kirk Byers (06:57)
There could be privacy issues if you're working on your internal code base and your org has requirements. You might have an internal API gateway you need to use, or you might have to keep this entirely locally.
Ryan Booth (07:01)
Yeah, that's another good point. The model that I'm seeing that a lot of people are saying is really good as well as an alternative is Deep Seeker Coder v2 or Deep.
Kirk Byers (07:21)
Okay. Is that, and I could be, is that the IBM one? I could be, and we can look this up and put it in the show notes. That's all right. I'll look it up afterwards.
Ryan Booth (07:27)
Good question. I'd have to look that up on exactly who built it. I haven't gone into those details. That's the other one that I'm hearing is really good for local and I do need to test that out.
Kirk Byers (07:41)
Okay, so you have this set up, you have Cline, you have it wired in generally to the Claude Sonnet 3.5 API. You're giving it an abstract description of what you're trying to build. How did you sort of iterate through getting it working, testing it? What was that sort of workflow process like?
Ryan Booth (07:47)
Yeah, so I learned very early on when getting into the coding stuff that you can't overload it with information. You really have to kind of start just like you would a normal project. You have to build from the foundation up. You've got to keep the AI focused on the area you need to work on.
Also, just like with normal standard software development practices, there's some things that you have to build before you build other things. You're not going to jump in and start building the UI first, especially if it uses APIs to get to the data layer. You want to start with the back end, get your APIs nailed down, get your infrastructure set up. Are you running a containerized environment? Are you hosting it just natively?
How are you setting that stuff up? Get those things built first. Then that helps you progress as you build layers up. You can always force it to reference the lower layers for how it should be progressing. Have it start with the APIs. If you're definitely working with third party clients with integrating with other tools, make sure that it builds the clients around those first. Then build the APIs on top of it. Kind of the normal workflow, you would with any project, it's just keeping it handled inside the prompt.
Kirk Byers (09:19)
I've seen this when using my developer workflow as well. I think with anything, just like if you're coding yourself, you need to focus on something specific. I would have specific tasks. One pattern that I can see that's problematic is sometimes it wants to change more things than I want it to change. Sometimes it's overly broad.
You can use GitHub or another nice trick that I like using with Claude is just to basically tell me, show me the changes in a diff format. So I can just see, if you're in the IDE, it'll clearly indicate this, but you can clearly see what changed. You can see, it generated 200 lines, but it only changed seven of them. You can see more clearly what the change that it's proposing is.
Ryan Booth (09:54)
Mm-hmm.
Kirk Byers (10:13)
I definitely have experimented in both directions. Somewhat, this is what you're trying to build, but you could also do front end first. If you were trying to build a user interface first, and then you'd have a pretend back end or even almost use a mockup of the UI and you're sort of saying, “I'm going to work out how to make the back end stuff all work,” but you have to build, break it down into a part of like, here's the parts of my system. Here's what I want. Which one am I going to focus on first? As opposed to trying to boil the ocean.
Ryan Booth (10:43)
Mm-hmm.
Yep. I agree with that. If it does make sense to go from one direction first in words, then there's nothing wrong with that.
Kirk Byers (11:05)
Now in this workflow, what would you see the biggest obstacles, problems that you ran into trying to get things accomplished?
Ryan Booth (11:15)
The very first thing that everybody will run into from day one is the ability to build out multiple files and code across multiple locations and across multiple features is, you run into a token limit. That's what we face everywhere and you run into that very fast. Even with the tools that I'm using, it hits the token limit pretty quick.
What happens when you hit the token limit is, it's kind of like first in first out. Those first instructions, those first rules that you give them, those are the first thing to go out the window. So as you get deeper into a task, it stops remembering, those first things that it did or the first things that you told it “Do not do this…” and it starts doing that. You have to pay attention to your context.
Anthropic has come out with some context management stuff recently that's pretty impressive. Then there's been some packages and some other projects out there that help you manage context. But keeping your context of the project or keeping the context of the files in front of the model at all times is critical.
What a lot of projects are doing is inline documentation where you're doing your notes and everything inline as comments, or even going as some tools are out there, that you actually have context files in every single directory that lay out the context. Then inside your prompt templates, you say every single time you're jumping into a directory or every time you're looking at this file, make sure you're pulling context from this location. That's going to help keep you on track.
Kirk Byers (12:52)
Now, when you talk about the token limits, are you actually hitting here where you've basically run out of how many you can use and you have to switch API? Or are you talking more of, you just have so much stuff in your context that it's basically stopped? It sounds like more of the latter that it's basically stopped remembering things that you said a long time ago.
Ryan Booth (13:12)
Yeah and everything I'm talking about right now is more to the latter. The size of the token and the limit that you get with Sonnet or whatever you're using, that's more to the point we talked about earlier with OpenRouter. But yeah, both of those are kind of the first things you'll run into.
Kirk Byers (13:28)
You started mentioning things that you do to help here, like providing per directory context files. What are some other things you try to do here to help it have the data in front of it that it really needs?
Ryan Booth (13:36)
Yeah. With most of the tools out there that allow you to either code inline with your IDE or it is a chat assistant that does the coding like Cline is, they offer the feature to have like a context statement or a prompt statement that is generalized and every single question or query you ask is included in the prompt.
It's kind of like those rules that you establish: Do I want trailing slashes or no trailing slashes in my API endpoints? Or are we doing strict typing here or are we using this package only? Things like that, that you would define in your project. Make sure those things get into those statements because it doesn't recognize all the time that maybe you're doing this and it just goes off whatever it finds and it could go down the wrong path that you don't want it to. Then you end up wasting time backtracking.
Kirk Byers (14:39)
Do you specify this in a special file or special files in Cline? How do you stuff this information in?
Ryan Booth (14:47)
The easiest way to do it is inside the settings of Cline. You open up the settings and you'll see about halfway down the page there's a text box where you basically enter your prompt that you want every single time. That's how you do it.
Kirk Byers (15:01)
I have a slightly different workflow, but I think it's interesting to sort of provide a file and I have similar issues. My general workflow is I'm still using Claude AI and I have what Claude AI terms Projects and Projects are a way in Claude that you can provide additional information that [are], sort of, part of your chat. I can upload files, input text.
Ryan Booth (15:23)
Mm-hmm.
Kirk Byers (15:30)
A lot of times what I do is I have a Git repository and then I basically load into the Project a set of files. Now, one thing that's annoying about the Claude Projects is there's no, at least if you're not an enterprise user of Claude, there's no easy way to sync via a Git repository. I keep hoping that they just add a sync to Git for the Project so that I could automatically update all the files. But right now I basically have to go and sync my Git repository, but then go and add those manually up into the Claude Project. But I usually don't need all the files because I'm usually working on a specific area, but then it'll have those in the Project. If for some reason, I think it's not looking at the file, I would just in the chat window say, “Hey, we're working on this, whatever file this main.py or whatever we're working on with the name of that file” and make sure it's aware.
Then I would probably just either create a file that was a prompt or just put into the chat window saying what I want to emphasize if I think it's losing... I probably would put some sort of file in the project that sort of emphasizes style guides. As far as, “Hey, I want you to do these types of things and keep referring to that.” If I thought it was missing that.
Ryan Booth (16:46)
Okay. Yep.
It's funny, this is an area of AI, really getting into what we're talking about here with context, it really just started surfacing and then becoming mainstream issues this year. Even it's only really been getting brought up over the past like six to eight months. What we're seeing out there as solutions, like what you talked about or what I'm talking about or some of these third party packages and stuff that are coming out. You know, this is all stuff that's been created over the past few months. So it's a very bleeding edge and there's a lot of areas that need to be figured out and tuned up.
Kirk Byers (17:30)
I also have seen various utilities where you can sort of concatenate a whole bunch of files and just sort of stuff them into the prompt. There's various utilities that I've seen that allow you to do that.
Now, obviously you're going to be eating up your input tokens and you're going to be eating up your API tokens. So you have to make trade-offs on how many files do I want to send? Sometimes you could say, if you send too much information, you're probably going to get worse answers because you're just overloading what it sort of knows about. So you might be getting worse answers as well.
Ryan Booth (17:43)
Yep. Mm-hmm.
Ryan Booth (18:12)
You're kind of hitting in on the very next issue that I usually faced that has to be corrected pretty quickly. The size of your files becomes very critical fast. If it has to refactor a file that's 300 plus lines, there's a pretty good chance it's going to struggle with that or it's going to start beating down the wrong path with certain stuff. As you're doing development, be very keen on how large your files are. I usually step back with Cline and once it breaks about 150 lines of code, I have it start breaking it down into more modules. So that's a little more excessive than we're used to as engineers. I mean, sometimes you walk in and see two, 3000 lines of code which is kind of cringy, there's no way that that can work within a development environment of an AI right now until we can get some better size memory and stuff.
Kirk Byers (19:07)
How did you find the results? When you got all the way through this process, were you happy with the results? How did things sort of end up, where you took this to its end state?
Ryan Booth (19:18)
I still haven't hit the end state. [The] end state is going to be when I publish the tool and start getting user feedback. but I have not found anything yet right now. I'm just doing cleanup, building in features like user feedback, and then tightening up testing and stuff like that. I honestly have not found anything that I've had to jump in and write the code for. We've had some pretty intense troubleshooting sessions here or there…
Kirk Byers (19:26)
Mm-hmm.
Ryan Booth (19:45)
..when it's gone down some bad paths. There's been a couple branches that I've had to back out of and destroy because it just did a shit job of it. But, you know, we got through everything and I've never had to touch a line.
Kirk Byers (19:55)
I think there's a couple points here. One, so I always want to be tracking this in Git. I find it helpful. And you can say where you found this. But I actually found it helpful to have a very small granularity of basically anything I get that's working. I basically just save it. Because I want these checkpoints that I can roll back to.
Ryan Booth (20:02)
Mm-hmm.
Kirk Byers (20:19)
I want these checkpoints that I can diff to real easily if I'm confused about what the AI changed. You have these checkpoints in Git. Now, when you got into some of these real rat holes with debugging, what kind of techniques did you have to try to employ there?
Ryan Booth (20:38)
At first, it's usually helping it understand key points. Just like network automation, it's not the stuff that you would think in networking that it needs to figure out. It's the stupid, simple stuff, like why isn't it getting this SNMP community added? That's a single one-line command in the CLI.
But in software dev with network automation, sometimes that's a two, three day troubleshooting process. It's the same thing here. You have to help it understand what's going on. You have to help dig in with what has it built already? How is it doing it? What are the best practices you should be using? I found that it's good to be able to question the AI and respond back. What you're doing, is that actually logical? Should you be doing that?
Why aren't we doing this? For the most part, it'll do good to step back and understand, so that's a good way to do it. When you really get thick into it, it's probably because it's not pulling in the full context of everything it needs to know. It's like we are when troubleshooting. It doesn't know everything that it should know, so you have got to help it get there.
The past couple ones over the past few weeks that I've really gotten into, one of them was straight up my fault in misrepresenting the logs. I was pulling something out of the log. I was trying to force it to make changes in the front end when logically the bug and the root cause was in the back end. As it wanted to try to navigate towards the back end, I was getting mad at it for doing that. Then, of course, I had to finally find where the issue was over multiple print statements, having it throw them in there to get there. Other ones were, it just didn't have the full context across front end, back end, and the proxy in the middle to marry all those up. That one right there was basically it got very confused on how to call the API URL.
Kirk Byers (22:20)
Mm-hmm.
Ryan Booth (22:30)
So what should it use? This is local devs, so should it use localhost? Should it use the container name? Because we're developing inside containers. How does it connect to it? And front end on the browser client, it's going to be hitting localhost. It has to have a reachable URL. But the front-end middleware that lives in the front-end container can use the app or the container name because it's attached to the Docker network. It was getting very confused on how to do that…
Kirk Byers (22:59)
Mm-hmm.
Ryan Booth (22:59)
…and it wasn't understanding it. I had to fully step back and say, when you're running in the browser, you have to use this URL. When you're running from middleware, you have to use this URL. And then standardizing that stuff as well. If you can get it done quickly in the beginning, you save a lot of headaches. But if you have to refactor and retouch it later, you could possibly run into pain points.
Kirk Byers (23:22)
In this application, it sounds like you have a web front end in it. How did the AI do on the web front end development?
Ryan Booth (23:26)
Yep. Yes.
It did really well. In the same sense as software development, the back end went up relatively fast. The framework of the front end went up relatively fast, but in getting all the features and all the pages and all the forms and all that stuff put into place, I think I spent about two times the amount of time on the front end that I did the back end.
Kirk Byers (23:53)
I've also been experimenting with some front end development with AI and I am by no means a front-end person. I am very much a Python person. So I'd be much more comfortable in the back end work, but there's a few techniques that I found really interesting. One, for the design, one pattern that I found interesting, useful is you can look at a go find…
Ryan Booth (24:02)
Mm-hmm.
Kirk Byers (24:21)
…for whatever you're building, try to find some models, some representations that are somewhat similar to what you like. At one point I was just building, I'm going to make a fake landing page for a fictional company. I wanted to see, could I do this? What would it be like? I went and found six landing pages that I like. Then I took one of them and I took an image of it.
Ryan Booth (24:49)
Mm-hmm.
Kirk Byers (24:49)
I asked ChatGPT to make a landing page that's somewhat like this. It's in no way a copy of it. It's not like a mimic. A lot of these landing pages are somewhat similar in many regards. Like you'll have some sort of navigation. It's frequently navigation that's at the top. You'll have some sort of section at the top, and then you'll have this big company logo or what they call the hero section in some way where you're selling your product or widget and things like that. But the cool thing is you could take an image of something and then ask it to generate the HTML, CSS, JavaScript, and ask it to generate the Flask thing to run it. Then it would build the Flask Python app to run it, build me the HTML and the CSS. Then I could just roll and start…
Ryan Booth (25:16)
Mm-hmm.
Kirk Byers (25:40)
….testing it and get this, there was no back end there. There was nothing there. If I clicked on any of the links, there was nowhere for it to go, but I could see the UI and that I was building the UI components and another nice debugging tool.
Then this is more when I get into problems. Level one of me getting into problems would be, the CSS is not working right. Okay. No surprise. That's CSS, you know, so I would basically describe it and take a picture of what it looked like, this pulldown is not working. The hover effect is not working here. This is not aligning. Then I'd include a screenshot and I'd feed that into Claude and Claude would have those files there because I'm using the Claude Projects. And then it would basically say, Here's the fix. Here's what we need to do. It would make recommended changes, mostly to the CSS, but potentially to the HTML as well if it thought it needed to do that.
Now, sometimes that doesn't work. This was more so, [when I] started doing this on my production website for my business, where my CSS is an ugly mess of a huge CSS file. It [AI] just doesn't know how to fix some of these things. Because there's overlapping classes or things that conflict with it. It would recommend a change and I'd tell it, this is not working. But eventually I'd have to say, I'd go into dev tools in Chrome, which is sort of a way you can see what's going on as you click on objects in the HTML and what's happening at the CSS and then literally I could sort of drill where I thought I needed to drill down into, and then take a screenshot of that and say, okay, here's what it looks like in dev tools and this is sort of debugging where I'm trying to help the AI to say, here's what I see when we're looking at this to try to give it more clues on what's the conflict that it's not working out that is more of like…
Ryan Booth (27:42)
Yep. When I'm troubleshooting, I make sure that if I'm saying this is happening, I provide reference logs. copy and paste those in or whatever to, make sure it's interpreting those fine. I know a few tools have it out there, specifically in Cline. I'm going to have to ask them to pay me for some sponsorship or something here.
Kirk Byers (28:08)
Hehe.
Ryan Booth (28:09)
Anthropic released the computer use feature, which if you're not familiar, basically allows it to take control of your computer and run through stuff. What Cline did, what they released is when it's working through building the code, once it gets to a validation step, it'll actually pull up a browser and click to your UI.
It actually attaches to a terminal. If you're having issues with a Docker run command or with a certain container that blows up on launch, it attaches itself to a shell and actually runs the stuff and watches the output. It really is built in line to where it'll do all that stuff that you said you have to do manually.
Kirk Byers (28:51)
I think this is sort of the evolution too of where the QA testing can be much more driven by AI that right now I'm still doing a lot of the QA testing and validation myself. But I think the direction we're going towards is clearly that more and more of this is going to be in some way accomplished…
Ryan Booth (29:10)
Mm-hmm.
Kirk Byers (29:20)
by AI and whether that's computer use and you doing it once and it's sort of seeing what you're doing every time, or obviously there's going to be products and services that are going to be doing this and helping this because that is a very time consuming aspect. For my production website, you know, I'm having to go through, okay, does this work for all these different browser sizes and you know, iPads, iPhones in this mode and that mode and you sort of need to look and see. If I could have that be automated, that would be a huge time sink and it would give me a lot higher confidence that everything was working properly whenever I made changes.
Ryan Booth (30:01)
Yeah and that's getting into kind of a completely different workflow, getting more into your CI-CD pipeline for your various teams and setting up the tools. I think that's where you're getting into utilizing tools like LangChain or LlamaIndex, CrewAI, those types of tools to really chain together your pipeline.
You're running back-end tests and interpreting logs. You're having a UI get clicked through by an AI agent that can support it. I think we're going to see some massive improvements in our testing and our CI-CD pipelines over the next couple of years.
Kirk Byers (30:40)
Now we've been talking about development in general quite a bit. Is there anything else specifically that we want to talk about related more exactly to network automation, how things work in network automation? I think a lot of these things apply regardless, but I've also had really good results with Ansible playbooks. I've had really good results with just straight Python network automation code. Are there other topics that we want to talk about there?
Ryan Booth (31:10)
For me, it's one of those, I still know it's network automation is managing software at the end of the day. You're writing code that you have to rely on, that you have to test, that you have to validate. All the standard practices fall into place that software developers follow. I think everything we're talking about here is applicable to network automation as well.
Kirk Byers (31:33)
You'd want to have, make sure you have good practices. I think these are general engineering software development. You want to have tests of some form. I put first level tests in the Python tool chain of some form of linting, which is doing basic code quality checks and then some sort of more extensive testing. Obviously the amount of testing depends on production, what are the production requirements of this?
Once again, I would be having AI write this testing code for me and having it roll it out having good software practices.
Now in Ansible, I definitely have pretty good results with Ansible. One thing I find very useful with Ansible is Ansible is very particular about syntax.
Ryan Booth (32:26)
Mm-hmm.
Kirk Byers (32:26)
It's very easy for me to get, and I've worked with Ansible a lot for over a decade now. I'm pretty good with Ansible, but when I'm writing it myself, I sort of have to go task by task and write one task, run it, write the next task, like the next task, run it.
When I'm developing it myself, if I don't do that, I pretty quickly break the code. Just that I forget, I didn't use the right quote curly brace notation here to have it be understood properly, so it's breaking here. Whereas when I'm using AI, it actually lets me write more steps in one go and gets it right quicker. I've actually found it makes my Ansible development quite a bit quicker just because of the tediousness of properly writing Ansible. I am not a shell…
Ryan Booth (33:11)
Mm-hmm.
Kirk Byers (33:23)
…scripter by any means, but I sort of find there to be similarities with shell scripting. Shell scripting can be so particular on syntax that I usually would probably punt anything complex out to Python just because I could get it done quicker. Now I would just have AI write me the shell script and it can get those syntax particulars right. It has this quicker cycle than if I was doing it by hand, which would be slow and tedious.
Ryan Booth (33:53)
Yep, everything you said there is the same thing that I've been experiencing as well. I get it to chew through stuff that I can do way faster, but it doesn't just stop there. I'm horrible at front-end code as well, write this front end code for me. It goes way beyond what I can do there and those various tools that you need it to do that you're not good at. It definitely picks those up and that's where it shines for you as long as you can keep it on track.
I definitely agree with you. I've learned that you have to have it validate or you have to have test coverage every step of the way that validates it. I like to break down my Git PRs based on features or what task am I focusing on.
It's the same thing for AI. The task that we're focused on is a separate task session for the AI. I don't go outside of that and I don't do additional testing. Standard rule set for software development. Then I specifically, as I've learned is once we get close to a final stage or if when I'm building out this feature, once I get the APIs built, I have the tool actually go out and do the actual calls, make this API call and make sure you're getting the right output and it validates it and it runs it through the shell and it does it.
Then we can put the test into place and then we can move on to the next step and add it to the front end. I found going through that and validating every step of the way saves you a lot more time than getting to the end state and then having to troubleshoot the full stack or multiple steps along the way and you know it simplifies it for the AI as well.
Kirk Byers (35:32)
Now we've mostly been focusing on specific tools. Cline in your case and me using Claude AI with Projects and Artifacts. Now this is a very rapidly changing world. There are a lot of tools out there. The tools that we're using today, there is a very good chance that they will not be the tools that we use six months from now.
What are some other tools that you find interesting that you find are at least potentially worth exploring or being aware of?
Ryan Booth (36:07)
Yeah, I think the first thing to start this with is, know, what level of hands-off are you looking at? The tools like Cline that I'm talking about, it's almost 100 % hands-off. You can edit side-by-side with it, but it does all the stuff for you. When you get into GitHub Copilot or similar tools out there to it, it's more like an inline style. Both you and the AI are working on the same lines of code as you move through it and it's helping you progress through it.
Kirk Byers (36:39)
So it's more like a pair programming kind of paradigm almost.
Ryan Booth (36:43)
Exactly. Then you get deeper into, and it might not even be applicable for what we're talking about, but you get into stuff that are more frameworks for AI working through processing and that's where you get into like AI agents or stuff like LangChain or LlamaIndex, where you can chain AIs together to do tasks.
Kirk Byers (37:02)
This is more like you're building a program that's using AI as a part of it where you're making API calls and using some of these libraries to help you. Now, once again, you could have your dev tools that are also AI based help you create these things, but you're using AI at multiple levels here.
Ryan Booth (37:12)
Exactly. If you're not familiar with LlamaIndex or LangChain, I like to consider those the Ansible or Ansible of AI, essentially. That's what they handle. But so far I like hands-on developments.
Kirk Byers (37:39)
Real quick, both Lang Chain and LlamaIndex are Python libraries that are going to make it easier for you to write these AI based applications generally.
Ryan Booth (37:49)
Exactly. They allow you to chain together multiple AI agents that have their specific task at hand to do, and you work through a specific task and have them do it all for you programmatically.
Kirk Byers (38:03)
Alright, so I think we're going to wrap it up here. Is there anything you want to sort of conclude with or anything you want to mention sort of at the end here?
Ryan Booth (38:10)
We covered a lot of stuff. This is really a space that's moving fast. It's very exciting. There's a lot of things you can do with this. It also can be very intimidating on where and how to dig into it. The best thing you can do is just start playing, find something and just start digging and playing with it. Find stuff that interests you and go for it. It's a wild space right now. There's a lot of fun to be had, but it's definitely one of those to really know what you're doing. You got to get your hands on it just like anything else.