Developers should use both: IDEs help understand and change code, while CLIs help execute, validate, operate, and deliver it. Neither tool wins; reducing friction and context loss between them is the important goal.
Ansible is an agentless IT automation platform for configuration management, application deployment, cloud provisioning, ad-hoc task execution, network automation, and multi-node orchestration. It describes infrastructure and tasks in a human- and machine-readable language, connects to remote systems through existing SSH services, and executes changes across machines in parallel without installing agents or opening additional ports. Ansible can be installed through pip or a package manager and supports operations such as application deployment, infrastructure updates, and zero-downtime rolling changes with load balancers.
Jenkins is an open-source automation server for continuous integration and continuous delivery (CI/CD). It automates software builds, tests, and deployments through Pipeline definitions and a large plugin ecosystem, and supports distributed build agents across multiple operating systems.
Searchable transcript of IDE vs CLI: What Every DevOps Engineer Should Know — IBM Technology (09:38). Search for a phrase, then click its timestamp to jump straight to that moment in the video.
Captions sourced from the original video on YouTube, published by IBM Technology. The video, its captions and all related intellectual property remain the property of their respective owners; AINotes claims no ownership. Provided for research, accessibility and search — see the Transcript Notice and Copyright Policy.
00:00 Okay, so Legree, would you rather use an IDE or a CLI? Yes. That's not even an answer. It's an honest one. I don't think there's any developers or engineers who only use one. That's fair and that's exactly why we wanted to do this video so that you can learn the differences between a integrated development environment or IDE. And a command line interface or CLI.
00:29 Let's get started. Now we said most developers use both an IDE and a CLI, but what does this really mean? Yeah, so you're likely to have an editor with your code base. This is your IDE where you're working on new features or maybe fixing bugs. But at the same time, it's not just the code that you need to think about, right? It's also, say for example, running tests to make sure that everything is working properly.
00:54 And this is going to happen in your CLI, where you have maybe live updates from a server that you're connected to, the build pipeline, and maybe even a VM that you connected to three days ago and forgot to close. I'm definitely guilty of that. It happens to all of us, but if you can agree that everyone's using both of these tools, then the interesting part is what's happening in the space between them.
01:17 Right, because code was never our full job. And the modern development spans across code repositories. Test. Build pipelines. Deployments. And cloud resources. And so the friction isn't just writing the code itself, but I guess coordinating everything around it. That's exactly it. Let's explain how. Of course, so let's say that you're working to build an awesome new app or feature in your IDE, but you're notified that a test case is failing.
02:05 Oh no, so where do we begin? Well, good question. This is where we use the IDE to see what specific test case is breaking, where is it at in the actual code base, and then we're also going to check the repository so that we can push this to our teammates and get this in a collaborative space. At the same time, we're going to be updating the infrastructure as code so it can be later deployed to all of our environments in the cloud and beyond.
02:32 And these are tasks that you'll do in an editor. There's really nothing else that can do it that well. But while the IDE can help write and understand code, we've got to move to the CLI in order to, say for example, run the test suite for our application. We're also going to use the CL I in order to kick off a build. And that build, while we might be doing it locally, we're going to be probably deploying it to someone else's machine, maybe in the hybrid cloud.
03:00 And we might even pull off logs from that cloud machine to make sure that everything is working. So... You can see there's a lot that's happening. Wait, how many times did we just switch environments? Oh jeez, at least five different times. And each of these times I'm carrying something with me that all of these tools don't have access to. For example, the editor itself doesn't know why I made the change and it can't pass that to the terminal, and the terminal has no way of passing that to the pipeline either.
03:30 And as AI helps generate more and more code and more changes to our application, all this context across the workflow gets even harder. So you, the human, have to be the glue holding everything together, right? Well, hopefully, right? Until I'm pulled into another meeting with my colleague and I totally forget about what was happening here. And none of that is a tooling failure.
03:54 They did their jobs. That's just what we know of as context overload. But we will get back to that later. So let's make a clear distinction between these two and when to use them. An IDE helps you write code, and a CLI helps you operate systems. I mean, that's about as clean as it gets. So on the IDE side, you've got actions like discovering code bases.
04:22 Maybe a project is new to you and you can use the IDE to see what's going on. You can also refactor the code to make it more readable and more appropriate for your team or even modernize it to a new framework. And finally, debugging. If something is wrong in the code base, you can go into the exact file, see what wrong and fix it. So it's all about comprehension and speed of the project.
04:44 So you can code. See the error, and fix it all within a few seconds. And on the CLI side is operation, like automation of a system with Ansible or running a pipeline with Jenkins. Or anything repeatable, scriptable, or remote will be done from the CLI. And there's really not much you can't do. Which is a good point. With the IDE, you've got these kind of guard rails, but with the command line, not so much.
05:21 But that's the thing, you shouldn't have to choose between the speed of an IDE and the power of a CLI. But in today's world, you kind of do, constantly having to cross between both and carrying that context yourself. Well, what are you losing at each handoff? Well, not to sound like an LLM here, but context. What's that mean? Well, that's a good question.
05:46 As work moves from just code to testing that code to automating it to then be deployed in different environments. Well, at all of these steps, we're no longer just managing for example, our repository of code, right? We're also working between different environments, different computing machines, for example. We're working with different CLI tools. And we're also working with communication apps, just to name a few of them.
06:19 And as an engineer here, we are the link between all of these different environments and steps, which can lead to context overload, which is what we mentioned earlier. And those handoffs add a little friction on their own. But over a day, it can really add up. Exactly. And it's a workflow problem rather than just a code problem. You could have the best AI code generator and that wouldn't solve this problem.
06:46 So what does it look like when tooling actually works across both the IDE and the CLI? Well, there's four things. First is the ability to have multi-step execution, because most work isn't a simple fix, right? It's a sequence of events. Let me give you an example. Perhaps you have a user submit an issue, and you change some functionality in order to accommodate that, test that in various ways to make sure that change works, and validate it across environments to deploy it to users.
07:18 Now these are steps that must happen sequentially or maybe even asynchronous. Now next is coordinated execution because as a human I'm likely to get hungry around noon and go out to grab lunch, but AI agents are able to work continuously one after another or as I mentioned asynchronously in order to complete tasks by connecting to different environments without needing me to connect them.
07:44 Now third is automated validation. So many times we make a change and cross our fingers that it works because it worked last time, but don't forget that that's really only half of the job. And the other half is checking and validating and making sure that the result is what you want. Exactly. And finally, the ability to have shell and remote access to systems because a lot of the action isn't just on a laptop, right?
08:13 It's on say, for example, a build agent or pipeline that brings it to a container to run locally or on Kubernetes or a virtual machine, which is where the application will end up running most likely. And if a tool isn't able to reach these different environments, and it can only help with part of the So if there's one takeaway here, it's not that one of these tools wins.
08:37 Exactly. Most developers use both an IDE and a CLI, and have for years. The real challenge here is the context overload carrying the context across coding, testing, builds, deployment, and infrastructure. And that's where the time goes. And as AI development tools mature, that's where the real opportunity is, because it's not just whether it can write code.
08:59 We know they can write, but it's the ability to manage that context overload, be able to carry tasks across different environments and help us as engineers and developers to do our job better. Exactly, IDEs help you understand and change code. CLIs help you execute, validate, and deliver it. But if you reduce friction between these steps, well, your life is gonna get a whole lot easier.