DEV Community

Quo
Quo

Posted on • Originally published at kitepon.dev

Learning About Shell and Terminal While Developing

!

This article is a republication from Claude Code 始めました.

A human using a terminal while AI extends structured connections into the computer's interior

Humans use terminals, while AI extends structured connections into the computer's interior

Hey, if it's AI, you don't need a shell or a terminal, right?

The development of AIShell started when I said that to an AI.

I had a vague understanding of shells and terminals. There's an OS, a shell, and a terminal. I use them daily in development, and I knew they were separate things.

But I didn't really grasp why they were separated.

What shells and terminals do

When I looked into it again, a terminal is an application for humans to input characters and see what the computer returns. A shell interprets the commands entered, launches programs, and asks the OS to process them.

Omitting the finer details, the diagram looks like this:

The terminal handles character input/output, while the shell interprets commands and asks the OS to process them

The terminal handles character input/output, while the shell interprets commands and asks the OS to process them

The terminal handles character input/output, and within it, the shell runs. Both are designed for humans to give instructions to the computer and understand the results.

After researching, I thought, yes, that's exactly right.

And then it occurred to me.

If it's AI, maybe you don't even need a shell.

Making AI use transformations meant for humans

When an AI uses a typical development environment, it basically goes through the same path as a human.

The AI converts what it wants to do into shell format. The execution results are formatted for humans to read in the terminal, and the AI reads them again.

If we build this for AI, we can pass instructions more directly. The results can also be returned in a form the AI needs for its next decision. This reduces the need to read long human-oriented displays each time, potentially saving tokens and speeding up processing.

If you truncate long output, the number of characters returned decreases. When necessary lines are missing, the AI starts re-executing or reading more. Rather than methods where the result varies depending on which parts are kept, reducing unnecessary conversions from the start seemed more fundamental.

It seemed interesting, so I decided to build it while learning. I thought GPT-5.6 could probably make it. Since it directly interacts with the OS, I was slightly concerned about model safety judgments preventing development.

I built AIShell

I named what I built simply AIShell. It's a Swift app that runs on Apple Silicon Macs and macOS 15 or later, connecting to the AI via MCP.

AIShell does not format the requests it receives from the AI into shell strings. It receives the program to execute, arguments, and working folder separately, and launches them directly using macOS features. File operations are also handled via macOS features.

Git, search programs, compilers, tests, etc., are already excellent. AIShell launches them directly as specified programs, managing execution time, exit status, and output.

From the AI's perspective, the path looks like this:

A typical AI uses shell commands and human-oriented text, while AIShell exchanges structured instructions and necessary information

A typical AI uses shell commands and human-oriented text, while AIShell exchanges structured instructions and necessary information

During development, I had the opportunity to see the commands AIShell sends directly to the OS and the information returned from the OS. The format differed from the commands and output I usually see in a terminal; the information exchanged directly between AIShell and the OS was laid out before me.

As I looked at it, I thought:

I can't understand this at all lol

I don't want to read it lol

The AI was progressing development using those commands and responses. It felt strange. At the same time, I realized for the first time that if an AI can directly handle something that is hard for humans to read, then building AIShell might have meaning.

Currently, AIShell exposes five features for everyday development:

  • Summarize the current state of the working folder and changes since the last time
  • Read as much as needed from multiple files
  • Search a specified range
  • Run builds or tests and return important diagnostics
  • Read the necessary range from the saved complete output

For example, even if a build outputs 216KB of diagnostics, it does not pass the full text to the AI every time. AIShell saves the complete output and normally returns the main failure cause and location. When the AI needs additional verification, it can go back to the saved output.

For files as well, I did not take the approach of re-examining everything each time. AIShell records change notifications from macOS, cross-references them with current file information and SHA-256 hashes, and returns only what has changed since the last time.

I designed it to reduce the amount shown to the AI in normal use while preserving complete evidence.

AIShell also manages safety on its own. It only operates on folders authorized by the human, and all features can be stopped from the management app. Deletion sends items to the trash, and before file updates, conflicts are detected using SHA-256 hashes. AIShell also explicitly communicates to the AI's environment the possibility that program execution may update files or communicate over the network.

Effects appeared in numbers

After building it, I compared a regular Codex with a Codex using AIShell by giving them the same tasks.

I used three tasks: a small code change, a compilation failure with a large amount of diagnostics, and a task that repeatedly checks the same working folder. Each was run three times, and both succeeded all nine times.

The results were as follows:

Measurement Regular Codex AIShell Change
Tokens per successful task 144,251 106,955 -25.86%
Average time 50.14 sec 33.80 sec -32.59%
95th percentile time 72.49 sec 43.54 sec -39.93%

For the task with large diagnostics, tokens decreased by 36.65% and time shortened by 52.01%. This was the task where the mechanism of saving complete diagnostics in AIShell and returning only the main failures to the AI worked most clearly.

This is a result from three fixed tasks under identical conditions. It does not represent a 25.86% reduction across the entire development. In small tasks, whether the AI used AIShell was not always consistent either.

Does AI really not need a shell and terminal?

I still don't know.

The numbers showed effects. In development, I haven't been able to use it much yet. I am currently using it in the development of the dotagents project while fixing bugs found along the way.

I, who only vaguely understood shells and terminals, built AIShell while learning from the AI. Through this, I finally grasped the mechanisms designed for humans to use computers.

The question I first posed to the AI still has no answer.

Hey, if it's AI, you don't need a shell or a terminal, right?

For now, it might not need them. I'll keep using it a bit more and find out.

Top comments (0)