An IBM Bob Early Adopter Shares Tips and Tricks
Rael Rodning, principal intelligent operations architect at Evolving Solutions, joins Andy Wig on IT Social Hour to share guidance on token efficiency, context management, security and more
Listen to the audio-only version.
The following transcript was edited for clarity:
Andy:
Hello everyone. Thanks for tuning into IT Social Hour. I’m Andy Wig, senior editor at TechChannel. And today I have with us Rael Rodning. She is principal intelligent operations architect at Evolving Solutions and she has had a chance to play around with IBM Bob for some time now and she is going to tell us about that today. So Rael, thanks for joining us.
Rael:
I am super glad to be here, Andrew. Thank you for having me.
Andy:
Yeah, it’s my pleasure. Let’s just start off, maybe why don’t you just tell us what you do at Evolving Solutions?
Rael:
At Evolving Solutions, I’m really focused on helping organizations apply AI to their IT operations. And believe it or not, applying AI to IT operations is much larger scope than you might think. It’s a combination of helping them understand their data and it helps understand what their observability maturity is and then also where they’re at in terms of automation, and then helping them turn all of that information into a process where they evaluate the results they get and then start the cycle back over again and improve from there.
Andy:
Sounds real simple. Not much to that job. No, it sounds like you’re really well positioned for this, I don’t know, you call it transformation we’re going through right now and characterized by one thing that people have probably been hearing about and maybe you can explain what it is, but IBM Bob. Today happens to be the GA day for the premium IBM i edition for IBM Bob. So that’s kind of neat, but it’s been out for a few months now as a kind of platform-agnostic tool. But yeah, maybe you can explain what it is better than me. So I’ll let you go for it.
Rael:
IBM Bob was built off of a fork of VS Code. So anybody who’s a developer and works with an IDE probably has heard of VS Code. And what IBM did was took it and included a lot of the smarts that they had in watson AI. They built it into IBM Bob. So IBM Bob is an AI-enhanced or -enabled IDE for developers. They’ve done some pretty neat things with it though that aren’t typically available even in other IDEs in a very unique way. And so they’ve really positioned it well to be able to put in place corporate security alongside development in the use of AI in doing coding. That’s really at its core what it is.
Andy:
Okay. And how long have you been able… I take it you probably got kind of an early release of Bob to experiment with?
Rael:
Well, I tried. Actually, I spent a couple months trying to get early release and actually I got approval the day it was GA, but I dug in very, very quickly and spent quite a bit of time with IBM Bob. And then I was privileged to attend one of the very first IBM Bobathons held by IBM in New York. I’m completely blown away by the product in a way that I’ve used a lot of different IDEs and I’m absolutely blown away by IBM Bob.
Andy:
Okay. Well, what is it about it? What’s blowing you away?
Rael:
I think the first thing I did, so I led an automation team before I joined. And so one of the things I did is just try to have it recreate some of the code that I had written at my prior job with natural language. And I could not believe how incredibly close it was to solutions and actually in many ways better. There were cleaner and more refined solutions that would just run more effectively. And to me, that was just mind blowing that we were able to very quickly, in a matter of a few minutes, something that took four, six, eight, 10 hours to write was 10 to 15 minutes with a well-structured prompt. I mean, so I’m going to be very candid. That was after I learned how to do a well-structured prompt. So that was—the very first thing I had to learn to do was figure out how to prompt it, which seems like, oh, I can just use natural language.
Yes and. It’s not quite that simple.
Andy:
Okay. So what have you learned about prompting then since then? What are some of the top prompting best practices?
Rael:
From a prompting perspective, my preferred way to… I would rather work with Bob in a way that’s called spec coding, which is fundamentally writing the business requirements and some technical constraints and technical requirements into a spec document. And the reason for that is it’s self-documenting and it really makes you think through the architecture, the connectivity, the networking that you have to have in place, as opposed to natural language. And it’s far more efficient with your Bobcoins, which I think people are hearing about tokenomics and the spend and changes in the way that pricing is happening across a lot of the AI-assisted coding. And so being really efficient with your prompts means you’re also really efficient with your token spend. So that was probably, that’s my favorite. With prompting, the more clear and exact you can be, the better results you’re going to get and the less refinement you’re going to have to do.
And this goes back to being efficient with your tokens. And it’s kind of like your paycheck. If you’ve got a budget, you really want to spend it really wisely. So learning to prompt really well is key to being efficient with the way that you spend your tokens to get what you want. So what I’m going to call sloppy prompting is going to result in a lot of wasteful token spend. And if you’re paying personally, that’s not that much fun.
Andy:
Yeah. I’ve been hearing about companies in some places encouraging their employees to use as much AI as possible. And then all of a sudden I think I might be butchering the timeline a little bit, but I think at least Claude said, well, now we’re going to go, it’s more something closer to the real cost, right? Instead of being subsidized and then all of a sudden people are kind of being like, “Oh wait, we have to start thinking about this. We can’t just go willy nilly all over the place and start really being careful about our prompts.” And I guess that gets into the context thing, right? Where you’re talking about documentation and the importance of context.
Rael:
Yes. And so I’ll share with you a story. When I first got IBM Bob, my typical way of developing, and this is just a personal preference, not everybody does this, is I have a folder that is called code and I clone all of my repos into that folder. And so I know that’s where my code is. I have it backed up. That way if my PC crashes, I can go back and get my things. And the rest of my stuff I don’t care about, but I back up my code. Even though it goes to repositories, I still back up my code folder because I do develop locally and do a lot of testing. One of the very first things that I learned, and fortunately I was doing this on somebody else’s dime, not my company’s. I was given access to kind of a wide open, a greenfield would be the way that I would put it initially.
And I opened and I had about 30 repositories in my code folder and that’s how I always worked. And then I just went to the folder. The reason I did that was frequently I’ll be like, “Oh, I did something like this in this other project. I’m going to go grab that and I’m going to pull it into this new project.” And so it’s just super easy to move between and borrow from things that I’ve done already. And so I didn’t think much of it. Bob, both a beauty and a curse wants to be very context aware. And so what I didn’t realize was that when I put a prompt in, it asked if it could read the code folder and all the sub folders. I was like, “Yeah, no problem.” It was pretty interesting. One of the things I love about Bob is you can actually watch your token spend in the upper facing my screen, it’s in the upper right corner.
And so you can watch your token spend live. It just goes up and down. And by the way, as it does tasking, it takes away tokens, but then if it’s more efficient, it’ll add them back. And all of a sudden I was watching and I burned through in about four hours 200,000 tokens-ish? A lot. Let’s put it that way. So the equivalent of 40 Bob coins. And I was like, “Uh-oh.” And what I had realized is I burned through the majority of those, having it go through and learn and read all of these repos that weren’t even related to what I was asking it to do. And so again, this goes back to tokenomics and learning to be efficient.
So what I’ve learned with Bob is you only open the things you want it to look at. Or in my case, I still work with the code folder, but now I’m very specific when I prompt. If I want it to look at another project, I actually specify in my prompt, “This is where I’m working and I want you to put stuff that you create, but I want you to reference stuff in this folder or sub-folder. And that way I’m very efficient again with my token use.” So that’s one of the tricks that I’ve learned in prompting.
Andy:
Okay. Because that way you keep it from trying to make connections that you don’t need it to make and that’s maybe where hallucinations can happen.
Rael:
Exactly. That’s a great point. Yes. And it’ll draw inferences that, exactly, you don’t want. So basically I gave it a bunch of bad data. Now in my case, it didn’t do anything bad. It just was like burned through a bunch of tokens that I could have saved for something else. But yes, that is one of the risks. So that’s a really intuitive call out is that’s the other risk is if you don’t keep your context very tightly grained, you’re exactly going to cause that. And you have a very high potential that it’s going to try to associate stuff that doesn’t go together at all.
Andy:
Okay. As I was preparing for this podcast, I was looking for other stuff you’ve done in the past and I found a recent webinar you did with evolving solutions called Date Claude Marry Bob. I love that title. And I was wondering if you could just explain to me what you meant by that.
Rael:
The story behind that is it started as a bit of a joke. So I had already been playing with IBM Bob and I went to the Bobathon that I shared with you and I came back raving about Bob to Michael Downs, our CTO, and also our marketing director, Kelly. And I was sitting and doing some work and happened to be, I think I was talking to Michael and Kelly walked by, and we started talking about IBM Bob. And I made a joke that I said, “Well, I called my husband after I was done with my IBM Bobathon and said, Honey, we’re getting a divorce. I’m marrying Bob. And so it became kind of an internal joke about dating Claude and marrying Bob. But what I mean by that is Claude’s fantastic. There are a lot of things that are fantastic about Claude.
A lot of what it doesn’t provide though, and I think one… I need to do this—I need to do a side by side for the exact same prompts and see if I get how close the code is. But Bob doesn’t easily allow you to layer in your corporate security standards the way that Bob does. And Evolving Solutions has come up with a prescribed way that we are giving to our customers when they engage with us on Bob that is very prescriptive and assures that every single repository and every single code base always has corporate security standards used. And Bob, they give you some guidance on the Bob side on how to do it, but it’s not very prescriptive if that makes sense. It’s like, well, this is how you could do it. We’ve come up with an approach that is very prescriptive that says you do this, you do this, here’s how you put it in place, here’s the controls you put around it, and laid it out step by step.
And I think that is probably the biggest reason I would say Date Claude, great to play with, much harder to control. The other thing that Bob has in place, especially for enterprises is the ability for enterprises to control token spend very easily. And you can allocate the tokens to different users and you can even pool them. So you can buy a large pool of tokens and you can either just say everybody has access and Rail can use 500 of whatever the pool is and I’ll just do what I need to do and other people can only use 20. And so you don’t have to necessarily give 10 to Andrew every month and 10 to Kelly and 10 to Rail and 10 to Michael. But you can do that if you want to. If you want to maybe have an administrative user or a marketing person use Bob ,because Bob can actually do some things.
And this is what I think is really cool. They can actually help with marketing if they wanted to. It can help write documents. It can do a lot of the things that Claude can do. And so maybe you only want to give the marketing team the ability to burn through 10 tokens a month, but you want your developers who are delivering customer stuff to be able to do 100 a month so you can divvy that up. So those are the reasons that I say date Claude, get your experience, figure out how do you like AI-assisted coding. But when you’re going to make a commitment to an IDE, mary Bob.
I guess the last thing I’ll say is Bob does two things. If you’ve got developers that don’t like mice, and I do mean this kind of mice, because I know developers. I had people that I worked with that just said, I want to do command line. Bob also has complete command line that does the exact same thing. So I think that’s fantastic. So I feel like they’ve really hit kind of the key sticking points for people using IDEs, security and personal preference for how do you develop?
Andy:
Yeah. I didn’t realize. I mean, I guess it makes sense. It’s got all these large language models in it that it would make sense that you can use craft marketing copy or something like that. I didn’t even thought of that, but of course. Yeah.
Rael:
Well that reminded me. Bob actually uses four different models. One is Anthropic, one is watsonX. One is Granite. And I forget what the other one is, but one of the other things Bob does is when you give it something to do, based on the particular task, it will pick the lowest cost model. So it will deliberately try to find the lowest cost model. So maybe if you’re doing something in marketing that isn’t super math or coding intensive, it might pick Granite because Granite costs less to use per query than it does if you’re going to use the Anthropic model.
Andy:
Okay. Have you found any kind of favorite use cases for Bob so far? What do you think is going to be? Where are people going to get the most value do you think out of this?
Rael:
I think it’s going to depend on the type of developer you are, to be very candid. I think for folks that are doing IBM i development and IBM Z and I’m going to just completely own up. I don’t know those languages or anything about them. However, one of the things that they’re doing with these packages is apparently there’s some very standard workflows that you need to go through. And if you don’t purchase a premium package, you can still use IBM Bob to do them, but you have to burn your own coins to build out the correct series of workflows and discover them yourself. And so built into that’s really the premium packages are a very prescriptive way of approaching modernizing your IBMi and your Z when they come out with it.
The Z code that apparently is very important to that work. And we do have somebody on our team, Brandon Rau, who does IBM i and could speak to that. I can’t with any authority speak to the quality of that kind of code. But to me, that’s a huge advantage because I think about things like the automation that I’ve done. And if there were pre-prescribed workflows that I didn’t have to discover kind of the entire process, I think about the efficiency of the team that I was working with would be tremendously improved in terms of updating and modernizing code. So to me, that’s pretty cool.
But I think it’s going to vary. Python people are going to find their own focus use cases. And recently I just used Bob. We’re doing some Bobathons for our internal team. And I shamelessly borrowed Bob to write IBM i and some security demo, basically think of it as demo code in order to use in the Bobathon because I know enough networking to write some code and actually understand that.
I’m going to have to send my IBMI stuff to our internal expert and go, okay, here’s what I’m trying to do with it. Did it get it right? And I’m going to have to do that with a security code. The networking, I can read it and go, yeah, that’s going to work fine. I understand it. And some of the other stuff. But again, it depends what you’re doing, I think, and what your specialty is. So it’s going to vary. I don’t have a need answer.
Andy:
Okay. And you mentioned kind of the challenge of validating the outputs of Bob as a non IBM i person. I imagine that’s going to be the case in a lot of times where a technologist translated COBOL to Java and maybe they don’t know one of those languages. So yeah, inherently people are going to maybe be validating code or tasked with validating code that they don’t know. How do we handle that?
Rael:
Candidly, I shouldn’t be writing IBM code even with Bob. Now for the purposes I’m doing, I’m okay with it and I’m owning up to it and I’m going to get some experts. So I have kind of two comments. If you don’t know the language that you’re coding in or that you’re translating from, I think using an agentic AI is a horrible thing to do. I read something the other day, you can never blame the machine or the program. It’s always the human that’s accountable. So I would not want to be accountable for code that I couldn’t validate and vet. And other people may feel differently, but from my perspective, that’s just … I mean, you might as well just put your social security number and your passwords out in the internet and say do what you will. Because it’s ultimately, especially if you work for an organization, I mean, if you’re doing it for your own private, your home or vibe coding and you’re using it personally, that’s a different situation.
But if you’re doing it professionally, you’re potentially exposing yourself in my opinion to professional risk and you’re potentially exposing your company. Even though Bob does a really good job. You can do security scans. It’ll give you CVEs and CSS rankings. It’ll tell you all of the stuff that it finds wrong, but that still doesn’t guarantee that you haven’t missed something or you don’t know because you just don’t know what you don’t know. So personally, if you don’t know it, you shouldn’t write it. And yes, there are some exceptions. I’m kind of okay with what I did because it’s internal and it’s really for demonstration purposes, but generally not a great practice. I just think it’s not a good practice.
Andy:
Okay. So yeah, we’re not talking about vibe coding here. We’re talking about professionals being professional and knowing what they’re doing. So are there any areas where, speaking of areas, places where you need to be careful, any certain tasks where maybe Bob could do it theoretically, but you might maybe keep Bob away from these tasks just because either it’s not worth it or maybe it’s too dangerous or anything like that where people need to be extra careful, I guess, aside from security?
Rael:
No. I think my biggest caution is just don’t do what you can’t validate. And sometimes you can’t get away from that. So I’m going to give you a use case that I actually think is incredibly valid for Bob and very helpful. And I think this is something that we’re seeing with our customers. Bob does a tremendous job of documenting undocumented code. So let’s say you work at a company and you’re in a situation where the guy who wrote the RPG code has given you a month before he leaves. That’s a perfect case to pull in IBM Bob while you still have the guy and go, Bob, point at this code base and I want you to give me … and Bob does a great job of this. It’ll lay out a full architecture. It will give you complete documentation. It’ll do security. So it’ll give you all of that stuff—in a pinch, if you don’t have anything better, like maybe the person won the lottery and ran off to Bora Bora because that’s where they want to live and there’s nobody else that can tell you, that’s better than nothing, but it’s a lot riskier.
But I think that’s a great use case for Bob is taking that legacy code that somebody wrote 30 or 40 years ago that still works, it’s really stable, but you know you’re going to have to upgrade because eventually it’s going to tip over. That’s a great case to go in and document it, especially while you have those legacy employees and get them to go, “Oh yeah, that’s actually what that does.” So Bob does that really well. You still need to validate it.
Andy:
Yeah. I’ve had people tell me that it’s really the documentation that they’ve found most helpful beyond the translation. They’re saying like, yeah, you can teach people the code, but it’s like the documentation. I’m not a coder, so I’m curious asking you how big of a pain is documentation, the process of creating it.
Rael:
That’s a great question. So again, I think it depends on the kind of developer you are. So I’m going to give you two answers. The way I develop code, and I’m a self-taught developer. My background, I have a real estate apraisal degree, so a BS in real estate. And then I have an MBA with a corporate finance emphasis. So people are probably going, “What are you doing in this field?” But I’ve been coding since Apple Basic just for fun because I liked it, and ultimately figured out that that’s truly where my personal passion was. And even more so being very passionate about things that are kind of leading edge and fresh and new and how do you simplify and make things easier. So that’s how I got into this. I lost my train of thought. I apologize. What was I saying?
Andy:
You were talking about how you got into coding and you were self-taught and—
Rael:
Oh yeah, but there was a point. You’d asked me a question. What was it?
Andy:
I was asking about documentation and how much of a pain it is.
Rael:
So because I’m self-taught and—I had to write like a paper and I had to write an outline of my code in plain language. I had to go, okay, I want to do … I always thought about it. If I was doing this manually, what would I do? I would go and I would get that piece of paper and I would look at this field and I would get this number and then I would take that number and I’d move over here and I’d put it here. And then after I put it there, then I’d open up this file and I’d search for the number. So I’d write this outline. So for me, it’s just a natural part of my development because I was self-taught. So what I would do is write this big long thing and then I would go search in the Python book or the Apple Basic book or whatever C or C++ and I’d go, okay, how do I do this? And then I would write that chunk of code.
My experience in leading a team of people who did development, they hated document, and they didn’t code that way. In their mind, they were able to go, “Oh, I want to do this.” And they just bang out what it was. So there was no need to write that outline first. And so I think some of it is how did you learn to code? I would say overall though, my experience with developers, they hate writing documentation. Getting them to even stick a comment in sometimes is almost like twisting their arm. I would do code reviews with my team and they’d be like, “Well, I made this decision.” Great. Could you put a note in as to why you did that so when you get promoted that somebody who’s coming behind? And they’d roll their eyeballs at me and I’d be like, “Come on. ” So typically that’s a tough one.
My coding style I think is pretty atypical. So yeah, documentation. That’s why
Andy:
It’s – That’s a fun part of the job. And I think it sounds like a great example of people talk about AI doing the drudgery, right? Some of those maybe road tasks don’t want to do. And sounds like, yeah, great example of that.
Rael:
Yeah. It’s a fantastic use case for Bob for a variety of reasons, not just legacy, but now you can have coders, if they want to do coding, they can write their code and then use IBM Bob to document it. And then now you’ve got the best of both worlds. You’ve got somebody who’s loving their coding job and they get decent documentation.
Andy:
Yeah. They’re free. Maybe they even do a better job at coding since they’re not getting weighed down by having to do the documentation.
Rael:
Great point. Exactly.
Andy:
Okay, okay. Another question I had was like, so say you’re a developer and you know the language you’re working with, you know the language that the output is in, but your thinking still has to change, right? How does using these coding assistants in general change the way you think? I mean, if you’re not coding at all anymore, maybe you still are, but I mean, yeah, what are you doing? How do people need to rearrange their minds to make this work.
Rael:
I think there’s two thoughts about that. One is I think you’re going to see more developers move to much more of the style that I talked about, which is you write the outline or you write the spec for your code and so you’re going to move to a little bit higher level thinking as opposed to the lower level tasks. Having said that, because the languages are always getting updated, or at least the ones I use. Python has always got new modules and new components coming out and new objects. I mean, because the languages change and get upgraded, you can’t just rely on AI to code. You still need to do some manual coding to stay fresh and keep your skills current. I mean, you just can’t, at least in my opinion, that would be a huge mistake because then you’re not going to keep up with advances in your chosen field.
And so I think they’re going to have to change to being deliberate about planning to write code that take advantage of the new things that come out so that they stay current. So I think that’s a big change. And like I said, I think for many developers, changing to thinking about it more from a spec perspective is going to be a big change, which is naturally going to create some documentation, maybe not detailed enough for something to be turned over should they get promoted or win the lottery or something like that.
And I think they also probably need to start to think about what that looks like when they are ready to move up, move out, move on. I know you alluded to the article and I’m going to touch on something that I think was posted out on LinkedIn is I forget what you called. There was a name that you used for the gap, but what we’ve been talking about is… Say
Andy:
I’m sorry. Cognitive atrophy?
Rael:
Yes. In the cognitive atrophy that you talked about is what I consider that skills gap. So we’ve been talking to our customers and saying, “Hey, your experts we think are going to become more valuable in the next five to 10 years, because we’ve got to be experts and we’re able to take these tools and we’re able to know within our area of expertise, are they doing what we’re expecting them to do in the right way? The organizations who choose not to bring in new engineers or new developers are going to put themselves in a devil of a pickle because how did I get to be an expert in my field? How did you get to be an expert in your field?” We got to be that because we started doing the small mundane kind of grunt work and there was somebody to give us some feedback.
And if companies don’t invest in those people and those new developers, whatever ages they may be, 10 years down the road when I decide to retire, who’s the expert that’s going to take my… All of a sudden there is no expert to backfill for me.
So you called it cognitive atrophy and I think that is something every organization needs to be aware of. And I also think, although interestingly, when I first saw that term, I thought of it in terms of myself as a developer and I’m like, “How do I not have cognitive atrophy when I’m relying on IBM Bob and I’m going to pick on our cellphones?” I don’t know about you, but I don’t remember a lot of people’s numbers anymore by memory, even though I used to know there are a few. I mean, I have about 10 that I remember that I could dial if I was given an old dial phone because I’ve known them for so long. But there’s a lot of people that I talk to every day. I couldn’t tell you what their phone number is unless I looked at it. And so to me, that’s a form of cognitive atrophy.
And I think we as developers need to be very careful of doing that to ourselves by relying too heavily on AI to do our job and just orchestrating. And that’s candidly, one of the things I like to do with Bob, I write my code and then I have Bob review it and go, “What did I miss? Where could I tighten it up? Where could it be more efficient? When I’m in a hurry, do I do that? No. If I’ve got to get something out the door, I’m going to write a spec and I’m going to ask Bob to write it. But when I’m playing with things, I want to write the code so that I don’t lose that like I’ve lost my phone numbers.
Andy:
So you’re not ready to completely let go of that ability. And I imagine once an organization maybe loses that expertise, they’re just kind of, well, they just have to trust the AI, I guess, at that point, right? They’re kind of trusting the black box.
Rael:
And to me, that’s very scary. I mean, the reality of AI, even with good security controls, being able to do something that is unexpected is 100% there, and it will never, ever go away because foundationally AI is based on a probabilistic sampling of the data set. So if I write the same prompt every day at 8 AM into the same LLM, into the same AI tool, I guarantee you it will not be identical one day to the next. It’ll probably be really close because hallucinations have gotten substantially better in reduction, but it will not be identical. I mean, unless it’s like a one-word answer, like you’re asking a dictionary answer—because it’s going to sample whatever hundred pieces today, it’s going to grab a different hundred pieces tomorrow. So you cannot trust that AI, at least today, maybe tomorrow, but I can’t imagine—unless, okay, maybe if quantum becomes a real thing and I don’t even know if quantum makes sense for AI or not, maybe because then you could always guarantee that it always picked the same? But I don’t know. I just think it’s really again, to me, that’s like plan roulette. And I don’t mean Russian roulette, I just mean roulette in general. Pick a number and go.
Andy:
Yes. Yeah. Taking your chances. Yeah. I was going to ask you if you’re going to miss coding, but it sounds like you’re not going to miss coding because you’re not going to stop coding. Am I understanding right there? Okay.
Rael:
Yeah. I’m going to miss some of it. And I think the things that I’m going to miss are, believe it or not, I’m probably going to… I would say my frustration level with coding has gone down a lot because I’m much more quickly able to solve when I get an error now. That’s the other thing that I use a lot of Bob for is if I write something and I get an error, I’ll throw that error into Bob and go, “What did I do wrong?” And one of the things I love about development is the aha moment when it works.
And so I used to do happy dances with my team before I joined Evolving. And there’s something really rewarding after it took me two months to learn to do something and that I’m incredibly proud of. There was a lot of swearing and a lot of frustration and a lot of head banging on the table. But I have to tell you, when I figured it out, it was just that discovery and there’s just this huge rush of I finally solved it. And I think the opportunities for that are a little smaller now with AI because that battle is not nearly as hard fought, if that makes sense.
Andy:
Yeah, it does. So maybe you have to find that level of satisfaction in other pursuits maybe. I don’t know.
Rael:
Maybe. I mean, that’ll probably be the one thing that I’ll miss is like I said, that level of satisfaction. Although to be—little news, I’ll share with you here. I actually am applying for a PhD program right now and I’m just finishing up a personal statement. I’m planning on going back to school to get a doctorate in AI. So I have a feeling I’m probably going to get that same sense. I’m just going to get it somewhere else.
Andy:
Yeah. New problems to solve, right? It’s all about you’re going up a level, right? Now you have an orchestration problem to solve or something and yeah, new challenges will arise.
Rael:
They will, but I don’t think it’s going to have that same coding challenges because it’s so much easier to troubleshoot now.
Andy:
Well, I don’t know. It sounds like it might be no turning back because this is kind of the new world we’re in. But Rael, thank you so much for giving us an idea of what IBM Bob is all about. I think we’re all benefiting from your extensive experience with the tool. So thank you so much, Rail. I really appreciate you joining us here.
Rael:
Thank you for letting me talk about it. It’s a super exciting field and I am just a huge fan of Bob. So any questions, please. I’m happy to answer any questions anytime. So thanks again, Andrew.
Andy:
Thanks Rael. All right. And for our audience out there, I just have to let you know if you don’t want to miss any content like this, just subscribe to our newsletter and you can go to techchannel.com/subscribe to do that. So there you go. All right. Thanks Rail. I’ll talk to you later.
Rael:
Bye-bye.