Smarter than Grep: What Happens When You Let an LLM Read Your Logs? | HackerNoon

Good old software engineering has long relied on Bash scripts to handle small but critical tasks. Whether it’s scheduling cron jobs, managing files, or automating routine system processes, Bash has remained a brutally simple, fast, and dependable tool for every engineer. But with the rise of the AI revolution — I’ve been experimenting with a new kind of automation. One that doesn’t depend on hard-coded logic, but instead on reasoning. LLMs that can not only perform many of the same functions as Bash scripts, but do so while sparing me the technical minutiae of scripting.

This post explores a question I’ve been genuinely curious about: Can large language models (LLMs) complement or even replace traditional Bash scripts for managing real-world infrastructure tasks? I put this to the test using some of my own tools — and honestly, I was surprised by how well an LLM could interpret logs and surface meaningful insights, with zero scripting involved.

Let’s take a simple use case to demonstrate – Extract last 10 critical error entries from a system log (e.g., /var/log/syslog) and generate a human-readable summary of what went wrong.

The Traditional Way: Bash Scripts Still Rock

A simple bash script that can be used to perform the task at hand:

#!/bin/bash
grep -iE "error|fail" /var/log/syslog | tail -n 10

If we break down the above line,

- grep: searches text using patterns

- -i: case-insensitive matching (matches "ERROR", "error", etc.)

- -E: enables extended regex (lets you use | as "OR")

- "error|fail": matches lines that contain either "error" or "fail"

- /var/log/syslog: the file being searched

- | tail -n 10: pipes the results into tail, which returns the last 10 lines

The result of the above command will show the 10 most recent log lines that contain “error” or “fail”. (as our expected result from the problem statement)

Now lets’ take a look a an example output

Apr 21 10:15:01 myhost CRON[31582]: (root) CMD (run-parts /etc/cron.hourly)
Apr 21 10:15:02 myhost systemd[1]: Failed to start Network Time Synchronization.
Apr 21 10:16:05 myhost kernel: [12345.67] CPU0: Core temperature above threshold, cpu clock throttled
Apr 21 10:18:11 myhost systemd[1]: Starting Cleanup of Temporary Directories...
Apr 21 10:18:12 myhost systemd[1]: Finished Cleanup of Temporary Directories.
Apr 21 10:20:43 myhost sshd[31612]: Failed password for invalid user admin from 192.168.1.5 port 60522 ssh2
Apr 21 10:21:00 myhost sudo[31645]: pam_unix(sudo:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/0 ruser=user rhost=  user=user
Apr 21 10:21:05 myhost systemd[1]: Failed to start User Manager for UID 1001.
Apr 21 10:22:34 myhost app[31710]: Error loading configuration: file not found
Apr 21 10:23:15 myhost docker[31750]: container failed to start due to missing environment variable

From the above logs, we can see multiple issues about systemd processes failing to start, CPU overheating warnings, App config and container startup issues. With a bash script, the processs stops at raw data. It is up-to user to understand and intrept the output, perform root cause analysis and fixes. In summary,

1. The output has no context
2. The output has no categorization
3. No explanation of what do to next

The AI Alternative: Using LLMs for Log Summarization

Here is where LLMs come in! What if we can add another step to this process to make it earlier for a user to understand the meaning of these errors and guide them with troubleshooting steps?

In this example, I’ve used a simple summarization API from Cohere. To run it, you’ll need to create an API key from Cohere (or a similar LLM provider) and assign it to cohere_api_key.

import cohere

cohere_api_key="Enter key here"

co = cohere.Client(cohere_api_key)

log_text = """
Apr 21 10:15:01 myhost CRON[31582]: (root) CMD (run-parts /etc/cron.hourly)
Apr 21 10:15:02 myhost systemd[1]: Failed to start Network Time Synchronization.
Apr 21 10:16:05 myhost kernel: [12345.67] CPU0: Core temperature above threshold, cpu clock throttled
Apr 21 10:18:11 myhost systemd[1]: Starting Cleanup of Temporary Directories...
Apr 21 10:18:12 myhost systemd[1]: Finished Cleanup of Temporary Directories.
Apr 21 10:20:43 myhost sshd[31612]: Failed password for invalid user admin from 192.168.1.5 port 60522 ssh2
Apr 21 10:21:00 myhost sudo[31645]: pam_unix(sudo:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/0 ruser=user rhost=  user=user
Apr 21 10:21:05 myhost systemd[1]: Failed to start User Manager for UID 1001.
Apr 21 10:22:34 myhost app[31710]: Error loading configuration: file not found
Apr 21 10:23:15 myhost docker[31750]: container failed to start due to missing environment variable
"""

prompt = f"""
You are an AI system assistant. Here are recent log entries:

{log_text}

Summarize:
1. What went wrong
2. Any recurring or serious issues
3. Suggested next steps
"""

response = co.generate(
    model="command-xlarge", 
    prompt=prompt,
    max_tokens=200
)

print(response.generations[0].text)

Let’s see the output from the above program:

The recent log entries indicate several issues:

1. There are errors and failures mentioned across different services, indicating some system instability. These include: 
    - Failed attempts to authenticate invalid users for SSH and sudo. 
    - cron and systemd errors starting the Network Time Synchronization and Cleanup of Temporary Directories. 
    - Failure to start the User Manager for UID 1001. 
    - An application error loading the configuration file. 
    - A Docker container failure due to a missing environment variable. 

2. Based on the log entries, no single issue is particularly recurring, but several different errors are frequent enough to be cause for concern. 

3. It is suggested to investigate and address the specific causes of the aforementioned issues to ensure the system functions optimally and securely. This may include reviewing authentication settings, checking system services configurations, verifying file locations for the configuration file, and inspecting the Docker container settings. Also, it is important to consider if any messages are explicitly highlighted across the logs,

Now, let’s level up the prompt a bit to get a structured output, along with the chat API endpoint.

response = co.chat(
    model="command-r",
    message=f"""
You are a system assistant. Given the logs below, extract all relevant issues and organize them into a table with these three columns:
1. Issue
2. Severity (Low / Medium / High / Critical)
3. Troubleshooting Recommendation""")

Here’s the result generated by the LLM:

Beyond LLMs: Enter the AI Agent

This is solid, but it could use just a bit more energy to tee up the comparison table. While Bash has served as a reliable workhorse for system automation, and LLMs offer a huge leap in interpreting infrastructure data like logs, they both operate within well-defined bounds. Bash is deterministic and fast, while LLMs are contextual and flexible — but still rely on human-triggered prompts. This is where AI agents come in.

Agents go one step further — they’re not just responding to prompts, they’re designed to act on goals, use tools, make decisions, and even loop through retries or escalate issues autonomously. Imagine a system that doesn’t just summarize errors but reads logs, correlates events, checks service health, and opens a Jira ticket — all without you lifting a finger.

Bash vs LLMs vs AI Agents

Here’s a quick comparison to highlight how these approaches differ:

We’re at interesting crossroads when it comes to automation. Bash is still the go-to for quick, repeatable tasks — and probably always will be. But with LLMs and agents stepping in, there’s a new way to approach problems that demand more context, flexibility, or even decision-making. This isn’t about replacing Bash, but about using the right tool for the job — whether it’s a script, a prompt, or a full-blown autonomous agent. As these technologies mature, I’ve found myself thinking less like a scripter and more like a system architect — connecting tools, shaping workflows, and designing for adaptability.