DEV Community: hitesh

I Made My Terminal 7.5x Faster by Deleting the Tools Everyone Tells You to Install

hitesh — Sun, 07 Jun 2026 19:20:26 +0000

My shell took 2 seconds to start. Then I realized an AI agent was paying that tax hundreds of times a day.

For fifteen years the advice was settled: install oh-my-zsh, add some plugins, get autosuggestions and a pretty git-aware prompt. It made the terminal nicer to sit in front of. That assumption — a human, sitting, typing, one command at a time — is now wrong most of the time.

On my machine, the overwhelming majority of terminal commands are issued by AI agents, not me. And once that flips, every plugin you installed for human comfort turns into a tax the machine pays on your behalf, over and over.

I profiled my own setup and cut shell startup from 2.05 seconds to 0.27 seconds — roughly 7.5x — by deleting tools that added zero value to an agent workflow. Here's what I found, why it matters more now than ever, and how to audit your own machine.

The thing nobody tells you: agents don't reuse your shell

When you work in a terminal, you open it once. Your ~/.zshrc runs a single time, you pay the startup cost once, and then you type into that warm session for hours. If sourcing oh-my-zsh costs 600ms at launch — who cares. You paid it at 9am and forgot about it.

AI agents don't work that way. An agent that runs terminal commands typically spawns a fresh shell process per command (or per small batch). There's no long-lived session it's lovingly curating. It runs git status → shell starts → sources your full init → runs the command → exits. Then it runs bun install → a brand new shell starts → sources your full init again → exits. Every command re-pays the entire startup cost.

Now layer on how modern agentic tools actually operate:

Parallel sub-agents. Complex tasks fan out across multiple agent threads working concurrently — one gathering context, one running tests, one editing files. Each spawns its own shells.
Background processes. Dev servers, watchers, and test runners get their own shell instances.
Retry and verification loops. Run a command, check output, fix, re-run. More shells.

So the cost isn't startup_time. It's:

startup_time × commands_per_task × parallel_agents

That 1.78 seconds I shaved off isn't saved once — it's saved on every shell spawn across every agent thread, all day.

A rough illustration: an agent task that runs 50 commands used to burn ~100 seconds just starting shells before doing any real work. Run three agents in parallel on a big task and you're throwing away minutes of pure init overhead — plus the CPU and battery to do it.

What I found when I profiled it

I used zsh's built-in profiler to see where 2 seconds per shell was going:

# Drop this at the very top of ~/.zshrc temporarily
zmodload zsh/zprof
# ... your config ...
# And this at the very bottom
zprof

Open a new shell and read the table. The results were almost comically lopsided.

Offender #1: The Yandex Cloud CLI's completion script — 827ms (52% of total)

The single biggest cost wasn't even a "plugin." It was the shell-completion script for the Yandex Cloud CLI (yc) — an SDK I'd installed months earlier and stopped using. The function eating the time showed up in the profiler as __yc_bash_source, and the completion file it sourced (completion.zsh.inc) was 9 MB. Every shell launch sourced nine megabytes of bash-compatibility completion logic to enable tab-completion for a command I never typed — and that the agent certainly never typed. The whole SDK was 189 MB sitting in ~/yandex-cloud.

This is the purest form of the problem. Tab-completion helps a human who is typing and pressing Tab. An agent generates the entire command string in one shot from a language model. It will never press Tab. The feature's whole value proposition is irrelevant to the primary user of the shell, yet it was the most expensive thing in the startup path.

Offender #2: The completion framework itself — ~640ms

oh-my-zsh's machinery (compinit, compdump, and ~2,500 compdef calls) accounted for most of the rest. compinit rebuilds a completion cache and runs a security audit over completion directories. Useful if you live in the shell. Dead weight if a model is generating your commands.

Offender #3: Forge's shell plugin

Ironically, a different AI coding tool — Forge (a CLI agent) — had installed its own zsh plugin (commands, completions, keybindings) that ran on every launch via eval "$(forge zsh plugin)" in the hot path. AI tooling adding shell-interactivity features to speed up humans, slowing down the AI tooling that's actually running the commands.

The cleanup, in order of impact

I removed things in descending order of cost, measuring after each step:

Step	What I removed	Startup time
Baseline	—	2.05s
Remove Yandex Cloud CLI (`yc`) + its 9MB completion	source lines + 189MB SDK	0.90s
Remove oh-my-zsh	framework + 14MB install	0.40s
Remove Forge's shell plugin	`eval` block + 33MB binary	0.30s
Remove completion entirely (`compinit`)	I never tab-complete	0.27s

A few details that turn this from "delete stuff" into something you can reason about:

Interactive vs. non-interactive shells matter. History expansion (the ! that breaks commit messages), completion, and prompt theming are interactive features — they only load in interactive shells. The fact that they bit an agent at all confirmed it was launching interactive shells that source ~/.zshrc, which is exactly why trimming the file paid off per-command.

Removing a tool means removing what depended on it. When I deleted oh-my-zsh, Forge's plugin started throwing command not found: compdef — oh-my-zsh had been initializing the completion system, and Forge registered its completions through it. You can't just yank the framework; you either restore the one primitive the dependents need (a lightweight compinit) or remove the dependents too. (I eventually removed both Forge and completion entirely.)

Cache logic is easy to get backwards. The standard "rebuild the completion cache once a day" idiom uses a glob modifier to check the dump's age. I initially inverted it and silently ran the slow audited rebuild on every launch instead of the fast cached path. It looked fine and cost 300ms every time. Profile after you change, not just before.

The principle: optimize for your actual primary user

The mental shift is this: your shell's primary user is now a program, and programs have different needs than people.

A human at a terminal values:

Autosuggestions and tab-completion (you're typing, you want help finishing)
A rich, git-aware, colored prompt (you're reading it constantly)
Syntax highlighting (you're scanning your own input)
History shortcuts like !! and !$ (you're recalling past commands)

An AI agent values:

Fast process startup (it spawns shells constantly)
Non-interactive, non-blocking behavior (it can't press q to exit a pager or type into an editor)
Predictable, literal command parsing (history expansion silently breaking a ! in a commit message just wastes a turn)

Almost none of the human-comfort features help the agent, and several actively hurt it. The pager that opens less on git log and waits for a keypress will hang the agent indefinitely — it sees no output and stalls until timeout. The editor that pops open for a commit without -m waits forever for a human who isn't coming. A glob that errors on no-match aborts a command the agent expected to succeed.

So the same audit that speeds things up also makes the environment correct for an agent:

# Non-blocking defaults — nothing waits for a human
export PAGER=cat
export GIT_PAGER=cat
export EDITOR=true          # a no-op "editor" that exits instantly
git config --global core.pager cat
git config --global core.editor true

# Parse command strings literally
setopt no_bang_hist         # '!' stops triggering history expansion
unsetopt nomatch            # don't error when a glob matches nothing

These aren't speed optimizations exactly — they're "stop the agent from getting stuck and burning tokens recovering from a hang" fixes. In an agentic workflow a blocked command is worse than a slow one: it doesn't just cost time, it costs context and tokens while the model tries to figure out why it got no response, often flailing into other tools.

It's not just the shell — it's the whole IDE surface

The same logic extends past ~/.zshrc.

The file watcher. My editor was watching ~163,000 files, 64,000 of them in node_modules. A file watcher exists so the UI updates when files change — but an agent is constantly changing files and doesn't need a watcher to know it did; it made the change. Excluding node_modules, build output, and caches removes a continuous CPU/memory drain and, crucially, removes event-queue lag that can delay saves.

// settings.json
"files.watcherExclude": {
  "**/node_modules/**": true,
  "**/.svelte-kit/**": true,
  "**/build/**": true,
  "**/dist/**": true,
  "**/.git/objects/**": true
}

The dirty-buffer conflict. Without auto-save, a human's unsaved editor buffer and the on-disk file diverge the moment an agent edits that file directly. You get a "save / revert / overwrite" conflict prompt — and the agent, seeing stale or conflicting content, second-guesses itself and wastes turns. Aggressive auto-save keeps disk and buffer in sync so the conflict never arises:

"files.autoSave": "afterDelay",
"files.autoSaveDelay": 1000

This is a pure agent-era failure mode. It literally cannot happen in a human-only workflow where the same person owns both the edit and the save.

How to audit your own setup

Profile, don't guess. zmodload zsh/zprof at the top, zprof at the bottom, open a shell, read the table. The offenders are almost never what you'd assume.
Time it honestly: for i in 1 2 3; do /usr/bin/time -p zsh -i -c exit; done. A lean config is well under 0.3s; over a second means you have a problem.
Delete by impact. Start with the biggest line in the profile. Re-measure after each removal so you know what actually moved the needle.
Remove the dependents, not just the framework. Anything hooked into what you deleted will break loudly or silently. Decide whether you need the primitive or the dependent at all.
Make it non-blocking. Pager → cat, editor → no-op, disable history expansion, don't error on unmatched globs. Correctness for a non-interactive caller, not just speed.
Extend to the IDE. Exclude heavy directories from the watcher and search; turn on auto-save so agent edits never collide with stale buffers.

The takeaway

oh-my-zsh, fancy prompts, and completion frameworks weren't bad tools. They were right for their era — when a human sat in front of one long-lived terminal and the startup cost amortized to nothing. That era is ending. When an AI agent spawns hundreds of short-lived shells across parallel threads, the math inverts completely: a one-time convenience becomes a per-command tax multiplied by your concurrency.

The fix isn't anti-tooling. It's recognizing who your tools are actually serving now. My terminal got 7.5x faster not because of some clever trick, but because I stopped optimizing it for a user who's barely there anymore and started optimizing it for the one doing most of the work.

If a program is typing your commands, build the environment that program needs — fast, non-blocking, and literal — and keep the human-comfort layer for the rare moments you're actually in the driver's seat.

Have you stripped your shell for an agent workflow? What was your biggest offender in zprof? Drop your before/after numbers in the comments.

From Node.js to Go: Supercharging S3 Downloads of Thousands of Files as a Single Zip

hitesh — Wed, 21 Aug 2024 03:09:09 +0000

As developers, we often face challenges when dealing with large-scale data processing and delivery. At Kamero, we recently tackled a significant bottleneck in our file delivery pipeline. Our application allows users to download thousands of files associated with a particular event as a single zip file. This feature, powered by a Node.js-based Lambda function responsible for fetching and zipping files from S3 buckets, was struggling with memory constraints and long execution times as our user base grew.

This post details our journey from a resource-hungry Node.js implementation to a lean and lightning-fast Go solution that efficiently handles massive S3 downloads. We'll explore how we optimized our system to provide users with a seamless experience when requesting large numbers of files from specific events, all packaged into a convenient single zip download.

The Challenge

Our original Lambda function faced several critical issues when processing large event-based file sets:

Memory Consumption: Even with 10GB of allocated memory, the function would fail when processing 20,000+ files for larger events.
Execution Time: Zip operations for events with numerous files were taking too long, sometimes timing out before completion.
Scalability: The function couldn't handle the increasing load efficiently, limiting our ability to serve users with large file sets from popular events.
User Experience: Slow download preparation times were impacting user satisfaction, especially for events with substantial file counts.

The Node.js Implementation: A Quick Look

Our original implementation used the s3-zip library to create zip files from S3 objects. Here's a simplified snippet of how we were processing files:

const s3Zip = require("s3-zip");

// ... other code ...

const body = s3Zip.archive(
  { bucket: bucketName },
  eventId,
  files,
  entryData
);

await uploadZipFile(Upload_Bucket, zipfileKey, body);

While this approach worked, it loaded all files into memory before creating the zip, leading to high memory usage and potential out-of-memory errors for large file sets.

Enter Go: A Game-Changing Rewrite

We decided to rewrite our Lambda function in Go, leveraging its efficiency and built-in concurrency features. The results were astounding:

Memory Usage: Dropped from 10GB to a mere 100MB for the same workload.
Speed: The function became approximately 10 times faster.
Reliability: Successfully processes 20,000+ files without issues.

Key Optimizations in the Go Implementation

1. Efficient S3 Operations

We used the AWS SDK for Go v2, which offers better performance and lower memory usage compared to v1:

cfg, err := config.LoadDefaultConfig(context.TODO())
s3Client = s3.NewFromConfig(cfg)

2. Concurrent Processing

Go's goroutines allowed us to process multiple files concurrently:

var wg sync.WaitGroup
sem := make(chan struct{}, 10) // Limit concurrent operations

for _, photo := range photos {
    wg.Add(1)
    go func(photo Photo) {
        defer wg.Done()
        sem <- struct{}{} // Acquire semaphore
        defer func() { <-sem }() // Release semaphore

        // Process photo
    }(photo)
}

wg.Wait()

This approach allows us to process multiple files simultaneously while controlling the level of concurrency to prevent overwhelming the system.

3. Streaming Zip Creation

Instead of loading all files into memory, we stream the zip content directly to S3:

pipeReader, pipeWriter := io.Pipe()

go func() {
    zipWriter := zip.NewWriter(pipeWriter)
    // Add files to zip
    zipWriter.Close()
    pipeWriter.Close()
}()

// Upload streaming content to S3
uploader.Upload(ctx, &s3.PutObjectInput{
    Bucket: &destBucket,
    Key:    &zipFileKey,
    Body:   pipeReader,
})

This streaming approach significantly reduces memory usage and allows us to handle much larger file sets.

The Results

Before: Node.js Implementation

After: Go Implementation

The rewrite to Go delivered impressive improvements:

Memory Usage: Reduced by 99% (from 10GB to around 100MB)
Processing Speed: Increased by approximately 1000%
Reliability: Successfully handles 20,000+ files without issues
Cost Efficiency: Lower memory usage and faster execution time result in reduced AWS Lambda costs

Lessons Learned

Language Choice Matters: Go's efficiency and concurrency model made a massive difference in our use case.
Understand Your Bottlenecks: Profiling our Node.js function helped us identify key areas for improvement.
Leverage Cloud-Native Solutions: Using AWS SDK for Go v2 and understanding S3's capabilities allowed for better integration and performance.
Think in Streams: Processing data as streams rather than loading everything into memory is crucial for large-scale operations.

Conclusion

Rewriting our Lambda function in Go not only solved our immediate scaling issues but also provided a more robust and efficient solution for our file processing needs. While Node.js served us well initially, this experience highlighted the importance of choosing the right tool for the job, especially when dealing with resource-intensive tasks at scale.

Remember, the best language or framework depends on your specific use case. In our scenario, Go's performance characteristics aligned perfectly with our needs, resulting in a significantly improved user experience and reduced operational costs.

Have you faced similar challenges with serverless functions? How did you overcome them? We'd love to hear about your experiences in the comments below!