It's Time to Learn the CLI & Your Job May Depend On It.

If you're in product delivery, GTM, IT or security operations roles, but don't know the basics of the command-line, I believe you will be at a competitive disadvantage over your peers for at least the next 3 years. Simply because not knowing how to leverage hordes of CLI tools will limit your ability to complete agentic tasks efficiently simply because those commands are often the best if not only ways that those tasks can be accomplished agentically, without having to develop code yourself.

Common use-cases will include

• GTM - Generating customer-facing branded slides from multiple content sources

• Product

  • Prototyping or deploying code to development & production

  • Generating reference diagrams from Jira, Product Board, etc.

  • Generating & shipping product documentation from source code, APIs, tickets, and other content sources

  • Syncing requirements between different systems

• SecOps - Automating common workflows around investigation, triage, response, and containment

• etc.

The evolution of agentic tooling has pulled me back into the technical depths in a way I haven’t felt in years.

The current state is that all frontier models and their tooling is essentially alpha software, and today agentic workflows are heavily dependent on calling deterministic tools such as commands and code to accomplish trustworthy work. Let me give you an example for a very common use-case which is for an LLM to load information from a PDF file so you can ask it questions about the contents or to summarize it. We take it for granted today how this actually occurs because uploading a PDF document is available to all major LLMs out of the box as a simple file upload form. But an LLM needs text, and a PDF is binary file. If the LLM was told to figure out how to parse the file itself without the help of tools, we would have two major problems

1. Non-determinism - Nuances across documents would lead to different document parsing logic and thus inaccuracies or inconsistency between how it reads a document

2. Expensive - It would be very expensive in compute power and token usage for an LLM to have to infer on how to do this every time a document was uploaded

So how is this done? well, like nearly all agentic workflows, under the hood they use a combination of deterministic tools via RAG, to do the parts that require repeatability and accuracy. In this case, it's going to leverage a document parser which could be from command-line tools or libraries such as pypdf, pdfplumber, docling, etc. These deterministic tools do the parsing, and the LLM then does non-deterministic inferences on the document to answer your questions.

But what happens if your LLM doesn't support the file type you want to ingest? Are you blocked? or will you learn how to leverage existing tooling that will help you ingest the data you want into the LLM in a way that it can understand? This is a clear example of where command-line knowledge will be helpful because chances are that an existing CLI tool exists to parse or understand that file type but the LLM will not be able to on its own.

Agents need tools to do more than just chat, and decades of CLI and open-source software provide a larger and more mature ecosystem for agentic workflows than MCP or most modern interfaces today.

The evolution of agentic tooling has pulled me back into the technical depths in a way I haven’t felt in years. I used to write a lot of command-line tools (CLI) in several former roles; when I was an administrator of *nix systems in a retail business, a security engineer at a supercomputing facility, or a software engineer at a startup. In all cases, they were used to automate tasks that needed repeatability or speed, as in the case of containment actions in incident response workflows. I love working from a CLI in general, there's no substitute for the tactile feel, and power you have over your computer when using well-developed CLI tools (but not any CLI, I'll pass on the Korn Shell (ksh) and Windows' cmd.exe). Power is derived from your ability to execute command as quickly as you can type, and it's exemplified in automating the execution of commands wrapped in logic using scripting languages so you can control behavior or flow of your workflows. To illustrate the simplicity of the CLI, simply compare deploying a new EC2 instance from an AWS account from your web browser, vs. the command-line. In your browser, you will load more than 5 different web pages, and over 10 mouse clicks to deploy a new EC2 machine. It's higher friction, and impossible to repeat at scale. In contrast, from the CLI, it's a single command:

$ aws ec2 run-instances --image-id ami-0b671272c81662a99 --instance-type t3.micro --key-name MySSHKey'

In both cases, you need to know the steps in advance to complete the task e.g. knowing where the EC2 page is, what instance type to provision, and what AMI image to use. The user interface is the only key difference.

In my experience, proficiency at the CLI coupled with an understanding of its principles has always set apart great from average engineers when it comes to delivery performance. I have found this true in software engineering, product management, DevOps, SecOps, and more. I think the divide is now higher in a world full of AI Agents. As agentic workflows become more common, command-line interfaces (CLIs) are going to experience a resurgence as a preferred way to orchestrate and manage them. Agents need tools i.e. code that it can execute, to do more than just chat, and decades of CLI and open-source software provide a larger and more mature ecosystem for agentic workflows than MCP or most modern interfaces today. In essence, Agent Skills become your human writable scripting language.

As agentic workflows become more common, command-line interfaces (CLIs) are experiencing a resurgence as a preferred way to orchestrate and manage them.

Building on this AWS example, we will create an Agent Skill for Claude Code to provision new EC2 instances whenever we need to. I can invoke this skill directly in the Claude Code interface by using it's filename in a slash-command: e.g `/provision-ec2` or I can have an agent invoke it from a Claude prompt or workflow by telling it to "Provision a fresh new EC2 box.." for me,

$ claude .
▗ ▗   ▖ ▖  Claude Code v2.1.138
           Sonnet 4.6 with medium effort · Claude Pro
  ▘▘ ▝▝    ~/repos/funproject                                                                                                                                      

⏺ Nothing to act on — let me know what you need.

❯ Provision a fresh EC2 box with SSH access

You can simply save the example file below as provision-ec2.md in a .claude/commands directory e.g .claude/commands/provision-ec2.md - when you store it in this location, it's a skill that becomes callable by a /command, named after its filename, in the Claude Code interface.

---
description: Provision a new EC2 instance (Amazon Linux 2023, t3.micro) with Jon's SSH key, a security group that allows SSH from anywhere, and also verify port 22 is open with nmap.
---

## Steps

### 1. Import SSH public key (idempotent)
```bash
aws ec2 import-key-pair --key-name "<SSH_KEY>" --public-key-material fileb://~/.ssh/aws.pub 2>&1 || true
```

If the key already exists, the error is safe to ignore.

### 2. Create the security group (idempotent)
```
aws ec2 create-security-group --group-name "SSH-Only-Group" --description "Security group for SSH access only" 2>&1
```

If the group already exists, retrieve its ID instead:
```bash
aws ec2 describe-security-groups --filters "Name=group-name,Values=SSH-Only-Group" --query "SecurityGroups[0].GroupId" --output text
```
...
### 4. Launch the instance

```bash
aws ec2 run-instances \
  --image-id ami-0b671272c81662a99 \
  --instance-type t3.micro \
  --key-name <SSH_KEY> \
  --security-group-ids <GROUP_ID> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=AutoPublish}]' \
  --query "Instances[0].InstanceId" \
  --output text
```

### 6. Retrieve the public IP

```bash
aws ec2 describe-instances \
  --instance-ids <INSTANCE_ID> \
  --query "Reservations[0].Instances[0].PublicIpAddress" \
  --output text
```

### 7. Validate port 22 is open with nmap

```bash
nmap -Pn -sT <PUBLIC_IP>
```

## After completion

Report:
- Instance ID
- Public IP address
- nmap output showing port 22/tcp open
- SSH command to connect: `ssh -i ~/.ssh/aws ec2-user@<PUBLIC_IP>`

If any step fails, show the exact error output and stop — do not proceed to subsequent steps.

You can now invoke the skill on demand, or have Claude or another tool invoke it as part of workflow or script, in an autonomous way such as when a specific condition happens.

What you have done is essentially programmed without a programming language. You can define steps using your natural language of choice (e.g. English) to get meaningful work done. And the great thing, is you don't need to be an expert. You can ask your LLM to help you create a skill that performs x, y,z and to include the commands needed and the installation instructions. For simple tasks that gets you 80% or more of the way there!

What About MCP?

Moving along, you may have heard about MCP which allows agents to communicate with one another to get work done. It's effectively an API specifically designed for Agents. This may resolve this issue to a degree but not every service or program you want to leverage in agentic workflows has an MCP server, nor one that is fully featured. In addition, we know that a lot of vendors have very poorly designed APIs and that's going to limit the impact of MCP which provides a layer ontop of those. MCP is growing and it seems like it may become the standard protocol going forward but it's not widespread yet and that will take time with only AI-forward tech / SaaS companies delivering the first MCP servers, and it will likely be years for smaller or slower moving companies to adopt. You can of course build your own MCP servers off of vendors' public APIs but that also requires CLI and basic programming knowledge of which you would greatly benefit from learning so you can get more done given the current constraints on the ecosystem.